[0.1.2.0] Velocity display switches from surface to orbit, SAS target follows suit, chaos ensues

[Davidian1024]

No mods.

This is something I've always hated in KSP1.  Looks like it's been brought over to KSP2.  I can only assume this has got to be something that completely confounds new players.  I know when I was new to KSP1 it confounded me.

While ascending over Kerbin, when you pass ~36K, the velocity display automatically switches from surface to orbit.  Because the SAS targets are based on that setting they switch as well.  This has regularly thrown my craft into an unrecoverable spin.  So, I nearly always have to do something to compensate.  I'm actually hard pressed to think of a situation where I actually want this behavior.

In KSP2 there's an added complication.  "Up" has been added as a SAS target when surface velocity is selected.  This addition is awesome, I find myself regularly using this during initial liftoff.  But once you cross the ~36K mark, the switch from velocity to orbit occurs, and "up" seems to correspond to "radial out".  And SAS diligently switches to the new target.  This has always been way off from what up was when the switch happened. 

I think all that's needed is a way to lock the velocity control to whatever it currently is.

 

[Turbo Ben]

Couldn't agree more. I've been using the "up" SAS button for most of my launches because I'm going for a very high orbit. Having to keep tabs of my altitude and then messing with SAS at 36Km is a pain in the rear, espescially if it coincides with a staging event. Even if flying prograde it can be a pain as the rocket reacts to the sudden change in prograde vector from ground to orbit and SAS overshoots by a mile and takes ages to correct.

[Vortygont]

Yes, this situation is so annoying. I also faced switching from "up" to "radial out" mode. I would like to switch to default SAS mode if it switchs from one mode to another. Except when it is set by maneuver or to/from the target

[Davidian1024]

Quote

quote from other thread

This sudden transition itself to orbit mode is devastating to large missions.  Huge launches need to clear the atmosphere before making any turns and this does some foolishness where it tries to sabotage the mission around 30km altitude. 

Radial out and in are slightly different than up and down depending on your orbital speed I think.  Regardless, I think it switches from "up" to another mode that is not "radial out" but the net result is flipping at high altitude among the many other things that can cause high altitude flipping.

Also I am not seeing the issue with up not being selectable due to my specific "workflow".  I watch the navball like a hawk and immediately engage hold mode with a double tap when it switches to "mission sabotage mode".  I then click the indicator to change back to surface and specify surface mode again and it works fine.

@Jason_25

"Mission Sabotage Mode" is a great way to describe this auto switch behavior.

[dr.phees]

SAS was basically excrementsty in KSP 1 and is again in KSP 2.

Years ago I suggested a solution for proper SAS: Do SAS via the trim sliders. This would also completely eliminate the weird 'bump' when adding some manual input. If SAS used the trim, a manual input would be added to the current pitch/roll/yaw. Currently, when a manual input is detected, the SAS input is basically switched off and handed over to the manual until manual input is zero again. And that even for all axis, even if there is no input on that axis.

Trim could be reset if SAS is turned off, or could even be kept (optional), so you get a stable craft when turning off SAS.

In case of surface/orbit switch, SAS should have a period of ~2 seconds of soft 'crossfade'. This should do the trick in solving OP's sudden 'step' issue.

Edited May 5, 2023 by dr.phees

[Lyneira]

On 5/5/2023 at 10:48 AM, dr.phees said:

In case of surface/orbit switch, SAS should have a period of ~2 seconds of soft 'crossfade'.

A crossfade, if technically feasible, would do a lot to soften the sudden movement. In addition, I would suggest mapping the SAS settings upon switch as follows:

In the event of switch from surface to orbit, map SAS settings as follows:

• Up/Down -> hold attitude

In the event of switch from orbit to surface:

• Radial in/out -> hold attitude

 

When flying aircraft in KSP2, I was initially trying to avoid using SAS and use trim only, because they could not be combined in KSP1.

In KSP2 though, trim does combine better with SAS. I use it to add a pitch up trim so that SAS can hold the plane's attitude well and the nose doesn't drop down when giving, for example, roll inputs to make turns.

