Am I the only one who dislikes the auto-switching to Target mode on the navball?

[razark]

What's pissing me off is the constant claim that it's player incompetence when the error was not made by the player.

Call it what it is. If a pilot flies its airplane into the ground because it misread the instruments, it's called "pilot error", not "instrument error". It is your responsibility as the operator to know what your instruments are telling you, not to blindly follow them. If you want the machine to tell you what to do, why not just use an autopilot in the first place?

And I for one quite frequently do my close maneuvers (down to 1 km or less) on the orbital map, using the navball in target mode.

Edit:

If you're driving your car in reverse and look at your speedometer, do you assume the car is moving forward just because the meter isn't reading a negative number?

[Psycix]

Perhaps Orbit, Surface and Target should have different colors to accentuate the current mode.

[leax256]

The velocity value doesn't cause your burn to be in the incorrect direction. Target mode vs Orbit mode does.

no but you are looking at the nav ball so a difference of about 2 KM/s in velosity is highly noticable.

[Scoundrel]

I'll put myself out there and state that I agree with the OP.

Perhaps Orbit, Surface and Target should have different colors to accentuate the current mode.

I've only occasionally had it switch modes on me when I wished it hadn't, and short of the ability to padlock the mode, I think Psycix's suggestion is an acceptable alternative. I personally understand Steven Mading's frustration, and regardless if one wants to call it pilot error or not, IMHO instruments shouldn't be flipping between modes without pilot input. Yes, I do agree that if one maintains alertness and awareness of instrument settings it isn't hard to deal with the issue or even anticipate it; my opinion though is that I should have the option to disable that auto-switching so if I do smash into something because I forgot to switch modes, then it's 100% my own fault, and not because my focus was elsewhere and became disorientated thanks to KSP doing switching for me without it being immediately obvious that my instruments have changed modes.

That all said, I don't think the devs should drop everything this instant to fix it - I would settle for a plugin in the interim until they revisit the UI and refine it more... which, as I understand it, they eventually will.

[allmappedout]

snip

You seem to have a major problem with this issue, but notice how I said it 'switched' to target mode around 100km out. That doesn't mean that is your closest approach. My closest would be a few km or so. But it switches to target mode in anticipation. I would not expect to be within 100km of a target and not on a closer approach unless something had gone wrong.

The fact is that you know about it, it's clearly not as issue to most players as determined by this thread, and you're being very combative over an issue which to the best of my knowledge has been designed for the purposes it's used for. As another poster said, the instruments are there as a guide to follow, but if you don't know what it is they are telling you (which is the case here, because they have changed what they are telling you, in an obvious manner - there is a change in the marker and the velocity, which you should be looking at whenever you are doing a maneuveur) then you need to reconsider using them and work from first principles.

Also, 100km is very, very close in astronomical scales, and even within an orbit, being 100km away isn't that far. Since the planet's equator is about 3,769km long, you're only just over 2.5% away in your orbit.

Being on the map view is a great indicator that you ARE ready to dock because you're looking at closest approach.

TL;DR End of my discussion is thus: Instruments tell you what they need to, you're not reading them right.

Edit:

If you're driving your car in reverse and look at your speedometer, do you assume the car is moving forward just because the meter isn't reading a negative number?

Also, this. velocity is a vector, your orbit readout is a speed. the navball changes context to help you do what you need to do in 3D. Please, just let it drop, OP, it's really not that big of a deal and is a bandage for something that doesn't need a bandage.

Edited August 22, 2013 by allmappedout

[Dunbaratu]

Call it what it is. If a pilot flies its airplane into the ground because it misread the instruments, it's called "pilot error", not "instrument error". It is your responsibility as the operator to know what your instruments are telling you, not to blindly follow them.

And it's the manufactuer's job to make instruments that don't alter what the pilot told them to do.

If you want the machine to tell you what to do, why not just use an autopilot in the first place?

Wow, that gets it 100% backward. My complaint has been from the very start of the thread that the machine is NOT doing what I tell it to when it switches the navball's mode without my say-so, based on its incorrect guesswork. It's trying to guess what I wanted, and it's guessing incorrectly. So yes "call it what it is", which is machinery trying to second-guess the pilot, and guessing incorrectly.

