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

[blowfish]

5 hours ago, Electrocutor said:

Is there an available syntax to copy a sub-node from a different parent?

Yeah, see here: https://github.com/KSP-RO/AJE/blob/6fff65c3ca7294607819e90c8c8e8599b131266f/GameData/AJE/Inlets/Squad.cfg#L8

[Electrocutor]

4 minutes ago, blowfish said:

Yeah, see here: https://github.com/KSP-RO/AJE/blob/6fff65c3ca7294607819e90c8c8e8599b131266f/GameData/AJE/Inlets/Squad.cfg#L8

Okay, so just starting a line with a variable acts as a node? Awesome, thanks: should add that to the syntax page.

Edited November 4, 2018 by Electrocutor

[blowfish]

1 minute ago, Electrocutor said:

Okay, so just starting a line with a variable acts as a node? Awesome, thanks: should add that to the syntax page.

It's slightly different than variables.  The first character is the same but then after that it's just a path to the node you want to paste.  No $ signs to interpolate

[Electrocutor]

2 minutes ago, blowfish said:

It's slightly different than variables.  The first character is the same but then after that it's just a path to the node you want to paste.  No $ signs to interpolate

I see that; while I'm on the subject of syntax, was the request a long time ago about optional ordering ever put in somehow?

@PART[]:NEEDS[abc] {} // requires abc

@PART[]:AFTER[abc] {} // does not require abc, but will process after if it exists

 

[Gordon Dry]

On 7/13/2018 at 9:11 PM, Gordon Dry said:

@blowfish How do I calculate a square root?

I have to repeat my question ...

 

Edited November 6, 2018 by Gordon Dry

[sarbian]

@value != 0.5

[sarbian]

Version 3.1.1

• more Internal code improvement by @blowfish

Downloads :

ModuleManager-3.1.1.zip

ModuleManager.3.1.1.dll

[blowfish]

Bit more info on this update, there are some noteworthy changes:

The parsing of root node and patch names (e.g. @PART[www]:HAS[xxx]:FOR[yyy]:NEEDS[zzz]) now follows a formal structure rather than each bit trying to be extracted individually.  This makes it much easier to change or add features.  It could mean that there is some bad data that was silently accepted before but will error now.  Eventually this system will be extended to parsing subnodes and values of patches too, but one thing at at time.

Some things that were previously errors are now just warnings.  Warnings will still complain to the user, but they will not prevent the cache from being created.  These are generally things where a patch has bad data but ModuleManager can guess the intent.  In general these should be fixed by the mod author in a timely manner.  One example is multiple pass specifiers on the same patch.  Previously it would error, now it will take the first one and warn.

[Jesusthebird]

3 hours ago, blowfish said:

Bit more info on this update, there are some noteworthy changes:

The parsing of root node and patch names (e.g. @PART[www]:HAS[xxx]:FOR[yyy]:NEEDS[zzz]) now follows a formal structure rather than each bit trying to be extracted individually.  This makes it much easier to change or add features.  It could mean that there is some bad data that was silently accepted before but will error now.  Eventually this system will be extended to parsing subnodes and values of patches too, but one thing at at time.

Some things that were previously errors are now just warnings.  Warnings will still complain to the user, but they will not prevent the cache from being created.  These are generally things where a patch has bad data but ModuleManager can guess the intent.  In general these should be fixed by the mod author in a timely manner.  One example is multiple pass specifiers on the same patch.  Previously it would error, now it will take the first one and warn.

Ok so I guess to clarify, The parsing needs to be in a specific order now?

:HAS[xxx]:FOR[xxx]:NEEDS[xxx] = correct and no error?

HAS[xxx]:NEEDS[xxx]:FOR[xxx] = incorrect and causes error?

also...edit

:HAS[xxx]:NEEDS[xxx]:FOR[xxx] = correct?

HAS:[xxx]NEEDS:[xxx]FOR:[xxx] = incorrect?

Edited November 12, 2018 by Jesusthebird

[blowfish]

9 minutes ago, Jesusthebird said:

