Plotting Frame's interaction with stock SAS is inconsistent

[scimas]

There is the already known problem of the markers on navball not matching with the actual direction when in the Target frame of reference. But apart from that, another inconsistency occurs when loading from a quick save (Hold F9).

What happens is that on a game load (normal load, you just started the game and are launching a ship, no quick loads so far) if you use the SAS in a special mode (prograde, normal etc. anything other than basic stability assist), the ship always aligns with the SOI body's markers, ignores the plotting frame (apart from change between inertial and surface fixed frames. Those do affect SAS correctly). So if I'm plotting in Mun - Kerbin barycenter frame, and want to burn in KMB prograde, I have to do so manually. Because the ship will keep pointing in Kerbin / Mun prograde direction, whichever SOI I happen to be in.

Now with your ship in space, do a quicksave (F5) and quickload (F9). Now the SAS will be faithful to the plotting frame, aligning with the markers shown on navball. And not just for that one ship, for every ship you take control of in that KSP session. Quit KSP, come back, and it will be ignoring plotting frame again.

I didn't find these issues documented anywhere. So, review of steps to reproduce:

1. Launch KSP and start a new game / resume previous game.
2. Launch a new vessel / take control of previously launched vessel. Observed behaviour: SAS ignores current plotting frame beyond inertial / surface fixed of current SOI.
3. While in control of a vessel, do a quicksave and quickload (F5, hold F9) Observed behaviour: SAS is faithful to the current plotting frame.

That said, I'm not sure which behaviour would be preferable. On one hand, I want to be able to properly execute nodes that are in a non stock frame. But on the other hand, I also want the ability to execute nodes in one frame while looking at the results in another frame (burn in KCI, looking at Mun periapsis in MCI). This isn't a big problem in sandbox mode where the manoeuvre mode of SAS is unlocked, but can be frustrating in career mode.

[eggrobin]

Thanks for the detailed report.

There is the already known problem of the markers on navball not matching with the actual direction when in the Target frame of reference.

Do you mean fact that the markers display the Frenet frame of the trajectories in the target LVLH frame as we discussed on the forum thread last year? If it is behaving as described in that post, it is working as intended (a bit puzzling at first when one is used to the way stock KSP does things, but the Frenet frame is the only thing that nicely generalizes to arbitrary weirdly-shaped trajectories).

What happens is that on a game load [...] the ship always aligns with the SOI body's markers, ignores the plotting frame. Now with your ship in space, do a quicksave (F5) and quickload (F9). Now the SAS will be faithful to the plotting frame

Thanks for the careful analysis; I had never managed to figure out how to deterministically reproduce this bug, which made investigating it extremely frustrating. Hopefully I will now be able to figure out what is going on.

That said, I'm not sure which behaviour would be preferable.

For what it's worth, the intended behaviour is that the following things should always be consistent with the plotting frame:

• the navball speed display should show the current speed of the vessel in the plotting frame;
• at a fixed position in the plotting frame, the navball should have a fixed orientation in the plotting frame;
• the navball markers should display the Frenet frame of the trajectory in the plotting frame;
• the SAS should should guide to the markers.

The reason is that this is what works best in sandbox mode: it means that all these frame-dependent indicators use the same frame, making things less confusing, and, as you point out, it is always possible to use the flight plan to burn in a direction defined in some other frame.

When career mode makes things inconvenient, we treat that as a separate issue, but we always design for sandbox mode.

Apologies for the delay, it seems this issue fell off my radar when I went on vacation this summer, and only now did a bug report on the forum thread bring it back to my attention.

[eggrobin]

I had never managed to figure out how to deterministically reproduce this bug

Unfortunately, I am unable to reproduce the issue by following the given reproduction steps with Εὔδοξος, either in 1.3.1 or 1.5.1: on normal game load (either starting a new game or loading one), launching a new vessel or taking control of an existing one, the SAS follows the plotting frame (quicksaving and quickloading have no further effect).

Nevertheless, the bug still exists: we just had a report to that effect on the forum thread.

[scimas]

I haven't played KSP much recently, so I maybe remembering some things incorrectly.

Do you mean fact that the markers display the Frenet frame of the trajectories in the target LVLH frame as we discussed on the forum thread last year?

