-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support KSP ManeuverNodes as an API in Principia #1964
Comments
Better compatibility with other mods (and stock expectations) is nice. Potential issue: we use the ManeuverNode API to draw the burn direction on the navball, and to allow things like MechJeb to guide to it. This is incompatible with using it for data interchange, so we would need a mod-compatible way to inject the "current burn" direction. |
Yeah I'm not sure I see a way to fix that. ManeuverNodes only wrap one vector and that vector needs to have a reference frame, and if the navball reference frame is different from the editing reference frame that doesn't work. One idea to quickly make it easy for MJ to manipulate nodes in the node editor though is to have a UI for MJ to ask for a ManeuverNode that is in the tangent/normal/binormal frame and does bidirectional so MJ can write to it, and Principia updates the maneuver. |
So actually no this still works in principle: node.DeltaV is what editors use to read in the frenet frame. node.UpdateNode(new Vector3d(radialPlus, normalPlus, prograde), node.UT) is used to update in the frenet frame. node.GetBurnVector(orbit) is used by autopilots to point in the node direction in world-space. so the first two can be in principia's frenet frame, while the latter can be massaged so that it works for autopilots and works for the navball. |
Ah right there's a pile of MJ extensions involved in manipulating maneuver nodes: Those should probably be broken out into NodeExtensions.cs and not left in VesselExtensions.cs |
The WorldDeltaV() extension in MJ is only used in the MergeNext functionality of the NodeEditor and I'd say that was a bug and MJ should just call GetBurnVector. |
Using Unfortunately, the other direction (whereby third-party editors can be used to edit the Δv and timing of the Pricipia burn) would be made very confusing by the fact that the Principia flight plan allows only modification of the last node, so that direction is blocked by #1936. |
Upon further reflection, this seems like a lot of work (and very brittle patching) to get an API which is, as you say, a pile of insane lies. As for interaction with Principia-aware mods, the reflection API is a much more reasonable approach. |
The idea here is to allow vanilla node editors to work with Principia out of the box. So the idea is that a Node Editor could grab
vessel.patchedConicSolver.maneuverNodes
and be able to edit the UT and dV of future maneuver node(s). Prograde/Radial/Normal will be translated into Tangent/Normal/Binormal by Principia. There needs to be another Principia object which will track what the reference frame and other principia state information is. Thevessel.patchedConicSolver.maneuverNodes
API will be a simple Facade over the real thing. Principia will turn off that patched conics and the display of the maneuver node widget itself (it won't be editable from the screen). Principia will draw the current orbit out to the point of the node, then draw the outgoing orbit. The result will be that a user can install something like PreciseNode and then tweak the three components and the time of the burn.As an extended API then offer the ability to grab a PrincipiaManeuverNode (or something) object which would let Principia-aware mods tweak the reference frame and other information.
And to be clear the vanilla KSP orbit patch coming out of the maneuver node will be a pile of insane lies, particularly if the reference frame is wonky, but that's okay, nobody should use that for planning maneuvers.
Not sure exactly how to wire this up, but you already can draw the maneuver node on the patched conics display and on the navball, so you can already inject maneuverNodes. This would require making the information two-way.
For bonus points somehow plug into vessel.patchedConicSolver.AddManeuverNode(UT) and vessel.patchedConicSolver.UpdateFlightPlan() to allow third party tooling to add a new maneuver node.
So the goal is that an unmodified PreciseNode or MJ's Maneuver Node Planner would be able to manipulate a burn in Principia unmodified. Then those mods could be gradually be made fully Principia-aware. And this would reduce the strain on writing/fixing your own UX.
The text was updated successfully, but these errors were encountered: