sarbian

I did not update the first post in detail but the first line has links to updated instructions.

With a random problem I would guess it is a mod that does something with threads that it should not do. Running KSP in Debug mode may show a few useful warnings.

Given the small code change between 4.1.2 and 4.1.3 I think your problem is more likely a random one that will happen with both versions. But if you can trigger it each time on 4.1.3 I would welcome a log and if it is not too large a zip of your install (without the Squad dirs).

Yes, you can. Version 4.1.3 is out. Cleanup the Exception interceptor code and remove the double exception logging and improve the badly worded warning ModuleManager-4.1.3.zip ModuleManager.4.1.3.dll I still doubt 4.1.2 could have broken anything but this one is even less likely to

Thanks for the log. The problem is a MJ incompatibility with toolbar controller. I ll see what I can do about it. Edit: err, nope. You are running MJ 2.9.0 and I fixed that bug in 2.9.1. Just update

I did not have much time to look at it tonight but I could not find anything really out of the ordinary. DeployableHabitat throw exceptions in both working and not working log... Hopefully I ll be more inspired tomorrow.

From what I am seeing in the log you have one (more?) mod(s) that are compiled for 1.8. TarsierSpaceTech is at least one and I think you also have a 1.8 MiniAVC

As I can not see the log posted in the other thread it is hard to extrapolate. The MM 4.1.2 new code does something only if a ReflectionTypeLoadException is thrown and not handled so something is triggering it. I see that the message I log is a bit obscure so I could improve that and I guess I could make sure this does not throw an other exception on top... Can you share the list of mod that triggers the endless loading for you ? zip the whole thing if it is not too large and I could have a look when I am back home.

I posted in MM thread about this but it is quite unlikely that MM 4.1.2 break anything. You see the "ModuleManager.UnityLogHandle.InterceptLogHandler:LogException" because an other mod did not catch an Exception and that MM version has some code that intercepts unhanded Exception to diagnose them. I can not look at the dropbox file from work but I suspect there is a useful line just after that Exception.

The last version of MM only added code that intercept the Exception logging so it can find out which dll generated a ReflectionTypeLoadException. I highly doubt it could break anything that is not already broken without it. I ll try to duplicate the poster problems but it is likely that I will find a problem somewhere else.

I can not duplicate it here so I guess you need some specifics mods. I will need the whole log.

You will have to re export the asset bundles with a Unity 2019.2.2. And Shaders names changed so you need to fix them (Adding "Legacy Shaders/" in front usually does the trick). It is likely that this covers all the required changes.

@Lisias, as I said in the other thread I am tired of this. You do not read my post and just push your conclusion. The problem is now properly diagnosed and the code I added to MM make it easy for anyone to know the DLLs that trigger it.

I replied in the other thread but the short version is that you left the old code in KSPWheelDustEffectsOld and it is still included in the DLL.

First let me make something clear so we do not waste time: I disagree with @Lisias about the source of those "stuck loading". We exchanged before and still disagree so you can think that he is right or I am. No need to try to convince me again since I am quite sure that my view is the right one (obviously ) I just had a look at KSPWheel and it does indeed uses the old particule system that was removed from Unity 2019: 1>------ Rebuild All started: Project: KSPWheel, Configuration: Debug Any CPU ------ 1>KSPWheel\PartModules\KSPWheelDustEffectsOld.cs(87,17,87,32): error CS0246: The type or namespace name 'ParticleEmitter' could not be found (are you missing a using directive or an assembly reference?) 1>KSPWheel\PartModules\KSPWheelDustEffectsOld.cs(88,17,88,33): error CS0246: The type or namespace name 'ParticleAnimator' could not be found (are you missing a using directive or an assembly reference?) 1>KSPWheel\PartModules\KSPWheelDustEffectsOld.cs(90,17,90,32): error CS0246: The type or namespace name 'ParticleEmitter' could not be found (are you missing a using directive or an assembly reference?) 1>KSPWheel\PartModules\KSPWheelDustEffectsOld.cs(91,17,91,33): error CS0246: The type or namespace name 'ParticleAnimator' could not be found (are you missing a using directive or an assembly reference?) ========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ========== As I explained in an other thread it creates a problem for reflexion call that puts Unity mono in an instable state which then breaks the extension loading that does a lot of reflexion. MJ uses some stock code (KSP.IO) that do reflexion and trigger this but other mods could do it. And it could also break stuff in game silently and mess up saves. The mod need some new code to move to the Shuriken particle system. Either @Shadowmage has the time to do it soon-ish or some else feels up to it. I did this migration in SmokeScreen a while ago and I guess I could do it but it does require time which is a limited ressource. My recommendation here would be to have a version of KSPWheel without KSPWheelDustEffectsOld. Given the name it may not even be used anymore and it just need a recompile without this file. This is why I added some code to catch this problem in the last MM. This way we can identify the problematic mods and either fix them or avoid them.