Kerbal Space Program

I do have Kerbal Engineer as you can see in the screenshot, and the orbit is at very low eccentricity, but I didn't realize this until after you mentioned it since it was not an objective of my flying at the time. I wouldn't classify this sort of flying as "incredibly hard" without mods since jitteringly low eccentricities can easily be done by equalizing apoapsis and periapsis altitude from the Map view. Polar orbits are a bit harder since the last little bit can only be done by observing Free camera and Navball rotation speeds at polar passage.

The actual 227 part monstrosity: nuthin'. I'll start testing the mods maybe tomorrow. I don't know if we should kill it, since most of the problems I've observed in Kerbal Engineer to date have been fed to it from the API (the most irritating being bad horizontal speed.)

Thanks for your work on this, it really is appreciated.

From your trials and tribulations during testing this I can't help infer that the problems are in fact arising from near exact orbits, and therefore floating point jitter or divide by zero errors. As I pointed out initially, these are extremely hard to achieve during normal gameplay in stock. The progression of this issue does appear to confirm the use of mods can introduce variables that are hard to reproduce in a stock game.

The behaviour is unwanted and potentially game breaking (even if it is rare in stock) so ideally needs some attention. This issue will remain open as it serves the dual purpose of highlighting both points above. This will also be forwarded to the developers as feedback.

As a footnote:

We are extremely interested in any reports of this problem in a stock game. Logs and (clean) savegames are very welcome, and can be used as compelling evidence for a higher priority.

Featherwinglove, your comment about suspecting Kerbal Engineer led me to do further testing (I've been encountering it on my installs as well), and it is KER -- in particular, the "time to atmosphere" readout. It's not installed on the orbital panel (or any panel) by default, so these errors are so rare because it's only people with custom HUD or panel settings that are at risk. Furthermore, the error only occurs under these conditions:

1. Time to atmosphere is installed on a panel or HUD which is open/viewed.
2. The "orbit" is entirely within the atmosphere (the error spam stops as soon as the apoapsis is above the atmosphere).

I see from the code (https://github.com/CYBUTEK/KerbalEngineer/blob/master/KerbalEngineer/Flight/Readouts/Orbital/TimeToAtmosphere.cs) that KER checks to make sure that the periapsis is inside the atmosphere, to stop it from asking for a time that doesn't exist (i.e. it asks when the orbit reaches the radius equal to the edge of the planet's atmosphere), so it probably also needs to check that apoapsis is outside the atmosphere. I'll pass the word along to the KER devs, and we'll see if this clears things up. EDIT 2: Made the change on my end, it works, pull-request is in.

If there is a "stock bug" here, it's probably the fact that orbit.TrueAnomalyAtRadius(radius) isn't happy when the orbit doesn't actually contain that radius (EDIT: and maybe doesn't have the built-in sanity checks to test for that case?), but in that case, NaN sounds like a perfectly reasonable answer -- probably the only thing that needs to change is a clearer log entry explaining what's going on. Maybe something like "requested TrueAnomalyAtRadius for radius not in orbit", with details on the orbit, requested radius, and a stack trace to see where the offending call was made?

From your trials and tribulations during testing this I can't help infer that the problems are in fact arising from near exact orbits, and therefore floating point jitter or divide by zero errors.

This is clearly not the case here, as I stated in comment # 2 This issue is occurring before I have achieve any kind of orbit, let alone a precise one.

As I pointed out initially, these are extremely hard to achieve during normal gameplay in stock.

This is a myth, and you are doing a disservice to the KSP community and developers by perpetuating it. A perfectly circular orbit can easily be achieved by bringing your vertical speed to zero and making your periapis and apoapsis equal with no mods and a level 1 tracking station in career mode. If you find it "extremely hard to achieve", it's because you're not a very good pilot.

The progression of this issue does appear to confirm the use of mods can introduce variables that are hard to reproduce in a stock game.

That I agree with. I'm almost surprised you didn't mark this issue as mod-related. I guess you didn't because of so many issues that mods have exposed (horizontal speed and latitudes reported by the stock API showing up in MechJeb and KER.)

I'm in a break from KSP at the moment, which is why I haven't updated this issue recently.

Kerbas_ad_astra wrote:

Featherwinglove, your comment about suspecting Kerbal Engineer led me to do further testing...

You're awesome! I'm tempted to ask for your Reddit, Voat, and Youtube overviews so I can throw you a bunch of random votes. Thanks for your hard work.

It's been a while, but if I recall correctly, this particular issue was caused by a call (in Kerbal Engineer) to orbit.TrueAnomalyAtRadius(radius) with a "radius" that was higher than the orbit's apoapsis (which does not exist). I contributed a sanity check to KER to stop it from making the call, but I just made a custom version with the fix removed, and the "dT is NaN" messages are still made. I don't consider this an unreasonable answer, but maybe TrueAnomalyAtRadius should have some sanity checks of its own, and put a more verbose message in the log than "dT is NaN!" if they fail. Maybe something like "Orbit.TrueAnomalyAtRadius(radius): radius > orbit.apoapsis" (or "radius < orbit.periapsis") and a stack trace?

It's true that it's been fixed on KER's end (since 1.0.19.1), but it may be worthwhile (I'd certainly suggest Squad consider it, at least) to add some logic to the stock method to provide more information in the log when bad calls get made.

I agree. This KER bug being reported and resolved here is a good indication of that. The lag and log output had me confused enough that I didn't think it had anything to do with mods