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

Flight planner is bad #2282

Closed
Hubcapp opened this issue Aug 11, 2019 · 2 comments
Closed

Flight planner is bad #2282

Hubcapp opened this issue Aug 11, 2019 · 2 comments

Comments

@Hubcapp
Copy link

Hubcapp commented Aug 11, 2019

Regressions from the stock KSP flight planner:

  • The periapsis of the target body is not shown while adjusting a maneuver. Without this feature, I can't really tell if I'm getting close or if it just looks like I'm getting close.

  • We can't click a point on the projected trajectory to set a maneuver. Instead, the only interface to set when a maneuver occurs is a text box with "time since start of mission". This means adding MET to the "T-1d 3h 28m" point in your trajectory that you want to perform a maneuver, (e.g., at the ascending node) which is not always obvious; it can be several orbits in the future.

  • The "advance maneuver 1 orbit into the future/past" buttons are gone. These are useful. Without them, I've had to calculate my orbital period and use a spreadsheet to add that orbital period to the point in my orbit I want to perform a burn.

  • The "burn time remaining" on the navball doesn't really seem to update for me while in the middle of a burn. It just glitches out and disappears.

Generally poor design:

  • There is no scroll bar in the flight planner window. If you add too many maneuvers, they go off screen, and you have to drag the flight planner window partially off screen to compensate.

  • The sliders are pretty much unusable if the calculations become too many. Additional buttons for "add/subtract 1dv, add/subtract 5dv, add/subtract 10dv, add/subtract $userSet dv" would help, since the many calculations will only have to occur once instead for every increment on the slider. Without these buttons, I'm fiddling with moving my keyboard cursor forward and back between the hour and second and day words and adding time or subtracting time to each segment of the text box, and it's tiring.

  • Y'all don't want to support maneuver nodes b/c they are "instantaneous and we are better than that" (Option to enable maneuver nodes (feature request) #1873), but without support for manually setting which engine/s will be active for the maneuver, I've had to use the instantaneous thrust mode of the Principia flight planner anyway. There are ways to compensate manually for the imprecise nature of maneuver nodes (burning half in front and half behind; or more accurately, you can start burning before the maneuver node and finish the burn so that it's done at the point your manuever node comes up... "instantly" applying that force)... Players will never get to the point of a "Earth -> Venus -> Venus -> Mercury -> Mercury -> Mercury" type burn if they can't even get to the Moon, and I really think disabling maneuver nodes altogether is a bad decision... I don't even really understand it, since the time parameter of a Principia maneuver is still an exact point in time since the start of the mission, one point in time, the same as a maneuver node. Maybe that would be different if the engine detection worked without turning them on, actively burning. You can just adjust for imprecision after the burn is made, I really don't understand the stubbornness against what is a really great user interface.

@eggrobin
Copy link
Member

Strewn through this issue is a cluster of miscellaneous problems which vary greatly in difficulty, and of general complaints, some of which may warrant some design work, while others stem from fundamentally misunderstanding how Principia forces n-body gravity onto a game that does not have it.

To address some of the individual points:

The periapsis of the target body is not shown while adjusting a maneuver. Without this feature, I can't really tell if I'm getting close or if it just looks like I'm getting close.

The periapsis marker is shown in map view; as in stock, right clicking on it makes the label showing its altitude stay there.

We can't click a point on the projected trajectory to set a maneuver.

We are acutely aware that it would be nice to have this.

Implementing that on top of our custom trajectory rendering, especially without harming rendering performance, does not sound trivial; in any case, we have yet to invest significant time in researching this.

The "advance maneuver 1 orbit into the future/past" buttons are gone.

In a situation with n-body and extended-body gravity, "advancing by one orbit" comes with the prerequisite of defining what "one orbit" means, as the osculating period is unusable.
The good news is I have been working on that for the past six months, and now have a reasonably-robust computation of the the nodal, anomalistic, and sidereal periods.

// The period of the (osculating) mean longitude λ = Ω + ω + M.
// Note that since our mean elements are filtered by integration over this
// period, it does not make much sense to recompute it based on our mean
// elements.
Time sidereal_period() const;
// The period of the (mean) mean argument of latitude u = ω + M.
Time nodal_period() const;
// The period of the (mean) mean anomaly M.
Time anomalistic_period() const;

Surfacing that in the UI should only be a few more months away; it should then be possible to use it for flight planning.

The "burn time remaining" on the navball doesn't really seem to update for me while in the middle of a burn. It just glitches out and disappears.

This indicator intentionally does not count down as you burn, as described in the concepts page; we do not provide closed-loop guidance in an n-body environment (this is a hard optimization problem on which @lamont-granquist has been working for several years), instead we only provide open-loop guidance in the form of the countdown in the flight plan UI itself.

If you add too many maneuvers, they go off screen, and you have to drag the flight planner window partially off screen to compensate.

I'm fiddling with moving my keyboard cursor forward and back between the hour and second and day words and adding time or subtracting time to each segment of the text box, and it's tiring.

These are legitimate concerns. @SirMortimer is working on UI mocks for a redesign of most of our UI, see #2275 for a small part of that; I expect that this kind of issue will be addressed as part of that work. Of course, it will take us many months to actually get to implementing those mocks.

without support for manually setting which engine/s will be active for the maneuver

We are aware of this issue, and we will add this at some point.

[...] I really don't understand the stubbornness against what is a really great user interface.

Some context may be helpful here.

The stock manœuvres are (programmatically) fundamentally tied to the stock patched conics, their UI to the stock trajectory plotting, and all of that to the KSP Orbit class which represents a Kepler orbit.

Principia trajectories are not Kepler orbits (this is the very point of the mod). In order to force the vessels to follow their n-body trajectory, at every point in time, the Orbit is reset; this makes patched conics unusable, and requires us to disable stock trajectory plotting in order to be able to show what the trajectory truly is.

This is further complicated by the fact that the more general trajectories need exotic reference frames for visualization, which again interfere with the basic logic of the stock patched conic and manœuvre logic.

The stock manœuvres flat out cease to work; we have to reimplement something instead, just like we have to reimplement trajectory plotting.


In general, the format and tone of this issue are not conducive to actionable and constructive feedback. I am therefore closing this.

@Hubcapp
Copy link
Author

Hubcapp commented Aug 12, 2019

Thank you for reading and responding to this issue. I may reorganize parts of this into less rant-style issues & instead more constructive smaller wish-list issues, or comments under #2275 .

My main concern was that maybe the reason that it's still this bad is that you haven't got any honest feedback on it, and are just used to the way it is.

I really think, part of my difficulty with Principia is in fact the difficulty of understanding the new orbital modes (although I have read and understood the concepts pages), but a lot of it will be that the tools given to understand this new world of n-body orbital physics aren't as robust as the tools in the base game, to understand the more simple 1-body orbital physics.

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

No branches or pull requests

2 participants