blowfish

Isn't this equivalent to the Altair which already exists?

This should all be happening after KSP is done loading the plugins, so I think that part is fine at least. And that should be only reading too - having two things read the file at the same time should be fine, this exception should only happen if something has a write lock.

Not sure what could be causing that, but it seems to be handled properly (the SHA for that DLL isn't generated but it's just for display purposes anyway). Also weird that it's just those two DLLs. Is there a chance something else is holding a lock on those files?

There are 3 warnings from BDB and one from Engine Lighting. The BDB ones are harmless and have already been fixed, I think you just need to update it. The engine lighting one is this: [WRN 2019-41-29 16:41:29.267] unrecognized tag: 'smallRadialEngineFOR' on: EngineLight/engine-configs/@PART[liquidEngineMini]:smallRadialEngineFOR[EngineLight] Which does indeed look badly formatted. It looks like someone has already proposed a fix for it: https://github.com/ToXik-yogHurt/EngineLightUnofficial/pull/2/files#diff-04a1b9a3639ee8be3aadbcf237d5afb6L85 but it has not been merged. The consequence of this I think is that the Spark and Twitch engines won't have quite the desired lighting settings.

They're all in the log. It can be a bit daunting to sort through, I can help with that though if you post it.

It was always happening. Config changes (and model/texture changes) wouldn't be reflected in the parts until they are recompiled.

Reloading can be done in the space center or main menu, I guess in the space center you'd be in an active game so maybe that doesn't really work?

It seems like Contract Configurator is complaining about something. Did this definitely work with previous versions of MM? It looks like ModuleManager's bit is finishing successfully, but Contract Configurator is getting tripped up when KSP is compiling parts [EXC 10:56:05.138] NullReferenceException: Object reference not set to an instance of an object ContractConfigurator.ContractType.CheckContractGroup (ContractConfigurator.ConfiguredContract contract, ContractConfigurator.ContractGroup group) ContractConfigurator.ContractType.MeetBasicRequirements (ContractConfigurator.ConfiguredContract contract)

Let's start with that, yeah

If you still have logs from a KSP run where this happened, would you mind sending them to me?

@ModZero avoid using Kerbalism with MM 4.0.x for now. Kerbalism was making an assumption about when ModuleManager was doing things that is not longer valid, most likely a few changes will have to be made on both sides to fix.

Based on my understanding of the issue that makes sense. And yeah, it looks like Kerbalism was making some assumptions about when and how ModuleManager does things to get these feature toggles to work. But I'm in contact with @N70 to hopefully come up with a better long term solution

Thanks! It looks like something really screwy was going on in 3.1.1, this doesn't seem to exist [ModuleManager] Applying update AntennaHelper/Localization/de_de/@Kerbalism:FOR[ProfileDefault] to Kerbalism/Settings/Kerbalism So something weird is going on that's making it think that ProfileDefault exists when it doesn't. I'll do a bit of digging and see if I can figure out what's going on. Best to avoid using ModuleManager 4.0.x with Kerbalism for now. I think it's related.

Not sure, I haven't looked into it in detail. If the thrust transforms did change then this would have to be reflected in the RealPlume config

It shouldn't have changed the number of patches. I didn't notice any significant changer in the number in my testing ... are you sure updating ModuleManager was the only thing you changed? Would be easiest to figure out what's going on with logs from both before and after

It can't be both :FOR[RealPlume] and :AFTER[Restock] - those are incompatible. Just choose one. the Restock pass will run after RealPlume so you probably want that

Are the new tech nodes there? Does this happen with a fresh save? There might be some stuff stuck in the save if you saved while using MM 4.0.0

Version 4.0.1 Fix custom tech tree and physics not being loaded Downloads : ModuleManager-4.0.1.zip ModuleManager.4.0.1.dll

It's complaining about :FOR[Kerbalism] - the :NEEDS is fine. Non-patch nodes can't have a pass - they're all inserted at the beginning.

Any node or value at any level can use :NEEDS

Thanks, I'm looking into it

It prevents them from loading, so they'll never exist in memory

Directly in GameData should be fine

Thanks. Since you uninstalled the mod before that log was generated I wasn't able to find the error in there, but since you figured out which mod it was I installed it and saw the warning [WRN 13:16:31.683] [ModuleManager] more than one :HAS tag detected, ignoring all but the first: DecouplerShroud/DecouplerShroud/@PART[*]:FOR[DecouplerShroud]:HAS[@MODULE[ModuleDecouple]]:HAS[!MODULE[ModuleDecouplerShroud]] It looks like it's actually already been fixed: https://github.com/nav0t/DecouplerShroud/commit/dad42944fdd7b32946763f703a65b0195056fa27 but the mod author just hasn't released a new version yet. You could ask the author to release a new version to fix this, but in the mean time I think it's safe to allow this warning to happen and just ignore it.

It's in the log somewhere. Post it and I can look through, unfortunately there's not an easy way to find them.