New Maneuver Node Editing Tool

[Alshain]

The current tool is very difficult to use when planning interplanetary transfers. What I propose is something that looks exactly like what we have now, but instead of being anchored to the orbit, it should be a free floating tool like the navball.

You would create a maneuver node exactly like you do now. Choose a place in the orbit, click it, choose create node. Once it is created, things change a lot. An icon showing the node position is placed on the orbit and a tool appears on screen near the navball allowing you to modify the orbit. But that tool stays on screen regardless of where your camera is focused (it also keeps the same orientation and size, so you never grab the wrong marker). All the current node editing controls apply, but some new ones will need to be added. The center grip will move the maneuver along the orbit (the same as dragging the tool does in the current KSP) and you will need a way to choose which node to edit for multiple nodes. So if you create a node around Kerbin, and then focus on Duna to fine tune the burn, you can still see the tool.

EDIT:

Ideas stemming from discussion in this thread

• The +Orbit and -Orbit buttons were left out of the mock up by mistake, they should be there somewhere. [Alshain]
• The tool could rotate based on velocity vector so Prograde is always facing prograde. However, it should not rotate with map movement alone. So it would take a burn for it to change orientation. This would allow it to feel correct in 'reverse' equatorial or polar orbits. Caution should be taken to ensure the controls never overlap like they do in the current implementation. [regex]
• The active maneuver should be highlighted or easily distinguishable. [Red Iron Crown] The active vessel icon and target vessel icon should be distinguishable as well (not white like everything else) [Alshain]
• There should be some way to tell what direction an orbit is from the orbit lines [kujuman] - Implemented in 1.1
• The fine controls need fixing. Mouse wheel acceleration is a problem in the current implementation. Possibly the mod key could be used for ultra-fine movements. [stoney3K]
• Apparently a similar idea was proposed by funk in May. Some additional ideas may be found in that thread.
• Clicking the node name should return focus to the node's position. [Temeter] (Changing the active node should NOT reset focus to that node [Alshain])
• Suggested Keyboard controls for editing the maneuver (see post) [wreckreation]

END EDIT

This is very hard to explain in text, so I have made a very crude mock up (ignore the other mods of course). If anyone with better image editing skills likes the idea and would like to make a better mock up, please be my guest.

Edited April 22, 2016 by Alshain

[Red Iron Crown]

That looks fairly brilliant. One of the main reasons I use PreciseNode is the ability to edit a node when it is not visible (hugely convenient for refining interplanetary encounters), this solves that issue neatly.

I guess it would need some way to show which node is active when more than one has been placed, but that's a minor detail.

[TyrannoFan]

Brilliant idea - this would make editing nodes while focused on other places far less finicky, and it would look neat too.

[Alshain]

I guess it would need some way to show which node is active when more than one has been placed, but that's a minor detail.

You seem to have missed the node selector at the bottom. Thanks for the support!

[Tex_NL]

You've got my vote on this one. The current manoeuvre node is one of those things that really needs to be improved. This would be an ideal solution.

[Gaarst]

I think this solution lacks a way to be really precise on your manoeurves, but still way better than stock !

Anyway, I 100% support any rework on the manoeuvre node system.

[Tex_NL]

I think this solution lacks a way to be really precise on your manoeurves, ...

Not if it works to augment the current system instead of replacing it. It should still be possible to edit the node just like we do right now.

[Alshain]

Well the idea was to have all the same controls so precision would not be any worse than it is in stock now. You still grab and drag the prograde out to quickly add prograde, drag it in to slowly move retrograde, roll the mouse wheel to go even slower. It would be identical to stock, except not ON the orbit lines.

Yes, Precise Node gives you more control but if we were going to get that in stock it would have happened by now. The idea is to not go so far that Squad simply says "no", because the goal is not to add precision controls, but to make the controls easier to access.

Edited September 21, 2015 by Alshain

[Red Iron Crown]

You seem to have missed the node selector at the bottom. Thanks for the support!

*facepalm* I totally missed that.

Edit to add: Er, still not exactly what I meant. the actively edited node should be highlighted somehow so it stands out from any others. Still a minor detail.

Edited September 21, 2015 by Red Iron Crown

[kujuman]

