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

[Cetera]

Can someone help out a total n00b?  I'm trying to figure out how to write an MM patch that will overwrite/replace/stop the E.V.E. config file in GameData > BoulderCo > Atmosphere > clouds.cfg, and replace it with a custom config.  I've been perusing the documentation, but since it isn't a module, I'm really not even certain where to start.

[Raptor831]

52 minutes ago, Cetera said:

Can someone help out a total n00b?  I'm trying to figure out how to write an MM patch that will overwrite/replace/stop the E.V.E. config file in GameData > BoulderCo > Atmosphere > clouds.cfg, and replace it with a custom config.  I've been perusing the documentation, but since it isn't a module, I'm really not even certain where to start.

You can see an example here: https://github.com/Sigma88/Sigma-Dimensions/blob/Development/GameData/Sigma/Dimensions/Configs/ReDimension/resizeClouds.cfg#L23 Should at least get you started.

 

Also, I seem to have a minor issue: I'm not getting any cache file any more. I don't know what I could have done for that. But before I post up logs and such, is there some user error I have committed to make this happen?

[Sigma88]

8 minutes ago, Raptor831 said:

You can see an example here: https://github.com/Sigma88/Sigma-Dimensions/blob/Development/GameData/Sigma/Dimensions/Configs/ReDimension/resizeClouds.cfg#L23 Should at least get you started.

 

Also, I seem to have a minor issue: I'm not getting any cache file any more. I don't know what I could have done for that. But before I post up logs and such, is there some user error I have committed to make this happen?

if there is an error in one of the mm patches the cache will not be generated,

if you look inside the output_log.txt it should tell you which file is failing and where

[Chris97b]

37 minutes ago, Raptor831 said:

You can see an example here: https://github.com/Sigma88/Sigma-Dimensions/blob/Development/GameData/Sigma/Dimensions/Configs/ReDimension/resizeClouds.cfg#L23 Should at least get you started.

 

Also, I seem to have a minor issue: I'm not getting any cache file any more. I don't know what I could have done for that. But before I post up logs and such, is there some user error I have committed to make this happen?

I've also had this issue happen with mods that store configuration files outside of a Plugindata/ folder. Remember that any changes to any config file that is not in a Plugindata folder will cause MM to invalidate the cache. If this is the case, check your KSP.log for which configuration files were considered to be out of date (MM will log which files have changed).

*edit* My bad, just realized you said you aren't getting a cache file generated at all. Probably due to errors as Sigma88 mentioned

Edited May 27, 2016 by Chris97b

[Raptor831]

@Sigma88 @Chris97b I believe it is just config errors. I have a file that's generating 2 errors while I'm testing versions of the RF Stockalike configs. Which, now that you say it, makes sense that you wouldn't want a cache file in that case.

I knew it had to be something simple that I overlooked. Thank you both.  

[nathan1]

22 hours ago, Chris97b said:

I'm no expert, but something like this is what I would have thought

  Hide contents

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE[*]:HAS[#ResourceName[MonoPropellant]]]]:FINAL
{
   +MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE[*]:HAS[#ResourceName[MonoPropellant]]]
   {
        @ConverterName = Lithium
        @StartActionName = Start ISRU [Li]
        @StopActionName = Stop ISRU [Li]
        @Specialty = Engineer
        @INPUT_RESOURCE:HAS[#ResourceName[Ore]]
        {
            @Ratio *= 2
            %FlowMode = STAGE_PRIORITY_FLOW
        }
        @INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]]
        {
            @Ratio *= .6
        }
        @OUTPUT_RESOURCE
        {
            @ResourceName = Lithium
            @Ratio *= 18
            @DumpExcess = false
            %FlowMode = STAGE_PRIORITY_FLOW
        }
    }
}

In testing though, I can't seem to get the nested :HAS conditions to work at all. Is this a bug perhaps?

When you use [*] you are restricting the patch to only apply to nodes that have a name property (with any value), so @OUTPUT_RESOURCE[*]:HAS[etc....] is restricted to matching OUTPUT_RESOURCE nodes with a name property in addition to what's in the HAS[...] part.

Well, I at least know that's true at the root level. For example, @PART[*] only matches parts with a name property (although in practice that won't make a difference for @PART since all parts have to have a name). I think what you need to do is something like this:

