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

blowfish · May 26, 2019

@Lisias I'm still interested to hear exactly this mod is/was doing with ModuleManager (not just what methods it was calling, but what was it trying to accomplish)

FreeThinker · May 26, 2019

Hello. I'm trying to create a script that adds a partmodule (AtmosphericIntake) based on the fields of an existing stock partmodule (ModuleResourceIntake)

@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir]]]:FOR[WarpPlugin]
{
	%ResourceIntakeArea = #$MODULE[ModuleResourceIntake]/area$
	%ResourceIntakeTransformName = #$MODULE[ModuleResourceIntake]/intakeTransformName$
	%ResourceIntakeUnitScalar = #$MODULE[ModuleResourceIntake]/unitScalar$

	MODULE
	{
		name = AtmosphericIntake
		area = #$../ResourceIntakeArea$
		intakeTransformName = #$../ResourceIntakeTransformName$
		unitScalar = #$../ResourceIntakeUnitScalar$
	}

	RESOURCE
	{
		name = IntakeAtm
		amount = 0
		maxAmount = 1.0 // stub, will be updated by AtmosphericIntake
	}
}

What I'm trying to do is readout the area field in the ModuleResourceIntake module.

How can I fix it?

Edit: it appears the only mistake is that the field unitScalar is usually not present. Is there a way to make it optional or give it a default value when not found?

Edited May 27, 2019 by FreeThinker

Lisias · May 26, 2019

7 hours ago, blowfish said:

@Lisias I'm still interested to hear exactly this mod is/was doing with ModuleManager (not just what methods it was calling, but what was it trying to accomplish)

Oh, that communication line got crossed. Sorry.

There're two things, one that is being done now and another that I would like to do instead:

1) Currently, it's using MMPatchLoader's StartLoad to reload the world so the new welded parts became active without restarting KSP. The way the class is searched is specially interesting, as it overcomes the buggy Mono's runtime support for Reflection (long story made short: if anything goes wrong everywhere while loading a DLL, the runtime's Reflection fails miserably for the whole system until restart - damn, I'm becoming repetitive about it).

Whatever you do to the public classes of MM that could be reused, allowing it to be found with UnityEngine.Object.FindObjectOfType apparently will save a lot of grief (as it appears to be imune to the problem described).

2) What I wanna do instead is, somehow (and this is just a bit more than a brainstorming now), plain inject the new welded part into the GameDatabase without reloading the World. Mangling parts on the prefab is not exactly hard, what's hard is to avoid breaking people on the process, and this is where MM could be a huge differential: a common ground mechanism, with concurrency being correctly dealt, to allow safe GameDatabase mangling.

That item 2 thingy would help too to prevent stunts like this one I made on TweakScale - a lot of Add'ons (including the current SquadExpansion and probably the future new one) uses the Main Menu Scene to carry on some unfinished business on GameDatabase, and with everybody running concurrently, a awful amount of feet stomping would be avoided.

— — — POST - EDIT — — --

3) There're a third suggestion that could be lost in the stream, I will avoid repeating it by linking it here.

Edited May 26, 2019 by Lisias
post edit

Gordon Dry · May 28, 2019

@blowfish @sarbian again I stumbled upon something:

value = #$/MODULE[ModuleEngineConfigs]/CONFIG[*]/maxThrust$