And I for one quite frequently do my close maneuvers (down to 1 km or less) on the orbital map, using the navball in target mode.

Doesn't change the problem.

Edit:

If you're driving your car in reverse and look at your speedometer, do you assume the car is moving forward just because the meter isn't reading a negative number?

The analogy fails because cars NEVER switch into reverse without the driver telling them to.

[Dunbaratu]

no but you are looking at the nav ball so a difference of about 2 KM/s in velosity is highly noticable.

Incorrect. I am not looking at the navball when the switch happens. The switch happens during time warping since it happens way too far away from the target while I'm still on map-based approach.

[Dunbaratu]

my opinion though is that I should have the option to disable that auto-switching so if I do smash into something because I forgot to switch modes, then it's 100% my own fault, and not because my focus was elsewhere and became disorientated thanks to KSP doing switching for me without it being immediately obvious that my instruments have changed modes.

Exactly. People in this thread keep choosing to pretend I'm asking for less pilot responsibility when it's pretty obvious that what I'm asking for is just the opposite. Any crashes incurred become MORE my own responsibility if the crash occurred while the computer did exactly what I told it to and didn't try to out-guess me by altering my inputs. I find it ironic (and infuriating, and trollish, and dishonest) that the people are trying to make the argument that if a person is asking for less automation that this is somehow because they want less responsibility of piloting. I can't even begin to fathom the logical inversion of that argument.

Arguing that the automation is better? Okay fine. Arguing that it's more helpful than unhelpful? Okay fine. But arguing that the inability to override an automated feature somehow makes the pilot MORE responsible??? That's just utterly backward.

[Sean Mirrsen]

Exactly. People in this thread keep choosing to pretend I'm asking for less pilot responsibility when it's pretty obvious that what I'm asking for is just the opposite. Any crashes incurred become MORE my own responsibility if the crash occurred while the computer did exactly what I told it to and didn't try to out-guess me by altering my inputs. I find it ironic (and infuriating, and trollish, and dishonest) that the people are trying to make the argument that if a person is asking for less automation that this is somehow because they want less responsibility of piloting. I can't even begin to fathom the logical inversion of that argument.

Arguing that the automation is better? Okay fine. Arguing that it's more helpful than unhelpful? Okay fine. But arguing that the inability to override an automated feature somehow makes the pilot MORE responsible??? That's just utterly backward.

I'm still not seeing a problem anywhere. All you're caught up on is the navball switching to a different frame of reference when you don't tell it to, instead wishing you could manually switch modes without the computer interfering.

I don't know what kind of mind it takes to think like that, but the computer is simply there to switch modes so you don't have to, because, all situations taken into account, you have to do less switching with the computer, than you have to do without.

If you're capable of directing your attention and switching frames of reference manually, then you are just as capable of paying attention and switching frames of reference manually. It's called a "piloting error" when an automated system performs everything as designed, and the pilot misinterprets its output or fails to act appropriately. It's only an "instrument error" when the automation fails, causing the pilot to act on incorrect data. You seem to be putting yourself on the latter type, when it really is the former - you are perfectly aware of how the navigation computer works, and you are perfectly capable of correcting its output, as the computer gives you all information necessary to act. Failing to act is pilot error.

If you want to continue the car analogy, this is your GPS suddenly telling you to "turn right" onto a gravel road because there's a major jam ahead, and you ignoring that because "this can't possibly be the right way" - assuming an error when the computer is correct, and not paying attention to surroundings. The difference is the the nav-computer doesn't tell you to re-plot your course.

(or, I guess, the GPS telling you to go straight and you choosing to try the gravel road is a closer approximation - because there's a major vector difference between target and orbit modes... eh, it wasn't all that good of simile either way )

[razark]

And it's the manufactuer's job to make instruments that don't alter what the pilot told them to do.

The instrument does the same thing, the same way, every time. If you are surprised by this, then you need to learn to use the instrument.

Wow, that gets it 100% backward.

You were the one talking about pointing at a marker and burning without understanding what you were pointing at.

