blowfish

in a :HAS block @ means "has node" ! means "does not have node" # means "has value" ~ means "does not have value"

I is valid in two contexts: in :NEEDS block (it means or) in top-level name checking, i.e. @PART[abc|def], in this case it also means or (since a part can only have one name)

Well you've got the arithmetic part basically right, just the RESOURCE:HAS[!RESOURCE[MonoPropellant]] bits are incorrect. HAS is used to check the node you're currently patching, so HAS[RESOURCE[MonoPropellant]] would only be valid at the top level. It also looks like you're trying to edit the resource in the second part but not using an operator to actually edit the node? Try this I added a few comments to try and explain what's going on there, of course they don't have to be part of the final patch.

Okay, that makes more sense. Does building the new "welded" part config involve MM patching, or are you putting it in the game database in its final state?

NEEDS[SquadExpansion/Serenity] Nothing is adding just Serenity to the mod list

Those all look like they would work to me. Do you get any errors? Is there any other reason why this value might not be available (e.g. patch order/wrong pass)? Maybe back up a couple more steps. At a high level, how does this mod do part welding? It sounds like you're creating new configs for the "welded" parts and then compiling them into actual parts?

@Lisias I'm still interested to hear exactly this mod is/was doing with ModuleManager (not just what methods it was calling, but what was it trying to accomplish)

Yes, apparently there were multiple mods hooking into ModuleManager in unintended and unsupported ways... Could you explain to me exactly what it was doing with ModuleManager? That still isn't very clear to me.

Still not sure why what requires anything involving ModuleManager. Shouldn't the final (patched) configs be sufficient for this?

Why would this require access to MMPatchLoader?

Why would we want ModuleManager to do this? We don't want KSP to load everything in zDeprecated. The idea would be that if you need specific files from there in your mod, your mod would do the setup required for those files to be loaded (either by copying or adding them to the tree at the appropriate time).

It probably is. The RAPIER (and similar) are hacks of the turbojet module really, so I'm not really sure of a good way to fix this yet. I've been looking at an alternate thermodynamic model for these engines but haven't generated anything I like yet.

If you copy the files immediately on addon startup KSP will actually pick them up. Reason being that the game database is re-initialized after addons are initialized. Alternately you can manipulate the game database tree structure a frame later to include the missing files - if you do it then ModuleManager will pick it up (just don't wait any longer)

I've seen this too, note that it's specifically on a database reload. I haven't really investigated much but my guess is that there's something that's already initialized that TU is trying to re-initialize without first clearing the old data out.

It needs to be one line yes. I only expanded it that way so that we could see the individual parts more clearly. And this is a limitation of KSP's config parser, not MM specifically I actually just thought of something. I think if you have ~minimumCrew[>0] it will match if there is no minimumCrew or if the value is <= 0 (I assume we don't really care about negative values here You want !MODULE - in a has block @ means "has module", ! means "does not have module", # means "has value, ~ means "does not have value"

@kcs123 looks right except that | doesn't work in a HAS block (no easy workaround unfortunately)

You have multiple top-level HAS blocks. Only the first will be used. And check your braces @PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS]:HAS[#SASServiceLevel[3],#minimumCrew[0]]]:NEEDS[kOS] E: might be easier to see this way: @PART[*]:HAS[ @MODULE[ModuleCommand], @MODULE[ModuleSAS]:HAS[ #SASServiceLevel[3], #minimumCrew[0] ] ]

Not currently. It would be a feature request, but probably pretty easy to implement since the instrumentation for modifying transforms is already there.

Oh, well RO is a completely different can of worms (and all the patches for RO are in RO). This is an RO configuration question, nothing to do with RF. My recollection is that the RO SSTU patches might be out of date post-1.3.1, but I don't remember for sure.

That patch would have been part of RF Stockalike, not RealFuels itself.

There should be a more detailed warning somewhere up in the log ... it's a bit hard to find unfortunately but the line will start with [WRN Looks like the issue is with the Mk2 Expansion's Tweakscale patches specifically

It's in the log (both KSP's main log and ModuleManager's logs in <ksp_root>/Logs/ModuleManager)

Yeah. If it's complaining now, it's nothing that wasn't silently broken before too.

The ModuleManager warnings are coming from RF Stockalike, not RF itself Nonetheless I have stubmitted a PR to fix them: https://github.com/Raptor831/RFStockalike/pull/100

Exactly that