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

TranceaddicT

TranceaddicT

Posted
Posted
  On 12/10/2017 at 9:58 PM, DStaal said:

NO! ':FOR' *creates* the mod, it's not a conditional.  It should *never* be used by other mods who want to call a mod.  It's main use is for things like the USI or WBI suites of mods, where multiple mods are in one folder, as it allows MM to reference those sub-mods that don't have either their own top-level folder or a .dll.

Expand  

That's not my understanding from the wiki.  I thought :FOR is a part of the ordering pass (1st - no directive (aka LEGACY), 2nd - FIRST, 3rd - BEFORE/FOR/AFTER, 4th FINAL) in which MMConfigs are applied.

To my understanding, using the :FOR directive means that a patch is applied IF the mod exists.

This:

+PART[MyPart]

{

name = MyNewPart

}

creates a new part called MyNewPart from MyPart all the time.

Adding the :FOR directive like this:

+PART[MyPart]:FOR[SomeMod]

creates the part MyNewPart from MyPart ONLY if SomeMod is installed because otherwise, the patch will error and no new part is created.

Am I off?

Link to comment
Share on other sites
New Horizons

New Horizons

Posted
Posted (edited)
  On 12/10/2017 at 10:01 PM, blowfish said:

The simplest thing to do is just to upload your log.  There's a lot in there, but myself and others who have experience doing this can find what we need to pretty quickly.  Also worth making sure all your mods are up to date - many have been updated for this in the last few days.

Expand  

Whish I could. Here one cannot upload files. 

 

Maybe this works magically, without makiing all my files readable.

https://www.dropbox.com/s/r0gytw9z7la8o36/KSP.log?dl=0

 

Edited by New Horizons
Link to comment
Share on other sites
AngrybobH

AngrybobH

Posted
Posted
  On 12/7/2017 at 3:07 PM, sarbian said:

"This means that FOOBAR[*] will not select all nodes of type FOOBAR, but all nodes of type FOOBAR which have a defined "name" field. (If you want to select all FOOBAR nodes, use FOOBAR,*.)"

Expand  

I am trying to go through all my installed mods that have errors starting with GPOSpeedpump because it has a bunch of errors.

The quote above leads me to believe that changing a [*] to a ,* would likely fix a line like:

@PART[*]:HAS[@MODULE[InterstellarFuelSwitch],!MODULE[GPOSpeedPump]]:FOR[GPOSpeedFuelPump]:FINAL

if I change it to:

@PART,*:HAS[@MODULE[InterstellarFuelSwitch],!MODULE[GPOSpeedPump]]:FOR[GPOSpeedFuelPump]:FINAL

Am I correct?

Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted
  On 12/10/2017 at 10:32 PM, AngrybobH said:

I am trying to go through all my installed mods that have errors starting with GPOSpeedpump because it has a bunch of errors.

The quote above leads me to believe that changing a [*] to a ,* would likely fix a line like:

@PART[*]:HAS[@MODULE[InterstellarFuelSwitch],!MODULE[GPOSpeedPump]]:FOR[GPOSpeedFuelPump]:FINAL

if I change it to:

@PART,*:HAS[@MODULE[InterstellarFuelSwitch],!MODULE[GPOSpeedPump]]:FOR[GPOSpeedFuelPump]:FINAL

Am I correct?

Expand  

@PART[*] works fine, because each PART node will always have a name value (or KSP will not compile the part).  However, @PART:HAS[...] will work fine, you only need the ,* on subnodes, since by default it will only apply to the first one.  The problem we found here was with EXPERIMENT_DEFINITION, since those don't have a name value.

Link to comment
Share on other sites
AngrybobH

AngrybobH

Posted
Posted
  On 12/10/2017 at 10:35 PM, blowfish said:

@PART[*] works fine, because each PART node will always have a name value (or KSP will not compile the part).  However, @PART:HAS[...] will work fine, you only need the ,* on subnodes, since by default it will only apply to the first one.  The problem we found here was with EXPERIMENT_DEFINITION, since those don't have a name value.

Expand  

Ok. Thank you. I'm trying to do some of my own debugging which includes learning just about everything I need to know about modding this game. Any suggestions on why this file gets an error? 

// Interstellar Fuel Switch support
@PART[*]:HAS[@MODULE[InterstellarFuelSwitch],!MODULE[GPOSpeedPump]]:FOR[GPOSpeedFuelPump]:FINAL
{
	MODULE
	{
		name = GPOSpeedPump
	}
}

// Firespitter fuel switch support
@PART[*]:HAS[@MODULE[FSfuelSwitch],!MODULE[GPOSpeedPump]]:FOR[GPOSpeedFuelPump]:FINAL
{
	MODULE
	{
		name = GPOSpeedPump
	}
}

