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

[Sigma88]

yet another question about MM syntax

this is the situation:

I have a part named "A", there might be also a part named "B" but I can't know.

I would like to add a resource to part "B" if it exists, if not I want to add it to part "A"

(part A must NOT have that resource if part B exists)

could this work?

@PART[A]
{
    RESOURCE
    {
        name = ElectricCharge
        amount = 100
        maxAmount = 100
    }
}
@PART[B]
{

[COLOR=#ff0000]    !../PART[A]/Resource[ElectricCharge] // This part is supposed to delete the ElectricCharge from Part[A] only if Part[B] exists[/COLOR]

    RESOURCE
    {
        name = ElectricCharge
        amount = 100
        maxAmount = 100
    }
}

I'm not sure about the red bit, if that works then the patch should do what I want, right?

[NathanKell]

No. But consider:

@PART[A]

{

flag = #$/PART/name$ //or whatever the syntax is to get a key from a root node

}

@PART[A]:HAS[~flag[]]

{

// do stuff here for the case where B doesn't exist.

}

[Sigma88]

No. But consider:

@PART[A]

{

flag = #$/PART/name$ //or whatever the syntax is to get a key from a root node

}

@PART[A]:HAS[~flag[]]

{

// do stuff here for the case where B doesn't exist.

}

I thought the root node was the PART. That's why I asked, because I need a way to go back a step further

I actually managed to get a result that *should* work, I needed this to set up a cloud config.

Let me just say that the way every clouds pack handles configs is really a nightmare.

Edited July 31, 2015 by Sigma88

[anxcon]

bug?

@PART

[*]:HAS[@MODULE[ModuleLandingGear]|@MODULE[ModuleLandingGearFixed]|@MODULE[ModuleWheel]|@MODULE[bDAdjustableLandingGear]]

applies to all parts that have modules 1 2 or 4, but not 3 (ModuleWheel)

@PART

[*]:HAS[@MODULE[ModuleWheel]|@MODULE[ModuleLandingGear]|@MODULE[ModuleLandingGearFixed]|@MODULE[bDAdjustableLandingGear]]

ModuleWheel moved to 1st slot, works for all parts with ModuleWheel, not 2 3 or 4th module

i'm a bit confused, i've wrote tons of MM scripts and haven't ran into that issue

[blowfish]

Would it be possible to implement a system for other addons to register callback functions with MM to be called with the database is reloaded? It would be great to be able to reload custom data without having to reload the entire game.

[sarbian]

bug?

@PART

[*]:HAS[@MODULE[ModuleLandingGear]|@MODULE[ModuleLandingGearFixed]|@MODULE[ModuleWheel]|@MODULE[bDAdjustableLandingGear]]

applies to all parts that have modules 1 2 or 4, but not 3 (ModuleWheel)

@PART

[*]:HAS[@MODULE[ModuleWheel]|@MODULE[ModuleLandingGear]|@MODULE[ModuleLandingGearFixed]|@MODULE[bDAdjustableLandingGear]]

ModuleWheel moved to 1st slot, works for all parts with ModuleWheel, not 2 3 or 4th module

i'm a bit confused, i've wrote tons of MM scripts and haven't ran into that issue

There is no '|' operator at that level. '|' works inside a node name ( ie NODE[ThisName|ThatName] ) or NEEDS ( :NEED[ModA|ModB] ) but not in the HAS level. If it partially works then it is by pure luck (and bad quality of my parsing)

So

@PART[*]:HAS[@MODULE[ModuleLandingGear|ModuleLandingGearFixed|ModuleWheel|BDAdjustableLandingGear]]
{
//stuff
}

blowfish : yep, there was one in the past but it was more or less unusable with multiple MM and each version requiring a new compile. I need to find a new system that does not require as much hard linking (annotation and/or reflection ?).

I was considering it since I also want to write something that needs to run after MM, but I don't want to package it into MM since it is not config related.

[nightingale]

Would it be possible to implement a system for other addons to register callback functions with MM to be called with the database is reloaded? It would be great to be able to reload custom data without having to reload the entire game.

I'd probably consider using this too if it came to pass - for Contract Configurator I ended up creating my own reload button in my debug GUI that does a database reload + module manager reload + contract configurator reload.

[blowfish]

blowfish : yep, there was one in the past but it was more or less unusable with multiple MM and each version requiring a new compile. I need to find a new system that does not require as much hard linking (annotation and/or reflection ?).

I was considering it since I also want to write something that needs to run after MM, but I don't want to package it into MM since it is not config related.

Yeah, the system I was thinking of involved registering events, but that of course requires hard linking and thus recompiling on MM version changes, which is reasonable to want to avoid. Reflection might be work - one option might be to look through all LoadingSytem -derived types for a static method with a particular signature (e.g. MMOnReload()) or something like that, though LoadingSystem might be a bit heavy for some of the things people might be doing with this (and looking through all types seems excessive). Another option is the route blizzy78's toolbar takes, which is to have a bit of code that you copy into your project.

[sarbian]

Version 2.6.7 is out

- log now displays the SHA256 of all loaded dll and the KSP exe

- at the end of the patching MM will call other mods that implement a specific method.

Module Manager will

- call a public static method named ModuleManagerPostLoad in any class that implements it

public static void ModuleManagerPostLoad()
{
	// do stuff
}

- call the public method named ModuleManagerPostLoad in all the active instance of a class that inherit MonoBehaviour that implements it

public void ModuleManagerPostLoad()
{
	// do stuff
}

Both method must have no parameters.

Downloads :

ModuleManager.2.6.7.dll

ModuleManager-2.6.7.zip

SHA256 : 98471342be4f4dd13c2562c96b78c23f2ba741070b5fdcdb5d1cdd5bf63ecaf3

Edited August 4, 2015 by sarbian

[blowfish]

Wow, quick turnaround. Thanks so much!

[HafCoJoe]

an update!

[ctbram]

Can you add to the first node something about under what conditions you should delete the cache files (I believe there are four now that get created). I just pulled my hair out for two days because I could not get a couple mods to install. For example Active Texture Management was not compressing files and was actually causing my game to crash. I was getting numerous crashes and odd glitches during game play. As an after thought I deleted all four of the cache file and the first thing I noticed was ATM was clearing compressing mods as the load time went way up as it normally does the first time you launch using ATM. The game has worked fine sine. Now I am super paranoid and with every new mod I install or even updates I wipe the MM cache files. But I would like to know if this is really necessary?

[tkw]

[h=2]HTTP ERROR 404[/h]Problem accessing /jenkins/job/ModuleManager/94/artifact/ModuleManager-2.6.7.dll. Reason:

Not Found

i see this error download the .dii[h=2][/h]

[FlexGunship]

Okay, I did my best to hunt this down. I've read the ModuleManager handbook and syntax guides, I've reviewed all of the examples that are linked in there, and I just finished searching this thread.

I know there are similar questions, but I haven't seen this one.

I want to perform arithmetic on the second entry of each index of atmosphereCurve while leaving the first in tact. (This is to make 64k somewhat easier from a delta-v stance, but not a thrust/construction stance.) I've tried the following:

@PART[*]:HAS[@MODULE[ModuleEngines*]]
{
@MODULE[ModuleEngines*]
{
@heatProduction *= 0.66

@atmosphereCurve
{
@key,0 *= 1 *= 1.33
@key,1 *= 1 *= 1.33
}
}
}

@PART[*]:HAS[@MODULE[ModuleEngines*]]
{
@MODULE[ModuleEngines*]
{
@heatProduction *= 0.66

@atmosphereCurve
{
@key,0 = 0
@key,0 *= 1.33
@key,1 = 1
@key,1 *= 1.33
}
}
}

@PART[*]:HAS[@MODULE[ModuleEngines*]]
{
@MODULE[ModuleEngines*]
{
@heatProduction *= 0.66

@atmosphereCurve
{
@key,*,1 *= 1.33
}
}
}

I usually tackle these things on my own, but this one is besting me. Any thoughts?

[Starwaster]

Okay, I did my best to hunt this down. I've read the ModuleManager handbook and syntax guides, I've reviewed all of the examples that are linked in there, and I just finished searching this thread.

I know there are similar questions, but I haven't seen this one.

I want to perform arithmetic on the second entry of each index of atmosphereCurve while leaving the first in tact. (This is to make 64k somewhat easier from a delta-v stance, but not a thrust/construction stance.) I've tried the following:

@PART
[*]:HAS[@MODULE[ModuleEngines*]]
{
@MODULE[ModuleEngines*]
{
@heatProduction *= 0.66

@atmosphereCurve
{
@key,0 *= 1 *= 1.33
@key,1 *= 1 *= 1.33
}
}
}

@PART
[*]:HAS[@MODULE[ModuleEngines*]]
{
@MODULE[ModuleEngines*]
{
@heatProduction *= 0.66

@atmosphereCurve
{
@key,0 = 0
@key,0 *= 1.33
@key,1 = 1
@key,1 *= 1.33
}
}
}

@PART
[*]:HAS[@MODULE[ModuleEngines*]]
{
@MODULE[ModuleEngines*]
{
@heatProduction *= 0.66

@atmosphereCurve
{
@key,*,1 *= 1.33
}
}
}

I usually tackle these things on my own, but this one is besting me. Any thoughts?

I don't think you're going to be able to do that the way you want. You might have to use variables instead as detailed here: http://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-2-3-5-%28Sept-14%29-Loading-Speed-Fix?p=1416253&viewfull=1#post1416253

[blowfish]

Okay, I did my best to hunt this down. I've read the ModuleManager handbook and syntax guides, I've reviewed all of the examples that are linked in there, and I just finished searching this thread.

I know there are similar questions, but I haven't seen this one.

I want to perform arithmetic on the second entry of each index of atmosphereCurve while leaving the first in tact. (This is to make 64k somewhat easier from a delta-v stance, but not a thrust/construction stance.) I've tried the following:

@PART[*]:HAS[@MODULE[ModuleEngines*]]
{
@MODULE[ModuleEngines*]
{
@heatProduction *= 0.66

@atmosphereCurve
{
@key,0 *= 1 *= 1.33
@key,1 *= 1 *= 1.33
}
}
}

@PART[*]:HAS[@MODULE[ModuleEngines*]]
{
@MODULE[ModuleEngines*]
{
@heatProduction *= 0.66

@atmosphereCurve
{
@key,0 = 0
@key,0 *= 1.33
@key,1 = 1
@key,1 *= 1.33
}
}
}

@PART[*]:HAS[@MODULE[ModuleEngines*]]
{
@MODULE[ModuleEngines*]
{
@heatProduction *= 0.66

@atmosphereCurve
{
@key,*,1 *= 1.33
}
}
}

I usually tackle these things on my own, but this one is besting me. Any thoughts?

I don't think FloatCurve values can be edited with simple math. It's two or four numbers separated by spaces, and I don't believe MM knows what to do with that. As Starwaster mentioned, you might be able to do something with variables, though I don't know how you'd isolate the individual values in the first place.

[Sigma88]

@sarbian (mainly)

I was hitting a wall lately with a config I'm writing and I was almost ready to give up when this morning at 3.00 AM, I had the intuition that made me crack the issue.

now, I'm assuming this behaviour is a bit strange, if it's normal it means that I'm missing something.

if anyone can point it out for me I'd be grateful

is there any reason why this patch

{
// stuff
}[/COLOR]

[COLOR=#333333]@CLOUD_LAYER_PACK:HAS[@CLOUD_LAYER:HAS[@DEFAULTS:HAS[#body[[/COLOR][B][COLOR=#0000cd]Laythe[/COLOR][/B]],#altitude[[B][COLOR=#0000cd]6000[/COLOR][/B][COLOR=#333333]]]]]

works only if I target the first CLOUD_LAYER node, but not if I try to target any other?

I've checked and double-checked this, and it only works when the #body and #altitude values are those from the first CLOUD_LAYER node, and not from any of the others.

In the log there is no error, MM simply never applies the patch since (I assume) it doesn't find anything after the :HAS search

Edited August 11, 2015 by Sigma88

[DaMichel]

Hi, i need some help, too. I tried to make better configs for RealChuteLite bundled with FAR.

REALCHUTELITECONFIGS
{
    massOfMk1ParachuteInv = #$@PART[parachuteSingle]/mass$
    @massOfMk1ParachuteInv != -1  // 1 over ...
}

@PART[*]:HAS[@MODULE[ModuleParachute]]:NEEDS[!RealChute]:FOR[FerramAerospaceResearch]
{
        //Copies ModuleParachute to transform it into RealChute
        +MODULE[ModuleParachute]
        {
            @name = RealChuteFAR

            // mass = area * some-fixed-area-density
            // -> mass0 / area0 = mass1 / area1
            // -> area1 = area0 (mass1/mass0)
            // -> diameter1 = diameter0 (mass1/mass0)^(1/2)
            multiplier = #$../mass$
            @multiplier *= 10  // WORKS
            //@multiplier *= #$@REALCHUTELITECONFIGS/massOfMk1ParachuteInv$ // ERROR
            @multiplier != 0.5 // multiplier = sqrt(multiplier)
            %deployedDiameter = 25 // default
            @deployedDiameter *=  #$multiplier$
        }

This line "@multiplier *= #$@REALCHUTELITECONFIGS/massOfMk1ParachuteInv$" generates an error.

[ModuleManager] Error - Failed to do a maths replacement: +MODULE[ModuleParachute] : original value="0.1" operator=* mod value="#$@PART[parachuteSingle]/mass$"

I cannot figure it out. Even the error report seems wrong since it should be one over the mass of the Mk1 Parachute.

[Sigma88]

Hi, i need some help, too. I tried to make better configs for RealChuteLite bundled with FAR.

I cannot figure it out. Even the error report seems wrong since it should be one over the mass of the Mk1 Parachute.

have you considered doing this?

@PART
[*]:HAS[@MODULE[ModuleParachute]]:NEEDS[!RealChute]:FOR[FerramAerospaceResearch]
{
        +MODULE[ModuleParachute]
        {
            @name = RealChuteFAR
            %deployedDiameter = #$@PART[parachuteSingle]/mass$
            @deployedDiameter != -1
            @deployedDiameter *= #$../mass$
            @deployedDiameter *= 10
            @deployedDiameter != 0.5
            @deployedDiameter *= 25
        }
}

[blowfish]

IIRC MM doesn't apply patches inside top level nodes. So if you had REALCHUTELITECONFIGS:BEFORE[FerramAerospaceResearch] it should work.

[Starwaster]

IIRC MM doesn't apply patches inside top level nodes. So if you had REALCHUTELITECONFIGS:BEFORE[FerramAerospaceResearch] it should work.

No longer true; top level nodes are patched the same as anything else now. What's not patched are things that were originally configured in the PluginData folder......

[Sigma88]

on a side note:

are you sure you can use "+" ?

here it sais to use "#"

- # operator to copy-paste whole node from anywhere. The syntax look like the one for the variables. I hope the example make the syntax clear :

MY_NODE_LIBRARY
{
MODULE
{
name = MechJebCore
}
}

@PART
[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]
{
#@MY_NODE_LIBRARY/MODULE[MechJebCore] { }

MODULE
{
name = tobepasted
}

OTHER
{
fun = 9001
}

OTHER2
{
fun = 9001
}

MODULE
{
#../MODULE[tobepasted] { }

#../OTHER { }

#/OTHER2 { }
}
}
[/spoiler]

I've always used "+" only for PARTs and never for sub-nodes. but it may work anyways

[DaMichel]

Thanks. This worked

@PART[*]:HAS[@MODULE[ModuleParachute]]:NEEDS[!RealChute]:FOR[FerramAerospaceResearch]
{
        //Copies ModuleParachute to transform it into RealChute
        +MODULE[ModuleParachute]
        {
            @name = RealChuteFAR

            sizeMultiplier = #$@PART[parachuteSingle]/mass$
            @sizeMultiplier != -1  // 1 over ...
            @sizeMultiplier *= #$../mass$
            @sizeMultiplier != 0.5 // multiplier = sqrt(multiplier)

            %deployedDiameter = 25 // default
            @deployedDiameter *=  #$sizeMultiplier$
        }

IIRC MM doesn't apply patches inside top level nodes. So if you had REALCHUTELITECONFIGS:BEFORE[FerramAerospaceResearch] it should work.

This didn't.

are you sure you can use "+" ?

I don't know. It was this way before

By the way, 2.6.7 of ModuleManager is apparently not in CKAN. I didn't notice, so i've actually been using the previous version 2.6.6.

[Starwaster]

Thanks. This worked

@PART
[*]:HAS[@MODULE[ModuleParachute]]:NEEDS[!RealChute]:FOR[FerramAerospaceResearch]
{
        //Copies ModuleParachute to transform it into RealChute
        +MODULE[ModuleParachute]
        {
            @name = RealChuteFAR

            sizeMultiplier = #$@PART[parachuteSingle]/mass$
            @sizeMultiplier != -1  // 1 over ...
            @sizeMultiplier *= #$../mass$
            @sizeMultiplier != 0.5 // multiplier = sqrt(multiplier)

            %deployedDiameter = 25 // default
            @deployedDiameter *=  #$sizeMultiplier$
        }

This didn't.

I don't know. It was this way before

By the way, 2.6.7 of ModuleManager is apparently not in CKAN. I didn't notice, so i've actually been using the previous version 2.6.6.

Ok, no, you don't want to do that. You will literally copy the node and end up with 1 ModuleParachute and 1 RealChuteFAR on the same part.

Change that + to a @

@PART
[*]:HAS[@MODULE[ModuleParachute]]:NEEDS[!RealChute]:FOR[FerramAerospaceResearch]
{
        //Edit the node with ModuleParachute to transform it into RealChute
        @MODULE[ModuleParachute]
        {
            @name = RealChuteFAR

            sizeMultiplier = #$@PART[parachuteSingle]/mass$
            @sizeMultiplier != -1  // 1 over ...
            @sizeMultiplier *= #$../mass$
            @sizeMultiplier != 0.5 // multiplier = sqrt(multiplier)

            %deployedDiameter = 25 // default
            @deployedDiameter *=  #$sizeMultiplier$
        }
}

- - - Updated - - -

@sarbian (mainly)

I was hitting a wall lately with a config I'm writing and I was almost ready to give up when this morning at 3.00 AM, I had the intuition that made me crack the issue.

now, I'm assuming this behaviour is a bit strange, if it's normal it means that I'm missing something.

if anyone can point it out for me I'd be grateful

is there any reason why this patch

{
// stuff
}[/COLOR]

[COLOR=#333333]@CLOUD_LAYER_PACK:HAS[@CLOUD_LAYER:HAS[@DEFAULTS:HAS[#body[[/COLOR][B][COLOR=#0000cd]Laythe[/COLOR][/B]],#altitude[[B][COLOR=#0000cd]6000[/COLOR][/B][COLOR=#333333]]

works only if I target the first CLOUD_LAYER node, but not if I try to target any other?

I've checked and double-checked this, and it only works when the #body and #altitude values are those from the first CLOUD_LAYER node, and not from any of the others.

In the log there is no error, MM simply never applies the patch since (I assume) it doesn't find anything after the :HAS search

This is problematic given the lack of named nodes.

And your code example is missing about 3 brackets.

As for your 'stuff' you probably want to put your #body and #altitude checks in whatever is going in the 'stuff' to target individual layers

@CLOUD_LAYER_PACK
{
    @CLOUD_LAYER:HAS[#body[Laythe]]
    {
        @DEFAULTS // Only has one DEFAULTS per CLOUD_LAYER so don't do any targeting here
        {
            // your stuff
        }
    }
}

[Sigma88]

your code example is missing about 3 brackets.

yup, my fault... just a copy paste error on the forum tho. the cfg is fine

As for your 'stuff' you probably want to put your #body and #altitude checks in whatever is going in the 'stuff' to target individual layers

@CLOUD_LAYER_PACK
{
    @CLOUD_LAYER:HAS[#body[Laythe]]
    {
        @DEFAULTS // Only has one DEFAULTS per CLOUD_LAYER so don't do any targeting here
        {
            // your stuff
        }
    }
}

the "stuff" is supposed to be in "CLOUD_LAYER_PACK", the :HAS is just a check to target the correct "CLOUD_LAYER_PACK"

basically this is the concept of how it works:

1- every clouds pack (EVE, KSPRC, AVP) has an unique CLOUD_LAYER_PACK

2- if I find that unique CLOUD_LAYER_PACK then I know which mod the player is using

3- if I know which mod the player is using I can activate the correct .cfg for adding clouds (in this case to OPM)

4- the "stuff" is basically just adding a name and variable to that CLOUD_LAYER_PACK

%name = MainCloudPack

%CloudsMod = 1 // example: 1 for EVE, 2 for KSPRC, 3 for AVP

5- After I have defined it, I can check it's value to know which mod is installed

this is actually working. it just seems strange that it doesn't look for those :HAS in the whole "CLOUD_LAYER_PACK" but just in the first node.