Jump to content

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


sarbian

Recommended Posts

7 hours ago, Starwaster said:

As he said, it allows subdirectories. Most parts if the mod's folders are structured sensibly will have the part in its own properly named folder. So target that folder. Obviously that won't work for mods which force their parts to live all in one folder or groups masses of them into one folder.

Normally this (:NEEDS[KAS/Legacy]) would work, except that every update will scrub the directory and am expecting most (like me) to just move the directory somewhere, and probably rename it.

So the answer is either :NEEDS[@PART[]) or as I remembered

:NEEDS[@MODULE[KASModuleWinch,!KASLinkWinch]] (think that is correct syntax)

since KAS changed it's module names for 1.2, then that is a great indicator / method of solving my dilemma elegantly.

And with KIS2.0 coming sooner (maybe) rather than later (Breaking Ground seems to have put pressure on @IgorZ) - can expect that this method should also work then for that as well.


 

Quote

 

"ad hoc, ergo promptus hoc." — Bill

"okay, whatever that means, whack it again with a hammer, a bigger one this time!" — Jeb

 

 

Edited by zer0Kerbal
Link to comment
Share on other sites

4 hours ago, zer0Kerbal said:

expecting most (like me) to just move the directory somewhere, and probably rename it.

Maybe this is an exception, but many mods will break if you move things around or rename them.  Specifically, any parts using MODEL {} will fail to compile.

Link to comment
Share on other sites

Not sure that makes sense... if you are expected to move mod folders around then something is very wrong.

You're not going to like this solution but too bad

On the tug part you want to do this to:

	MODULE
	{
		name = KASLinkWinch
	}

IT WILL WORK

Where by 'work' I mean if the proper version is installed then the you'll have KASLinkWinch installed.

If the proper version isn't installed then KSP will silently complain in the log and it will move on without the module.

It's about as elegant as Alpo and Velveeta for dinner but it will get the job done.

Link to comment
Share on other sites

  • 2 weeks later...

Did stuff change? My old tweaks - months, 1y+ old - stopped working (partially).

Swapping "biome sensitivity" of EVA and Crew Report does not work anymore.

Spoiler

// situation bits:
// SrfLanded = 1,
// SrfSplashed = 2,
// FlyingLow = 4,
// FlyingHigh = 8,
// InSpaceLow = 16,
// InSpaceHigh = 32

