Squad, "Target Mode" is DRIVING ME CRAZY

[Clancy]

11 hours ago, Technical Ben said:

I landed on Minmus sideways last week because I targeted a flag to land near it, then used the navball to land and try for zero mps. Only to notice it was my relative velocity to the flag, not to the surface!

 

2 hours ago, Jarin said:

I'm mostly confused how "target speed" and "surface speed" can be so incredibly different when I'm targeting a stationary object on the surface. My target speed always shows significantly higher, despite the fact that my surface speed and approach speed should be nearly equal. Instead, it's 100+m/s off, and I stall out on approach if I don't catch it in time. (yes, I always check now, but I didn't even realize what was wrong the first few times)

This is my problem as well. For some reason when you target a stationary object, relative velocity defaults to ORBITAL instead of SURFACE. I sent a couple of landers tumbling across the plains of Minmus and had a few planes stall out as they approach the runway when speed read 200m/s before I figured this out. Now I check the navball mode obsessively during every landing, but that's a work-around, not an ideal solution.

[DrunkenKerbalnaut]

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. 

Edited November 15, 2016 by DrunkenKerbalnaut

[Allocthonous]

For all those people asking how this causes problems: Every time it's happened to me, I've been leaving the Mun or Minmus after meeting up with an object orbiting those bodies. Usually I un-target an object after undocking with it, but I forgot a couple of times, and ended up making an incorrect burn.

And really, it's not a problem unless you're absentminded about things. But it would be nice to have an attention grabbing visual indicator or other obvious difference between target-prograde and surface/orbit-prograde.

[Gargamel]

I'm not sure what the issue is here... the navball states "TARGET" "ORBIT" or "SURFACE" in big bold letters right on the top of it.   While of course it would be nice to have automatic switching as a toggleable option, it seems pretty intuitive to check what mode you're in before burning, and extremely easy to click over to the right mode.   I think with all the recent dev departures from Squad, it may be a little much to have them come sit by your side and hold your hand for you while you play.  Of course, maybe one of the few remaining ones can write a bit of code to help people with this issue.   Maybe something like this?

 

[DrunkenKerbalnaut]

6 minutes ago, gargamel said:

I'm not sure what the issue is here... the navball states "TARGET" "ORBIT" or "SURFACE" in big bold letters right on the top of it.   While of course it would be nice to have automatic switching as a toggleable option, it seems pretty intuitive to check what mode you're in before burning, and extremely easy to click over to the right mode.   I think with all the recent dev departures from Squad, it may be a little much to have them come sit by your side and hold your hand for you while you play.  Of course, maybe one of the few remaining ones can write a bit of code to help people with this issue.   Maybe something like this?

 

I wouldn't describe it as "big bold letters". That's my own personal issue with the automatic switching. It's easy to miss when it has happened, and make incorrect burns due to it. I would relate it to a similar issue of "control from here" changing when switching vehicles, ie.: a valid issue.

If an intuitive UI with repeatable results amounts to SQUAD "sitting by my side and holding my hand" then we simply have largely differing expectations of commercial end-user software.

I'm ok with that. 

[Allocthonous]

10 minutes ago, gargamel said:

 I think with all the recent dev departures from Squad, it may be a little much to have them come sit by your side and hold your hand for you while you play.  Of course, maybe one of the few remaining ones can write a bit of code to help people with this issue.   Maybe something like this?

Bitter much? Besides, chances are there's already a mod for that.

I've paid my money for this game, and I'm 400 hours worth of happy with my purchase, most of that even before the most recent update. That works out to the game costing me something like 1 cent per hour of play. Any further improvements that are made, essentially free of charge to me, are just bonuses. If other people disagree with the things that I personally believe could be improved upon, that's fine. Don't get so worked up about it.

That said, I still think this piece of interface could be better. Merge target mode into the other modes with new symbols, or even just add color coding to the surface/target/orbit label text. It already changes position, left for surface, right for orbit, and centered for target, but that was apparently subtle enough that I had to specifically look for it to notice.

[Gargamel]

If a large indicator light that states, quite obviously, what mode the navball is in, is not an intuitive UI, I don't know what is. 

There's a reason NASA and most aerospace ventures use checklists when operating their vehicles, it's so things don't get missed.  I've built such complicated vessels before that I've had to write up, by hand, page long checklists before operating them.   In this case, I don't have a written checklist for doing a burn, but a mental one.  I step through all the possible questions I could have about the burn before performing it.  Similar to how wood workers use the saying "Measure twice, cut once" or Medical workers use the phrase "Right patient, right drug, right dose, right date" for administering drugs, you should have a mental checklist for every operation you perform in the game. 

[DrunkenKerbalnaut]

1 minute ago, gargamel said:

If a large indicator light that states, quite obviously, what mode the navball is in, is not an intuitive UI, I don't know what is. 

There's a reason NASA and most aerospace ventures use checklists when operating their vehicles, it's so things don't get missed.  I've built such complicated vessels before that I've had to write up, by hand, page long checklists before operating them.   In this case, I don't have a written checklist for doing a burn, but a mental one.  I step through all the possible questions I could have about the burn before performing it.  Similar to how wood workers use the saying "Measure twice, cut once" or Medical workers use the phrase "Right patient, right drug, right dose, right date" for administering drugs, you should have a mental checklist for every operation you perform in the game. 

Yeah, but it's a game. 

[foamyesque]

14 hours ago, Jarin said:

I'm mostly confused how "target speed" and "surface speed" can be so incredibly different when I'm targeting a stationary object on the surface. My target speed always shows significantly higher, despite the fact that my surface speed and approach speed should be nearly equal. Instead, it's 100+m/s off, and I stall out on approach if I don't catch it in time. (yes, I always check now, but I didn't even realize what was wrong the first few times)

That's due to the rotation of the body, if I recall right from when I ran into it for the first time years ago. As long as two objects are in orbit, it works. As long as two objects are within physics range of each other, it works. If, however, they're both landed, but one is outside physics range (and therefore unloaded) the game screws up its math and assumes it is moving relative to you at a speed exactly equal to the rotation of whatever body you're on.

[KerikBalm]

I would very much like an option to disable the autoswitching of both the navball, and the camera.

It can really such when i'm trying to do a precisely timed rendezvous from the surface. I'm well into my gravity turn, SAS set to follow prograde... a little terrier/poodle/LV-N doing a long burn at low TWR... the orbit is looking good.... the predicted intercept distance is under 1.0 km... and then my ship flips out because it switched to target mode and that darn SAS that was following the craft's prograde starts pointing in another direction that screws up the nice intercept...

Its annoying.... let me switch modes when I want to switch.

At the very least toggle the SAS state so the entire craft won't start to rotate when the switch happens.

[Starhawk]

After skimming this thread it's clear that there is an issue with the automatic navball mode switching in some circumstances.

9 minutes ago, KerikBalm said:

I would very much like an option to disable the autoswitching of both the navball, and the camera.

I think an option to disable auto-switching of navball mode would work well.

Perhaps a thread suggesting this in Suggestions and Development Discussion is in order.

I usually don't launch direct to rendezvous but I can see how the automatic switch in the middle of a burn would most likely end in disaster.

Happy landings!

[HebaruSan]

32 minutes ago, KerikBalm said:

Its annoying.... let me switch modes when I want to switch.

At the very least toggle the SAS state so the entire craft won't start to rotate when the switch happens.

What if the game also checked relative velocity in addition to proximity before switching? Say, if you're over 100 m/s it assumes you're not ready for precise docking maneuvers, but slower than that it changes modes. You could still change it manually for a "suicide rendezvous."

Alternately, revert SAS to stability assist when auto-switching to target mode. Prograde and retrograde mean such different things in those two contexts that it's hard to imagine a case where the user's intention is reflected by the current behavior.

[KingPhantom]

On 14.11.2016 at 8: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

same here. just check before burn. same with surface and orbit. i often watch youtube ksp videos... and i often see that the gamer forgets to switch or didnt checked it. 75% of the fails i can see comming

[Comante]

7 hours ago, foamyesque said:

That's due to the rotation of the body, if I recall right from when I ran into it for the first time years ago. As long as two objects are in orbit, it works. As long as two objects are within physics range of each other, it works. If, however, they're both landed, but one is outside physics range (and therefore unloaded) the game screws up its math and assumes it is moving relative to you at a speed exactly equal to the rotation of whatever body you're on.

I think the reason is in the definition, and in geometry.
Surface speed is your vector velocity PARALLEL to the surface of the planet, instead, your target velocity is the straight vector from you to the target. So, the angle at which your velocity vector is angled, matter a lot. If you dive ad 90° on your target, you could read your surface speed as ZERO, but your target speed could be 3000m/s. And it's no bug.

[suicidejunkie]

Many of you seem to be under the impression that the problem is "navball is in an unexpected mode and you forgot to check before doing a burn"

The big problem comes in when the navball CHANGES mode DURING a burn;  you are merrily running your engines burning prograde to orbit, when the navball flips to target mode.  Your ship then flips out as SAS panic sets in and you do not go to space today.

 

1 hour ago, Comante said:

your target velocity is the straight vector from you to the target

And if you're both parked reasonably close on the surface, this vector should not be changing (other than rotating a leisurely 360 degrees per day), so the target velocity should be near zero, would you not agree?

Instead, you'll find that when rovering slowly towards a stationary target, orbital speed is roughly equal to target speed.

[Jarin]

8 hours ago, foamyesque said:

That's due to the rotation of the body, if I recall right from when I ran into it for the first time years ago. As long as two objects are in orbit, it works. As long as two objects are within physics range of each other, it works. If, however, they're both landed, but one is outside physics range (and therefore unloaded) the game screws up its math and assumes it is moving relative to you at a speed exactly equal to the rotation of whatever body you're on.

Tested a bit more, and things start to get weird. I have a flag at the east end of my runway, putting it at just under 3km away from me at launch. If I target it with a stationary aircraft, I read 170m/s. Okay, sure. I taxi down the runway, and get inside 2.2km, and it flips to showing my 10m/s surface speed (i.e. actual relative velocity). Alright, physics range theory basically proven. But now I take off and fly west, and the target velocity remains accurate, even once outside of the physics bubble.

So it can switch to "correct" mode once you're in physics range of an object, and then save it. But this is getting lost somehow on orbital flights. Otherwise I would never have any trouble, since I fly straight over that flag on every single takeoff. Need further testing to see when this jumps. 

[Norcalplanner]

So it sounds like the solution is simple - Squad, could you please make auto-switching of nav ball modes a toggleable option? Thanks.

And in the meantime, anuone habing trouble may want to check out the SmartASS function in MechJeb. The more I play, the more I love that function. I'm pretty sure that if MJ was reduced just to SmartASS and a button for "execute next node" that I'd be quite happy.

[Padishar]

10 minutes ago, Norcalplanner said:

So it sounds like the solution is simple - Squad, could you please make auto-switching of nav ball modes a toggleable option? Thanks.

Perhaps a better (or just alternative) option would be to make it never automatically switch modes when SAS is in any mode other than plain stability assist...

[Jarin]

Okay, this is interesting. If you target something AND enter its physics range (to have the correct target velocity), you never lose that. It's possible that it's only lost on reload, and I've only been caught out by this problem on flights where I've scene-swapped after reaching orbit.

Edit: Anyway, enough of a sidetrack from the navball-switching issue. I think I've properly demonstrated that this has some unintended effects here, and that surface-velocity-tracking possibly has a bug.

Edited November 15, 2016 by Jarin

[KerikBalm]

7 hours ago, Starhawk said:

After skimming this thread it's clear that there is an issue with the automatic navball mode switching in some circumstances.

I think an option to disable auto-switching of navball mode would work well.

Another more minor issue is the auto switch from surface to orbital. IIRC on minmus the very highest places are high enough that it auto switches to orbital... which can be annoying if you were just doing a short hop to land at a highlands biome.

I also find it annoying during some ascents where my craft that is set ot follow prograde switches from surface to orbital... this isn't the same thing and changes the AoA and the drag - this is minor because it seems to occur over 30 km, and the small AoA change isn't going to cause any rocket/plane to become unstable and flip if it was stable enough to make it through the lower atmosphere (only some very very very marginal cases, where stability may have gotten worse as fuel burns off), and the drag at that altitude is minimal.

Its a minor annoyance, and I've learned to expect the autoswitch coming and set SAS to hold heading as it nears the point that it will switch.

An option to disable navbal autoswitch would be greatly appreciated... just one of those small things that would be nice.

[EpicSpaceTroll139]

While I haven't had any space disasters or significant amounts of fuel wasted by this, I do find that it often switches before I want it to. The game commonly switches me over when I get within 10-20, sometimes even as much as 30km, even though I still have two or three more orbits to go before the rendezvous (I like to save my fuel so I don't use large ∆sep  phasing orbits). Before the last one I need to make a prograde or retrograde (depending on whether I'm coming from the inside or outside) burn to set up an approach within 2km (usually more like .5km). I don't need or want the target mode on the nav ball before I get within 2km. Thus I constantly have to turn the nav ball back to orbital and later to target again. While it's not really a problem, it would be nice to be able to either toggle the auto switch, or change the range at which it is activated.

Edited November 15, 2016 by EpicSpaceTroll139

[Tyko]

I'm all in favor of adding customizability to the game, but I think the current behavior works extremely well as the default. I've been doing a ton of docking - in the midst of scraping Mun and Minmus of science using a dedicated lander and small station - and the switch always feels like it comes at the right time.

My positive experience is likely tied to the fact that I learned docking under the current regime, so I get that others may have learned differently and support that idea that they can switch it off. Just don't change the current default behavior.

[Aragosnat]

47 minutes ago, tjt said:

I'm all in favor of adding customizability to the game, but I think the current behavior works extremely well as the default. I've been doing a ton of docking - in the midst of scraping Mun and Minmus of science using a dedicated lander and small station - and the switch always feels like it comes at the right time.

My positive experience is likely tied to the fact that I learned docking under the current regime, so I get that others may have learned differently and support that idea that they can switch it off. Just don't change the current default behavior.

Actually. The NavBall has been doing this since 0.18 and likely before as well. But, it would be nice if it was disable the auto-switch as well as increase the switch surface to orbit for places like Minmus where we can see mountain tops while still being in orbit. It has been annoying when drivign rovers there.

[monstah]

I never had a problem with auto-switching, but reading this thread I see that some people's problems aren't really too easy to circumvent; prominently, these two:

On 14/11/2016 at 1:54 PM, Veeltch said:

Same thing happened to me. I was on my ascent profile going suborbital and I saw an old sat flying by so I went "Hey, I can target it now and rendezvous with it later to perform an EVA inspection just for fun". But I didn't. Everything went wrong. The vessel I was flying was set to prograde keeping mode and all hell broke loose. Tumbled, wasted tons of fuel and fell back into the atmosphere.

21 hours ago, KerikBalm said:

Another more minor issue is the auto switch from surface to orbital. IIRC on minmus the very highest places are high enough that it auto switches to orbital... which can be annoying if you were just doing a short hop to land at a highlands biome.

I still like the auto-switching myself, but in defense of people having these problems, I suspect it would be good having SAS switch from whatever autopilot mode it was to "SAS hold", when doing the auto-switch.

[Wjolcz]

1 hour ago, monstah said:

I never had a problem with auto-switching, but reading this thread I see that some people's problems aren't really too easy to circumvent; prominently, these two:

I still like the auto-switching myself, but in defense of people having these problems, I suspect it would be good having SAS switch from whatever autopilot mode it was to "SAS hold", when doing the auto-switch.

Nah. I just goofed there. It was only one time. I actually think it was a pretty funny situation.