Squad, "Target Mode" is DRIVING ME CRAZY

[KerikBalm]

Well, they are pretty easy to circumvent.

Its not that its difficult to get around it, its that its *annoying* that I have to. I'd like to be able to lock the nav ball in a specific mode. I don't think it would be too hard to do.

But I'm also not going to go on a rant against squad if they don't get around to it for the next update.

[DrunkenKerbalnaut]

3 hours ago, KerikBalm said:

But I'm also not going to go on a rant against squad if they don't get around to it for the next update.

Really bucking the norm, here. Not even a wee little rant?

I'm down with a lock/unlock button. Perhaps OP should consider a feature suggestion in the appropriate sub-forum?

[Draco T stand-up guy]

On 15/11/2016 at 8:46 AM, Capt. Hunt said:

mode switch occurs at Max-Q

 

He is a shifty bugger.

[RocketBlam]

I guess the problem is that I learned how to rendezvous with a target before I knew target mode existed (apparently they only started turning it on automatically a few versions ago). So if I'm coming in, and I just want to use the manual method because I can clearly see what to do to rendezvous, this won't work when it automatically switches.

Still, I think automatic switching is a bad idea, and it's been a problem for me since they changed it.

As far as the switch between Orbit and Surface, I've never noticed, and it's never been a problem for me.

On 11/14/2016 at 6:38 PM, DrunkenKerbalnaut said:

If the NavBall changed colors when switching it would catch your attention. 

SURFACE: Blue/Brown

ORBIT: Black/Green

TARGET: Light Gray/Dark Grey

or something like that. 

Exactly. This would at least make it easy to see that you were in a different mode.

The camera mode switches automatically sometimes, but this is immediately obvious to me because the camera moves. 

Edited November 17, 2016 by RocketBlam

[problemecium]

I admit I've accidentally burned the wrong way a couple times before, but as a careful driver who keeps an eye on my map while burning, it's never cost me more than 1 or 2 m/s delta-V at most.

Also, where'd the assertion about Max Q come from? In my experience it invariably happens at exactly 36km (for Kerbin anyway) and Max Q seems (based on vehicle handling) to fall somewhere between 10 and 20km.

Edited November 17, 2016 by parameciumkid
Max Q?

[DrunkenKerbalnaut]

3 hours ago, parameciumkid said:

I admit I've accidentally burned the wrong way a couple times before, but as a careful driver who keeps an eye on my map while burning, it's never cost me more than 1 or 2 m/s delta-V at most.

Also, where'd the assertion about Max Q come from? In my experience it invariably happens at exactly 36km (for Kerbin anyway) and Max Q seems (based on vehicle handling) to fall somewhere between 10 and 20km.

Somebody said it earlier in this thread. Or somewhere around this place. Dubious theory, but I've seen worse go un-challenged .

If you build a rocket that tumbles at 18km, throttling down at Max Q takes a backseat to more pressing matters  .

[problemecium]

Yeah, that person was what I was talking about.

...are you supposed to throttle down at Max Q? I always keep full throttle until either I hit 3 Gs of acceleration or my Apoapsis breaks 50km o_O

[Stoney3K]

On 14-11-2016 at 2:32 PM, Firemetal said:

Edit: Sometimes, it automatically unsets your target as target for me. This is really annoying because it also switches to orbit mode as well. But given the things I said in this post, you should notice it.

That happens because a double click will always unset the active target. IMO, that *is* an annoying bug which needs to be tackled because accidental double-clicks happen all too often with part selection or mods which have their own UI.

[Padishar]

4 minutes ago, parameciumkid said:

...are you supposed to throttle down at Max Q?

Not specifically.  The only thing you're "supposed" to do is whatever is needed to get the vessel to do what you want.  If throttling down around maxQ with a certain vessel means you get to orbit without flipping then do it.  You might be better off redesigning so you don't have to but, with some vessels (and some players) that may not be easy...

[Leafbaron]

I don't understand how this is an issue, really I don't. Its the pilots job (the player) to monitor flight instrumentation. Take some accountability and just check your flight instrumentation before making a burn. It's that simple. While I like the idea of different colored navballs for surface, orbit, and target velocity vectors, the veolcity information above the navball clearly states what mode you are currently in.   

