NRE Spam in Certain Flight Modes after Flight Loaded from Tracking Station

[toadicus]

Found what may be a FAR bug when loading up my (moderately-heavily modded) career save with Glauert last night. In general, it looks like a failure during FARGUI startup (perhaps a race with FARSettingsScenarioModule construction specifically) is cascading into various bits of the GUI which eventually results in per-physics update NRE spam.

Lightly-pruned log file here: http://ksp.hawkbats.com/20150713-KSP_log-FAR-NRE.xz

HTH

[ferram4]

Can't reproduce just loading up a craft. Need more specific reproduction steps.

[toadicus]

Full conditions go something like this:

• KSP is running in Linux, 64-bit.
• Save was old; started in 1.0.2 with FAR 0.14 and variously upgraded.
• Save was Career Mode.
• Save was moderately-heavily modded; lots of plugins to start up, a few of them noisily.
• Craft was old(er than Glauert); probably built under similar FAR 0.14.1 in KSP 1.0.4.
• Craft was on a hyperbolic trajectory past Duna when it was loaded.
• Loaded craft directly from tracking station without ever visiting the editor or taking any other route to flight mode.

This seems like something that probably isn't easily reproducible without a pre-existing condition that exhibits the problem. I can't reproduce it in a simple way either.

That said, it seems pretty clear that it is a race condition, given that:

• FlightGUI depends on constructing StabilityAugmentation to Start (FlightGUI.cs#L77)
• Constructing StabilityAugmentation depends (StabilityAugmentation.cs#L262) on FARSettingsScenarioModule.instance being pre-set (FARSettingsScenarioModule.cs#L78).
• In the log, FARSettingsScenarioModule happens after (log line 8813) FlightGUI tries to Start (log lines 8672-8676). See also FlightGUI.cs#L111

Since ScenarioModule startup and VesselModule startup are probably both invoked via coroutines (or perhaps just arbitrarily depending on the order and expediency with which Squad adds the MonoBehaviours), there is no guarantee of orderly startup in a situation containing many such items.

If you'd prefer, I can try to provide more specific steps by removing mods until the problem doesn't happen. But, I'd wager the problem is actually related to the number of mods using either ScenarioModule or VesselModule objects and not to the mods themselves.

FWIW, the follow mods in my install use ScenarioModules:

./KerbalConstructionTime/plugins/KerbalConstructionTime.dll
./TriggerTech/KerbalAlarmClock/KerbalAlarmClock.dll
./UmbraSpaceIndustries/LifeSupport/USILifeSupport.dll
./FerramAerospaceResearch/Plugins/FerramAerospaceResearch.dll
./AsteroidDay/SentinelMission.dll

These ones use VesselModules:

./ModularFlightIntegrator/ModularFlightIntegrator.dll
./FerramAerospaceResearch/Plugins/FerramAerospaceResearch.dll

[toadicus]

Found another piece of the puzzle looking back over the log. Turns out, that specific load in question completely skipped the SpaceCentre/TrackingStation scenes, meaning FARSettingsScenarioModule hadn't had its usual chance to set instance before Flight. I think I had restored something from a hacked-up quicksave after a different mod issue or something; I'd forgotten that detail.

Guessing that's probably a somewhat more-esoteric circumstance than you really need to support; I'll verify tonight if the problem disappears after a normal Menu->SpaceCentre->[Other]->Flight startup sequence.

[ferram4]

Since I haven't been able to reproduce this in a long time, I'm assuming that this has likely been fixed somewhere along the way, and so I'm closing this issue.