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

[sarbian]

Okay, version 1.5 is the official release. (1.4 shall be forgotten)

Edited the first 2 post for link, changes and doc.

Thanks to all who helped and shared their mind.

Edited November 11, 2013 by sarbian

[Starwaster]

Okay, version 1.5 is the official release. (1.4 shall be forgotten)

Edited the first 2 post for link, changes and doc.

Thanks to all who helped and shared their mind.

Has MODULEMANAGER[LOCAL] {} been tested by the people who need that feature and found to be working as it should?

[asmi]

The only question I've got is wheither 1.5 is 100% backward-compatible with 1.3?

[Starwaster]

The only question I've got is wheither 1.5 is 100% backward-compatible with 1.3?

I'm currently using it with the installation I use for My Real Solar System install with several mods that use MM such as Modular Fuel Tanks. Also an assortment of config files that add various things to parts. All 1.3 files with no modifications.

[sirklick]

Excellent work sarbian, I know it wasn't easy figuring out how to keep everyone "happy". I have been using the dev releases for the past few days without hitch.

[johnsonwax]

Ok, I want to do something complicated...

I'm working on .cfg files for AIES to add tech tree and RT2 support. I intend to add the RT2 support through one .cfg file not unlike how RT2 modifies stock. These won't have the :FINAL parameter. They'll add MODULE[ModuleRTAntenna] node to the dozen or so parts that need RT2 support. The second .cfg will be the one that adds the standard bits to all the pieces such as the MODULE[ModuleDataTransmitter] node and will have the :FINAL parameter. Now, in this file on some parts I want it to add the ModuleDataTransmitter node only if there is no MODULE[ModuleRTAntenna]. My question:

I can see that you can use wildcards when modifying nodes, but the syntax doesn't seem to allow you to do that when creating them. I could create two entries in the file, one which only modifies the part if the ModuleRTAntenna node isn't present, and then the second that does all of the other bits, but I'd prefer to have it all together. I think this is my best option - 3 modifications to the part. First adds RT2 support, non-final. Second checks for RT2 support, final, processes after the RT2 one. Third (in same file as second) applies to anything without tech tree and applies it, also final. The last two can go in either order, so having them both process in the 2nd pass is fine.

RT2 file: @PART[Dishcl1] {}

AIES file: @PART[Dishcl1]:HAS[!MODULE[ModuleRTAntenna]]:Final {}

AIES file: @PART[Dishcl1]:HAS[~TechRequired[]]:Final {}

Questions:

1) Does 2 :FINAL node edits cause one to be blocked, or do they all process just fine. That is, does :FINAL simply signal what pass to do the modification in?

2) Is there a simpler way to process this? I want to keep the RT2 one clean like RT2 does, so I don't really want to invert the order. My expectation is that Carmics will get TechRequired added and that last element will simply disappear, but the RT2 one may always be needed. Not sure if that support will get built in either by Carmics or by Cilph.

3) What does the # signify in the expression? Is that necessary to indicate that it's a property and not a node? If so, then # is used for a match, ~ is used to find missing, but for nodes you don't need a prefix for a match, and ! is used to find missing. Is that correct?

[sarbian]

I don't understand what you mean by "I can see that you can use wildcards when modifying nodes, the syntax doesn't seem to allow you to do that when creating them"

1) It just tell MM to process the modification in a later pass. You can put the :Final anywhere in the file, the non final will be processed first then the :Final

2) If I understand what you want, no I don't think you can do it simpler.

3) The "first" line of each patch can use different symbol to find a specific PART (to keep it simple) : @ and ! are used for node, # and ~ for properties. You always need one of those 4 in the :HAS[ ] part

Once you are inside the curly bracket you can only use @ to go inside an existing node, ! to delete it or nothing to create it. Same for properties

[johnsonwax]

I don't understand what you mean by "I can see that you can use wildcards when modifying nodes, the syntax doesn't seem to allow you to do that when creating them"

