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

[zer0Kerbal]

1 hour ago, Lisias said:

That would not apply the patch, also, for anything matching the pattern [AKI<any_char>GolfClub]?

I got a nasty savegame corruption once due an Add'On doing something similar, and ending up patching a lot of unrelated parts.

There's really a need for using a space on the name? Why not "_" or "-" ?

been there. wildcards are powerful and need to be respected and carefully used - sparingly.

1 hour ago, cakepie said:

Because that's not a part that they have "ownership" of, it is in another mod that they have no control over.

The part in question is from SEP, which has been officially discontinued, so there is no chance of getting it renamed at source.

If you'd read the post, you'd see that the goal is in fact trying to use MM rename the original part (with space in name) so that the new version won't have a space in the name.

 

Correct.

[Geonovast]

Is there a way to have a patch applied only if another mod is NOT present?

Say, I have a patch I want to include in a mod.  Another mod already does exactly what I want, so I only want to apply mine if the other mod is not installed.

[Tonka Crash]

2 minutes ago, Geonovast said:

Is there a way to have a patch applied only if another mod is NOT present?

If think it's just :HAS[!Modname] 

@Geonovast Sorry :NEEDS[!Modname]

Edited May 14, 2019 by Tonka Crash

[Geonovast]

Thanks!  That did it.

[edemlama]

Module manager is giving me 1 warning, where do I check what the warning is?

[blowfish]

16 minutes ago, edemlama said:

Module manager is giving me 1 warning, where do I check what the warning is?

It's in the log (both KSP's main log and ModuleManager's logs in <ksp_root>/Logs/ModuleManager)

[edemlama]

7 minutes ago, blowfish said:

It's in the log (both KSP's main log and ModuleManager's logs in <ksp_root>/Logs/ModuleManager)

Thanks!!! it's a problem with a patch for MK2 Expansion and Tweakscale I guess I'll head over to that thread and see what's up 

[WRN 2019-05-15 16:55:30.084] 1 warning related to GameData/Mk2Expansion/Patches/M2X_Tweakscale.cfg

Edited May 15, 2019 by edemlama

[blowfish]

12 minutes ago, edemlama said:

Thanks!!! it's a problem with a patch for MK2 Expansion and Tweakscale I guess I'll head over to that thread and see what's up 

[WRN 2019-05-15 16:55:30.084] 1 warning related to GameData/Mk2Expansion/Patches/M2X_Tweakscale.cfg

There should be a more detailed warning somewhere up in the log ... it's a bit hard to find unfortunately but the line will start with [WRN

Looks like the issue is with the Mk2 Expansion's Tweakscale patches specifically

[edemlama]

22 minutes ago, blowfish said:

There should be a more detailed warning somewhere up in the log ... it's a bit hard to find unfortunately but the line will start with [WRN

Looks like the issue is with the Mk2 Expansion's Tweakscale patches specifically

