Jump to content

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


sarbian

Recommended Posts

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.   

Link to comment
Share on other sites

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 by blowfish
Link to comment
Share on other sites

 

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

 

Link to comment
Share on other sites

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]]

Link to comment
Share on other sites

@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*'

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Streetwind
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by Electrocutor
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Starwaster
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Bit Fiddler
Link to comment
Share on other sites

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

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...