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

[HB Stratos]

I haven been racking my brain over this for hours now.

Is there any way to properly deal with multiple .cfg files providing the same root node name? Can I somehow apply a patch to only a subset of them? How does multiple CFG files providing the same root node even behave?

I'm working on a patch that will hopefully make AVP and Volumetric Clouds play nicely together, but the issue is both it and volumetric clouds as well as any config pack for volumetric clouds provide .cfg files with EVE_CLOUDS as the root node. Now I need to remove all EVE_CLOUDS instances that were added by StockVolumetricClouds as I have a config pack that overrides them (you're supposed to overwrite the file itself, but that is infeasible in a ckan modpack. I tried tagging the nodes from AVP with @OBJECT[*]{@name^=:$:AVP_TAG:} run as AFTER[AstronomersVisualPack], however this tagging doesn't work properly as 'insert' patches are read before anything else is executed, hence even the alphabetically later StockVolumetricClouds config is already loaded by then and receives the tag. 

I've tried about everything I know, even tried looking through the source code to see if :HAS had an implementation to deal with this, but I haven't found anything useful. Help would be much apprechiated.

[Lisias]

3 hours ago, HB Stratos said:

I haven been racking my brain over this for hours now.

Is there any way to properly deal with multiple .cfg files providing the same root node name? Can I somehow apply a patch to only a subset of them? How does multiple CFG files providing the same root node even behave?

I'm working on a patch that will hopefully make AVP and Volumetric Clouds play nicely together, but the issue is both it and volumetric clouds as well as any config pack for volumetric clouds provide .cfg files with EVE_CLOUDS as the root node. Now I need to remove all EVE_CLOUDS instances that were added by StockVolumetricClouds as I have a config pack that overrides them (you're supposed to overwrite the file itself, but that is infeasible in a ckan modpack.  <...>

I'm unsure if I understood it correctly, but... Had you tried

-EVE_CLOUDS:AFTER[StockVolumetricClouds] { }

(Assuming StockVolumetricClouds is the name of the directory where it lays)

The problem you will have is that it will remove ALL OF THEM, being defined by the StockVolumetricClouds or not. You can try to limit it by using :HAS looking for something that only exists by the nodes created by StockVolumetricClouds.

[JonnyOThan]

3 hours ago, HB Stratos said:

I tried tagging the nodes from AVP with @OBJECT[*]{@name^=:$:AVP_TAG:} run as AFTER[AstronomersVisualPack],

You’ll need to use :HAS or filter for specific named objects (hopefully AVP and stock volumetric clouds use distinct names?).

AFTER probably isn’t very useful unless you’re trying to position your patch after one that runs in a specific FOR pass.  Note that a patch without a pass specifier runs in the legacy pass (which is fairly early), it does NOT inherit the pass from whatever folder it’s placed in.

[HB Stratos]

That is exactly the issue, there are no generalizable distinct names for objects added by multiple mods into the EVE_CLOUDS root node. The only way I have for separating them would be by somehow determining what .cfg file they were loaded from. I don't even really know what happens when you load multiple files with the same root node name. I'm not sure if it creates multiple instances of the root node, or merges all under one root node. 

Can I somehow look at the output that resulted from my MM patches somewhere? That would be quite useful. 

And well, how do I determine which mod added a certain root node if there are multiple instances?

[JonnyOThan]

26 minutes ago, HB Stratos said:

That is exactly the issue, there are no generalizable distinct names

It doesn't need to be generalizable as long as they're unique, there can't be more than 50 or so right?  Just list them all.

 

27 minutes ago, HB Stratos said:

what happens when you load multiple files with the same root node name

They exist as separate top-level nodes (this is how all PART configs work).

 

27 minutes ago, HB Stratos said:

Can I somehow look at the output that resulted from my MM patches somewhere?

Yes, see ModuleManager.configcache in the GameData directory (as long as there were no patching errors - fix those first).

 

28 minutes ago, HB Stratos said:

And well, how do I determine which mod added a certain root node if there are multiple instances?

The modulemanager logs list all the patches and cfg files (this is also mirrored to ksp.log).  But there's no direct way to see which patch produced which change.

[HB Stratos]

1 hour ago, JonnyOThan said:

It doesn't need to be generalizable as long as they're unique, there can't be more than 50 or so right?  Just list them all.

it is around 30 nodes or so. I just really dislike how unstable this is. If anything updates, the patch breaks. 

 

1 hour ago, JonnyOThan said:

They exist as separate top-level nodes (this is how all PART configs work).

