About MechJeb2 versus the World on KSP 1.8 - Part 2

Still on this lsubject about MechJeb2 and now Module Manager, that issued new versions claiming that the offeding DLLs are "outdated", I decided to make some more testing.

This essay is about the new findings about the new subject.

TL;DR: Again, we don't have a problem caused by "outdated DLLs'. They are just the preferred Screaming Victims, as they are more prone to fall due this problem - the same way MM was until recently. The problem is an anomaly on KSP's thread's life-cycle that kills itself when ir receives an unhandled exception sometimes (other times, it does not - appears to be some missing try catches).

Such anomaly is a problem that, besides looking terribly bad, it's not - it's just an annoyance. What made it terribly bad is people deflecting responsibilities by electing scapegoats to save face.

First and for once, this is not a problem on Module Manager. It was being only the messenger. However, I want to dispute the error message:

Again, the problem is not (and never were) about outdated DLL "incompatible" to KSP, MM or MechJeb. The problem is faulty DLLs (being it updated or outdated) borking on some critical sections of the KSP life-cycle, inducing KSP to a crash.

By removing a needed resource, you can induce Stock, Squad made ModuleEngines to crash the game loading the same way:

[LOG 12:44:57.519] FSCoolant not found in resource database. Propellant Setup has failed.
[ERR 12:44:57.525] Module ModuleEnginesFX threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object
  at ModuleEngines.SetupPropellant () [0x000a4] in <394a98b9c7624adc895c04290da62640>:0
  at ModuleEngines.OnLoad (ConfigNode node) [0x000d7] in <394a98b9c7624adc895c04290da62640>:0
  at PartModule.Load (ConfigNode node) [0x001ab] in <394a98b9c7624adc895c04290da62640>:0

And I have a hard time trying to classify ModuleEngines as an "outdated Mod". To make my point, I induced this problem using a MM patch (the full details are on the KAX Issue #6).

Long story made short, I made a part.cfg and a patch.cfg (replicating a configuration I know borks KSP) to be used before any of Squad's owns. Module Manager applies the patch normally, and after it finishes, KSP kills the loading thread while loaded the patched part. Then I restarted KSP, when MM just reloaded the ConfigCache and called it a day, and then the KSP loading thread continued its job and borked the same way. Of course, deleting ModuleManager and recooking that part to incorporate the patch (as Stock parts do), the KSP crashes the same way.

So we have a confirmation of an anomaly on KSP itself. Ok, it's an Elon Musk kind of Anomaly. But yet, just an anomaly :)

Then I made another stunt: installed "my" fork of Firespitter DLLs, that needs KSPe (a lib of mine). But I didn't installed KSPe on purpose, to make the FS DLL to bork on loading and not while its initialization. Guess what? Things kinda worked this time! Of course, FS modules weren't loaded, so they didn't worked - but KSP loaded fine, and the Modules that loaded worked! (and yeah, this was unexpected).

Logs available no KAX Issue #6.

So, and again, I have confirmation that it's not every DLL bork that triggers that Anomaly. The code must throw an unhandled exception on a specific phase of the father's thread life cycle in order to crash KSP.

What again pinpoints Module Manager as only the main involved on the problem due it's popularity. Had I not made a stock module to kill the game loading as above, and then confirmed my hypothesis using my personal forks of the Add'Ons, I would pinpoint MM as the cause of the problem. Now that I know better, I realize that MM was only the preferred screaming victim of a problem on the stack, because before 4.1.2 it was not handling the ReflectionTypeLoadException , allowing it to be raised to it's father thread, that so crashed KSP as I did above.

Again, we don't have a problem caused by "outdated DLLs'. They are just the preferred Screaming Victims, as they are more prone to fall due this problem - the same way MM was until recently. The problem is an anomaly on KSP's thread's life-cycle that kills itself when ir receives an unhandled exception sometimes (other times, it does not - appears to be some missing try catches).

Such anomaly is a problem that, besides looking terribly bad, it's not - it's just an annoyance. What made it terribly bad is people deflecting responsibilities by electing scapegoats to save face.

L., 2019-1116

This article is also published on Forum and it's deeply related to KAX Issue #6.