[1.8.x-1.12.x] Module Manager 4.2.3 (July 03th 2023) - Fireworks season

[Lisias]

41 minutes ago, linuxgurugamer said:

And there are still some mods out there which insist on using spaces, odd characters, etc in the part names (not title). 

There're people that still believe that uncontrolled wide use of wildcards on patching is a good idea. Kraken knows how many problems in the past would simply not happened without wildcards....  Some of that patches were so broad I could not fix them with a counter-patch - they were essentially a SQL's update without a where clausule....

(I decided to ditch wildcards on all my patching for a reason).

 

41 minutes ago, linuxgurugamer said:

This is what happened, I fixed it by replacing the parens with questionmarks

It was my understanding that the use of ? didn't worked for you, what I found intriguing and decided to check it myself...

Well... Now we have some public documentation to be pinpointed next time someone think it's a good idea to use odd chars on names.

Cheers!

Edited May 10, 2021 by Lisias
Why I just detect tyops *AFTER* clicking on "Post"?.... =/

[linuxgurugamer]

2 hours ago, Lisias said:

It was my understanding that the use of ? didn't worked for you, what I found intriguing and decided to check it myself...

Well... Now we have some public documentation to be pinpointed next time someone think it's a good idea to use odd chars on names.

It did.  The problem was a race condition on my side (ie: I was making a change and not properly doing the test due to limited time)  When I finished my stream, I was able to do a good test and validated the fix.

Thanks

[Incarnation of Chaos]

4 hours ago, Lisias said:

There're people that still believe that uncontrolled wide use of wildcards on patching is a good idea. Kraken knows how many problems in the past would simply not happened without wildcards....  Some of that patches were so broad I could not fix them with a counter-patch - they were essentially a SQL's update without a where clausule....

(I decided to ditch wildcards on all my patching for a reason).

 

It was my understanding that the use of ? didn't worked for you, what I found intriguing and decided to check it myself...

Well... Now we have some public documentation to be pinpointed next time someone think it's a good idea to use odd chars on names.

Cheers!

