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

[sarbian]

Wanted to inform you that module manager 2.6.7 breaks the opentree mod. It makes the stock tech tree appear in place of that one, there are no parts in the nodes. Reverting to MM 2.6.6 fixes. Will cross post in their thread.

Log ? That helps when you want something fixed.

[FlexGunship]

Sigh... I'm officially too stupid for this (which I didn't expect, I write motion control software for a living).

I just want to take atmosphereCurve and rescale it to improve fuel economy for 64k. I've tried standard edits, and not variables. I can't seem to get the data out and modify only the ISP by some multiplier.

Has anyone done this successfully? Or is there a module manager file for a mod that does this that I can reference?

[Felbourn]

I'm becoming somewhat of a MM master at this point. I'm "reprogramming" my entire game with it to change balance, and well... everything. I even used MM to quite a generic square root function that I use for a few calculations when altering mass values! I can help you out Flex. But I'm not 100% sure what you're asking still. You just want to change the Isp vsalues for one atmo curve in one engine?

Here's one example of an atmo curve I use for my own game:

@PART[*]:HAS[@PLUME[*]]:AFTER[zPhase2Engines]
{
    %ACTIONS
    {
        action = set Isp curve
    }
    @MODULE[ModuleEngines*]
    {
        @atmosphereCurve
        {           
            @key,0 = #0 $/VARS/isp_v$
            @key,1 = #1 $/VARS/isp_sl$
        }
    }
}

Edited August 8, 2015 by Felbourn

[FlexGunship]

I'm becoming somewhat of a MM master at this point. I'm "reprogramming" my entire game with it to change balance, and well... everything. I even used MM to quite a generic square root function that I use for a few calculations when altering mass values! I can help you out Flex. But I'm not 100% sure what you're asking still. You just want to change the Isp vsalues for one atmo curve in one engine?

No, I'd like scale the ISP of all LFO engines up by about 30%.

Example... take:

atmosphereCurve

{

key = 0 400

key = 1 300

}

...and make that...

atmosphereCurve

{

key = 0 533

key = 1 400

}

EDIT:

Right now I'm... kinda... doing this by:

@RESOURCE_DEFINITION[LiquidFuel]
{
	@density *= 0.7
}

@RESOURCE_DEFINITION[Oxidizer]
{
	@density *= 0.7
}

Double Edit: To be clear, I gave an example above, but I'd like to hit all engines with an equivalent scale.

Edited August 8, 2015 by FlexGunship

[Felbourn]

Ooooo I am about to learn something new, because I have not tried doing this exact kind of change before. The issue is I am not sure how to two-dimensionaly index into the key. My first guess is something like this, but now I need to test it and see if I am right:

@PART[yourPartName]
{
    @MODULE[ModuleEngines*]
    {
        @atmosphereCurve
        {           
            key0 = #$key,0[1]$
            @key0 *= 1.3
            key1 = #$key,1[1]$
            @key1 *= 1.3
            @key,0 = #0 $key0$
            @key,1 = #1 $key1$
        }
    }
}

[FlexGunship]

        @atmosphereCurve
        {           
            @key,0 = #0 $/VARS/isp_v$
            @key,1 = #1 $/VARS/isp_sl$
        }

Okay, I came close to this part. I didn't see any evidence of it doing anything. do I need a different /VAR/ for every single engine? MM completes one modification before moving on, right? So I should be able to use the same convention. But, this doesn't take the value and actually modify it, right? In fact, as near as I can tell, it writes a value indiscriminately.

- - - Updated - - -

@PART[yourPartName]
{
    @MODULE[ModuleEngines*]
    {
        @atmosphereCurve
        {           
            key0 = #$key,0[1]$
            @key0 *= 1.3
            key1 = #$key,1[1]$
            @key1 *= 1.3
            @key,0 = #0 $key0$
            @key,1 = #1 $key1$
        }
    }
}

Spoiler alert... that doesn't work. You've latched on to the exact problem. There seems to be no way to get to that second value.

EDIT: Uh, okay, upon a closer look. I have NOT tried exactly what you posted. It looked like something I did try.

- - - Updated - - -

Okay, I came close to this part. I didn't see any evidence of it doing anything. do I need a different /VAR/ for every single engine? MM completes one modification before moving on, right? So I should be able to use the same convention. But, this doesn't take the value and actually modify it, right? In fact, as near as I can tell, it writes a value indiscriminately.

- - - Updated - - -

Spoiler alert... that doesn't work. You've latched on to the exact problem. There seems to be no way to get to that second value.

EDIT: Uh, okay, upon a closer look. I have NOT tried exactly what you posted. It looked like something I did try.

