Finding Retrograde

[Xyphos]

[Snark]

Yup, it's an annoyance, has been around for a really long time.

You didn't include any actual text with your post... but I'll take the liberty of assuming that your intent here is "this is a bad thing, I wish Squad would fix this."  (I agree with you on that!)

In which case, this is a suggestion-- moving to the Suggestions subforum.

[ZooNamedGames]

What I wish is that the navball could be click and shifted around to view where everything is without having to expend EC or monopropellant to find a certain node. Have it where if you double click the navball it will recenter. 

As to the OP's specific issue, that is annoying so it overcompensates for where it's moving and always flies past the target marker. 

[Andem]

Also, with SAS... it's all or nothing. It's a binary system, which causes many issues.

[ZooNamedGames]

However I will say the OP's picture does not show the shortest distance from the current heading to retrograde.

[THX1138]

3 hours ago, ZooNamedGames said:

What I wish is that the navball could be click and shifted around to view where everything is without having to expend EC or monopropellant to find a certain node. Have it where if you double click the navball it will recenter. 

As to the OP's specific issue, that is annoying so it overcompensates for where it's moving and always flies past the target marker. 

RasterPropMonitor addresses this by just showing the pro- and retro-grade and target symbols on the outer edges of the navball (more of a navcircle on RasterPropMonitor) so you know which direction to take.

[ZooNamedGames]

47 minutes ago, THX1138 said:

RasterPropMonitor addresses this by just showing the pro- and retro-grade and target symbols on the outer edges of the navball (more of a navcircle on RasterPropMonitor) so you know which direction to take.

You mean the now redundant Enhanced Navball?

[THX1138]

1 hour ago, ZooNamedGames said:

You mean the now redundant Enhanced Navball?

 

I don't know. It's on the far left in this picture:

[ZooNamedGames]

54 minutes ago, THX1138 said:

 

I don't know. It's on the far left in this picture:

Looks like it.

[OrbitalBuzzsaw]

7 hours ago, ZooNamedGames said:

What I wish is that the navball could be click and shifted around to view where everything is without having to expend EC or monopropellant to find a certain node. Have it where if you double click the navball it will recenter. 

As to the OP's specific issue, that is annoying so it overcompensates for where it's moving and always flies past the target marker. 

With you on both points 

[Xyphos]

15 hours ago, THX1138 said:

It's on the far left in this picture:

 

 

RasterPropMonitor is the one that does IVA enhancements.
Enhanced Navball is now Redundant and IMHO, obsolete.

[Snark]

On 7/22/2016 at 9:06 AM, ZooNamedGames said:

As to the OP's specific issue, that is annoying so it overcompensates for where it's moving and always flies past the target marker.

It's worth noting that there are two problems with the way SAS works to point in a direction.  They're pretty much orthogonal to each other-- unrelated, the fix would be different for each one.

1. When the navball is at point A, and it needs to go to point B, it often torques in the wrong direction, i.e. not straight towards B.
2. The motion overcompensates:  when it arrives at the target orientation, it overshoots and has to come back again.  Sometimes it takes a few oscillations before it settles down.

The OP is complaining about issue #1.  You're mentioning issue #2, which is also a problem but is a different issue.

Issue #2 is about PID tuning, which is a solvable problem, but non-trivial-- it would be a chunk of work to code.  I don't mind it too much; I'd like it if Squad could fix the problem, but I'm fine if they don't get around to it for a while.

I gotta say, though, that issue #1 (which the OP brings up) really irritates me, and has done so for a very long time.  Seems like it ought to be a perfectly straightforward piece of vector math to decide "I'm in this orientation, and I need to point in that orientation, and therefore I need to rotate in this direction".  I'd say (with the obvious caveat that I didn't write the code that's there now, and therefore am not really in a position to say!) that it ought to be a straightforward problem to fix-- at least, more straightforward than problem #2.

 

[Daveroski]

Turn SAS off.

Gently tap any direction key once.

As you approach Retrograde turn SAS on again.

Select Retrograde on SAS

Job done.

[Paul Cobbaut]

15 hours ago, Snark said:

It's worth noting that there are two problems with the way SAS works to point in a direction.  They're pretty much orthogonal to each other-- unrelated, the fix would be different for each one.

1. When the navball is at point A, and it needs to go to point B, it often torques in the wrong direction, i.e. not straight towards B.
2. The motion overcompensates:  when it arrives at the target orientation, it overshoots and has to come back again.  Sometimes it takes a few oscillations before it settles down.

Issue #2: You can briefly timewarp to 5x and back to 1x right before it overshoots. This will stop the vessel from rotating past retrograde.

[Tex_NL]

29 minutes ago, Paul Cobbaut said:

Issue #2: You can briefly timewarp to 5x and back to 1x right before it overshoots. This will stop the vessel from rotating past retrograde.

Yes, this will work. But it should not be necessary. Stock SAS pretty much always over shoots and over corrects. MechJebs Smart A.S.S does not. It starts to slow down the motion in time and stops on the mark with near perfect accuracy.
Why does MechJeb succeed where Stock fails? I'll tell you why: poor programming by SQUAD.

