UI representation of constant acceleration

[nsgallup]

Hello, I have searched around but have not found anything. I was wondering if there has been any indication as to how the game will represent constant acceleration trajectories in the UI. Planning maneuvers in KSP 1 is pretty straightforward with the maneuver planner nodes. Will they be able to keep this simplicity with constant acceleration maneuvers?

[Vl3d]

9 hours ago, nsgallup said:

how the game will represent constant acceleration trajectories in the UI

Probably with arrows.

[t_v]

I see two options for the UI (not saying these are the ones we’ll be seeing).
 

One, the systems are separate and you create a different kind of maneuver node, and you specify what direction to thrust in (either something variable like prograde or normal, or a specific heading) by dragging arrows (and sometimes “locking” the heading) and then it shows you the new trajectory. The thrust keeps being applied until the next maneuver node, where it changes to the new thrust vector. 
 

Two, the two maneuver node styles are combined, and as you drag out your arrow, you see how long your burn is going to take along your trajectory. You would need two new interactive elements, one to specify throttle and one to lock/unlock heading, but this would have the pros of making burns less annoying (now when you set up a normal burn, the direction of the burn actually shifts as your orbit does) but the cons of making the maneuver node interface more complicated. 

[MechBFP]

At interstellar distances even the slightest error in a trajectory will cause your ship to be millions of kilometres off course.

Even interplanetary brachistochrone trajectories will have major errors if the acceleration is even slightly off course.

As such I suspect those situations won’t be handled like regular interplanetary trajectories at all  

 

[Bej Kerman]

Does it need to be complicated? Maneuver nodes don't have to work any different from KSP 1, just highlight the bits in which thrust is applied using a different colour. No arrows, no complicated UI elements, it's just an additional bit of physics to take into account. Remember that KSP 1 already has constant burns, even if not accounted for in the UI. Maneuver nodes still worked without all this overcomplication. The trajectory UI element only needs to be adjusted to show the flight path curving into the new orbit as opposed to reflecting an impulse maneuver, maneuvers can work exactly as they've always done.

 

3 minutes ago, MechBFP said:

At interstellar distances even the slightest error in a trajectory will cause your ship to be millions of kilometres off course.

Yes, then again our targets will be hundreds of millions (if not billions) of kilometers in diameter and we can always adjust course closer in where errors aren't as big.

[t_v]

Just now, Bej Kerman said:

Does it need to be complicated? Maneuver nodes don't have to work any different from KSP 1, just highlight the bits in which thrust is applied using a different colour. No arrows, no complicated UI elements, it's just an additional bit of physics to take into account. Remember that KSP 1 already has constant burns, even if not accounted for in the UI. Maneuver nodes still worked without all this overcomplication. The trajectory UI element only needs to be adjusted to show the flight path curving into the new orbit as opposed to reflecting an impulse maneuver, maneuvers can work exactly as they've always done.

In case this was referring to my post, the system you are suggesting is pretty much the same as the one I am. The thing is that players might want to burn at a low throttle for a long time instead of at max thrust for a shorter time (because while KSP 1 assumed that all of the dV happened at the same point, that system will need to decide how fast the trajectory is curving) which means extra slider #1, and then players might want to continue burning, say, prograde to spiral out of a planet, so there needs to be a way to toggle between constant and variable direction, so that's extra toggle #2. With everything already in the maneuver node system, it wouldn't be much more complex, but I proposed splitting it anyways to make it less complicated than the original KSP 1 maneuver node system. 

[MechBFP]

1 hour ago, Bej Kerman said:

Yes, then again our targets will be hundreds of millions (if not billions) of kilometers in diameter and we can always adjust course closer in where errors aren't as big.

Having to manually plan correction burns mid flight is frankly pointless busy work for the player, it serves no gameplay purpose since it is solely the result of inaccurate controls in KSP 1. 
I can almost guarantee you that whatever solution they implement for planning and burning won’t make that manual step necessary.  

[jimmymcgoochie]

Children of a Dead Earth features limited delta-V and long, low-acceleration trajectory changes as a core feature. The trajectory widget looks strikingly similar to KSP’s node editor but the planned trajectory adjusts in real time according to the vessel(s)’s acceleration with arrows to show the direction of the burn and a continuous line to show the resulting trajectory. It also has an automated burn calculator to do things like interplanetary transfers, rendezvouses with other vessels and simpler trajectory intercepts for merely flying by a target (and blasting it with railguns etc., but which in KSP would be ideal for a flyby science probe).

CoaDE uses n-body physics so it’s not directly comparable to KSP’s patched conics system, however many of the bodies have incredibly low gravity so that aspect doesn’t always matter; KSP can already show trajectories spanning multiple SOIs so it wouldn’t be too much of a stretch to make something similar work here.

The real issue would probably be trying to plan out a very long burn such that it can spiral out of a planet’s gravity well going the right way for an interplanetary or interstellar journey, which would require a level of forward planning that just sticking a node on an existing orbit and adding the necessary changes in velocity doesn’t really give you. With a proper node planning tool on hand, though, it would be much, much easier.

Edited July 29, 2022 by jimmymcgoochie