[Padishar]

9 minutes ago, Leafbaron said:

I don't understand how this is an issue, really I don't. Its the pilots job (the player) to monitor flight instrumentation. Take some accountability and just check your flight instrumentation before making a burn. It's that simple. While I like the idea of different colored navballs for surface, orbit, and target velocity vectors, the veolcity information above the navball clearly states what mode you are currently in.   

Now consider the situation where the display changes during a burn causing your SAS (when set to prograde or retrograde) to suddenly change the direction your vessel is pointing...

[Leafbaron]

1 minute ago, Padishar said:

Now consider the situation where the display changes during a burn causing your SAS (when set to prograde or retrograde) to suddenly change the direction your vessel is pointing...

I have never ever encountered a situation where this has happened. I suppose it's possible under the right circumstances. The only scenarios I can see this happening in are if you approaching a set target in which case I don't know why you'd be setting up a burn, or if you were de-orbiting to land in which case you'd want to be burning in surface mode anyways. Still, a complacent pilot is a dead pilot, always monitor your flight data. 

[Padishar]

4 minutes ago, Leafbaron said:

I suppose it's possible under the right circumstances.

I suggest you go and read the thread (a number of real, problem situations have been described) rather than just jumping in with a poorly-informed opinion.  I almost always see it switch from surface to orbital during launch and it has caused an issue on at least two occasions when I was set to follow prograde and trying to launch to an accurately inclined orbit.  I've also had it switch from orbital to target during a burn that was supposed to adjust a phasing orbit for a close encounter.  Then there's also the issue where a rover can switch into orbit mode while still on the ground on certain bodies.  This has never caused me a problem but it's still very silly...

An option to totally disable the auto-switching wouldn't hurt anyone.  Nor would an option that prevents auto-switch during a burn (possibly only if SAS is set to a potentially dangerous setting).

[Leafbaron]

40 minutes ago, Padishar said:

I suggest you go and read the thread (a number of real, problem situations have been described) rather than just jumping in with a poorly-informed opinion.  I almost always see it switch from surface to orbital during launch and it has caused an issue on at least two occasions when I was set to follow prograde and trying to launch to an accurately inclined orbit.  I've also had it switch from orbital to target during a burn that was supposed to adjust a phasing orbit for a close encounter.  Then there's also the issue where a rover can switch into orbit mode while still on the ground on certain bodies.  This has never caused me a problem but it's still very silly...

An option to totally disable the auto-switching wouldn't hurt anyone.  Nor would an option that prevents auto-switch during a burn (possibly only if SAS is set to a potentially dangerous setting).

you are right, it wouldn't hurt to add that functionality, I have read the entire thread, twice, so I wouldn't go as far as to say poorly-informed haha. That being said it is my opinion and you know what they about those don't ya!? they're just like amazing persons, everyone's got one and they all stink! Still though I believe many people would agree with me that falling victim to theses different circumstances is pilot input error rather than system error.  

[HebaruSan]

16 minutes ago, Leafbaron said:

Still though I believe many people would agree with me that falling victim to theses different circumstances is pilot input error rather than system error.  

What error is the pilot making in the launch-to-rendezvous scenario? Targeting the target? Locking prograde?

[Capt. Hunt]

10 hours ago, DrunkenKerbalnaut said:

Somebody said it earlier in this thread. Or somewhere around this place. Dubious theory, but I've seen worse go un-challenged .

If you build a rocket that tumbles at 18km, throttling down at Max Q takes a backseat to more pressing matters  .

Sorry, I'm pretty sure I read that here somewhere.  Does anyone know for sure when it occurs?  

[Leafbaron]

16 minutes ago, Capt. Hunt said:

Sorry, I'm pretty sure I read that here somewhere.  Does anyone know for sure when it occurs?  

just kidding thats from like a couple posts up.

Edited November 17, 2016 by Leafbaron

[Leafbaron]

30 minutes ago, HebaruSan said:

What error is the pilot making in the launch-to-rendezvous scenario? Targeting the target? Locking prograde?

