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

[Starwaster]

I'm trying to remove an EC resource node from a part.

However, somehow I'm too stupid to get it working Here's what I tried:

//inside the selected PART
!RESOURCE[ElectricCharge]{}

I don't get any MM errors in the log, but the resource is still there. Any help is much appreciated!

Either something else is adding it back in after your config is run or there's something else wrong in your config

If it's something in your config then it's not possible to troubleshoot it unless you post the entire thing, or at least the entire section for that PART (i.e., //inside the selected PART <- Need to see that entire thing instead of assuming that it was written properly)

[marce]

Either something else is adding it back in after your config is run or there's something else wrong in your config

If it's something in your config then it's not possible to troubleshoot it unless you post the entire thing, or at least the entire section for that PART (i.e., //inside the selected PART <- Need to see that entire thing instead of assuming that it was written properly)

Taverius helped me out (in the IRC chan), I was missing a space between "]" and "{"

!RESOURCE[ElectricCharge] {}

works.

Edited September 9, 2014 by marce

[seanth]

I'm currently working on a way to have difficulty levels for a mod I help with. Right now the in-game gui from the spcace center window lets the user pick the difficulty and results in a modulemanager cfg being written to file. Is it possible to call DataBaseReloadWithMM() from code to reload the database and pickup the changes to the difficulty file?

I did read the wiki on github, but what I am describing seems different than the dynamic module examples.

[TheAlmightyOS]

I am just going to come out and ask cause reading though the documentation/wiki and tinkering with a config file isn't getting me anywhere.

I am attempting to add a value to an existing string.

//part config, not MM config

MODULE
{
name = TESTmodule
examplevalue = value1; value2; value3
}

In this example, I want to add ; value4 to the end of examplevalue. Is there a way to do this with MM? I am thinking I have to use some sort of expression to copy the default value then use the @ edit function to change the value to the copy and my new value. But it is too late and I am too wiped to focus anymore brainpower on this. Thanks in advance for the help.

[NathanKell]

looks like you could use @MODULE[TESTModule]

{

@examplevalue ^= :$:; value4:

}

(the docs explain more the ^= feature (reg. exp.))

[TheAlmightyOS]

looks like you could use @MODULE[TESTModule]

{

@examplevalue ^= :$:; value4:

}

(the docs explain more the ^= feature (reg. exp.))

I always miss something. Thank's for the assist.

[SirJodelstein]

is it possible to combine searches to do something like this? i want to apply some changes to multiple parts and a combined search would be very neat. I know theres wildcards, but i have not seen (or overlooked?) if something like this is possible

@PART[part1,part2,part3]
{
   //stuff
}

[Starwaster]

is it possible to combine searches to do something like this? i want to apply some changes to multiple parts and a combined search would be very neat. I know theres wildcards, but i have not seen (or overlooked?) if something like this is possible

@PART[part1,part2,part3]
{
   //stuff
}

No, that won't work. Wildcards are the limit of what's available to you.

Taverius helped me out (in the IRC chan), I was missing a space between "]" and "{"

!RESOURCE[ElectricCharge] {}

works.

Whatever problem you were having, a missing space wasn't the source of the problem. You must have done something else that fixed it.

The following config removes every single bit of ElectricCharge from every single part. No survivors. Confirmed.

@PART
[*]:HAS[@RESOURCE[ElectricCharge]]:FINAL
{
    !RESOURCE[ElectricCharge]{}
}

And Behold!

Edited September 11, 2014 by Starwaster

[TranceaddicT]

Some time in the recent past I got my hands on a version (2.1.1?) that had a persistent box in the SpaceCenter which allowed me to do a database dump of all the config files as loaded. The dump went to a /KSP/MM_Config.

Can I get that again? Was it a debug version?

[sarbian]

Read the first post.

[TranceaddicT]

Read the first post.

Yeah, just goes to show you shouldn't post if:

1. You've been at the keyboard for more than 6h.

2. You haven't read the first post.

[Starwaster]

Yeah, just goes to show you shouldn't post if:

1. You've been at the keyboard for more than 6h.

I spend more than that on this site alone :/

[TranceaddicT]

I spend more than that on this site alone :/

Would that have anything to do with the "waster" in Starwaster?

[Surefoot]

with mm 2.3.5 (and nothing else): my stock parachutes, such as MK16, will not appear in staging list either in VAB or flight. They cant be triggered / deployed and there is no right click menu on them in the VAB.

[K3-Chris]

Silly question: can you use MM to replace props in a INTERNAL{}? Say some internals use a prop I've made a better version off, but I don't want to make my own version of all those internals and MM in the internal itself into the parts? I just want to use MM to swap the prop in all those internals?

[sarbian]

Yes, INTERNAL are doable.

I pushed 2.3.5 as the official release. Since it's the one bundled with B9 I'm sure it did not destroy the universe now.

I m starting a dev release to get feedback and test a new feature. Dreadicon posted a nice example of syntax for allowing variable a few days ago. I implemented a similar syntax this weekend as I was stuck at work but ask to not actually work.

So here is a work in progress on that system. It's nearly finished but not really tested (work computer lacks a KSP install). Keep it far from your main install (even if it should not mess things up). If you have some time please test it. The few basic test I have the time to do worked, but I won't be able to do much more for a couple of days so it would help.

- Added a new "power of" math operator. ^= is already used so it's !=

 

a = 2
@a != 3  // now a = 8

- Added a system to use variable.

Say we have this PART :

 

PART
{
 name = fuelTank
 module = Part
 mass = 1.25
 scale = 0.1
 entryCost = 1600
 cost = 850
 node_stack_top = 0.0, 7, 0.0, 0.0, 1.0, 0.0

 RESOURCE
 {
   name = LiquidFuel
   amount = 180
   maxAmount = 180
 }

 RESOURCE
 {
   name = Oxidizer
   amount = 220
   maxAmount = 220
 }
}

We want to replace the resource with a new one with a capacity equal tho the sum of both. And make it bigger too

 

MYMODCONFIGS
{
 rescaleMult = 2
}

@PART[fuelTank]
{
 rescaleMult = #$@MYMODCONFIGS/rescaleMult$   // get a value from the MYMODCONFIGS node you created to store common values.
 @scale *= #$rescaleMult$
 @mass *= #$rescaleMult$

 RESOURCE
 {
   name = MonoPropellant

   amount = #$../RESOURCE[LiquidFuel]/amount$       // get one level lower, find the LiquidFuel node and get the amount value here
   @amount += #$../RESOURCE[Oxidizer]/amount$    // Add the value from the Oxidizer node
   @amount != #$/rescaleMult$   // amount = amount ^ 2                // ( let's say our tank is a cube )

   maxAmount = #$/RESOURCE[Oxidizer]/maxAmount$  // start from the PART base, find the node and get the amount value here
   @maxAmount += #$/RESOURCE[Oxidizer]/maxAmount$
   @maxAmount != #$/rescaleMult$
 }

 !RESOURCE[LiquidFuel] {}   // delete the LiquidFuel & Oxidizer node 
 !RESOURCE[Oxidizer] {}

 // we may have to resize the node too.

  var = #$node_stack_top[1]$     // get the second value of the node_stack_top
  @var *= #$rescaleMult$
  @node_stack_top = #$node_stack_top[0]$, $var$, $node_stack_top[2]$,$node_stack_top[3]$,$node_stack_top[4]$,$node_stack_top[5]$    // rebuild node_stack_top   
}

So, what's the proper syntax. the first char after the equal must be a #, then anything between two $ will be replaced by the result of the search string

valueName = #$search1$ $search2$ $search2$ // you get the drift

A search string is a optional "node position followed by a /" and a value name.

node position starts with

- "/" for the current PART (or other) root.

- "../" to get down one subnode from where you are. "../../" is down two, etc.

- @ flowed by the same string your use to choose which part to patch, to get a value from a different PART or other config.

So to get down to the fuel ratio of an engine :

/MODULE[ModuleEngines]/PROPELLANT[LiquidFuel]/ratio

As in the other MM command you can add a index to choose when more than one module is called the same

/MODULE,1[ModuleEngines]/PROPELLANT[LiquidFuel]/ratio

or add more info the select the one you want :

/MODULE[ModuleEngines]:HAS[#engineID[AirBreathing]]/PROPELLANT[LiquidFuel]/ratio

Now the value itself :

ratio // gets you the value called ratio

ratio,1 // gets you the second value called ratio

ratio[2] gets you the third comma separated field ( so if the value is "1,2,4,8,16" you get 4 )

ratio[2, ] gets you the third space separated field

ratio[2,/] gets you the third / separated field (you get it now I hope)

And you can combine them all :

ratio,1[2,/]

ModuleManager.2.3.6_dev.dll

ModuleManager-2.3.6_dev.zip

Edited July 2, 2016 by sarbian

[NathanKell]

That's utterly epic.

[Nori]

Trying to remove TweakScale from command modules. Have the following but it doesn't seem to work.

@PART[*]:HAS[@MODULE[ModuleCommand]]:Final
{
	!NODE[TweakScale]{}
}

I imagine I'm doing the delete wrong but not sure.

[Starwaster]

Trying to remove TweakScale from command modules. Have the following but it doesn't seem to work.

@PART
[*]:HAS[@MODULE[ModuleCommand]]:Final
{
    !NODE[TweakScale]{}
}

I imagine I'm doing the delete wrong but not sure.

Assuming that you have the correct name of the PartModule then....

It's

!MODULE[TweakScale]{}

not

!NODE

[Justin Kerbice]

@sarbian: I wonder why negation use two different characters in part check:

@PART[*]:HAS[!MODULE[ModuleCommand]]

@PART[*]:HAS[~TechRequired[]]

why not using the same '!' or '~' ?

Is there any difference with them (undocumented maybe) ?

And: FOR and NEEDS are equivalent or not ?

If I use FOR statement, does it check for existence of plug-in or directory ?

Or I need to combine both to make sure the plug-in is there and the patch is related to it ?

Thanks.

[sarbian]

!MODULE[ModuleCommand] check that there is no Node of type MODULE with name = ModuleCommand ( so no MODULE { name = ModuleCommand } )

~TechRequired[] check that there is no value called TechRequired ( so no line with TechRequired = xxxx )

We need both because if we use the same we can't know if you mean a value or a module, since nothing stops a PART from having both ressource = xxx and ressource { name = xxx key = yyy }

When MM starts it build a "list of mods". This list is

- the name of the loaded mods DLL

- the xxxx in the FOR/BEFORE/AFTER[xxxx]

- the directory name where patch without FOR/BEFORE/AFTER are

Then it check all the patch for :NEED. Any patch with a NEED[xxx] where xxxx is not in the "list of mods" is now removed, and won't be executed.

Then it runs the remaining patch in that order :

- All patch with :FIRST

- All patch with nothing set

- for each xxx in the "list of mods"

- BEFORE[xxx]

- FOR[xxx]

- AFTER[xxx]

- All patch with :FINAL

[Nori]

Assuming that you have the correct name of the PartModule then....

It's

!MODULE[TweakScale]{}

not

!NODE

Ah! Thanks, rookie mistake. First time trying to delete modules.

[Justin Kerbice]

!MODULE[ModuleCommand] check that there is no Node of type MODULE with name = ModuleCommand ( so no MODULE { name = ModuleCommand } )

~TechRequired[] check that there is no value called TechRequired ( so no line with TechRequired = xxxx )

We need both because if we use the same we can't know if you mean a value or a module, since nothing stops a PART from having both ressource = xxx and ressource { name = xxx key = yyy }

Did you choose a very bad example or I didn't catch the trick, cause if there are 2 different chars for the same logical operator for 2 different confignodes which are only those 2 (for now at least), it's useless cause MODULE are always in form MODULE{} whereas resources are either one or the other form which didn't use the name MODULE (obviously) at all.

Even the only parameter-less module I know use the usual syntax:

MODULE

{

name = ModuleSAS

}

as nothing else can use MODULE name, MM (should) know it's a module and not a MIA kerbals (in Tron style ) or a gremlin.

When MM starts it build a "list of mods". This list is

[...]

Then it check all the patch for :NEED. Any patch with a NEED[xxx] where xxxx is not in the "list of mods" is now removed, and won't be executed.

[...]

So, don't using NEEDS is quite a bad practice, which may explain some issues people have with HotRockets FX or other if for any reason, the plug-in is not loaded. HRFX and NEAR for example don't use it in their configs, NEAR use only FOR.

[undercoveryankee]

Did you choose a very bad example or I didn't catch the trick, cause if there are 2 different chars for the same logical operator for 2 different confignodes which are only those 2 (for now at least), it's useless cause MODULE are always in form MODULE{} whereas resources are either one or the other form which didn't use the name MODULE (obviously) at all.

Even the only parameter-less module I know use the usual syntax:

MODULE

{

name = ModuleSAS

}

as nothing else can use MODULE name, MM (should) know it's a module and not a MIA kerbals (in Tron style ) or a gremlin.

So, don't using NEEDS is quite a bad practice, which may explain some issues people have with HotRockets FX or other if for any reason, the plug-in is not loaded. HRFX and NEAR for example don't use it in their configs, NEAR use only FOR.

The issue is that the name of a value can be the same string as a node's type. A part's "module = Part" line differs from a MODULE node only by case, and it would be reckless for MM to depend on module types (e.g. PART, MODULE, RESOURCE) always being all capitals and value names always being mixed case. KSP would be happy to parse "MODULE = foo" if for whatever reason a file were written that way, distinguishing it from a MODULE node by the absence of curly braces.

HotRockets and NEAR shipping configs with :FOR is probably correct. :FOR[MyMod] means "this patch is part of MyMod's distribution, so it needs to run in the right order between :BEFORE[MyMod] and :AFTER[MyMod]." If configs using :FOR are installed and the plugin isn't, that's most likely an error on the part of the person installing the mod, because the only place they should have gotten configs with :FOR is from the author of the mod.

[Gaalidas]

I'll admit it all seems a little too confusing at first with all these separate operators that seem to be doing the same thing, but in the end it does make sense to save some time by simply using ~ instead of ! for parameters and values. Otherwise, you'd need to reinvent the wheel, so to speak, and basically parse the entire part configuration in the same way that KSP does itself in order to make sense of it before you even got the chance to check if you need to edit the part at all, and then figure out what to modify... it's all way too complicated for the needs of the tweakers (why does that sound so dirty? no... I don't want to know.)