I think this is a really good idea to at least try out. I think the one addition I'd want is some visual indicator on the orbit of which direction the different node handles are pointing (since the moved node gizmo would be fixed in rotation it seems). Maybe when you hover over a handle on the gizmo, a line or set of lines are drawn on the location of the node indicating the current direction (this would be more useful for changing inclination/radial in/out burns than simple prograde/retrograde maneuvers. The seperate node selection could also give us dVs for each node in real time as we're dragging (actually that'd make a cool app--a simple list of node # and dV, and then a total sum. For extra coolness, maybe nodes could also have a user naming function ("Duna capture" instead of "node 3")

[Wjolcz]

That's an amazing idea. I support it.

[magico13]

This seems like a good Stock-alike solution to the problem. PreciseNode level of detail is "too many numbers" for the Stock game, but this would be a great compromise. I'd still install PreciseNode on top of this though, because I like the numbers. Being able to modify a node while focusing on my intercept with another planet would be a great addition to the Stock game.

[pandaman]

This I like. Good idea, will improve using nodes a lot.

[Alshain]

*facepalm* I totally missed that.

Edit to add: Er, still not exactly what I meant. the actively edited node should be highlighted somehow so it stands out from any others. Still a minor detail.

Ah, yes that would be a good idea. I also realized I forgot to add +Orbit and -Orbit buttons, but the base idea is there.

[TMS]

Nice idea. It would certainly help with the absurd game one has to play with nodes as you scroll out and in. I think the detached controls would also have to rotate concurrently as you rotate the map to retain one's frame of reference.

But it doesn't get away from the core problems of the stock interface. Specifically, the lack of precision in anything and the fiddly nature of adjusting the placement or vectors. Fine tuning an ejection angle involves time, as well as vectors. Until that is tackled, I think we're replacing bad with less bad.

I'd really rather they gave an "advanced" option where numerical and scaled button input was available (a la precise node), but hiding it as default.

[Stoney3K]

Nice idea. It would certainly help with the absurd game one has to play with nodes as you scroll out and in. I think the detached controls would also have to rotate concurrently as you rotate the map to retain one's frame of reference.

I'm not sure about the rotating part. That would cause the editing gizmo to rotate and obscure controls when you're in a certain camera viewpoint. I've had quite a few occasions where I accidentally grabbed the wrong direction handle because the one I wanted to grab was too close in the camera viewpoint I was using.

Also, the node editor could make good use of the modifier key, MOD + mouse wheel would be a good way to enable very precise node editing.

[monstah]

Sounds awesome. I support it, too.

[regex]

If the scroll wheel didn't accelerate during fine adjustment, or only did so without certain key combinations, that would serve for fine control just great. The node tool is fantastic, it just needs to be refined. I don't even use Precise Node (or any other node editor) anymore, even when playing with RSS.

I support this idea as well, so long as the node tool stays oriented to its velocity vector.

[CaptainTurbomuffin]

I was about to suggest something similar. What I would suggest was an advanced manouver, available after tracking station upgrades. With this node, you could get to your target with a 100% accuracy. It would fix the 3 problems of the current manouver, that cause inaccuracy.

The manouver is linear. The current manouver is a point, while your burn is a linear event. The current manouver could only be completed 100% accurately, if you could perform your burn under 0 seconds (immadiately). Using the current manouver system, if you start earlier, and finish earlier, with the center of the burn in the node, the center of your burn will eventually move away, because you started accelerating before it. You end up getting shifted. This can be avoided, if the manouver is not a point, but a section with continous burn.

The current manouver correcting itself if you burn the wrong direction, is brilliant, but you'll have a longer burn that way, and you'll end up getting even more shifted. The current correction system makes you exactly accelerate the planned DV towards the planned direction, NOT to the planned trajectory. If you complete the manouver exactly, it won't lead you to the planned trajectory, while you want that. So, the advanced manouver would correct itself, so that you'll get to the planned trajectory, instead of completing the planned burn.

The current manouver calculates your burn time incorrectly. For me, it won't even show a value. Maybe because of flying with lowered thrust, but it should count with full thrust burn, and it should count with staging too. But anyway, if the second part is true, this would not make a difference.

And finally, transfers could be made easier. Maybe being able to display your future velocity in certain selected points. And by knowing the orbital velocity at certain altitudes.

[Alshain]

Great comments, I've paraphrased some of them and added them to the original post (in no particular order).

[nikokespprfan]

To solve the precision system, i came with the following idea:

Now pulling on the nodes will always add x m/s deltaV per pixel of vector-tugging per second of having pulled on said vector. This value (x) is -as far as I know- the same.

What if (after tracking station upgrades of course) you can manipulate this value, so that if you pull a vector out a pixel for a second, that you will get 0.1 times the addition of deltaV than what you normally would. or 0.01x or 10x and so forth. You would only need two more buttons on the interface.

[Alshain]

To solve the precision system, i came with the following idea:

Now pulling on the nodes will always add x m/s deltaV per pixel of vector-tugging per second of having pulled on said vector. This value (x) is -as far as I know- the same.

What if (after tracking station upgrades of course) you can manipulate this value, so that if you pull a vector out a pixel for a second, that you will get 0.1 times the addition of deltaV than what you normally would. or 0.01x or 10x and so forth. You would only need two more buttons on the interface.

That is all fine but you are getting into the PreciseNode area and that is beyond the scope of this request. I want to keep it simple because if it gets too complex Squad seems to shy away from it. Feel free to make your own request thread though, such a thing could be added whether this idea is implemented or not.

[Gaarst]

Thinking about it, the problem is not so much the nodes placement but the burn itself.

The burn times indicated by KSP assume you have constant mass and do not stage... and that's when it indicates any time at all. Also it calculated this burn time according to your last burn, which is completely stupid. Including the variation of acceleration and mass, and staging in a way that you can predict when/where to burn is not hard, KER shows that it is perfectly possible.

Adding this only would be a huge improvement compared to the current system. Because, if you can put a precise node, but can't get it without burning too much, or just loose it because you ended up burning too soon, is/will be extremely frustrating when going far away such as Eeloo (and let's not talk about the "flickering" patched conics when going there).

[Wjolcz]

How about an 'undo' function? Bascially what Paint/Gimp/other graphics programs have except it undoes the last input you gave the node. I screwed up way too many manouvers and had to recreate and fine-tune them from the scratch.

Though I guess it wouldn't be an issue if the mouse scrollwheel precision got fixed.

[regex]

Though I guess it wouldn't be an issue if the mouse scrollwheel precision got fixed.

That is the most glaring issue with the current widget, IMO. I could even accept placement on the orbit without the OP suggestion if the mousewheel issues are addressed as a "perfect" system.