Maneuver nodes rotating for no reason

[michelcolman]

Hi everyone,

I'm just posting here out of frustration that nobody seems to take bug reports about the illogical behavior of maneuver nodes seriously. They get downgraded to "feedback" and low priority, even with the explicit mention that this is unlikely to be changed since it doesn't break the game and users seem to manage just fine.

The problem is as follows:

When you add a perpendicular input (normal or radial) to a maneuver node, the handles rotate to align with the new trajectory. However, their effect is still relative to the old reference frame which creates a very counterintuitive experience. Rotating the maneuver node handles is simply wrong. They don't act in that direction, so why make it seem so?

Is there any vaid reason for prefering this behavior over the much more logical alternative that keeps the node aligned with the original trajectory?

Example scenario:

- User is in an equatorial orbit (let's call it "horizontal") and wants to transition to a polar orbit

- User pulls the "normal" handle (triangle)

- The post-maneuver trajectory rotates around until it approaches vertical

- Meanwhile , the triangle handle rotates and approaches horizontal. It is pointing exactly in the direction where the user wants to pull the trajectory to reach a polar orbit.

- So the user pulls the normal handle some more, but the trajectory does not move in that direction, it just stretches out further upwards

- User visits the forums for help

- Someone points out that he needs to add retrograde

- User is confused, because the retrograde handle is pointing downwards. He tries it anyway, and low and behold, it works, who would have thunk? Must be some weird mathematical reason behind it, orbital mechanics are apparently really complicated and counterintuitive, you probably need a degree in mathematics to figure it out so better just move on to a simpler game.

Now compare this with the correct behavior that nodes should have:

- User is in an equatorial orbit ("horizontal") and wants to transition to a polar orbit

- User pulls the "normal" handle (triangle)

- The post-maneuver trajectory rotates around until it approaches vertical, but the node stays put

- User sees that he needs to twist the trajectory sideways now to get towards the pole. The retrograde handle is pointing in that direction, so he pulls it.

- Great, the node performs the correction exactly as expected. See, orbital mechanics are easy, this is a fun game!

 

So, once again, why would anyone prefer the former behavior? I've really been thinking about this long and hard, and can't find a single reason, not even a small one, for rotating the node. The more I think about it, the more flabbergasting it seems. Why would anyone prefer the current behavior? It makes absolutely no sense.

I know that there are mods to correct this, but that's no reason for stock to be so wrong.

[Superfluous J]

100% agreement. It doesn't affect 90%+ of the nodes (those where you don't normal or radial more than 15 degrees or so) but those it DOES affect can easily get to the point where they're not fixable.

[Kobymaru]

I agree as well. Can you link to the bug report where it got downgraded? Maybe if we raise some voices, we can get this taken seriously.

ps.: I think there's a mod for that. If I recall correctly, PreciseNode had an "intuitive maneuver node mode", which did something to alleviate the lack of logic in the current implementation. I am not 100% sure that it made things a lot better though.

[OddFunction]

Are you guys talking about 1.0.5? Or is this in the 1.1 prerelease as well?

[Superfluous J]

1 minute ago, OddFunction said:

Are you guys talking about 1.0.5? Or is this in the 1.1 prerelease as well?

It happens in 1.1 and has happened in every previous version of the game since Maneuver Nodes were implemented.

[SchweinAero]

This, a thousand times this. In an ideal world, we could also switch between "old-relative" and "new-relative" on the fly. No more guessing just how I must mix retrograde into into this plane change to stay circular.

It'd be fine if the retrograde adjustment didn't in turn affect the magnitude of the desired normal burn, but orbital mechanics says it must. Might as well have the node look the way it acts.

[michelcolman]

It's in the prerelease as well.

The "intuitive maneuver" option in PreciseNode does something different, not sure exactly what, and whether or not it was a good idea, I never tried it. I don't think it changes the behavior of the original nodes. There appears to be a different mod that does fix the issue, though, but I don't know it if still works. 

Bug reports:

There already was a report in the bug tracker for the released KSP:

http://bugs.kerbalspaceprogram.com/issues/3953

And I added a new one for the prerelease:

http://bugs.kerbalspaceprogram.com/issues/7860

[John FX]

I fully support this change/fix.

I can`t count the times I have been trying to switch from an equatorial orbit to a polar one and just gave up and had mechjeb figure out the burn or just entered the right numbers into precisenode.

 

When the user knows exactly what they want to do but they can`t because of the way the game interface is designed then the interface is bad or at best counter intuitive.

It seems there is a fix out linked in one of the bug reports, I have not tested it but here is a link

http://bugs.kerbalspaceprogram.com/attachments/download/5166/IntuitiveManeuvers.zip

[steve_v]

1 hour ago, michelcolman said:

And I added a new one for the prerelease:

Top notch, hopefully it'll get some love.

41 minutes ago, John FX said:

just entered the right numbers into precisenode

S.O.P. here, the stock node editor is...  'meh, mods work better'. Pretty much entirely because of this issue (and I prefer the numbers anyway).

