Packed vessels position isn't reliable from FixedUpdate !

[Gotmachine]

So, I've been struggling with something for many hours, so maybe someone over here can help me :

I need to get the direction vector of my vessel target, which is another vessel that implement ITargetable. To do so, I use this :

target.GetTransform().position - myvessel.transform.position

It works fine in the following situations :

• Both vessels are in the scene and NOT packed (they are close enough to each other and I'm not timewarping)
• Both vessels are in the scene and packed (happens when I'm timewarping)
• My vessel if either packed or not and the target vessel is unloaded (not in the scene)

But in the situation where both vessels are in the scene, my vessel is not packed and the target vessel is packed (when the distance is greater than the physics-load distance, I believe this is set to 200 m by default), the direction vector I get is slightly offset, and the offset seems to gets worse the further my vessel is from the target vessel. I noted that the offset error seems to depend on the distance to the mainbody (or is it the orbital velocity ?) : it is barely noticeable in LKO but I get a 30-40° error when orbiting the sun.

What is strange to me is that every stock value that I could find (including FlightGlobals.fetch.vesselTargetDirection, GetWorldPos3D, Orbit...) are giving me the same wrong result, but somehow the navball target marker isn't affected by the issue and is correctly updated with a consistent target direction. I guess there is some shifting reference frame correction to do, but I can't pinpoint it. Does someone have a clue at what may be happening ?

Edit : @sarbian MechJeb is experiencing the exact same issue when using SmartASS. To reproduce, using the stock vessel mover cheat, rendez-vous a first vessel with an asteroid in sun orbit, then rendez-vous a second vessel with the first, this will place the two vessels 150m apart. Activate SmartAss and target the other vessel, everything should be fine. Then burn a bit to get further from the other vessel. As soon as the other vessel become packed, watch your attitude suddenly experience a 30-40° offset from the stock target navball marker.

Edit2 : Okay I think I found why : it seems that for On Rails vessels, the vessels state is updated in Update(), not in FixedUpdate() (!?!#%!), so if you try to acquire another vessel position from a vessel FixedUpdate, you may be reading the values FROM THE LAST FRAME... I need to do some more testing, but the TCA autopilot is not affected by the issue and happens to be updating its autopilot directions in Update().

Moreover, if I substract the orbital velocity of the target to the direction (essentially computing were will be the target in the next frame), I get the correct direction :

target.GetTransform().position - vessel.transform.position - (target.GetObtVelocity() * TimeWarp.fixedDeltaTime)

Also, this description of the VesselPrecalculate Class from the API docs seems to confirm that packed and non packed vessels may not get their position update at the same time, but I have trouble understanding the exact implications :

Quote

This is the counterpart to FlightIntegrator. As FI runs after most other FixedUpdate things run and finally applies all physics changes for the frame prior to passing off to the integrator, this runs at the start of the frame and precalculates the values for the fixed frame, like CoM, vessel velocity and angular velocity, the force of gravity (and any drift compensation), vessel acceleration/G forces, and the like. It also will set position and rotation when on rails, or if off rails recompute the orbit based on those stats calculated. It handles being off rails specially: it will do its final update for any given UT in Update() rather than FixedUpdate() so the calculated pos/vel/etc stats for the vessel are correct for visual display. When on rails, nothing changes in PhysX integration so there is no need to run later. Note that so long as this is running, it tells the vessel's OrbitDriver not to do anything, and instead directly calls OrbitDriver's Update methods. This is because when off rails, orbit updating needs to occur after we determine vessel CoM and velocity, whereas when on rails, we need to update from the orbit before we calculate CoM and velocity.

 

Edited April 14, 2018 by Gotmachine