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

[Sigma88]

42 minutes ago, Galenmacil said:

Thanks a lot!

Dang, the module manager syntax is so weird sometimes. I read official documentation and tried everything I could find but it all turned to nothing.

Your simple "code" works!

"&" means "add only if missing"

[monstah]

On 07/10/2017 at 1:26 AM, Nightside said:

Since no one has mentioned it...

Module Manager does not crash 1.3.1

Better yet, seems to be working  

[EdwardB3020]

this mod ahem plugin is pretty good!

[Wyzard]

On 10/7/2017 at 4:49 PM, Sigma88 said:

"&" means "add only if missing"

Is that documented somewhere?  The MM syntax documentation only seems to mention "@" for edit, "+" and "$" for copy, "-" and "!" for delete, and "%" for edit-or-create.

[Sigma88]

1 minute ago, Wyzard said:

Is that documented somewhere?  The MM syntax documentation only seems to mention "@" for edit, "+" and "$" for copy, "-" and "!" for delete, and "%" for edit-or-create.

On 25/10/2013 at 3:01 PM, sarbian said:

Version 2.6.23

• @blowfish patch to add & operator: insert only if it doesn't already exist
• Fix for the insert NODE at position keeping the index in the node name that blowfish found
• fix for nested constraint not looking past the first result

 

 

[h0yer]

Heya!

 

I'm whipping up some minor MM patch and wanted to ask for some help, in regards to wildcards and adding stuff to the end of already existing stuff. (I'm quite new to 'making things' in KSP^^)

I'm quite hestitant to 'just try it out', don't wanna mess up things, although a lot of people say one can't really mess up things with ModuleManager. Better be safe. At least right now, where my understanding lacks... understanding^^

I already gave the MM wiki a peek, but I'm not fully sure if I properly understood using wildcards and other 'fancy' things^^

 

The general idea:

Adding all agency logos from my "CRAP" mod to the "DecalStickers" mod from blackheart612.

It has four "sticker" parts, which all four need just a few more entries added to the end of 2 different config nodes/strings.

 

 

The already existing lines inside DecalStickers: (shortened for overview, if legit^^)

MODULE
{
	name = FStextureSwitch2
	moduleID = 1
	nextButtonText = Next Flag
	prevButtonText = Previous Flag
	statusText = Current
	textureRootFolder = Squad\
	textureNames = Flags\Default ; Flags\esa_dark_blue 		//Wanna add paths here
	objectNames = stickerflat;stickerh;stickerv				//Wanna add names here
	textureDisplayNames = KSP;ESA
	debugMode = true
	showInfo = false
}

 

What I've "whipped up" so far:
 

@PART[sticker~]:HAS[FStextureSwitch2]:NEEDS[blackheart]
{
	@MODULE,1[FStextureSwitch2]
	{
		@textureNames = :$: ; \CommunityRealAgencyPack\Agencies\ISRO_logo:		//Almost 90 additional entries
		@textureDisplayNames = :$: ;ISRO:		//Almost 90 additional entries
	}
}

Am I applying the [sticker~] wildcard properly? It should act on four parts, named "stickerbig; stickerh; stickermini and stickerv", IF they contain a [FStextureSwitch2] node.

I've salvaged the :$: blabla: from other mods' guts, intended for adding all additions to the end of the already existing entries.

The leading semicolon I guess is therefore necessary, due to the original lines not ending in one, which they don't need to, because of no necessity for the last entry?

I'm really confused by "textureRootFolder", I believe I need to change my entered paths in some way, but clueless how it needs to look. I'd need to "go up" one folder layer.

 

I hope I asked the right questions in the right way^^

 

Thanks for giving us MM!

Peace and have fun

[Aelfhe1m]

2 hours ago, h0yer said:

What I've "whipped up" so far:
 

@PART[sticker~]:HAS[FStextureSwitch2]:NEEDS[blackheart]
{
	@MODULE,1[FStextureSwitch2]
	{
		@textureNames = :$: ; \CommunityRealAgencyPack\Agencies\ISRO_logo:		//Almost 90 additional entries
		@textureDisplayNames = :$: ;ISRO:		//Almost 90 additional entries
	}
}

Am I applying the [sticker~] wildcard properly? It should act on four parts, named "stickerbig; stickerh; stickermini and stickerv", IF they contain a [FStextureSwitch2] node.

I've salvaged the :$: blabla: from other mods' guts, intended for adding all additions to the end of the already existing entries.

The leading semicolon I guess is therefore necessary, due to the original lines not ending in one, which they don't need to, because of no necessity for the last entry?

I'm really confused by "textureRootFolder", I believe I need to change my entered paths in some way, but clueless how it needs to look. I'd need to "go up" one folder layer.

 

