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

[Starwaster]

add the unmet req to the original needs

What he's trying to do should still work though and WAS working with past versions of MM.

[nightingale]

add the unmet req to the original needs

What he's trying to do should still work though and WAS working with past versions of MM.

Yup, and I oversimplified it to give the simplest still broken example. This also does not work:

[B]Config:[/B]
// A NEEDS dependency that will be met
SOME_NODE:NEEDS[ModuleManager.2.6.7|SomeUnmetDep]
{
    // 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]
    {
    }
}

[Sigma88]

Yup, and I oversimplified it to give the simplest still broken example. This also does not work:

[B]Config:[/B]
// A NEEDS dependency that will be met
SOME_NODE:NEEDS[ModuleManager.2.6.7|[COLOR=#008000][B]Dep1[/B][/COLOR]] //
{
    // A NEEDS dependency that will not be met
    CHILD_NODE:NEEDS[[B][COLOR=#ff0000]Dep2[/COLOR][/B]]
    {
    }
}

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

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

are you sure you can use ":NEEDS" in child nodes?

and are you sure you can use "ModuleManager.2.6.7" in a ":NEEDS" check?

and, are you sure you can use ":NEEDS" non in a patch?

this is what I would try:

File1.cfg = setting the node

SOME_NODE
{
    CHILD_NODE
    {
    }
}

File2.cfg = patching the node

!SOME_NODE:NEEDS[![B][COLOR=#008000]Dep1[/COLOR][/B]] {} // if the mod Dep1 [B]is installed[/B], SOME_NODE [B]will not be deleted[/B]
@SOME_NODE:NEEDS[![B][COLOR=#ff0000]Dep2[/COLOR][/B]] // if the mod Dep1 [B]is not installed[/B], SOME_NODE [B]will be deleted[/B]
{
    !CHILD_NODE {}
}

Expected result with Dep1 and without Dep2:

SOME_NODE
{
}

or you could do the same thing, but using the patch to add the subnodes instead of deleting it which I guess is better.

Edited August 17, 2015 by Sigma88

[Starwaster]

Sigma88: Re: child nodes. Again, It used to work in previous versions of MM. It no longer works now. Below is an example of some fairly complex patching for KSO depending on whether or not RSS was installed or not:

Yes, these all worked. (these are for example only, of patches that I know for a fact worked before. They are currently obsolete and deprecated)

@PART[super25rudderkso]:BEFORE[DeadlyReentry]:NEEDS[DeadlyReentry]
{
@maxTemp = 1500
MODULE
{
name = ModuleHeatShield
ablative = HeatCapacity


direction:NEEDS[!RealSolarSystem] = 0, 0, 0 // omnidirectional light shielding
direction:NEEDS[RealSolarSystem] = 0, 1, 0 // forward standard shielding (only when playing Real Solar System mod)


reflective:NEEDS[RealSolarSystem] = 1.8 // 180% of heat is ignored at correct angle (no, seriously. You have NO idea until you've attempted this in RSS with FAR)
reflective:NEEDS[!RealSolarSystem] = 0.05 // 5% of heat is ignored at correct angle
//adjustCollider = -0.015

loss:NEEDS[RealSolarSystem]
{
key = 650 0 0 0 // start ablating at 650 degrees C
key = 2000 1000 0 0 // peak ablation at 2000 degrees C
key = 6000 2000 0 0 // max ablation at 6000 degrees C
}

dissipation:NEEDS[RealSolarSystem]
{
// dissipation is based on the part's current temperature
key = 300 0 0 0 // begin dissipating at 300 degrees C
key = 800 250 0 0 // maximum dissipation at 500 degrees C
}
}


RESOURCE:NEEDS[RealSolarSystem]
{
name = HeatCapacity
amount = 3000
maxAmount = 3000
}
MODULE:NEEDS[RealSolarSystem]
{
name = ModuleGenerator
isAlwaysActive = true
OUTPUT_RESOURCE
{
name = HeatCapacity
rate = 0.2
}
}
}

[sarbian]

When did it last work ? I don't think I made any change to that part of the code for a while so I don't see why it would break

[Starwaster]

When did it last work ? I don't think I made any change to that part of the code for a while so I don't see why it would break

I don't know; I haven't used KSO much in awhile and haven't verified any change in functionality of those configs since sometime between KSP 0.90 and 1.0.

So... probably it worked at least as late as 2.5.6

I'll make up some new test configs and watch the logs and see if anything turns up as well as verifying that there is an issue. But not until after I've had some bed and comatose time.

(on a related note, I've been up all night with MJ2 and RCSFX and found a control input issue in RCSFX that definitely will hamper MJ2 no matter how much torque calculation you do. Tell you more later)

[ABZB]

Hello:

I having the following issue:

the code:

    MODULE
    {
		name = InterstellarFuelSwitch
		resourceGui = Liquid Hydrogen;Liquid Helium;Hydrolox;Methalox;Liquid Oxygen;Liquid Methane;Liquid Ammonia;Hydrazine;Liquid Nitrogen;Liquid CarbonDioxide;Liquid CarbonMonoxide;Water;Kerosene
		resourceNames = LqdHydrogen;LqdHelium;LqdHydrogen,LqdOxygen;LqdMethane,LqdOxygen;LqdOxygen;LqdMethane;LqdAmmonia;Hydrazine;LqdNitrogen;LqdCO2;LqdCO;Water;Kerosene
		resourceAmounts = 26880;26880;21504,5376;14972,10632;26880;26880;26880;26880;26880;26880;26880;26880;26880

		@resourceAmounts[0,;] = #$/../RESOURCE[LiquidFuel]/maxAmount$ //LqdHydrogen
		@resourceAmounts[1,;] = #$/../RESOURCE[LiquidFuel]/maxAmount$ //LqdHelium
.
.
.
.

is returning these errors:

[WRN 21:23:38.536] InsterstellarFuelSwitch: error parsing resourceTankAmountArray amount 1/0: '#$../RESOURCE[LiquidFuel]/maxAmount$': '#$../RESOURCE[LiquidFuel]/maxAmount$' with error: Unknown char: #
[WRN 21:23:38.538] InsterstellarFuelSwitch: error parsing initialResourceList amount 1/0: 'System.Collections.Generic.List`1[System.Double]': '#$../RESOURCE[LiquidFuel]/maxAmount$' with error: Unknown char: #
[WRN 21:23:38.539] InsterstellarFuelSwitch: error parsing resourceTankAmountArray amount 2/0: '#$../variableone$,#$../variabletwo$': '#$../variableone$' with error: Unknown char: #
[WRN 21:23:38.540] InsterstellarFuelSwitch: error parsing initialResourceList amount 2/0: 'System.Collections.Generic.List`1[System.Double]': '#$../variableone$' with error: Unknown char: #
[WRN 21:23:38.541] InsterstellarFuelSwitch: error parsing resourceTankAmountArray amount 2/1: '#$../variableone$,#$../variabletwo$': '#$../variabletwo$' with error: Unknown char: #
[WRN 21:23:38.543] InsterstellarFuelSwitch: error parsing initialResourceList amount 2/1: 'System.Collections.Generic.List`1[System.Double]': '#$../variabletwo$' with error: Unknown char: #

It looks like the array insert does not work with the variable reference? What am I missing?

thanks!

[Felbourn]

Hmm I am not aware of being able to modify a single index inside a key. It looks like you're trying to reference a second resourceAmount which does not exist. So either I am about to learn something new that you can do, or I have found the problem. I would have redone the entire resourceAmount line and used indexing to "copy" the old resourceAmount values where I was not changing them, and then replace the rest.

[sarbian]

Yep, the "resourceAmounts[1,;]" is meant to be on the right side of the equal.

[ABZB]

Yep, the "resourceAmounts[1,;]" is meant to be on the right side of the equal.

I am not clear on exactly what the that means? could you write me an example of that?

[sarbian]

Here :

MODULE
{
	resourceAmounts = 26880;26880;21504,5376;14972,10632;26880;26880;26880;26880;26880;26880;26880;26880;26880

	mycustomvalue = #$./resourceAmounts[0,;]$ // this will be 26880
}

[ABZB]

Here :

MODULE
{
	resourceAmounts = 26880;26880;21504,5376;14972,10632;26880;26880;26880;26880;26880;26880;26880;26880;26880

	mycustomvalue = #$./resourceAmounts[0,;]$ // this will be 26880
}

I am trying to do the opposite - assign various formula-derived custom values to indices of resourceAmounts...

In any event, it seems that I actually can do a simple assignment as follows:

resourceAmounts = #$value0$;$value1$;$value2$;$value3$

apparently, # only should appear once, at the start of the line, which was unclear to me from the documentation.

[Pinchy]

http://forum.kerbalspaceprogram.com/threads/127138-1-0-x-Contract-Pack-Base-Constuction-v0-2-2?p=2137970&viewfull=1#post2137970

Is there any update to the fix for this ^ please

[sashan]

So, mods without dll's should be referenced by their GAmeData folder name?

[Hupherius]

I have a problem where a mods MM.cfg has rewritten a part with ill affects and could use some MM help to fix the desired output. It concerns a MFT Module and the available tanks.

Here is what I want:

MODULE {

name = ModuleFuelTanks

volume = 43200

type = Default

basemass = 0.0003125 * volume

baseCostPV = 0

typeAvailable = Default

typeAvailable = TalUtility

typeAvailable = LifeSupportAll

}

But this MFT.cfg strips away the TalUtility and LifeSupportAll available tanks, leaving just Default and Cryogenic. Is there a syntax that would just add another typeAvailable = line to the module instead of replacing them?

// Adds tank type Cryogenic to all default tanks

@PART

[*]:HAS[@MODULE[ModuleFuelTanks]]:FINAL

{

@MODULE[ModuleFuelTanks]:HAS[#type[Default]]

{

%typeAvailable = Default

typeAvailable = Cryogenic

}

}

[ABZB]

Get rid of %...default line.

If that is needed in parts that previously only had default, write two separate config nodes, for each case.

[Starwaster]

http://forum.kerbalspaceprogram.com/threads/127138-1-0-x-Contract-Pack-Base-Constuction-v0-2-2?p=2137970&viewfull=1#post2137970

Is there any update to the fix for this ^ please

As I understand it, the problem was in subnode NEEDS being treated as met that were actually unmet?

As in: The following should fail for the RESOURCE?

@PART[crewCabin]:NEEDS[Squad]
{
	RESOURCE:NEEDS[asdfasdfasdf]
	{
		name = LiquidFuel
		amount = 32000
		maxAmount = 32000
	}
}

Because that's what I just tested out, and as expected, the RESOURCE did not get added and the log reveals the following when processing it:

[ModuleManager] Deleting node in file: /NEEDS.TESTING subnode: @PART[crewCabin]:NEEDS[squad]/@PART[crewCabin]:NEEDS[squad][]/RESOURCE:NEEDS[asdfasdfasdf] as it can't satisfy its NEEDS

Looks to me like it's failing where it should fail.

[nightingale]

As I understand it, the problem was in subnode NEEDS being treated as met that were actually unmet?

As in: The following should fail for the RESOURCE?

@PART[crewCabin]:NEEDS[Squad]
{
    RESOURCE:NEEDS[asdfasdfasdf]
    {
        name = LiquidFuel
        amount = 32000
        maxAmount = 32000
    }
}

Because that's what I just tested out, and as expected, the RESOURCE did not get added and the log reveals the following when processing it:

Looks to me like it's failing where it should fail.

What's output in the log and what actually ends up happening after that log message is output are two different things. Have a look at the config cache or do a database dump to see what's actually happening and you should expect to see this:

[COLOR=#333333]PART
[/COLOR]{
    RESOURCE:NEEDS[asdfasdfasdf]
    {
        name = LiquidFuel
        amount = 32000
        maxAmount = 32000
    }
}

Of course, in my test it was being done right in the original config node definition, and not in a @ patch node, so that's another possible difference. The issue appears to be that when a NEEDS check passes on an outer node where there was an inner node that previously failed a NEEDS check, the inner node ends up being added back in (module manager syntax and all). In the example above, the stock code just ignores the unrecognized node, but in the original Contract Configurator issue that this was raised for, it actually prevents the contract in question from being loaded.

[Pinchy]

The contract doesn't work - so something is not working - I am neither a coder or tester, but nightingale believes there to be a bug in the MM code which is causing these contracts to be "Red" in contract configurator.

[Hupherius]

Get rid of %...default line.

If that is needed in parts that previously only had default, write two separate config nodes, for each case.

Thank you!

[Starwaster]

What's output in the log and what actually ends up happening after that log message is output are two different things. Have a look at the config cache or do a database dump to see what's actually happening and you should expect to see this:

[COLOR=#333333]PART
[/COLOR]{
    RESOURCE:NEEDS[asdfasdfasdf]
    {
        name = LiquidFuel
        amount = 32000
        maxAmount = 32000
    }
}

Of course, in my test it was being done right in the original config node definition, and not in a @ patch node, so that's another possible difference. The issue appears to be that when a NEEDS check passes on an outer node where there was an inner node that previously failed a NEEDS check, the inner node ends up being added back in (module manager syntax and all). In the example above, the stock code just ignores the unrecognized node, but in the original Contract Configurator issue that this was raised for, it actually prevents the contract in question from being loaded.

ok, I think I get it now. The node is still hanging around in the database as some unrecognized malformed thing.

[ABZB]

Thank you!

no problem - I did the exact same thing for myself with the toroidal tank.

[Pinchy]

Thanks Starwaster - do we have an ETA for a fix?

[nightingale]

ok, I think I get it now. The node is still hanging around in the database as some unrecognized malformed thing.

Yup, exactly.

[Whovian]

Just wanted to share this with you guys

(That is, a lot of legacy)