kRPC: Control the game using C#, C++, Java, Lua, Python...

kRPC: Control the game using C#, C++, Java, Lua, Python...

7.8k Downloads

body.epoch is always zero

jj314 opened this issue ยท 5 comments

commented

What happened?

While working fine for vessel orbits, the epoch on body orbits always is zero.

How can someone else reproduce it?

import krpc
import numpy as np

conn = krpc.connect(name='foo')
space_center = conn.space_center
for body in space_center.bodies.values():
	orbit = body.orbit
	if orbit:
		print(f'{body.name} expected epoch {space_center.ut}, actual {orbit.epoch}')

What is your environment?

krpc 0.5.2

Anything else we need to know?

No response

commented

I wouldn't consider this a bug. Body orbits are defined by their position at UT=0 and they do not change (except with Principia which is currently not supported, see #767; though with Principia the typical orbital elements are not accurate anyway)

commented

+1 for not considering this a bug.

Also, we simply return what the underlying KSP Orbit object has in its epoch field: https://github.com/krpc/krpc/blob/main/service/SpaceCenter/src/Services/Orbit.cs#L234
So if this is a bug, I'd consider it a KSP bug.

commented

I wouldn't consider this a bug. Body orbits are defined by their position at UT=0 and they do not change

This is not quite so. The true anomaly does change. When you retrieve an orbit, the true anomaly is always the up to date one, not the one at ut=0. So the epoch does not match the true anomaly.

I think a fix might be to just set the epoch to the current ut, when retrieving the orbit of a body. I do this on the user side right now as a work around.

commented

The true anomaly is not defined in terms of the epoch. The only thing the epoch is used for is the mean anomaly at epoch, as described in the docs. Perhaps this should be documented better on the true anomaly field.

commented

@ThePuzzlemaker Thanks for the clarification. That explains everything.