Galileo Posted January 27, 2018 Share Posted January 27, 2018 4 minutes ago, eberkain said: Trying to remove tweakscale from all engines, except SRBs, just not getting it. I anyone could tweak this to make it work I would be grateful. @PART[*]:HAS[@MODULE[ModuleEngines*]]:HAS[!RESOURCE[SolidFuel]]:FINAL { !MODULE[TweakScale] {} } Try removing the [*] after @PART. Quote Link to comment Share on other sites More sharing options...
blowfish Posted January 27, 2018 Share Posted January 27, 2018 (edited) 4 hours ago, eberkain said: Trying to remove tweakscale from all engines, except SRBs, just not getting it. I anyone could tweak this to make it work I would be grateful. @PART[*]:HAS[@MODULE[ModuleEngines*]]:HAS[!RESOURCE[SolidFuel]]:FINAL { !MODULE[TweakScale] {} } You have two top-level :HAS blocks. Try this @PART[*]:HAS[@MODULE[ModuleEngines*],!RESOURCE[SolidFuel]]:FINAL 4 hours ago, Galileo said: Try removing the [*] after @PART. Nope, not that... But the [*] is completely redundant in this case Edited January 27, 2018 by blowfish Quote Link to comment Share on other sites More sharing options...
eberkain Posted January 27, 2018 Share Posted January 27, 2018 6 hours ago, blowfish said: 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 Thanks! I'll learn my way around MM eventually. Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted January 28, 2018 Share Posted January 28, 2018 On 1/26/2018 at 7:45 PM, eberkain said: Trying to remove tweakscale from all engines, except SRBs, just not getting it. I anyone could tweak this to make it work I would be grateful. @PART[*]:HAS[@MODULE[ModuleEngines*]]:HAS[!RESOURCE[SolidFuel]]:FINAL { !MODULE[TweakScale] {} } This says find any parts that have any variant of ModuleEngines and do NOT have the resource SolidFuel. Try this: @PART[*]:HAS[#EngineType[SolidBooster]]:FINAL { !MODULE[TweakScale] {} } Unfortunately, this will also include any LES or Sepratrons. Quote Link to comment Share on other sites More sharing options...
eberkain Posted January 28, 2018 Share Posted January 28, 2018 5 hours ago, TranceaddicT said: This says find any parts that have any variant of ModuleEngines and do NOT have the resource SolidFuel. Try this: @PART[*]:HAS[#EngineType[SolidBooster]]:FINAL { !MODULE[TweakScale] {} } Unfortunately, this will also include any LES or Sepratrons. But my goal is to leave tweakscale on SRBs and remove it from all other engines. I have been working on another issue and I think I finally figured it out. some parts have defaultScale = 0.625 other parts have defaultScale = .625 HAS[#defaultScale[0.625] does not catch them both. Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted January 28, 2018 Share Posted January 28, 2018 6 hours ago, eberkain said: But my goal is to leave tweakscale on SRBs and remove it from all other engines. 1 Sorry, read that completely wrong. Anywho, try replacing 'SolidBooster' with 'LiquidFuel' Quote Link to comment Share on other sites More sharing options...
blowfish Posted January 29, 2018 Share Posted January 29, 2018 12 hours ago, eberkain said: I have been working on another issue and I think I finally figured it out. some parts have defaultScale = 0.625 other parts have defaultScale = .625 HAS[#defaultScale[0.625] does not catch them both. 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]] Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted January 30, 2018 Share Posted January 30, 2018 @eberkain I have an alternative to the previous configuration. If you haven't solved your situation try this: @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[!RESOURCE[LiquidFuel]]]:FINAL { !MODULE[TweakScale] {} } It's it different from my previous based on the 'Engine Type'. This one should remove TweakScale from any parts that have 'LiquidFuel' WITHIN 'ModuleEngines*' Quote Link to comment Share on other sites More sharing options...
eberkain Posted January 30, 2018 Share Posted January 30, 2018 I have it working, thanks for the help! Quote Link to comment Share on other sites More sharing options...
blowfish Posted January 30, 2018 Share Posted January 30, 2018 4 hours ago, TranceaddicT said: It's it different from my previous based on the 'Engine Type'. This one should remove TweakScale from any parts that have 'LiquidFuel' WITHIN 'ModuleEngines*' If you want to do that, you want to look for PROPELLANT nodes. RESOURCE is on the part, PROPELLANT is on the engine module. Quote Link to comment Share on other sites More sharing options...
Streetwind Posted February 3, 2018 Share Posted February 3, 2018 (edited) I'm currently trying to remove the incremental upgrades from some of the parts in Porkjet's PartOverhauls. But for some reason, it's not working. I have tried this: @MODULE[ModuleEngines*] { !UPGRADES {} } And also this: @MODULE[ModuleEngines*] { @UPGRADES { !UPGRADE,* {} } } And various variants thereof. This has always worked for me for deleting nodes in the past, but it's not working here. It doesn't matter which pass the patch runs in, either. Is there a different approach that I could try? Edited February 3, 2018 by Streetwind Quote Link to comment Share on other sites More sharing options...
Bit Fiddler Posted February 6, 2018 Share Posted February 6, 2018 i am getting several MM errors on load and then it says something about not creating a cache because of the errors. if i understand MM correctly this cache that is not being created will make my game load faster yes? so if i can fix the errors in the patches i can save myself some headache in the wait for my overly modded installs? Spoiler [ModuleManager] Error - more than one pass specifier on a node: Corvus/MM_Patches/Corvus_DRE/@PART[Corvus_Heatshield]:HAS[!MODULE[ModuleHeatShield]]:AFTER[DeadlyReentry]:FOR[zzz_Corvus] [ModuleManager] Error - more than one pass specifier on a node: Mk2Expansion/Patches/Mk2X_DRE/@PART[M2X_DropshipCockpit]:FOR[Mk2Expansion]:FINAL [ModuleManager] Error - more than one pass specifier on a node: Mk2Expansion/Patches/Mk2X_DRE/@PART[M2X_HypersonicNose]:FOR[Mk2Expansion]:FINAL [ModuleManager] Error - more than one pass specifier on a node: Mk2Expansion/Patches/Mk2X_DRE/@PART[M2X_SupersonicNose]:FOR[Mk2Expansion]:FINAL [ModuleManager] Error - malformed :FOR patch specifier detected: Mythological-Space-Administration/FenrirLuncherPack/Patches/FLPCommunityTechTree/@PART[FLP_UPPER01]:FOR [ModuleManager] Error - malformed :FOR patch specifier detected: Mythological-Space-Administration/FenrirLuncherPack/Patches/FLPCommunityTechTree/@PART[FLP_DownFenrir]:FOR [ModuleManager] Error - more than one pass specifier on a node: WildBlueIndustries/MCM/Parts/Stockyard250/@PART[WBI_Stockyard2502]:FOR[MCM]:FINAL [ModuleManager] Error - more than one pass specifier on a node: WildBlueIndustries/MCM/Parts/Stockyard375/@PART[WBI_Stockyard3752]:FOR[MCM]:FINAL not knowing the MM syntax that well i look at these and i think i see the problems, but just so i do not create more problems with incorrectly fixing them... How would i go aboutr fixing these 8 errors? Quote Link to comment Share on other sites More sharing options...
Electrocutor Posted February 6, 2018 Share Posted February 6, 2018 (edited) 25 minutes ago, Bit Fiddler said: i am getting several MM errors on load and then it says something about not creating a cache because of the errors. if i understand MM correctly this cache that is not being created will make my game load faster yes? so if i can fix the errors in the patches i can save myself some headache in the wait for my overly modded installs? Hide contents [ModuleManager] Error - more than one pass specifier on a node: Corvus/MM_Patches/Corvus_DRE/@PART[Corvus_Heatshield]:HAS[!MODULE[ModuleHeatShield]]:AFTER[DeadlyReentry]:FOR[zzz_Corvus] [ModuleManager] Error - more than one pass specifier on a node: Mk2Expansion/Patches/Mk2X_DRE/@PART[M2X_DropshipCockpit]:FOR[Mk2Expansion]:FINAL [ModuleManager] Error - more than one pass specifier on a node: Mk2Expansion/Patches/Mk2X_DRE/@PART[M2X_HypersonicNose]:FOR[Mk2Expansion]:FINAL [ModuleManager] Error - more than one pass specifier on a node: Mk2Expansion/Patches/Mk2X_DRE/@PART[M2X_SupersonicNose]:FOR[Mk2Expansion]:FINAL [ModuleManager] Error - malformed :FOR patch specifier detected: Mythological-Space-Administration/FenrirLuncherPack/Patches/FLPCommunityTechTree/@PART[FLP_UPPER01]:FOR [ModuleManager] Error - malformed :FOR patch specifier detected: Mythological-Space-Administration/FenrirLuncherPack/Patches/FLPCommunityTechTree/@PART[FLP_DownFenrir]:FOR [ModuleManager] Error - more than one pass specifier on a node: WildBlueIndustries/MCM/Parts/Stockyard250/@PART[WBI_Stockyard2502]:FOR[MCM]:FINAL [ModuleManager] Error - more than one pass specifier on a node: WildBlueIndustries/MCM/Parts/Stockyard375/@PART[WBI_Stockyard3752]:FOR[MCM]:FINAL not knowing the MM syntax that well i look at these and i think i see the problems, but just so i do not create more problems with incorrectly fixing them... How would i go aboutr fixing these 8 errors? FIRST, BEFORE, AFTER, FOR, and FINAL are used to determine order. NEEDS is used to determine requirements. You can have only one of each defined. Example: @PART[Corvus_Heatshield]:HAS[!MODULE[ModuleHeatShield]]:AFTER[DeadlyReentry]:FOR[zzz_Corvus] Should probably be: @PART[Corvus_Heatshield]:HAS[!MODULE[ModuleHeatShield]]:NEEDS[DeadlyReentry]:FOR[zzz_Corvus] ---- Example: @PART[M2X_DropshipCockpit]:FOR[Mk2Expansion]:FINAL Should probably be: @PART[M2X_DropshipCockpit]:FOR[Mk2Expansion] ---- Example: @PART[FLP_UPPER01]:FOR *This looks to be unfinished, so not sure what it should be, you can just remove the :FOR completely unless you know what it should be Edited February 6, 2018 by Electrocutor Quote Link to comment Share on other sites More sharing options...
Bit Fiddler Posted February 6, 2018 Share Posted February 6, 2018 yes that is what i did... i guess ill just save the files this way and restart it. worst case, i can always restore the original i guess... Quote Link to comment Share on other sites More sharing options...
Electrocutor Posted February 6, 2018 Share Posted February 6, 2018 4 minutes ago, Bit Fiddler said: yes that is what i did... i guess ill just save the files this way and restart it. worst case, i can always restore the original i guess... You should drop an issue into these mods' github or a comment in their forum about it too, so the author is aware of the issue. Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted February 6, 2018 Share Posted February 6, 2018 6 hours ago, Electrocutor said: FIRST, BEFORE, AFTER, FOR, and FINAL are used to determine order. NEEDS is used to determine requirements. You can have only one of each defined. Example: @PART[Corvus_Heatshield]:HAS[!MODULE[ModuleHeatShield]]:AFTER[DeadlyReentry]:FOR[zzz_Corvus] Should probably be: @PART[Corvus_Heatshield]:HAS[!MODULE[ModuleHeatShield]]:NEEDS[DeadlyReentry]:FOR[zzz_Corvus] ---- Example: @PART[M2X_DropshipCockpit]:FOR[Mk2Expansion]:FINAL Should probably be: @PART[M2X_DropshipCockpit]:FOR[Mk2Expansion] ---- Example: @PART[FLP_UPPER01]:FOR *This looks to be unfinished, so not sure what it should be, you can just remove the :FOR completely unless you know what it should be 5 @PART[Corvus_Heatshield]:HAS[!MODULE[ModuleHeatShield]]:AFTER[DeadlyReentry] @PART[M2X_DropshipCockpit]:FOR[Mk2Expansion] @PART[M2X_HypersonicNose]:FOR[Mk2Expansion] @PART[M2X_SupersonicNose]:FOR[Mk2Expansion] @PART[FLP_UPPER01]:FOR[ModPackName] *** @PART[FLP_DownFenrir]:FOR[ModPackName] *** @PART[WBI_Stockyard2502]:FOR[MCM] @PART[WBI_Stockyard3752]:FOR[MCM] *** Whatever mod pack these came in, insert that mod's FolderNameWithoutSpaces. Quote Link to comment Share on other sites More sharing options...
Bit Fiddler Posted February 7, 2018 Share Posted February 7, 2018 (edited) does the :NEEDS switch also imply :AFTER? or will it fire any time as long as that mod is available? Edited February 7, 2018 by Bit Fiddler Quote Link to comment Share on other sites More sharing options...
Starwaster Posted February 7, 2018 Share Posted February 7, 2018 (edited) 38 minutes ago, Bit Fiddler said: does the :NEEDS switch also imply :AFTER? or will it fire any time as long as that mod is available? :NEEDS does not imply any pass whatsoever. It's just a condition for the patch to be applied. Standard pass determination applies. Ordering is as follows :FIRST legacy (cannot be assigned manually; this is the pass a patch falls into if no specific pass was specified) Then, each modname is gone through in alphabetical order and BEFORE/FOR/AFTER passes are done for each one. (if a mod is not present by GameData/foldername, plugin name or does not have a :FOR[modname] then BEFORE and AFTER patches for that mod will not be applied) :BEFORE[modname] :FOR[modname] (do not use this if it is not your mod. EVER. It will fulfill :NEEDS[modname] even if the mod isn't really installed) :AFTER[modname] :FINAL (don't use this as a modder. It is reserved for the end user so they can have ultimate control over their game) Edited February 7, 2018 by Starwaster Quote Link to comment Share on other sites More sharing options...
Bit Fiddler Posted February 7, 2018 Share Posted February 7, 2018 and conversly? Will :AFTER imply :NEED or are the two not tied in any way? Quote Link to comment Share on other sites More sharing options...
Starwaster Posted February 7, 2018 Share Posted February 7, 2018 49 minutes ago, Bit Fiddler said: and conversly? Will :AFTER imply :NEED or are the two not tied in any way? No, as stated above, patches that specify AFTER and BEFORE will fail if the mod doesn't exist. Either it has to have a folder by that modname directly off of the GameData folder, a plugin by that modname or :FOR[modname]. Incidentally, that last is why you NEVER use :FOR if it's not your mod. It will cause conditional :NEEDS to pass which can be problematic if the mod isn't really installed. For example, heat shields have to be configured properly if RealSolarSystem is installed. Deadly Reentry does that automatically for RSS or other upscaled star systems IFF RealismOverhaul is NOT installed because RO takes care of heat shield configuration itself. So let's say some other modder decides to specify :FOR[RealismOverhaul]. But let's say RealismOverhaul is NOT really installed. But now MM fails to apply DR's patches because the :NEEDS[!RealismOverhaul] fails because of the illicit use of FOR. Players NOT using RealismOverhaul no longer have adequate protection for their upscaled non-RSS heat shield. It explodes spectacularly and the player has no idea why. Quote Link to comment Share on other sites More sharing options...
Bit Fiddler Posted February 7, 2018 Share Posted February 7, 2018 (edited) ok... it is a bit more clear now what is going on with MM... but in light of this i have seen too many mods who use these switches incorectly... it is no wonder so many times my heavily moded games suddenly implode. Edited February 7, 2018 by Bit Fiddler Quote Link to comment Share on other sites More sharing options...
danielboro Posted February 8, 2018 Share Posted February 8, 2018 is it possible to add upgrades using MM? i use an MM patch @PART[*]:HAS[@MODULE[ModuleCommand]] { MODULE { name = kOSProcessor diskSpace = 2048 } } to add a kos core to all probes and command pods but i wold like to make the core bigger as i get more thech if i can how can i do that? thanks Quote Link to comment Share on other sites More sharing options...
sarbian Posted February 8, 2018 Author Share Posted February 8, 2018 Minor patch Version 3.0.2 Allow 0 or many spaces before operator Fix :NEEDS patch order Downloads : ModuleManager.3.0.2.dll ModuleManager-3.0.2.zip Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted February 9, 2018 Share Posted February 9, 2018 ckan is apparently installing v3.0.3 is that safe? Quote Link to comment Share on other sites More sharing options...
sarbian Posted February 9, 2018 Author Share Posted February 9, 2018 Yes, it is. https://ksp.sarbian.com/jenkins/job/ModuleManager/137/changes 3.0.3 is a minor bug fix for a really specific case (Non English Linux) and I did not feel the urgency to update the post 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.