I try to get the value of maxThrust of for example:

	MODULE
	{
		name = ModuleEngineConfigs
		type = ModuleEngines
		configuration = Rutherford
		origMass = 0.05
		modded = false
		CONFIG
		{
			name = Rutherford
			massMult = 1
			minThrust = 15.575
			maxThrust = 22.25

I tried so many variants
value = #$/MODULE[ModuleEngineConfigs]/CONFIG/maxThrust$
value = #$/MODULE[ModuleEngineConfigs]/CONFIG,0/maxThrust$
value = #$/MODULE[ModuleEngineConfigs]/CONFIG[*]/maxThrust$
even nested search weirdness value = #$/MODULE[ModuleEngineConfigs]/CONFIG[#$/MODULE[ModuleEngineConfigs]/configuration$]/maxThrust$

I lost it. What?

Edited May 28, 2019 by Gordon Dry

blowfish · May 28, 2019

3 minutes ago, Gordon Dry said:

value = #$/MODULE[ModuleEngineConfigs]/CONFIG/maxThrust$
value = #$/MODULE[ModuleEngineConfigs]/CONFIG,0/maxThrust$
value = #$/MODULE[ModuleEngineConfigs]/CONFIG[*]/maxThrust$

Those all look like they would work to me. Do you get any errors? Is there any other reason why this value might not be available (e.g. patch order/wrong pass)?

On 5/26/2019 at 9:13 AM, Lisias said:

Oh, that communication line got crossed. Sorry.

There're two things, one that is being done now and another that I would like to do instead:

1) Currently, it's using MMPatchLoader's StartLoad to reload the world so the new welded parts became active without restarting KSP. The way the class is searched is specially interesting, as it overcomes the buggy Mono's runtime support for Reflection (long story made short: if anything goes wrong everywhere while loading a DLL, the runtime's Reflection fails miserably for the whole system until restart - damn, I'm becoming repetitive about it).

Whatever you do to the public classes of MM that could be reused, allowing it to be found with UnityEngine.Object.FindObjectOfType apparently will save a lot of grief (as it appears to be imune to the problem described).

2) What I wanna do instead is, somehow (and this is just a bit more than a brainstorming now), plain inject the new welded part into the GameDatabase without reloading the World. Mangling parts on the prefab is not exactly hard, what's hard is to avoid breaking people on the process, and this is where MM could be a huge differential: a common ground mechanism, with concurrency being correctly dealt, to allow safe GameDatabase mangling.

That item 2 thingy would help too to prevent stunts like this one I made on TweakScale - a lot of Add'ons (including the current SquadExpansion and probably the future new one) uses the Main Menu Scene to carry on some unfinished business on GameDatabase, and with everybody running concurrently, a awful amount of feet stomping would be avoided.

Maybe back up a couple more steps. At a high level, how does this mod do part welding? It sounds like you're creating new configs for the "welded" parts and then compiling them into actual parts?

Gordon Dry · May 28, 2019

8 hours ago, blowfish said:

Those all look like they would work to me. Do you get any errors? Is there any other reason why this value might not be available (e.g. patch order/wrong pass)?

This is what I get

[WRN 2019-05-28 04:43:05.545] Cannot find key CONFIG in MODULE
[ERR 2019-05-28 04:43:05.545] Error - Cannot parse variable search when inserting new key volume = #$/MODULE[ModuleEngineConfigs]/CONFIG[*]/maxThrust$

for the third variant with CONFIG[*] and the log errors look similar for the other variants.

I checked the original config and the RealPlume patches / RO patches and there definetely IS a ModuleEngineConfigs with a subnode CONFIG with a value maxThrust.

This is an example of the full patch:
(RO compatibility for Rocket Sound Enhancement)

