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

[Drew Kerman]

4 hours ago, Sahadara said:

So if I found a common identifier in all the parts, how would I then target all parts with that identifier? Sorry I'm very new to creating patches.

@PART[*]:HAS[#manufacturer[Kerbal?Standard]]:FINAL
{
  // do stuff
}

That's using the manufacturer field to ID parts from the Airplane Plus/Grounded mods from Blackheart

[Sahadara]

15 hours ago, Drew Kerman said:

@PART[*]:HAS[#manufacturer[Kerbal?Standard]]:FINAL
{
  // do stuff
}

That's using the manufacturer field to ID parts from the Airplane Plus/Grounded mods from Blackheart

Thank you! I'll try this as soon as I can. My PC is out of commission right now and I'm waiting on repairs.

[Stone Blue]

On 11/15/2019 at 4:01 PM, Sahadara said:

Is there a way to edit all parts from a given mod?

MM is very flexible. Meaning there are usually moar than one way to skin a cat

It all depends on your targeted parts. If, like you said, you want to target parts specific to a single (or even multiple mods), you can specify the name of the mod(s) folder(s).

ie
 

@PART[*]:NEEDS[<mod(s)folder(s)_name>]
{

	do stuff

}

	

if targeting 2 or moar mod folders, seperate the folder names with a comma, inside the single set of brackets.
I gave an example of a general patch. the top line can have additional filters/logic depending on what set of parts you want to target.
Just realise, that you have to keep in mind what youre trying to do, how youre trying to do it, and how it might affect any other installed patches trying to target the same set of parts.
You dont want to end up with conflicting or overlapping patches.

Edited November 17, 2019 by Stone Blue

[Jognt]

3 hours ago, Stone Blue said:

MM is very flexible. Meaning there are usually moar than one way to skin a cat

It all depends on your targeted parts. If, like you said, you want to target parts specific to a single (or even multiple mods), you can specify the name of the mod(s) folder(s).

ie
 

@PART[*]:NEEDS[<mod(s)folder(s)_name>]
{

	do stuff

}

	

if targeting 2 or moar mod folders, seperate the folder names with a comma, inside the single set of brackets.
I gave an example of a general patch. the top line can have additional filters/logic depending on what set of parts you want to target.
Just realise, that you have to keep in mind what youre trying to do, how youre trying to do it, and how it might affect any other installed patches trying to target the same set of parts.
You dont want to end up with conflicting or overlapping patches.

That would target every part if the folder is present, not target just that folder. 

[Drew Kerman]

@Stone Blue does that really do what you think it does? I interpret that example as affecting every part in the game as long as you have that specific mod folder installed

edit gaaaaah I was JUST about to hit submit when the forum blipped a response and I was like crap I think I was just ninja'd

Edited November 17, 2019 by Drew Kerman

[Jognt]

1 hour ago, Drew Kerman said:

@Stone Blue does that really do what you think it does? I interpret that example as affecting every part in the game as long as you have that specific mod folder installed

edit gaaaaah I was JUST about to hit submit when the forum blipped a response and I was like crap I think I was just ninja'd

[Sahadara]

In line with what I previously asked, is there a way to change the mass of a stock resource? I'm trying to get realistic mass fractions with a combination of SMURFF and my own configs. SMURFF changes the mass tanks but doesn't touch the mass of the fuel which is also way too heavy. Is it possible to make Liquidfuel lighter with module manager? If not is there another mod that allows this?

Thanks in advance.

[blowfish]

24 minutes ago, Sahadara said:

In line with what I previously asked, is there a way to change the mass of a stock resource? I'm trying to get realistic mass fractions with a combination of SMURFF and my own configs. SMURFF changes the mass tanks but doesn't touch the mass of the fuel which is also way too heavy. Is it possible to make Liquidfuel lighter with module manager? If not is there another mod that allows this?

Thanks in advance.

Is it actually too heavy?  Recall that one KSP volume unit is about equivalent to 5 liters.  My recollection is that the density isn't too far off from actual fuels.

That being said, it is possible to modify a RESOURCE_DEFINITION with ModuleManager just like anything else.

[Sahadara]

1 hour ago, blowfish said:

Is it actually too heavy?  Recall that one KSP volume unit is about equivalent to 5 liters.  My recollection is that the density isn't too far off from actual fuels.

That being said, it is possible to modify a RESOURCE_DEFINITION with ModuleManager just like anything else.

Hmm. I had read posts by others saying that the density was something like 5 times higher than RP-1. I believed that they'd used the tank volume rather than the arbitrary ksp unit. But I might have misread. I'll have to check myself. If I do want to change it, how do I go about targeting the resource? Would I have to do anything differently because it's a stock resource rather than a mod introduced one? Also would I be able to do something like mass*=.2 to reduce it by a factor of 5? Thanks for the help!

[blowfish]

2 hours ago, Sahadara said:

Hmm. I had read posts by others saying that the density was something like 5 times higher than RP-1. I believed that they'd used the tank volume rather than the arbitrary ksp unit. But I might have misread. I'll have to check myself. If I do want to change it, how do I go about targeting the resource? Would I have to do anything differently because it's a stock resource rather than a mod introduced one? Also would I be able to do something like mass*=.2 to reduce it by a factor of 5? Thanks for the help!

Every config in GameData* gets put into the same place, then MM applies patches, then KSP (or mods) pull the pieces they need out and interpret them.  No difference between stock and modded stuff.  First, let's look at the thing you're trying to edit:

Spoiler

RESOURCE_DEFINITION
{
  name = LiquidFuel
  density = 0.005
}

(some irrelevant bits excluded)

So what top-level node do do you want to target?

a RESOURCE_DEFINITION with name = LiquidFuel

What do you want to do to it?

edit it

What do you want to modify in it?

the density value

What do you want to do to that value?

modify it

How do you want to modify it?

Multiply by 0.2

Spoiler

@RESOURCE_DEFINITION[LiquidFuel]:FINAL
{
    @density *= 0.2
}

 

A couple more things to note about this patch:

• The bit in brackets is special syntax for targeting the name, however you can match other values (and subnodes)too
• I added :FINAL which tells MM to run this patch at the end.  Generally you want to specify when you want MM to run your patch, although in this case it probably doesn't matter.  For personal patches that are only going to exist in your install, :FINAL makes sense since it'll run after everything else, however for patches distributed in a mod you should not use FINAL (since other mods may need to change things afterward)

[Sahadara]

2 hours ago, blowfish said:

Every config in GameData* gets put into the same place, then MM applies patches, then KSP (or mods) pull the pieces they need out and interpret them.  No difference between stock and modded stuff.  First, let's look at the thing you're trying to edit:

  Hide contents

RESOURCE_DEFINITION
{
  name = LiquidFuel
  density = 0.005
}

(some irrelevant bits excluded)

So what top-level node do do you want to target?

a RESOURCE_DEFINITION with name = LiquidFuel

What do you want to do to it?

edit it

What do you want to modify in it?

the density value

What do you want to do to that value?

modify it

How do you want to modify it?

Multiply by 0.2

  Hide contents

@RESOURCE_DEFINITION[LiquidFuel]:FINAL
{
    @density *= 0.2
}

 

A couple more things to note about this patch:

• The bit in brackets is special syntax for targeting the name, however you can match other values (and subnodes)too
• I added :FINAL which tells MM to run this patch at the end.  Generally you want to specify when you want MM to run your patch, although in this case it probably doesn't matter.  For personal patches that are only going to exist in your install, :FINAL makes sense since it'll run after everything else, however for patches distributed in a mod you should not use FINAL (since other mods may need to change things afterward)

Thank you! I'm still new to module manager and this is very helpful.

[EngineerMartijn]

Hello guys,

I was wondering if it is possible to add for example inventory slots to inflatable parts like Kerbalow KEAM but only if it is inflated. So when it is packed no inventory, but once it is inflated i have some inventory slots from KIS.
Right now it has some inventory slots, but i like to have them only when the part is on full size.

Have been looking around already, but could not find anything yet.

Thanks in advance
 

[paul23]

I've a question about the syntax:

 

Can one put multiple after statements in a row? Or multiple "needs"?

 

Also is it possible to work by sub folder? IE, after `gamedate/myMod/somepatch`?

[Aelfhe1m]

48 minutes ago, paul23 said:

I've a question about the syntax:

 

Can one put multiple after statements in a row? Or multiple "needs"?

 

Also is it possible to work by sub folder? IE, after `gamedate/myMod/somepatch`?

You can only have one AFTER or NEEDS per patch. Because AFTER defines when a patch is run it must have a single value but NEEDS can refer to multiple mods so the following would be valid :AFTER[modA]:NEEDS[modB,modC,modD]

Sub folders are valid inside NEEDS but not AFAIK inside BEFORE, FOR, AFTER (although I haven't tried this recently and it might just be missing from the change list).

[paul23]

Well how to define subfolders?

[Aelfhe1m]

55 minutes ago, paul23 said:

Well how to define subfolders?

In your own mod or referencing some other mod?

If the sub-folder contains a DLL then that DLL name will be added to ModuleManager's list automatically (for example USI-LifeSupport and KolonyTools are DLLs that are inside separate sub-folders of /GameData/UmbraSpaceIndustries). Alternatively a patch inside the sub-folder may define a unique name using a FOR (never use FOR outside of the mod owning the name) e.g. FOR[FelineUtilityRover] is defined by a patch inside folder /GameData/KerbetrotterLtd/FelineUtilityRover.

A list of the names defined in your particular install can be found near the start of the ModuleManager log ([KSP]/Logs/ModuleManager/ModuleManager.log)

 

Edited November 22, 2019 by Aelfhe1m
MKS is actually from a FOR[] the DLL is KolonyTools

[paul23]

Well for inside another mod:

 

StationPartsRedux has a subfolder called "patches". This contains patches for the station parts for several popular lifesupport mods (ie adding a USI habitat module). Now I wish to "modify" this, as the patch is giving way to high habitat numbers compared to vanilla USI, outshining them by a factor 10.

 

So I wish to run *after* the patch of stationpartredux, which has a part patch defined like:

 

@PART[sspx-habitation-125-1]:NEEDS[USILifeSupport]

Inside the folder gamedate/stationpartredux/patches

[Idleness]

6 minutes ago, paul23 said:

Well for inside another mod:

 

StationPartsRedux has a subfolder called "patches". This contains patches for the station parts for several popular lifesupport mods (ie adding a USI habitat module). Now I wish to "modify" this, as the patch is giving way to high habitat numbers compared to vanilla USI, outshining them by a factor 10.

Aside question - why not just modify that .cfg that already exists for that part?  If you think the numbers aren't good for your install/balance, change them in the already defined config.

[paul23]

Just now, Idleness said:

Aside question - why not just modify that .cfg that already exists for that part?  If you think the numbers aren't good for your install/balance, change them in the already defined config.

Because updates. In a world with ckan (or from more experience: linux patches) it's best to write "patches" instead of directly modifying the module itself. CKAN/snappy/apt will otherwise overwrite the settings, and while with high profile mods this is quickly remedied it's a general idea I try to uphold with anything. (IE if stationpartredux was an implied mod by another mod it might update if I update that other mod, without me actually directly noticing).

[Jacke]

9 minutes ago, Idleness said:

Aside question - why not just modify that .cfg that already exists for that part?  If you think the numbers aren't good for your install/balance, change them in the already defined config.

Because the mod comes from one source (the upstream mod developer) and the metamodding of the values comes from another, @paul23.  Which is why it handles upgrades of the mod better.

[Aelfhe1m]

1 hour ago, paul23 said:

Well for inside another mod:

 

StationPartsRedux has a subfolder called "patches". This contains patches for the station parts for several popular lifesupport mods (ie adding a USI habitat module). Now I wish to "modify" this, as the patch is giving way to high habitat numbers compared to vanilla USI, outshining them by a factor 10.

 

So I wish to run *after* the patch of stationpartredux, which has a part patch defined like:

 

 

@PART[sspx-habitation-125-1]:NEEDS[USILifeSupport]

 

Inside the folder gamedate/stationpartredux/patches

Since the patch in SSPX does not specify any pass information (before,for,after etc.) then it will be applied near the beginning of the patching process during the legacy pass.

So any valid AFTER[] would come later and override its settings. That lets you use after with the top level folder name (or final if this is a personal patch and not something you're going to distribute). Then include the settings you think should apply and they will overwrite whatever the SSPX patch applied.

e.g.

@PART[sspx-habitation-125-1]:AFTER[StationPartsExpansionRedux]:NEEDS[USILifeSupport]

or

@PART[sspx-habitation-125-1]:NEEDS[USILifeSupport]:FINAL

If the patch you were trying to override had included a before, for or after then one trick is to pick another mod that is sorted after it in alphabetic order and use that mods name.

ModuleManager applies patches in the order -

Spoiler

• insert (initial raw values from all cfgs)
• first
• legacy (default)    [this is where the SSPX patch would apply]
• before[A]
• for[A]
• after[A]
• before[BB]
• for[BB]
• after[BB]
• ... and all the other recognised mod names (folders, dlls, for[]) in alphabetic order
• after[ZZZZZZZZZZZZZZZZ]
• last[A]
• ...
• last[ZZZZZZZZZZZZZZZZ]
• final

Patches that run at the same pass level are applied in order of path and filename (e.g. a/1.cfg, a/2.cfg, b/1.cfg).

This is why I keep all my personal patches in a folder named ZZZ_Custom then I can use :AFTER[ZZZ_Custom] to come very near the end of the patching order but still have room for LAST or FINAL patches that might need to run even later.

Edited November 22, 2019 by Aelfhe1m
fixing formatting - it really didn't like B as a mod name

[Jognt]

3 hours ago, paul23 said:

Well for inside another mod:

 

StationPartsRedux has a subfolder called "patches". This contains patches for the station parts for several popular lifesupport mods (ie adding a USI habitat module). Now I wish to "modify" this, as the patch is giving way to high habitat numbers compared to vanilla USI, outshining them by a factor 10.

 

So I wish to run *after* the patch of stationpartredux, which has a part patch defined like:

 

 

@PART[sspx-habitation-125-1]:NEEDS[USILifeSupport]

 

Inside the folder gamedate/stationpartredux/patches

There is no FOR in that patch so you can’t do a AFTER. 

You CAN give your patch a filename that is alphabetically later, adding a ‘x’ In front will make MM execute your patch later. If the patch in question already has a Z at the start, and another to yours.  

If you’re feeling adventurous you can also define a ‘mod’ of your own like using FOR[paul23sPatches] since BEFORE/FOR/AFTER happens after the legacy pass. (Good way to execute personal patches or patches to mods that aren’t using FOR passes)

For more details on patch ordering I highly recommend checking the MM wiki. Or open your MM patching log in the KSP/logs folder as it shows line by line what patch it’s executing in what pass. 

Edit: you could also poke the mod author to update the patches to use the proper FOR format. Then you can just use AFTER as intended. 

3 hours ago, Idleness said:

Aside question - why not just modify that .cfg that already exists for that part?  If you think the numbers aren't good for your install/balance, change them in the already defined config.

This is generally a bad idea. It’s easier for beginners, sure. But down the line you introduce complexity where you have to re-do it when updates are released and since you’re messing with mod’s own files, any issues arising from that will be very hard to track down and troubleshoot. 

Just make your own patches and save them in your personal ‘mod’ folder. Easy to use, share, maintain, and disable when troubleshooting. 

Edited November 22, 2019 by Jognt

[Aelfhe1m]

1 hour ago, Jognt said:

There is no FOR in that patch so you can’t do a AFTER.

You can use AFTER for ANY name that MM recognises. In this case that would be the top level StationPartsExpansionRedux folder. While it's true the patch (or patch folder) doesn't have any unique identifier I'm not sure it's really needed either so no need to poke Nertea to add a FOR. Indeed in my current game I've modded parts from SSPX myself using :AFTER[StationPartsExpansionRedux] and they appear in the correct part of the MM log

Spoiler

...
[LOG 20:10:27.899] :BEFORE[STAGERECOVERY] pass
[LOG 20:10:27.899] :FOR[STAGERECOVERY] pass
[LOG 20:10:27.899] :AFTER[STAGERECOVERY] pass
[LOG 20:10:27.899] :BEFORE[STATIONKEEPING] pass
[LOG 20:10:27.899] :FOR[STATIONKEEPING] pass
[LOG 20:10:27.899] :AFTER[STATIONKEEPING] pass
[LOG 20:10:27.899] :BEFORE[STATIONPARTSEXPANSIONREDUX] pass
[LOG 20:10:27.899] :FOR[STATIONPARTSEXPANSIONREDUX] pass
[LOG 20:10:27.899] :AFTER[STATIONPARTSEXPANSIONREDUX] pass
[LOG 20:10:27.923] Applying update StationPartsExpansionRedux/Patches/SSPXR-MKS-Extras/@PART[sspx-greenhouse-25-1|sspx-greenhouse-375-1]:NEEDS[USILifeSupport,MKS]:AFTER[StationPartsExpansionRedux] to StationPartsExpansionRedux/Parts/Rigid/station-25/sspx-greenhouse-25-1.cfg/PART[sspx-greenhouse-25-1]
[LOG 20:10:27.923] Applying update StationPartsExpansionRedux/Patches/SSPXR-MKS-Extras/@PART[sspx-greenhouse-25-1|sspx-greenhouse-375-1]:NEEDS[USILifeSupport,MKS]:AFTER[StationPartsExpansionRedux] to StationPartsExpansionRedux/Parts/Rigid/station-375/sspx-greenhouse-375-1.cfg/PART[sspx-greenhouse-375-1]
[LOG 20:10:27.929] :BEFORE[STRATEGIA] pass
[LOG 20:10:27.929] :FOR[STRATEGIA] pass
[LOG 20:10:27.930] Applying update Strategia/CustomBarnKitConfig/@CUSTOMBARNKIT:FOR[Strategia] to CustomBarnKit/default.cfg/CUSTOMBARNKIT
[LOG 20:10:27.931] :AFTER[STRATEGIA] pass
...

 

 

[Jognt]

1 hour ago, Aelfhe1m said:

You can use AFTER for ANY name that MM recognises. In this case that would be the top level StationPartsExpansionRedux folder. While it's true the patch (or patch folder) doesn't have any unique identifier I'm not sure it's really needed either so no need to poke Nertea to add a FOR. Indeed in my current game I've modded parts from SSPX myself using :AFTER[StationPartsExpansionRedux] and they appear in the correct part of the MM log

  Hide contents

...
[LOG 20:10:27.899] :BEFORE[STAGERECOVERY] pass
[LOG 20:10:27.899] :FOR[STAGERECOVERY] pass
[LOG 20:10:27.899] :AFTER[STAGERECOVERY] pass
[LOG 20:10:27.899] :BEFORE[STATIONKEEPING] pass
[LOG 20:10:27.899] :FOR[STATIONKEEPING] pass
[LOG 20:10:27.899] :AFTER[STATIONKEEPING] pass
[LOG 20:10:27.899] :BEFORE[STATIONPARTSEXPANSIONREDUX] pass
[LOG 20:10:27.899] :FOR[STATIONPARTSEXPANSIONREDUX] pass
[LOG 20:10:27.899] :AFTER[STATIONPARTSEXPANSIONREDUX] pass
[LOG 20:10:27.923] Applying update StationPartsExpansionRedux/Patches/SSPXR-MKS-Extras/@PART[sspx-greenhouse-25-1|sspx-greenhouse-375-1]:NEEDS[USILifeSupport,MKS]:AFTER[StationPartsExpansionRedux] to StationPartsExpansionRedux/Parts/Rigid/station-25/sspx-greenhouse-25-1.cfg/PART[sspx-greenhouse-25-1]
[LOG 20:10:27.923] Applying update StationPartsExpansionRedux/Patches/SSPXR-MKS-Extras/@PART[sspx-greenhouse-25-1|sspx-greenhouse-375-1]:NEEDS[USILifeSupport,MKS]:AFTER[StationPartsExpansionRedux] to StationPartsExpansionRedux/Parts/Rigid/station-375/sspx-greenhouse-375-1.cfg/PART[sspx-greenhouse-375-1]
[LOG 20:10:27.929] :BEFORE[STRATEGIA] pass
[LOG 20:10:27.929] :FOR[STRATEGIA] pass
[LOG 20:10:27.930] Applying update Strategia/CustomBarnKitConfig/@CUSTOMBARNKIT:FOR[Strategia] to CustomBarnKit/default.cfg/CUSTOMBARNKIT
[LOG 20:10:27.931] :AFTER[STRATEGIA] pass
...

 

Ah, right. Forgot about that detail. Funny, considering I have patches for SSPXr myself as well. 

[linuxgurugamer]

HI,

I just got a message from someone who claims that the current version of MM is broken in some way.

He describes the issue here:

Can anyone comment on this?