@PART:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]:FINAL

And similarly for the +MODULE part.

[toric5]

11 minutes ago, nathan1 said:

When you use [*] you are restricting the patch to only apply to nodes that have a name property (with any value), so @OUTPUT_RESOURCE[*]:HAS[etc....] is restricted to matching OUTPUT_RESOURCE nodes with a name property in addition to what's in the HAS[...] part.

Well, I at least know that's true at the root level. For example, @PART[*] only matches parts with a name property (although in practice that won't make a difference for @PART since all parts have to have a name). I think what you need to do is something like this:

@PART:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]:FINAL

And similarly for the +MODULE part.

i currently have

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT?RESOURCE[MonoPropellant],@INPUT?RESOURCE[Ore]]]

the ? replacing the _ is because a couple post above my op, @linuxgurugamer seems to have found a bug having to do with _. still does not work.

Edited May 27, 2016 by toric5

[Chris97b]

The MonoPropellant resource is a subset variable of the OUTPUT_RESOURCE node, I would try this:

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT?RESOURCE:HAS[#ResourceName[MonoPropellant]],@INPUT?RESOURCE:HAS[#ResourceName[Ore]]]]]

(Note: I wasn't overly diligent in counting the brackets, I would double-check that)

@nathan1 Many thanks for that, I was going crazy trying to specify a node with no name variable. I tried @OUTPUT_RESOURCE[] but that generated errors, didn't think to try it without the square brackets

Edited May 27, 2016 by Chris97b

[nathan1]

4 minutes ago, toric5 said:

i currently have

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT?RESOURCE[MonoPropellant],@INPUT?RESOURCE[Ore]]]

the ? replacing the _ is because a couple post above my op, @linuxgurugamer seems to have found a bug having to do with _. still does not work.

I'm pretty sure you can't use wildcards for nodes, only for values. In other words, for the above snippet: PART, MODULE, OUTPUT_RESOURCE, and INPUT_RESOURCE all cannot be matched via wildcard, but must be matched directly. ModuleResourceConverter, MonoPropellant, and Ore are all values that could be matched via wildcard.

[toric5]

Just now, nathan1 said:

I'm pretty sure you can't use wildcards for nodes, only for values. In other words, for the above snippet: PART, MODULE, OUTPUT_RESOURCE, and INPUT_RESOURCE all cannot be matched via wildcard, but must be matched directly. ModuleResourceConverter, MonoPropellant, and Ore are all values that could be matched via wildcard.

yah, ive tried _ as well, was just a shot in the dark...

[nathan1]

41 minutes ago, toric5 said:

yah, ive tried _ as well, was just a shot in the dark...

Ok, I tested out the following and it works (I don't have Lithium, so I used SolidFuel instead as a proof-of-concept):

@PART:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]
{
	+MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]
	{
		%ConverterName = SolidFuel
		%StartActionName = Start ISRU [SRB]
		%StopActionName = Stop ISRU [SRB]
		
		@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]
		{
			@ResourceName = SolidFuel
		}
	}
}

The two stock ISRU parts have the extra converter added, and the stock fuel cells were correctly left unaltered (they have ModuleResourceConverter, but it doesn't have MonoPropellant as an output).

You should be able to modify this to suit your needs.

[Chris97b]

Yep, looks perfect. @toric5 This should do what you need:

Spoiler

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]:FINAL
{
   +MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]
   {
        @name = ModuleResourceConverter
        @ConverterName = Lithium
        @StartActionName = Start ISRU [Li]
        @StopActionName = Stop ISRU [Li]
        @Specialty = Engineer
        @INPUT_RESOURCE:HAS[#ResourceName[Ore]]
        {
            @ResourceName = Ore
            @Ratio *= 2
            FlowMode = STAGE_PRIORITY_FLOW
        }
        @INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]]
        {
            @ResourceName = ElectricCharge
            @Ratio *= .6
        }
        @OUTPUT_RESOURCE
        {
            @ResourceName = Lithium
            @Ratio *= 18
            @DumpExcess = false
            FlowMode = STAGE_PRIORITY_FLOW
        }
    }
}

 

