sarbian

[1.8.x] Module Manager 4.1.0 (October 16th 2019) - Right To Ludicrous Speed

Recommended Posts

19 hours ago, Jesusthebird said:

im prolly a bit early to the party.
4.0.3 change notes? Just noticed it in ckan, didnt see it mentioned in OP nor last few paged of thread.

6 hours ago, Lisias said:

Follows a brute-force change log

This is what I got from the github (inverted order than jenkins).

The commit log isn't really meant to be human readable.  But I put together a list of the meaningful changes:

  • Logging:
    • Fix context not showing up for exceptions in logs
    • Remove datestamps from log messages (only put time), instead write date at top of logs
    • Have timestamps on logs reflect when the log message was created rather than when it was written to the log
  • Fix files with a space before the extension breaking the cache
  • Fix tabs and newlines (\t and \n) getting stripped out of values

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

Question, is there a functional difference between

 

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

and

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

 

Share this post


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

Share this post


Link to post
Share on other sites
Posted (edited)

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!! :P

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 by Lisias
Moved my text to a Spoiler.

Share this post


Link to post
Share on other sites
Posted (edited)

@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 by Starwaster

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
48 minutes ago, sarbian said:

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

Well, thanks to @blowfish, then ;)

 

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

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

 

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

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?

Share this post


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

Share this post


Link to post
Share on other sites
Posted (edited)

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 by RobertaME

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.