[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 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 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 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 by Alshain