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.

And that's a plain lie. The problem is not with MJ and I am tired of explaining it to armchair devs.

Which is the thing I was most afraid of, because 100% of my crafts have "Kerbal Foundries" parts on them. I was able to play the game fine and prevent crashes using the method @Azic Minar mentioned and helped me via PM Great, it works as intended then. And I am not surprised that KSPWheel has the problem since it includes code that uses the now removed legacy particles.

I am amazed at how you manage to reach a conclusion so far from the mark. MM did not trigger the problem before and it does not now. You did try to understand how the code added intercepts Exception from other mods and the stock game and went straight to "It was MM all along!". I doubt players would read a 40 lines explanation. However I see that I am missing a verb in the first sentence (?!). The purpose of the message is to help diagnose a problem, not instruct everyone on the fine point of assembly loading. As to generating NRE when you have a broken conf it is nothing new.

For now what I would like to see is what the last ModuleManager report on those installs. Just update MM and wait for the extension load. It should display a message in the lower part of the screen (and the log)

Install the new MM and MJ I just released and you should get more info about the broken mods on your loading screen when the extension load freeze.

Version 4.1.2 Add an Exception interceptor to catch ReflectionTypeLoadException and properly blame broken DLLs Downloads : ModuleManager-4.1.2.zip ModuleManager.4.1.2.dll

Here is v2.9.1 Changelog ReflectionTypeLoadException will now list the DLLs that are the actual source of the exception in the log. tinygrox on GithUb took on the huge work required to add localization to MJ. People who want to translate MJ should have a look at this file The DeltaV window now has buttons to hide the empty stages and switch between s and dhms for burn time

Read this You posted at night in my timezone. I have a freaking job, other hobbies and people I like to spend time with. So wait in line for me to get the motivation to reply [snip]. Not that you will get anything more than what I said in the quoted post.

My guess would be that you just need to add [SerializeField] to _overrideFingertipScale. The value is private so Unity will not serialize/deserialize it when it reload objects.

I already had a look in your logs and nothing stood out. But then I do not know each of those mods. My guess would be something adding some particle effect which would be the same problem there was with firespitter. It s actually an interesting puzzle to solve but the timing is terrible on my side since I do not have that much time/will to look into it. But it is something I want to solve because there is nothing obvious in the log that can show the real origin of the problem and I would love to add something to ModuleManager that could detect this.