Draggable Patched Conics

[Kernel Kraken]

I'd love it as a difficulty option. I'm not much of a hardcore player, and I don't tend to attempt super difficult things. When I'm just screwing around on easy mode, sending my garbage to the moon and sinking all of my funds into launching uranium waste into Jool, I'd love the option to skip all the fiddling and pain! That way, you could keep the normal, 6-axis dragging system from the original game and give the people just playing for shiggles a simpler way to do so.

[KerikBalm]

On 2/17/2021 at 8:49 PM, MechBFP said:

I was playing KSP and it hit me that something would be an amazing QoL feature would be draggable patched conics!
I don't mean draggable handles on the little maneuver node like you can do in KSP, I mean dragging the actual patched conic line itself into the position you want around the moon/planet.

I don't think this can work the way you want it to.

To drag something into place, you are essentially saying that you want a trajectory to intersect a given point... starting from a given point I assume. The problem is that there are potentially an infinite number of solutions to that intersect, all with varying dV requirements.

On 2/17/2021 at 8:49 PM, MechBFP said:

How many times have you wanted to enter a polar orbit, and had to mess with all 3 to 6 of the maneuver node handles until you finally were able to get the patched conic line into the position you wanted? How many times have you moved those handles only to have it fly off into interstellar space causing you to have to fiddle to find your way back or to simply start over and try again?

How awesome would it be to be able to click on that patched conics line and simple drag it around the sphere of the moon/planet until it is in the position you want, with the ability to swap the direction of the path as well?

While dragging it around I think the altitude would have to be locked and adjusted separately, and it could also do a transparent sphere overlay that would show you were it is possible and impossible to drag the path to.

Indeed, sometimes, there's simply no single maneuver that can give you the intersect. You have to choose a different start of the maneuver, or do 2 burn, etc.

I don't see how this can work.

Learn how to plan maneuvers, its the basis of the game

 

[MechBFP]

1 hour ago, KerikBalm said:

Learn how to plan maneuvers, its the basis of the game

 

Oh its pretty cool you get to play KSP 2. I assume you must have an NDA so can't tell us anymore about it. Shucks.

[Kernel Kraken]

2 hours ago, KerikBalm said:

Indeed, sometimes, there's simply no single maneuver that can give you the intersect. You have to choose a different start of the maneuver, or do 2 burn, etc.

I don't see how this can work.

Learn how to plan maneuvers, its the basis of the game

Then just let me drag-and-drop 2 maneuvers. I just want to orbitally bombard my colonies for god's sake! All those purple and blue buttons hurt my brain.

[linuxgurugamer]

1 hour ago, MechBFP said:

Oh its pretty cool you get to play KSP 2. I assume you must have an NDA so can't tell us anymore about it. Shucks.

Huh?  Where do you get that from?

The phrase "it's the basis of the game" doesn't need playtime to know it's true, since KSP2 is a sequel to KSP1

[MechBFP]

2 hours ago, linuxgurugamer said:

Huh?  Where do you get that from?

The phrase "it's the basis of the game" doesn't need playtime to know it's true, since KSP2 is a sequel to KSP1

If fiddling with maneuver nodes is going to be the basis of KSP 2, then I am going to be very disappointed.

[linuxgurugamer]

1 minute ago, MechBFP said:

If fiddling with maneuver nodes is going to be the basis of KSP 2, then I am going to be very disappointed.

Then you'd better prepare yourself for disappointment, it's going to be there.

[MechBFP]

Just now, linuxgurugamer said:

Then you'd better prepare yourself for disappointment, it's going to be there.

We shall see. Too bad this forum doesn't have a RemindMe! feature.

Edited March 9, 2021 by MechBFP

[MechBFP]

7 hours ago, KerikBalm said:

I don't think this can work the way you want it to.

To drag something into place, you are essentially saying that you want a trajectory to intersect a given point... starting from a given point I assume. The problem is that there are potentially an infinite number of solutions to that intersect, all with varying dV requirements.

