sarbian

[1.8.x] Module Manager 4.1.2 (November 15th 2019) - Right To Ludicrous Speed

Recommended Posts

Posted (edited)
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.

I had read the post, and what you explained is not there. I don't know SEP neither KIS intrinsics, but I know very well the breakage that patching partnames using wildcards can do, since my intervention.

Thanks for your attempt of correcting what appears to be a mistake, however. Gave me the chance to reforce my message. And to file a enhance request perhaps? Since spaces are being used on patches (besides being not exactly a best practice), wouldn't be better to create a meta-char to match exactly a space char on part names and prevent the risk of the wildcards as a kludge to overcome this?

Edited by Lisias
yeah. tyops.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Tonka Crash

Share this post


Link to post
Share on other sites

Thanks!  That did it.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
Posted (edited)
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 by edemlama

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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
 

Share this post


Link to post
Share on other sites
Posted (edited)
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 by 4x4cheesecake

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Brigadier
Clarification

Share this post


Link to post
Share on other sites
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\?

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Brigadier

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by blowfish

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Posted (edited)
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 by kcs123
replaced "!@" with only "!" in front of kOS module as suggested by blowfish

Share this post


Link to post
Share on other sites
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"

Share this post


Link to post
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.