-
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
Flight planner is bad #2282
Comments
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 marker is shown in map view; as in stock, right clicking on it makes the label showing its altitude stay there.
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.
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. Principia/astronomy/orbital_elements.hpp Lines 53 to 61 in 1bf7998
Surfacing that in the UI should only be a few more months away; it should then be possible to use it for flight planning.
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.
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.
We are aware of this issue, and we will add this at some point.
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 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 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. |
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. |
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.
The text was updated successfully, but these errors were encountered: