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

Sigma88

Sigma88

Posted
Posted (edited)

@KerbMav there are a certain number of errors / incorrect stuff in those cfgs, let's go through one by one:

5 hours ago, KerbMav said: 

-PART[mk1pod]:AFTER[Squad]:FOR[PartOverhauls] {}

-PART[liquidEngine]:AFTER[Squad]:FOR[PartOverhauls] {}

Removes stock parts - works.

 

when you have multiple tags (:BEFORE :FOR :AFTER) the cfg will be run when the first one triggers.

so ":AFTER[Squad]:FOR[PartOverhauls]" will run only once at ":FOR[PartOverhauls]"

also, this is not needed, configs without any tag will run at the start, which means you can delete those parts by just doing: 

-PART[mk1pod] {}

-PART[liquidEngine] {}

of course, :FOR[PartOverhauls] will also create a new "mod" definition called "PartOverhauls" if that's not already existent. so you need to keep that in mind if you need it.

 

5 hours ago, KerbMav said: 

@PART[mk1podNew]:AFTER[Squad]:FOR[PartOverhauls] { @name = mk1pod }

@PART[liquidEngineT30]:AFTER[Squad]:FOR[PartOverhauls] { @name = liquidEngine }

Renames new part to old name - supposedly. 


@PART[mk1podNew]:AFTER[PartOverhauls] {stuff happens}

Works - but should not, because part should have "name = mk1pod" now?

Note the AFTER, but it still targets the old name.

here I am confused by what you want to do, you put the ":AFTER[Squad]" tag so I suppose you want your cfg to run at that point, but then you say that the following patch, which has only :AFTER[PartOverhauls], should run after but actually it shouldn't. because "PartOverhauls" comes before "Squad" in the alphabet.

but, as discussed earlier, your first patches will run at ":FOR[PartOverhauls]" regardless of the ":AFTER[Squad]" (which is completely pointless there)

so actually in the end you patches end up running in the order you say you want.

 

regarding the name issue, this is a very old issue I noticed a lot of time ago, when you rename a NODE you can't then use the syntax NODE[name] to target it

what you need to do is using the :HAS[] check

 

so something like this: 

