blowfish

You already asked for this, I just haven't gotten to it yet. But based on what you're saying now different scaling on each axis is required.

RESOURCE nodes in parts are all caps, it is case sensitive This can be simplified to !MODULE[ModuleKPBSNuclearStorage], also you need brackets after it for it to be recognized as a node (as with !RESOURCE,* {}) As above

That is correct. I've looked into changing this, it's certainly possible but it would break a bunch of existing patches that rely on the post-localization values. There's no way to index within a HAS block unfortunately.

If KSPIE might be involved then I'm afraid there's not much I can do. That mod is a labyrinth of code and configs that I don't have the time to take the time to understand. Have you tried asking about over in that thread? If you look in the Github issue I linked, it is in fact a bug in RPM, but it's not going to be addressed unless someone else takes up maintenance of that mod, and also the B9 prop configs use a legacy system which is much lower priority to support.

Haven't noticed them overheating myself (and I just tested). Any other info you can provide? Known, probably needs a redo of the RPM configurations which I don't know how to do

Post your log, most likely something is installed incorrectly. I guess maybe do it in the B9PartSwitch thread though.

I created an issue to investigate this. Not sure how those textures would have gone missing

Pretty sure you will start to see some problems if you install a mod that requires B9PartSwitch and no B9PartSwitch If you re-install it and provide your full log I can point to where the issue lies. Either something is installed incorrectly or an unexpected combination of mods is causing a ModuleManager patch to fail. Either way, I will get to the bottom of it if you let me. E: So apparently you also have mods installed that require Community Resource Pack but don't have that installed. That would definitely cause issues.

I could almost consider adding title, descriptionSummary, descriptionDetail to B9_TANK_TYPE to provide defaults for the SUBTYPE. But I think you're talking about adding a templating system for entire switcher modules, which is an entirely different thing and a much bigger undertaking. oh and P.S. you don't need to set affectDragCubes 90% of the time. If there's no mesh switching it won't try to re-render drag cubes.

Other mods use a ModuleManager patch targeting multiple parts to install the same module multiple times. Maybe that would make sense here?

Looking at your example, I think you might be a little bit confused. B9_TANK_TYPE defines a tankType that can be used on an individual SUBTYPE, it's not a template for an entire ModuleB9PartSwitch. Maybe look at some existing examples for how these are used?

primaryColor and secondaryColor yes (in B9_TANK_TYPE), the rest no. And none of them in RESOURCE nodes.

Welcome to the forums! The error you're getting has nothing to do with the version of B9PartSwitch you have installed. The problem appears to be that your GameData/Squad directory is missing some pieces. So in this case the stock resources (LiquidFuel, Oxidizer, etc) are not defined. Try deleting and re-installing GameData/Squad.

@Autochton has transferred ownership of this package to me, the repo can now be found at: https://github.com/blowfishpro/kerbal-config

Seems like your installation of RationalResources might be out of date? Try updating that Thanks for posting the log though, allowed me to quickly see what's in your install and what might be wrong

B9PartSwitch v2.10.0 for KSP 1.7.3 Use funds symbol for cost in tooltips Fix vessel size including disabled objects add new upgradeRequired field to SUBTYPEs References the name of a PARTUPGRADE require do unlock the subtype At least one subtype on every switcher must have no tech restriction (i.e. unlocks with the part), otherwise it will complain and remove the restriction from the first subtype All subtypes are unlocked in sandbox regardless of whether upgrades are applied Warning if the upgrade doesn't exist If you attempt to load a craft with a locked subtype you get a warning that it was replaced with the highest priority unlocked subtype Add defaultSubtypePriority to SUBTYPEs Number (float) that determines a subtype's priority as the "default" subtype (i.e. the one that is chosen when you freshly add the part). The subtype with the highest priority that is also unlocked will be chosen If two subtypes have the same priority and both are unlocked, it will choose the first The default value is zero. Add basic implementation of module switching HIGHLY EXPERIMENTAL Subtypes now accept a MODULE node inside is an IDENTIFIER node which is used to identify the module it must have a name which is the same as the module it can have any other fields that are used to identify the module e.g. engineID on ModuleEngines Identifying the module by nodes is not currently supported It accepts a DATA node which provides new data to be loaded into the module It accepts a moduleActive = false value which causes the module to be disabled Not everything will work initially, custom handling will have to be added for some modules Some modules are blacklisted for loading new data and disabling. This list is subject to change. ModulePartVariants ModuleB9PartSwitch ModuleB9PartInfo ModuleB9DisableTransform FSfuelSwitch FSmeshSwitch FStextureSwitch FStextureSwitch2 InterstellarFuelSwitch IntersteallarMeshSwitch InterstellarTextureSwitch Big thanks to @Gotmachine who's initial implementation of module switching this is based on Please talk to me before you attempt to use module switching. Like I said in the changelog not everything will work initially. I'm willing to add additional code to support specific modules, but I'd like to understand the use cases before doing so.

I did. It ends up being pretty complicated, although I got a working prototype. It requires reaching deep into KSP's/Unity's/.NET's internals in a way that I'm still not sure I feel comfortable with. Also some mod plugins do things that are straight up not compatible with it.

For what it's worth you can use any number of spaces as the separator

The documentation isn't complete sadly. But the delimiter is specified by the patch @key,*[0, ] *= 2 The [0, ] part says to modify the entry at index 0 separated by the character after the comma which in this case is a space

I think this happens because the values are tab separated but the patch expects them to be space separated.

I have not implemented themes yet. IIRC there's an open issue for it.

Just appropriate application of :HAS blocks @TechTree:FOR[SomeMod] { @RDNode:HAS[#id[stability]] { @Parent:HAS[#parentID[basicRocketry]] { @parentID = subsonicFlight } } } (replacing :FOR[SomeMod] with an appropriate pass specifier of course)

Unfortunately the only way to do this currently is with multiple patches. Would like to add this at some point in the future ... once a bunch of the core code is rewritten.

correct

And ConfigCache, that will include the final state of all configs in the game database.