blowfish

You do have to put it in a patch. Variable replacements and other MM things aren't processed on non-patch root level nodes (i.e. PART { }). This may change at some point in the future but is the case for now.

Can't help without logs. But at that stage it's usually a conflict that's going to break your craft which is why I'm forcing it to be resolved.

NEEDS only checks the presence or absence of mods. You'll need to split this into multiple patches. I think this is what you want F { g = h } @PART[something] // whatever your patch actually is { %j = #$@F[g]/h$ } @PART[something]:HAS[#j[h]] { MODULE { // ... } } @PART[something]:HAS[#j[*]] { !j = del // del part can be anything, just needs to be an equal sign here }

It usually takes a while. However the ModuleManager errors I mentioned earlier are preventing some caching from happening that would speed up game loads (assuming no mods have been changed since the last load)

You want %J = #$@F[g]/h$ to paste a variable from a different top-level node (@ tells it to look at the top level) You're missing the /h part :HAS is not valid when creating a node. It checks the node you're modifying, so if you had @MODULE:HAS[...] that would check the conditions on the existing MODULE node See 3

It’s just the stock 1.25m-2.5m flat adapter with some structural bits to hold the engines.

B9PartSwitch v2.4.4 for KSP 1.5.1 Recompile against KSP 1.5.1 Downgrade certain fatal errors to warnings The user will still get an on-screen message but it can be dismissed without closing the game Duplicate subtype names is now only a serious warning Subtype without a name is now only a serious warning I really should have learned this lesson with ModuleManager, but after seeing the extent to which misconfigured parts already exist and are hitting the new fatal errors, I have decided that at least for now it's not worth preventing the user from playing. You will still see an on-screen message complains about the issue but you can dismiss it without exiting the game. And you can probably run this version on 1.5 if you want, nothing really changed as far as this mod is concerned.

Okay, Antares take two And bonus Vulcan-Centaur

If there's something in particular that's likely to be independent of the rest maybe it's worth putting on the alpha channel since that's independent? For instance I'd expect some correlation between metallicity and smoothness but none with AO

I think I was missing something but I figured it out: This Stockalike Station Parts Redux patch adds a resouce named Supplies if you're running USI Life Support: https://github.com/ChrisAdderley/StationPartsExpansionRedux/blob/434277978413cac0f0014bb4fb79d7fb8ec2bd40/GameData/StationPartsExpansionRedux/Patches/SSPXR-Containers-Switches.cfg#L65 This patch in Kerbalism adds a subtype named Supplies as well: https://github.com/steamp0rt/Kerbalism/blob/e992803903d44922275ecf4e63f1cb0cad889bf6/GameData/Kerbalism/Support/SSPX.cfg#L1031 Are USI Life Support and Kerbalism even supposed to be run together? It seems like they'd be conflicting life support systems. E: Gordon Dry's pull request will fix the incompatibility.

We're getting somewhere. Any idea what created GameData/Kerbalism/Support/B9Switch.cfg? It doesn't seem to be part of the Kerbalism distribution. Just removing that file will likely cause other errors but it seems likely that wherever it came from is the source of the incompatibility with SSPX. If you can't figure it out you could try searching for "tankType = Supplies" in GameData

IT should still have outputted all the configs (errors happen after ModuleManager finishes). If you can zip those up and send them to me I can take a look.

Thanks for the report. truss-spinal-01 - this has already been reported and will be fixed in Near Future M3X_AdapterSegment - I have reported the issue here: https://github.com/SuicidalInsanity/Mk3Expansion/issues/15

Hmm, alternately if you can't manager that you can run KSP with the -mm-dump option which will output all the configs to _MMCfgOutput/ in your KSP root folder regardless of errors.

Nope. No ModuleManager errors are different. The mods that appear to be causing ModuleManager errors are ContractPacks/UsefulSpaceStations, Omicron, and MKS