blowfish

In this context, @ means edit the existing value and % means "edit the value or create it if it doesn't already exist.

All values are processed before all nodes. It's a limitation of KSP's parser. So for instance @mass = #$MODULE[ModuleLPG]/newMass$ will be processes before you have added the newMass. The workaround is to put that in a separate patch. @ should work fine in general here. When will there be a part without name or title?

I saw a couple of issues around this lately, so let me say it clearly Do not install B9PartSwitch by downloading the repo. It does not contain any compiled plugin. Go to the releases page and download the latest release (for your KSP version) there. That is all

it's the short LDC 2nd stage tank

B9PartSwitch v2.17.0 for KSP 1.10.1 Recompile against KSP 1.10.1 Update Spanish localization, add German and Chinese localization

It's actually looking more and more like the Block 2 booster development has converged with OmegA and that it will use something like those (the segments are slightly longer than the current ones)

It's on the list in the OP

The fairing thing is actually different (the fairing module looks for a specifically named object on the model), has this been reported too?

B9PartSwitch doesn't actually do anything on its own. It's up to other mods to make use of the interface it provides.

In case my previous message got buried The fairings will be broken until KSP 1.10.1 not saying they will magically work then either, but there is a critical issue that needs to be addressed on KSP's side, so nothing Restock can do until then that is all

@Superfluous J oh, the difference is @EXPERIMENT_DEFINITION[*] vs @EXPERIMENT_DEFINITION - the [*] indicates the presence of some name value to match (which experiment definitions don't have), and that has been the case for a long time in MM. Are you sure you're comparing with the same MM version?

They did before they were acquired by T2. Now T2 forbids it.

would work, yes, or anything that's lexicographically after Restock

There's no way for patch order to change based on the list of installed mods. Pick a pass that's always after the thing you want it to be after and have it always run there.

Can you check in ModuleManager.ConfigCache to see whether it looks correct? This will show you the final state of all the configs after MM has patched them but before KSP interprets them. It's a much faster way of debugging patches than trying to look for the effects in-game. It'll also tell us where to go next with the debugging.

Silly us, of course we would have learned from Youtube previews that the fairing now requires a specifically named object to exist on the base and will fail to initialize otherwise. Anyway, update on the fairings is that the problem affects other mods (not just Restock) and we can't do anything about it until KSP 1.10.1.

We would expect things to break occasionally with new KSP versions, often in unpredictable ways. We knew some updates were coming to fairings in 1.10, but the exact scope was not public until the release. Some of these issues will take time to investigate. Be patient, the team will look at them in due time.

You want @NegativeA -= 0.2807 otherwise it won't try to modify the existing value

B9PartSwitch has nothing to do with ModulePartVariants (the stock thing) other than using the same(ish) UI element.

You can enable switching in flight on the module. It's just on parameter - I don't remember the exact name but it's on the wiki.

I see only two places in RO where this is used one uses the FOR[RealismOverhaul] pass, so that should be fine the other uses FOR[RealismOverhaulEngines] so it makes sense why it wouldn't have run yet

:AFTER[RealismOverhaul] would only run if RealismOverhaul is present. Please don't ship :FINAL patches with any actual mod. They should be reserved for one-off fixes in your local install.

Syntax looks correct to me. Verify that all the capitalization is correct, whether there are any log messages about the patch, etc. And make sure you check the result in the ConfigCache rather than in-game - that can help narrow down a lot of issues.

Did whoever added ModuleEngineConfigs to AJE engines actually test that the configuration works?

Yes, that's a quite complex and there are dozens of higher priorities we haven't gotten to yet. As a side note, the characters = { and } are not valid for anything MM does because KSP uses them to parse configs before MM is even involved.