That is perfectly fine, so limit the dV requirements to within a reasonable threshold, which may only allow a small area within it can be adjusted

Its not intended to be a replacement for maneuver nodes, its intended to remove the fiddling that goes along with them.

(Just a reminder the definition of that word is "annoyingly trivial or petty.")

Really, if people are arguing against adding QoL features that can used to remove annoyances, I gotta question what their motives are, because that is pretty ridiculous.

[Dientus]

I was just curious. How would you determine which axis the 'conic drag' should glide along? Would it be tied to camera view in some way? How would you go from large changes to small, so that you don't accidentally drag it out across the system?

[MechBFP]

5 minutes ago, Dientus said:

I was just curious. How would you determine which axis the 'conic drag' should glide along? Would it be tied to camera view in some way? How would you go from large changes to small, so that you don't accidentally drag it out across the system?

My idea is that a sphere would be created at the PE point of the patched conics, and then it would be dragged along that  virtual sphere attempting to maintain roughly the same PE altitude.

Edited March 9, 2021 by MechBFP

[shdwlrd]

1 hour ago, MechBFP said:

Really, if people are arguing against adding QoL features that can used to remove annoyances, I gotta question what their motives are, because that is pretty ridiculous.

Some people don't like change, can't see that there are different ways to do things, can't embrace the sayings "there's more than one way to skin a cat" and "if it's stupid and works, it's not stupid"

[linuxgurugamer]

17 minutes ago, shdwlrd said:

Some people don't like change, can't see that there are different ways to do things, can't embrace the sayings "there's more than one way to skin a cat" and "if it's stupid and works, it's not stupid"

And sometimes, something which seems simple to you is really quite complex, to the point that it's not worth doing.  This , IMHO, is one of those things

[MechBFP]

18 minutes ago, linuxgurugamer said:

And sometimes, something which seems simple to you is really quite complex, to the point that it's not worth doing.  This , IMHO, is one of those things

That is fair. However if there are no valid solutions that can be created to help with manual planning, then logically the only other solution is some form of automation to do it instead.  I don't care either way which path that might be.

[linuxgurugamer]

1 hour ago, MechBFP said:

That is fair. However if there are no valid solutions that can be created to help with manual planning, then logically the only other solution is some form of automation to do it instead.  I don't care either way which path that might be.

They did say that they wanted to improve that aspect, sx o it might be best to wait and see

[shdwlrd]

7 hours ago, linuxgurugamer said:

And sometimes, something which seems simple to you is really quite complex, to the point that it's not worth doing.  This , IMHO, is one of those things

Fair enough 

[linuxgurugamer]

16 hours ago, MechBFP said:

That is fair. However if there are no valid solutions that can be created to help with manual planning, then logically the only other solution is some form of automation to do it instead.  I don't care either way which path that might be.

I never said there were no other solutions.  In fact, the dev team for KSP2 has stated that they are working on improving the available tools.  Just don't expect a full autopilot like Mechjeb

[YNM]

Orbits are not "dragged". What you are changing is your velocity vector, which in turn changes your angular momentum (also a vector) around the parent body.

Why changing to a polar orbit is hard, despite the 'speed' barely changes ? It's because it's a vector and not a scalar, and with triangles you get to spend as much as ~1.42 times (√2) your circular orbital velocity magnitude (the scalar value). To give some idea, the circular orbital speed around Kerbin is about 2200 m/s, and that means you need to spend ~3100 m/s to change from an equatorial orbit (0° inclination) to an orbit with 90° inclination - about as much as needed to lift a payload into LKO itself.

I would say that something that allows you to change your maneuver dV nodes down to the m/s of the velocity vector change is more than enough. I've used them often enough with MechJeb. There are many times when I go and do the 'lazy' way, but often to pre-place a satellite to the right inclination once entering a new SOI (or just before it) it's indispensable to be able to command a maneuver node down to the last digit. It's realistic too if you think of TCMs of space probes. Also useful I think is to change the patched conics view between relative-to-body and the standard 'dragged' view, which gives you a much clearer idea of what's going to happen around the new parent body once you enter their SOI.