this is all I could find searching for [WRN 

[WRN 2019-05-15 16:54:57.684] more than one pass specifier detected, ignoring all but the first: Mk2Expansion/Patches/M2X_Tweakscale/@PART[M2X_RootChine*]:NEEDS[TweakScale]:FINAL:FINAL
[WRN 2019-05-15 16:55:30.084] 1 warning related to GameData/Mk2Expansion/Patches/M2X_Tweakscale.cfg
 

[4x4cheesecake]

5 hours ago, edemlama said:

this is all I could find searching for [WRN 

[WRN 2019-05-15 16:54:57.684] more than one pass specifier detected, ignoring all but the first: Mk2Expansion/Patches/M2X_Tweakscale/@PART[M2X_RootChine*]:NEEDS[TweakScale]:FINAL:FINAL
[WRN 2019-05-15 16:55:30.084] 1 warning related to GameData/Mk2Expansion/Patches/M2X_Tweakscale.cfg
 

Well, now you know the file:

GameData/Mk2Expansion/Patches/M2X_Tweakscale.cfg

the issue

more than one pass specifier detected

and the line which contains the issue:

@PART[M2X_RootChine*]:NEEDS[TweakScale]:FINAL:FINAL

 

"pass specifier" are NEEDS, HAS, FIRST, BEFORE, FOR, AFTER and FINAL. Apparently, the patch uses two ":FINAL" directives while just one can be applied. Remove one of the ":FINAL" directives and the warning should disappear

Edited May 15, 2019 by 4x4cheesecake

[123nick]

when, during loading, Module manager states it finds a warning, where do i find the warning? 

[Brigadier]

6 minutes ago, 123nick said:

when, during loading, Module manager states it finds a warning, where do i find the warning? 

In the KSP log file.  The warning can be difficult to find though.

Edited May 17, 2019 by Brigadier
Clarification

[zer0Kerbal]

13 minutes ago, Brigadier said:

In the KSP log file.  The warning can be difficult to find though.

isn't there also a MM log file now?

[GameFolder]\Logs\ModuleManager\?

[Brigadier]

1 hour ago, zer0Kerbal said:

isn't there also a MM log file now?

[GameFolder]\Logs\ModuleManager\?

Yes, there is and you can find warnings there by opening the MMPatch.log file and searching for "WRN".

Edited May 17, 2019 by Brigadier

[TranceaddicT]

19 hours ago, zer0Kerbal said:

isn't there also a MM log file now?

[GameFolder]\Logs\ModuleManager\?

And if you use launch KSP with the command line option '-mm-dump' you'll get a complete dump of every part in its final state.

[Tonka Crash]

Is there a comprehensive list of command line arguments and their effects for ModuleManager? I see several mentioned in the OP, but usually no description of what they do.

[TranceaddicT]

2 hours ago, Tonka Crash said:

Is there a comprehensive list of command line arguments and their effects for ModuleManager? I see several mentioned in the OP, but usually no description of what they do.

For KSP from Squad there's this:  https://wiki.kerbalspaceprogram.com/wiki/Startup_parameters

 

The '-mm-dump' is a startup parameter particular to MM provided by @sarbian for help with debugging MM config files.

[kcs123]

I want to add kOS CPU module only to remote controled probes. And I want to probe with higher SAS level (ability to hold prograde, maneuver, etc.) have also better disk capacity. I tried something like this:

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS]]:HAS[#SASServiceLevel[1]]:HAS[#minimumCrew[0]]:NEEDS[kOS]:Final
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 20000
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS]]:HAS[#SASServiceLevel[2]]:HAS[#minimumCrew[0]]:NEEDS[kOS]:Final
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 100000
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS]]:HAS[#SASServiceLevel[3]]:HAS[#minimumCrew[0]]:NEEDS[kOS]:Final
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 300000
	}
}

 

However, it does not properly exclude cockpits from B9 mod, only from stock parts. I have also tried with "...:HAS[~minimumCrew]". Still does not exclude them properly. Also for some reason above commands adds kOS CPU 3 times instead of just only once. Have no idea what I'm doing wrong.

[Dunbaratu]

55 minutes ago, kcs123 said:

I want to add kOS CPU module only to remote controled probes. And I want to probe with higher SAS level (ability to hold prograde, maneuver, etc.) have also better disk capacity. I tried something like this:

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS]]:HAS[#SASServiceLevel[1]]:HAS[#minimumCrew[0]]:NEEDS[kOS]:Final
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 20000
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS]]:HAS[#SASServiceLevel[2]]:HAS[#minimumCrew[0]]:NEEDS[kOS]:Final
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 100000
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS]]:HAS[#SASServiceLevel[3]]:HAS[#minimumCrew[0]]:NEEDS[kOS]:Final
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 300000
	}
}

 

However, it does not properly exclude cockpits from B9 mod, only from stock parts. I have also tried with "...:HAS[~minimumCrew]". Still does not exclude them properly. Also for some reason above commands adds kOS CPU 3 times instead of just only once. Have no idea what I'm doing wrong.

I don't know Module Manager that well, but presumably it has  "not has" rule - so maybe you can say "not has module "kOSProcessor" in the conditional check - thus it only ever adds kOSProcessor if there's not already one there.  That might fix the 3 copies problem.

[blowfish]

5 hours ago, kcs123 said:

I want to add kOS CPU module only to remote controled probes. And I want to probe with higher SAS level (ability to hold prograde, maneuver, etc.) have also better disk capacity. I tried something like this:

