Very long scene changes with outer-planet probes

[lpgagnon]

per discord discussion starting at https://discord.com/channels/319857228905447436/480397772248580098/745633507409395753

Seen with both Gallai and Galois; no reason to think it's a new issue.

I'm seeing excessively long scene changes; initially thought it was a consequence of #2400, but after reducing the save to a single, recently-launched vessel, I was still seeing several-minute scene change times. Removing Principia eliminates the delay, indicating Principia plays some role in the issue. Removing that last vessel also eliminates the delay, suggesting the issue is caused by some property of specific vessels.

Initially seen on a ~100MB save; saving took ~30s, loading and scene changes both took over 3 minutes.

Sample save linked. 7MB, with a single vessel: a probe to Neptune, only a couple of days after launch. No flight plan currently configured; a flight plan was used to plot a ~7-year transfer. There's a good chance I cranked up the plan duration to 10,000-days at some point while fiddling with it. Scene changes take over 5 minutes; nothing appears in glog/INFO.log, and there's a full 5-minute gap in KSP.log with nothing getting logged.

https://drive.google.com/file/d/1kle4M75-KHUB4aH-UKXAmEgWU0TwktJl/view?usp=sharing

[pleroy]

Thanks for opening this issue. I probably won't have time to look into it until next week, though.

[lpgagnon]

workaround and possible clue: turning Hack Gravity on and off while the vessel is loaded appears to clear out whatever's broken.

... but trying to do this to the 6 outer-planet probes I had in the original save didn't help. Could mean the trick won't work if there's more than one "guilty" vessel. (could also mean I fat-fingered something; at 5 minutes per scene change, I'm not going to try repeating the experiment)

[pleroy]

On my machine it takes 5 min 38 s to load that save. Not good. What I found so far:

• The Principia part of the save is 247 KiB so it's tiny and it will read in seconds.
• The first thing that happens is that the ephemeris gets prolonged from 1950-01-01 to the current time of the game, viz. 1962-01-01. That part takes 19 seconds. This is consistent with what I would expect: we typically do 30 years/minute.
• Then it reads that vessel. Surprise! That vessel wants the ephemeris to be prolonged to 2135-06-22. Let's go for 173 years. Sure enough, that's more than 5 minutes.
• The part of the vessel that needs this super-long prolongation is the prediction. The save really does have a prediction of 173 years.

So, question for @lpgagnon: does the vessel really have such a long prediction at the time the save gets created (in which case you get what you deserve)? or did you shorten the prediction prior to saving and somehow that was not taken into account (in which case I have a bug)? In other words, I am curious to know how we got into that state.

[lpgagnon]

The vessel was saved with prediction settings at the minimum values. I'm not aware of ever having asked it to be that long, either; longest I recall is asking for a 10,000-day flight plan. It's possible I fat-fingered something longer at some point.

[pleroy]

Would it be possible to have a journal? I seem to remember that you were at some point able to reproduce the issue semi-deterministically. As things stand there is no obvious reason why we would save a super-long prediction when the settings are at the minimum values.

[pleroy]

@lpgagnon: Do you still have INFO logs corresponding to that save? That would help a lot.

[pleroy]

I have a theory.

As we know, the length of the prediction is determined by the tolerance and the number of steps selected in the UI, which are then passed to the adaptive integrator. The final duration of the prediction is autonomously determined by the integrator, but generally the straighter the prediction, the longer.

Now consider a user planning a trip to, say, Pluto. The user may set a large value for the number of steps to get a good understanding of where the vessel will go. Since the trajectory is rather straight during interplanetary travel, the integrator will need a limited number of steps to reach the outer planets. But it is its duty to reach the number of steps selected by the user. So it will keep extending the prediction, and at the same time the ephemeris. For all we know, it may not even reach the desired number of steps. Onwards towards the Oort cloud!

This is all fine because the prediction computation is asynchronous. Maybe the user is tuning a flight plan, or went for a coffee, During that time, the prediction and the ephemeris are extended and from time to time a new segment is drawn at the end of the prediction, but none of that is getting in the way.

Then the user does a scene change. The prediction is part of the save. It compresses well thanks to downsampling and zfp because it's mostly a straight line, so the save is not big. Still, the prediction ends (in the case at hand) in AD 2135. When the save is reloaded, the entire ephemeris must be recomputed. Amusingly, that takes exactly the same time that the user took for drinking a coffee because in both instance the ephemeris prolongation is the limiting factor.

This would explain a lot of complaints from users trying to plan interplanetary missions.

The fix is probably to avoid saving the prediction and recompute it on scene changes. At least it's the best we can do until #2400 solves all the problems.