[Cetera]

3 hours ago, Raptor831 said:

You can see an example here: https://github.com/Sigma88/Sigma-Dimensions/blob/Development/GameData/Sigma/Dimensions/Configs/ReDimension/resizeClouds.cfg#L23 Should at least get you started.

Unfortunately, that really doesn't help me much.  It looks like something wildly complicated to me.  I'm guessing you can write your own variables using that, but I'm really not sure how to even get that far.  I was thinking of something much, much more basic.  Can module manager do a patch to say "don't load clouds.cfg" and "instead, load this new.cfg?"

[toric5]

9 minutes ago, Chris97b said:

Yep, looks perfect. @toric5 This should do what you need:

  Hide contents

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]:FINAL
{
   +MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]
   {
        @name = ModuleResourceConverter
        @ConverterName = Lithium
        @StartActionName = Start ISRU [Li]
        @StopActionName = Stop ISRU [Li]
        @Specialty = Engineer
        @INPUT_RESOURCE:HAS[#ResourceName[Ore]]
        {
            @ResourceName = Ore
            @Ratio *= 2
            FlowMode = STAGE_PRIORITY_FLOW
        }
        @INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]]
        {
            @ResourceName = ElectricCharge
            @Ratio *= .6
        }
        @OUTPUT_RESOURCE
        {
            @ResourceName = Lithium
            @Ratio *= 18
            @DumpExcess = false
            FlowMode = STAGE_PRIORITY_FLOW
        }
    }
}

 

so how would i add a check to make sure the input resource is ore? (dont want, say, karbonite converters to have this.) also a check for a lithium converter, so you dont get 2 on a part? im guessing it would be:

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]&@INPUT_RESOURCE:HAS[#ResourceName[Ore]]&!@OUTPUT_RESOURCE:HAS[#ResourceName[Lithium]]]]:FINAL

 

will the thermal efficenccy stuff automatically copy over?

[Chris97b]

34 minutes ago, toric5 said:

so how would i add a check to make sure the input resource is ore? (dont want, say, karbonite converters to have this.) also a check for a lithium converter, so you dont get 2 on a part? im guessing it would be:

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]&@INPUT_RESOURCE:HAS[#ResourceName[Ore]]&!@OUTPUT_RESOURCE:HAS[#ResourceName[Lithium]]]]:FINAL

 

will the thermal efficenccy stuff automatically copy over?

Yep, exactly. That copies the monoprop module so anything not specified would have the same properties as the monoprop converter.

[linuxgurugamer]

7 hours ago, toric5 said:

i currently have

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT?RESOURCE[MonoPropellant],@INPUT?RESOURCE[Ore]]]

the ? replacing the _ is because a couple post above my op, @linuxgurugamer seems to have found a bug having to do with _. still does not work.

It actually isn't a bug, it's documented.  Anything other than an alphanumeric (letter or number) should be represented with a ? as described below:

• <Name-With-Wildcards> : The name of the value you'll be messing with. Wildcards are not always available for every Op. Wildcards include ? for any character, and * for any number of chars. Note that ''only alphanumeric chars'' are allowed in value names for patches. If you have spaces or any other char, use a ? to match it.

I'm not sure what your INPUT_RESOURCE and OUTPUT_RESOURCE is; if that is part of the MM syntax, then you need the underscores;  the issue with underscores is only regarding names.  I never saw these two before.

Edited May 27, 2016 by linuxgurugamer

[NecroBones]

 

This might need to be double-checked, but I ran into problems with having multiple HAS/NEEDS statements evaluating as "OR" rather than "AND" in recent MM updates (whereas they all had to be satisfied before). So this:

 

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]:FINAL

 