My complaint has been from the very start of the thread that the machine is NOT doing what I tell it to when it switches the navball's mode without my say-so, based on its incorrect guesswork. It's trying to guess what I wanted, and it's guessing incorrectly. So yes "call it what it is", which is machinery trying to second-guess the pilot, and guessing incorrectly.

When an instrument operates a certain way, and does so consistently, not checking the clearly marked mode indicator before you begin using the instrument is not your best option.

Doesn't change the problem.

Didn't say it did change the "problem". It was in response to your comments of "I can't see ANY circumstances in which someone would use target mode on the navball from the map view..." and "Shouldn't the fact that I'm on the map view be a good enough clue to the game that I'm not trying to dock yet?" and "...but if I stay on the map screen that's a pretty good indication I'm still operating orbitally."

The analogy fails because cars NEVER switch into reverse without the driver telling them to.

If cars were KNOWN to switch, and KNOWN to do it under certain conditions, and you KNOW there is a possibility that you are subject to those conditions, and yet you fail to check the very clearly marked indicator before flooring the gas pedal, it's not an instrument problem.

You'd have a point if the mode indicator were located on a different part of the screen, or if it wasn't shown, or if it only showed up in IVA. But it's clearly printed right above the navball, where you really can't help but see it if you bother to look at the numbers. I don't know how you can fail to know what mode you're in unless you are purposely refusing to look at it.

Edited August 26, 2013 by razark

[Frederf]

The instrument does the same thing, the same way, every time. If you are surprised by this, then you need to learn to use the instrument.

You would make a horrible engineer. "User testing reveals that a significant fraction of users experience a negative experience with the design." "The design is perfect and unchangeable! The users are bad people and should feel bad!"

I know it's hyperbolic, but it's how you come off. You're white-knighting the status quo without a semblance of objectivity. You might have considered your position carefully but it's not apparent. When examining the design of a system you must divorce yourself from the current implementation. Imaging that the system works in any and all ways simultaneously and pick out the practical best design uninformed by history. If you oppose a change check your conclusion by framing it as the change has already occurred and you suggest that it be changed back.

"The navball mode persists until user input to do so. I suggest that at an undocumented consistent round number that it automatically change modes without user input with minimal visual clues."

[Psycix]

Though this IS a usability problem rather than a functional problem with the instruments themselves, so I stick to my suggetion: Color code the different modes!

[Sean Mirrsen]

You would make a horrible engineer. "User testing reveals that a significant fraction of users experience a negative experience with the design." "The design is perfect and unchangeable! The users are bad people and should feel bad!"

I know it's hyperbolic, but it's how you come off. You're white-knighting the status quo without a semblance of objectivity. You might have considered your position carefully but it's not apparent. When examining the design of a system you must divorce yourself from the current implementation. Imaging that the system works in any and all ways simultaneously and pick out the practical best design uninformed by history. If you oppose a change check your conclusion by framing it as the change has already occurred and you suggest that it be changed back.

"The navball mode persists until user input to do so. I suggest that at an undocumented consistent round number that it automatically change modes without user input with minimal visual clues."

I'd point out that the navball is your single most important and most-used instrument, and when you see that something is off you better damn well check the speed reading. Also the phrasing would be "I propose that the navball automatically change modes as most appropriate to current ship mission parameters without requiring user input."

[M5000]

I think several things...

1) People need to calm down. This is not worth getting your panties in a bunch over. It's a small thing that needs to be addressed calmly.

2) I don't think changing the way it auto-switches would be a good idea, because as people have mentioned, it may throw off other users.

3) I think the best solution would be a color-code change, either of the velocity itself, or of the sky/ground colors. The reason for this is that it would CLEARLY indicate to players that "HEY the Navball is in mode X Y or Z because it's color A B or C! Take heed!" but it wouldn't force a change on how it already operates, so it would not throw off players who are already accustomed to it in a certain way.

4) Is it really that big of a problem that people don't look at their velocity and see what mode the navball is on before doing a burn?

Seriously though, guys, settle down, this is not life or death. It's okay to have a strong opinion, it is not okay to express it so violently.

[Diche Bach]

Options to turn off any "auto" thingy are always good.

[brusura]

Options to turn off any "auto" thingy are always good.

You sir speak the truth o7 , would be nice to have this option in the next versions....like 0.24