Lisias Posted May 10, 2021 Share Posted May 10, 2021 (edited) 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"?.... =/ Quote Link to comment Share on other sites More sharing options...
linuxgurugamer Posted May 10, 2021 Share Posted May 10, 2021 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 Quote Link to comment Share on other sites More sharing options...
Incarnation of Chaos Posted May 10, 2021 Share Posted May 10, 2021 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...) Quote Link to comment Share on other sites More sharing options...
linuxgurugamer Posted May 10, 2021 Share Posted May 10, 2021 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 Quote Link to comment Share on other sites More sharing options...
Lisias Posted May 10, 2021 Share Posted May 10, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Incarnation of Chaos Posted May 10, 2021 Share Posted May 10, 2021 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. Quote Link to comment Share on other sites More sharing options...
Lisias Posted May 10, 2021 Share Posted May 10, 2021 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! Quote Link to comment Share on other sites More sharing options...
Incarnation of Chaos Posted May 10, 2021 Share Posted May 10, 2021 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 Quote Link to comment Share on other sites More sharing options...
KerbMav Posted May 13, 2021 Share Posted May 13, 2021 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. Quote Link to comment Share on other sites More sharing options...
Araym Posted May 23, 2021 Share Posted May 23, 2021 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? Quote Link to comment Share on other sites More sharing options...
Caerfinon Posted May 23, 2021 Share Posted May 23, 2021 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 Quote Link to comment Share on other sites More sharing options...
Araym Posted May 23, 2021 Share Posted May 23, 2021 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 Quote Link to comment Share on other sites More sharing options...
Araym Posted May 23, 2021 Share Posted May 23, 2021 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.... Quote Link to comment Share on other sites More sharing options...
Caerfinon Posted May 23, 2021 Share Posted May 23, 2021 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 Quote Link to comment Share on other sites More sharing options...
Tabris Posted June 3, 2021 Share Posted June 3, 2021 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 Quote Link to comment Share on other sites More sharing options...
blowfish Posted June 3, 2021 Share Posted June 3, 2021 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. Quote Link to comment Share on other sites More sharing options...
KerbMav Posted June 3, 2021 Share Posted June 3, 2021 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. Quote Link to comment Share on other sites More sharing options...
blowfish Posted June 6, 2021 Share Posted June 6, 2021 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. Quote Link to comment Share on other sites More sharing options...
canisin Posted June 17, 2021 Share Posted June 17, 2021 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 } } Quote Link to comment Share on other sites More sharing options...
Lisias Posted June 18, 2021 Share Posted June 18, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
canisin Posted June 18, 2021 Share Posted June 18, 2021 6 hours ago, Lisias said: ... helpful advice ... thanks a lot!!! i will be experimenting some more this evening, i'll post the results here. Quote Link to comment Share on other sites More sharing options...
canisin Posted June 18, 2021 Share Posted June 18, 2021 Here is what I ended up with, thanks to your help @Lisias topTorquePoint = #$MODULE[ModuleWheelMotor*]/torqueCurve/key,99$ @topTorquePoint ^= : .*:: Quote Link to comment Share on other sites More sharing options...
zer0Kerbal Posted June 21, 2021 Share Posted June 21, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Lisias Posted June 21, 2021 Share Posted June 21, 2021 (edited) 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! Quote Link to comment Share on other sites More sharing options...
zer0Kerbal Posted June 22, 2021 Share Posted June 22, 2021 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.