@PART:HAS[#name[mk1podNew]]:AFTER[PartOverhauls] {stuff happens}

 

alternatively:

 

there is a chance that you might be forced to use the syntax NODE[name] instead of the NODE:HAS[#name[name]]

if you are forced to do that (for whatever reason) then the solution would be to duplicate the stock part, changing it's name and the delete the original one.

like this: 

+PART[mk1podNew]:FOR[PartOverhauls]
{
	@name = mk1pod
}
-PART[mk1podNew]:FOR[PartOverhauls] {}


+PART[liquidEngineT30]:FOR[PartOverhauls]
{
	@name = liquidEngine
}
-PART[liquidEngineT30]:FOR[PartOverhauls] {}

 

Edited by Sigma88
Link to comment
Share on other sites
KerbMav

KerbMav

Posted
Posted

@Sigma88 Thank you for all these explainations today!

So, multiple conditions for when to execute something do not work, it picks the first one - and calling a part by its name after giving it a new one does not work at all (the way it is done here). I guess that was the whole problem!

 

PartOverhaul is actually just Porkjet's rocket part files and a config file I glued together from posts of @Kerbal101 and @Alshain in another thread. (Would a mod in the sense of ModuleManager require a dll for :AFTER, :NEEDS etc. to work?)

Since I am nowhere near a programmer but daring enough to try stuff, I usually just take what I find and bend it till it works for me as good as I can.

The idea here was for the Squad parts to first load, then delete the originals that are to be replaced and rename the new ones to take their place, so saved crafts and other mods can still use the stock names. After that some changes are made to bring the parts parameters back to stock, meaningful titles are given and part test contracts enabled. 

// we remove those first, but just after Squad parts are loaded

/// should you encounter a mod, which changes properties and fuels of MK1 parts,
/// please add ":BEFORE[xxxx]" just after "[Squad]" below, working all the way down to the end, 
/// with xxx being directory name of the mod.

/// for example:  -PART[mk1pod]:AFTER[Squad] -->  -PART[mk1pod]:AFTER[Squad]:BEFORE[FuelChanger]
/// this will cause replacer do the job before the said mod touches the parts.

-PART[mk1pod]:AFTER[Squad]:FOR[PartOverhauls] {}

-PART[liquidEngine3]:AFTER[Squad]:FOR[PartOverhauls] {}
-PART[liquidEngine]:AFTER[Squad]:FOR[PartOverhauls] {}
-PART[liquidEngine2]:AFTER[Squad]:FOR[PartOverhauls] {}

-PART[fuelTankSmallFlat]:AFTER[Squad]:FOR[PartOverhauls] {}
-PART[fuelTankSmall]:AFTER[Squad]:FOR[PartOverhauls] {}
-PART[fuelTank]:AFTER[Squad]:FOR[PartOverhauls] {}
-PART[fuelTank_long]:AFTER[Squad]:FOR[PartOverhauls] {}


// then we rename newer parts to older part names, effectively replacing them.
// precise names were tested against ksp wiki.

@PART[fuelTank100]:AFTER[Squad]:FOR[PartOverhauls] { @name = fuelTankSmallFlat }
@PART[fuelTank200]:AFTER[Squad]:FOR[PartOverhauls] { @name = fuelTankSmall }
@PART[fuelTank400]:AFTER[Squad]:FOR[PartOverhauls] { @name = fuelTank }
@PART[fuelTank800]:AFTER[Squad]:FOR[PartOverhauls] { @name = fuelTank_long }

@PART[mk1podNew]:AFTER[Squad]:FOR[PartOverhauls] { @name = mk1pod }

@PART[liquidEngineT45]:AFTER[Squad]:FOR[PartOverhauls] { @name = liquidEngine2 }
@PART[liquidEngineT30]:AFTER[Squad]:FOR[PartOverhauls] { @name = liquidEngine }
@PART[liquidEngine909]:AFTER[Squad]:FOR[PartOverhauls] { @name = liquidEngine3 }

@PART[liquidEngine|liquidEngineT30*]:AFTER[PartOverhauls]
{
	@entryCost = 3200
	@cost = 1100
	
	@MODULE[ModuleEngines]
	{ 
		@maxThrust = 240
		-UPGRADES {}

		-atmosphereCurve {}
		atmosphereCurve
		{
			key = 0 310
			key = 1 265
			key = 7 0.001
		}
	}
}

@PART[liquidEngine2|liquidEngineT45*]:AFTER[PartOverhauls]
{
	@MODULE[ModuleEngines]
	{ 
		@maxThrust = 215
		-UPGRADES {}

		-atmosphereCurve {}
		atmosphereCurve
		{
			key = 0 320
			key = 1 250
			key = 6 0.001
		}
	}
}

@PART[liquidEngine3|liquidEngine909*]:AFTER[PartOverhauls]
{
	@entryCost = 1600
	@cost = 390
	
	@MODULE[ModuleEngines]
	{ 
		@maxThrust = 60
		-UPGRADES {}

		-atmosphereCurve {}
		atmosphereCurve
		{
			key = 0 345
			key = 1 85
			key = 3 0.001
		}
	}

//	-RESOURCE[LiquidFuel] {}
//	-RESOURCE[Oxidizer] {}

}


// Remove any engine upgrades

@PART[*]:AFTER[PartOverhauls]
{
	@MODULE[ModuleEngines] { -UPGRADES {} }
}


// Rename part variants

@PART[liquidEngineT15]{
  @title = LV-T15-A "Valiant" Liquid Fuel Engine
}

@PART[liquidEngineT15_Boattail]{
  @title = LV-T15-B "Valiant" Liquid Fuel Engine
}

@PART[liquidEngine]:FINAL{
  @title = LV-T30-A "Reliant" Liquid Fuel Engine
}

@PART[liquidEngineT30_Boattail]{
  @title = LV-T30-B "Reliant" Liquid Fuel Engine
}

@PART[liquidEngine2]{
  @title = LV-T45-A "Swivel" Liquid Fuel Engine
}

@PART[liquidEngineT45_Boat]{
  @title = LV-T45-B "Swivel" Liquid Fuel Engine
}

@PART[liquidEngine303]{
  @title = LV-303-A "Pug" Liquid Fuel Engine
}

@PART[liquidEngine303_Boattail]{
  @title = LV-303-B "Pug" Liquid Fuel Engine
}

@PART[liquidEngine3]{
  @title = LV-909-A "Terrier" Liquid Fuel Engine
}

@PART[liquidEngine909_Boattail]{
  @title = LV-909-B "Terrier" Liquid Fuel Engine
}

// Add testing contracts to overhauled parts

//@PART[liquidEngineT15,liquidEngineT15_Boattail,liquidEngine,liquidEngineT30_Boattail,liquidEngine2,liquidEngineT45_Boat,liquidEngine303,liquidEngine303_Boattail,liquidEngine3,liquidEngine909_Boattail]:HAS[!MODULE[ModuleTestSubject]]

@PART[liquidEngine*]:HAS[!MODULE[ModuleTestSubject]]
{
  MODULE
	{
		name = ModuleTestSubject
		useStaging = True
		useEvent = True
		situationMask = 127
		CONSTRAINT
		{
			type = REPEATABILITY
			value = ALWAYS
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = REPEATABILITY
			value = BODYANDSITUATION
			prestige = Significant
		}
		CONSTRAINT
		{
			type = REPEATABILITY
			value = ONCEPERPART
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = GT
			value = 4000
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = LT
			value = 8000
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = GT
			value = 2000
			prestige = Significant
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = LT
			value = 4000
			prestige = Significant
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = GT
			value = 1000
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = LT
			value = 2000
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = ALTITUDE
			test = GT
			value = 0 // this just registers altitude as something to care about
			situationMask = 8
		}
		CONSTRAINT
		{
			type = ALTITUDE
			test = LT
			value = 300000
			situationMask = 16
			body = _NotSun
		}
		CONSTRAINT
		{
			type = ALTITUDE
			test = LT
			value = 600000
			situationMask = 32
			body = _NotSun
		}
		CONSTRAINT
		{
			type = SPEED
			test = GT
			value = 0
			situationMask = 8
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = SPEED
			test = LT
			value = 600
			situationMask = 8
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = SPEED
			test = GT
			value = 300
			situationMask = 8
			prestige = Significant
		}
		CONSTRAINT
		{
			type = SPEED
			test = LT
			value = 1200
			situationMask = 8
			prestige = Significant
		}
		CONSTRAINT
		{
			type = SPEED
			test = GT
			value = 600
			situationMask = 8
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = SPEED
			test = LT
			value = 2500
			situationMask = 8
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = LT
			value = 200
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = GT
			value = 100
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = LT
			value = 100
			prestige = Significant
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = GT
			value = 50
			prestige = Significant
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = LT
			value = 50
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = GT
			value = 20
			prestige = Exceptional
		}
	}
}

Everything works but the new titles.

For the ModuleTestSubject I am not sure, but I removed the listing of parts with my own line, looking for engines without it.

Link to comment
Share on other sites
Sigma88

Sigma88

Posted
Posted (edited)
8 minutes ago, KerbMav said:

@Sigma88 Thank you for all these explainations today!

So, multiple conditions for when to execute something do not work, it picks the first one - and calling a part by its name after giving it a new one does not work at all (the way it is done here). I guess that was the whole problem!

 

PartOverhaul is actually just Porkjet's rocket part files and a config file I glued together from posts of @Kerbal101 and @Alshain in another thread. (Would a mod in the sense of ModuleManager require a dll for :AFTER, :NEEDS etc. to work?)

Since I am nowhere near a programmer but daring enough to try stuff, I usually just take what I find and bend it till it works for me as good as I can.

The idea here was for the Squad parts to first load, then delete the originals that are to be replaced and rename the new ones to take their place, so saved crafts and other mods can still use the stock names. After that some changes are made to bring the parts parameters back to stock, meaningful titles are given and part test contracts enabled. 


// we remove those first, but just after Squad parts are loaded

/// should you encounter a mod, which changes properties and fuels of MK1 parts,
/// please add ":BEFORE[xxxx]" just after "[Squad]" below, working all the way down to the end, 
/// with xxx being directory name of the mod.

/// for example:  -PART[mk1pod]:AFTER[Squad] -->  -PART[mk1pod]:AFTER[Squad]:BEFORE[FuelChanger]
/// this will cause replacer do the job before the said mod touches the parts.

-PART[mk1pod]:AFTER[Squad]:FOR[PartOverhauls] {}

-PART[liquidEngine3]:AFTER[Squad]:FOR[PartOverhauls] {}
-PART[liquidEngine]:AFTER[Squad]:FOR[PartOverhauls] {}
-PART[liquidEngine2]:AFTER[Squad]:FOR[PartOverhauls] {}

-PART[fuelTankSmallFlat]:AFTER[Squad]:FOR[PartOverhauls] {}
-PART[fuelTankSmall]:AFTER[Squad]:FOR[PartOverhauls] {}
-PART[fuelTank]:AFTER[Squad]:FOR[PartOverhauls] {}
-PART[fuelTank_long]:AFTER[Squad]:FOR[PartOverhauls] {}


// then we rename newer parts to older part names, effectively replacing them.
// precise names were tested against ksp wiki.

@PART[fuelTank100]:AFTER[Squad]:FOR[PartOverhauls] { @name = fuelTankSmallFlat }
@PART[fuelTank200]:AFTER[Squad]:FOR[PartOverhauls] { @name = fuelTankSmall }
@PART[fuelTank400]:AFTER[Squad]:FOR[PartOverhauls] { @name = fuelTank }
@PART[fuelTank800]:AFTER[Squad]:FOR[PartOverhauls] { @name = fuelTank_long }

@PART[mk1podNew]:AFTER[Squad]:FOR[PartOverhauls] { @name = mk1pod }

@PART[liquidEngineT45]:AFTER[Squad]:FOR[PartOverhauls] { @name = liquidEngine2 }
@PART[liquidEngineT30]:AFTER[Squad]:FOR[PartOverhauls] { @name = liquidEngine }
@PART[liquidEngine909]:AFTER[Squad]:FOR[PartOverhauls] { @name = liquidEngine3 }

@PART[liquidEngine|liquidEngineT30*]:AFTER[PartOverhauls]
{
	@entryCost = 3200
	@cost = 1100
	
	@MODULE[ModuleEngines]
	{ 
		@maxThrust = 240
		-UPGRADES {}

		-atmosphereCurve {}
		atmosphereCurve
		{
			key = 0 310
			key = 1 265
			key = 7 0.001
		}
	}
}

@PART[liquidEngine2|liquidEngineT45*]:AFTER[PartOverhauls]
{
	@MODULE[ModuleEngines]
	{ 
		@maxThrust = 215
		-UPGRADES {}

		-atmosphereCurve {}
		atmosphereCurve
		{
			key = 0 320
			key = 1 250
			key = 6 0.001
		}
	}
}

@PART[liquidEngine3|liquidEngine909*]:AFTER[PartOverhauls]
{
	@entryCost = 1600
	@cost = 390
	
	@MODULE[ModuleEngines]
	{ 
		@maxThrust = 60
		-UPGRADES {}

		-atmosphereCurve {}
		atmosphereCurve
		{
			key = 0 345
			key = 1 85
			key = 3 0.001
		}
	}

//	-RESOURCE[LiquidFuel] {}
//	-RESOURCE[Oxidizer] {}

}


// Remove any engine upgrades

@PART[*]:AFTER[PartOverhauls]
{
	@MODULE[ModuleEngines] { -UPGRADES {} }
}


// Rename part variants

@PART[liquidEngineT15]{
  @title = LV-T15-A "Valiant" Liquid Fuel Engine
}

@PART[liquidEngineT15_Boattail]{
  @title = LV-T15-B "Valiant" Liquid Fuel Engine
}

@PART[liquidEngine]:FINAL{
  @title = LV-T30-A "Reliant" Liquid Fuel Engine
}

@PART[liquidEngineT30_Boattail]{
  @title = LV-T30-B "Reliant" Liquid Fuel Engine
}

@PART[liquidEngine2]{
  @title = LV-T45-A "Swivel" Liquid Fuel Engine
}

@PART[liquidEngineT45_Boat]{
  @title = LV-T45-B "Swivel" Liquid Fuel Engine
}

@PART[liquidEngine303]{
  @title = LV-303-A "Pug" Liquid Fuel Engine
}

@PART[liquidEngine303_Boattail]{
  @title = LV-303-B "Pug" Liquid Fuel Engine
}

@PART[liquidEngine3]{
  @title = LV-909-A "Terrier" Liquid Fuel Engine
}

@PART[liquidEngine909_Boattail]{
  @title = LV-909-B "Terrier" Liquid Fuel Engine
}

// Add testing contracts to overhauled parts

//@PART[liquidEngineT15,liquidEngineT15_Boattail,liquidEngine,liquidEngineT30_Boattail,liquidEngine2,liquidEngineT45_Boat,liquidEngine303,liquidEngine303_Boattail,liquidEngine3,liquidEngine909_Boattail]:HAS[!MODULE[ModuleTestSubject]]

@PART[liquidEngine*]:HAS[!MODULE[ModuleTestSubject]]
{
  MODULE
	{
		name = ModuleTestSubject
		useStaging = True
		useEvent = True
		situationMask = 127
		CONSTRAINT
		{
			type = REPEATABILITY
			value = ALWAYS
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = REPEATABILITY
			value = BODYANDSITUATION
			prestige = Significant
		}
		CONSTRAINT
		{
			type = REPEATABILITY
			value = ONCEPERPART
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = GT
			value = 4000
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = LT
			value = 8000
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = GT
			value = 2000
			prestige = Significant
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = LT
			value = 4000
			prestige = Significant
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = GT
			value = 1000
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = LT
			value = 2000
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = ALTITUDE
			test = GT
			value = 0 // this just registers altitude as something to care about
			situationMask = 8
		}
		CONSTRAINT
		{
			type = ALTITUDE
			test = LT
			value = 300000
			situationMask = 16
			body = _NotSun
		}
		CONSTRAINT
		{
			type = ALTITUDE
			test = LT
			value = 600000
			situationMask = 32
			body = _NotSun
		}
		CONSTRAINT
		{
			type = SPEED
			test = GT
			value = 0
			situationMask = 8
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = SPEED
			test = LT
			value = 600
			situationMask = 8
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = SPEED
			test = GT
			value = 300
			situationMask = 8
			prestige = Significant
		}
		CONSTRAINT
		{
			type = SPEED
			test = LT
			value = 1200
			situationMask = 8
			prestige = Significant
		}
		CONSTRAINT
		{
			type = SPEED
			test = GT
			value = 600
			situationMask = 8
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = SPEED
			test = LT
			value = 2500
			situationMask = 8
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = LT
			value = 200
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = GT
			value = 100
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = LT
			value = 100
			prestige = Significant
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = GT
			value = 50
			prestige = Significant
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = LT
			value = 50
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = GT
			value = 20
			prestige = Exceptional
		}
	}
}

Everything works but the new titles.

For the ModuleTestSubject I am not sure, but I removed the listing of parts with my own line, looking for engines without it. 

// we remove those first, but just after Squad parts are loaded

/// should you encounter a mod, which changes properties and fuels of MK1 parts,
/// please add ":BEFORE[xxxx]" just after "[Squad]" below, working all the way down to the end, 
/// with xxx being directory name of the mod.

/// for example:  -PART[mk1pod] -->  -PART[mk1pod]:BEFORE[FuelChanger]
/// this will cause replacer do the job before the said mod touches the parts.

-PART[mk1pod]:FOR[PartOverhauls] {}

-PART[liquidEngine3]:FOR[PartOverhauls] {}
-PART[liquidEngine]:FOR[PartOverhauls] {}
-PART[liquidEngine2]:FOR[PartOverhauls] {}

-PART[fuelTankSmallFlat]:FOR[PartOverhauls] {}
-PART[fuelTankSmall]:FOR[PartOverhauls] {}
-PART[fuelTank]:FOR[PartOverhauls] {}
-PART[fuelTank_long]:FOR[PartOverhauls] {}


// then we create newer parts with older part names.
// precise names were tested against ksp wiki.

+PART[fuelTank100]:FOR[PartOverhauls] { @name = fuelTankSmallFlat }
+PART[fuelTank200]:FOR[PartOverhauls] { @name = fuelTankSmall }
+PART[fuelTank400]:FOR[PartOverhauls] { @name = fuelTank }
+PART[fuelTank800]:FOR[PartOverhauls] { @name = fuelTank_long }
+PART[mk1podNew]:FOR[PartOverhauls] { @name = mk1pod }
+PART[liquidEngineT45]:FOR[PartOverhauls] { @name = liquidEngine2 }
+PART[liquidEngineT30]:FOR[PartOverhauls] { @name = liquidEngine }
+PART[liquidEngine909]:FOR[PartOverhauls] { @name = liquidEngine3 }

// then we delete parts with the new names

-PART[fuelTank100]:FOR[PartOverhauls] {}
-PART[fuelTank200]:FOR[PartOverhauls] {}
-PART[fuelTank400]:FOR[PartOverhauls] {}
-PART[fuelTank800]:FOR[PartOverhauls] {}
-PART[mk1podNew]:FOR[PartOverhauls] {}
-PART[liquidEngineT45]:FOR[PartOverhauls] {}
-PART[liquidEngineT30]:FOR[PartOverhauls] {}
-PART[liquidEngine909]:FOR[PartOverhauls] {}



@PART[liquidEngine]:AFTER[PartOverhauls]
{
	@entryCost = 3200
	@cost = 1100
	
	@MODULE[ModuleEngines]
	{ 
		@maxThrust = 240
		-UPGRADES {}

		-atmosphereCurve {}
		atmosphereCurve
		{
			key = 0 310
			key = 1 265
			key = 7 0.001
		}
	}
}

@PART[liquidEngine2]:AFTER[PartOverhauls]
{
	@MODULE[ModuleEngines]
	{ 
		@maxThrust = 215
		-UPGRADES {}

		-atmosphereCurve {}
		atmosphereCurve
		{
			key = 0 320
			key = 1 250
			key = 6 0.001
		}
	}
}

@PART[liquidEngine3]:AFTER[PartOverhauls]
{
	@entryCost = 1600
	@cost = 390
	
	@MODULE[ModuleEngines]
	{ 
		@maxThrust = 60
		-UPGRADES {}

		-atmosphereCurve {}
		atmosphereCurve
		{
			key = 0 345
			key = 1 85
			key = 3 0.001
		}
	}

//	-RESOURCE[LiquidFuel] {}
//	-RESOURCE[Oxidizer] {}

}


// Remove any engine upgrades

@PART[*]:AFTER[PartOverhauls]
{
	@MODULE[ModuleEngines] { -UPGRADES {} }
}


// Rename part variants

@PART[liquidEngineT15]{
  @title = LV-T15-A "Valiant" Liquid Fuel Engine
}

@PART[liquidEngineT15_Boattail]{
  @title = LV-T15-B "Valiant" Liquid Fuel Engine
}

@PART[liquidEngine]:FINAL{
  @title = LV-T30-A "Reliant" Liquid Fuel Engine
}

@PART[liquidEngineT30_Boattail]{
  @title = LV-T30-B "Reliant" Liquid Fuel Engine
}

@PART[liquidEngine2]{
  @title = LV-T45-A "Swivel" Liquid Fuel Engine
}

@PART[liquidEngineT45_Boat]{
  @title = LV-T45-B "Swivel" Liquid Fuel Engine
}

@PART[liquidEngine303]{
  @title = LV-303-A "Pug" Liquid Fuel Engine
}

@PART[liquidEngine303_Boattail]{
  @title = LV-303-B "Pug" Liquid Fuel Engine
}

@PART[liquidEngine3]{
  @title = LV-909-A "Terrier" Liquid Fuel Engine
}

@PART[liquidEngine909_Boattail]{
  @title = LV-909-B "Terrier" Liquid Fuel Engine
}

// Add testing contracts to overhauled parts

//@PART[liquidEngineT15,liquidEngineT15_Boattail,liquidEngine,liquidEngineT30_Boattail,liquidEngine2,liquidEngineT45_Boat,liquidEngine303,liquidEngine303_Boattail,liquidEngine3,liquidEngine909_Boattail]:HAS[!MODULE[ModuleTestSubject]]

@PART[liquidEngine*]:HAS[!MODULE[ModuleTestSubject]]
{
  MODULE
	{
		name = ModuleTestSubject
		useStaging = True
		useEvent = True
		situationMask = 127
		CONSTRAINT
		{
			type = REPEATABILITY
			value = ALWAYS
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = REPEATABILITY
			value = BODYANDSITUATION
			prestige = Significant
		}
		CONSTRAINT
		{
			type = REPEATABILITY
			value = ONCEPERPART
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = GT
			value = 4000
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = LT
			value = 8000
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = GT
			value = 2000
			prestige = Significant
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = LT
			value = 4000
			prestige = Significant
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = GT
			value = 1000
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = ALTITUDEENV
			test = LT
			value = 2000
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = ALTITUDE
			test = GT
			value = 0 // this just registers altitude as something to care about
			situationMask = 8
		}
		CONSTRAINT
		{
			type = ALTITUDE
			test = LT
			value = 300000
			situationMask = 16
			body = _NotSun
		}
		CONSTRAINT
		{
			type = ALTITUDE
			test = LT
			value = 600000
			situationMask = 32
			body = _NotSun
		}
		CONSTRAINT
		{
			type = SPEED
			test = GT
			value = 0
			situationMask = 8
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = SPEED
			test = LT
			value = 600
			situationMask = 8
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = SPEED
			test = GT
			value = 300
			situationMask = 8
			prestige = Significant
		}
		CONSTRAINT
		{
			type = SPEED
			test = LT
			value = 1200
			situationMask = 8
			prestige = Significant
		}
		CONSTRAINT
		{
			type = SPEED
			test = GT
			value = 600
			situationMask = 8
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = SPEED
			test = LT
			value = 2500
			situationMask = 8
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = LT
			value = 200
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = GT
			value = 100
			prestige = Trivial
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = LT
			value = 100
			prestige = Significant
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = GT
			value = 50
			prestige = Significant
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = LT
			value = 50
			prestige = Exceptional
		}
		CONSTRAINT
		{
			type = SPEEDENV
			test = GT
			value = 20
			prestige = Exceptional
		}
	}
}

this should work.

 

alternatively, why not apply the changes first, and change the names later? that would seem the most efficient option

Edited by Sigma88
Link to comment
Share on other sites
Kerbal101

Kerbal101

Posted
Posted

@KerbMav  The changes by / code of Alshain are neither supported, nor tested by me.
This is my code for stock parts replacer (method 3 in "Porkjet Stock Engine Overhaul"), I have tested it to work.

Spoiler

From here , the config name is usually "pork-replacer.cfg". It is placed directly into "Gamedata". 


// we remove those first, but just after Squad parts are loaded

/// should you encounter a mod, which changes properties and fuels of MK1 parts,
/// please add ":BEFORE[xxxx]" just after "[Squad]" below, working all the way down to the end, 
/// with xxx being directory name of the mod.

/// for example:  -PART[mk1pod]:AFTER[Squad] -->  -PART[mk1pod]:AFTER[Squad]:BEFORE[FuelChanger]
/// this will cause replacer do the job before the said mod touches the parts.

-PART[mk1pod]:AFTER[Squad] {}
-PART[liquidEngine3]:AFTER[Squad] {}
-PART[liquidEngine]:AFTER[Squad] {}
-PART[liquidEngine2]:AFTER[Squad] {}

-PART[fuelTankSmallFlat]:AFTER[Squad] {}
-PART[fuelTankSmall]:AFTER[Squad] {}
-PART[fuelTank]:AFTER[Squad] {}
-PART[fuelTank_long]:AFTER[Squad] {}


// then we rename newer parts to older part names, effectively replacing them.
// precise names were tested against ksp wiki.

@PART[fuelTank100]:AFTER[Squad] { @name = fuelTankSmallFlat }
@PART[fuelTank200]:AFTER[Squad] { @name = fuelTankSmall }
@PART[fuelTank400]:AFTER[Squad] { @name = fuelTank }
@PART[fuelTank800]:AFTER[Squad] { @name = fuelTank_long }

@PART[mk1podNew]:AFTER[Squad] { @name = mk1pod }

@PART[liquidEngineT45]:AFTER[Squad] { @name = liquidEngine2 }
@PART[liquidEngineT30]:AFTER[Squad] { @name = liquidEngine }
@PART[liquidEngine909]:AFTER[Squad] { @name = liquidEngine3 }

 

The Goal of method 3 (replacer) is to:
- remove stock parts
- insert original Porkjet Overhaul parts without changing anything to them
Specifically - it does not try to change any values in "Porkjet Overhaul", nor tries to overwrite stock part values directly.

In this sense, my config works even without adding "BEFORE", as it tries to be executed:
- right after Squad (main "mod")
- before any other mod
- there is no " :FOR[PartOverhauls] " part

I have tested it with "Interstellar Fuel Switch" and it reliably works.
I have received no incompatibility information with any other mods to this time.

Alshain's Goal is different!
Its about replacing the visuals of the parts, but retaining original Stock engine characteristics and deleting the "upgrades" to engines, which were introduced with Porkjet Overhaul.
In this sense, Alshain's method is a visual enhancer, rather than replacer.

And it does have valuable uses  as I see it - for example if one want to compete in challenges that require stock properties/disallow any mods; or if one wants just the new models/visuals, but no other changes from Porkjet Overhaul.
But it is not an "Overhaul" because of this. I have not yet tested how reliably Alshain's code works.

Link to comment
Share on other sites
Kerbal101

Kerbal101

Posted
Posted
3 hours ago, Sigma88 said:

regarding the name issue, this is a very old issue I noticed a lot of time ago, when you rename a NODE you can't then use the syntax NODE[name] to target it

....

if you are forced to do that (for whatever reason) then the solution would be to duplicate the stock part, changing it's name and the delete the original one.
like this: 


+PART[mk1podNew]:FOR[PartOverhauls]
{
	@name = mk1pod
}
-PART[mk1podNew]:FOR[PartOverhauls] {}


+PART[liquidEngineT30]:FOR[PartOverhauls]
{
	@name = liquidEngine
}
-PART[liquidEngineT30]:FOR[PartOverhauls] {}

Sigma88, are you sure that renaming a NODE causes NODE duplication instead ?

Link to comment
Share on other sites
Sigma88

Sigma88

Posted
Posted
1 minute ago, Kerbal101 said:

Sigma88, are you sure that renaming a NODE causes NODE duplication instead ?

no

renaming a node changes the name of the node

but it breaks the functionality of targetting the node using "@NODE[XXXXX]"

 

as I explained there are 2 way around this:

either you target the node using "@NODE:HAS[#name[XXXXX]]"

or you duplicate the node first (changing the name in the process), then you delete the old node so you avoid having duplicates

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
3 minutes ago, Kerbal101 said:

Sigma88, are you sure that renaming a NODE causes NODE duplication instead ?

That's what + does

+PART means clone that part

Renaming it after is mandatory, otherwise you'd just have two parts with the same name and that causes problems

Link to comment
Share on other sites
Kerbal101

Kerbal101

Posted
Posted
3 minutes ago, Sigma88 said:

no

renaming a node changes the name of the node

but it breaks the functionality of targetting the node using "@NODE[XXXXX]"

Hm, I got it.. Strange, my code did exactly this (remove original, rename via "@") and I received no complaints about problems...

@Starwaster thank you!

Link to comment
Share on other sites
Sigma88

Sigma88

Posted
Posted
43 minutes ago, Kerbal101 said:

Hm, I got it.. Strange, my code did exactly this (remove original, rename via "@") and I received no complaints about problems...

@Starwaster thank you!

the bug is not very consistent, sometimes it shows up and sometimes it doesn't

I haven't been able to really understand what's going on, I remember posting about this in the past, but I can't find where right now

Link to comment
Share on other sites
KerbMav

KerbMav

Posted
Posted
1 hour ago, Kerbal101 said:

Hm, I got it.. Strange, my code did exactly this (remove original, rename via "@") and I received no complaints about problems...

I guess problems started when I began meddling in the code and wondering what went wrong.

Oy vey ... Im-so-so-sorry.gif

Link to comment
Share on other sites
linuxgurugamer

linuxgurugamer

Posted
Posted (edited)

I'm trying to write a patch which will take some values in an existing module, and use them when adding a new module: 

@PART[aerocam|aerocam180]
{
	MODULE
	{
		name = cccam
		speed = 0
		cameraForward = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraForward$
		cameraUp = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraUp$
		cameraPosition = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraPosition$
	}
}

Unfortunately, it's returning an error: 


[ModuleManager] Applying node HullCameraVDS/CCTVPatch/@PART[aerocam|aerocam180] to HullCameraVDS/Parts/aerocam/part/aerocam
[ModuleManager] Error - Cannot parse variable search when inserting new key cameraForward = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraForward$
[ModuleManager] Error - Cannot parse variable search when inserting new key cameraUp = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraUp$
[ModuleManager] Error - Cannot parse variable search when inserting new key cameraPosition = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraPosition$

[ModuleManager] Applying node HullCameraVDS/CCTVPatch/@PART[aerocam|aerocam180] to HullCameraVDS/Parts/aerocam/part/aerocam180
[ModuleManager] Error - Cannot parse variable search when inserting new key cameraForward = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraForward$
[ModuleManager] Error - Cannot parse variable search when inserting new key cameraUp = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraUp$
[ModuleManager] Error - Cannot parse variable search when inserting new key cameraPosition = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraPosition$

The ",0" was added because some of the parts have multiple modules, but the same error happens without it.

I know that the module being referenced is there MuMechModuleHullCameraZoom: 

MODULE
{
	name = MuMechModuleHullCameraZoom
	cameraName = Pictozoom 1000
	cameraForward = 0, 1, 0
	cameraUp = 0, 1, 0
	cameraPosition = 0, 0.18, 0.00
	cameraFoVMax = 60
	cameraFoVMin = 0.5
}

 

So what am I doing wrong?

Thanks in advance

Edited by linuxgurugamer
Link to comment
Share on other sites
Sigma88

Sigma88

Posted
Posted
38 minutes ago, linuxgurugamer said:

The ",0" was added because some of the parts have multiple modules, but the same error happens without it.

,0 is what is causing your issue

"MODULE[MuMechModuleHullCameraZoom]" will automatically pick the first, so you don't need to worry about it

Link to comment
Share on other sites
linuxgurugamer

linuxgurugamer

Posted
Posted
7 minutes ago, Sigma88 said:

,0 is what is causing your issue

"MODULE[MuMechModuleHullCameraZoom]" will automatically pick the first, so you don't need to worry about it

No, I need it because some parts have multiple.

I've gotten it working, see below: 

@PART[aerocam|aerocam180|hc_booster|hc_kazzelblad|hc_launchcam|hc_navcam|hc_nightvision|hc_scicam|hc_wideangle|kerbpro|Telescope|Pictozoom_2000]
{
	%CF = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraForward$
	%CU = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraUp$
	%CP = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraPosition$
	MODULE
	{
		name = cccam
		cameraForward = #$../CF$
		cameraUp = #$../CU$
		cameraPosition = #$../CP$
	}
}

@PART[hc_booster]
{
	%CF = #$MODULE[MuMechModuleHullCameraZoom,1]/cameraForward$
	%CU = #$MODULE[MuMechModuleHullCameraZoom,1]/cameraUp$
	%CP = #$MODULE[MuMechModuleHullCameraZoom,1]/cameraPosition$
	MODULE
	{
		name = cccam
		cameraForward = #$../CF$
		cameraUp = #$../CU$
		cameraPosition = #$../CP$
	}
}
// Delete the variables to avoid log spam
@PART[aerocam|aerocam180]:FINAL
{
	!CF = 0
	!CU = 0
	!CP = 0
}

 

Link to comment
Share on other sites
linuxgurugamer

linuxgurugamer

Posted
Posted
53 minutes ago, Sigma88 said:

@linuxgurugamer that's very weird syntax, I had no idea MM could do that

 

out of curiosity, why don't you just copy the whole node since the keys you want have the same name?

Because I'm not copying the whole node, and this is a template for my applying the same thing to other cameras.

Link to comment
Share on other sites
Sigma88

Sigma88

Posted
Posted
1 minute ago, linuxgurugamer said:

Because I'm not copying the whole node, and this is a template for my applying the same thing to other cameras.

derp, now I see what was wrong with your cfg

you forgot to add the ../ 

@PART[aerocam|aerocam180]
{
	MODULE
	{
		name = cccam
		speed = 0
		cameraForward = #$../MODULE[MuMechModuleHullCameraZoom,0]/cameraForward$
		cameraUp = #$../MODULE[MuMechModuleHullCameraZoom,0]/cameraUp$
		cameraPosition = #$../MODULE[MuMechModuleHullCameraZoom,0]/cameraPosition$
	}
}

this should work

Link to comment
Share on other sites
linuxgurugamer

linuxgurugamer

Posted
Posted
23 hours ago, Sigma88 said:

derp, now I see what was wrong with your cfg

you forgot to add the ../ 


@PART[aerocam|aerocam180]
{
	MODULE
	{
		name = cccam
		speed = 0
		cameraForward = #$../MODULE[MuMechModuleHullCameraZoom,0]/cameraForward$
		cameraUp = #$../MODULE[MuMechModuleHullCameraZoom,0]/cameraUp$
		cameraPosition = #$../MODULE[MuMechModuleHullCameraZoom,0]/cameraPosition$
	}
}

this should work

Yup

Link to comment
Share on other sites
linuxgurugamer

linuxgurugamer

Posted
Posted

So, this is mostly working, except for one patch.

The patch is looking for MuMechModuleHullCameraZoom

One of the parts has two of these modules, each with different values.  So, according to the MM wiki, the index is zero based, and will refer to the nth match. But that isn't happening:

  

@PART[aerocam|aerocam180|hc_booster|hc_kazzelblad|hc_launchcam|hc_navcam|hc_nightvision|hc_scicam|hc_wideangle|kerbpro|Telescope|Pictozoom_2000]
{
	%CF = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraForward$
	%CU = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraUp$
	%CP = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraPosition$
	%FOVMAX = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraFoVMax$
	%FOVMIN = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraFoVMin$

	MODULE
	{
		name = cccam
		cameraForward = #$../CF$
		cameraUp = #$../CU$
		cameraPosition = #$../CP$
		cameraFoVMax = #$../FOVMAX$
		cameraFoVMin = #$../FOVMIN$
	}
}

@PART[hc_booster]
{
	%CF1 = #$MODULE[MuMechModuleHullCameraZoom,1]/cameraForward$
	%CU1 = #$MODULE[MuMechModuleHullCameraZoom,1]/cameraUp$
	%CP1 = #$MODULE[MuMechModuleHullCameraZoom,1]/cameraPosition$
	%FOVMAX1 = #$MODULE[MuMechModuleHullCameraZoom,1]/cameraFoVMax$
	%FOVMIN1 = #$MODULE[MuMechModuleHullCameraZoom,1]/cameraFoVMin$

	MODULE
	{
		name = cccam
		cameraForward = #$../CF1$
		cameraUp = #$../CU1$
		cameraPosition = #$../CP1$
		cameraFoVMax = #$../FOVMAX1$
		cameraFoVMin = #$../FOVMIN1$
	}
}

But what's happening  is that it seems to be only matching the first one.  Here is the final MM cache output: 

UrlConfig
{
	name = hc_booster
	type = PART
	parentUrl = HullCameraVDS/Parts/hc_booster/part
	url = HullCameraVDS/Parts/hc_booster/part/hc_booster
	PART
	{
		name = hc_booster
		module = Part
		author = Rubber Ducky
		mesh = model.mu
		scale = 1
		node_attach = -0.03, 0.0, 0.0, -1.0, 0.0, 0.0
		TechRequired = basicScience
		entryCost = 130
		cost = 65
		category = Utility
		subcategory = 0
		title = BoosterCam
		manufacturer = Maniacal Mallard Industries
		description = The BoosterCam packs two cameras in one discrete, streamlined package. Provides no science value, but useful for piloting.
		tags = (cam science hull
		attachRules = 0,1,0,0,0
		PhysicsSignificance = 1
		mass = 0.005
		dragModelType = default
		maximum_drag = 0
		minimum_drag = 0
		angularDrag = 0
		crashTolerance = 8
		impactTolerance = 8
		maxTemp = 1200
		CF = 0, 1, 0
		CU = 1, 0, 0
		CP = 0.05, 0.14, 0.0
		FOVMAX = 90
		FOVMIN = 60
		CF1 = 0, 1, 0
		CU1 = 1, 0, 0
		CP1 = 0.05, 0.14, 0.0
		FOVMAX1 = 90
		FOVMIN1 = 60
		MODULE
		{
			name = MuMechModuleHullCameraZoom
			cameraName = BoosterCamAft
			cameraForward = 0, 1, 0
			cameraUp = 1, 0, 0
			cameraPosition = 0.05, 0.14, 0.0
			cameraFoVMax = 90
			cameraFoVMin = 60
			cameraMode = 7
		}
		RESOURCE
		{
			name = Resolution
			amount = 1
			maxAmount = 15
		}
		MODULE
		{
			name = MuMechModuleHullCameraZoom
			cameraName = BoosterCamForward
			cameraForward = 0, -1, 0
			cameraUp = 1, 0, 0
			cameraPosition = 0.05, -0.15, 0.0
			cameraFoVMax = 90
			cameraFoVMin = 60
			cameraMode = 7
		}
		
		RESOURCE
		{
			name = Resolution
			amount = 1
			maxAmount = 15
		}
		MODULE
		{
			name = cccam
			cameraForward = 0, 1, 0
			cameraUp = 1, 0, 0
			cameraPosition = 0.05, 0.14, 0.0
			cameraFoVMax = 90
			cameraFoVMin = 60
		}
		MODULE
		{
			name = cccam
			cameraForward = 0, 1, 0
			cameraUp = 1, 0, 0
			cameraPosition = 0.05, 0.14, 0.0
			cameraFoVMax = 90
			cameraFoVMin = 60
		}
		MODULE
		{
			name = JSIExternalCameraSelector
			cameraContainer = hc_booster
			rotateCamera = -90,-90,0
			translateCamera = 0.06,0.1,0
			cameraIDPrefix = ExtCam
		}
	}
}

 

is this a bug, or did I get something wrong?

Thanks in advance

Link to comment
Share on other sites
Sigma88

Sigma88

Posted
Posted (edited)
1 hour ago, linuxgurugamer said:

is this a bug, or did I get something wrong?

Thanks in advance

are you sure you can use this syntax? 

MODULE[MuMechModuleHullCameraZoom,1]

I've never seen it used anywhere, does the manual mention it somewhere?

 

EDIT:

yes that's the problem, I told you before that it wasn't the correct syntax and I was right

 

from the handbook: 

@MODULE[Example],1
{
<...>
}
  
  
Looks for all the "Example" MODULES. Filters the second one and edits it. Note that this is a named MODULE, but this doesn't prevent you from filtering them by numbers.

 

the use of that syntax is never shown in the "duplicate node" function, but if it works, I would assume it would follow the same syntax of the "edit node" function

 

so I guess you need to use  

#$MODULE[MuMechModuleHullCameraZoom],1/cameraForward$
Edited by Sigma88
Link to comment
Share on other sites
linuxgurugamer

linuxgurugamer

Posted
Posted
16 minutes ago, Sigma88 said:

are you sure you can use this syntax? 


MODULE[MuMechModuleHullCameraZoom,1]

I've never seen it used anywhere, does the manual mention it somewhere?

 

EDIT:

yes that's the problem, I told you before that it wasn't the correct syntax and I was right

 

from the handbook: 


@MODULE[Example],1
{
<...>
}
  
  
Looks for all the "Example" MODULES. Filters the second one and edits it. Note that this is a named MODULE, but this doesn't prevent you from filtering them by numbers.

 

the use of that syntax is never shown in the "duplicate node" function, but if it works, I would assume it would follow the same syntax of the "edit node" function

 

so I guess you need to use  


#$MODULE[MuMechModuleHullCameraZoom],1/cameraForward$

Ok, thanks

Link to comment
Share on other sites
Sigma88

Sigma88

Posted
Posted
8 minutes ago, Errol said:

What would be the correct syntax for specifiying a mod that is a folder within a folder in game data for :AFTER[mod] or :BEFORE[mod]?

it's not possible, but if it's a situation like my mods, where more mods are in the same folder (in my case named Sigma) then it's very likely the mod author is using a :FOR[] tag somewhere to signal that his mod is installed.

so, to check if the mod is installed you would need to use :NEEDS[] with inside the name used in the :FOR[] from the mod you want to check if is installed.

 

for :AFTER[] and  :BEFORE[] it doesn't matter what folder the mod is in, it matters what tags that mod is using

so before you need to see when that mod applies its patches, and then you can choose what to put in your :BEFORE[] / :AFTER[] tags

keep in mind that, when using the same :BEFORE[] / :AFTER[], the patches are applied following alphabetical order of the folders in gamedata

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