Improved Maneuvers & Planetary encounters

[cwood]

Currently the scheme for maneuvers works well for bodies that are close-by (like moons), but it's a real headache to get to or from distant planetary bodies because of the scale and zoom involved. There is no numerical control over angles, or any assistance for finding - or even applying - optimum trajectories (e.g. http://ksp.olex.biz/) can be easily used.

I can't help but think that the scheme for doing all of this would benefit enormously from a conceptual overhaul. At a minimum, the ability to see an overview of the solar system WHILE editing maneuvers would help. Zooming in-and-out constantly to, say, change the location of the maneuver along an orbit is difficult and just plain bad UI compared to what is possible.

Suggestion: a "picture-inside-picture" view zoomed in on the encounter when one appears would help enormously with a minimum of changes, while eliminating the need to zoom in and out so much. This would be an interim fix, but a lot more could be done to improve the "big picture" view of interplanetary travel. I propose starting a discussion about ways to accomplish better controls for interplanetary-scale transfers and ease of accomplishing maneuvers with more precision.

This forum is brimming with stuff, so sadly I'm afraid this may be drowned out quickly, but I wasn't able to find another thread referencing this issue, and I feel that it's in serious need of improvement.

Edited May 31, 2015 by cwood

[Wjolcz]

That is actually a really good idea. I like it!

[JacaByte]

I would kill for this. It would also help when setting up circularization burns, insertion burns or rendezvous. A PiP view of the periapsis, apoapsis, ascending node and descending node with a numerical readout would make all of these maneuvers much easier. I wouldn't need one hand to keep the mouse on the node, another hand for pitch and roll on my joystick and another for yaw and throttle.

[cwood]

Yes - numerical readouts (or easier access to them, with a schematic) would be really big benefit. I'm not sure how they came to the present scheme, but at a minimum it needs some tweaking if not a complete overhaul.

What's the chance they'll actually read this and prioritize it among a zillion other suggestions?

[Red Iron Crown]

Another way to approach it (heh) is to show the node interface away from the node itself. That way you could focus on the target body and fine tune the node for a better approach.

An idea for visualizing transfer windows I've been kicking around in my head is, after setting a target, use coloration on the orbits to show when a good time to transfer is.

[KSK]

I like this idea, although I think I prefer cwood's version to Red Iron Crown's because it seems more generally applicable. Another possible answer (and feel free to forum-slap me if this is already a thing) would simply be to add keyboard controls for the maneuver nodes for opening them, sliding them along their orbit and adjusting their control handles. That way you can drop your node, focus view on your target and use the keyboard for fine tuning.

Not quite as elegant but perhaps a little easier to implement?

[hellion13]

They have numerical readouts in the form of kerbal engineer, mechjeb(dont have to use the auto pilot), flight indicator, among a few others and precise node along with mechjeb amd probably more can help with controlling encounters. Not exactly core gameplay, but they are mostly just GUI mods and dont take up a huge amount of memory(unlike most of the part mods).

I find that engineer and mechjeb(I bounce between the two depending) are AMAZING for craft readouts and flight information. Mechjeb(if you're lazy) will even perform the manoeuvres pretty much dead on +/-100m(outside of the launch autopilot)

[pincushionman]

PIP would be great - but I'd suggest TWO extra windows, one to show your node, one to show the targeted body at the appropriate time (encounter, perispsis, escape, pickable by radio button), and the main window for the entire trajectory. Windows could be dragged and zoomed independently, but the orientations would be constant.

[amorymeltzer]

FWIW, I pretty regularly tab over to the body in question once I get an encounter. It's really quite easy to change your incoming there, not a major issue. And in the meantime, look no further than blizzy's excellent Precise Node.

[nholzric]

Currently the scheme for maneuvers works well for bodies that are close-by (like moons), but it's a real headache to get to or from distant planetary bodies because of the scale and zoom involved. There is no numerical control over angles, or any assistance for finding - or even applying - optimum trajectories (e.g. http://ksp.olex.biz/) can be easily used.

I have a thread at the following link concerning how to let the player discover or explore interplanetary trajectories. Basically, there would be maneuver node like objects, I called them "transfer nodes" that, instead of being placed on a ship's trajectory, would be placed on the trajectory of the body the ship was orbiting. If I was orbiting Kerbin, I would zoom out and click on Kerbal's orbit to place a transfer node. Just like a normal maneuver node, I would adjust the three elements of a potential maneuver while monitoring the dV requirement. I could slide the transfer node around Kerbin's orbit allowing to me discover transfer windows up to one revolution later (a whole year for Kerbin) or more if there's a "next rev" button.

http://forum.kerbalspaceprogram.com/threads/108944-Transfer-Nodes

This doesn't address the zoom problem or how unwieldy maneuver nodes can be. I think your inset view is a good idea, or at least starting down the right track! Thanks for sharing!

An idea for visualizing transfer windows I've been kicking around in my head is, after setting a target, use coloration on the orbits to show when a good time to transfer is.

Brilliant! The one thing the transfer node idea has going for it is the "self discovery" aspect - the player can fiddle with the transfer nodes until he "discovers" a transfer window or at least an inexpensive enough transfer. The transfer node idea has a few problems though, for example I'm not sure if it is possible or how the dV cost of the transfer node would be related back to a ship; ultimately the player wants a maneuver specific to a ship and its current orbit, I don't know if it's possible to make that translation from transfer node to maneuver node in a useful way. Your coloration idea sidesteps this translation issue and sounds very intuitive for the player.