Definition of Vessel.GetWorldPos3D() seems to be inconsistent

[Dunbaratu]

I was wondering if anyone else can confirm this behavior because it really doesn't seem right and I'm wondering if I'm misunderstanding it.

As far as I can tell, the definition of Vessel.GetWorldPos3D() seems to vary.

Sometimes vessel.GetWorldPos3D() returns the position of the ship's center of mass. Other times it returns the position of the ship's root part.

Can anyone else confirm that I'm not nuts here and this really is the way it seems to work? It makes no sense but it would explain some of the weird behavior I'm getting if it was true.

Basicaly I'm doing this:

arrow vector = ( vessel 2's GetWorldPos3D() - vessel1's GeWorldPos3D() ).

Draw this arrow vector with origin transformed to vessel1's GetWorldPos3D().

And getting a picture of an arrow that is aimed as if it was pointing from vessel1's cockpit to vessel2's cockpit, BUT it's origined at vessel1's CoM instead of vessel1's cockpit so it looks wrong.

Edited September 19, 2014 by Steven Mading

[philotical]

I can confirm, there is cause for confusion..

but I'm not sure it's allways as you describe..

While working on my tractor beam, I found strangest things happening too..

for example the calculated center of mass for an other vessel (parked beside) starts to rotate in weird direction if the active vessel moves..

I'm sure there is a unity-typical explanation around that needs an own documentation to be understood..

My conclusion was "Ohh well" - and still is btw..

If strange things happen with positions and especially rotations, you might not be as nuts as you think and unity might not be as intuitive as it should be..

I know, not very helpfull but maybe comforting..

[Dunbaratu]

Maybe the only thing I can do to bypass KSP's undocumented API is to just explicitly get the Unity Transform of the Vessel's Root part and use that to get its position. Then at least I know I'm getting the same consistent definition all the time.

[philotical]

Maybe the only thing I can do to bypass KSP's undocumented API is to just explicitly get the Unity Transform of the Vessel's Root part and use that to get its position. Then at least I know I'm getting the same consistent definition all the time.

:-D good luck..

optimism is allways good hahah

Unity (transforms/rotation) isn't much better if you ask me - after hours of testing I get it to work too usually - but don't ask me why it works now and didn't before :-)

there is KSP and unity alike for guys with my knowledge. A big mystery in many things..

[Justin Kerbice]

I can confirm, there is cause for confusion..

but I'm not sure it's allways as you describe..

While working on my tractor beam, I found strangest things happening too..

for example the calculated center of mass for an other vessel (parked beside) starts to rotate in weird direction if the active vessel moves..

Maybe because you forgot one important fact: in KSP, universe is centered on the active vessel, so positions of everything else change as the active vessel move/rotate.

(seen not a long ago in an Harvester explanation on floating point precision limitation).

[Dunbaratu]

Maybe because you forgot one important fact: in KSP, universe is centered on the active vessel, so positions of everything else change as the active vessel move/rotate.

(seen not a long ago in an Harvester explanation on floating point precision limitation).

Nope, I knew that. and it's not entirely correct either. The origin point is only *near* the current ship, not directly ON it. When you first come off rails, the origin is right on the ship. As you fly in normal physics time after that, however, the ship drifts away from the origin.

But in any regard, it wouldn't matter because I'm getting the relative *difference* between the two vessel's position readouts, and setting the tail of the arrow at the vessel1's position, so it should work regardless of whether vessel 1's position is (0,0,0) or something else.