What I mean, is can I have a second pass on the pattern:

@PART[Dishcl1]:HAS[~TechRequired[]]:Final {
  @PART[Dishcl1]:HAS[!MODULE[ModuleRTAntenna]] {
    MODULE[ModuleDataTransmitter] {
    }
  }
}

So the inner pattern only processes if the outer one passes. This would allow a certain illusion of branching and simplify some of the more complex patterns by repeating redundancy. It's not a feature request, just asking if in the rewrite you covered more generic handling and simply didn't document it.

1) It just tell MM to process the modification in a later pass. You can put the :Final anywhere in the file, the non final will be processed first then the :Final

2) If I understand what you want, no I don't think you can do it simpler.

3) The "first" line of each patch can use different symbol to find a specific PART (to keep it simple) : @ and ! are used for node, # and ~ for properties. You always need one of those 4 in the :HAS[ ] part

Once you are inside the curly bracket you can only use @ to go inside an existing node, ! to delete it or nothing to create it. Same for properties

Got it. Excellent. Might want to add something to the effect of answer #3 to your 2nd post/documentation. Might help clarify a few things for people.

[sarbian]

It's an AND condition, you just have to use to condition with a coma :

(space added for clarity)

@PART[Dishcl1]:HAS[~TechRequired[]  ,  !MODULE[ModuleRTAntenna] ]:Final {

    MODULE[ModuleDataTransmitter] {
    }

}

The doc need some work I agree.

[sidfu]

so is it fine to just use this and get rid of the old MM and sarbianext .dll?

[NathanKell]

Yep!

sarbian, I'll be swapping over to this on the next releases of all my stuff that uses it. Thanks so much!

[scottholio]

This is great work Sarbian, I've replaced my old versions of MM and MMExt without a hitch. A question: I am updating an old probe that still has the old "rotPower = 3" and "Kp = 1" etc. I have no problem dropping the new SAS parameters in, but do I need to get rid of these old rotPower and Kp entries? And if so would it be just like this:

@PART[myPart]

{

!rotPower = 3

!linPower = 3

....etc

}

Thanks

[sarbian]

Yes, it's the correct way to do it

[Greys]

Suggestion: A means to swap entire nodes based on the presence of other mods by identifying loaded .dlls

Edit: Format changed to account for multiple dependancies as suggested by Sarbian

PART
{
	MODULE
	{
		name = ModuleManagerSwapperThingy
		WITH
		{
			dependant = FireSpitter.dll
			MODULE
			{
				name = FSwheel
				etc = etc
			}
		}
		WITH
		{
			dependant = Multiwheels6.dll
			MODULE
			{
				name = TTModularWheel
				etc = etc
			}
		}
		WITHOUT
		{
			MODULE
			{
				name = ModuleLandingGear
			}
		}
	}
}

In this example, for each WITH{} node, if the specified dependent plugin is loaded, that WITH{} gets passed up to PART{} and everything followed gets thrown away or ignored. If the specified dependent plugin is not loaded, that WITH{} gets thrown away and the next one is checked until all the WITH{}s are used up, then the WITHOUT{} node gets passed up to PART{}, allowing for multiple support tiers and preferred support based on order, I want FS but if FS isn't there I'd rather have MMW than stock, but if neither are there stock will do.

As they're contained within "the wrong context" the MODULE{} nodes won't operate at all, making them functionally inert so really ModuleManagerSwapperThingy just has to pass the desired set of cfg things up to PART{} so they will work and the other won't.

This will allow parts add-ons to take advantage of the offerings from other plugin add-ons while only being dependent on MM to handle the swapping and make use of the best features available.

It shouldn't matter whether this happens before or after the main MM patching sweep, if before then patch sets could reference the pre-swap position, if after they reference the post-swap position, and by using WITH{}/WITHOUT{} rather than MODULE[1] and MODULE[2], then the system can be used to pass any cfg node, but also just raw keys into PART{}, for example changing the description to announce some feature or explain how to use it.

