Opening and closing the vehicle editor in flight corrupts fuel and staged delta-v (even with no edit)

[Maxi]

Game Version​

2026.7.8.4980

Operating System​

Windows 10

What Happened​

Opening and then closing the vehicle editor while flying a vehicle, without editing anything, corrupts that vehicle's staging. Two things break at once:

• Staged delta-v collapses. The staging (Resource Groups) window delta-v drops to a small fraction of its real value.
• Fuel is redistributed. The propellant is shuffled between the tanks: some tanks end up near-empty, others end up holding far more than they can physically store.

The NavBall vacuum delta-v and the total propellant mass do not change, and neither do the stage numbers or the decoupler connections.

https://imgur.com/a/XMGAbJ7

(this version might be a bit higher-res: https://discord.com/channels/1260011486735241329/1260011487905189897/1529948324084453650 )

What Was Expected​

Opening and closing the editor without making any change should leave the vehicle exactly as it was. The staging delta-v and the fuel distribution should be identical before and after.

Reproduction Steps​

1. Start a flight with a staged vehicle (the stock "Rocket" starting situation is enough).
2. Open the staging (Resource Groups) window and note the vehicle's staged delta-v.
3. Open the vehicle editor, then close it again without editing anything.
4. Resume the simulation.
5. The staged delta-v in the staging window has collapsed, and the fuel gauges show the propellant redistributed, even though nothing was changed.

Reproduction Rate​

Always (100%).

Additional Info​

Suspected cause (from the decompiled source):
Leaving the editor tears it down in VehicleEditor.Dispose, which for an already-flying vehicle calls, on the live part tree:

ExistingVehicle.Parts.ResourceGroupList.CalculateStages(reconfigureTankContents: true)

The editor holds the flying vehicle's tree by reference (via VehicleEditingSpace), and this runs unconditionally because AutomaticResourceGroupMode defaults to true, even with no edit. Inside CalculateStages, the reconfigureTankContents path runs PartTree.ReconfigureTanks(), which reassigns the tank contents; the staged delta-v (SequencePerformanceList) then recomputes over the reconfigured tanks and collapses. ComputeStageNumbers also runs but leaves the stage numbers unchanged on this vehicle, so the tank reconfigure looks like the actual trigger.

Evidence:​

I wrote / vibe-coded a small read-only logging mod that dumps a before/after across the editor visit. On the "Rocket" it logs:

baseline: vehicle 'Rocket', staged=0.0 m/s, single-stage DeltaVInVacuum=14340.0 m/s, totalFuel=570529.1 kg, parts=58, stages={0:39, 1:1, 2:18}

=== controlled vehicle 'Rocket' changed across a no-control period (opening and closing the editor with no edit) ===
staged TotalDeltaV 18195.7 -> 555.0 m/s | single-stage DeltaVInVacuum 14340.0 -> 14340.0 m/s | totalFuel 570529.1 -> 570529.1 kg
stages {0:39, 1:1, 2:18} -> {0:39, 1:1, 2:18} | parts 58 -> 58
*** staged dV dropped sharply while single-stage DeltaVInVacuum (fuel mass) is unchanged: staged total is wrong after the editor-exit tank reconfigure ***
tank [2355] fill 100.0% -> 0.2%, mass 65703.2 -> 52.7 kg
tank [2706] fill 100.0% -> 101732.6%, mass 52.7 -> 71690.0 kg
tank [2759] fill 100.0% -> 0.2%, mass 71690.0 -> 52.7 kg
... (10 more tanks swap contents the same way) ...
decoupler [2712] 'CoreFairingA_Prefab_Interstage3W3HB': Connector.Connection=present, stage 0

e.g. a tank ends up holding more than it can store. I have not worked out what that means downstream, so I am only reporting the observed before/after, not claiming the mechanism.

• debug loggin Mod source: https://github.com/Maximilian-Nesslauer/KSA-StagingCollapseLogger (read-only diagnostic used for the log above)