@EXPERIMENT_DEFINITION[*]:HAS[#id[crewReport]]
{
        @baseValue = 8
        @scienceCap = 8
        @dataScale = 1
        @situationMask = 63
        @biomeMask = 31
}
 
@EXPERIMENT_DEFINITION[*]:HAS[#id[evaReport]]
{
        @baseValue = 5
        @scienceCap = 5
        @dataScale = 1

        @situationMask = 63
        @biomeMask = 3
}

 

Changing SAS availability of probe cores to "grow" with TechTree progression - does not work completely.

The "Software Update" appears in the TechTree, but does not change even new crafts, not even the text in the VAB.
Silly enough, it works in a Sandbox game, but not career.

Spoiler

@PART[probeCoreSphere]:BEFORE[SASupgrade]
{
	MODULE
	{
	name = ModuleSAS	
	}
}

@PART[*]:HAS[@MODULE[ModuleSAS]]:FOR[SASupgrade]

{

	@MODULE[ModuleSAS]
	{
				
	%SASServiceLevel = 0
	%moduleIsEnabled = false		
	%showUpgradesInModuleInfo = true
		
		UPGRADES
		{

			UPGRADE
			{
				name__ = SASupgradeLvl0
				description__ = SAS Vers. 1.0
				ExclusiveWith__ = SASb
				//IsAdditiveUpgrade__ = false
				moduleIsEnabled = true
				SASServiceLevel = 0
			}
			
			UPGRADE
			{
				name__ = SASupgradeLvl1
				description__ = SAS Vers. 1.1
				ExclusiveWith__ = SASb
				//IsAdditiveUpgrade__ = false
				moduleIsEnabled = true
				SASServiceLevel = 1
			}
			
			UPGRADE
			{
				name__ = SASupgradeLvl2
				description__ = SAS Vers. 1.2
				ExclusiveWith__ = SASb
				//IsAdditiveUpgrade__ = false
				moduleIsEnabled = true
				SASServiceLevel = 2
			}
			
			UPGRADE
			{
				name__ = SASupgradeLvl3
				description__ = SAS Vers. 1.3
				ExclusiveWith__ = SASb
				//IsAdditiveUpgrade__ = false
				moduleIsEnabled = true
				SASServiceLevel = 3
			}
		}
	}
	
}

 

Spoiler

PARTUPGRADE
	{
	name = SASupgradeLvl0
	partIcon = probeCoreSphere
	techRequired = electrics
	entryCost = 1000
	cost = 0
	title = SAS Software 1.0
	description = Installs SAS software Version 1.0
	}

PARTUPGRADE
	{
	name = SASupgradeLvl1
	partIcon = probeCoreSphere
	techRequired = precisionEngineering
	entryCost = 5000
	cost = 0
	title = SAS Software Upgrade 1.1
	description = Updates SAS software to Version 1.1	
	}

PARTUPGRADE
	{
	name = SASupgradeLvl2
	partIcon = probeCoreSphere
	techRequired = unmannedTech
	entryCost = 10000
	cost = 0
	title = SAS Software Upgrade 1.2
	description = Updates SAS software to Version 1.2	
	}

PARTUPGRADE
	{
	name = SASupgradeLvl3
	partIcon = probeCoreSphere
	techRequired = advUnmanned
	entryCost = 15000
	cost = 0
	title = SAS Software Upgrade 1.3
	description = Updates SAS software to Version 1.3	
	}

 

Link to comment
Share on other sites

50 minutes ago, KerbMav said:

Did stuff change? My old tweaks - months, 1y+ old - stopped working (partially).

Swapping "biome sensitivity" of EVA and Crew Report does not work anymore.

  Reveal hidden contents


// situation bits:
// SrfLanded = 1,
// SrfSplashed = 2,
// FlyingLow = 4,
// FlyingHigh = 8,
// InSpaceLow = 16,
// InSpaceHigh = 32

@EXPERIMENT_DEFINITION[*]:HAS[#id[crewReport]]
{
        @baseValue = 8
        @scienceCap = 8
        @dataScale = 1
        @situationMask = 63
        @biomeMask = 31
}
 
@EXPERIMENT_DEFINITION[*]:HAS[#id[evaReport]]
{
        @baseValue = 5
        @scienceCap = 5
        @dataScale = 1

        @situationMask = 63
        @biomeMask = 3
}

 

There was a change, but it happened quite a while ago (maybe more than a year at this point?).  EXPERIMENT_DEFINITION nodes don't have a name value, so @EXPERIMENT_DEFINITION[*] no longer works (you want @EXPERIMENT_DEFINITION:HAS[#id[crewReport]])

Less sure about the 2nd part, I don't think that has anything to do with ModuleManager though.

Edited by blowfish
Link to comment
Share on other sites

5 minutes ago, blowfish said:

There was a change, but it happened quite a while ago (maybe more than a year at this point?).  EXPERIMENT_DEFINITION nodes don't have a name value, so @EXPERIMENT_DEFINITION[*] no longer works (you want @EXPERIMENT_DEFINITION:HAS[#id[crewReport]])

Less sure about the 2nd part, I don't think that has anything to do with ModuleManager though.

Ah, thanks, will try that.

Would it be something similar here?

Spoiler

@PART[*]:HAS[@MODULE[*]:HAS[#experimentID[atmosphereAnalysis]|#experimentID[temperatureScan]|#experimentID[gravityScan]|#experimentID[barometerScan]|#experimentID[seismicScan]|#experimentID[scopeScan]]]
{
    @MODULE[*]:HAS[#experimentID[atmosphereAnalysis]|#experimentID[temperatureScan]|#experimentID[gravityScan]|#experimentID[barometerScan]|#experimentID[seismicScan]|#experimentID[scopeScan]]
    {
        @xmitDataScalar = 1.0
    }
}

 

Link to comment
Share on other sites

I've poked around through the documentation and many configs and have never seen this, so maybe it's just not possible. but in case I just didn't see it and it IS possible...

Is there a way to reference another part's data when changing a part? Let's say, as a random example, I want to set the mass of partA to equal the mass of partB. I don't want to have to re-check partB every KSP update, so I'd like to do something like:

@PART[partA]
{
	@mass = PART[partB].mass
}

Is something like that possible?

Link to comment
Share on other sites

1 hour ago, KerbMav said:

Ah, thanks, will try that.

Would it be something similar here?

  Hide contents

@PART[*]:HAS[@MODULE[*]:HAS[#experimentID[atmosphereAnalysis]|#experimentID[temperatureScan]|#experimentID[gravityScan]|#experimentID[barometerScan]|#experimentID[seismicScan]|#experimentID[scopeScan]]]
{
    @MODULE[*]:HAS[#experimentID[atmosphereAnalysis]|#experimentID[temperatureScan]|#experimentID[gravityScan]|#experimentID[barometerScan]|#experimentID[seismicScan]|#experimentID[scopeScan]]
    {
        @xmitDataScalar = 1.0
    }
}

 

| doesn't work in a HAS block, unfortunately you need a separate patch for each

Link to comment
Share on other sites

8 hours ago, blowfish said:

| doesn't work in a HAS block, unfortunately you need a separate patch for each

Curious ... it must have worked at some point, because I had to dig deep into my backups before I found a version that handled each experiment seperately.

 

And regarding my other problem - Squad updated the Stayputnik, but kept the older version - so the name of the part changed ... :D

So, catch all version in first line:

Spoiler

@PART[probeCoreSphere*]:BEFORE[SASupgrade]

The localization stuff leads to silly entries in the TechTree (AUTOLOC***), but that doesnt bother me as much. ^^

Thanks again!

Link to comment
Share on other sites

20 hours ago, KerbMav said:

Curious ... it must have worked at some point, because I had to dig deep into my backups before I found a version that handled each experiment seperately.

It's pretty bizarre considering commas work in HAS blocks as a logical AND

You're probably right and it probably did work in the past which means its failure to work now is another regression.

Just as it used to be possible to add a field to a node, test for that field in a node and then delete that field from the node in the same patch section as it had been tested for. (now MM gets confused because it no longer knows what order to execute the commands in)

Link to comment
Share on other sites

12 hours ago, Starwaster said:

It's pretty bizarre considering commas work in HAS blocks as a logical ANDYou're probably right and it probably did work in the past which means its failure to work now is another regression.

This never worked to my knowledge.  It was not implemented.  In fact, you can go look at old versions of the code and confirm that.

12 hours ago, Starwaster said:

Just as it used to be possible to add a field to a node, test for that field in a node and then delete that field from the node in the same patch section as it had been tested for. (now MM gets confused because it no longer knows what order to execute the commands in)

Could you be more specific?  Maybe an example?

Link to comment
Share on other sites

I want to prefix the TITLE of fuel tanks with the bulkhead profile, but my script isn't working.

Input:

@PART[*]:HAS[#category[FuelTank]]:FINAL 
{ 
    @title ^= :^:#$bulkheadProfiles$: 
}

Desired result: title =  size0 PB-X150 Xenon Container

Ingame/Config Cache: title = #$bulkheadProfiles$PB-X150 Xenon Container

 

Link to comment
Share on other sites

4 hours ago, blowfish said:

This never worked to my knowledge.  It was not implemented.  In fact, you can go look at old versions of the code and confirm that.

Could you be more specific?  Maybe an example?

I don't need to look at the code to know that it worked for Module Manager 2.0.8. What I can't tell you is when it stopped working. But yes, using | in HAS blocks was a thing once upon a time.

As for the latter, Deadly Reentry looks for a flag 'leaveTemp' in the body of all part configs. More properly that flag belongs in ModuleAeroReentry but we look for it in the part itself to make it easier for other modders to opt out. 

What USED to happen was that in the same patch that we looked for the flag in we would add ModuleAeroReentry with the flag and its associated value (leaveTemp = #$/leaveTemp$) inserted and then the flag would be deleted. That worked up until a few years ago when it stopped after MM updated. I reported it here and was told that there was just no way for Module Manager to know that the flag was being read before its value inserted into the module and I left it at that as it was just easier to leave it in there. (worst that happens is the part compiler complains about an unknown field). But it did used to work.

@PART[*]:HAS[#leaveTemp[*],@MODULE[ModuleAeroReentry]]:FINAL
{
	@MODULE[ModuleAeroReentry]
	{
		%leaveTemp = #$../leaveTemp$
	}
	!leaveTemp
}
@PART[*]:HAS[#leaveTemp[*],!MODULE[ModuleAeroReentry]]:FINAL
{
	MODULE
	{
		name = ModuleAeroReentry
		leaveTemp = #$../leaveTemp$
	}
	!leaveTemp
}

 

3 hours ago, Nightside said:

I want to prefix the TITLE of fuel tanks with the bulkhead profile, but my script isn't working.

Input:


@PART[*]:HAS[#category[FuelTank]]:FINAL 
{ 
    @title ^= :^:#$bulkheadProfiles$: 
}

Desired result: title =  size0 PB-X150 Xenon Container

Ingame/Config Cache: title = #$bulkheadProfiles$PB-X150 Xenon Container

 

Try removing the : at the end of title

@title ^= :^:#$bulkheadProfiles$

Also though, the way you have it there there won't be a space between bulkhead profiles and the rest of the title.

Link to comment
Share on other sites

4 hours ago, Starwaster said:

I don't need to look at the code to know that it worked for Module Manager 2.0.8. What I can't tell you is when it stopped working. But yes, using | in HAS blocks was a thing once upon a time.

2.0.8 is ancient history, like pre-Sarbian ancient history.  I checked the code around then and I don't see it looking for | in HAS blocks, but maybe if you say so?  That was probably before I was even playing KSP.

5 hours ago, Starwaster said:

@PART[*]:HAS[#leaveTemp[*],@MODULE[ModuleAeroReentry]]:FINAL
{
	@MODULE[ModuleAeroReentry]
	{
		%leaveTemp = #$../leaveTemp$
	}
	!leaveTemp
}

 

The problem here is that when KSP parses nodes, it puts all the nodes in one list and all the values in another list.  So ModuleManager has no way of knowing which came first originally.  I'm not sure how this could have worked before, and a few years sounds before my time working on ModuleManager, but if you narrow it down to a version update I might be able to look at the code and see.

Also it would have to be !leaveTemp = DEL (or some other value that doesn't matter), otherwise KSP doesn't parse it as a value

8 hours ago, Nightside said:

@title ^= :^:#$bulkheadProfiles$:

 

Close...

@title ^= :^:#$bulkheadProfiles$:

As starwaster mentioned you probably want a space before the final :

Link to comment
Share on other sites

44 minutes ago, blowfish said:

Also it would have to be !leaveTemp = DEL (or some other value that doesn't matter), otherwise KSP doesn't parse it as a value

That's because that was the older code (which, yes, !leaveTemp actually worked too, once upon a time)

Quote

 I'm not sure how this could have worked before, and a few years sounds before my time working on ModuleManager, but if you narrow it down to a version update I might be able to look at the code and see.

Conditionals are (or were) generic. Anywhere that was doing logic checks the same syntax worked for them all. I have no idea what's happened with the code since then but yes, that worked.

Edited by Starwaster
Link to comment
Share on other sites

56 minutes ago, Starwaster said:

That's because that was the older code (which, yes, !leaveTemp actually worked too, once upon a time)

I wonder if this was actually a change in KSP's ConfigNode parser...

57 minutes ago, Starwaster said:

Conditionals are (or were) generic. Anywhere that was doing logic checks the same syntax worked for them all. I have no idea what's happened with the code since then but yes, that worked.

Still very curious how this would have worked.  ModuleManager wouldn't have had any way to know to process the node before the value, then or now.

Link to comment
Share on other sites

3 minutes ago, Gurki said:

Have you something in the pipe regarding patch that will apply twice when parts are define twice ? kerbalEVA is what I have in mind with Serenity DLC. I didn't see anything related into github issue :(

You don't need special handling for that from Module Manager. Serenity defining a part named KerbalEVA is just so they can add the ROC science module to the standard KerbalEVA suit. Remember that stock doesn't use Module Manager so they just define a part that has the same name and the end result is that the new Serenity science module gets added to the KerbalEVA part whenever it gets spawned. I'm not clear on the specific internal workings but that's basically what happens. They also do the same with KerbalEVAVintage

So, you yourself don't need to target all parts named KerbalEVA or all parts named KerbalEVAFemale. Just target one of each. In fact if you did try to patch all parts named KerbalEVA it might end up in duplication of whatever you're trying to do. Depends really on what you are trying to do. (in fact I think Deadly Reentry might be doing something like that so I better go make sure it isnt...)

In fact just do this:

@PART[*]:HAS[@MODULE[KerbalEVA]]
{
}

 

 

Link to comment
Share on other sites

That was more or less something that I did to remove duplicated module added by Kerbalism on kerbalEVA from my setup.

Obviously KSP merge parts defined multiple time after MM.

I was wondering if doing that merge in MM as some kind of pre-process, applying patches and returning to KSP something that has no duplicated definition is possible.
It will avoid accidental duplicates for any parts, but I'm not sure if it worth the effort of implementing it ...

Edited by Gurki
Link to comment
Share on other sites

On 7/17/2019 at 6:04 PM, Gurki said:

I was wondering if doing that merge in MM as some kind of pre-process, applying patches and returning to KSP something that has no duplicated definition is possible.

That would need more knowledge than MM has (and need to have).

Sometimes such duplication is wanted (as an array of sections), sometimes it's not. We would need to tell MM about it.

I have a similar problem on some Sanity Checks for an Add'On of mine. Sometimes a datum can be zero, some other it can not (or KSP capsizes) - so there's no generic rule that can be applied, you need to specialize for each datum. And this can vary module by module.

So it appears to me that this task need to be performed by the modules themselves.

Edited by Lisias
Bad grammars. =P
Link to comment
Share on other sites

I've recently upgraded to 1.6 from 1.3, and noticed there were some major changes in-between. From what I understand, MM now applies patches "in parallel" as the parts are loaded. So I guess it goes like this:

MM for 1.3.1: Load parts (one run through the GameData folder) -----> apply patches -----> Post-patch callbacks (or whatever it is called; another run through GameData)

MM for 1.6.1: Load parts/apply patches (one run through the GameData folder) -----> Post-patch callbacks (another run)

If I keep a validated cache between KSP startups, will MM do both "loading" runs all the same? I'm asking because, in older versions, reading from the cache significantly decreased load times since it removed one step from the loading process whereas, in the current version, it will be limited by whichever operation concludes last (part loading or patch applying). I'm still assembling a modpack with multiple installs/uninstalls/config changes between play sessions, so I haven't been able to test it yet.

TL;DR: will a valid cache allow for MM to jump straight to post-patch callbacks, therefore only running through my modlist once? Or did I get the workings of MM completely wrong?

Link to comment
Share on other sites

59 minutes ago, Tonas1997 said:

I've recently upgraded to 1.6 from 1.3, and noticed there were some major changes in-between. From what I understand, MM now applies patches "in parallel" as the parts are loaded. So I guess it goes like this:

MM for 1.3.1: Load parts (one run through the GameData folder) -----> apply patches -----> Post-patch callbacks (or whatever it is called; another run through GameData)

MM for 1.6.1: Load parts/apply patches (one run through the GameData folder) -----> Post-patch callbacks (another run)

If I keep a validated cache between KSP startups, will MM do both "loading" runs all the same? I'm asking because, in older versions, reading from the cache significantly decreased load times since it removed one step from the loading process whereas, in the current version, it will be limited by whichever operation concludes last (part loading or patch applying). I'm still assembling a modpack with multiple installs/uninstalls/config changes between play sessions, so I haven't been able to test it yet.

TL;DR: will a valid cache allow for MM to jump straight to post-patch callbacks, therefore only running through my modlist once? Or did I get the workings of MM completely wrong?

Here was the previous sequence of events

KSP loads plugins -> KSP loads textures -> KSP loads models -> ModuleManager applies patches -> ModuleManager runs post patch callbacks -> KSP compiles parts

Here is the new sequence

                  -> KSP loads textures -> KSP loads models ->
KSP loads plugins ->                                        -> ModuleManager runs post patch callbacks -> KSP compiles parts
                  -> ModuleManager applies patches ---------->

There shouldn't be any effect as 99% of mods are concerned.  Also note that applying patches is still done one by one, it's just done in the background while KSP is doing unrelated stuff.  There shouldn't be any effect as far as the cache is concerned (and changing ModuleManager versions invalidates the cache anyway)

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.

×
×
  • Create New...