Edited November 19, 2013 by Greys

[sirklick]

I am sure this has been brought up before but my search-fu is failing. Is there a way to target modules/resources/etc that have a space in their name? I have tried [name here], ["name here"], ['name here'] as well as a few other variations with no success. Is this just not supported?

[xandalis]

I've found a problem with the current release: it breaks anything above 2-fold symmetry for SRB/boosters, causing the staging icons for the "extra" SRBs not to appear in staging until launch (and then not in the correct stage). I narrowed the cause down to this version, by only having a MM dependent mod and this version of the .dll installed. Happens every time, regardless of which dependent mod is used. I can work around this problem by manually adding/copying single SRBs, but of course that gets tedious very quickly when dealing with multiple sep motors or other "after design" additions of SRB type parts to existing symmetry.

[NathanKell]

Oh, is that what's doing it? I got that too but assumed it was from something in RSS since I only noticed it once I made RSS.

[xandalis]

I'm really only making an "educated guess" on it, since I haven't tried RSS yet. Either way, I hope it's easier to find and fix the cause, now.

[Starwaster]

Oh, is that what's doing it? I got that too but assumed it was from something in RSS since I only noticed it once I made RSS.

already posted about this elsewhere but it is not modulemanager. I noticed this bug day 1 that 0.22 came out. I won't go so far as to say right now that it's a stock KSP problem but it's been around ever since 0.22 has been.

[TaranisElsu]

Creating a config file with the following added the module to every part in the game, even if it did not have any resources:

@PART[*]:HAS[ @RESOURCE[*] ]
{
  MODULE
  {
    name = MyModule
  }
}

I am using v1.5, and I redownloaded it just in case. Is my syntax wrong? Or is this not working as intended?

Thanks!

Edited November 19, 2013 by TaranisElsu

[Starwaster]

Creating a config file with the following added the module to every part in the game, even if it did not have any resources:

@PART[*]:HAS[ @RESOURCE[*] ]
{
	MODULE
	{
		name = MyModule
	}
}

I am using v1.5, and I redownloaded it just in case. Is my syntax wrong? Or is this not working as intended?

Thanks!

Syntax looks correct, that should work. Except for the spaces on line #1. Are those just there to make it easy to navigate? If not, if they're in your working copy then get rid of them.

Aside from that, it should only be applying the patch to all parts that have any resource node.

Edit: Can you verify that it's ONLY appearing in PARTS? That is, can you go check to see if it's applying to non-PART nodes as well? (i.e. INTERNALs, etc)

[TaranisElsu]

Syntax looks correct, that should work. Except for the spaces on line #1. Are those just there to make it easy to navigate? If not, if they're in your working copy then get rid of them.

Aside from that, it should only be applying the patch to all parts that have any resource node.

Edit: Can you verify that it's ONLY appearing in PARTS? That is, can you go check to see if it's applying to non-PART nodes as well? (i.e. INTERNALs, etc)

That was it. Removing the spaces fixed it. Thank you!

[sarbian]

I am sure this has been brought up before but my search-fu is failing. Is there a way to target modules/resources/etc that have a space in their name? I have tried [name here], ["name here"], ['name here'] as well as a few other variations with no success. Is this just not supported?

Space in part name are evil.

Replace the space with an "?". It should work

If not replace it with an "*". I know this one work but it may match more than just 1 space

That was it. Removing the spaces fixed it. Thank you!

I need to add more trim() then ...

[Starwaster]

Space in part name are evil.

Replace the space with an "?". It should work

If not replace it with an "*". I know this one work but it may match more than just 1 space

I need to add more trim() then ...

Just a little off the top.

[sarbian]

For those who need it here is a version that reapply patch after each database reload http://www.sarbian.com/sarbian/ModuleManager_1_5_1.dll

Not an official release for now.