// B9 fuel switch support
@PART[*]:HAS[@MODULE[ModuleB9PartSwitch],!MODULE[GPOSpeedPump]]:FOR[GPOSpeedFuelPump]:AFTER[zzz_CryoTanks]:FINAL
{
	MODULE
	{
		name = GPOSpeedPump
	}
}
Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted
  On 12/10/2017 at 10:35 PM, New Horizons said:

Did it!

Expand  

Thanks!

I see errors from RealPlume-StockConfigs and SETI.  The RealPlume-Stock errors have been fixed in 1.0.1, so be sure to update.  I've reported the SETI error in the thread but no response from the author yet (and can't make sense of which Github repositories correspond to what so I can't submit a fix myself).

  On 12/10/2017 at 10:41 PM, AngrybobH said:

Ok. Thank you. I'm trying to do some of my own debugging which includes learning just about everything I need to know about modding this game. Any suggestions on why this file gets an error? 

// Interstellar Fuel Switch support
@PART[*]:HAS[@MODULE[InterstellarFuelSwitch],!MODULE[GPOSpeedPump]]:FOR[GPOSpeedFuelPump]:FINAL
{
	MODULE
	{
		name = GPOSpeedPump
	}
}

// Firespitter fuel switch support
@PART[*]:HAS[@MODULE[FSfuelSwitch],!MODULE[GPOSpeedPump]]:FOR[GPOSpeedFuelPump]:FINAL
{
	MODULE
	{
		name = GPOSpeedPump
	}
}

// B9 fuel switch support
@PART[*]:HAS[@MODULE[ModuleB9PartSwitch],!MODULE[GPOSpeedPump]]:FOR[GPOSpeedFuelPump]:AFTER[zzz_CryoTanks]:FINAL
{
	MODULE
	{
		name = GPOSpeedPump
	}
}
Expand  

:FOR[GPOSpeedFuelPump]:FINAL, :FOR[GPOSpeedFuelPump]:FINAL, :AFTER[zzz_CryoTanks]:FINAL are all specifying two passes.  ModuleManager has only ever applied the patch in one pass, so it was previously meaningless (and now an error) to provide more than one.

Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted
  On 12/10/2017 at 10:54 PM, New Horizons said:

With other words: Things as this with two ":" are not allowed anymore?

@PART[jx2LDA]:FOR[Kerbalism]:AFTER[JX2Antenna]

Expand  

Correct, any combination of more than one :FOR, :BEFORE, :AFTER, :FIRST, :FINAL is not allowed.  But again, it wasn't really meaningful even in previous versions of MM, it would always use the first one and ignore any others.

Link to comment
Share on other sites
DStaal

DStaal

Posted
Posted
  On 12/10/2017 at 10:16 PM, TranceaddicT said:

That's not my understanding from the wiki.  I thought :FOR is a part of the ordering pass (1st - no directive (aka LEGACY), 2nd - FIRST, 3rd - BEFORE/FOR/AFTER, 4th FINAL) in which MMConfigs are applied.

To my understanding, using the :FOR directive means that a patch is applied IF the mod exists.

This:

+PART[MyPart]

{

name = MyNewPart

}

creates a new part called MyNewPart from MyPart all the time.

Adding the :FOR directive like this:

+PART[MyPart]:FOR[SomeMod]

creates the part MyNewPart from MyPart ONLY if SomeMod is installed because otherwise, the patch will error and no new part is created.

Am I off?

Expand  

You are off.  Yes, FOR is part of the ordering pass - but that's *because* it creates the mod in question.  So you get patches BEFORE the mod, FOR the mod, and then AFTER the mod.  Both of your statements will (attempt) to create the part MyPart all the time.  (And will likely throw an error if SomeMod is not installed.)

If you want to apply some patch only if SomeMod is installed, you would use ':NEEDS[SomeMod]'.  Getting FOR and NEEDS mixed up is the *most* common error I've seen in MM patches, and the one most likely to cause unrelated or weird issues.  (As it causes issues in *other* mods which are using everything correctly, but only in the presence of your mod and not the mod you're trying to conditionally depend on.)

Link to comment
Share on other sites
DStaal

DStaal

Posted
Posted
  On 12/10/2017 at 10:54 PM, New Horizons said:

With other words: Things as this with two ":" are not allowed anymore? 

@PART[jx2LDA]:FOR[Kerbalism]:AFTER[JX2Antenna]

 

Expand  

Per my discussion with TranceaddicT - Try this instead, I believe this will work, and do what you likely actually intend: 

@PART[jx2LDA]:NEEDS[Kerbalism]:AFTER[JX2Antenna]

 

Link to comment
Share on other sites
TranceaddicT

TranceaddicT

Posted
Posted
  On 12/10/2017 at 10:55 PM, DStaal said:

You are off.  Yes, FOR is part of the ordering pass - but that's *because* it creates the mod in question.  So you get patches BEFORE the mod, FOR the mod, and then AFTER the mod.  Both of your statements will (attempt) to create the part MyPart all the time.  (And will likely throw an error if SomeMod is not installed.)