... might need to change to this:

 

@PART[*]:HAS[@MODULE[ModuleResourceConverter],@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]:FINAL

 

(notice the second HAS changed to just a comma)

 

It's possible I had something else going on, but I recently had to collapse my NEEDS statements to restore the expected behavior in some of my configs. It's possible this doesn't extend to HAS though. But it's worth taking a look at.

 

 

 

[Sigma88]

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]

@PART[*]:HAS[@MODULE[ModuleResourceConverter],@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]

As far as I know this is how those two lines work

the first one will look for a PART that contains a MODULE which contains a OUTPUTRESOURCE

the second one will look for a PART that contains both a MODULE and a OUTPUTRESOURCE

what kind of results were you getting?

[Chris97b]

5 hours ago, linuxgurugamer said:

It actually isn't a bug, it's documented.  Anything other than an alphanumeric (letter or number) should be represented with a ? as described below:

• <Name-With-Wildcards> : The name of the value you'll be messing with. Wildcards are not always available for every Op. Wildcards include ? for any character, and * for any number of chars. Note that ''only alphanumeric chars'' are allowed in value names for patches. If you have spaces or any other char, use a ? to match it.

I'm not sure what your INPUT_RESOURCE and OUTPUT_RESOURCE is; if that is part of the MM syntax, then you need the underscores;  the issue with underscores is only regarding names.  I never saw these two before.

Yeah to my knowledge the underscore thing is unique to the MODULE[ModuleName] syntax. In this case INPUT_RESOURCE and OUTPUT_RESOURCE are actually nodes. In other words, a node of type OUTPUT_RESOURCE (as opposed to say a node of type MODULE). From the stock ISRU config:

Spoiler

MODULE
    {
        name = ModuleResourceConverter
        <snip>
        INPUT_RESOURCE
         {
            ResourceName = Ore
            Ratio = 0.5
         }
         INPUT_RESOURCE
         {
            ResourceName = ElectricCharge
            Ratio = 30
         }
         OUTPUT_RESOURCE
         {
            ResourceName = MonoPropellant
            Ratio = 1
            DumpExcess = false
         }
    }

 

1 hour ago, NecroBones said:

 

This might need to be double-checked, but I ran into problems with having multiple HAS/NEEDS statements evaluating as "OR" rather than "AND" in recent MM updates (whereas they all had to be satisfied before). So this:

 

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]:FINAL

 

... might need to change to this:

 

@PART[*]:HAS[@MODULE[ModuleResourceConverter],@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]:FINAL

 

In this case the :HAS conditions are actually nested, it's neither an OR nor an AND, we were trying to match a Module with the name ModuleResourceConverter which *contains* a node of type OUTPUT_RESOURCE which contains a variable with the key ResourceName. My understanding is that :HAS[@MODULE[ModuleResourceConverter],@OUTPUT_RESOURCE] would go back to the top level node when looking for the OUTPUT_RESOURCE as opposed to looking within the ModuleResourceConverter node. Take a look at the snip of the stock ISRU config above, that should make it more clear.

29 minutes ago, Sigma88 said:

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]

@PART[*]:HAS[@MODULE[ModuleResourceConverter],@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]

As far as I know this is how those two lines work

the first one will look for a PART that contains a MODULE which contains a OUTPUTRESOURCE

the second one will look for a PART that contains both a MODULE and a OUTPUTRESOURCE

what kind of results were you getting?

Yep, exactly. What ended up working was:

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]:FINAL

The thing I got caught beating my head on was how to specify a node containing no name key at all. Apparently @OUTPUT_RESOURCE[*] just means a node of type OUTPUT_RESOURCE with any name, but still requiring that a name exist.

[Sigma88]

20 minutes ago, Chris97b said:

The thing I got caught beating my head on was how to specify a node containing no name key at all. Apparently @OUTPUT_RESOURCE[*] just means a node of type OUTPUT_RESOURCE with any name, but still requiring that a name exist.

This is true for @PART[*] as well