I hope I asked the right questions in the right way^^

1. The wildcard is * not ~

2. You don't need to use an index on the module (and if you did it would go at the end not in the middle

3. To add to the end of a key the syntax is keyname ^= :$:new value:  - you're missing the ^

4. Your texture names should not start with a \

Putting it all together:

@PART[sticker*]:HAS[FStextureSwitch2]:NEEDS[blackheart]
{
	@MODULE[FStextureSwitch2]
	{
		@textureNames ^= :$:; CommunityRealAgencyPack\Agencies\ISRO_logo; CommunityRealAgencyPack\Agencies\ISRO_logo2: // etc.
		@textureDisplayNames = :$:;ISRO;ISRO2:	
	}
}

 

[h0yer]

@Aelfhe1m

Things are now much clearer, thank you very much

 

I indexed the module only because the original is indexed as well, and there is another texture switcher node with index 2, I thought it is somewhat important^^

And thanks especially for pointing out the leading backslashes, they surely would have caused me lots of headaches!

 

OK, I'll try to stitch all that together and learn something from it.

Again, thanks a lot

[Aelfhe1m]

4 minutes ago, h0yer said:

I indexed the module only because the original is indexed as well, and there is another texture switcher node with index 2, I thought it is somewhat important^^

I downloaded a fresh copy of decal stickers from SpaceDock to check but I'm only seeing one FStextureSwitch2 module in each part. (The FSmeshSwitch module has a different name so it doesn't matter for indexing purposes.)

[h0yer]

2 minutes ago, Aelfhe1m said:

I downloaded a fresh copy of decal stickers from SpaceDock to check but I'm only seeing one FStextureSwitch2 module in each part. (The FSmeshSwitch module has a different name so it doesn't matter for indexing purposes.)

Oh my!

OK I have badly overseen that one, I should be more careful/less hasty

Thanks again^^

[Nightside]

Hi all,

I'm trying to generically patch fairings to a larger scale, but I keep getting errors with this config.

This first config works the one that is commented out doesn't work. Is there a way to use variables here or do these values need to be set directly?

@PART[*]:HAS[@MODULE[ModuleProceduralFairing]] //:FOR[zzz_TRANSMOGRIFIER]
{

	@MODEL,0 
	{
		%scale = 1.6, 1, 1.6 //This works
		//%scale = #$@TRANSMOGRIFIER/transmogrifierScalar$, 1, #$@TRANSMOGRIFIER/transmogrifierScalar$ //this does not work - parts don't even show up in KSP log or in game.
	}	
}

Any thoughts?

[Sigma88]

17 minutes ago, Nightside said:

Hi all,

I'm trying to generically patch fairings to a larger scale, but I keep getting errors with this config.

This first config works the one that is commented out doesn't work. Is there a way to use variables here or do these values need to be set directly?

@PART[*]:HAS[@MODULE[ModuleProceduralFairing]] //:FOR[zzz_TRANSMOGRIFIER]
{

	@MODEL,0 
	{
		%scale = 1.6, 1, 1.6 //This works
		//%scale = #$@TRANSMOGRIFIER/transmogrifierScalar$, 1, #$@TRANSMOGRIFIER/transmogrifierScalar$ //this does not work - parts don't even show up in KSP log or in game.
	}	
}

Any thoughts?