If you want to apply some patch only if SomeMod is installed, you would use ':NEEDS[SomeMod]'.  Getting FOR and NEEDS mixed up is the *most* common error I've seen in MM patches, and the one most likely to cause unrelated or weird issues.  (As it causes issues in *other* mods which are using everything correctly, but only in the presence of your mod and not the mod you're trying to conditionally depend on.)

Expand  

Thank you.  I've been conflating NEEDS/FOR for a long time.  Wow, that just makes things so much better.

Link to comment
Share on other sites
AngrybobH

AngrybobH

Posted
Posted

So this worked out and got rid of 3 errors and fixed some issues I had with GPO. I changed what I had posted before to: 

@PART[*]:HAS[@MODULE[InterstellarFuelSwitch],!MODULE[GPOSpeedPump]]:NEEDS[GPOSpeedFuelPump]:AFTER[InterstellarFuelSwitch]
{
	MODULE
	{
		name = GPOSpeedPump
	}
}

// Firespitter fuel switch support
@PART[*]:HAS[@MODULE[FSfuelSwitch],!MODULE[GPOSpeedPump]]:NEEDS[GPOSpeedFuelPump]:AFTER[FSfuelSwitch]
{
	MODULE
	{
		name = GPOSpeedPump
	}
}

// B9 fuel switch support
@PART[*]:HAS[@MODULE[ModuleB9PartSwitch],!MODULE[GPOSpeedPump]]:NEEDS[GPOSpeedFuelPump]:AFTER[zzz_CryoTanks]
{
	MODULE
	{
		name = GPOSpeedPump
	}
}

 

It also makes more sense to me. Thanks again to @TranceaddicT , @blowfish, and indirectly @DStaal.

Can you NEEDS twice or more?

Link to comment
Share on other sites
sarbian

sarbian

Posted
  • Author
Posted
  On 12/10/2017 at 4:20 PM, maja said:

Hi sarbian, did you have time to build a custom 2.8.1 or am I looking for something not done yet?

Expand  

Sorry about the delay :) Here is the 2.8 version with included -mm-dump command. 

https://www.dropbox.com/s/g78d7jggeoz0kwv/ModuleManager.2.8.withdump.dll?dl=0

 

Link to comment
Share on other sites
maja

maja

Posted
Posted
  On 12/11/2017 at 6:06 PM, sarbian said:

Sorry about the delay :) Here is the 2.8 version with included -mm-dump command. 

https://www.dropbox.com/s/g78d7jggeoz0kwv/ModuleManager.2.8.withdump.dll?dl=0

 

Expand  

No problem at all and thanks. I have a lot of other things to do too. I searched in the github and jenkins repo and when I didn't found anything I asked :)

Link to comment
Share on other sites
Electrocutor

Electrocutor

Posted
Posted

so... is it designed behavior for any cloned parts to also be affected by future cfg edits to their parent? 

Test.cfg:
+PART[fuelTank]
{
	@name = TestFuelTank
	@title = TestFuelTank
	@mesh = Squad/Parts/FuelTank/fuelTankT400/model
	-mesh = DELETE
	-MODEL {}

	MODEL
	{
		model = Test/fuelTank
	}
}

ModuleManager.ConfigCache:
UrlConfig
{
	name = TestFuelTank
	type = PART
	parentUrl = Squad/Parts/FuelTank/fuelTankT400/fuelTankT400
	PART
	{
		name = TestFuelTank
		...
		MODEL
		{
			model = VenStockRevamp/Squad/Parts/Propulsion/T400Tank
		}
	}
}

 

Link to comment
Share on other sites
Sigma88

Sigma88

Posted
Posted (edited)
  On 12/13/2017 at 3:25 PM, Electrocutor said:

so... is it designed behavior for any cloned parts to also be affected by future cfg edits to their parent?

Expand  

mm patches don't target cfgs, they target nodes.

depending on how the patch is applied it may or may not apply to the cloned part.

first of all the cloning happens at a certain time, so the part is cloned in the state it is at the moment of cloning.

after the cloning, if a patch starts with: 

@PART

it will affect all parts (included the clones)

if it specifies the name for example: 

@PART[fuelTank]

it will affect only the original "fuelTank" part and not the clone (since it has a different 'name' )

if it uses some different method like: 

@PART:HAS[#title[fuelTank]]

it might still fail (like in this case) if your cloning process messed up the particular value the patch is looking for

 

 

bottom line, if you want your cloned part to get all the patches of the original, just clone it at the end using :FINAL (for personal use) or :FOR[zzzzzzYourMod] (if you are releasing it with a mod)

 

on the other hand, if you don't want your part to be affected by any other patch, I don't think there is a way to do that
( @sarbian / @blowfish  please correct me if I'm wrong on this last point)

Edited by Sigma88
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...