No, the forum thread was just me getting confused. From what I recall, in the LVLH frame, the velocity with respect to the target wouldn't match with the (+/-)tangent markers on the navball. Even when using kOS and telling it to point in the direction of my:Velocity - target:Velocity would result in the vessel pointing in a direction slightly different than the tangent markers on the navball. Although I would really need to test this again to confirm.

Unfortunately, I am unable to reproduce the issue by following the given reproduction steps with Εὔδοξος, either in 1.3.1 or 1.5.1

I was able to reproduce it reliably when I opened the issue. Can you let me know the Principia version at the time of the issue? I still have principia releases from Christoffel, I can try to recreate it in that version and then the current one. Let's see if that works.
Edit: It was probably Dedekind. I will try with that one first.

[eggrobin]

in the LVLH frame, the velocity with respect to the target wouldn't match with the (+/-)tangent markers on the navball. Even when using kOS and telling it to point in the direction of my:Velocity - target:Velocity would result in the vessel pointing in a direction slightly different than the tangent markers on the navball.

Ah, I think you see what you mean. This is intended, but fairly subtle: the LVLH frame is a rotating frame, so that your velocity in that frame is not just the difference of the KCI velocities.

As an example, consider a situation where the target is on a circular orbit around Kerbin, and you are on an orbit at the same altitude, in the same plane, and in the same direction, but 180° out of phase from the target (i.e., you remain directly opposite the target on the orbit). In that case, the kOS my:Velocity - target:Velocity will be twice your orbital velocity, as the ships are moving in opposite directions with respect to Kerbin. However, in the LVLH frame, which rotates with the target, neither ship is moving: the markers on the navball will indicate whatever tiny deviation there is from the ideal "same orbit" setup, and the navball speed display will indicate a very small speed.

I was able to reproduce it reliably when I opened the issue. Can you let me know the Principia version at the time of the issue? I still have principia releases from Christoffel, I can try to recreate it in that version and then the current one. Let's see if that works. Edit: It was probably Dedekind. I will try with that one first.

Yes, I think it was Dedekind.

[scimas]

However, in the LVLH frame, which rotates with the target, neither ship is moving: the markers on the navball will indicate whatever tiny deviation there is from the ideal "same orbit" setup, and the navball speed display will indicate a very small speed.

Ah, I see now. Learn something new everyday.

So, I tried to reproduce the bug in 1.3.1 with Dedekind and 1.5.1 with Εὔδοξος. Both work as I wrote in the original post. The save only has principia installed, no other mod and reproduced with fresh KSP installs. The games were started in sandbox mode, no settings changed.

Start KSP. New Game (sandbox). Build a new vessel.

The craft is very simple. Mk1 cockpit with a parachute, T800 tank and Terrier. Stack decoupler followed by 2x T800 tanks with a swivel. 2x hammer solid are attached to this stage with radial decouplers. (I forgot to save the craft, just launched. Otherwise I would've included it here.)

Launch. Burn enough to get encounter with Mun (so that the barycentric and other frames are significantly different than the inertial frames). Warp far ahead so that the markers are pointing in different directions in different frames. Try to hold prograde with SAS prograde mode. Observe that SAS keeps pointing in current SOI inertial prograde direction.

Hit quick save, quick load. Now the SAS works as per current plotting frame.

The OS is Windows 10, if that makes any difference.

saves.zip

[eggrobin]

OK, by following your instructions, I have reproduced it, but only via the "launch a new vessel" path; taking control of a previously-launched vessel (such as the vessels in the save you linked above) results in a working SAS for me. Going to the space centre and then back to the vessel via the tracking station fixes the behaviour of the SAS. Further, I do not need to quit KSP to reproduce the behaviour again, only to launch another vessel.

[eggrobin]

Weirder still: launching to orbit reliably reproduces the bug, but launching to a suborbital trajectory does not.

[eggrobin]

Weirder still: launching to orbit reliably reproduces the bug, but launching to a suborbital trajectory does not.

Nevermind; it seems a critical factor in reproducing this bug is whether SAS is turned on before launching: if SAS is turned on prior to launch, the SAS will keep its stock behaviour and thus ignore the plotting frame; if it is turned on after launch, it will follow the plotting frame.