Roll was included when determining if the craft had settled down, but since it was deliberately left uncontrolled, the roll rate would never decrease; this prevented the node executor from going to warp unless 'kicked' (when timewarp removes all angular momemtum).
It sometimes takes a few ticks before the base game updates the vessel's situation. This means that `VerticalHeadingTo` will disable the actuation controls during this time.
If the vessel switches from `VERTICAL_ASCENT` to `GRAVITY_TURN` before the situation changes, the actuation controls never get re-enabled (`VerticalHeadingTo` never gets called while, according to the game, the vessel has lifted off). This can happen if the pitch start velocity is very small, for example if the auto-turn velocity slider is all the way to the left.
This change makes sure that the actuation controls also get enabled properly while in the `GRAVITY_TURN` phase of flight, by enabling the actuation controls at the same time as the axis controls in the `AttitudeTo` method.
Fixes the root cause of the problem in #2025. (commit: 96b2ecd)
When no exception occurred in the optimizer, PSG prints "Null" to the debug log every second. This commit reduces this log spam; now it only prints the exception if an exception actually occured. (commit: 0d9594f)
Also clean up the 'SetAxisControl' toggles a bit; the axis control settings were set the same in three different places. Now it's done only once. (commit: 22f8418)
If a stage has ullage motors that light at the same time as the main engine, then hotstaging the _next_ stage does not work properly. Since both the ullage motors and the "regular" engine have the same KSP stage number, hotstaging starts when the ullage motors have less than `HotStagingLeadTime` seconds left to burn, even if the main engine burn time is much longer.
With this change, all burn times with the same KSP stage are added up to calculate the `LastNonZeroDVStageBurnTime`. (commit: 1db1e8b)
The bug occurs when using the autoascent feature for negative inclination orbits. Namely, the circularization burn was explicitly trying to achieve the _abs(inclination)_ instead of the target.
The bug was fixed by removing the `Math.Abs()` from the OrbitalManeuverCalculator.DeltaVToChangeInclination input. (commit: c767cd8)