DOUBLE EDIT: Okay, yes, same message I got before (doing it a different way)... essentially it can't grab ONLY the second entry.

[LOG 20:33:21.326] [ModuleManager] Error - Failed to do a maths replacement: @atmosphereCurve : original value="0 210" operator=* mod value="1.3"
[LOG 20:33:21.327] [ModuleManager] Error - Failed to do a maths replacement: @atmosphereCurve : original value="1 175" operator=* mod value="1.3"

[Felbourn]

I'll go read the source code and get back to you when/if I see the answer in it.

- - - Updated - - -

I'm looking at source now, but did you every try it like this?

key0 = #$key,0$
@key0 = #$key0[1]$
@key0 *= 1.3
@key,0 = #0 $key0$

- - - Updated - - -

Hmmm might have figured it out... maybe?

key0 = #$key,0[1, ]$
@key0 *= 1.3
@key,0 = #0 $key0$

[FlexGunship]

I'll go read the source code and get back to you when/if I see the answer in it.

- - - Updated - - -

I'm looking at source now, but did you every try it like this?

key0 = #$key,0$
@key0 = #$key0[1]$
@key0 *= 1.3
@key,0 = #0 $key0$

- - - Updated - - -

Hmmm might have figured it out... maybe?

key0 = #$key,0[1, ]$
@key0 *= 1.3
@key,0 = #0 $key0$

Tried the first... not the second. Will try the second now.

EDIT: you tricked me! You edited between my refreshes. I was about to replay... "wait, that won't work".

DOUBLE EDIT: Well... this will be the FIRST time I've ever used variables on atmosphereCurve and didn't get an error.

- - - Updated - - -

Felbourn, you're a genius. It works. It actually works. I thought I had a typo, but when I checked in game values, it was fine. so I'm unclear as to what "0[1, ]" and "1[1, ]" actually do. Well, I know what they do... I don't really know why.

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

		@atmosphereCurve
		{
			key0 = #$key,0[1, ]$
			@key0 *= 1.3
			@key,0 = #0 $key0$
			key1 = #$key,1[1, ]$
			@key1 *= 1.3
			@key,1 = #1 $key1$	
		}			
	}
}

Edited August 8, 2015 by FlexGunship

[SorensonPA]

What luck! I've been doing an ad-hoc MM-based science progression deal of sorts and the isp scaling is the one bit I was having trouble with, so many thanks.

One thing I did notice, however, is that if a part has only one isp value (stock jet engines and OPT dark drives and Mk 2 scramjets, for example) any additional key,# entries will keep piling on it so it winds up getting modded to the square of the multiplier value, so this would need something with the ability to detect that there're no more key,# entries to mod and stop instead of looping back.

[Felbourn]

What luck! I've been doing an ad-hoc MM-based science progression deal of sorts and the isp scaling is the one bit I was having trouble with, so many thanks. One thing I did notice, however, is that if a part has only one isp value (stock jet engines and OPT dark drives and Mk 2 scramjets, for example) any additional key,# entries will keep piling on it so it winds up getting modded to the square of the multiplier value, so this would need something with the ability to detect that there're no more key,# entries to mod and stop instead of looping back.

You mean you tried it and it did this? Or you just think it should? Because I thought it would not. It uses a different key0 or key1 etc for each line, and if a key,0 or key,1 etc is missing then it can't replace anything, so it should get ignored (maybe with an error message, but still ignored).

Also if we just want to get rid of those meaningless errors so we don't see errors, we could try a HAS on @atmosphereCurve.

