Perhaps a bit of a strange use case, but is it possible to copy arbitrarily many of a top-level node?
The MM_PATCH_LOOP {} functionality does not seem to trigger under any circumstances if the operation for the top-level node is copy. The example case given here, which would be perfect:
- does not seem to work, even explicitly as presented there (copy-pasted) - the relevant region of the config cache is as follows:
The log (expectedly) makes no mention of a loop -
<unrelated before>
[LOG 06:33:10.700] Applying update SXT/Patches/SquadPartTweaks/Satellite_Contract_Satisfaction/@Contracts to Squad/Contracts/Contracts.cfg/Contracts
[LOG 06:33:10.702] Applying update TestPatches/test/@TEST to TestPatches/test.cfg/TEST[Test]
[LOG 06:33:10.703] Applying copy TestPatches/test/$TEST[Test]:HAS[#copy[>0]] to TestPatches/test.cfg/TEST[Test]
[LOG 06:33:10.705] Applying update VenStockRevamp/Patches/IVA-Placeholders/@PART[InflatableHAB]:HAS[!INTERNAL] to VenStockRevamp/PartBin/Data/Command.cfg/PART[InflatableHAB]
<unrelated hereafter>
The first update being the addition of the count, and then the copy, with no subsequent looping. Those are the only two mentions (barring the "what files changed" at the top of the MM section of ksp.log) of test.cfg.
In my testing, barring the occasional user-error infinite loop, edit-looping works flawlessly.
Is it possible to somehow replicate this another way? For instance, something akin to:
@PART[*]:HAS[#condition]
{
// somehow copy a different top-level node
*@TOPLEVEL[Copy]/attribute = foo
}
Swapping the *@ for a *$ (and changing name rather than some other attribute) merely introduces an error - is there a way to accomplish this, if the failing loop on a copy operation is intended behaviour?
Edit: A test case on a fresh install of stock KSP (rather than a slightly out of date RP-1 installation) with MM downloaded through CKAN behaved identically:
Just a sanity check to make sure it wasn't a specific issue with the install I was working with.