@PART[*]:HAS[@EFFECTS:HAS[@Ammonialox],@MODULE[ModuleEngineConfigs]]:FOR[zzRocketSoundEnhancement]:NEEDS[RealPlume,RealismOverhaul]
{
    @EFFECTS
    {
        @Ammonialox
        {
            !AUDIO{}
            RSE_AUDIO
            {
				name = running
                channel = Ship
                clip = RocketSoundEnhancement/Sounds/sound_lqd_light
				rolloffMode = Linear
				maxDistance = 10000
				
				lowpass = 0 1 -130.8109 -130.8109
				lowpass = 0.016 0.256 -5.289068 -5.289068
				lowpass = 0.064 0.128 -1.238469 -1.238469
				lowpass = 0.256 0.064 -0.15625 0
				lowpass = 1 0.064
				
				volume = 0.0 0.0
				volume = #$/MODULE[ModuleEngineConfigs]/CONFIG/maxThrust$
				
				@volume,1 /= 1000
				@volume,1 += 1
				@volume,1 /= 2
				@volume,1 ^= :^:0.1 :

				pitch = 0.0 0.2
				pitch = 1.0 0.5

                loop = true
            }
        }
        @engage
        {
            !AUDIO{}
            AUDIO
            {
                channel = Ship
                clip = sound_vent_medium
				volume = #$/MODULE[ModuleEngineConfigs]/CONFIG/maxThrust$
				
				@volume /= 1000
				@volume += 1
				@volume /= 2
				
                pitch = 2.0
                loop = false
            }
        }
        @disengage
        {
            !AUDIO{}
            AUDIO
            {
                channel = Ship
                clip = sound_vent_soft
				volume = #$/MODULE[ModuleEngineConfigs]/CONFIG/maxThrust$
				
				@volume /= 1000
				@volume += 1
				@volume /= 2
				
                pitch = 2.0
                loop = false
            }
        }
        @flameout
        {
            !AUDIO{}
            AUDIO
            {
                channel = Ship
                clip = sound_explosion_low
				
				volume = #$/MODULE[ModuleEngineConfigs]/CONFIG/maxThrust$
				@volume /= 1000
				@volume += 1
				@volume /= 2
				
                pitch = 2.0
                loop = false
            }
        }
    }
}

This btw is the original patch that is for non-RO - and it works this way:

Spoiler


