Draggable Patched Conics

[MechBFP]

5 hours ago, YNM said:

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

No it doesn’t. 

[Bej Kerman]

On 3/9/2021 at 2:05 PM, Kernel Kraken said:

On 3/9/2021 at 11:47 AM, 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.

It's literal rocket science, don't feel bad if you don't manage to get the correct trajectory first time.

[mattinoz]

On 3/11/2021 at 7:33 AM, HebaruSan said:

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.

So if it’s hard for a computer to reason even thou it can run what 100s of simulations in a second then how is the player ever to learn?

but the computer can run simulations faster than we can guess at it.
 

So thinking mod design could I create fake paths with dV modified a known amount on one axis. Do that say 2 times per axis and should be able generate a line showing effect of each axis at that point. expanding from there it’s how many points can I quickly generate a shield of possibilities they could snap on .  
 

Yes not a magic answer just writing post still but still think better tools to help players get their head around the logic of orbital mechanics is possible.  

[HebaruSan]

3 hours ago, mattinoz said:

So if it’s hard for a computer to reason even thou it can run what 100s of simulations in a second then how is the player ever to learn?

but the computer can run simulations faster than we can guess at it.

Would running a lot of simulations help somehow with the two challenges I pointed out? Hmm, I'm not seeing it.

[SOXBLOX]

On 3/12/2021 at 7:22 PM, mattinoz said:

but the computer can run simulations faster than we can guess at it.

But you can learn and iterate. I'm willing to bet your PC isn't running a strong AI.

[mattinoz]

6 hours ago, SOXBLOX said:

But you can learn and iterate. I'm willing to bet your PC isn't running a strong AI.

The AI in my computer is a bit of a CAD

the point is I can learn faster with a visual that confirms or confronts my mental model. 

Edited March 14, 2021 by mattinoz

[K^2]

On 3/12/2021 at 9:01 PM, HebaruSan said:

Would running a lot of simulations help somehow with the two challenges I pointed out? Hmm, I'm not seeing it.

It's literally how optimization solvers work.

Just to be clear, is the argument seriously, "This would be bad, because it's very hard to program?" Because that's not the case. Yeah, you can end up with another object getting in the way, and the actual trajectory not being the one you want, but that's going to be the case with any sort of planning. So long as you are getting correct maneuvers otherwise, you can simply drag the point around until you get a solution that works and gives you good fuel usage.

Planning a transfer from LKO to Minmus isn't a challenge, it's a chore. Sure, it might make sense to have to do it once or twice to get the idea of how it works with maneuver nodes, but being able to simply drag out the trajectory thereafter is a great idea. And there is no significant technical challenge in it.