...in SQL land that would overwrite all rows with the values given, so are you saying that MM wildcards can potentially patch every single part with potentially erroneous values?( unlike SQL MM doesn't have any type checking...)

[linuxgurugamer]

26 minutes ago, Incarnation of Chaos said:

...in SQL land that would overwrite all rows with the values given, so are you saying that MM wildcards can potentially patch every single part with potentially erroneous values?( unlike SQL MM doesn't have any type checking...)

That is Correct 

[Lisias]

On 5/10/2021 at 4:37 PM, Incarnation of Chaos said:

...in SQL land that would overwrite all rows with the values given, so are you saying that MM wildcards can potentially patch every single part with potentially erroneous values?( unlike SQL MM doesn't have any type checking...)

Well, yep - if you are not careful on using it.

By example, lets pretend we need to remove all the resources from parts from AddOnA, AddOnB and AddOnC, all of them made by RandomAuthor:

@PART[*]:HAS[#author[RandomAuthor]]
{
	-RESOURCE[*],* {}
}

Looks great, right? RandomAuthor just published these 3 add'ons, so what could possibly go wrong?

Well, some time later, RandomAuthor leaves the Scene and his add'ons got dismembered into many others, maintained by different people, that fixed/updated/whatever the parts so they don't have to be edited anymore. Being ethical and law abiding authors, they kept RandomAuthor as the author of the new parts.

Yep, you guessed it right - that patch essentially screwed up beyound fix a lot of parts from different new add'ons.

And a stunt like this screwed up a good fraction of my modding time once on TweakScale.

What I do since them? I enumerate every single that would be fixed one by one:

@PART[part-a-from-a]:NEEDS[AddOnA]
{
	-RESOURCE[*],* {}
}
@PART[part-b-from-a]:NEEDS[AddOnA]
{
	-RESOURCE[*],* {}
}
@PART[part-a-from-b]:NEEDS[AddOnB]
{
	-RESOURCE[*],* {}
}
<etc>

Usually just the part name is enough, but I add the :NEEDS clausule as more than once I got the original part adopted on other add'on where the fix should not be applied, so I decided to err to the safer side (and :NEEDS would eliminate the whole patch if the Add'On is not installed, what's slightly faster than looking for a part - so it's a win-win situation).

Edited October 17, 2023 by Lisias
Eliminating attrition with the moderation

[Incarnation of Chaos]

5 minutes ago, Lisias said:

Well, yep - if you are not careful on using it.

By example, lets pretend we need to remove all the resources from parts from AddOnA, AddOnB and AddOnC, all of them made by RandomAuthor:

@PART[*]:HAS[#author[RandomAuthor]]
{
	-RESOURCE[*],* {}
}

Looks great, right? RandomAuthor just published these 3 add'ons, so what could possibly go wrong?

Well, some time later, RandomAuthor leaves the Scene and his add'ons got dismembered into many others, maintained by different people, that fixed/updated/whatever the parts so they don't have to be edited anymore. Being ethical and law abiding authors, they kept RandomAuthor as the author of the new parts.

Yep, you guessed it right - that patch essentially screwed up beyound fix a lot of parts from different new add'ons.

And a stunt like this fsck'd up a good fraction of my modding time once on TweakScale.

What I do since them? I enumerate every single that would be fixed one by one:

@PART[part-a-from-a]:NEEDS[AddOnA]
{
	-RESOURCE[*],* {}
}
@PART[part-b-from-a]:NEEDS[AddOnA]
{
	-RESOURCE[*],* {}
}
@PART[part-a-from-b]:NEEDS[AddOnB]
{
	-RESOURCE[*],* {}
}
<etc>

Usually just the part name is enough, but I add the :NEEDS clausule as more than once I got the original part adopted on other add'on where the fix should not be applied, so I decided to err to the safer side (and :NEEDS would eliminate the whole patch if the Add'On is not installed, what's slightly faster than looking for a part - so it's a win-win situation).

So you have to write custom exception handling for all of these rogue patches that were abandoned just so they don't nuke MM patching, specifiing the author responsible and then determine if the specific patch even needs to be rejected?

At that point I would have almost found it easier to reimplement the patches.

Mad respect for you and your work. 

[Lisias]

11 minutes ago, Incarnation of Chaos said:

So you have to write custom exception handling for all of these rogue patches that were abandoned just so they don't nuke MM patching, specifiing the author responsible and then determine if the specific patch even needs to be rejected?

Well, more or less. I can't detect rogue patches, only badly patched parts. Once something bad is detected,  TS issues a Warning or Fatality and then someone (usually me ) needs to hunt down who screwed up by eye balling everybody that touched the broken part.

In the end, I just write all my patches without using wide wildcards at all - all of them, not only the hot fixes and workarounds.

It's tedious sometimes, but it's way safer (and polite, to tell the true) to "invest" a bit more of my time once than waste it (and others too) forever handling unwanted colateral damage because I could  not foresee the future!

Conciseness and quality are not synonymous. 

 

22 minutes ago, Incarnation of Chaos said:

At that point I would have almost found it easier to reimplement the pstches

It's what I did on my patches. But I'm not the only patcher around, and a few authors still rely on such wide wildcards even nowadays.  It's a cat and mouse game, there's  nothitng else I can do.

 

25 minutes ago, Incarnation of Chaos said:

Mad respect for you and your work. 

The madness never ends!

[Incarnation of Chaos]

2 minutes ago, Lisias said:

Well, more or less. I can't detect rogue patches, only badly patched parts. Once something bad is detected,  TS issues a Warning or Fatality and then someone (usually me ) needs to hunt down who screwed up by eye balling everybody that touched the broken part.

In the end, I just write all my patches without using wide wildcards at all - all of them, not only the hot fixes and workarounds.

It's tedious sometimes, but it's way safer (and polite, to tell the true) to "invest" a bit more of my time once than waste it (and others too) forever handling unwanted colateral damage because I could  not foresee the future!

Conciseness and quality are not synonymous. 

 

It's what I did on my patches. But I'm not the only patcher around, and a few authors still rely on such wide wildcards even nowadays.  It's a cat and mouse game, there's  nothitng else I can do.

 

The madness never ends!

Oh yeah, I'm just commenting on the level of effort on display here. Nothing more.

Also it's KSP, the moment the madness ends is the moment something has truly gone wrong lel

[KerbMav]

From https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering

"You can control how module manager applies patches through these five directives, that are applied at the top-level node. Only ONE of these directives can be applied to a specific top-level patch."

 

So I cannot do ...:FOR[abc]:AFTER[xyz] ?

 

Specifically I want SMURFF (which uses :FOR[zzz_SMURFF] ) to run before SimpleFuelSwitch (which uses :FOR[SimpleFuelSwitch] ).
To avoid the alphabetical order I wanted to add :AFTER[SMURFF] to SimpleFuelSwitch (because that would be only two lines to change).

As far as I can see SMURFF does not recognize SimpleFuelSwitch, that is why I want them to run in that order.

[Araym]

Help question:

I have an HEAVILY modded install, and suddenly it's trowing 2 Modulemanager Warnings that I never noticed before, just when it start to loads patches.

I'm trying to find it on the log, but I'm kind of lost in search of it.

Any hints about what I should look for in my notepad+ "search" function?

[Caerfinon]

10 minutes ago, Araym said:

Any hints about what I should look for in my notepad+ "search" function?

look for "Done patching". Warnings will be listed following it.

Example:

[LOG 16:11:00.374] Done patching
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-120.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-122.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-124.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-201.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-202.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-203.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-30.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-320.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-322.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-324.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-360.cfg

 

[Araym]

1 minute ago, Caerfinon said:

look for "Done patching". Warnings will be listed following it.

Example:

[LOG 16:11:00.374] Done patching
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-120.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-122.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-124.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-201.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-202.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-203.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-30.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-320.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-322.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-324.cfg
[WRN 16:11:00.374] 1 warning related to GameData/ContractPacks/GAP/Flights/Airline-Flight-360.cfg

 

Thanks. I will use this hint for future reference.

In meantime I kind of worked back my latest installe mods (I changed a couple of things) and someway I reduced the culprits to a couple of them (pulling them from the install, untill I saw the error disappearing), so for the moment I have just to check them one by one to find what is behaving strangely

 

[Araym]

15 minutes ago, Caerfinon said:

look for "Done patching". Warnings will be listed following it.

Just an additional question: to properly find that warning list, should I leave the entire game to load, or could I "kill" the loading just after MM is done patching, but the game is still loading all the assests?

I'm asking just because this is occurring in my main install, that is VERY HEAVILY modded, and it needs to half an hour to fully load all the game, each time....

[Caerfinon]

6 minutes ago, Araym said:

Just an additional question:

You could safely kill the load after module manager is completed

Also you could see specific module manager logs in the \Kerbal Space Program\Logs\ModuleManager folder that would contain the same information as the ksp.log without the extra bits

[Tabris]

Hey All,
trying to make a MM patch that will add ModuleScienceContainer to anything with the module KOSProcessor

This is what i have so far

@PART[*]:HAS[@MODULE[kOSProcessor],!MODULE[KerbalEVA]]
{
	%MODULE
	{
		Name = ModuleScienceContainer
		reviewActionName = #autoLOC_502201 //#autoLOC_502201 = Review Stored Data
		storeActionName = #autoLOC_502202 //#autoLOC_502202 = Store Experiments
		evaOnlyStorage = False // i.e. can nearby regular vessels also do this, or EVA only
		capacity = 0
		storageRange = 1.3
		canBeTransferredToInVessel = True
		canTransferInVessel = True
		showStatus = True
	}
}

This is from the ModuleManager.ConfigCache showing that the ModuleScienceContainer gets added to the part

Spoiler

UrlConfig
{
	parentUrl = kOS-EVA/Parts/kOSPad3.cfg
	PART
	{
		name = kOSPad3
		module = Part
		author = GER-Space
		rescaleFactor = 1
		node_attach = 0, 0, 0, 1, 0, 0, 1
		TechRequired = start
		entryCost = 8000
		cost = 800
		category = Control
		subcategory = 0
		title = kOS Pad Air 3
		manufacturer = Compotronix
		description = The latest computer tech in a small package with unlimited runtime. A short range LTE transmitter is included.
		attachRules = 0,0,0,0,0
		mass = 0.001
		dragModelType = default
		maximum_drag = 0.2
		minimum_drag = 0.2
		angularDrag = 2
		crashTolerance = 8
		maxTemp = 1200
		breakingForce = 50
		breakingTorque = 50
		bulkheadProfiles = srf
		MODEL
		{
			model = kOS-Pad/Assets/kPad
			scale = 0.1, 0.1, 0.1
		}
		MODULE
		{
			name = ModuleKISItem
			shortcutKeyAction = custom
			usableFromEva = true
			usableFromPod = false
			usableFromEditor = false
			equipable = true
			equipMode = part
			equipSlot = leftHand
			equipMeshName = body01
			equipBoneName = bn_l_mid_a01
			equipPos = (-0.03, 0.01 ,0.05)
			equipDir = ( 180,75,90)
			allowPartAttach = 0
			allowStaticAttach = 0
			stackable = false
		}
		MODULE
		{
			name = kOSProcessor
			diskSpace = 500
			ECPerBytePerSecond = 0
			ECPerInstruction = 0
		}
		MODULE
		{
			name = ModuleDataTransmitter
			packetInterval = 0.6
			packetSize = 1
			packetResourceCost = 0
			requiredResource = ElectricCharge
			DeployFxModules = 0
			JNSQ = True
		}
		RESOURCE
		{
			name = ElectricCharge
			amount = 5
			maxAmount = 5
		}
		MODULE
		{
			name = USI_ModuleRecycleablePart
			Menu = Disassemble Part
			ResourceName = MaterialKits
			Efficiency = .5
		}
		MODULE
		{
			name = KOSNameTag
		}
		MODULE
		{
			Name = ModuleScienceContainer
			reviewActionName = Review Stored Data
			storeActionName = Store Experiments
			evaOnlyStorage = False
			capacity = 0
			storageRange = 1.3
			canBeTransferredToInVessel = True
			canTransferInVessel = True
			showStatus = True
		}
	}
}

 

However when using

print ship:partstagged("test"):modules.

it doesn't list the module on the part or the actions on the PAW

 

[blowfish]

On 5/9/2021 at 3:25 PM, linuxgurugamer said:

Is it because of the parantheses?  If so, then if I replace the parens with questionmarks, it should work, right?

Edit:  I tried replacing the parens with questionmarks, didn't change the error

KSP strips out everything after the first parenthase before MM even gets there.  Can you show what happens when all of them are replaced with question marks?

On 5/13/2021 at 1:25 AM, KerbMav said:

From https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering

"You can control how module manager applies patches through these five directives, that are applied at the top-level node. Only ONE of these directives can be applied to a specific top-level patch."

 

So I cannot do ...:FOR[abc]:AFTER[xyz] ?

 

Specifically I want SMURFF (which uses :FOR[zzz_SMURFF] ) to run before SimpleFuelSwitch (which uses :FOR[SimpleFuelSwitch] ).
To avoid the alphabetical order I wanted to add :AFTER[SMURFF] to SimpleFuelSwitch (because that would be only two lines to change).

As far as I can see SMURFF does not recognize SimpleFuelSwitch, that is why I want them to run in that order.

Each of those passes runs in alphabetical order.

[KerbMav]

30 minutes ago, blowfish said:

Each of those passes runs in alphabetical order.

And since sImple comes before sMurff - but I want them to run the other way around. Which is why I asked for clarification on the “only one directive” part.

I could check whether I can rename Smurff easily.

[blowfish]

On 6/2/2021 at 11:30 PM, KerbMav said:

And since sImple comes before sMurff - but I want them to run the other way around. Which is why I asked for clarification on the “only one directive” part.

I could check whether I can rename Smurff easily.

Well each patch is only run once.  So there has to be one thing that uniquely tells MM when to run the patch.

[canisin]

Hello!

Can anyone spot my mistake here?

Quote

// store rover wheels' max speed for later use
@PART[*]:HAS[@MODULE[ModuleWheelMotor*],!MODULE[RSE_Wheels]]:FINAL
{
    topTorquePoint = #$MODULE[ModuleWheelMotor*]/torqueCurve/key,-1[0, ]$
}

I had expected to store the first element of the last key, but I ended up storing all of the first key.

Sample result from my cache:

Quote

topTorquePoint = 0 0.17 0 0

for

Quote

        MODULE
        {
            name = ModuleWheelMotor
            baseModuleIndex = 0
            wheelSpeedMax = 11
            driveResponse = 2
            idleDrain = 0.0
            torqueCurve
            {
                key = 0 0.17 0 0
                key = 2.5 0.1 0 0
                key = 12 0 0 0
            }
            RESOURCE
            {
                name = ElectricCharge
                rate = 1
            }
        }

 

[Lisias]

On 6/16/2021 at 10:09 PM, canisin said:

Hello!

Can anyone spot my mistake here?

I had expected to store the first element of the last key, but I ended up storing all of the first key.

One problem you have for sure is that MM appears to do not understand negative indexes (the relevant source code is here, if you are really curious, your use case starts to be handled here).

After parsing your path, in the very end the index is handled here. This function, FindValueIn, starts looking on index 0 of the array, and stops as soon as the selected index counter is negative. Since your index is already negative, it returns the first value.

This explains that command returning the "0 0.17 0 0" value, as it is the first entry on the "array".  (The wiki also states negative indexes are not yet supported here, look for "(,<index>)?").

However, your second problem is confusing me. This post explains that "[0, ]" should be working as expected - you want the second value from a space separated list of values, so the expected result should be 0.17... Perhaps some bug on the parser?

Try this:

    %temp = #$MODULE[ModuleWheelMotor*]/torqueCurve/key,-1$
    %topTorquePoint = #$temp[0, ]$
    -temp = Kill me!

It's a wild guess,  but if this works it will result with 0.17 on the topTorquePoint - what at least solves part of your problem while we try to tackle down the other part (perhaps a hack using MM_PATCH_LOOP ?)

Edited June 18, 2021 by Lisias
Fixing the hack

[canisin]

6 hours ago, Lisias said:

... helpful advice ...

thanks a lot!!! i will be experimenting some more this evening, i'll post the results here. 

[canisin]

Here is what I ended up with, thanks to your help @Lisias

	topTorquePoint = #$MODULE[ModuleWheelMotor*]/torqueCurve/key,99$
	@topTorquePoint ^= : .*::

 

[zer0Kerbal]

this one has me flummoxed (probably too much Jeb Coffee and not enough sleep).

Here is the error:

[ERR 01:33:05.237] Error - Cannot parse variable search when editing key MonoPropellant = #$MaxEC$
[WRN 01:33:05.236] Cannot find key ODFCMaxEC in MODULE

Here is the code

ODFCMaxEC was defined in a patch that runs earlier.

Spoiler

...
@PART[DM-RFC]:NEEDS[ODFC]:AFTER[ODFC]
{
	@MODULE[ODFC]
	{
		%ODFCMaxEC = 1.5
		@MODE[MP]
		{
			@MaxEC = #$../MODULE[ODFC]/ODFCMaxEC$
			@FUELS
			{
				@MonoPropellant *= #$../MaxEC$
			}
		}
		@MODE[LFO]
		{
			@MaxEC =#$../ODFCMaxEC$
			@FUELS
			{
				@LiquidFuel *= #$../MaxEC$
				@Oxidizer *= #$../MaxEC$
			}
		}
...

 

it should pull from one level up which is MODULE[ODFC] where ODFCMaxEC lives

 all can afford to pay is in reputation and gratitude!

Edited June 21, 2021 by zer0Kerbal

[Lisias]

12 hours ago, zer0Kerbal said:

Here is the code

ODFCMaxEC was defined in a patch that runs earlier.

  Reveal hidden contents

...
@PART[DM-RFC]:NEEDS[ODFC]:AFTER[ODFC]
{
	@MODULE[ODFC]
	{
		%ODFCMaxEC = 1.5
		@MODE[MP]
		{
			@MaxEC = #$../MODULE[ODFC]/ODFCMaxEC$
			@FUELS
			{
				@MonoPropellant *= #$../MaxEC$
			}
		}
		@MODE[LFO]
		{
			@MaxEC =#$../ODFCMaxEC$
			@FUELS
			{
				@LiquidFuel *= #$../MaxEC$
				@Oxidizer *= #$../MaxEC$
			}
		}
...

 

it should pull from one level up which is MODULE[ODFC] where ODFCMaxEC lives

 all can afford to pay is in reputation and gratitude!

Think on the GameDatabase as it was a filesystem, with a twist: "../" means the parent dir (or node), but the current mode is given by "/" - while the "root" is given by "@". It's a bit confusing because everybody is used to "..", "." and "/" to do this job.

So, think on the nodes as directories, and the values as files. You have, so, something like this (names ending with "/" are directories on this representation):

PART[DM-RFC]/
	MODULE[ODFC]/
		ODFCMaxEC
		MODE[MP]/
			MaxEC
			FUELS/
				MonoPropellant
		MODE[LFO]/
			MaxEC
			FUELS/
				LiquidFuel
				Oxidizer

What you wrote, so, is something like this:

PART[DM-RFC]/
	MODULE[ODFC]/
		ODFCMaxEC
		MODE[MP]/
			MaxEC = ../MODULE[ODFC]/ODFCMaxEC // Whoops!
			FUELS/
				MonoPropellant
		MODE[LFO]/
			MaxEC
			FUELS/
				LiquidFuel
				Oxidizer

MaxEC will take a value called ODFCMaxEC from a MODULE[ODFC] that it's on its parent, i.e., it's looking for a module that it's "its brother". What is not what you want, the value is not inside a "brother" module, it's on its parent itself!

PART[DM-RFC]/
	MODULE[ODFC]/
		ODFCMaxEC
		MODE[MP]/
			MaxEC = ../ODFCMaxEC // This should work!
			FUELS/
				MonoPropellant
		MODE[LFO]/
			MaxEC
			FUELS/
				LiquidFuel
				Oxidizer

So, what you need is:

			@MaxEC = #$../ODFCMaxEC$

Spoiler

As an exercise, if you are willing to have fun with the reader, you can also do this:

			MaxEC = ../../MODULE[ODFC]/ODFCMaxEC // This also works. ]:->

 

when in doubt, "simulate" the GameDatabase on the file system the way I did. Things will be easier this way.

Cheers!

Edited June 21, 2021 by Lisias
tyop!

[zer0Kerbal]

14 hours ago, Lisias said:

Cheers!

Thank you!

turns out I was doing something else wrong... later in the same patch at the same level I was 

Spoiler

	!ODFCMaxEc {} // clean up

 

I am guessing that MM processes everything on a level before moving downstream so by deleting the key, MM couldn't find it even if the deletion appeared after the rest in the patch.