add ship:compass, ship:pitch, ship:roll.

[Dunbaratu]

People have been asking about these for a while and we may as well just do them as shown in the title. It's simple and quick.

compass = navball compass heading.

pitch = angle above horizon (90 - VANG(ship:up,ship:facing:forevector).

roll = angle of deflection between ship:facing:topvector and ship:up, with sign to distinguish left and right.

There are issues with what to return in the case of gimbal locks. (What is the "compass" and "roll" when going straight up? There are an infinite number of combinations of compass and roll that would result in the same orientation when going straight up.

[erendrake]

is this something we could provide easily with a kerboscript function?

[Dunbaratu]

yes but.... I felt as if some of these are silly to do in slow user code. (i.e. why are SHIP:UP, and SHIP:NORTH first-class citizens, but SHIP:EAST isn't?)

[space-is-hard]

Could you return 0 for both roll and compass when abs(pitch) > 89.5? Better yet, have the "bottom" of the ship return the compass heading when the pitch is above that limit, that way the user can orient their rocket to pitch down to that compass heading. It would be useful for the initial stages of a launch.

[Dunbaratu]

I'm tempted to have it track a memory of the previous compass heading it had back when it was readable and not gimbal locked yet, and then have it give you the roll that would necessarily go with that heading. Thus if you pitch up to the point of lock, it assumes you want to "think" in the orientation you were just in a moment ago.

[erendrake]

The reason i think it would be interesting to have them in user code it to show that they are simply transformations of the data they already have. how many instructions are we talking about here?

[Dunbaratu]

hmm. well it would be a nice thing to expose as a start of a "standard library".

[Kemp-J]

As someone who wasted an afternoon trying to figure out why SHIP:FACING:PITCH was giving nonsense (until I finally found the issue report here), I wholeheartedly agree with having values available that directly relate to the navball readings.

Maybe the documentation should also be updated to reflect that the existing values don't do what might be expected?

[jonfortescue]

I think directly exposing the values would be nice, but I echo Kemp's comments on updating the documentation. I think the most critical thing right now would be to clear examples of calculating these values.

[crupeng-1]

Is there a way to calculate the ship:compass? Since as of yet it isn't implemented in KOS.

[nuggreat]

Yes there is see lib_navball.ks and is associated documentation and example . While there are simpler methods to get these values than the methods employed by lib_navball they are far less general in application.