Jump to content

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

sarbian

By sarbian
in KSP1 Mod Releases

 Share

Recommended Posts

blowfish

blowfish

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

Question, is there a functional difference between

  

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

and 

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

 

Expand  

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

Link to comment
Share on other sites
Lisias

Lisias

Posted
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

  Reveal hidden contents

— — — POST EDIT — — — 

I was wrong! See post below!

Edited by Lisias
Moved my text to a Spoiler.
Link to comment
Share on other sites
Starwaster

Starwaster

Posted
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
Link to comment
Share on other sites
Lisias

Lisias

Posted
Posted
  On 8/10/2019 at 5:03 AM, 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

Expand  

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!

Link to comment
Share on other sites
Jognt

Jognt

Posted
Posted
  On 8/10/2019 at 5:03 AM, 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

 

Expand  

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

Faith in humanity: lost. 

Link to comment
Share on other sites
Lisias

Lisias

Posted
Posted
  On 8/10/2019 at 1:40 PM, Jognt said:

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

Faith in humanity: lost. 

Expand  

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.

Link to comment
Share on other sites
zer0Kerbal

zer0Kerbal

Posted
Posted (edited)
  On 8/10/2019 at 6:12 PM, Lisias said:

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

Expand  

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

Jognt

Posted
Posted (edited)
  On 8/10/2019 at 6:12 PM, 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.

Expand  

 

  On 8/10/2019 at 6:47 PM, 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*

Expand  

 

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

zer0Kerbal

Posted
Posted
  On 8/10/2019 at 7:50 PM, 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. 

Expand  

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) :)

Link to comment
Share on other sites
Lisias

Lisias

Posted
Posted
  On 8/10/2019 at 7:50 PM, 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. 

Expand  

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.

Link to comment
Share on other sites
Jognt

Jognt

Posted
Posted (edited)
  On 8/10/2019 at 8:08 PM, 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) :)

Expand  

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

zer0Kerbal

Posted
Posted
  On 8/11/2019 at 1:24 AM, 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.

Expand  

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

Link to comment
Share on other sites
zer0Kerbal

zer0Kerbal

Posted
Posted

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

 

Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted
  On 8/11/2019 at 5:34 AM, 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

 

Expand  

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

Link to comment
Share on other sites
jd284

jd284

Posted
Posted

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?

Link to comment
Share on other sites
RobertaME

RobertaME

Posted
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
Link to comment
Share on other sites
Jognt

Jognt

Posted
Posted
  On 8/14/2019 at 1:11 AM, 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!

Expand  

@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)

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

×
 Share
Go to topic listing
×
×
  • Create New...