Skip to content
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

Closed
lamont-granquist opened this issue Oct 14, 2018 · 7 comments
Closed

Support KSP ManeuverNodes as an API in Principia #1964

lamont-granquist opened this issue Oct 14, 2018 · 7 comments
Assignees

Comments

@lamont-granquist
Copy link
Contributor

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. The vessel.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.

@eggrobin eggrobin self-assigned this Oct 14, 2018
@eggrobin
Copy link
Member

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.
We do inject the "prograde" etc. direction (although this has always been a bit flaky, and it might have been broken by 1.4), so this might be feasible.

@lamont-granquist
Copy link
Contributor Author

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.

@lamont-granquist
Copy link
Contributor Author

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.

@lamont-granquist
Copy link
Contributor Author

Ah right there's a pile of MJ extensions involved in manipulating maneuver nodes:

https://github.com/MuMech/MechJeb2/blob/2c1091e1d7f009909f7a26cdfa6be88d85701e05/MechJeb2/VesselExtensions.cs#L229-L269

https://github.com/MuMech/MechJeb2/blob/2c1091e1d7f009909f7a26cdfa6be88d85701e05/MechJeb2/VesselExtensions.cs#L333-L347

Those should probably be broken out into NodeExtensions.cs and not left in VesselExtensions.cs

@lamont-granquist
Copy link
Contributor Author

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.

@eggrobin
Copy link
Member

Using DeltaV for stock-compatible data interchange combined with timely patching of nextPatch so that GetBurnVector produces the correct thing should work nicely.
It is likely feasible in the current state for Principia-to-stock communication, and would make the patchedConicSolver as close a reflection of Principia's guidance as it can be.

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.

@eggrobin
Copy link
Member

eggrobin commented Apr 3, 2019

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.
The flight plan needs additional information (e.g. inertial vs. guided tangent burn), and will end up providing additional information on the nature of the coast arcs; if it has to be around and take up space on the screen, we should address its UI issues directly rather than build a complicated way to offload some of its UI to other mods.

As for interaction with Principia-aware mods, the reflection API is a much more reasonable approach.

Sorry, something went wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants