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

[DuoDex]

Hi @sarbian and @blowfish, it seems your donate button is broken. And to think I was going to buy you guys tickets to the Caribbean...

[FreeThinker]

Question, is there a functional difference between

 

@PART[part1,part2]
{
 //do something
}

and

@PART[part1|part2]
{
 // do something
}

 

[blowfish]

On 8/8/2019 at 1:41 AM, FreeThinker said:

Question, is there a functional difference between

 

@PART[part1,part2]
{
 //do something
}

and

@PART[part1|part2]
{
 // do something
}

 

They’re equivalent.  However, I’d prefer the 2nd as it’s more common and , means something different in other contexts.

[Lisias]

Hi.

I found this weird issue, and there's a chance that Module Manager could had misbehaved on the thing.

TL;DR: I was wrong!!

Spoiler

Currently, TweakScale patches are dated and in need of being updated (this is old news, and I'm working on it gradually to minimize breakage), so it's my understanding that it's being applied in the "Legacy" phase, i.e., at the step 1 as says the Docs:

Quote

Patches are applied in the following order:

1. Nodes with no operator ('insert') are loaded by the KSP GameDatabase first.
2. Patches for modname values in NEEDS, BEFORE, AFTER that don't exist are removed.
3. All patches with :FIRST are applied.
4. All patches without an ordering directive (:FIRST, :BEFORE, :FOR, :AFTER, :LAST, :FINAL) are applied.
5. For each item in the Unicode-sorted list of modname values:
6. All patches with :BEFORE are applied
7. All patches with :FOR are applied
8. All patches with :AFTER are applied
9. All patches with :FINAL are applied

However, I just got that issue where a patch with :NEEDS[TweakScale] and :FINAL are being applied before TweakScale ones!!

Quote

[LOG 18:52:59.453] Config(PART) Mk3Expansion/Parts/Engines/HeavyProp/part/M3X_Heavyprop
[LOG 18:52:59.456] Config(@PART[M3X_Heavyprop]:NEEDS[TweakScale]) Mk3Expansion/Patches/M3X_Tweakscale/@PART[M3X_Heavyprop]:NEEDS[TweakScale]
[LOG 18:52:59.517] Config(@PART[M3X_Heavyprop]) TweakScale/patches/Mk3X_Tweakscale/@PART[M3X_Heavyprop]
[LOG 17:59:41.402] Applying update Mk2Expansion/Patches/Mk2X_AtmIntake/@PART[*]:HAS[@MODULE[ModuleResourceIntake],@RESOURCE[IntakeAir],!RESOURCE[IntakeAtm]]:NEEDS[!WarpPlugin,!GTI] to Mk3Expansion/Parts/Engines/HeavyProp/part.cfg/PART[M3X_Heavyprop]
[LOG 17:59:42.120] Applying update Mk3Expansion/Patches/M3X_Tweakscale/@PART[M3X_Heavyprop]:NEEDS[TweakScale] to Mk3Expansion/Parts/Engines/HeavyProp/part.cfg/PART[M3X_Heavyprop]
[LOG 17:59:48.310] Applying update TweakScale/patches/Mk3X_Tweakscale/@PART[M3X_Heavyprop] to Mk3Expansion/Parts/Engines/HeavyProp/part.cfg/PART[M3X_Heavyprop]
[LOG 17:59:57.531] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Mk3Expansion/Parts/Engines/HeavyProp/part.cfg/PART[M3X_Heavyprop]

full log: https://drive.google.com/file/d/1eA1cn8ltzNg0Zh917DWBu2hcDQnd6hA3/view?usp=sharing

The M3X patches has :NEEDS[TweakScale]:FINAL on them, while TweakScale ones has no directive at all.

The fix for this problem specifically is just deleting one of the patches, no problem on that.

But it's my understanding that MM should had applied TweakScale's ones first, and then the M3X ones.

Any advise on this?

Thanks.

— — — POST EDIT — — — 

I was wrong! See post below!

Edited August 10, 2019 by Lisias
Moved my text to a Spoiler.

[Starwaster]

@Lisias that does sound odd but, that doesn't look like a case of patches being applied out of order as such.  If the patches that you're focusing on there were marked :FINAL that would show in the log and it doesn't, not anywhere for the designated patch. Where then was it determined that those patches were marked as :FINAL?

Edit: No offense to the player having this problem but I strongly suspect he is using a different version of MiningExpansion than what you think he is. He was probably using 0.99.1 which has no pass specified for those patches. 0.99.2 is the one that specifies :FINAL

 

Edited August 10, 2019 by Starwaster

[Lisias]

4 hours ago, Starwaster said:

@Lisias that does sound odd but, that doesn't look like a case of patches being applied out of order as such.  If the patches that you're focusing on there were marked :FINAL that would show in the log and it doesn't, not anywhere for the designated patch. Where then was it determined that those patches were marked as :FINAL?

Edit: No offense to the player having this problem but I strongly suspect he is using a different version of MiningExpansion than what you think he is. He was probably using 0.99.1 which has no pass specified for those patches. 0.99.2 is the one that specifies :FINAL

I completely missed that. The user was using the previous version of the Add'Ons. I should had fired up a test bed before jumping into conclusions.

Thanks for the tip, and my apologies for the trouble!

[Geschosskopf]

@sarbianThanks for the new update!

[Jognt]

8 hours ago, Starwaster said:

@Lisias that does sound odd but, that doesn't look like a case of patches being applied out of order as such.  If the patches that you're focusing on there were marked :FINAL that would show in the log and it doesn't, not anywhere for the designated patch. Where then was it determined that those patches were marked as :FINAL?

Edit: No offense to the player having this problem but I strongly suspect he is using a different version of MiningExpansion than what you think he is. He was probably using 0.99.1 which has no pass specified for those patches. 0.99.2 is the one that specifies :FINAL

 

Wait, so someone recently decided that using :FINAL in a distribution was still a good idea?

Faith in humanity: lost. 

[sarbian]

14 minutes ago, Geschosskopf said:

@sarbianThanks for the new update!

@blowfish is the one doing the heavy lifting for MM now. I just push a button

[Geschosskopf]

48 minutes ago, sarbian said:

@blowfish is the one doing the heavy lifting for MM now. I just push a button

Well, thanks to @blowfish, then

 

[Lisias]

4 hours ago, Jognt said:

Wait, so someone recently decided that using :FINAL in a distribution was still a good idea?

Faith in humanity: lost. 

To tell you the true, I think that the guy did that due TweakScale patches being outdated. TweakScale should be using :FOR, so the guy could use :AFTER. (But by adding :FOR now on TweakScale, a huge amount of Add'Ons on the wild bork relentlessly (yes, I tried that on test bed) - so I'm paving the way before putting that on mainstream.)

So I'm wondering he did that to be sure his patches prevails over the TweakScale's ones. I never tried using :AFTER on something that doesn't have the :FOR - so I can't tell if what he did was, indeed, the best way out of the mess. But at least, it's working for now.

[zer0Kerbal]

42 minutes ago, Lisias said:

TweakScale should be using :FOR, so the guy could use :AFTER.

Agree - In my opinion - using :FOR[] should be considered best practices. In fact (lots of work for this) the patches should be evolved to using :NEEDS[] as well - *gets to work adding :NEEDS[] to all Tweakscale patches*

Edited August 10, 2019 by zer0Kerbal

[Jognt]

1 hour ago, Lisias said:

To tell you the true, I think that the guy did that due TweakScale patches being outdated. TweakScale should be using :FOR, so the guy could use :AFTER. (But by adding :FOR now on TweakScale, a huge amount of Add'Ons on the wild bork relentlessly (yes, I tried that on test bed) - so I'm paving the way before putting that on mainstream.)

So I'm wondering he did that to be sure his patches prevails over the TweakScale's ones. I never tried using :AFTER on something that doesn't have the :FOR - so I can't tell if what he did was, indeed, the best way out of the mess. But at least, it's working for now.

 

1 hour ago, zer0Kerbal said:

Agree - In my opinion - using :FOR[] should be considered best practices. In fact (lots of work for this) the patches should be evolved to using :NEEDS[] as well - *gets to work adding :NEEDS[] to all Tweakscale patches*

 

FOR[myMod] does two things: first it states ‘myMod is present’, second it states ‘run these patches in my turn’.

AFTER[myMod] does two things too: first a conditional ‘only run me if myMod is present’. Second it states ‘run these right after myMod’s turn’.

I don’t see why one wouldn’t just use AFTER[tweakscale] (or myMod) in all user patches. Because as long as tweakscale/myMod does its thing in its own turn (FOR) every AFTER user-patch will override tweakscale/myMod and not execute if the mod isnt present. 

Any patches running in the legacy pass (no specified turn/pass) won’t work if they depend on changing changes, but that’s ok. After all, patches without a specified pass that target a mod are bound to screw up something at some point so you may as well weed them out .

edit: So DONT use FOR if you’re not the author of the defined mod pass, and replace FOR/NEEDS in user patches with AFTER. 

Edited August 10, 2019 by Jognt

[zer0Kerbal]

16 minutes ago, Jognt said:

edit: So DONT use FOR if you’re not the author of the defined mod pass, and replace FOR/NEEDS in user patches with AFTER. 

agree - but do use :FOR[xxx] - so TweakScale uses :FOR[Tweakscale] and others use something else. better to be specific rather than be vague. vague is Kraken food (see current Tweakscale insanity)

[Lisias]

53 minutes ago, Jognt said:

I don’t see why one wouldn’t just use AFTER[tweakscale] (or myMod) in all user patches. Because as long as tweakscale/myMod does its thing in its own turn (FOR) every AFTER user-patch will override tweakscale/myMod and not execute if the mod isnt present. 

Yep. However, TweakScale is not doing the :FOR yet, and I can't shove it now due the breakage it did with a lot of Add'Ons. Since my guess that that Author choose to use :FINAL on their patches.

[Jognt]

5 hours ago, zer0Kerbal said:

agree - but do use :FOR[xxx] - so TweakScale uses :FOR[Tweakscale] and others use something else. better to be specific rather than be vague. vague is Kraken food (see current Tweakscale insanity)

AFTER is equally specific as FOR.  

I suggest you check your output log or MM log so you can see the order of patching. AFTER[myMod] is literally right after FOR[myMod]. 

Lets say we have myMod and myMod2, here is the order of patching, assuming both are installed:

BEFORE[myMod] -> FOR[myMod] -> AFTER[myMod] -> BEFORE[myMod2] -> FOR[myMod2] -> AFTER[myMod2]

There are only passes for defined mods, so if there is no FOR[lolz], and no folder/dll called ‘lolz’, there are no BEFORE or AFTER passes for ‘lolz’. 

So again: Dont use FOR[myMod] unless you’re the mod author, since doing to will declare myMod as being present. So if you have a user patch with FOR[someMod] then someMod is declared present and patches with BEFORE or AFTER someMod will be run. 

So don’t do it. 

Edit: I may have misunderstood you. If you meant to always declare a pass, then you’re right. The ‘no pass specified’ pass is called legacy for a reason. 

Edited August 11, 2019 by Jognt

[zer0Kerbal]

48 minutes ago, Jognt said:

Edit: I may have misunderstood you. If you meant to always declare a pass, then you’re right. The ‘no pass specified’ pass is called legacy for a reason.

agree - always declare - but reserve :FOR[mod] for the mod. I always declare (at least do now) a :FOR[] so it is firmly placed where I want it - rather than floating in the ubiquitous legacy or :FINAL. On a side note, someday am hoping that MM will provide a timing feature / performance debug - outputs how long each section took, and how long each mod took - help us mad tweakers squeeze performance out.

[zer0Kerbal]

having an issue with MM:

using -mm-dump command line switch, MM creates file structure "_MMCfgOutput" like it should, but no part.cfg's show up and here is the error message (one of many) from KSP.log:

Spoiler

[LOG 00:12:03.990] [ModuleManager] Exporting /NohArksPnP/Parts/Utility/microLeg/NohArksPnP/Parts/Utility/microLeg/microLegVentral.cfg
[LOG 00:12:03.990] [ModuleManager] Exception while trying to write the file C:/Games/NodeTest/KSP_x64_Data/..//_MMCfgOutput//NohArksPnP/Parts/Utility/microLeg/NohArksPnP/Parts/Utility/microLeg/microLegVentral.cfg
System.IO.IsolatedStorage.IsolatedStorageException: Could not find a part of the path "C:\Games\NodeTest\_MMCfgOutput\NohArksPnP\Parts\Utility\microLeg\NohArksPnP\Parts\Utility\microLeg\microLegVentral.cfg".
  at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0
  at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] in <filename unknown>:0
  at System.IO.StreamWriter..ctor (System.String path, Boolean append, System.Text.Encoding encoding, Int32 bufferSize) [0x00000] in <filename unknown>:0
  at System.IO.StreamWriter..ctor (System.String path, Boolean append) [0x00000] in <filename unknown>:0
  at System.IO.File.AppendAllText (System.String path, System.String contents) [0x00000] in <filename unknown>:0
  at ModuleManager.ModuleManager.OutputAllConfigs () [0x00000] in <filename unknown>:0

 

[blowfish]

On 8/10/2019 at 10:34 PM, zer0Kerbal said:

having an issue with MM:

using -mm-dump command line switch, MM creates file structure "_MMCfgOutput" like it should, but no part.cfg's show up and here is the error message (one of many) from KSP.log:

  Reveal hidden contents

[LOG 00:12:03.990] [ModuleManager] Exporting /NohArksPnP/Parts/Utility/microLeg/NohArksPnP/Parts/Utility/microLeg/microLegVentral.cfg
[LOG 00:12:03.990] [ModuleManager] Exception while trying to write the file C:/Games/NodeTest/KSP_x64_Data/..//_MMCfgOutput//NohArksPnP/Parts/Utility/microLeg/NohArksPnP/Parts/Utility/microLeg/microLegVentral.cfg
System.IO.IsolatedStorage.IsolatedStorageException: Could not find a part of the path "C:\Games\NodeTest\_MMCfgOutput\NohArksPnP\Parts\Utility\microLeg\NohArksPnP\Parts\Utility\microLeg\microLegVentral.cfg".
  at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0
  at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] in <filename unknown>:0
  at System.IO.StreamWriter..ctor (System.String path, Boolean append, System.Text.Encoding encoding, Int32 bufferSize) [0x00000] in <filename unknown>:0
  at System.IO.StreamWriter..ctor (System.String path, Boolean append) [0x00000] in <filename unknown>:0
  at System.IO.File.AppendAllText (System.String path, System.String contents) [0x00000] in <filename unknown>:0
  at ModuleManager.ModuleManager.OutputAllConfigs () [0x00000] in <filename unknown>:0

 

Does indeed appear to have been broken recently.  I just wrote a fix, should be released soon.

[zer0Kerbal]

3 hours ago, blowfish said:

Does indeed appear to have been broken recently.  I just wrote a fix, should be released soon.

Thank you. Until then, there is always the log.

[blowfish]

8 hours ago, zer0Kerbal said:

Thank you. Until then, there is always the log.

And ConfigCache, that will include the final state of all configs in the game database.

[jd284]

How do I express a condition "has ModuleA OR ModuleB OR ModuleC"?

I tried various things like

@PART[*]:HAS[@MODULE[ModuleA|ModuleB]]

or

@PART[*]:HAS[@MODULE[ModuleA,ModuleB]]

but it only ever got applied if I have a single module name there. Is such a thing supported or do I have to copy my block many times for all possible combinations of modules?

[blowfish]

2 hours ago, jd284 said:

How do I express a condition "has ModuleA OR ModuleB OR ModuleC"?

Unfortunately the only way to do this currently is with multiple patches.  Would like to add this at some point in the future ... once a bunch of the core code is rewritten.

[RobertaME]

Trying to create a MM patch to change the Tech Tree, but5 I can't wrap my head around how to do something. I want to change one of the two Parent objects for a Node without changing the other. Here's the source from Techtree.cfg in the Squad folder:

	RDNode
	{
		id = stability
		title = #autoLOC_501028 //#autoLOC_501028 = Stability
		description = #autoLOC_501029 //#autoLOC_501029 = Reaching for the stars starts with keeping our spacecraft pointed generally in the right direction.
		cost = 18
		hideEmpty = False
		nodeName = node2_stability
		anyToUnlock = True
		icon = RDicon_stability
		pos = -2170,1201,0
		scale = 0.6
		Parent
		{
			parentID = engineering101
			lineFrom = RIGHT
			lineTo = LEFT
		}
		Parent
		{
			parentID = basicRocketry
			lineFrom = RIGHT
			lineTo = LEFT
		}
	}

So I want to change ONLY the "parentID = basicRocketry" to "parentID = subsonicFlight" without changing "parentID = engineering101". is there a way to change ONLY a specific instance? If so, I haven't figured it out.

Thanks in advance!

Edited August 14, 2019 by RobertaME

[Jognt]

1 hour ago, RobertaME said:

Trying to create a MM patch to change the Tech Tree, but5 I can't wrap my head around how to do something. I want to change one of the two Parent objects for a Node without changing the other. Here's the source from Techtree.cfg in the Squad folder:

	RDNode
	{
		id = stability
		title = #autoLOC_501028 //#autoLOC_501028 = Stability
		description = #autoLOC_501029 //#autoLOC_501029 = Reaching for the stars starts with keeping our spacecraft pointed generally in the right direction.
		cost = 18
		hideEmpty = False
		nodeName = node2_stability
		anyToUnlock = True
		icon = RDicon_stability
		pos = -2170,1201,0
		scale = 0.6
		Parent
		{
			parentID = engineering101
			lineFrom = RIGHT
			lineTo = LEFT
		}
		Parent
		{
			parentID = basicRocketry
			lineFrom = RIGHT
			lineTo = LEFT
		}
	}

So I want to change ONLY the "parentID = basicRocketry" to "parentID = subsonicFlight" without changing "parentID = engineering101". is there a way to change ONLY a specific instance? If so, I haven't figured it out.

Thanks in advance!

@rdnode:has[@parent:has[#parentid[basicrocketry]]]:for[mymod]{

@parent:has[#parentid[basicrocketry] {}

}

something like that? (On mobile, so you’ll Have to properly capitalize/tweak it yourself)