I can't see any logical reason for this behaviour, so it's a little mystifying that it's gone unfixed for so long. Surely this is just a minor UI change, how hard can it be?

Edited April 1, 2016 by steve_v

[John FX]

1 hour ago, steve_v said:

Top notch, hopefully it'll get some love.

S.O.P. here, the stock node editor is...  'meh, mods work better'. Pretty much entirely because of this issue (and I prefer the numbers anyway).

I can't see any logical reason for this behaviour, so it's a little mystifying that it's gone unfixed for so long. Surely this is just a minor UI change, how hard can it be?

In fact I would imagine that it would take extra programming to provide this `feature` to rotate the node so the mere existence of it in the first place is more of a mystery.

It`s continued existence is another mystery unless someone is suffering from `it`s my baby` syndrome inside squad of course. I have found that when dealing with work done by someone else, in film making or coding or pretty much any area, if someone has too much pride in the work they have done then they regard it as their baby and resist any further changes to it because it has become precious to them, to the detriment of the film, code, or other project. That part stagnates and becomes dated or worse, counter productive.

It is good practice to make something and never regard it as good enough or finished so you will be open to good suggestions from others, if you think it is finished/good enough you will resist attempts to make it better. Most film scripts you see that are actually made into films are generally rewritten multiple times, sometimes 20-30 times, until they are deemed good enough to be seriously considered for production.

I used to suffer from exactly this and it was good for my business practice that I watched `the west wing` and in particular the way they wrote scripts for speeches. They would write something that contained the core of the message they wanted to say to act almost as a placeholder then rewrite the same passages over and over until they could not see any area where they could change a word or reorder a sentence and subtly affect the message to improve the script.

They did not see the previous scripts as failures, they saw them simply as a step on the way to a better script. An essential step because you just cant`t leap that far in one go.

Didn`t think I was going to say so much but it`s said now so I`ll post it.

tl;dr just read the first sentence

[steve_v]

In good faith, I'll withhold any judgement on potentially dubious dev practices by squad here... Though "It's my baby" is a common enough thing IME too.

The only other explanation I can come up with is that something deeper in the manoeuvre node code is referencing the projected, rather than the current trajectory (and perhaps shouldn't). Though if that's the case I'm surprised it hasn't caused other weirdness.

[michelcolman]

I wrote in my bug report that it was probably just an adjustment to a single line of code, but they replied it would be a lot more. I'm having trouble imagining this, though. I would asume the code fetches the orientation of the new trajectory and applies that transformation to the node. All that needs to be changed is "fetch the orienation of the old trajectory". How much harder can it be? That's one function call! Maybe the code got duplicated in two or three places due to poor coding style (which I'm frequently guilty of too, so perfectly understandable), maybe its orientation is set when clicking, when dragging, when updating the map view,... but surely that's it? A few identical lines that do the same thing and need the same change?

All the handles do is change the respective component of the node. You can see the values change in the Mechjeb maneuver node editor. I originally thought (based on the weird orientation of the node) that there was some kind of complicated calculation going on with the handles acting relative to the new trajectory (something like transformation matrices that either have the old coordinates of the new base vectors or the new coordinates of the old vectors) but no, each handle just modifies the delta-v in that direction, relative to the original trajectory. Nothing more complicated than that. So all that needs to change is the display orientation of the node so the handles match what they actually do.

[monstah]

I think this has already been brought up before. I agreed then, and agree again

[steve_v]

16 hours ago, michelcolman said:

I wrote in my bug report that it was probably just an adjustment to a single line of code, but they replied it would be a lot more. I'm having trouble imagining this, though.

Yeah, I'm a bit stumped as to where the difficulty lies too. Obviously I don't have access to the source, so it's impossible to say for sure - but this looks like it would be pretty trivial to fix.

[HenryBlatbugIII]

4 hours ago, steve_v said:

Yeah, I'm a bit stumped as to where the difficulty lies too. Obviously I don't have access to the source, so it's impossible to say for sure - but this looks like it would be pretty trivial to fix.

Well, technically, we all have access to the source.  C# is very easy to decompile (http://ilspy.net/),

<Removed by the moderation team>

Edit: Sorry, I didn't realize it wasn't allowed.  My point was: you're correct, it's a single-line change.  Therefore, I assume Squad thinks it's better to leave it the way it is, but I wish we could at least change a configuration option to make it more sensible.

Edited April 2, 2016 by HenryBlatbugIII
Oops, apparently that was against the rules.

[Red Iron Crown]

3 hours ago, HenryBlatbugIII said:

Well, technically, we all have access to the source.  C# is very easy to decompile (http://ilspy.net/),

<Removed by the moderation team>

Easy or not, it's a violation of the EULA/TOS to decompile the game, please do not share such things here.

[Superfluous J]

There was a mod posted in the bug report page (of all places) that purported to "fix" this. I tested it back then and for the fun of it tested it now, and it didn't work either time.

As a non-modder myself I by no means will speak to how easy it'd be, but is anybody involved in this discussion capable of modding this into the game?