About MechJeb2 versus the World on KSP 1.8
I'm seeing a lot of drama about MechJeb2 lately. So I decided to check it.
This essay is about my findings about the subject.
TL;DR: "Outdated" Add'Ons are not the problem. They never were. They were used as scapegoats to justify problems deeper on the stack, at the same time deflecting the responsibility for fixing the problems - what ends up perpetuating them.
We are in a mine field. Deactivating only the visible mines does not solve the problem.
First and for once, this is not a problem on MechJeb. It's not a problem on (old) Firespitter neither. It's something deep inside the stack.
To the moment, what I can confirm is that an Exception happening on a very special moment inside the runtime renders the Reflection unusable. In the past, I had misdiagnosed the problem reducing it to a failed DLL loading, but now Firespitter gave me evidence that there are more triggers inducing this misbehaviour, as there're no DLL failing to load on this case (it was shaders failing to be loaded!).
In a way or another, FIrespitter borking lead to MechJeb borking. And MechJeb borking leads to the Expansion borking on loading the DLCs:
[LOG 00:33:07.191] Expansion makinghistory detected in path /Users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/SquadExpansion/MakingHistory
[LOG 00:33:07.191] Expansion serenity detected in path /Users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/SquadExpansion/Serenity
[EXC 00:33:07.209] ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.
System.Reflection.Assembly.GetTypes () (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0)
AssemblyLoader.GetTypesOfClassesImplementingInterface[T] () (at <394a98b9c7624adc895c04290da62640>:0)
Expansions.Missions.MissionsUtils.InitialiseAdjusterTypes () (at <394a98b9c7624adc895c04290da62640>:0)
Expansions.ExpansionsLoader+<LoadExpansions>d__21.MoveNext () (at <394a98b9c7624adc895c04290da62640>:0)
UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <7d9ec060e791409ab3eb85c61e312ed6>:0
And its this last failing that is preventing the Main Menu to be loaded.
By deleting Firespitter, you can use MechJeb and the DLCs. By Deleting MechJeb and the DLCs, you can't use Firespitter. Right, we have a pattern.
Firespitter is involved on this mess for sure. Let's keep diagnosing it, however, instead of pinpoint the first symptom detected as being the disease (we do not treat Malaria with antipyretics, you know…).
By deleting the DLCs, you can't use Firespitter and MechJeb, because MechJeb borks on every KSP.IO call it does (that triggers a Reflection Exception, and then something else prevents the Main Menu to be loaded) due the Firespitter's bork.
So I made an experiment, and compiled a MechJeb DLL that doesn't uses the KSP.IO (using an alternate, non reflection dependent, mechanism). It worked a bit more, even with the faulty Firespitter, but then it borked on the
[MechJeb2] ERROR: module threw an exception in OnLoad: MechJebModuleMenu System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.
at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool)
at System.Reflection.Assembly.GetExportedTypes () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0
at MuMech.ToolbarTypes.getType (System.String name) [0x0002b] in <715215068edb467e85d0d3c1bcf9e83c>:0
at MuMech.ToolbarManager.get_Instance () [0x0002d] in <715215068edb467e85d0d3c1bcf9e83c>:0
at MuMech.ToolbarManager.get_ToolbarAvailable () [0x00013] in <715215068edb467e85d0d3c1bcf9e83c>:0
at MuMech.MechJebModuleMenu.ClearButtons () [0x0003d] in <715215068edb467e85d0d3c1bcf9e83c>:0
at MuMech.MechJebModuleMenu.OnLoad (ConfigNode local, ConfigNode type, ConfigNode global) [0x00001] in <715215068edb467e85d0d3c1bcf9e83c>:0
at MuMech.MechJebCore.OnLoad (ConfigNode sfsNode) [0x00347] in <715215068edb467e85d0d3c1bcf9e83c>:0
And, again, the problem is the runtime's Reflection subsystem. And, I want to say it again, it's not a problem on MechJeb neither Firespitter. They are just the messengers, they are the ones with the unhappy luck of stepping on a mine while walking on the minefield.
This is so true that by removing Firespitter without removing KAX, that depends from it, I got this:
[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 the game loading stopped on the spot. Everything is stalled, except by the Loading Screens and the fancy loading messages - what makes me believe that the loading thread was killed.
Well, we have enough evidences about the nature of the problem already. But one more test is in need to satisfy my death wishes: I need to artificially make MechJeb2 bork the game loading. So I decided to induce it to bork in the very same way Firespitter was borking. I'm working on it at the moment, I'll be back about this.
Conclusion
I'm trying to diagnose this thing since last year, yet on the KSP 1.4 era (didn't tried it on KSP 1.3 and 1.2… Something to be tried this weekend…). This is not something new, this is not about "outdated" Add'Ons. This is a bug on the runtime Reflection subsystem and this is not going away.
Even Squad's own modules are borking under the same circumstances.
In order to get this thing safely handled, do not limit yourselves on making tests on "outdated" Add'Ons. Every single Add'On that uses Reflection are prone to this, and every single Add'On that borks something inside the runtime is prone to be the trigger of the problem (not matter its an "outdated" or "updated" Add'On!!)
My evidences above confirms that MechJeb can be the victim, but also the trigger for this thing.
This is a hint that Firespitter is not the only one borking here. What does not means that Firespitter did not needed to be fixed. Just do not feel safe thinking you solved the problem, because you didn't.
The mines are still on the minefield, you just located and deactivated one of them.
L., 2019-1115
This article is also published on Forum and it's deeply related to KAX Issue #6.