CKAN Compatibility issue with 1.8.0 2686
GitN3wb opened this issue · 19 comments
I tried to install KAX with CKAN, both with and without Firespitter (but with Firespitter Core and Firespitter Resources config successfully installed).
Installation seems fine but then the game loading fails when reaching the KAX electric engine or some other electric part.
Sorry if this was already known.
And, as usual, I ended up forgetting this one open too.
KAX is working fine on KSP >=- 1.8, or at least on 1.12.2.
Next version will have the proper metadata on SpaceDock.
Well… Using a clean KSP 1.8.1 (with both DLCs), I installed KAX (and TweakScale) from CKAN and everything works.
I don't have a 1.8.0 available for testing anymore, as the problems on this version renders a lot of Add'Ons unusable (and this cannot be fixed, as as bugs on KSP itself). I suggest you to upgrade to 1.8.1 .
Additionally, even on 1.8.1 are some Add'On combinations that causes some of them to crash. MechJeb2 is a usual victim of that problem (older Firespitter crashes it, be absolutely sure to be using Firespitter 7.14 or later).
If you have MechJeb2 installed, uninstall it and see if things work again. If by deleting MechJeb2 your game works, you will need to reach MechJeb2 maintainer for help on diagnosing the Add'Ons that are leading it to crash.
Humm.. Just remembered… I had tested it on 1.8.0 some time ago.
It's or sure something on your installment, and it's not related to KAX.
Humm.. Yeah, I decided to give it a shot. I installed MechJeb2.
The startup took a awful amount of time this time, but it ended up working. The part where the loading phase is done and then the Main Menu is loaded is where things are terribly slow.
But once the game loads, on my testings, KAX + Firespitter 7.14 + TweakScale + MechJeb2 works fine.
Until the moment, everything worked fine (even if somewhat slow to load). I need your KSP.log and the Player.log in order to help you. It's something else on your game.
@GitN3wb , I think I fixed the problem on MechJeb2! But I will need your help.
Please send me your KSP.log. I need to reproduce the problem here, then try the fix. If I manage to solve this, I will send you a experimental DLL so you can confirm from your side. If you confirm the fix, I will issue a Pull Request to the maintainer!
There's a reason to use KSP 1.8.0? KSP 1.8.1 had solved a lot of compatibility issues that happened on 1.8.0 , and I find hard to justify using 1.8.0 due that.
Other than that, I will check this against 1.8.1 to see what happens. What you describes sounds like a Exception happening on a critical section of the Module initialization, and this kills the thread responsible for loading things on game loading - as the the master thread stays locked forever waiting for a "go ahead" that will never be issued.
Since Firespitter is a hard dependency for KAX, and KAX uses Firespitter modules for some features on the engines (sound), I think that somehow Firespitter entry on CKAN is kaput.
I will come back to this soon.
To tell you the true, 1.8.1 is critical for TweakScale due some glitches on the UI Controls it uses. But since TweakScale is highly recommended to be used with KAX (besides not being a requirement), and since a lot of interesting Add'Ons don't work on 1.8.0 (some for similar reasons, others for anothers), there's no reason to stick to 1.8.0.
It's like using 1.4.0 in the past - just doesn't worth. :)
Well, since your problem is solved, you don't need to send me that data. But I would be thankful if you do, becasue MechJeb2 is important for some people, and it's KAX best interest to make this thing work fine with Firespitter (as I don't want to ditch it).
Hi, thanks for the support!
Right now I am installing 1.8.1, I didn't know it was critical for compatibility. To be clear I was not using MechJeb2.
Do I still need to send you KSP.log ? And a portable for the old 1.8.0 install also?
So here is the KSP.log . Tell me if you need the old zip containing the 1.8.0 game version.
And thanks again for the support
Well.. I made some progress on that glitch, but found another later. =D
[LOG 00:31:12.714] [MechJeb2] ERROR: module threw an exception in OnLoad: MechJebModuleMenu System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Ref
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
I need to document this somehow, so I will do it here. This is something that should be tacked down by KSPe, by the way.
Originally, i was thinking that by failing to load a DLL, the data structures used by the C# runtime to handle reflections get corrupted, and then any attempt to call them ends with an internal exception.
I noticed this behaviour last year, while working on the KSPe.IO subsystem from KSPe, that relies heavily on reflection to infer who is calling it to decide where to put things on the filesystem. I had noted that every time a DLL dependency failed to be loaded, all calls to KSPe dies tragically (what can be a problem, since the logging subsystem also uses reflection).
However, this does not explains Firespitter behaviour. No DLL is failing at loading on it - but yet, the same problems are happening, as I shoved KSPe.IO on MechJeb and t borked the same.
So I cooked a light KSPe.IO thingy, that doesn't relies on reflection, to be used instead. This workarounded the issue, MechJeb is not failing anymore while reading/writting files. Now it's borking on the ToolbarManager, that also needs reflection. :D
That's a hard confirmation about the reflection problem, but doesnt' explains, yet, why Firespitter is triggering this problem.
Checking on the FireSpitter commit log, I realized what was done to prevent the problem. It was trying to blindly loading deprecated shaders (that on Unity 2019 changed places), and that code was borking, of course. And then I realized that failing to load a DLL is not causingr the reflection problems, but it was itself only another trigger.
Knowing better how things work inside KSP and Unity, i can now postulate that unhandled exceptions that happens inside some critical threads of Unity make things going through the tubes!
This makes things way more harder do diagnose than I though, because a DLL failing to load leaves a log on the KSP.log, but Firestpitter exceptions are completely silent.
What remains to be diagnosed is why MechJeb is inducing the killing of the startup process of the Main Menu. Because MechJeb is not killing the startup itself, in the same sense that Firespitter is not killing MechJeb neither. It's the Expansion Loading that is killing the Main Menu:
[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
Do you mean Firespitter Core? Because the Firespitter parts are not mandatory for KAX to run, and I didn't install them except once to try to fix the issue.
Yeah, things are finally figured out. :)
On Forum, a new Module Manager version had solved the problem.
I don't agree (as usual) with the maintainer about his diagnosis. MM says that an DLL incompatible with KSP is the problem, and I dispute that.
The problem are faulty DLLs, indeed, but not about KSP incompatibility. ModuleEngines, a STOCK KSP module from Squad, also borks the Game Loading when something bad happens (as a missing needed resource for the part).
This was not a problem with Module Manager, it happened that MM was only the preferred victim as this guy is almost omnipresent and right on the critical path of everything while loading. It is a glitch somewhere on KSP (be it on Squad's code, on Unity's or Microsoft): some special event handles cannot have unhandled exceptions, or the father thread dies.
But MM being able to detect and overcome this on game loading is going to help a lot. You don't need to fix every bug to make things works, sometimes is cheaper to just known it exists and workaround it.
And, by the way, Firespitter 7.13 /L (my personal fork) loads fine on KSP 1.8.1 as long nobody freaks out due an unhandled exception. :D Obviously, most Firespitter Modules are not working, but the parts are and KSP still loads fine, damn it! :(
So I made this test. Faked one of the KAX parts into GameData, making sure it would be the very first part to be loaded. I shove if on Gamedata/00hack
PART
{
// Kerbal Space Program - Part Config
// e50 Electric Propeller Engine rebuilt for KSP 131 following extensive prop related NRE's
//
// --- general parameters ---
name = KAXelectricprop
module = Part
author = Spanner Keptin
//Big thanks to Snjo for his Firespitter plugin and help!
// --- asset parameters ---
mesh = electricProp.mu
rescaleFactor = 1
// --- node definitions ---
node_attach = 0.0, 0.0, 0.0, 0.0, 0.0, 1.0
// --- editor parameters ---
TechRequired = aerodynamicSystems
entryCost = 3200
cost = 750
category = Propulsion
subcategory = 0
title = e50 Electric Propeller Engine
manufacturer = Kerbal Aircraft Expansioneers Ltd
description = An electric motor.
bulkheadProfiles = srf
// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 0,1,0,1,0
// --- standard part parameters ---
mass = 0.2
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.3
angularDrag = 2
crashTolerance = 6
breakingForce = 50
breakingTorque = 50
maxTemp = 2900
fuelCrossFeed = True
EFFECTS
{
idle
{
AUDIO
{
channel = Ship
clip = KAX/Sounds/sound_kax_electricpropIdle
volume = 0.0 0.0
volume = 0.01 0.7
volume = 1.0 0.7
pitch = 0.0 0.5
pitch = 1.0 0.65
loop = true
}
}
}
}
@PART[KAXelectricprop]
{
MODULE
{
name = ModuleEnginesFX
thrustVectorTransformName = thrustTransform
exhaustDamage = False
ignitionThreshold = 0.1
minThrust = 0
maxThrust = 8
heatProduction = 8
useEngineResponseTime = True
engineAccelerationSpeed = 20
engineDecelerationSpeed = 20
useVelocityCurve = True
spoolEffectName = idle
PROPELLANT
{
name = ElectricCharge
ratio = 0.4
DrawGauge = True
}
PROPELLANT
{
name = FSCoolant
ratio = 0.01
}
atmosphereCurve
{
key = 0 800
key = 1 800
}
velocityCurve
{
key = 500 0 0 0
key = 425 0.2 0 0
key = 0 1 0 0
}
}
RESOURCE
{
name = FSCoolant
amount = 5.0
maxAmount = 5.0
}
MODULE
{
name = ModuleResourceIntake
resourceName = FSCoolant
checkForOxygen = false
area = 1
intakeSpeed = 50
intakeTransformName = Intake //thrustTransform //Intake
}
}
And then KSP crashed the loading, entering into an eternal loop of Loading Screens and fancy messages. However, one of the threads of Module Manager appears to be killed, as no Exception is logged on KSP.log!!
However Module Manager managed to save the ConfigCache, so I restarted KSP to see whap happens.
So we have a confirmation that KSP itself is crashing, it's not something being made by Module Manager.
And since I used only Stock modules (only ModuleManager 4.1.2 is installed - and the hack above), there are no "outdated mods" on this thing.
Yep. Firespitter Core is Firespitter without the parts. As you can see on the Forum, I made some new discoveries about the issue.
It's not that bad really - what is playing havoc with us is people misdiagnosing it as "not compatible to this KSP version". That thing will happen (and to tell you the true, it's happening since 1.4.0) when any Add'On borks on some critical code.
Of course, Add'Ons "not compatible" with the KSP version will bork for sure, but "compatible" Add'Ons that have a coding bug on critical code will bork exactly the same way. I made a Stock module (ModuleEngines) to bork by accident, and the thing just killed the game the same way. Are the Stock ModuleEngines not compatible with KSP? :D
Could you update the metadata for the mod on CKAN? It currently says that the latest compatible version of KSP is 1.7.3.
Apologies, I know this is somewhat unrelated but I felt like it was related enough and didn't warrant making a whole new issue.
I will. I want to proper test this thing before updating the metadata stating 1.8 compatibility. I have evidences that it works, but I didn't tested it thoroughly. And I don't want push it into 1.8 mainstream prematurely.
Given the current circumstances on Forum, such a mistake of mine would render me some headaches. :P
It will be done in the next 10 days for sure - I can't say exactly when due Real Life issues.