Kerbal Space Program

This is a dup of https://bugs.kerbalspaceprogram.com/issues/14076 but since that is three years old and stalled hard, I thought I'd open this with a more actionable request.

For reference that bug addresses:

https://github.com/MuMech/MechJeb2/issues/866

The bug is that when a ManeuverNode is placed via `vessel.patchedConicSolver.AddManeuverNode` and then retrieved via `vessel.patchedConicSolver.maneuverNodes<sup>0</sup>.GetBurnVector()` that there is a difference in the computed burn vectors, which can be significant.

I've gone through the MechJeb code which converts the burn vector into the frenet frame and there's no loss of precision in anything MechJeb is doing there, and it is using Vector3d.Dot to do the projection of the vector onto the coordinate axis.

Debugging the before and after of placing a maneuver node looks like:

[LOG 10:31:39.939] placed dV = [1624.97467726249, -997.372898790216, 946.492620930603]
[LOG 10:31:39.939] placed UT = 299088.096336164

[LOG 10:31:39.939] actual dV = [1625.12725957217, -997.372899802009, 946.236477800571]
[LOG 10:31:39.939] actual UT = 299088.096336164

That is logging what I want, vs. what I read back from GetBurnVector() after doing the round trip through KSP. Note that the timestamp is identical so there's no rotation-frame issues here.

While this deviation is small as with all single-precision things in KSP this can have large effects, particularly on flyby altitudes on interplanetary trips, and makes implementing a flyby transfer planner very difficult.

I'm not sure this easily replicates with the stock maneuver node editor since you have to be working in the burn vector frame, not in the frenet frame. The prograde/radial/normal values of the maneuver node will not change. But if you call GetBurnVector() and use those values to re-generate the frenet values and then write the ManeuverNode again, then if you are under the inverse rotation threshold (i.e. very low kerbin parking orbit) then the rotation being applied to the burn vector will cause the loss of precision on the conversion to the Quaternion to become apparent on every single tick.

That does suggest a solution to the maneuver node editor problem which is to make certain to work in the frenet frame consistently and not do any conversions to the burn vector, but that can't help at all with trying to precisely place maneuver nodes for flybys where the problem isn't in trying to maintain the values of the Quaternion but that the single-precision values are just not sufficiently accurate.

This has been reported against KSP 1.2.x-1.8.x and should replicate against every version of KSP.

And please don't just ask to replicate this against stock unmodded KSP, the point is that this API makes modding goals harder / impossible.