I don't understand why everybody keeps using it

it kinda annoys me

 

PS: if you want to modify only those modules that have no name at all, you can use :HAS[~name[]]

but I don't see a reason to do that honeslty

Edited May 27, 2016 by Sigma88

[Raptor831]

12 hours ago, Cetera said:

Unfortunately, that really doesn't help me much.  It looks like something wildly complicated to me.  I'm guessing you can write your own variables using that, but I'm really not sure how to even get that far.  I was thinking of something much, much more basic.  Can module manager do a patch to say "don't load clouds.cfg" and "instead, load this new.cfg?"

The instructions in the OP are pretty good, so start there. That particular link does look a little scary at first. Basically, though, @SOMETHING means you want to change that something. In your case, @EVE_CLOUDS{ ..stuff.. } will change stuff inside the EVE_CLOUDS node. Look through the original clouds config and then map out what you want to change, using the examples in the OP as a guide. Also, check out some other MM patches for insight, as there are a lot of them floating around.

Sorry, not the best teacher here. Generally I learn by breaking it until it works again.

[toric5]

well, it seems to be working. it should be easy enough to make the same sort of thing for LH2. thanks everyone for helping me out with this!

[NecroBones]

1 hour ago, Chris97b said:

In this case the :HAS conditions are actually nested,
 

 

Yep, I missed this. That's what I get for glancing too quickly.

 

[Cetera]

2 hours ago, Raptor831 said:

The instructions in the OP are pretty good, so start there. That particular link does look a little scary at first. Basically, though, @SOMETHING means you want to change that something. In your case, @EVE_CLOUDS{ ..stuff.. } will change stuff inside the EVE_CLOUDS node. Look through the original clouds config and then map out what you want to change, using the examples in the OP as a guide. Also, check out some other MM patches for insight, as there are a lot of them floating around.

Sorry, not the best teacher here. Generally I learn by breaking it until it works again.

Oh, so for the EVE mod, the first line in the clouds.cfg file that I want to edit is "EVE_CLOUDS", so in my MM patch to modify that config I start with @EVE_CLOUDS.  I am slowly starting to understand.  

There are nested OBJECTS under the EVE_CLOUDS.  They aren't specifically-named objects, however.  How do I specify each one I want to change?  Can I just remove them all, and then recreate everything I want?

Oh, I think I see.  Can I just do "!OBJECT,*" to remove them all, and then put in the config as I want?  Is that correct?

Edited May 27, 2016 by Cetera

[Raptor831]

58 minutes ago, Cetera said:

Oh, so for the EVE mod, the first line in the clouds.cfg file that I want to edit is "EVE_CLOUDS", so in my MM patch to modify that config I start with @EVE_CLOUDS.  I am slowly starting to understand.  

There are nested OBJECTS under the EVE_CLOUDS.  They aren't specifically-named objects, however.  How do I specify each one I want to change?  Can I just remove them all, and then recreate everything I want?

Oh, I think I see.  Can I just do "!OBJECT,*" to remove them all, and then put in the config as I want?  Is that correct?

Yes, you can do that. In which case you should use !OBJECT,*{}  If the config is vastly different, you could do this and replace everything with your config. Personally, I'd try and alter the settings as needed, for example:

@EVE_CLOUDS
{
  @OBJECT[Kerbin-clouds1] // Grab the main Kerbin cloud layer...
  {
    @altitude = 4500 // change the altitude parameter
    @settings // get inside the settings{} node...
    {
      @_DetailTex = MyModFolder/custom/textures/clouds // use your own cloud texture
    }
  }

  @OBJECT[Laythe-clouds1] // Grab Laythe clouds...
  {
    @detailSpeed = 0,8,0 // change detailSpeed
    @altitude *= 1.5 // scale the altitude up by 50% (i.e. take what's in altitude and multiply it by 1.5)
  }
}

NOTE: I have no idea what the above does, it's just an example of how something could look. Doing it the above way saves you from having to rebuild configs every time you update a mod, or losing the original configs (which was the original use of MM).