Edited July 24, 2016 by Tex_NL

[pandaman]

40 minutes ago, Paul Cobbaut said:

Issue #2: You can briefly timewarp to 5x and back to 1x right before it overshoots. This will stop the vessel from rotating past retrograde.

Yes, I do this too, it irritates me a bit that I need to do it so often though.  Slightly off topic,  but it feels as if they can fix that then the oscillating wobbly rockets on launch would be reduced too.

As for #1,  

13 hours ago, Daveroski said:

Turn SAS off.

Gently tap any direction key once.

As you approach Retrograde turn SAS on again.

Select Retrograde on SAS

Job done.

I do this too, but it's a bit of a pain  when you don't know the direction you need to  turn, prograde/retrograde aren't so bad because you can usually see one of the two, but the maneuver marker can be an elusive beast at times. 

[John FX]

16 hours ago, Snark said:

The motion overcompensates:  when it arrives at the target orientation, it overshoots and has to come back again.  Sometimes it takes a few oscillations before it settles down.

I have found that if you have a small enough craft this effect means sometimes your craft just spins with no attempt to stabilise and if it does the oscillations are around 90 degrees each way and no sign of settling. I`m talking REALLY small, like an octo, two docking ports, a battery and the smallest RCS tank (with RCS thrusters). I use them for mini-tugs to dock other craft.

It would be nice for the SAS code to get a review.

[Snark]

4 hours ago, Paul Cobbaut said:

Issue #2: You can briefly timewarp to 5x and back to 1x right before it overshoots. This will stop the vessel from rotating past retrograde.

Yes, and I do this all the time, which is why it bugs me less than the other issue. #1 strikes me as an easier technical fix, and less easily worked around, thus the wish for them to address it.

[Waxing_Kibbous]

+1 to toggling timewarp on and off to stop the SAS at the retrograde marker before shooting past it, it's a nice little cheat.

[TheDestroyer111]

3 hours ago, John FX said:

I have found that if you have a small enough craft this effect means sometimes your craft just spins with no attempt to stabilise and if it does the oscillations are around 90 degrees each way and no sign of settling. I`m talking REALLY small, like an octo, two docking ports, a battery and the smallest RCS tank (with RCS thrusters). I use them for mini-tugs to dock other craft.

It would be nice for the SAS code to get a review.

Yeah SAS sucks at stabilizing crafts with high control authority. Even more weird is that it wobbles even more if you use SAS to point prograde/retrograde etc.

[OHara]

On 7/23/2016 at 9:36 AM, Snark said:

I gotta say, though, that issue #1 (which the OP brings up) really irritates me, and has done so for a very long time.  Seems like it ought to be a perfectly straightforward piece of vector math to decide "I'm in this orientation, and I need to point in that orientation, and therefore I need to rotate in this direction".  I'd say (with the obvious caveat that I didn't write the code that's there now, and therefore am not really in a position to say!) that it ought to be a straightforward problem to fix-- at least, more straightforward than problem #2.

The interesting bit that makes issue #1 not so easy, is that for general 3D bodies, torque along one direction causes rotation about a different axis. Some axes of the body have higher moments of inertia than others, so a torque between these principal axes cause a rotation about an axis closer to the easier one.  (The concept is the 'tensor of inertia' but I can't find a link with a helpful illustration)

The physics classroom demonstration showing why this is more interesting than you might think, is to take a book and tape it shut.  You can toss it like a pizza so it rotates like an airplane in a flat spin. You can toss it so it rotates along its longest axis of near-symmetry, probably up and down the printed pages.  But if you try to toss it along its mid-length axis of symmetry, it refuses to cooperate and tumbles in some messy way.

I'm not sure if that's the main cause of SAS's roundabout path, but so far it looks plausible.

[kBob]

Maybe more accurate SAS functions could be part of the pilot upgrade.  Say a 4 star pilot finally figures out how to use the SAS controls properly.  I know I sometimes overshoot the markers, but usually I'm better at it than SAS but it took me awhile to get used to it.  So maybe it takes the pilots awhile to figure out how the SAS works and set the correct adjustment knobs.  Alternatively maybe it could be something a say 3 star engineer could do: s/he visits the ship installs the upgrade and then it works great until the ship is lost or decommissioned.

[Stargate525]

The cause of issue #1, as far as I can see, is that the SAS will almost always utilize both pitch and yaw to make a gross orientation shift, even if it doesn't have to. Assumedly because it's faster in the current reaction wheel system to move on the diagonal.* This leads to counter-intuitive movements of the SAS.

 

*As I understand SAS, a reaction wheel with 5 in all directions, can actually move diagonally at slightly over a relative power of 7 (5 on pitch, 5 in yaw, both 45 degrees off of the true direction).

[Alshain]

On 7/23/2016 at 8:29 AM, Xyphos said:

Enhanced Navball is now Redundant and IMHO, obsolete.

Except for the ghosting feature, the stock navball icons suck.  So it's not entirely obsolete, just 95%.  I do hope Kitoban comes back and fixes that part of it.  I tried, couldn't figure it out.

 

On topic, I agree and I wish the SAS were smarter.

Edited July 26, 2016 by Alshain