Ok so I guess to clarify, The parsing needs to be in a specific order now?

HAS->FOR->NEEDS: correct and no error?

HAS->NEEDS->FOR: incorrect and causes error?

Order does not matter.

[Wyzard]

10 hours ago, blowfish said:

Some things that were previously errors are now just warnings.  Warnings will still complain to the user, but they will not prevent the cache from being created.

Minor thing: when there are warnings, the summary text on the loading screen says something like "8 warnings</yellow>" — I think the closing tag needs to be "</color>" for the game to recognize it.

[blowfish]

1 hour ago, Wyzard said:

Minor thing: when there are warnings, the summary text on the loading screen says something like "8 warnings</yellow>" — I think the closing tag needs to be "</color>" for the game to recognize it.

Ahh thanks.  Got a report of this earlier it turns out but couldn't make sense of it until now.

[LatiMacciato]

8 hours ago, blowfish said:

Ahh thanks.  Got a report of this earlier it turns out but couldn't make sense of it until now.

CKAN installed me the 3.1.1 and the tag still shows up, shall I try the link posted by @sarbian?

EDIT:
v3.1.1 (both CKAN and the link version) shows up the "</yellow>", v3.1.0 doesn't. Saw this commit and it did not make it into the last version, I assume it will be patched next release, right?

 

Edited November 13, 2018 by LatiMacciato

[blowfish]

1 hour ago, LatiMacciato said:

EDIT:
v3.1.1 (both CKAN and the link version) shows up the "</yellow>", v3.1.0 doesn't. Saw this commit and it did not make it into the last version, I assume it will be patched next release, right?

3.1.1 was before the fix

Edited November 13, 2018 by blowfish

[Bit Fiddler]

What is wrong with this .cfg line?  it errors out with the comment "Cannot parse node name as tag list: encountered opening bracket in traileron:"  . 

@PART[*]:HAS[@RESOURCE[MonoPropellant]],!MODULE[ConfigurableContainers],!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[ModuleB9PartSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]:FINAL

 

Edited November 17, 2018 by Bit Fiddler

[LatiMacciato]

35 minutes ago, Bit Fiddler said:

What is wrong with this .cfg line?  it errors out with the comment "Cannot parse node name as tag list: encountered opening bracket in traileron:"  . 

@PART[*]:HAS[@RESOURCE[MonoPropellant]],!MODULE[ConfigurableContainers],!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[ModuleB9PartSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]:FINAL

 

@PART[*]:HAS[@RESOURCE[MonoPropellant]],!MODULE[ConfigurableContainers],!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[ModuleB9PartSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]:FINAL

// should be

@PART[*]:HAS[@RESOURCE[MonoPropellant]],!MODULE[ConfigurableContainers],!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[ModuleB9PartSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]:FINAL

have you tried adding ] before :FINAL ?

Edited November 17, 2018 by LatiMacciato

[Bit Fiddler]

ah I see, I closed the HAS here...  

HAS[@RESOURCE[MonoPropellant]]

so when counting open and close bracket it all added up.

 

Thanks...  just blind I guess.

 

Edited November 17, 2018 by Bit Fiddler

[Dedalous]

On 11/12/2018 at 11:54 PM, Wyzard said:

Minor thing: when there are warnings, the summary text on the loading screen says something like "8 warnings</yellow>" — I think the closing tag needs to be "</color>" for the game to recognize it.

Is there a way to locate the warnings like it does with errors?

[blowfish]

1 hour ago, Dedalous said:

Is there a way to locate the warnings like it does with errors?

It's all in the log.

[Wyzard]

Is there a way to use an "OR" relationship within a :HAS, to match parts that have any of several different modules?  I tried both HAS[@MODULE[ModuleFoo|ModuleBar]] and HAS[@MODULE[ModuleFoo]|@MODULE[ModuleBar]], but neither seems to work.

If not, I know of a possible workaround: have separate patches with HAS[@MODULE[ModuleFoo]] and HAS[@MODULE[ModuleBar]] that just set "someTemporaryVariable = y", followed by a HAS[#someTemporaryVariable[y]] patch to do the real work and delete the variable.  But that's awkward, so I'm hoping I can avoid it.

(On a related note, if I put several patches like that within the same file, are they guaranteed to apply in the same order as they're written in the file?  Assuming they have the same :FOR, of course.)

[LatiMacciato]

@PART[*]:HAS[@MODULE[Needed],!MODULE[NotNeeded]]
{ }

searches for MODULE with name = Needed but filters (excludes MODULES with name = NotNeeded)

I wrote a little patch file where I use MKS's internalDampener

@PART[*]:NEEDS[MKS&ConfigurableContainers]:HAS[@MODULE[ModuleTankManager],!MODULE[USI_InertialDampener]]:FINAL
{
	MODULE { name = USI_InertialDampener }
}

this might be helpful too

Regards

Edited November 25, 2018 by LatiMacciato

[Electrocutor]

@blowfish So... the new version of MM no longer puts the translation of cfg into the cache, but instead the pre-process commands. Is there still a way to see what the actual output cfg is after processing?

 

My scenario is that this...

		#@StockPBR_Templates/MATERIAL[SpecularFixed]
		{
		}

... does not seem to be copying the SpecularFixed one, but instead the first MATERIAL node it finds. I wanted to see the post-process cfg to verify.

Edited November 25, 2018 by Electrocutor

[blowfish]

6 hours ago, Electrocutor said:

@blowfish So... the new version of MM no longer puts the translation of cfg into the cache, but instead the pre-process commands. Is there still a way to see what the actual output cfg is after processing?

 

My scenario is that this...

		#@StockPBR_Templates/MATERIAL[SpecularFixed]
		{
		}

... does not seem to be copying the SpecularFixed one, but instead the first MATERIAL node it finds. I wanted to see the post-process cfg to verify.

I'm not seeing anything wrong with the cache.  Can you show me what you're seeing?

E: Could not replicate any issues with pasting nodes either

Spoiler

SOME_NODE
{
    INNER_NODE
    {
        name = blah1
        value = something1
    }
    INNER_NODE
    {
        name = blah2
        value = something2
    }
}

SOME_OTHER_NODE
{
    stuff = meh
}

@SOME_OTHER_NODE:FINAL
{
    #@SOME_NODE/INNER_NODE[blah2] {}
}

// in config cache:

UrlConfig
{
	name = SOME_OTHER_NODE
	type = SOME_OTHER_NODE
	parentUrl = /test
	SOME_OTHER_NODE
	{
		stuff = meh
		INNER_NODE
		{
			name = blah2
			value = something2
		}
	}
}

 

@Wyzard not currently possible to use or in that context.  Will probably be done eventually but need to clean up a lot of code first.  But patches in the same file and pass will be applied in order.

Edited November 25, 2018 by blowfish

[Electrocutor]

27 minutes ago, blowfish said:

I'm not seeing anything wrong with the cache.  Can you show me what you're seeing?

E: Could not replicate any issues with pasting nodes either

UrlConfig
{
	name = KSP_MODEL_SHADER
	type = KSP_MODEL_SHADER
	parentUrl = StockPBR/Squad/Parts/Command/Mk1-3Pod/Mk1-3
	KSP_MODEL_SHADER
	{
		model = Squad/Parts/Command/Mk1-3Pod/Mk1-3
		#@StockPBR_Templates/Transparent/MATERIAL
		{
		}
		@MATERIAL[Transparent]
		{
			mesh = Flag
		}
		#@StockPBR_Templates/SpecularFixed/MATERIAL
		{
		}
		@MATERIAL[SpecularFixed]
		{
			mesh = M1-3
		}
	}
}

I'm on 3.1.1. I changed it so it only had a single line to follow instead of multiple of the same node type, but it still isn't working right.

Edited November 25, 2018 by Electrocutor

[blowfish]

2 minutes ago, Electrocutor said:

I'm on 3.1.1. I changed it so it only had a single line to follow instead of multiple of the same node type, but it still isn't working right.

Can you also show the patch this stuff is in?