Something like: @atmosphereCurve:HAS[#key,0[]]

Maybe that would work, or is really close.

Just need to have one @atmosphereCurve for each change you want to make.

@atmosphereCurve:HAS[#key,0[]]
{
    %newKey = #$key,0[1, ]$
    @newKey *= 1.3
    @key,0 = #0 $newKey$
}
@atmosphereCurve:HAS[#key,1[]]
{
    %newKey = #$key,1[1, ]$
    @newKey *= 1.3
    @key,1 = #1 $newKey$
}

[SorensonPA]

You mean you tried it and it did this? Or you just think it should?

I ran the configuration as copied from FlexGunship's latest post where he confirmed your approach worked:

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

		@atmosphereCurve
		{
			key0 = #$key,0[1, ]$
			@key0 *= 1.3
			@key,0 = #0 $key0$
			key1 = #$key,1[1, ]$
			@key1 *= 1.3
			@key,1 = #1 $key1$	
		}			
	}
}

That config worked fine on any engine with 2 or more key entries (ion engine with 100-4200 reads as 130-5460, modded T-1 aerospike with base isp of 464-464 is now 603.2-603.2) but anything that had just 1 key value got a squared increase - the aforementioned OPT dark drive has a single entry of 3000, but comes out at 5070 and the stock basic jet engine has 9600 but comes out to 16224 after patching.

I'm trying to run your latest bit now, though I'm guessing I'm hosing up the formatting somehow since it won't even take root.

[Felbourn]

Maybe I needed the wildcards:

@atmosphereCurve:HAS[#key,0[*]]
{
    %newKey = #$key,0[1, ]$
    @newKey *= 1.3
    @key,0 = #0 $newKey$
}
@atmosphereCurve:HAS[#key,1[*]]
{
    %newKey = #$key,1[1, ]$
    @newKey *= 1.3
    @key,1 = #1 $newKey$
}

This only works for 2 entries. Engines with 3+ will need this repeated for each instance of a key.

Edited August 8, 2015 by Felbourn

[SorensonPA]

No bite, just a NullRef exception:

[LOG 21:00:23.821] [ModuleManager] Exception while processing node : /Kingularity_Values/@PART[*]:HAS[@MODULE[ModuleEngines*]]:Final
System.NullReferenceException: Object reference not set to an instance of an object
  at ModuleManager.MMPatchLoader.WildcardMatchValues (.ConfigNode node, System.String type, System.String value) [0x00000] in <filename unknown>:0 
  at ModuleManager.MMPatchLoader.CheckConstraints (.ConfigNode node, System.String constraints) [0x00000] in <filename unknown>:0 
  at ModuleManager.MMPatchLoader+<CheckConstraints>c__AnonStorey3.<>m__0 (System.String c) [0x00000] in <filename unknown>:0 
  at System.Collections.Generic.List`1[System.String].TrueForAll (System.Predicate`1 match) [0x00000] in <filename unknown>:0 
  at ModuleManager.MMPatchLoader.CheckConstraints (.ConfigNode node, System.String constraints) [0x00000] in <filename unknown>:0 
  at ModuleManager.MMPatchLoader.ModifyNode (.ConfigNode original, .ConfigNode mod) [0x00000] in <filename unknown>:0 
  at ModuleManager.MMPatchLoader.ModifyNode (.ConfigNode original, .ConfigNode mod) [0x00000] in <filename unknown>:0 
  at ModuleManager.MMPatchLoader+<ApplyPatch>c__Iterator1.MoveNext () [0x00000] in <filename unknown>:0 

It's probably something stupid on my end, here's the config I'm running this on:

@PART[*]:HAS[@MODULE[ModuleEngines*]]:Final
{	
	@MODULE[ModuleEngines*]
    {    
        @atmosphereCurve:HAS[#key,0[*]]
        {
            %newKey = #$key,0[1, ]$
            @newKey *= 1.3
            @key,0 = #0 $newKey$
        }
        @atmosphereCurve:HAS[#key,1[*]]
        {
            %newKey = #$key,1[1, ]$
            @newKey *= 1.3
            @key,1 = #1 $newKey$
        }
	}
}

I'm wondering if it might be a tabbing error from copypasting the code or something, seems Notepad++ doesn't compensate for pasted tabs.

EDIT: I might just be making an ass of myself by making some mistake only invisible to the programming-illiterate, but I think I might have gotten it:

@PART[*]:HAS[@MODULE[ModuleEngines*]]:Final
{
    @MODULE[ModuleEngines*]
    {    
        @atmosphereCurve:HAS[#key[0?*]]
        {
            %newKey = #$key,0[1, ]$
            @newKey *= 1.3
            @key,0 = #0 $newKey$
        }
        @atmosphereCurve:HAS[#key[1?*]]
        {
            %newKey = #$key,1[1, ]$
            @newKey *= 1.3
            @key,1 = #1 $newKey$
        }
    }
}

Unmodded ion's 130-5460, modded T-1 aerospike is 603.2-603.2, basic jet engine is 12480, OPT dark drive is 3900. I do get the feeling that this approach is only hitting stuff that reads as key,x = 0 x and key,x = 1 x - there's some air-breathing rocket engine with a funky atmosphereCurve setup with the ASL value unchanged while the vac rating was modified. EDIT: Yeah, looks like that's it, here's the part's curve:

	atmosphereCurve
 	{
			key = 0 340

			key = 0.1 850
 	}

Although it certainly begs the question of why he'd use a setup like that when atmCurve would do the same and better.

EDIT: I've also noticed this doesn't do anything for mode-based engines, but that's just a matter of fiddling with the specified affected modules in some fashion.

Edited August 8, 2015 by SorensonPA

[anxcon]

whatd i do wrong?

//file 1

MODULE_LIBRARY:NEEDS[modularFuelTanks]

{

MODULE

{

name = ModuleFuelTanks

volume = 1000

type = JetBasic

typeAvailable = JetBasic

typeAvailable = RocketBasic

}

}

//file 2

@PART[TankMk3Short]:NEEDS[modularFuelTanks]:FOR[modularFuelTanks]

{

//A) doesnt work, trying to paste a template

// #@MODULE_LIBRARY/MODULE[ModuleFuelTanks] ( )

//B) works the normal way

MODULE

{

name = ModuleFuelTanks

volume = 1000

type = JetBasic

typeAvailable = JetBasic

typeAvailable = RocketBasic

}

//C) would this work (when fixed)? pasting a template then edit to fit

// #@MODULE_LIBRARY/MODULE[ModuleFuelTanks]

// {

// //D) assuming C would work when fixed, would this work?

//i assume need @volume, but if i dont put volume in template, would i still need @?

// volume = 1500

// }

}

Edited August 10, 2015 by anxcon

[sarbian]

whatd i do wrong?

You used something that does not exist ?

[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

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.

I'm bumping this one since I'm really curious about it

Edited August 11, 2015 by Sigma88

[sarbian]

I have a strong suspicion that it does not work because it only test the first CLOUD_LAYER. I need to look into the code but I can't for now.

[Sigma88]

I have a strong suspicion that it does not work because it only test the first CLOUD_LAYER. I need to look into the code but I can't for now.

ehm, yeah... that's exactly what I'm saying.

It only checks the first

so If I target the first everything works properly, but If I try targetting the second it doesn't "find it" so the patch is skipped

I managed to make the mod work anyways, I just thought it was a weird behaviour

Edited August 11, 2015 by Sigma88

[anxcon]

You used something that does not exist ?

http://forum.kerbalspaceprogram.com/threads/55219-0-90-Module-Manager-2-5-10-%28Feb-13%29-Including-faster-cats?p=1805260&viewfull=1#post1805260

was using the copy/paste module function of that post

granted using MODULE_LIBRARY not MY_NODE_LIBRARY (latter didnt work either) but according to your post it exists

was trying to place the template in file 1, and the part edit script in file 2 (same file it didnt get the module either)

loaded game, checked part

case A) didnt work direct apply (no copy/paste) works with same module setup

so unless feature removed, it exists, and i did it wrong

[sarbian]

Your post has parenthesis at the end of the line. You need to use curly brackets.

And FOR and NEED in the same line does not make sense. FOR define a NEED. use one or the other.

[Starwaster]

Your post has parenthesis at the end of the line. You need to use curly brackets.

And FOR and NEED in the same line does not make sense. FOR define a NEED. use one or the other.

wait really? But FOR also specifies scheduling passes and NEEDS can be used to run in the absence of a specific mod. There's times where you do want to use both.

[sarbian]

Sorry, my statement was missleading. The line I am talking about is :

@PART[TankMk3Short]:NEEDS[modularFuelTanks]:FOR[modularFuelTanks]

As you can see the NEED and FOR are the same.

[anxcon]

wow i didnt even see it wasnt curly bracket notepad++ shows both the same to me, mustve hit the other by reflex

ok so now that it works for me to paste amodule, sorry again

wass able to test my other question

simply suggesting impliment B

//A) this works now yay

#@MODULE_LIBRARY/MODULE[ModuleFuelTanks] { }

//B) this doesn't

#@MODULE_LIBRARY/MODULE[ModuleFuelTanks]

{

@volume = 500

}

//C) this works

#@MODULE_LIBRARY/MODULE[ModuleFuelTanks] { }

@MODULE[ModuleFuelTanks]

{

@volume = 500

}

while C works, its redundant text and kinda feels like B should work

atleast this cleans up alot of my MM files now heh nice feature ty

Edited August 12, 2015 by anxcon

[nightingale]

I've got what looks like a bug with handling of ModuleManager NEEDS on different nodes within a heirarchy. The issue was reported on CosmoBro's Base Construction contract pack here (you can find the users logs in that post). The problem is that when a NEEDS check is unmet on a child node, but a different NEEDS check is met on the parent node, then the child node does not get removed. Example:

[B]Config:[/B]
// A NEEDS dependency that will be met
SOME_NODE:NEEDS[ModuleManager.2.6.7]
{
    // A NEEDS dependency that will not be met
    CHILD_NODE:NEEDS[SomeUnmetDep]
    {
    }
}

[B]Expected result:
[/B]SOME_NODE
{
}

[B]Actual result:
[/B]SOME_NODE
{
    CHILD_NODE:NEEDS[SomeUnmetDep]
    {
    }
}

[anxcon]

add the unmet req to the original needs