New Maneuver Node Editing Tool

[Alshain]

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.

I disagree, that would be the second biggest issue. The biggest issue is at a distance, it is very difficult to grab the right node on the gizmo. It is incredibly irritating to try and grab the prograde and end up grabbing radial. Fine controls aren't perfect but fine controls are irrelevant if you can't get the right control in the first place.

[Wiseman]

I disagree, that would be the second biggest issue. The biggest issue is at a distance, it is very difficult to grab the right node on the gizmo. It is incredibly irritating to try and grab the prograde and end up grabbing radial. Fine controls aren't perfect but fine controls are irrelevant if you can't get the right control in the first place.

Agree one hundred percent, that's my biggest issue as well. I'm constantly having to switch focus targets and move around just to fine-tune my maneuver, and doing goofy things like trying to angle my camera just right so that I can see if I have an encounter on the far side of the Sun, when my camera is on a ship in orbit around Kerbin. Love this suggestion, very well thought out.

[Bev7787]

I would like the ability that PreciseNode and MechJeb have, with maneuver nodes having the ability to be adjusted with a button, rather than by click and drag.

[LitaAlto]

I like Alshain's suggestion, a lot. Even when using MechJeb I find myself manually adjusting nodes all the time, and having a control off to the side would be a wonderful improvement.

[JAFO]

Great idea.. and long overdue. I'd love to see this implemented.

I totally agree with, and would love to see Gaarst's suggestion implemented, too.

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.

[eddiew]

Yes please, node editing is painful and these suggestions sound good.

I'm constantly adjusting the wrong thing, or accidentally mouse-wheeling while hovering, or trying to click next orbit and instead deleting it - or worst of all, switching ship because there's one currently under the parking orbit I'm putting the node on x(

[pellinor]

I'd like to raise the question what coordinate system the maneuver node gizmo should use (see this post in another thread).

Short version, I'd suggest to use the coordinate system of the target orbit (instead of the current one before the node). For example pulling the normal+ handle would incrementally add dV in the new normal+ direction (which changes in the process), effectively changing the inclination of the target orbit without affecting anything else. Likewise, prograde would raise the velocity after the maneuver without changing the direction.

Edited October 3, 2015 by pellinor

[Alshain]

I'd like to raise the question what coordinate system the maneuver node gizmo should use (see this post in another thread).

Short version, I'd suggest to use the coordinate system of the target orbit (instead of the current one before the node). For example pulling the normal+ handle would incrementally add dV in the new normal+ direction (which changes in the process), effectively changing the inclination of the target orbit without affecting anything else. Likewise, prograde would raise the velocity after the maneuver without changing the direction.

No, sorry. That would be confusing, probably would be inaccurate and impossible, and also directly conflicts with this idea. The controls shouldn't change in position or behavior on any given node without a burn. If you want a maneuver after the current one, create a second node after.

[Luis]

This is an incredibly good idea and, if implemented in stock, might just be enough to allow all but the most hardcore players to manage without Precise Node.

At this point I think the best way to get it made stock would be for someone to create it as a mod, to demonstrate its usefulness and popularity. Then Squad might bring the modder into the fold, to make it stock. I have my fingers firmly crossed that this happens.

[mattinoz]

Yes please, node editing is painful and these suggestions sound good.

I'm constantly adjusting the wrong thing, or accidentally mouse-wheeling while hovering, or trying to click next orbit and instead deleting it - or worst of all, switching ship because there's one currently under the parking orbit I'm putting the node on x(

I find the mouse wheel control of the nodes to be bad UI at the best of times.

I mean in all other software I use and including in KSP (when not over the node) mouse wheel is the zoom control. So much so that it is the ingrained and you don't think about zooming you just it just do it, then realise your node is now so far out of wack that you sometimes have to delete it and start again. Especially if you moved the mouse slightly and ended up changing normal instead of prograde.

Still it would be better to have the node control off the path to start with.

Add say a modifier key to change mouse from zoom to adjust and I'm fully sold.

[DancZer]

Alshain for president! Excellent idea!

