Need some help with Vector3d & planet positions

[linuxgurugamer]

I'm trying to get some code working properly which will check for an eclipse.  I'm having some problems, and have narrowed it down to this:

I thought the function CelestialBody.getPositionAtUT(double)  returns the position at the specified UT, but my tests are showing otherwise:

Test code, which find the Mun and prints out the position at 5 days (ignoring the ScaledSpace.ScaleFactor for now):

 foreach (CelestialBody rock in FlightGlobals.Bodies)
                    if (rock.name == "Mun")
                    Hire.Log.Info("currentUT: " + Math.Floor(Planetarium.GetUniversalTime()) + ",   UT of 86400: " + rock.getPositionAtUT(86400));

So, when I go into KSP in a new game and immediately call this, I get the following in the log:

currentUT: 2,   UT of 86400: [251406.665520146, 1014.90997314453, 11656821.4515618]

Then, I timewarp to the next day, and call it, I get the following:

currentUT: 16414,   UT of 86400: [-11489361.4157803, 1014.90997314453, 292532.747668683]

which doesn't make sense.

I then tried using the ScaledSpace.LocalToScaledSpace:

 

foreach (CelestialBody rock in FlightGlobals.Bodies)
                    if (rock.name == "Mun")
                    Hire.Log.Info("currentUT: " + Math.Floor(Planetarium.GetUniversalTime()) + ",   UT of 86400: " + ScaledSpace.LocalToScaledSpace(rock.getPositionAtUT(86400)));

and got the following:

New game:

currentUT: 2,   UT of 86400: [41.7059294153351, 0.269453529015138, 1942.65336378619]

Next day:

currentUT: 16414,   UT of 86400: [-1914.923662531, 0.269453529015138, 48.2014139488716]

Again, they aren't even close.  I would expect that getting the position of a body at a specified UT would always be the same.

So I'm obviously missing something, but no idea what.

Anybody?

Thanks in advance

Edited December 4, 2017 by linuxgurugamer

[MOARdV]

For position in the future, I've used the CelestialBody's orbit :

Vector3d bodyPos = body.orbit.getPositionAtUT(t);

This has been reliable enough for me to solve closest approach iteratively between bodies.

If you just need position "now" between bodies, CelestialBody.position will provide it.

Edited December 4, 2017 by MOARdV
Extraneous characters

[linuxgurugamer]

30 minutes ago, MOARdV said:

For position in the future, I've used the CelestialBody's orbit :

Vector3d bodyPos = body.orbit.getPositionAtUT(t);

This has been reliable enough for me to solve closest approach iteratively between bodies.

If you just need position "now" between bodies, CelestialBody.position will provide it.

 

Well, I'm pretty sure that body.getPositionAtUT just calls that, but I tried it anyway:

foreach (CelestialBody rock in FlightGlobals.Bodies)
                    if (rock.name == "Mun")
                    Hire.Log.Info("currentUT: " + Math.Floor(Planetarium.GetUniversalTime()) + ",   UT of 86400: " + ScaledSpace.LocalToScaledSpace(rock.orbit.getPositionAtUT(86400)));

at UT= 3:

Hire: currentUT: 3,   UT of 86400: [42.4405393536052, 0.269453529015138, 1942.66814631748]

At UT = 16415 (next day):

Hire: currentUT: 16415,   UT of 86400: [-1914.88357933297, 0.269453529015138, 48.9601178307615]

 

These should be the same, since it's asking for the same UT in the future.

So what's wrong?

[MOARdV]

19 minutes ago, linuxgurugamer said:

So what's wrong?

It might be the local -> scaled space conversion then?  I am pretty sure that's not a local space result from getPositionAtUT(), since I've been using the unaltered results of it, (eg here) to compare positions between objects that aren't necessarily in the same SoI.

Isn't local space local to the current body?  If so, it makes sense that the same (body-relative) position will have a different scaled space position after some time passes, although I'm not sure why it'd rotate about 90 degrees like that.

Although you also initially looked at the body.getPositionAtUT, too.

Sorry, I guess I'm not much help.  I can say that comparing two positions using the orbit's getPositionAtUT has been reliable in the cases I've used, but I haven't looked at the absolute output of the values for quite some time, and I haven't used the other methods you mention, so I don't know how they interrelate.

[linuxgurugamer]

11 hours ago, MOARdV said:

It might be the local -> scaled space conversion then?  I am pretty sure that's not a local space result from getPositionAtUT(), since I've been using the unaltered results of it, (eg here) to compare positions between objects that aren't necessarily in the same SoI.

Isn't local space local to the current body?  If so, it makes sense that the same (body-relative) position will have a different scaled space position after some time passes, although I'm not sure why it'd rotate about 90 degrees like that.

Although you also initially looked at the body.getPositionAtUT, too.

Sorry, I guess I'm not much help.  I can say that comparing two positions using the orbit's getPositionAtUT has been reliable in the cases I've used, but I haven't looked at the absolute output of the values for quite some time, and I haven't used the other methods you mention, so I don't know how they interrelate.

The problem is that we are trying to calculate and angle of multiple bodies not disturb and we are getting very strange results