Good to know. That might make something possible.

 

1 hour ago, JonnyOThan said:

Yes, see ModuleManager.configcache in the GameData directory (as long as there were no patching errors - fix those first).

Very helpful, thanks!

[JonnyOThan]

5 minutes ago, HB Stratos said:

If anything updates, the patch breaks. 

Welcome to modding. If you like, you can specify a max version for the dependencies in the ckan metadata, so that it will not allow installing newer versions until you verify them. Or don’t and just assume it’ll work until someone reports an issue.

[HB Stratos]

@EVE_CLOUDS:AFTER[StockVolumetricClouds]:HAS[@OBJECT[*]:HAS[@settings:HAS[@_MainTex:HAS[#value[Astronomers*]]]]]
{
	%__isAVP=true
}
@EVE_CLOUDS:AFTER[StockVolumetricClouds]:HAS[@OBJECT[*]:HAS[@settings:HAS[#_MainTex[Astronomers*]]]]
{
	
	%__isAVP=true
}
@EVE_CLOUDS:AFTER[StockVolumetricClouds]:HAS[#__isAVP]
{
	!__isAVP=_
	(do Something)
}

It's perhaps not pretty, but it certainly works! Technically only hits AVP files that also hit AVP textures, but that's a minor flaw. 

[HB Stratos]

---
Also, is it somehow possible to modify game settings like e.g. ambient light value from a MM patch? I have a TUFX profile that works by far the best with reduced ambient light.

[Pappystein]

Hoping someone can help me here.   I am attempting to Update a B9PartSwitch that is using multiple SUBTYPES.   I had a patch that USED to work when there were only two subtypes per part but now those parts have grown to near 10 Subtypes.

MyCode:  (shortened to 1 example for berivity)

Spoiler

@PART[bluedog_LR87]:BEFORE[Bluedog_DB_8]   // Base Titan First stage engine and all variants
{

  @MODULE[ModuleB9PartSwitch]:HAS[#moduleID[engineSwitch]]
  {
    @SUBTYPE[LR87-AJ5]
    {
      @MODULE:HAS[@IDENTIFIER:HAS[#name[ModuleEngines*]]]
      {
        @DATA{
        
            PROPELLANT[LiquidFuel]
            {
                name = Aerozine50
                ratio = 0.9
                DrawGauge = True                
            }
            PROPELLANT[Oxidizer]
            {
                name = NTO
                ratio = 1.1                
            }
       }
      }
    }
    }

SHORTEND

}

And the OG B9PartSwitch section of the part.cfg

Again snipped down to just the area I am trying to edit with the above code)

 

Spoiler

        SUBTYPE
        {
            name = LR87-AJ5
            title = LR8707-548 "Pallas"
            descriptionSummary = Powerful 1.875m engine for the Prometheus-II first stage.
            real_title = LR87-AJ-5
            real_descriptionSummary = Powerful 1.875m engine for the Titan-II first stage.
            descriptionDetail = <b>Thrust:</b> 477.9 kN ASL / 548 kN Vac.\n<b>Isp:</b> 259 s ASL / 297 s Vac.
            defaultSubtypePriority = 2
            addedCost = 2798
            transform = LR87_AJ5_Merged
            transform = AJ5
            upgradeRequired = bluedog_LR87AJ5
            NODE
            {
                name = bottom
                position = 0.0, -1.0275413, 0.0
            }
            MODULE
            {
                IDENTIFIER
                {
                    name = ModuleEnginesFX
                }

                DATA
                {
                    maxThrust = 548
                    atmosphereCurve
                    {
                        key = 0 297
                        key = 1 259
                        key = 6 0.001
                    }
                }
            }
        }

 

Logs are clean in so far as this patch (patch read patch applied at appropriate portion of time)  I will edit this post with an upload of them in a few minutes.

https://drive.google.com/file/d/1YclUj_zl-et2ZMMwOu57Z6wSLraOZAbK/view?usp=sharing   <--The Log

https://drive.google.com/file/d/1ENU45dsP769ivys7jhx5ijD2SlWumVR0/view?usp=sharing

Any help is appreciated.  I have gone through 33 checks, reads, and relaunches of KSP trying to solve the issue.

Edited July 5, 2024 by Pappystein

[JonnyOThan]

1 hour ago, Pappystein said:

PROPELLANT[LiquidFuel]

This is wrong. There should be a @ or % in front. And then the fields inside should have the same.

[Pappystein]

8 minutes ago, JonnyOThan said:

This is wrong. There should be a @ or % in front. And then the fields inside should have the same.

Since the Base module has no propellant entry in data it should be % then?

And thanks  I knew it was something simple.    The bad part is that means my OG patch never worked as intended (since it didn't have the symbols either... and no one reported it until a week ago.)

Spoiler

@PART[bluedog_LR87]:BEFORE[Bluedog_DB_8]   // Base Titan First stage engine and all variants
{

  @MODULE[ModuleB9PartSwitch]:HAS[#moduleID[engineSwitch]]
  {
    @SUBTYPE[LR87-AJ5]
    {
      @MODULE:HAS[@IDENTIFIER:HAS[#name[ModuleEngines*]]]
      {
        @DATA{
        
            %PROPELLANT[LiquidFuel]
            {
                %name = Aerozine50
                %ratio = 0.9
                %DrawGauge = True                
            }
            %PROPELLANT[Oxidizer]
            {
                %name = NTO
                %ratio = 1.1                
            }
       }
      }
    }
    }

Updated code snippet in the above Spoiler   % Adds or edits as I recall so :Fingers_crossed:

 

Edited July 5, 2024 by Pappystein

[Pappystein]

Followup.  So my code now works... on ONE set of parts.  the other two don't.  But I think that is a structure in the Origional part issue now and am looking into it.  Thanks @JonnyOThan!   You got me going where I needed to!

 

[lBoBl]

I'm trying to write a patche that targets all parts that don't have a ModuleCommand and have CrewCapacity > 0

@PART[*]:HAS[!MODULE[ModuleCommand],~CrewCapacity[0]]:AFTER[Launchpad]

Applies to all parts that are not command pods since having no crew capacity key seems to work

So I tried 

@PART[*]:HAS[!MODULE[ModuleCommand],#CrewCapacity[~0]]:AFTER[Launchpad]

but this applies to nothing, I guess it is not valid syntax. 
I would appreciate any help, basically the idea is to target all parts that can hold kerbals but are not command pods, such as the hitchhiker container, airplane crew cabins and such.

[JonnyOThan]

2 hours ago, lBoBl said:

I'm trying to write a patche that targets all parts that don't have a ModuleCommand and have CrewCapacity > 0

@PART[*]:HAS[!MODULE[ModuleCommand],~CrewCapacity[0]]:AFTER[Launchpad]

Applies to all parts that are not command pods since having no crew capacity key seems to work

So I tried 

@PART[*]:HAS[!MODULE[ModuleCommand],#CrewCapacity[~0]]:AFTER[Launchpad]

but this applies to nothing, I guess it is not valid syntax. 
I would appreciate any help, basically the idea is to target all parts that can hold kerbals but are not command pods, such as the hitchhiker container, airplane crew cabins and such.

I'm not certain about your specific situation, but a few observations:

1. If no MM pass named "Launchpad" is present then this patch will not run
2. many parts do not have an explicit crew capacity field, though it will default to 0.  Modulemanager does not care what the default value of some structure that is loaded from a config file.  Modulemanager is only concerned with cfg files and ConfigNodes.  You need to treat the absence of a CrewCapacity field as the same as it being set to 0.

[lBoBl]

12 hours ago, JonnyOThan said:

You need to treat the absence of a CrewCapacity field as the same as it being set to 0.

Thanks! So something like 

@PART[*]:HAS[!MODULE[ModuleCommand],#CrewCapacity,~CrewCapacity[0]]:AFTER[Launchpad]

should work instead of #CrewCapacity[~0]?

Edit: I tried it it works, thanks a lot @JonnyOThan

Edited July 14, 2024 by lBoBl

[lBoBl]

So, that does the trick to target parts that are not command pods but can hold crew, any idea how I could target unmanned parts only? I have tried 

@PART[*]:HAS[#category[Science],!CrewCapacity]

but it still applies to things like the science lab and SSPX greenhouse and aquaculture modules, which I would like to exclude. 

[JonnyOThan]

59 minutes ago, lBoBl said:

target unmanned parts only?

Try ~CrewCapacity[>0]

[lBoBl]

11 hours ago, JonnyOThan said:

Try ~CrewCapacity[>0]

It works! Thanks a lot. I didn't think > was a thing in MM, I was solely using operators described in https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook
That's going to be very useful for what I need to do.

[OHN]

I'm looking for a way to patch all parts except ones from a particular mod. Is there a way to filter a @PART[*] to exclude a single mod?

[JonnyOThan]

2 hours ago, OHN said:

I'm looking for a way to patch all parts except ones from a particular mod. Is there a way to filter a @PART[*] to exclude a single mod?

MM has no concept of what mod something came from. If all the parts in that mod have something in common (model path, author, naming pattern, etc) then you can use that to filter. Use something like @PART:HAS[!MODEL:HAS[#model[ModFolder/*]]]
 

If there’s no common thing you can use, then one way to do this would be to add a custom key/value to all the parts you don’t want to affect and then apply your patch to things that don’t have that key.

[Alshain]

On 6/30/2024 at 6:52 PM, Krakatoa said:

It exists already.

I don't manage it anymore though.  If someone wanted to succeed it they would have my support (not that they would need it).  I don't visit here as often as I used to.  In the end it was quite difficult to keep updated, the forum isn't exactly the right tool for such a thing.

Edited September 14, 2024 by Alshain

[Professor K]

I'm having a timing issue with a module manager patch. MM appears to be trying to run it before the mod specified in it's AFTER clause.

KSP (latest, on PC)

Kopernicus 2.19

Dwarf Planets Plus planet pack

self written patch

Kopernicus and the Planet Pack itself have been working fine for months and other patches for DPP are working.

All of the body config files in the planet pack start with:

@Kopernicus:AFTER[Kopernicus]

And the patch starts with:

@DEPLOYEDSCIENCE:NEEDS[DwarfPlanetsPlus&SquadExpansion/Serenity]:AFTER[DwarfPlanetsPlus]

With this I would expect the patch to run after the planet pack, but as shown in the log timestamps below, it's not, MM is trying to run it before the planet pack, which is causing errors when the patch attempts to access variables that don't exist yet. I use the same patch with another planet pack and it works fine/runs in the expected order. 

[LOG 12:07:20.875] :AFTER[DWARFPLANETSPLUS] pass
[LOG 12:07:20.877] Applying update GruTech/Patches/DeployedScience/DPP_Deployed_Science_Seismic/@DEPLOYEDSCIENCE:NEEDS[DwarfPlanetsPlus&SquadExpansion/Serenity]:AFTER[DwarfPlanetsPlus] to SquadExpansion/Serenity/Resources/DeployedScience.cfg/DEPLOYEDSCIENCE
[ERR 12:07:20.877] Error - Cannot parse variable search when inserting new key tmpG = #$@Kopernicus/Body[Morbheana]/Properties/geeASL$
[ERR 12:07:20.877] Error - Cannot parse variable search when inserting new key tmpR = #$@Kopernicus/Body[Morbheana]/Properties/radius$
...
[LOG 12:07:21.215] :AFTER[KOPERNICUS] pass
[LOG 12:07:21.215] Applying update DwarfPlanetsPlus/DwarfPlanets/AsteroidBelt/Cador/Cador/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.215] Applying update DwarfPlanetsPlus/DwarfPlanets/AsteroidBelt/Talus/Talus/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.217] Applying update DwarfPlanetsPlus/DwarfPlanets/CentaurObjects/Virani/Virani/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.217] Applying update DwarfPlanetsPlus/DwarfPlanets/CentaurObjects/Walru/Walru/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.218] Applying update DwarfPlanetsPlus/DwarfPlanets/CentaurObjects/Zevrin/Zevrin/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.219] Applying update DwarfPlanetsPlus/DwarfPlanets/KerperBelt/Cruachan/Awe/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.220] Applying update DwarfPlanetsPlus/DwarfPlanets/KerperBelt/Cruachan/Cruachan/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.220] Applying update DwarfPlanetsPlus/IceGiants/Morbheana/Morbheana/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.220] :BEFORE[KOPERNICUS.PARSER] pass

Does anyone know why this would be happening and, more importantly, how to fix it?

-K

[Professor K]

On 12/26/2024 at 12:57 PM, Professor K said:

I'm having a timing issue with a module manager patch. MM appears to be trying to run it before the mod specified in it's AFTER clause.

I have resolved this.

I say "resolved", not "solved" because I still don't know why it was behaving as it was.

After examining the config files from other planet packs I modified the planet pack files for start with "@Kopernicus:FOR[DwarfPlanetsPlus]"

While I understand that FOR statements are loaded earlier in the load process, I still fail to understand why the AFTER[DwarfPlanetsPlus] on the patch was being ignored.

-K

[Lisias]

On 12/26/2024 at 2:57 PM, Professor K said:

I'm having a timing issue with a module manager patch. MM appears to be trying to run it before the mod specified in it's AFTER clause.

KSP (latest, on PC)

Kopernicus 2.19

Dwarf Planets Plus planet pack

self written patch

Kopernicus and the Planet Pack itself have been working fine for months and other patches for DPP are working.

All of the body config files in the planet pack start with:

@Kopernicus:AFTER[Kopernicus]

And the patch starts with:

@DEPLOYEDSCIENCE:NEEDS[DwarfPlanetsPlus&SquadExpansion/Serenity]:AFTER[DwarfPlanetsPlus]

With this I would expect the patch to run after the planet pack, but as shown in the log timestamps below, it's not, MM is trying to run it before the planet pack, which is causing errors when the patch attempts to access variables that don't exist yet. I use the same patch with another planet pack and it works fine/runs in the expected order. 

[LOG 12:07:20.875] :AFTER[DWARFPLANETSPLUS] pass
[LOG 12:07:20.877] Applying update GruTech/Patches/DeployedScience/DPP_Deployed_Science_Seismic/@DEPLOYEDSCIENCE:NEEDS[DwarfPlanetsPlus&SquadExpansion/Serenity]:AFTER[DwarfPlanetsPlus] to SquadExpansion/Serenity/Resources/DeployedScience.cfg/DEPLOYEDSCIENCE
[ERR 12:07:20.877] Error - Cannot parse variable search when inserting new key tmpG = #$@Kopernicus/Body[Morbheana]/Properties/geeASL$
[ERR 12:07:20.877] Error - Cannot parse variable search when inserting new key tmpR = #$@Kopernicus/Body[Morbheana]/Properties/radius$
...
[LOG 12:07:21.215] :AFTER[KOPERNICUS] pass
[LOG 12:07:21.215] Applying update DwarfPlanetsPlus/DwarfPlanets/AsteroidBelt/Cador/Cador/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.215] Applying update DwarfPlanetsPlus/DwarfPlanets/AsteroidBelt/Talus/Talus/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.217] Applying update DwarfPlanetsPlus/DwarfPlanets/CentaurObjects/Virani/Virani/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.217] Applying update DwarfPlanetsPlus/DwarfPlanets/CentaurObjects/Walru/Walru/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.218] Applying update DwarfPlanetsPlus/DwarfPlanets/CentaurObjects/Zevrin/Zevrin/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.219] Applying update DwarfPlanetsPlus/DwarfPlanets/KerperBelt/Cruachan/Awe/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.220] Applying update DwarfPlanetsPlus/DwarfPlanets/KerperBelt/Cruachan/Cruachan/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.220] Applying update DwarfPlanetsPlus/IceGiants/Morbheana/Morbheana/@Kopernicus:AFTER[Kopernicus] to Kopernicus/Config/System.cfg/Kopernicus[Kerbol System]
[LOG 12:07:21.220] :BEFORE[KOPERNICUS.PARSER] pass

Does anyone know why this would be happening and, more importantly, how to fix it?

I installed this very same setup on a 1.12.5 test bed, and I got similar results.

Please note that the DwarfPlanetsPlus is being patched AFTER KOPERNICUS. Since Kopernicus is patched after DPP due the patching being applied in ascending order, this is the reason your custom patches are being applied "too soon".

MM is doing right. Kopernicus is the one tricking you here - besides not being exactly an error neither.

I had advocated for a solution for this problem some time ago, by the way. Unfortunately, my proposal was ignored and nothing was proposed to fix the problem neither.

TL;DR: Kopernicus should be patching DwarfPlanetsPlus using ":FOR[DwarfPlanetsPlus]:NEEDS[DwarfPlanetsPlus]".  The needs will prevent the patch from being applied if DPP is not installed, and the :FOR will patch it in the "FOR" loop, allowing you to correctly apply :AFTER .

Right now, your best chance is to use ":FINAL", or perhaps some ":AFTER[zzzz_something]" to achieve what you want. edit: unless you edit Kopernicus' patches,  of course...

 

1 hour ago, Professor K said:

I have resolved this.

I say "resolved", not "solved" because I still don't know why it was behaving as it was.

After examining the config files from other planet packs I modified the planet pack files for start with "@Kopernicus:FOR[DwarfPlanetsPlus]"

While I understand that FOR statements are loaded earlier in the load process, I still fail to understand why the AFTER[DwarfPlanetsPlus] on the patch was being ignored.

-K

And, interesting enough, you reached to the same conclusion as I did! Just add ":NEEDS[DwarfPlanetsPlus]" to the patch to prevent your patching from being applied (and creating a MM tag for DPP) when DPP is not installed!

(sorry answering you just now, I had missed the previous post)

Edited December 28, 2024 by Lisias
edit