There is an empty line between @PART and {

This will break MM

[Tyko]

If I want to comment out an @module change, do I just comment out the initial @module line or must I comment out all the subsequent lines down to the close bracket for that module?

 

 

[blowfish]

1 hour ago, Tyko said:

If I want to comment out an @module change, do I just comment out the initial @module line or must I comment out all the subsequent lines down to the close bracket for that module?

 

 

You should comment out the entire node, otherwise KSP will see it as a node with no name.  Many editors will allow you to select the beginning of all those lines at once so that you can commend them all at the same time.

[Johould]

On 4/24/2016 at 7:49 AM, NecroBones said:

Adding tags should be pretty easy. Strings can be added onto by doing something like this:

@PART[MassiveBooster]
{
	%tags = #$tags$ sounding
}

The variable can reference itself and add something at the end.

Unfortunately this doesn't work any more when the part has no tags, it produces errors and leaves the tags unchanged.

[LOG 20:54:45.931] [ModuleManager] Applying node MyModuleManangerPatches/categories/@PART[*]:HAS[#manufacturer[USI?-?Logistics?Division],~tags[*cck-logistics*]] to UmbraSpaceIndustries/Kontainers/Kontainer_KIS_03/C3_Kontainer_KIS_03
[LOG 20:54:45.931] [ModuleManager] Cannot find key tags in PART
[LOG 20:54:45.931] [ModuleManager] Error - Cannot parse variable search when replacing (%) key tags = #$tags$ cck-logistics

Using a separate &tags entry seems to work:

@PART[MassiveBooster]
{
	@tags = #$tags$ sounding
	&tags = sounding
}

 

[Nightside]

22 hours ago, Sigma88 said:

There is an empty line between @PART and {

This will break MM

Hmm, thanks for the help. I made sure there was no empty line and cleaned up my messy comments but I'm still having problems.

What are the rules for multiplying terms?

Given:     var = 2

and:        definition = 1,1,1

?????:     What goes here? - I have tried @definition,* *=#$var$ but that doesn't seem to work

Desired: definition = 2, 2, 2

------------------------------------

I would like to use a variable to change the values but I have been getting errors and now I'm not sure if its because of something wrong with my variables (which work in other cases) or just my multiplication technique.

_______________________

Getting a lot of this error:

[LOG 08:55:21.117] [ModuleManager] Error - Failed to do a maths replacement: @INTERNAL[*]:HAS[~TransmogrifyExclude[*rue]]:FOR[zzz_TRANSMOGRIFIER] : original value="1, 1, 1" operator=* mod value="1.6"

 

Trial and error and error and error and... finally got the syntax in the right order to multiply to all parts of the key

Edited October 19, 2017 by Nightside
fixed it!

[flart]

Hi, I tried to put handrails to cck-eva-items (CCK KIS-category), but this patch didn't work. (disappeared from "utility" as expected, but didn't appear at "EVA Items")

Spoiler

// NEBULA eva handrail
@PART[*handrail*]:NEEDS[CommunityCategoryKit]:NEEDS[KIS]:NEEDS[NEBULA]:AFTER[CommunityCategoryKit]:AFTER[KIS]:AFTER[NEBULA]
{
  @category = none
  @tags ^= :^:cck-eva-items
}

@PART[*handle*]:NEEDS[CommunityCategoryKit]:NEEDS[KIS]:NEEDS[NEBULA]:AFTER[CommunityCategoryKit]:AFTER[KIS]:AFTER[NEBULA]
{
  @category = none
  @tags ^= :^:cck-eva-items
}

 

Lightweight gamerun. Patch, CommunityCategoryKit, NEBULA, KAS, KIS. LOG-file - https://ufile.io/o7ssa

Edited October 22, 2017 by flart

[Aelfhe1m]

@flart The main problem is the @tags line. When using ^= the trailing part needs three :s. One at the beginning, one to separate search from replace and one at the end. In most cases when adding a tag you want to stick it on the end, so: @tags ^= :$: extratag: Also note the space in the middle to separate the new tag from the existing ones.

You can also merge the :NEEDS into a single statement :NEEDS[CommunityCategoryKit,KIS,NEBULA] and since the order of patch execution during the :BEFORE :FOR :AFTER phase is alphabetical you only need one :AFTER with the highest value (alphabetically).

Putting it all together:

Spoiler

// NEBULA eva handrail
@PART[*handrail*]:NEEDS[CommunityCategoryKit,KIS,NEBULA]:AFTER[NEBULA]
{
  @category = none
  @tags ^= :$: cck-eva-items:
}

@PART[*handle*]:NEEDS[CommunityCategoryKit,KIS,NEBULA]:AFTER[NEBULA]
{
  @category = none
  @tags ^= :$: cck-eva-items:
}

 

 

[flart]

@Aelfhe1m, thank you, I corrected that, but result the same. (not inside "utility", not inside "EVA Items")

KSP_with_patch https://ufile.io/b4eap (not inside "utility", not inside "EVA Items")

KSP_without_patch https://ufile.io/8v7ze (inside "utility")

[Aelfhe1m]

16 minutes ago, flart said:

@Aelfhe1m, thank you, I corrected that, but result the same. (not inside "utility", not inside "EVA Items")

KSP_with_patch https://ufile.io/b4eap (not inside "utility", not inside "EVA Items")

KSP_without_patch https://ufile.io/8v7ze (inside "utility")

Well that shows that "some" patch is being applied at the right time:

Spoiler

[LOG 15:51:16.810] [ModuleManager] :AFTER[NEBULA] pass
[LOG 15:51:16.812] [ModuleManager] Applying node 0_My/Patches/categories/@PART[*handrail*]:AFTER[NEBULA] to NEBULA/handrail 1mR curved/handrail 1mR curved/EVA handrail curved 1mR
[LOG 15:51:16.815] [ModuleManager] Applying node 0_My/Patches/categories/@PART[*handrail*]:AFTER[NEBULA] to NEBULA/handrail 2mR curved/handrail 2mR/EVA handrail 2mR
[LOG 15:51:16.816] [ModuleManager] Applying node 0_My/Patches/categories/@PART[*handrail*]:AFTER[NEBULA] to NEBULA/handrail 2mR curved/handrail 2mR/EVA handrail curved 3mR
[LOG 15:51:16.817] [ModuleManager] Applying node 0_My/Patches/categories/@PART[*handrail*]:AFTER[NEBULA] to NEBULA/handrail type1/handrail type1/EVA handrail type 1
[LOG 15:51:16.818] [ModuleManager] Applying node 0_My/Patches/categories/@PART[*handrail*]:AFTER[NEBULA] to NEBULA/handrail type1/handrail type1/EVA handrail type 1a
[LOG 15:51:16.819] [ModuleManager] Applying node 0_My/Patches/categories/@PART[*handrail*]:AFTER[NEBULA] to NEBULA/handrail type2/handrail type2/EVA handrail type 2
[LOG 15:51:16.821] [ModuleManager] Applying node 0_My/Patches/categories/@PART[*handrail*]:AFTER[NEBULA] to NEBULA/handrail type2/handrail type2/EVA handrail type 2a
[LOG 15:51:16.824] [ModuleManager] Applying node 0_My/Patches/categories/@PART[*handle*]:AFTER[NEBULA] to NEBULA/handle/handle type1/handle type1
[LOG 15:51:16.826] [ModuleManager] Applying node 0_My/Patches/categories/@PART[*handle*]:AFTER[NEBULA] to NEBULA/handle/handle type1/handle type1a

The log isn't very helpful for diagnosing MM problems (unless there's an actual patch error reported or you're trying to find conflicting patches, which is not the case here).

Try posting a link to your ModuleManager.ConfigCache file - it will show what the modified part configs look like after patching.

 

EDIT: downloaded EVA handrails continued to test myself. The problem is that the original parts don't have any tags. You can change the patch to work with either modifying a n existing tag or adding a whole new tag set:

Spoiler

// NEBULA eva handrail
@PART[*handrail*]:NEEDS[CommunityCategoryKit,KIS,NEBULA]:AFTER[NEBULA]
{
  @category = none
  @tags ^= :$: cck-eva-items: // will apply if part has tags
  &tags = cck-eva-items NEBULA handrails // will apply if part has no existing tags
}

@PART[*handle*]:NEEDS[CommunityCategoryKit,KIS,NEBULA]:AFTER[NEBULA]
{
  @category = none
  @tags ^= :$: cck-eva-items:
  &tags = cck-eva-items NEBULA handrails
}

 

 

Edited October 22, 2017 by Aelfhe1m
Further testing

[flart]

@Aelfhe1m It has not tags-value at all https://ufile.io/7e09c

Maybe there is another command for creating tags-value?

 

EDIT: Thank you, it works now.

Edited October 22, 2017 by flart

[Aelfhe1m]

2 minutes ago, flart said:

@Aelfhe1m It has not tags-value at all https://ufile.io/7e09c

Maybe there is another command for creating tags-value?

Just posted an edit to my last post after I noticed that myself.

[Blyad Cat]

I'm getting  crashes on KSP with any mods. Current mod list: B9 HX, B9 Partswitch, B9Animation Modules, BD Armory, CAL, DockingCam, FShangarExtender, KAX, NAS, North Kerbin Weaponry, Physics Range Extender, SmokeScreen, Firespitter, and Vessel Mover. I'm thinking it has something to do with module manager. 

Logs here: https://drive.google.com/open?id=0Bz9EqChWXJTfOWtfUnpHLWYzZm8

[blowfish]

1 hour ago, Blyad Cat said:

I'm getting  crashes on KSP with any mods. Current mod list: B9 HX, B9 Partswitch, B9Animation Modules, BD Armory, CAL, DockingCam, FShangarExtender, KAX, NAS, North Kerbin Weaponry, Physics Range Extender, SmokeScreen, Firespitter, and Vessel Mover. I'm thinking it has something to do with module manager. 

Logs here: https://drive.google.com/open?id=0Bz9EqChWXJTfOWtfUnpHLWYzZm8

Welcome to the forums, and thanks for providing logs!

The crash is likely the result of a module on the part BDArmory/Parts/AmmoBox/BDAcUniversalAmmoBox/UniversalAmmoBoxBDA .  Could you verify that all the plugins you have installed are for at least KSP 1.3.0?  These days, that is usually the cause of this sort of crash.

[h0yer]

Heya!

Got another few questions regarding MM syntax:

How far can one go with *wildcards and partnames in general?

Can I use a @PART[part1;part2;...] to apply the exact same patches to a set of specific parts? (Changing textures for example)

Or can I use a @PART[*decal*] to include all parts that are, for example named "Flat Decal", "Decal Curved" and "Funny Decal Of Fun"? Are two wildcards allowed?

I believe I'm getting more and more a hand on MM, I really start to like it a lot