Staging leaves VehicleConfig stale, BurnDuration stuck at 0, Auto-burn disabled,

Maxi

Member
Oct 17, 2025
51
26

Game Version​

2026.4.17.4184

Operating System​

Windows 10

What Happened​

After staging/(activating a sequence) for the first time the flight computer's BurnDuration stays at "000SEC" for any planned burn, even though the maneuver has a valid delta-v. The Auto-burn button is greyed out with the "burn duration is empty" tooltip.

What Was Expected​

After staging activates new engines, BurnDuration should recompute based on the new active engines' total mass flow rate, and the Auto-burn button should be re-armable.

Reproduction Steps​

  1. Launch the default Rocket demo with no mods.
  2. Burn the first stage until it runs out of propellant.
  3. run the staging sequence
  4. Plan an Burn
  5. The BurnDuration still shows "000SEC", the Auto-burn button is disabled even though deltaV, Time to Burn etc. are calculated.1777190521617.png

Reproduction Rate​

Always.

Possible Cause​

This looks like a timing issue around when FlightComputer.VehicleConfig is recomputed relative to the deferred IsActive application.

Vehicle.ProcessInput (next-stage branch, InputAction.CameraUp / GlfwKeyAction.Release) does:

Parts.SequenceList.ActivateNextSequence(this);
UpdateAfterPartTreeModification();

ActivateNextSequence iterates parts in the new sequence and calls ActivateInStage. For each EngineController / Decoupler /
ThrusterController, that goes through SetIsActive which queues the activation into InputEvents.IActivateInputBuffer instead of applying it immediately. The buffer is drained at end of frame in InputEvents.ApplyInputEvents.

The UpdateAfterPartTreeModification() call runs in the same input dispatch, before ApplyInputEvents. So when FlightComputer.ReadUpdatedVehicleConfiguration
iterates vehicle.Parts.Modules.Get<EngineController>() and checks each engine's IsActive flag, the new-stage engines still read IsActive == false. They're skipped
in the summation and TotalEngineVacuumMassFlowRate ends up at 0.

Burn.BurnDuration is then computed in FlightComputer.UpdateBurnTarget:


Burn.BurnDuration = 0f;
if (!VehicleConfig.TotalEngineVacuumMassFlowRate.IsNearlyZero()) {
Burn.BurnDuration = num3 / VehicleConfig.TotalEngineVacuumMassFlowRate;
}

So BurnDuration gets pinned to 0. Vehicle.IsFlightComputerDisabled<FlightComputerBurnMode> then returns true (its check is FlightComputer.Burn == null ||
FlightComputer.Burn.BurnDuration <= 0.0), and the Auto-burn gauge button stays disabled with "burn duration is empty".

Once the IActivate buffer is drained later in the same frame the engines do flip to IsActive == true, but at that point nothing else triggers a VehicleConfig refresh.

Possible Fix​

Either drain IActivateInputBuffer between ActivateNextSequence and UpdateAfterPartTreeModification, or schedule one more
UpdateAfterPartTreeModification (or just FlightComputer.ReadUpdatedVehicleConfiguration) right after ApplyInputEvents has run.

How I Found This​

I was building a mod (https://github.com/Maximilian-Nesslauer/KSA-AutoStage) that automatically stages on propellant depletion.

The mod goes through the same ActivateInStage / ReadUpdatedVehicleConfiguration code paths, just from a Harmony postfix on Vehicle.UpdateFromTaskResults instead of from the input dispatch. After every auto-stage event, the next planned Auto burn would refuse to arm with the same "burn duration is empty" tooltip and BurnDuration = 0 after one of the last game version updates changed related code. I at first assumed that it was my Bug, but was able to replicate the described issue without any mods enabled.

My initial workaround was to callUpdateAfterPartTreeModification one more time on the next tick, after the buffer had been drained: https://github.com/Maximilian-Nesslauer/KSA-AutoStage/commit/8944e29.
That worked, but I then switched to draining the buffer synchronously right after activation because i believe it to be less fragile:

seqList.ResetCaches();
InputEvents.IActivateInputBuffer.ApplyAll();
vehicle.UpdateAfterPartTreeModification();

With the drain in place, ReadUpdatedVehicleConfiguration sees the new engines as IsActive=true immediately and TotalEngineVacuumMassFlowRate is computed correctly
on the spot. The mod's auto-burns then re-arm cleanly between stages.


I then noticed that @Matty reported the same "000SEC" symptom in this earlier thread.
To check whether the same bug exists in stock, I disabled all mods, launched the default Rocket on 2026.4.17.4184, and ran the manual repro above.

Related Threads​

@Matty reported the same "000SEC" symptom in this earlier thread. Posting this one since an formal bug report did not exist yet.

Related Changelog Entries​

  • Revision 4158 by @JPLRepo
    • Changed IActivate implementations to process updates via tghe new InputEvents buffer.
  • Revision 4184 by @gravhoek
    • Notify a vehicle of a part tree modification when a sequence is activated. This fixes an error where the flight computer wouldn't realize an engine was available after activation by sequence.

Additional Info​

  • Save File attached to the Thread
 

Attachments

Upvote 0