@PART[*]:HAS[@EFFECTS:HAS[@Ammonialox],@MODULE[@ModuleEngines*]:HAS[#maxThrust[>0]]]:FOR[zzRocketSoundEnhancement]:NEEDS[RealPlume]
{
    @EFFECTS
    {
        @Ammonialox
        {
            !AUDIO{}
            RSE_AUDIO
            {
				name = running
                channel = Ship
                clip = RocketSoundEnhancement/Sounds/sound_lqd_light
				rolloffMode = Linear
				maxDistance = 10000
				
				lowpass = 0 1 -130.8109 -130.8109
				lowpass = 0.016 0.256 -5.289068 -5.289068
				lowpass = 0.064 0.128 -1.238469 -1.238469
				lowpass = 0.256 0.064 -0.15625 0
				lowpass = 1 0.064
				
				volume = 0.0 0.0
				volume = #$/MODULE[ModuleEngines*]/maxThrust$
				
				@volume,1 /= 1000
				@volume,1 += 1
				@volume,1 /= 2
				@volume,1 ^= :^:0.1 :

				pitch = 0.0 0.2
				pitch = 1.0 0.5

                loop = true
            }
        }
        @engage
        {
            !AUDIO{}
            AUDIO
            {
                channel = Ship
                clip = sound_vent_medium
				volume = #$/MODULE[ModuleEngines*]/maxThrust$
				
				@volume /= 1000
				@volume += 1
				@volume /= 2
				
                pitch = 2.0
                loop = false
            }
        }
        @disengage
        {
            !AUDIO{}
            AUDIO
            {
                channel = Ship
                clip = sound_vent_soft
				volume = #$/MODULE[ModuleEngines*]/maxThrust$
				
				@volume /= 1000
				@volume += 1
				@volume /= 2
				
                pitch = 2.0
                loop = false
            }
        }
        @flameout
        {
            !AUDIO{}
            AUDIO
            {
                channel = Ship
                clip = sound_explosion_low
				
				volume = #$/MODULE[ModuleEngines*]/maxThrust$
				@volume /= 1000
				@volume += 1
				@volume /= 2
				
                pitch = 2.0
                loop = false
            }
        }
    }
}

Gordon Dry · May 28, 2019

btw what is the difference between
https://ksp.sarbian.com/jenkins/job/ModuleManager/149/
and
https://ksp.sarbian.com/jenkins/job/ModuleManager-RO/8/

because I don't see any link to follow to see commits etc. to check for myself.

Gordon Dry · May 28, 2019

@blowfish

This is the actual variant of the code which does not throw MM errors but also does not do anything:

@PART[*]:HAS[@EFFECTS:HAS[@Kerolox-Upper],@MODULE[@ModuleEngines*]:HAS[#maxThrust[>0]]]:NEEDS[RealPlume]:FOR[ZZROCKETSOUNDENHANCEMENT]
{
    @EFFECTS
    {
        @Kerolox-Upper
        {
			!AUDIO{}
            RSE_AUDIO
            {
				name = running
                channel = Ship
                clip = RocketSoundEnhancement/Sounds/sound_lqd_medium
				rolloffMode = Linear
				maxDistance = 10000
			
				lowpass = 0 1 -130.8109 -130.8109
				lowpass = 0.016 0.256 -5.289068 -5.289068
				lowpass = 0.064 0.128 -1.238469 -1.238469
				lowpass = 0.256 0.064 -0.15625 0
				lowpass = 1 0.064
				
				volume = 0.0 0.0
				volume = #$/MODULE[ModuleEngines*]/maxThrust$
				
				@volume,1 /= 1000
				@volume,1 += 1
				@volume,1 /= 2
				@volume,1 ^= :^:0.1 :

				pitch = 0.0 0.5
				pitch = 1.0 1.0

                loop = true
            }
		}
		
		@engage
		{
            !AUDIO{}
			AUDIO
            {
                channel = Ship
                clip = sound_vent_medium
				volume = #$/MODULE[ModuleEngines*]/maxThrust$
				@volume /= 1000
				@volume += 1
				@volume /= 2
				
                pitch = 1.0
                loop = false
            }
		}
		
		@disengage
		{
            !AUDIO{}
            AUDIO
            {
                channel = Ship
                clip = sound_vent_soft
				volume = #$/MODULE[ModuleEngines*]/maxThrust$
				@volume /= 1000
				@volume += 1
				@volume /= 2
				
                pitch = 1.0
                loop = false
            }
		}
        @flameout
        {
            !AUDIO{}
            AUDIO
            {
                channel = Ship
                clip = sound_explosion_low
				volume = #$/MODULE[ModuleEngines*]/maxThrust$
				@volume /= 1000
				@volume += 1
				@volume /= 2
				
                pitch = 2.0
                loop = false
            }
        }
	}
}

@PART[*]:HAS[@EFFECTS:HAS[@Kerolox-Upper],@MODULE[@ModuleEngines*]:HAS[~maxThrust[>0]],@MODULE[ModuleEngineConfigs]:HAS[~type[ModuleRCS],#origMass[>0],@CONFIG:HAS[#maxThrust[>0]]]]:NEEDS[RealPlume,RealismOverhaul]:LAST[ZZROCKETSOUNDENHANCEMENT]
{
    @EFFECTS
    {
        @Kerolox-Upper
        {
			!AUDIO{}
            RSE_AUDIO
            {
				name = running
                channel = Ship
                clip = RocketSoundEnhancement/Sounds/sound_lqd_medium
				rolloffMode = Linear
				maxDistance = 10000
			
				lowpass = 0 1 -130.8109 -130.8109
				lowpass = 0.016 0.256 -5.289068 -5.289068
				lowpass = 0.064 0.128 -1.238469 -1.238469
				lowpass = 0.256 0.064 -0.15625 0
				lowpass = 1 0.064
				
				volume = 0.0 0.0
				volume = #$/MODULE[ModuleEngineConfigs]/CONFIG/maxThrust$
				
				@volume,1 /= 1000
				@volume,1 += 1
				@volume,1 /= 2
				@volume,1 ^= :^:0.1 :

				pitch = 0.0 0.5
				pitch = 1.0 1.0

                loop = true
            }
		}
		
		@engage
		{
            !AUDIO{}
			AUDIO
            {
                channel = Ship
                clip = sound_vent_medium
				volume = #$/MODULE[ModuleEngineConfigs]/CONFIG/maxThrust$
				@volume /= 1000
				@volume += 1
				@volume /= 2
				
                pitch = 1.0
                loop = false
            }
		}
		
		@disengage
		{
            !AUDIO{}
            AUDIO
            {
                channel = Ship
                clip = sound_vent_soft
				volume = #$/MODULE[ModuleEngineConfigs]/CONFIG/maxThrust$
				@volume /= 1000
				@volume += 1
				@volume /= 2
				
                pitch = 1.0
                loop = false
            }
		}
        @flameout
        {
            !AUDIO{}
            AUDIO
            {
                channel = Ship
                clip = sound_explosion_low
				volume = #$/MODULE[ModuleEngineConfigs]/CONFIG/maxThrust$
				@volume /= 1000
				@volume += 1
				@volume /= 2
				
                pitch = 2.0
                loop = false
            }
        }
	}
}

There is no single instance in the ModuleManager.ConfigCache where AUDIO has been replaced by RSE_AUDIO - that alone shows me that the patch does nothing at all.

All the checks are necessary to avoid failures because of a handful of part packs.

Edited May 28, 2019 by Gordon Dry

kcs123 · May 28, 2019

46 minutes ago, Gordon Dry said:

!AUDIO{}

AUDIO{

// ....

}

I'm new when comes to MM syntax, but above does not look legit to me.
I suppose that firts "!AUDIO{}" command try to earse whole AUDIO module and after that, to add new one.

Does MM can handle such thing properly ?

linuxgurugamer · May 28, 2019

1 minute ago, kcs123 said:

I'm new when comes to MM syntax, but above does not look legit to me.
I suppose that firts "!AUDIO{}" command try to earse whole AUDIO module and after that, to add new one.

Does MM can handle such thing properly ?

Yes, lots of mods do that. The syntax is correct

Lisias · May 29, 2019

On 5/27/2019 at 11:55 PM, blowfish said:

Maybe back up a couple more steps. At a high level, how does this mod do part welding? It sounds like you're creating new configs for the "welded" parts and then compiling them into actual parts?

Yes. Essentially, a 'welded" part is a new synthetic part, living in a new CFG file. How the part is built is somewhat out of scope to this problem, but essentially we "join" the meshes and textures, recalculate mass, CoM, CoL, etc, and create a new part that ideally woud behave as the parts "welded" behaved when they were separated.

Edited May 30, 2019 by Lisias
A bit less worse grammars

Laie · May 30, 2019

On 5/28/2019 at 8:59 PM, kcs123 said:

I suppose that firts "!AUDIO{}" command try to earse whole AUDIO module and after that, to add new one.

Yes, that works fine. Also best practice. Ripping out the old module, then inserting your new one often is easier and less error-prone than trying to modify it.

I've got a question of my own: what's the smart approach to applying a patch to each and every part from one particular mod?

DStaal · May 30, 2019

7 minutes ago, Laie said:

I've got a question of my own: what's the smart approach to applying a patch to each and every part from one particular mod?

Depends on the mod. Some have a systematic naming scheme which makes it easy - a simple glob and you're done.

zer0Kerbal · May 31, 2019

Working on a patch for BreakingGround

I want to add one InventorySlots per seat in each command pod, here is what I have - corrections and improvements are solicited and appreciated:

Spoiler


Serenity@PART[*]:HAS[#CrewCapacity[>0],!MODULE[ModuleInventoryPart]:NEEDS[SquadExpansion/Serenity]:FINAL
{
	MODULE
	{
		name = ModuleInventoryPart	
		InventorySlots = 1
		@InventorySlots *= #$../CrewCapacity$
	}
}

// zer0Kerbal

thank you in advance!

gameplay balance: this is what each kerbal already has inherently in their backpack, so is just reflecting this in their seat.

and two more I have been working on for kOS - setting diskspace based upon mass for crewed, and based upon SASServiceLevel for unmanned. Again, suggestions and corrections appreciated:

Spoiler


@PART[*]:HAS[#CrewCapacity[>0],!MODULE[kOSProcessor]:NEEDS[kOS]:FINAL
{
	MODULE
	{
		name = kOSProcessor
		bootfile = /boot/boot.ks
		diskSpace = 20
		@diskSpace *= #$../mass$
		ECPerBytePerSecond = 0
		ECPerInstruction = 0.000004
	}

	%MODULE[KOSNameTag]
	{
		%nameTag = command
	}
}

// for probes set to multiply by sas level
@PART[*]:HAS[@MODULE[ModuleCommand]:HAS[#minimumCrew[0]],@MODULE[ModuleSAS],!MODULE[kOSProcessor]]:NEEDS[kOS]:FINAL
{
	MODULE
	{
		name = kOSProcessor
		bootfile = /boot/boot.ks
		diskSpace = 20000
		@diskSpace *= #$../ModuleSAS/SASServiceLevel$
		@diskSpace += 10000	//account for SASServiceLevel of 0
		ECPerBytePerSecond = 0
		ECPerInstruction = 0.000004
	}

	%MODULE[KOSNameTag]
	{
		%nameTag = probe
	}
}

// zer0Kerbal

Edited May 31, 2019 by zer0Kerbal

kcs123 · May 31, 2019

13 hours ago, zer0Kerbal said:

@PART[*]:HAS[#CrewCapacity[>0],!MODULE[ModuleInventoryPart]:NEEDS[BreakingGround]:FINAL

How MM recognize name "BreakingGround" as name of DLC/mod/addition ? Is it hadcoded somewhere ?
I found that DLC is installed into "..\Gamedata\SquadExpansion\Serenity\" folder. No any dll plugin with "BreakingGround" in name either.

In another word, is it legit to put "BreakingGround" in MM filter and be certain that something was not messed up ?

zer0Kerbal · May 31, 2019

11 minutes ago, kcs123 said:

How MM recognize name "BreakingGround" as name of DLC/mod/addition ? Is it hadcoded somewhere ?
I found that DLC is installed into "..\Gamedata\SquadExpansion\Serenity\" folder. No any dll plugin with "BreakingGround" in name either.

In another word, is it legit to put "BreakingGround" in MM filter and be certain that something was not messed up ?

good catch - that was a placeholder while I was spitcoding and forgot to change it. thank you for noticing - it should be :NEEDS[Serenity]. will fix in above.

zer0Kerbal · May 31, 2019

just tested - patch InventorySlots based upon CrewCapacity works, except the :NEEDS[] - Serenity doesn't work. Suggestions?

blowfish · May 31, 2019

26 minutes ago, zer0Kerbal said:

just tested - patch InventorySlots based upon CrewCapacity works, except the :NEEDS[] - Serenity doesn't work. Suggestions?

NEEDS[SquadExpansion/Serenity]

Nothing is adding just Serenity to the mod list

zer0Kerbal · May 31, 2019

3 minutes ago, blowfish said:

NEEDS[SquadExpansion/Serenity]

Nothing is adding just Serenity to the mod list

thank you.

fixed in original patch above.

was wondering how to do that.

was going to try REAVERS or Firefly....

Edited May 31, 2019 by zer0Kerbal

blowfish · June 2, 2019

On 5/29/2019 at 5:56 AM, Lisias said:

Yes. Essentially, a 'welded" part is a new synthetic part, living in a new CFG file. How the part is built is somewhat out of scope to this problem, but essentially we "join" the meshes and textures, recalculate mass, CoM, CoL, etc, and create a new part that ideally woud behave as the parts "welded" were when separated.

Okay, that makes more sense. Does building the new "welded" part config involve MM patching, or are you putting it in the game database in its final state?

zer0Kerbal · June 2, 2019

1 hour ago, blowfish said:

Okay, that makes more sense. Does building the new "welded" part config involve MM patching, or are you putting it in the game database in its final state?

after a part is welded - it is standalone (except for the models/textures it requires). Example of a weldedpart:

Spoiler


PART
{
	name = weldedpart
	module = Part
	author = UbioZurWeldingLtd
	rescaleFactor = 1
	PhysicsSignificance = -1
	node_stack_topsspx-adjusting-base-125-10 = 0, 0.57, 0, 0, 1, 0, 1
	node_stack_bottomsspx-adjusting-base-125-10 = 0, 0.45, 0, 0, -1, 0, 0
	node_attach = 0, 0, 0, 0, 0, 0, 0
	CrewCapacity = 0
	TechRequired = advLanding
	entryCost = 9000
	cost = 3000
	category = Ground
	subcategory = 0
	title = My welded part
	manufacturer = UbioZur Welding Ltd
	description = Warranty void during re-entry.
	attachRules = 1,0,1,1,0,0,0
	mass = 0.1875
	dragModelType = default
	maximum_drag = 0.100000001
	minimum_drag = 0.100000001
	angularDrag = 1
	crashTolerance = 35
	breakingForce = 50
	breakingTorque = 50
	maxTemp = 1000
	fuelCrossFeed = True
	explosionPotential = 0.5
	thermalMassModifier = 1
	heatConductivity = 0.12
	emissiveConstant = 0.40000000000000002
	radiatorHeadroom = 0.25
	bulkheadProfiles = size1, size0
	MODEL
	{
		model = StationPartsExpansionRedux/Parts/Ground/adjusting-base/sspx-adjusting-base-125-1
		position = 0, 0, 0
	}
	MODULE
	{
		name = ModuleAdjustableLeg
		LegDisplayName = Leg C
		BaseTransformName = LegBaseTransform003
		FootTransformName = LegFootTransform003
		LegID = LegC
		ExtenderTransformName = Leg003
		LegExtension = 0
		ExtenderMin = 0
		ExtenderMax = 2.49
		ExtensionRate = 3
		PhysicsStaticFriction = 2.7
		PhysicsDynamicFriction = 2.7
	}
	MODULE
	{
		name = ModuleLevelingBase
		Automated = false
		LevelingTransformName = LevelingTransform
		LinkedExtensionMax = 0.83
	}
	MODULE
	{
		name = ModuleColorChanger
		shaderProperty = _EmissiveColor
		animRate = 0.8
		animState = false
		useRate = true
		toggleInEditor = true
		toggleInFlight = true
		toggleInFlight = true
		unfocusedRange = 5
		toggleName = Toggle Lights
		eventOnName = Lights On
		eventOffName = Lights Off
		toggleAction = True
		defaultActionGroup = Light
		redCurve
		{
			key = 0 0 0 3
			key = 1 1 0 0
		}
		greenCurve
		{
			key = 0 0 0 1
			key = 1 1 1 0
		}
		blueCurve
		{
			key = 0 0 0 0
			key = 1 0.7 1.5 0
		}
		alphaCurve
		{
			key = 0 1
		}
	}
}

zer0Kerbal · June 3, 2019

a little assistance kindly:

want to make sure all crewed pods have MonoPropellent: so the patch adds 5 to any pod without, then adds 5 units per crew capacity to all pods with MP.

so a pod without: 5/5

pod with: MaxAmount+(5*CrewCapacity)

Would appreciate some error checking and suggestions. Thank you.

Spoiler


@PART[*]:HAS[#CrewCapacity[>0]] {
	
	// if no MP, add 5 units
	RESOURCE:HAS[!RESOURCE[MonoPropellant]] {
		name = MonoPropellant
		amount = 5
		maxAmount = 5
	}
	
	// add 5 units per crew capacity to existing
	RESOURCE:HAS[RESOURCE[MonoPropellant]] {
		// name = MonoPropellant
		@amount = #$../CrewCapacity$
		@amount *= 5
		@amount += #$maxAmount$
		@maxAmount = #$amount$
	}
}

// zer0Kerbal

blowfish · June 3, 2019

1 hour ago, zer0Kerbal said:
a little assistance kindly:

want to make sure all crewed pods have MonoPropellent: so the patch adds 5 to any pod without, then adds 5 units per crew capacity to all pods with MP.

so a pod without: 5/5

pod with: MaxAmount+(5*CrewCapacity)

Would appreciate some error checking and suggestions. Thank you.
Hide contents
@PART[*]:HAS[#CrewCapacity[>0]] {
	
	// if no MP, add 5 units
	RESOURCE:HAS[!RESOURCE[MonoPropellant]] {
		name = MonoPropellant
		amount = 5
		maxAmount = 5
	}
	
	// add 5 units per crew capacity to existing
	RESOURCE:HAS[RESOURCE[MonoPropellant]] {
		// name = MonoPropellant
		@amount = #$../CrewCapacity$
		@amount *= 5
		@amount += #$maxAmount$
		@maxAmount = #$amount$
	}
}

// zer0Kerbal

Well you've got the arithmetic part basically right, just the RESOURCE:HAS[!RESOURCE[MonoPropellant]] bits are incorrect. HAS is used to check the node you're currently patching, so HAS[RESOURCE[MonoPropellant]] would only be valid at the top level. It also looks like you're trying to edit the resource in the second part but not using an operator to actually edit the node? Try this

Spoiler


@PART:HAS[#CrewCapacity[>0]]
{
    %RESOURCE[MonoPropellant] // Edit or create if it doesn't already exist
    {
        &maxAmount = 5 // Set value if it doesn't exist already
        %amount = #$../CrewCapacity$ // Set the value whether or not it exists
        @amount *= 5
        @amount += #$maxAmount$ 
        @maxAmount = #$amount$
    }
}

I added a few comments to try and explain what's going on there, of course they don't have to be part of the final patch.

zer0Kerbal · June 3, 2019

2 hours ago, blowfish said:
Well you've got the arithmetic part basically right, just the RESOURCE:HAS[!RESOURCE[MonoPropellant]] bits are incorrect. HAS is used to check the node you're currently patching, so HAS[RESOURCE[MonoPropellant]] would only be valid at the top level. It also looks like you're trying to edit the resource in the second part but not using an operator to actually edit the node? Try this
Hide contents
@PART:HAS[#CrewCapacity[>0]]
{
    %RESOURCE[MonoPropellant] // Edit or create if it doesn't already exist
    {
        &maxAmount = 5 // Set value if it doesn't exist already
        %amount = #$../CrewCapacity$ // Set the value whether or not it exists
        @amount *= 5
        @amount += #$maxAmount$ 
        @maxAmount = #$amount$
    }
}
I added a few comments to try and explain what's going on there, of course they don't have to be part of the final patch.

thank you.

I understand now and appreciate the assistance both for its timeliness and usefulness.

Tonka Crash · June 3, 2019

This is just a heads up. In the breaking ground release Squad has done something I didn't think was valid. I've now seen two places where Squad patches add new nodes for existing parts instead of appending to existing nodes. It apparently doesn't create problems in the stock game, but can cause issues with mod patches.

For example: kerbalEVA is the part definition for the male Kerbal in the default suit. It's originally defined in GameData\Squad\Parts\Prebuilt\kerbalEVA.cfg. There's a different files for each suit and gender combination, but all have the pattern kerbalEVA*. Serenity adds the new pick up rocks science experiment to each Kerbal in GameData\SquadExpansion\Serentiy\Parts\Prebuilt\kerbalEVA.cfg. The gotcha is that instead of patching the existing kerbalEVA PART node with @PART, the files create a new PART (no '@') with the same name with just the science experiment in it.

You can see the multiple PART nodes in the ModuleManager.ConfigCache. I guess the partloader merges all the nodes with the same part name together eventually. Mods (like KAS) that add modules to kerbalEVA* need to be careful to catch the correct node definition otherwise it's modules can be duplicated on a part node with unintended consequences. This is one of the things breaking KAS on 1.7.1 launch, it's patches need to be more specific to prevent duplicate KAS modules on each Kerbal.

The second case was less of a problem. The same thing happens with GameData\SquadExpansion\Serenity\Experience\Traits.cfg. A new EXPERIENCE_TRAIT node is created to add skills for Engineers and Scientists related to the deployed ground experiments. This caused patches for mods that expand the list of traits like Extraplanetary Launchpads and MKS to run on multiple nodes duplicating their changes. At least in this case you only get a warning that the trait already exists in the database for each of the duplicates.

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation