Harry Twinotter

I noticed this one as well.

It sounds similiar to a bug I reported. Like Turbo Ben suggests, try doing a quicksave then a quickrestore to see if the Mun appears (it does in my test case).

KSP2 v0.1.2.0 Windows 10 Intel Core i9 processor. Nvidia RTX 2080 Super. Description of the bug. The Mun is not visible on the Flight screen during a flyby after entering the SOI of The Mun. Restoring to a quicksave made at that point makes The Mun visible as expected. Steps to Replicate - Build a vessel capable of reaching the orbit of The Mun when launched straight up. - Target The Mun. - Launch straight up when The Mun has passed overhead and set by 30 degrees ie do not use a parking orbit or maneuver plans. - Cut throttle when the Ap of the launch trajectory has reached the orbit of The Mun - this is the point of the future encounter. - From the Map screen, timewarp until the vessel has entered the SOI of The Mun. - From the Map screen, timewarp until the vessel reaches the Pe. - From the Flight screen, look around for The Mun - it should be clearly visible at that point. Restoring to a quicksave made at that point makes The Mun visible as expected. No mods Other Notes / Screenshots / Log Files (if possible..) - I have a YouTube video which shows a flyby of The Mun for Patch 2. I can add the URL if neccessary (I am not familiar with this Forum's policies about self-promotion). - A related "bug" (if it is a bug) is the encounter with the SOI of The Mun is not displayed after the trajectory reaches the orbit of The Mun, the SOI exit point IS displayed after the vessel reaches the SOI. It is likely the SOI info including the image of The Mun is not being loaded correctly.

Thanks. I assumed the convention of the Z axis being the direction the vessel points in was also used in KSP. Apparently not - I am a bit surprised but I am sure they has their reasons. This explains why they need to rotate by Euler(90,0,0) in KSP, this is to align the way the vessel is pointing with the Z axis that the LookRotation defines (the lookat axis is the Z axis) . This is not required in kOS as it has already been done, the doco says the vessel "facing" direction is aligned with the Z axis. I hope I got all this straight, the semantics are a bit wobbly in natural language, it might have been easier expressing it in mathematics, if I knew enough mathematics :-)

OK I think I have worked out why the code gives the results it does. Once I found the error in my vessel (a misaligned MechJeb control pod), I started to get consistent results. The "magic" works like this (if I am not wrong of course): 1. Create an orientation where the vessel's pitch,roll and yaw are said to be zero. Call this the reference orientation. 2. Create a relative rotation by multiplying the reference orientation with the inverse of the vessel's orientation. In effect this relative rotation then contains the roll, pitch and yaw of the vessel relative to the reference orientation. 3. Take the inverse of the relative rotation. This has the effect of converting the relative rotation's roll, pitch and yaw back into absolute terms which can then be simply read from the X,Y,Z values of the quaternion. a. I get confused because quaternions are used to store both rotations and orientations. That is because rotations and orientations are the same thing, it's the context/semantics that is different. b. I still have not worked why Euler(90,0,0) is necessary in the MechJeb C# code, but is not necessary in kOS. I am aware that kOS "tweaks" some of the Unity API details, so maybe this is the explanation.

Changing the orientation of the MechJeb2 module does appear to make my code return the correct values in all cases, as long as I removed the r(90,0,0) from the multiplication. I better test this again more carefully, I am tired. I will report back in a day or so.

Thanks - that makes a lot of sense. I must test that, perhaps my vessel has a misaligned control part somewhere? Using MechJeb, kOS and a command pod means I have 3 potential control points on the vessel maybe. It won't take me long to check. I remember the NavBall going nuts if I built a rover wrong.

Thanks. I did get the impression the multiplication order was right to left, not left to right (at least when it come to applying rotations to orientations). The Unity doco is ambiguous. And I get that context is everything, you need to get your head around whether the quant you are interested in is a rotation for rotating a real object (hence the quants coordinates have no meaning in world space), or if the quant is an orientation of a real object and the coordinates do have a meaning in world space.

Disclosure I also posted this question on the kOS Reddit. I was wondering if anyone can explain to me what the quanterion multplication is doing in the follow code from MechJeb2 ie how the rotations produce the desired result: rotationSurface = Quaternion.LookRotation(north, up); rotationVesselSurface = Quaternion.Inverse(Quaternion.Euler(90, 0, 0) * Quaternion.Inverse(vessel.GetTransform().rotation) * rotationSurface); What appears to get returned is the pitch, roll and yaw values like what you would see on the KSP Navball. I am trying to reverse-engineer the code because I am impressed and I want to understand for my education. But I keep getting results that do not agree with MechJeb2 results. The strange thing is my version almost works if I remove the Euler(90,0,0) rotation - the need for this rotation is really puzzling. I do accept that quanterions can give counter-intuitive results so I will accept it just works, but I do need to know the order the rotations are being performed in. BTW why GetTransform instead of the Unity Transform?