blowfish

SolverEngines v3.5 for KSP 1.3.1 Engine modules now support THRUST_TRANSFORM nodes to allow thrust transforms with multiple names If present, these will overwrite any other thrust transform setup Any number of these nodes can exist on the engine module They have the following fields name: name of the transforms(s) to be used (required) overallMultiplier: thrust multiplier applied to all transforms with this name (optional) multiplier: multiplier applied to individual transforms, there can be either 0, 1, or n multipliers, where n is the number of thrust transforms with this name If there is 1 multiplier then it will be multiplied into overallMultiplier

Unfortunately I wouldn't say I have enough of a grasp of how the system works to describe all of that very accurately. I'd recommend playing around with some highly distinguishable values to figure out what's going where. If you can narrow down questions about what's going into what specific field, I might be able to help with some investigation, but there's really no definitive resource on how all of this works other than trying it out.

Porkjet's overhauls have some upgrades implemented, if you can find those they might be a good example.

Good catch, they must have changed the URL scheme at some point

I don't think the DLLs conflict. If you have configs that attempt to add fuel switching to all fuel tanks for both, you will run into issues, but just the DLLs themselves shouldn't be a problem. I would ask whoever is saying this to clarify what they mean.

Firespitter is not used for fuel switching anymore. However, there are a couple of Firespitter modules that are still in use, including the VTOL rotator module and texture switching on the landing gear. It is possible. But someone has to go through and calculate the volumes on every wing, and I really don't have the time for that right now.

I tried this, but I can't replicate this behavior. Symmetry behaves exactly as I would expect. Are you sure there isn't some other mod here messing with things? There were originally craft files, but no one maintained them through many updates, so they are no longer included. I can't help you with the Interstellar warp plugin. If it's crashing your game, that's on it...

Yes, but it involves writing all your own engine configs...

If you want to do that, you want to look for PROPELLANT nodes. RESOURCE is on the part, PROPELLANT is on the engine module.

Yeah, it uses string comparison unless you're using > or < One thing you could do is constrain it in a small range, e.g. :HAS[#defaultScale[>0.624],#defaultScale[<0.626]]

You have two top-level :HAS blocks. Try this @PART[*]:HAS[@MODULE[ModuleEngines*],!RESOURCE[SolidFuel]]:FINAL Nope, not that... But the [*] is completely redundant in this case

Sorry, which part exactly is that? I can't tell from the screenshot. And it's definitely not broken on every part...

Not something that's currently possible. Something I've looked into but it ends up being rather messy and complicated.

It would have to be a separate patch (or you could assign the keys within ModuleEngines and then have another @MODULE that checks for them).

You also can't index a multipart value in a :HAS block (you can however assign what you want to another value and then check it later.

Yeah, MM like matching was something that came to mind. It's not built into .NET though, you have to escape it, replace certain characters, and turn it into a regular expression.

I could think about adding some way to fuzzily match nodes. Other than this one particular case though, I haven't seen many places that would benefit from it. The old fuzzy matching was really doing more bad than good.

I don't think so, unfortunately.

v2.0.0 removed fuzzy node matching, you now need the exact name of the node (e.g. top01). However, node names with underscores would never have worked - if you have e.g. node_stack_top_something, KSP will take only top as the node name. Also, spaces before the :NEEDS and :FINAL will cause them to be ignored (limitation of how KSP parses nodes)

key,x refers to the xth key value in the node (where x is 0-indexed)

B9PartSwitch v2.1.1 for KSP 1.3.1 Fix texture replacements being reset when drag cubes are rendered Fix battery tank type having 100x too much electric charge, bring mass in-line with stock

@PART { @MODULE[ModuleGimbal],* { @gimbalRange /= 2 } } You're close. I think you need #$atmosphereCurve/key,0[1, ]$ Assign the variable to some value, then check for the value later in a :HAS block

AJE v2.10.0 for KSP 1.3.1 Recompile for KSP 1.3.1 Add initial Chinese localization support Fix paths for some Firespitter models Add intake support for Aviation Cockpits

That's not currently possible, unfortunately. MM does not process variable searches within those brackets.

You can't check variables that way unfortunately. You'll need to do it outside that @PART:HAS[#CrewCapacity[>0]] { MODULE { ... } }