[meyerweb]

I loved this idea when funk proposed it, and I love it still. +100 to making it happen (I wish I could help!).

[Alshain]

I loved this idea when funk proposed it, and I love it still. +100 to making it happen (I wish I could help!).

Interesting, I had no idea it had been proposed already. Slight differences but close enough. You know they say great minds think alike

[elitebuster]

This seems like a very, very good idea. Faffing about with nodes and cameras are what made me give up, and simply rely on mechJeb for my burns. If the node UI was implemented like this, I'm sure my patience would've lasted longer.

[Rath]

Yes please

[meyerweb]

Alshain said:

Interesting, I had no idea it had been proposed already. Slight differences but close enough. You know they say great minds think alike

Heh. I think you’ve captured some great ideas here that didn’t come up in the earlier proposal, and your UI has some enhancements that are much better, in my opinion. I hope this gets enough traction that someone takes it on! It would make adjusting course-correction nodes much simpler when trying for close encounters with moons (and planets).

Edited December 12, 2015 by meyerweb
Cleaned up forum migration errors (Unicode and hyperlinking were both botched—sigh)

[zolotiyeruki]

Yes please, node editing is painful and these suggestions sound good.

I'm constantly adjusting the wrong thing, or accidentally mouse-wheeling while hovering, or trying to click next orbit and instead deleting it - or worst of all, switching ship because there's one currently under the parking orbit I'm putting the node on x(

This, a thousand times this.

[Snipe86K]

I'll be honest I love the idea! I would love for this to be my first mod, but I think it is a bit out of my league!

[monstah]

I just noticed some bad behaviour on the stock gizmo's part which I believe has been unnoticed so far:

When you hit normal or radial, it rotates so it's in the same frame of reference as the post-maneuver orbit. However, your input is still in the pre-maneuver frame of reference!

It's quite noticeable, for example, if you plan a 90-degree turn right, and then start adding prograde. Given the gizmo position, you'd expect to go further along the 90 degree trajectory, but instead the angle decreases and it goes further along it's original trajectory.

Very wrong behaviour, IMO, and very easily fixable just by having the gizmo fixed in the original orbit's frame of reference.

That's not actually what happens, my memory is screwing me. There is something strange related to that when you try to negate all your velocity, however (like planning a landing), and the prog/retro switch around. That's probably what I was thinking of when I... brainfarted.

Edited October 22, 2015 by monstah

[TheXRuler]

All of you have brought together some amazing ideas here, I wholeheartedly support this. The current node editing is just about fine for kerbins SOI including mun and minmus, but going any farther is a gian pain in the ***. I almost never use the stock system anymore since it's just to much fiddling and wasting time for my taste. I get that squad doesen't want a huge wall of numbers, that would just make the game even harder for new players. However I find that after almost 1000h ingame the stock tool is just lacking in so many ways. Personally I like my numbers and decimals, as provided by precise node, but I also quite like and enjoy the usability and ease of access that the ccurrent system provides. It's just that it becomes almost useless for really far targets.

[Pthigrivi]

Finally got around to reading this whole thread and eff yes. Killer idea Alshain (et al.) This would be a huge help.

[Temeter]

This would be so utterly amazing to have

squad pls implement k thx bai

edit: As for a bit of input, I'd like to able to klick on the nodes name ('node 1' in mockup) to instantly focus on it. Less scrolling around on the map screen would be nice.

Edited November 15, 2015 by Temeter

[Destroyer713]

I'd honestly love to see something like this in stock.

As it is right now, it's a pain to adjust the periapsis and orbit of an encounter for anything farther than a Kerbin to Mun transfer. You can either focus on where the node is and not be able to see the encounter orbit, or you can focus on the body you'll encounter and become unable to properly adjust the maneuver node.

So yeah, +1 to this idea from me.

[bbz]

+1 Support, maneuver nodes editing really need fixing

[m4ti140]

In my opinion the tool should rotate with the map, it would make it more intuitive as you would add delta v by moving the marker in the direction you want to burn into on the map.