[dr.phees]

1 hour ago, Lyneira said:

In KSP2 though, trim does combine better with SAS. I use it to add a pitch up trim so that SAS can hold the plane's attitude well and the nose doesn't drop down when giving, for example, roll inputs to make turns.

It should be the other way around (that's what some real pilot assists do). SAS should control trim, user input should be added to SAS input.

I don't know why the current bad behavior has been put into the game again, except that the devs seemingly not only want to build the complete same game as KSP 1 again, not going for new / extended story etc., but really don't want to touch anything physics related - 'good enough' left and right.

@DEVS: If you somehow read this (we never know, because you never comment): Finally do SAS properly! I don't care for better communication anymore, just do this right.

[Bej Kerman]

40 minutes ago, dr.phees said:

because you never comment

Incorrect

[dr.phees]

On 5/8/2023 at 4:43 PM, Bej Kerman said:

Incorrect

Show me an example where a proper comment from a developer was made on a suggestion.

[Bej Kerman]

7 hours ago, dr.phees said:

On 5/8/2023 at 3:43 PM, Bej Kerman said:

Incorrect

Show me an example where a proper comment from a developer was made on a suggestion.

The burden of proof is on you for suggesting they don't in the first place. Don't try to weasel out of being wrong about something, just because you want to paint the developers as ignorant gremlins.

[Davidian1024]

On 5/5/2023 at 4:48 AM, dr.phees said:

In case of surface/orbit switch, SAS should have a period of ~2 seconds of soft 'crossfade'. This should do the trick in solving OP's sudden 'step' issue.

No, it would not solve my issue.  My issue is that a switch from orbit to velocity occurs period.  I always end up switching back.  I just want a way to disable the auto switch.  I don't even understand why the switch exits.

[Socraticat]

5 minutes ago, Davidian1024 said:

No, it would not solve my issue.  My issue is that a switch from orbit to velocity occurs period.  I always end up switching back.  I just want a way to disable the auto switch.  I don't even understand why the switch exits.

A toggle in the gameplay menu would be just right. I am 100% on board with your idea.

[dr.phees]

I agree, there should be a UI-toggle /lock for auto-switching and a preferrence toggle in the settings.

Edited May 10, 2023 by dr.phees

[Bej Kerman]

2 hours ago, dr.phees said:

I agree, there should be a UI-toggle /lock for auto-switching and a preferrence toggle in the settings.

It's weird to quote someone then completely change your reply, but I agree.

[Davidian1024]

Something else comes to mind that I forgot to mention previously.

This switch from surface relativity to orbital relativity happens while you're about half way between sea level and the edge of the atmosphere.

Why should it change like that when you go above that altitude?  It's highly unlikely that you've achieved orbit.  You definitely haven't achieved a stable orbit because you're still in the atmosphere.

So why should it change to orbital relativity in this moment?

I think it would make alot more sense if the switch happened once you've at least got a periapsis above sea level.  To be honest, I really don't think it should happen automatically until you have an orbit that's fully outside of the atmosphere.

[Dakitess]

As for myself, I've never been annoyed by this transition : any Gravity Turn will lead you to a near-horizontal (+10° for extreme weird launches) attitude at ~36km anyway, and it's better to be even more flat to build horizontal speed rather than keeping in Surface Referential and keep adding vertical speed.

I don't see how a massive really weird launch would flip at 36km because of that, except indeed if you're ascending straight vertical, but why doing so rather than a very gentle Gravity Turn using Follow Prograde ? You'll end up with vastly improved launch performance while not loosing anything in stability if you stick to that Follow Prograde SAS and have some gimbal (even just a little is enough). At 36km, the atmosphere is globally already empty so the sudden change of attitude would not to much even for an passive-unstable craft.

Anyway, I find it mostly convenient but agree that it's weird, it should not switch before 70km for instance, and people like me enjoying flat GT would trigger the Speed Referential by themselves.

[Davidian1024]

This actually comes up if you just have SAS tracking surface prograde while making a typical gravity turn.  If the craft is particularly aerodynamically unstable, the sudden switch from surface prograde to orbit prograde, which may only be a few degrees, can be enough to throw you into a spin.

This is how I remember running into it most often in my KSP1 days.  Trying to build craft that were barely capable of reaching orbit.  Or trying to squeeze every last drop of delta v out of my in atmosphere stages.  Even if the sudden switch didn't spin me out, it might cause enough delta v loss to ruin the mission.

I think another area that this comes up in is when you're running KSP on an under powered machine.  I used to play KSP1 on a laptop with a dedicated GPU that was barely better than integrated graphics.  It truly was Kerbal Slideshow Program at times.  This generally meant relying heavily on SAS.  So when SAS suddenly does something you don't expect without warning, it can have a drastically negative effect on your mission.

There are definitely ways to work around this, but I have yet to hear someone argue in favor of it.  As in, they depend upon it for something, and would miss it if it were gone.  Part of me really just wants to know why it exists at all.  What was the thinking when it was put into the game in the first place.

[Dakitess]

I've never never ever had a spin because of the speed referential switch from surface to orbit. At 36km, you really barely have no lift / drag that would cause that. I guess if you have something with TONS of wings at the tip + no GT, just vertical ascension at low low speed and the shift is then maybe a sudden 10°, while not having any gimbal, it might *might* happen, but that sounds unlikely to me. Any GT, even very conservative, would lead to <5° switch I guess and any Gimbal would perfectly deal with adjustments while prevention for a spin.

Do you have a screenshot of a problematic craft that spin because of that prograde switch from Surface to Orbit ?

Anyway, as said previously, theses considerations change nothing to the fact that, indeed, this is very weird to have this referential switch. It does not serve any use and is not comfortable either, should just trigger past 70km so that newbies get the proper referential when they load a game / a craft or get to orbit the first time.

[Davidian1024]

This still exists in 0.1.5.0

@The Space Peacock @Spicat @Anth Can this be moved into the current set of bug reports?  Or do I need to open a new one?

[Kerbart]

We now have  ap/pe markers on the navball but for the longest time that info wasn’t available in a readout ((KSP1), so if you’re keeping an eye on velocity when launching to orbit (2270 is the magic number) then the equatorial rotation velocity of Kerbin (or any body you’re on) gives a considerable offset.

Also, beginning players would be completely unaware of the difference and wouldn’t know you have to switch over. Making it an option is very likely a good idea but it can be argued that the existing setting should be the default to aid new players (and those who’ve come to be used to it).

[The Space Peacock]

1 hour ago, Davidian1024 said:

This still exists in 0.1.5.0

@The Space Peacock @Spicat @Anth Can this be moved into the current set of bug reports?  Or do I need to open a new one?

i'm pretty sure this isn't actually a bug, it sounds more like intended (but annoying) behaviour. in theory it makes sense to switch from 'up' to 'radial out', but in practice it almost never works out.

having it switch to 'SAS hold' instead of 'radial out' when your SAS is set to 'up' when crossing the transition altitude is a great suggestion 

[Bej Kerman]

1 minute ago, The Space Peacock said:

in theory it makes sense to switch from 'up' to 'radial out', but in practice it almost never works out.

It doesn't make sense in theory either because "radial out" is not "up".

[The Space Peacock]

3 minutes ago, Bej Kerman said:

It doesn't make sense in theory either because "radial out" is not "up".

true, but its the closest thing there is to it and all the other surface SAS holds have an orbital counterpart. i'm just saying i get why they did it, not that i'm a fan of it :p

[Davidian1024]

SAS Surface/Orbit Auto Switch While Targeting North

[The Space Peacock]

1 hour ago, Davidian1024 said:

SAS Surface/Orbit Auto Switch While Targeting North

you've sufficiently convinved me that this should indeed be reported as a bug with that video  i still think this is fine for pro/retrograde (since that basically allows you to do a continous launch without ever having to press a button), but it is a problem for up/radial and north/normal

 

Also, a quick heads up: the forum cant embed .mkv files, so please submit any videos for bug reports either as a .mp4 file or youtube link if you can