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

Cetera · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

@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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

@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 · May 27, 2016

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 · May 27, 2016

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 · May 27, 2016

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. :wink:

toric5 · May 27, 2016

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 · May 27, 2016

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. :wink:

Cetera · May 27, 2016

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 · May 27, 2016

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).

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation