Jump to content

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


sarbian

Recommended Posts

4 minutes ago, blowfish said:

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

Edited by Electrocutor
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Jesusthebird
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by LatiMacciato
Link to comment
Share on other sites

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 by blowfish
Link to comment
Share on other sites

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 by Bit Fiddler
Link to comment
Share on other sites

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 by LatiMacciato
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

@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 by LatiMacciato
Link to comment
Share on other sites

@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 by Electrocutor
Link to comment
Share on other sites

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 by blowfish
Link to comment
Share on other sites

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 by Electrocutor
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...