blowfish

It's unfortunately not possible in the current, very basic, thermodynamic model.

I think Nertea was going to look at the NearFuture / SSPX issues. It’s nothing that wasn’t broken before too, B9PartSwitch is just complaining about it now rather than just writing to the log so that they actually get fixed. You can send me your log if you want and I can see if any other mods have bad data too and let the authors know.

B9PartSwitch has its own checking which is a bit more sophisticated than this - it only complains if ModuleFuelTanks exists on the same part as a ModuleB9PartSwitch that actually switches resources (if it doesn't switch resources there's no issue)

Yes, someone probably just forgot to package it

Yeah, it's in GameData/ModuleManager.ConfigCache (assuming there are no errors during patching (but warnings are ok))

Okay, so it looks like this is an incompatibility with CryoTanks ... CryoTanks tries to add fuel switching to anything with LF/O and with LH2, so in effect it's adding two fuel switching modules that are conflicting. Based on what I'm seeing it sounds like you probably don't want any fuel switching, but I don't see an easy way to prevent the switching patches from applying. Might be something to coordinate with @Nertea on, maybe there could be some sort of flag on the part that prevents the CryoTanks patches from being applied if set?

Do you know what mod the DemonBattery directory belongs to? Issue seems to be with those parts. Best guess is that both CryoTanks and it are adding fuel switching to its parts, but I'd have to see the configs/patches involved to be sure.

Did you try starting a new save and looking at it? IIRC the tech tree is cached in your save file, though I don't remember exactly how much of it is.

It just means that some other plugin you have can't be loaded. But there is a small piece that's broken in ModuleManager - it should tell you which plugin it is but it's not. But based on other log messages it looks like it's 000_AT_Utils\Plugins\002_MultiAnimators.dll

Just the latest. The rest will disable themselves anyway.

Whitelisting the old model/textures isn't sufficient - you also need to remove the Restock patch which uses the new stuff on the actual part.

That should be :HAS[#REFUSE_wet_mass] since it's a value not a node

They're legitimate configuration issues that have to be fixed in the respective mods. 2.7.1 didn't change anything fundamentally there, it just added more context to the message (you can see what part/module/subtype is causing them now). I believe the BDB one is fixed in master but not in the release version, and Nertea just spoke to the SSPX one.

@Someone2018 because the REFUSE_wet_mass value is left on the PART at the end, and KSP doesn't know what to do with that when compiling the part. It's harmless but you could include a separate patch to remove it at the end (it would have to be a separate patch - all values are processed before all nodes so you wouldn't be able to use it in the RESOURCE node otherwise).

No, the patch I linked you to is rewriting the config. ModuleManager doesn't do anything like that on its own.

@linuxgurugamer spaces have nothing to do with it. A patch is pointing it to a model that doesn't exist, so of course it's complaining when MM is installed https://github.com/linuxgurugamer/EVAHandrailsPack/blob/46f943a02b4644463c1e9690a1b894f37b34df11/GameData/NEBULA/EVAHandRailsPack/nebulaEvaHandrailsPatch.cfg#L72 (should be NEBULA/EVAHandRailsPack/handle/model )

B9PartSwitch v2.7.1 for KSP 1.7.0 Fix part into button being shown when there's no info to display Provide more context for subtype initialization errors in the warning dialog

Pretty much nothing. KSP will load it into the game database but with the :NEEDS part still in the name so nothing will ever look for it

The 4.0.2 listed there is actually a backport (notice that the url is ModuleManager-RO rather than just ModuleManager). It will work with KSP 1.3.1 but note that the regular 4.0.2 will not.

@GJNelson can you upload GameData/ModuleManager.ConfigCache for me to look at and also let me know what version of Mk2 Expansion you're running? Edit: Apparently Github hasn't been updated with the latest changes, I see the issues and I'll report them Edit2: I reported both the issues with Mk2 Expansion: first and second

Anything it's complaining about now was an issue before, it was just a log message the no one ever read. Keep sending me your logs and I'll figure out what the offending parts are.

B9PartSwitch v2.7.0 for KSP 1.7.0 Compile for KSP 1.7.0 Remove ModuleB9PropagateCopyEvents from parts since KSP handles this correctly now Leave empty class so that KSP doesn't complain when loading craft/vessels Subtype initialization errors now warn the user but allow the game to continue Add fuzzy matching for attach node toggling ? will match any one character, * will match anything (or nothing) All matching nodes will be switched Allow moving and rotation of transforms Subtypes can now have TRANSFORM nodes Each one should nave a name which is the name of the transform Each one can have a positionOffset = x, y, z which is a local offset for that transform Any number of modules can modify a transform's position (it's additive) Each one can have a rotationOffset = x, y, z which is a local rotation offset Only one module can modify a transform's position Remove KSP localization debug logging Add Brazilian Portuguese localization Localize switch subtype button Fix texture switches incorrectly saying the current texture wasn't found when really the new texture wasn't found Use more correct part names in some log messages Allow subtypes to specify a mirror symmetry counterpart Subtypes now accept a mirrorSymmetrySubtype value which is the subtype name of the mirror symmetry subtype When placing the part in mirror symmetry, the symmetry counterpart will use this mirror symmetry subtype, otherwise it will use the normal subtype I'm pretty sure this will also work with KSP 1.6.x but no explicit guarantees

@NermNermNerm PlanetaryBaseInc is alphabetically before PlanetarySurfaceStructures Just to clarify, let's say your mod list is mod1, mod2, mod3. The order of patches will be: :FIRST legacy (no pass) :BEFORE[mod1] :FOR[mod1] :AFTER[mod1] :BEFORE[mod2] :FOR[mod2] :AFTER[mod2] :BEFORE[mod3] :FOR[mod3] :AFTER[mod3] :FINAL

@linuxgurugamer obj_ctrlSrf_R has the Icon_Hidden tag. So that's hiding that subtype (which is the default) in the part icon.

I get what you're doing, what I'm saying is that there's no need to find it because the AvailablePart stores a reference to it