yeah i would say locking prograde and not checking his/her flight instrumentation. If you wanna fly with little to no intervention, have mechjeb do the piloting. But if you're flying manually just check to make sure the right mode is selected even if it changes during a burn be quick to change it back or don't lock prograde until you're sure it won't change again. I just don't see how its Squads responsibility to fix a problem that can and has been solved by diligent piloting. 

[HebaruSan]

15 minutes ago, Leafbaron said:

yeah i would say locking prograde and not checking his/her flight instrumentation. If you wanna fly with little to no intervention, have mechjeb do the piloting. But if you're flying manually just check to make sure the right mode is selected even if it changes during a burn be quick to change it back or don't lock prograde until you're sure it won't change again. I just don't see how its Squads responsibility to fix a problem that can and has been solved by diligent piloting. 

In case this was unclear, "not checking his/her flight instrumentation" is not involved in the launch-to-rendezvous scenario. The pilot does check his/her flight instrumentation, and it is set appropriately for the action of locking prograde at the time that decision is made. Then, later and without warning, the flight instrumentation changes itself automatically, and the craft swerves out of the pilot's intended alignment.

Yes, we can work around that problem by watching carefully for the moment when the malfunction sets in and tapping 'F' to reset the SAS mode, or clicking the nav ball until it's back in the correct mode. But being able to work around a problem doesn't mean it's a non-problem.

[CloudlessEchoes]

I agree that this can be annoying, and an option to disable it would be great!

[swjr-swis]

This issue has been identified and reported several times, all requesting a way to stop the automatic switching:

http://bugs.kerbalspaceprogram.com/issues/3980: Option to disable automatic switching of reference frame?

http://bugs.kerbalspaceprogram.com/issues/5283: Reset (at least some) autopilots to basic SAS when navball switches modes

http://bugs.kerbalspaceprogram.com/issues/6570: Navball should switch NOT switch to Target mode in proximity of a target if the target is landed or if SAS is in pro/retrograde tracking mode

 

I particularly enjoyed the response on the first report I found, from 2 years ago: "A very good and well described suggestion. It has been forwarded for attention."

Ah well... they'll get to it at some point. Right?

[DrunkenKerbalnaut]

14 hours ago, parameciumkid said:

Yeah, that person was what I was talking about.

...are you supposed to throttle down at Max Q? I always keep full throttle until either I hit 3 Gs of acceleration or my Apoapsis breaks 50km o_O

I feel like I've read about the Apollo and Shuttle launches doing this. Minimizes strain on the vehicle. Not necessary (at least for the same reasons) in KSP. Real astronauts have to contend with many more structural failure modes than we Kerbals. 

[memes in space]

On 11/14/2016 at 2:57 AM, Streetwind said:

In contrast to the previous posters, I've never fallen victim to this... in fact I wonder how it even happens for you guys o_O

The auto-changing from Orbit reference to Target reference only happens once you're really close to your target... AKA, you're on a close intercept already. At that point, you want to be in target mode. You need the Target Retrograde marker so that you can easily match orbits. It makes perfect sense to auto-switch.

If you're making rendezvous burns that cost a third of your remaining dV or more - or in fact, if you're making any burn at all that changes your orbit in any significant way while having a vessel targeted and being in close proximity of it - you're probably doing it wrong. If you want to rendezvous with your target, you need to burn Target Retrograde for a small amount of dV, and not manually muck about with your orbit for large amounts. If you don't want to rendezvous with the target, why have you targeted it in the first place? Put the thing you actually want to go to as your target instead! If you really need to make that big of a burn to reach it, it's going to be far enough away that you never have the auto-switch problem.

I've always enjoyed the automatic switching to target mode. In contrast to surface/orbit, which sometimes switches too late or too early for my tastes, and requires me to manually switch, the target mode has always come up precisely when I needed it, and never in any other case. Which is why I'm surprised that three people at once seem to have a problem with it.

 

[Jarin]

13 hours ago, DrunkenKerbalnaut said:

Real astronauts have to contend with many more structural failure modes than we Kerbals. 

Tell that to my attempts at a cargo SSTO.

[Leafbaron]

I very much agree with what @Streetwind said!