What would be nice is if the maneuver nodes can count for burn losses... but this is an equally hard problem IRL and I don't expect the devs to do the same work down to the nit and grit of someone from a space agency would do. Large TCMs around the parent star are fine I guess.

Edited March 10, 2021 by YNM

[MechBFP]

1 hour ago, linuxgurugamer said:

I never said there were no other solutions.  In fact, the dev team for KSP2 has stated that they are working on improving the available tools.  Just don't expect a full autopilot like Mechjeb

Ya that is fine by me. As long as it is more functional, I don't care if it is manual or automated.

[KerikBalm]

23 hours ago, MechBFP said:

Really, if people are arguing against adding QoL features that can used to remove annoyances, I gotta question what their motives are, because that is pretty ridiculous.

I am all fir QoL features, I just don't think that this would work the way you think it will, as linuxguru says:

22 hours ago, linuxgurugamer said:

And sometimes, something which seems simple to you is really quite complex, to the point that it's not worth doing.  This , IMHO, is one of those things

That said, there can definitely be improvements made to the maneuver node system.

Porkchop plots would be nice, perhaps a system like some of the online maneuver node planners, pick a set of parameters, pick a point ob the porkchop plot, and then the game can plop down the maneuver nodes for you if you want.

Just spitballing here for alternatives

[HebaruSan]

Thanks for suggesting this, it's been interesting to think about. I see two serious technical challenges (and I would encourage anyone strongly in favor of this idea to try implementing it as a plugin for KSP1; you may make something great, or you may gain a greater appreciation of why some people are skeptical).

First:  Programmatically reasoning backwards to figure out what burn-changes are needed in order to have a given effect. We are all familiar with setting up a maneuver and in order to move the orbit line "downwards" on the screen later on, you have to drag upwards on the handles of your maneuver (same for prograde/retrograde, same for radial in/out). In order to release orbit-dragging as a stock supported feature, the game would have to solve thIs problem in a generic, reliable way. Depending on how far apart your mouse dragging point is from the maneuver and how many gravitating bodies are involved, the relationships here can be arbitrarily complex. We may think that the game already "knows" what will happen in general, but that is only the case in a forwards-reasoning direction, where you change the maneuver and the game shows you what will happen after it. And that's much, much easier than doing the reverse; the current logic basically just has to trace your current orbit's path using simple conic section equations till it hits an SOI boundary, then generate the next conic patch by setting the velocities at the boundary equal, and so on. By contrast, knowing that the user wants an orbit to be 500 km higher at some point does not tell the game anything about where those corresponding SOI boundary transitions occur. You could try holding velocity constant and running time backwards through the patched conic solver, but then there's no guarantee that you'll actually trace a valid path back to your ship.

Second (possibly more important):  Implicit invariants. You as the player make certain assumptions about what is OK and what is not OK to change when you imagine dragging an orbit line, but it's not clear that the computer could necessarily figure out these assumptions, let alone obey them. E.g.: I want to burn before my electric charge runs out; I want to arrive at my destination before my modded life support runs out; I want to intercept my space station but keep enough deltaV to dock; I want to stay in my current orbit but just tweak the Ap/Pe; I want to escape the current body entirely; I don't want to lose this gravity assist; I want to aerobrake or land; I want to stay above the atmosphere; I want it to adjust my current maneuver nodes only; I want it to add and remove maneuver nodes to get to my destination optimally. All the game really knows for sure is that you want the orbit you're dragging to pass through the point (line through the camera?) in space where your mouse cursor is pointing at some future time, but there are infinite ways to make that happen, and all of the other intentions that the player has are not available to the solver. It may be that you grab the line and drag it two pixels and suddenly the solver gives you a completely different trajectory that also just happens to pass through the mouse cursor. Now we need an "undo" option and a "constraints" window, and suddenly our simple UI solution is almost as complex as maneuvers themselves.

