Open bvulich opened 10 years ago
are you serious? what a pain in the butt :P
Thank you very much for letting us know!
This is not a bug - this is mean anomaly AT EPOCH, or at time=0, which is constant. What changes, is true anomaly.
Thank you for clearing up what at epoch meant. If that is the case, then there is still an issue with how this value reports for the current vessel, as I remember that value changing over time. Also, it seems that the time that KSP considers to be the epoch is different for different vessels, being the time when that vessel was last active.
I do not know if this is still the case, as I haven't had KOS installed in quite some time and I don't have time to test it right now.
It would be very helpful to have this value be measured in a consistent way across vessels, as it is helpful for determining the relative position of two vessels in the same orbit, which is what I was trying to do when I first encountered this.
You are right - I just checked, and the value changes in time, even without switching vessels. So this turns out to actually be a bug, but different than you initially posted. Likely, this suffix returns the wrong orbital parameter.
All kOS is doing is returning orbit.meanAnomalyAtEpoch directly from SQUAD's own code, modified for degrees instead of radians. If it's changing, it's changing because SQUAD keeps changing what it's returning. What actually is this then if it's changing?
If it's changing, then what the heck was SQUAD thinking naming it "meanAnomoalyAtEpoch". The name is clearly a lie.
Just a thought, without looking into kOS or Squad's code: "At epoch" doesn't necessarily mean "at UT=0"; the epoch can change and is simply the datum relative to which the values are recorded or calculated. IIRC, "epoch" is a field in the persistent.sfs, most likely in the flight state, or each vessel's orbit structure.
In fact, the underlying ksp Orbit class includes a double member epoch
. Looking at the PatchedConicSolver code, it appears that the epoch may vary depending on if it is in transitions and/or . Within the Orbit class, epoch is updated whenever it is updated from state vectors, and also in OrbitDriver.RecalculateOrbit
(I think this is called when you transion).
If you have ever used hyperedit, they also offer the ability to modify the epoch time.
The value for meanAnomalyAtEpoch only appears to be used by the Orbit.UpdateFromStateVectors
method (in the same code that modifies the value of epoch).
I'd say it's safe to assume that Squad is trying to modify the value of epoch and meanAnomalyAtEpoch to keep their math calculations easier. Possibly to reduce the floating point errors as much as possible, since these errors increase as the value gets further from zero. It may also be important with hyperbolic orbits.
If we want, it would be possible to modify the existing suffix, or provide a new suffix, such that you can query the mean anomaly at 0UT. TrueAnomalyAtUT
provides TA, from which you can calculate E, from which you can calculate M (all using methods on the orbit class). This will introduce floating point errors, and is potentially an expensive call (trig functions can be expensive), but would provide a fairly consistent result.
I'm curious what people would use this value for? The best example I can come up with would potentially be to have kOS plot a long duration multi-planet tour of the planets. Even that could use the "current" mean anomaly instead. Is there anything else that might need access to the 0UT mean anomaly?
Without the epoch off of the orbit, isn't meananomalyatepoch completely useless?
I noted in #1665 that the "Epoch" for obt:meananomalyatepoch is based on the same thing that'd be present in a save (and corresponds to the MNA field in a savegame):
Mentioning it here since the two issues are related.
The mean anomaly for ships other than the cpu vessel remains constant over time, when it should vary from 0 to 2pi as the other vessel orbits. It appears to be fixed on the value it was when the other vessel was last active. If I switch to the other vessel and back, it updates the value, but otherwise it remains constant.