You have multiple top-level HAS blocks.  Only the first will be used.  And check your braces

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS]:HAS[#SASServiceLevel[3],#minimumCrew[0]]]:NEEDS[kOS]

E: might be easier to see this way:

@PART[*]:HAS[
  @MODULE[ModuleCommand],
  @MODULE[ModuleSAS]:HAS[
    #SASServiceLevel[3],
    #minimumCrew[0]
  ]
]

 

Edited May 21, 2019 by blowfish

[kcs123]

18 hours ago, blowfish said:

You have multiple top-level HAS blocks.  Only the first will be used.  And check your braces

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS]:HAS[#SASServiceLevel[3],#minimumCrew[0]]]:NEEDS[kOS]

E: might be easier to see this way:

@PART[*]:HAS[
  @MODULE[ModuleCommand],
  @MODULE[ModuleSAS]:HAS[
    #SASServiceLevel[3],
    #minimumCrew[0]
  ]
]

 

Thanks a lot for this info, it explain why my first try didn't worked. I was put additioanal "HAS" outside first one because I was thinking that MM work like that (obviously wrong). Didn't know that MM only accept first "HAS" and any additional info have to be inside main HAS brackets.

To clarify, if I want to access and check extra variables that were inside {} brackets within part MODULE block in original config file, then I have to write like this:

Quote

@MODULE[ModuleSAS]:HAS[#SASServiceLevel[3]

In other words additional ":HAS[some_key] behave similar like object accessing object properties in other languages, am I right ?
If that is true, than I should need this:

@PART[*]:HAS[
  @MODULE[ModuleCommand],
  @MODULE[ModuleCommand]:HAS[#minimumCrew[0]]|@MODULE[ModuleCommand]:HAS[~minimumCrew],
  @MODULE[ModuleSAS]:HAS[#SASServiceLevel[3]]
]

Because minimumCrew was inside MODULE with name "ModuleCommand" and not within MODULE "ModuleSAS".

In other words, I want to filer all modules with name "ModuleCommand" and extra filer out only those that have "minimumCrew=0" or that does not have "minimumCrew" key at all.

As addition to filter, I need only parts that also have MODULE "ModuleSAS" and with exact key in it "SASServiceLevel=3".

Have yet to try that while waiting for confirmation. Thanks a lot again for explanation.

 

[blowfish]

@kcs123 looks right except that | doesn't work in a HAS block (no easy workaround unfortunately)

[kcs123]

12 hours ago, blowfish said:

@kcs123 looks right except that | doesn't work in a HAS block (no easy workaround unfortunately)

Yep, I got errors from MM with "|" in commands, it worked with just "#minimumCrew[0]" in conditions. I didn't have time to check out all of crewed command pods, was worked properly from all moded cockpits or not. Have yet to try additional commands for other SAS levels and have another question, does "!" in front of @MODULE works properly as NOT condition ?

I have yet to try everything again and test, but previously, when I wanted to exclude if kOSProcessor module exist from patch command, it was excluded from all parts. Meaning kOS was not applied to any of wanted parts.

I have something like this in mind:

@PART[*]:HAS[@MODULE[ModuleCommand],
			@MODULE[ModuleCommand]:HAS[#minimumCrew[0]],
            @MODULE[ModuleSAS]:HAS[#SASServiceLevel[3]],
            !MODULE[kOSProcessor]
]:NEEDS[kOS]:Final
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 300000
	}
}

Found that everything need to be in one line, MM complains about it otherwise, but I wrote it like this for better readability.

 

Edited May 22, 2019 by kcs123
replaced "!@" with only "!" in front of kOS module as suggested by blowfish

[blowfish]

2 hours ago, kcs123 said:

Found that everything need to be in one line, MM complains about it otherwise, but I wrote it like this for better readability.

It needs to be one line yes.  I only expanded it that way so that we could see the individual parts more clearly.  And this is a limitation of KSP's config parser, not MM specifically

2 hours ago, kcs123 said:

Yep, I got errors from MM with "|" in commands, it worked with just "#minimumCrew[0]" in conditions. I didn't have time to check out all of crewed command pods, was worked properly from all moded cockpits or not.

I actually just thought of something.  I think if you have ~minimumCrew[>0] it will match if there is no minimumCrew or if the value is <= 0 (I assume we don't really care about negative values here

2 hours ago, kcs123 said:

Have yet to try additional commands for other SAS levels and have another question, does "!" in front of @MODULE works properly as NOT condition ?

You want !MODULE - in a has block @ means "has module", ! means "does not have module", # means "has value, ~ means "does not have value"

[kcs123]

10 minutes ago, blowfish said:

I actually just thought of something.  I think if you have ~minimumCrew[>0] it will match if there is no minimumCrew or if the value is <= 0 (I assume we don't really care about negative values here

You want !MODULE - in a has block @ means "has module", ! means "does not have module", # means "has value, ~ means "does not have value"

Thanks again for clarification, I was not certain while I was looking at other examples should I always need @ before module or not. Regardless of that mistake, I have checked in game and seems to work properly, at least with B9, KAX, USI/MKS parts and stock parts. Have yet to investigate if I need some addition for some other mod that might not fit the above rules.