Ultimately, even if the above were solved, I think users would still have to deal with maneuver nodes; dragging orbits just isn't a flexible enough input to express all the things you might want to do. If you're zoomed in on a Duna arrival, what kind of orbit-dragging motion could you perform to circularize? How would you indicate that you want to arrive at the mouse cursor earlier or later for a rendezvous?

[OHara]

This would be a very interesting mod to write for KSP-1, or KSP-2.

At first it makes me think of 'Lambert's problem' to find the orbit joining the maneuver node to the desired destination-point (the problem the transfer-window finders solve, including probably HerbaruSan's). But, the interactive dragging might work better with an iterative solver, making a incremental changes on the maneuver node to chase the desired point on the post-maneuver orbit.

I guess we want a three-axis (six-handle) gizmo for the dragged point on the orbit.  At first I thought you wouldn't need to drag along the orbit, but once you start dragging, the orbit changes shape, and the gizmo would rotate enough that we would probably want to slide along the adjusted orbit and then drag again.  

So I am imagining a constrained optimizer, with five free adjustments: prograde, radial, and normal components of the burn, time of the maneuver, and time of arrival.  The dragged 3D point gives three constraints. The remaining two degrees of freedom allow a choice of what to minimize -- delta-V being the obvious choice.  Adjusting the time of the maneuver is usually free, so maybe let that time vary freely.  

I'll boldly guess that two steepest-descent steps will be good enough, for each incremental drag of the destination in the UI.  I'm assuming the routine finds and caches the Jacobian matrix of changes to the destination upon selection of the maneuver node.

We would usually expect that the time when we reach the dragged point changes as we drag the point, so maybe we don't care about the precise time we reach the desired point.  On the other hand, if we are doing a rendez-vous or encountering a planet, we have to get to the point at the same time as our target does.  Having two modes of operation starts to complicate the UI. Maybe constraining the arrival time when you drag along the target orbit, leaving it free when you drag the orbit, would work?  Experimentation would probably give surprises.

[YNM]

On 3/11/2021 at 2:09 AM, KerikBalm said:

Porkchop plots would be nice, perhaps a system like some of the online maneuver node planners, pick a set of parameters, pick a point ob the porkchop plot, and then the game can plop down the maneuver nodes for you if you want.

These already exist from MechJeb but the resulting nodes are a bit of a hit and miss, esp. when selecting the most efficient spot on the plot.

[KerikBalm]

On 3/10/2021 at 3:45 PM, YNM said:

Why changing to a polar orbit is hard, despite the 'speed' barely changes ? It's because it's a vector and not a scalar, and with triangles you get to spend as much as ~1.42 times (√2) your circular orbital velocity magnitude (the scalar value). To give some idea, the circular orbital speed around Kerbin is about 2200 m/s, and that means you need to spend ~3100 m/s to change from an equatorial orbit (0° inclination) to an orbit with 90° inclination - about as much as needed to lift a payload into LKO itself.

You are probably already aware of this, but you can change to a polar orbit much cheaper than that (and much much cheaper with aerobraking) if you don't try to do it all at the same altitude and in 1 burn.

900 m/s to boost apoapsis.

Maybe... 100m/s to change inclination 90 degrees at the target orbit,

900 m/s to lower apoapsis again.

1900 m/s total. If you aerobrake, this can come down to about 1000, m/s. Use Mun for a gravity assist too, and you can get it done in under 900 m/s... it takes a lot longer though

 

[YNM]

1 hour ago, KerikBalm said:

You are probably already aware of this, but you can change to a polar orbit much cheaper than that (and much much cheaper with aerobraking) if you don't try to do it all at the same altitude and in 1 burn.

Well, OP says that he don't want to deal with the maneuver nodes at all, so probably let alone doing it 3 times.

Although I do get the impression that part of the problem is just how imprecise the handles could be, and I've addressed this in my post here as well. Being able to change the values of the dV vector by the numbers is handy regardless of if you're doing it the lazy way or not.