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

[Tonka Crash]

36 minutes ago, zer0Kerbal said:

am attempting to write a patch that puts SAS into a part, but limits it due to the techtree.

...

this should work - just need help on the :NEEDS statement - how to reference the techtree for a specific tech?

What you are describing is really handled by the Part Upgrades functionality.

[zer0Kerbal]

6 minutes ago, Tonka Crash said:

What you are describing is really handled by the Part Upgrades functionality.

True - and I can write that - but that might be another step later on. Would prefer to use a patch..."

"I usually don't ask if it is possible, rather I hit it with a big enough hammer to make it work.  — Jeb

Edited June 13, 2019 by zer0Kerbal

[Tonka Crash]

@zer0Kerbal MM can't do what you want since it runs before your save loads. Individual part or module values don't get individual unlocks at different tech levels, the entire part unlocks at one tech level. The only Mod that does anything similar is MechJeb and I think it handles its feature unlocks at different tech level in code for the mod. This is where Part Upgrades come into play, allowing parts to change as a function of your game progress.

[zer0Kerbal]

1 minute ago, Tonka Crash said:

@zer0Kerbal MM can't do what you want since it runs before your save loads. Individual part or module values don't get individual unlocks at different tech levels, the entire part unlocks at one tech level. The only Mod that does anything similar is MechJeb and I think it handles its feature unlocks at different tech level in code for the mod. This is where Part Upgrades come into play, allowing parts to change as a function of your game progress.

thank you . that makes sense. doesn't matter the size of the hammer, or how much you try to whack it - if it doesn't exist.

[Tonka Crash]

@zer0Kerbal Try this out  and see if it's doing what you want.

[zer0Kerbal]

3 hours ago, Tonka Crash said:

@zer0Kerbal Try this out  and see if it's doing what you want.

thank you. saved me a spell of time. I have written part upgrades in the past, and have really wanted (low priority) to do a more expansive set.

this will make a great tool to start/continue that toolbox.

Edited June 14, 2019 by zer0Kerbal

[zer0Kerbal]

I'm BACK!

Want to add the new ControlPoint functionality to parts that don't have it, the patch I have so far is below.

Spoiler

@PART:HAS[MODULE[ModuleCommand]]:FOR[_Me]
	@MODULE[ModuleCommand] {
		name = ModuleCommand
		%defaultControlPointDisplayName = Up
		%CONTROLPOINT {
			%name = forward
			%displayName = Forward
			%orientation = 90,0,0
		}
		%CONTROLPOINT {
			%name = reverse
			%displayName = Reverse
			%orientation = 0,0,180
		}
	}
}
// zer0Kerbal

 

a fresh set of eyes would be appreciated!

[4x4cheesecake]

6 hours ago, zer0Kerbal said:

a fresh set of eyes would be appreciated!

*takes glasses* now you get 4 

But I'm on mobile  so don't expect a full patch

First of all, there is a missing '@' in the first HAS block, it needs to be

@PART:HAS[@MODULE[ModuleCommand]]:FOR[_Me]

And this:

@MODULE[ModuleCommand] {
		name = ModuleCommand

doesn't  look right at all. This will address the module with the name 'ModuleCommand' and adds the name 'ModuleCommand' to it so the final config is going to provide two 'name' keys.

I cannot look up the stock configs right now but I guess you want to add 'ControlPoint' nodes to the module 'ModuleCommand'? You should be fine by removing the additional name key then

[nmc]

@zer0Kerbal your patch has some issues, my fresh set of eyes did not like it:

• It is syntactically incorrect because the opening brace after the "@PART" node is missing
• It does not match any part (I think, not sure about this one) because the "@PART" node needs "[*]" (a wildcard name selector)
• As indicated by @4x4cheesecake, it does not any match parts because the "MODULE[ModuleCommand]" filter needs "@" (a node selector)
• As indicated by @4x4cheesecake, it duplicates the "name" key of the "MODULE[ModuleCommand]" node, it should not
• The "%CONTROLPOINT" patches will override one another one because they are missing a name selector, they should be "%CONTROLPOINT[forward]" and "%CONTROLPOINT[reverse]" and the "%name" key becomes useless
• It is applied to all parts with a "MODULE[ModuleCommand]" node, whereas it should probably only be for the ones that do not have any "CONTROLPOINT" node inside, in which case the "%CONTROLPOINT" patches do not need either a name selector or a "%" but do need a "name" key
• It is a custom user patch, so it should probably be applied last and therefore needs a ":FINAL"

 

All in all, it offer you this:

@PART[*]:HAS[@MODULE[ModuleCommand]]:HAS[!CONTROLPOINT[]]:FOR[_Me]:FINAL
{
	@MODULE[ModuleCommand]
	{
		%defaultControlPointDisplayName = Up
		CONTROLPOINT 
		{
			name = forward
			displayName = Forward
			orientation = 90,0,0
		}
		CONTROLPOINT
		{
			name = reverse
			displayName = Reverse
			orientation = 0,0,180
		}
	}
}

 

Some notes:

• This will not add a "Forward" control point to parts which already have the "Up" and "Reverse" control point: I believe this is good, since these parts are likely not made to be used with a "Forward" control point anyway
• This will look weird on plane cockpits, wich will have the "Up" control point pointing forward and the "Forward" control point pointing downward: I believe this is bad, but I am not sure what you can do about it except filtering on the name of the parts...

[blowfish]

On 6/12/2019 at 4:22 AM, TriggeredSnake said:

Hang on, this doesn’t support 1.7.1? Wow! I think that’s the first time I’ve ever seen module manager be out of date.

Have you discovered an incompatibility?

[TriggeredSnake]

8 hours ago, blowfish said:

Have you discovered an incompatibility?

No, it’s working perfectly, but the forum title just says 1.4.0-1.6.x.

[Drew Kerman]

28 minutes ago, TriggeredSnake said:

No, it’s working perfectly, but the forum title just says 1.4.0-1.6.x.

Sarbian is on an extended vacation - I think until the end of this month IIRC, so the thread title hasn't been updated

[TriggeredSnake]

29 minutes ago, Drew Kerman said:

Sarbian is on an extended vacation - I think until the end of this month IIRC, so the thread title hasn't been updated

Okay

[Jesusthebird]

Hi everyone. Im attempting to modify an engine from MK2X to add an air breathing mode to an engine. Ive been able to add the engine mode, and it seems to be working properly so far..the only issue seems to be the exhaust heat fx

here is the original part CFG(snipped out non related things like.. Module Test Subject and Module Gimbal..Module Alternator)

Spoiler

PART
{
    name = M2X_FuselageRVTOLE
    module = Part
    author = SuicidalInsanity
    mesh = Model.mu
    rescaleFactor = 1
    node_stack_top = 0.0, 0.5, 0.0, 0.0, 1.0, 0.0
    node_stack_bottom = 0.0, -0.5, 0.0, 0.0, -1.0, 0.0
    CoMOffset = 0.0, 0, 0.0
    TechRequired = advAerodynamics
    entryCost = 15500
    cost = 1500
    category = Engine
    subcategory = 0
    title = #LOC_M2X_Mutt_title
    manufacturer = #LOC_M2X_manufacturer_IA_title
    description = #LOC_M2X_Mutt_description
    attachRules = 1,0,1,1,0
    mass = 1.1
    heatConductivity = 0.06 // half default
    skinInternalConductionMult = 4.0
    emissiveConstant = 0.8 // engine nozzles are good at radiating.
    dragModelType = default
    maximum_drag = 0.2
    minimum_drag = 0.2
    angularDrag = 2
    crashTolerance = 7
    maxTemp = 2000 // = 3600
    bulkheadProfiles = mk2
    tags = #LOC_M2X_Mutt_tags
    MODEL
    {
        model = Mk2Expansion/Parts/Engines/LanderEngine/Model
        texture = mk2FuselageShort, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort
        texture = engine3, Squad/Parts/Engine/liquidEngineLV-909/engine3
        texture = engine3_emissive, Squad/Parts/Engine/liquidEngineLV-909/engine3_emissive
    }
    EFFECTS
    {
        running_closed
        {
            AUDIO
            {
                channel = Ship
                clip = sound_rocket_hard
                volume = 0.0 0.0
                volume = 0.05 0.6
                volume = 1.0 1.5
                pitch = 0.0 1.2
                pitch = 1.0 2.0
                loop = true
            }
            PREFAB_PARTICLE
            {
                name = StarboardSmoke
                prefabName = fx_smokeTrail_light
                transformName = StarboardSmoke
                emission = 0.0 0.0
                emission = 0.05 0.0
                emission = 0.075 0.25
                emission = 1.0 1.25
                speed = 0.0 0.25
                speed = 1.0 1.0
                localOffset = 0, 0, 1
                localRotation = 1, 0, 0, -90
            }    
            PREFAB_PARTICLE
            {
                name = PortSmoke
                prefabName = fx_smokeTrail_light
                transformName = PortSmoke
                emission = 0.0 0.0
                emission = 0.05 0.0
                emission = 0.075 0.25
                emission = 1.0 1.25
                speed = 0.0 0.25
                speed = 1.0 1.0
                localOffset = 0, 0, 1
                localRotation = 1, 0, 0, -90
            }
        MODEL_MULTI_PARTICLE
            {
                modelName = Squad/FX/shockExhaust_blue_small
                transformName = FXpoint
                emission = 0.0 0.0
                emission = 0.05 0.0
                emission = 0.075 0.25
                emission = 1.0 1.25
                speed = 0.0 0.5
                speed = 1.0 1.2
            }
        }
        engage
        {
            AUDIO
            {
                channel = Ship
                clip = sound_vent_soft
                volume = 1.0
                pitch = 2.0
                loop = false
            }
        }
        flameout
        {
            AUDIO
            {
                channel = Ship
                clip = sound_explosion_low
                volume = 1.0
                pitch = 2.0
                loop = false
            }
        }
    }
    MODULE
    {
        name = ModuleEnginesFX
        runningEffectName = running_closed
        thrustVectorTransformName = thrustTransform
        exhaustDamage = True
        ignitionThreshold = 0.1
        minThrust = 0
        maxThrust = 140
        heatProduction = 60
        fxOffset = 0, 0, 0
        EngineType = LiquidFuel
        PROPELLANT
        {
            name = LiquidFuel
            ratio = 0.9
            DrawGauge = True
        }
        PROPELLANT
        {
            name = Oxidizer
            ratio = 1.1
        }
        atmosphereCurve
        {
            key = 0 340
            key = 1 195
            key = 12 0.001
        }
    }
    MODULE
    {
        name = FXModuleAnimateThrottle
        animationName = Lander_Engine_Heat
        responseSpeed = 0.05
        dependOnEngineState = True
    }
    RESOURCE
    {
        name = ElectricCharge
        amount = 0
        maxAmount = 0
        isTweakable = false
        hideFlow = true
    }
    MODULE
    {
        name = ModuleSurfaceFX
        thrustProviderModuleIndex = 0
        fxMax = 0.5
        maxDistance = 20
        falloff = 2
        thrustTransformName = thrustTransform
    }
}
    

and here is my patch

Spoiler

@PART[M2X_FuselageRVTOLE]:NEEDS[Mk2Expansion]:FINAL
{
@MODULE[ModuleEnginesFX]
    {
        engineID = ClosedCycle
    }
EFFECTS
    {
        running_open
        {
            AUDIO
            {
                channel = Ship
                clip = sound_rocket_hard
                volume = 0.0 0.0
                volume = 0.05 0.6
                volume = 1.0 1.5
                pitch = 0.0 1.2
                pitch = 1.0 2.0
                loop = true
            }
            PREFAB_PARTICLE
            {
                name = StarboardSmoke
                prefabName = fx_smokeTrail_light
                transformName = StarboardSmoke
                emission = 0.0 0.0
                emission = 0.05 0.0
                emission = 0.075 0.25
                emission = 1.0 1.25
                speed = 0.0 0.25
                speed = 1.0 1.0
                localOffset = 0, 0, 1
                localRotation = 1, 0, 0, -90
            }    
            PREFAB_PARTICLE
            {
                name = PortSmoke
                prefabName = fx_smokeTrail_light
                transformName = PortSmoke
                emission = 0.0 0.0
                emission = 0.05 0.0
                emission = 0.075 0.25
                emission = 1.0 1.25
                speed = 0.0 0.25
                speed = 1.0 1.0
                localOffset = 0, 0, 1
                localRotation = 1, 0, 0, -90
            }
        MODEL_MULTI_PARTICLE
            {
                modelName = Squad/FX/shockExhaust_blue_small
                transformName = FXpoint
                emission = 0.0 0.0
                emission = 0.05 0.0
                emission = 0.075 0.25
                emission = 1.0 1.25
                speed = 0.0 0.5
                speed = 1.0 1.2
            }
        }
        engage
        {
            AUDIO
            {
                channel = Ship
                clip = sound_vent_soft
                volume = 1.0
                pitch = 2.0
                loop = false
            }
        }
        flameout
        {
            AUDIO
            {
                channel = Ship
                clip = sound_explosion_low
                volume = 1.0
                pitch = 2.0
                loop = false
            }
        }
    }
MODULE
    {
        name = MultiModeEngine
        primaryEngineID = ClosedCycle
        primaryEngineModeDisplayName = #autoLOC_6001898 //            #autoLOC_6001898 = ClosedCycle
        secondaryEngineID = AirBreathing
        secondaryEngineModeDisplayName = #autoLOC_6001897 //            #autoLOC_6001897 = AirBreathing
    }

MODULE
    {
        name = ModuleEnginesFX
        engineID = AirBreathing
        runningEffectName = running_open
        thrustVectorTransformName = thrustTransform
        exhaustDamage = True
        ignitionThreshold = 0.1
        maxThrust = 105
        heatProduction = 60
        fxOffset = 0, 0, 0
        engineSpoolTime = 1.5
        spoolEffectName = running_open
        EngineType = Turbine
        PROPELLANT
        {
            name = LiquidFuel
            ratio = 0.9
            DrawGauge = True
        }
        PROPELLANT
        {
            name = IntakeAir
            ignoreForIsp = True
            ratio = 1.1
        }
        atmosphereCurve
        {
            key = 0 900
        }
    }
}

So..currently for both modes. the particles, smoke trail and sounds seems to be identical. The only thing thats absent seems to be the orange glow from the exhaust port during the new air breathing mode.

screenshot: https://1drv.ms/u/s!AjOhSRn-M-XfjwFC5DrNLucSrm_o

the screenshot is during closed cycle. When airbreathing is activated..it goes back to black like engine was turned off or something

Thoughts? Thanks Peeps

I can go post in the mk2x thread if this is more appropriate there..but I figured this was a more likely a problem with my MM patch

Edited June 17, 2019 by Jesusthebird

[sarbian]

3 hours ago, Drew Kerman said:

Sarbian is on an extended vacation - I think until the end of this month IIRC, so the thread title hasn't been updated

That was in April. We French do go to work from time to time

I am around but busy with work and not really in the mood to write mode code at home ATM. 

I'll fix the thread title.

[zer0Kerbal]

thank you.

it is working now.

full patch (specifically for OrbitalTug)

Spoiler

@PART[OrbitalTugPod,DronePod,helperDrone]:NEEDS[OrbitalTug]:FOR[OrbitalTug]
 {
	@MODULE[ModuleCommand] {
		@name = ModuleCommand
		%defaultControlPointDisplayName = Up
		%CONTROLPOINT[forward] {
			%name = forward
			%displayName = Forward
			%orientation = 90,0,0
		}
		%CONTROLPOINT[reverse] {
			%name = reverse
			%displayName = Reverse
			%orientation = 0,0,180
		}
	}
}
// zer0Kerbal

 

 

On 6/15/2019 at 12:52 PM, 4x4cheesecake said:

*takes glasses* now you get 4 

But I'm on mobile  so don't expect a full patch

First of all, there is a missing '@' in the first HAS block, it needs to be

@PART:HAS[@MODULE[ModuleCommand]]:FOR[_Me]

And this:

@MODULE[ModuleCommand] {
		name = ModuleCommand

doesn't  look right at all. This will address the module with the name 'ModuleCommand' and adds the name 'ModuleCommand' to it so the final config is going to provide two 'name' keys.

I cannot look up the stock configs right now but I guess you want to add 'ControlPoint' nodes to the module 'ModuleCommand'? You should be fine by removing the additional name key then

*faceplant*

On 6/15/2019 at 2:50 PM, nmc said:

@zer0Kerbal your patch has some issues, my fresh set of eyes did not like it:

• It is syntactically incorrect because the opening brace after the "@PART" node is missing
• It does not match any part (I think, not sure about this one) because the "@PART" node needs "[*]" (a wildcard name selector)
• As indicated by @4x4cheesecake, it does not any match parts because the "MODULE[ModuleCommand]" filter needs "@" (a node selector)
• As indicated by @4x4cheesecake, it duplicates the "name" key of the "MODULE[ModuleCommand]" node, it should not
• The "%CONTROLPOINT" patches will override one another one because they are missing a name selector, they should be "%CONTROLPOINT[forward]" and "%CONTROLPOINT[reverse]" and the "%name" key becomes useless
• It is applied to all parts with a "MODULE[ModuleCommand]" node, whereas it should probably only be for the ones that do not have any "CONTROLPOINT" node inside, in which case the "%CONTROLPOINT" patches do not need either a name selector or a "%" but do need a "name" key
• It is a custom user patch, so it should probably be applied last and therefore needs a ":FINAL"

 

All in all, it offer you this:

 

Some notes:

• This will not add a "Forward" control point to parts which already have the "Up" and "Reverse" control point: I believe this is good, since these parts are likely not made to be used with a "Forward" control point anyway
• This will look weird on plane cockpits, wich will have the "Up" control point pointing forward and the "Forward" control point pointing downward: I believe this is bad, but I am not sure what you can do about it except filtering on the name of the parts...

thank you.

missing left brace (faceplant) missing@ (faceplant)

the @PART (according to this thread) is syntactically correct reference to all parts, and I believe was the preferred method to @PART[*]; however I agree that in light of recent revelations we need to start following a set of 'best practices' and specificity is one of them. so @PART[*] win vs. @PART.

:Final is overused. everything gets a :FINAL so :FINAL really means not much.  Best practices in my humble layman opinion should always see a :FOR clause on all patches - even it is just :FOR[_Me] which if I understand correctly will be processed very near last.

agree on the !CONTROLPOINT

the extra % (add or edit) &(Add only) are there to handle any possible duplication. since this can only &(Add only) - it cannot create additional copies - if I am making myself clear.

agree it would look strange on a plane cockpit - and quite confident some brain will figure it out.

part of the expanded plan for this is to handle those situations we have all been in where we slap a probe core onto something and launch it - only to discover it is backwards, upside-down, or even sideways.

Edited June 18, 2019 by zer0Kerbal

[nmc]

@zer0Kerbal glad you liked it

 

Last points:

• I was not sure about @PART without a name selector because I have not seen it properly documented, but if it works then it is fine
• This does not do anything and can be removed:

@name = ModuleCommand

• The FOR clause is reserved for the mod author, it tells ModuleManager that the config is part of the OrbitalTug mod (mainly to be able to use OrbitalTug in BEFORE/AFTER/NEEDS clauses), you should not use it in your custom patches; the NEEDS clause should be enough to make sure that the OrbitalTug parts are loaded before your patch applies; if you want a FOR, it should be using your custom name like "_Me" or "ZZZ_CustomPatches" or something (but it should not be necessary)
• If your patch works without FINAL then I agree that there is no need for it

[blowfish]

13 hours ago, Jesusthebird said:

Hi everyone. Im attempting to modify an engine from MK2X to add an air breathing mode to an engine. Ive been able to add the engine mode, and it seems to be working properly so far..the only issue seems to be the exhaust heat fx

here is the original part CFG(snipped out non related things like.. Module Test Subject and Module Gimbal..Module Alternator)

  Reveal hidden contents

PART
{
    name = M2X_FuselageRVTOLE
    module = Part
    author = SuicidalInsanity
    mesh = Model.mu
    rescaleFactor = 1
    node_stack_top = 0.0, 0.5, 0.0, 0.0, 1.0, 0.0
    node_stack_bottom = 0.0, -0.5, 0.0, 0.0, -1.0, 0.0
    CoMOffset = 0.0, 0, 0.0
    TechRequired = advAerodynamics
    entryCost = 15500
    cost = 1500
    category = Engine
    subcategory = 0
    title = #LOC_M2X_Mutt_title
    manufacturer = #LOC_M2X_manufacturer_IA_title
    description = #LOC_M2X_Mutt_description
    attachRules = 1,0,1,1,0
    mass = 1.1
    heatConductivity = 0.06 // half default
    skinInternalConductionMult = 4.0
    emissiveConstant = 0.8 // engine nozzles are good at radiating.
    dragModelType = default
    maximum_drag = 0.2
    minimum_drag = 0.2
    angularDrag = 2
    crashTolerance = 7
    maxTemp = 2000 // = 3600
    bulkheadProfiles = mk2
    tags = #LOC_M2X_Mutt_tags
    MODEL
    {
        model = Mk2Expansion/Parts/Engines/LanderEngine/Model
        texture = mk2FuselageShort, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort
        texture = engine3, Squad/Parts/Engine/liquidEngineLV-909/engine3
        texture = engine3_emissive, Squad/Parts/Engine/liquidEngineLV-909/engine3_emissive
    }
    EFFECTS
    {
        running_closed
        {
            AUDIO
            {
                channel = Ship
                clip = sound_rocket_hard
                volume = 0.0 0.0
                volume = 0.05 0.6
                volume = 1.0 1.5
                pitch = 0.0 1.2
                pitch = 1.0 2.0
                loop = true
            }
            PREFAB_PARTICLE
            {
                name = StarboardSmoke
                prefabName = fx_smokeTrail_light
                transformName = StarboardSmoke
                emission = 0.0 0.0
                emission = 0.05 0.0
                emission = 0.075 0.25
                emission = 1.0 1.25
                speed = 0.0 0.25
                speed = 1.0 1.0
                localOffset = 0, 0, 1
                localRotation = 1, 0, 0, -90
            }    
            PREFAB_PARTICLE
            {
                name = PortSmoke
                prefabName = fx_smokeTrail_light
                transformName = PortSmoke
                emission = 0.0 0.0
                emission = 0.05 0.0
                emission = 0.075 0.25
                emission = 1.0 1.25
                speed = 0.0 0.25
                speed = 1.0 1.0
                localOffset = 0, 0, 1
                localRotation = 1, 0, 0, -90
            }
        MODEL_MULTI_PARTICLE
            {
                modelName = Squad/FX/shockExhaust_blue_small
                transformName = FXpoint
                emission = 0.0 0.0
                emission = 0.05 0.0
                emission = 0.075 0.25
                emission = 1.0 1.25
                speed = 0.0 0.5
                speed = 1.0 1.2
            }
        }
        engage
        {
            AUDIO
            {
                channel = Ship
                clip = sound_vent_soft
                volume = 1.0
                pitch = 2.0
                loop = false
            }
        }
        flameout
        {
            AUDIO
            {
                channel = Ship
                clip = sound_explosion_low
                volume = 1.0
                pitch = 2.0
                loop = false
            }
        }
    }
    MODULE
    {
        name = ModuleEnginesFX
        runningEffectName = running_closed
        thrustVectorTransformName = thrustTransform
        exhaustDamage = True
        ignitionThreshold = 0.1
        minThrust = 0
        maxThrust = 140
        heatProduction = 60
        fxOffset = 0, 0, 0
        EngineType = LiquidFuel
        PROPELLANT
        {
            name = LiquidFuel
            ratio = 0.9
            DrawGauge = True
        }
        PROPELLANT
        {
            name = Oxidizer
            ratio = 1.1
        }
        atmosphereCurve
        {
            key = 0 340
            key = 1 195
            key = 12 0.001
        }
    }
    MODULE
    {
        name = FXModuleAnimateThrottle
        animationName = Lander_Engine_Heat
        responseSpeed = 0.05
        dependOnEngineState = True
    }
    RESOURCE
    {
        name = ElectricCharge
        amount = 0
        maxAmount = 0
        isTweakable = false
        hideFlow = true
    }
    MODULE
    {
        name = ModuleSurfaceFX
        thrustProviderModuleIndex = 0
        fxMax = 0.5
        maxDistance = 20
        falloff = 2
        thrustTransformName = thrustTransform
    }
}
    

and here is my patch

  Reveal hidden contents

@PART[M2X_FuselageRVTOLE]:NEEDS[Mk2Expansion]:FINAL
{
@MODULE[ModuleEnginesFX]
    {
        engineID = ClosedCycle
    }
EFFECTS
    {
        running_open
        {
            AUDIO
            {
                channel = Ship
                clip = sound_rocket_hard
                volume = 0.0 0.0
                volume = 0.05 0.6
                volume = 1.0 1.5
                pitch = 0.0 1.2
                pitch = 1.0 2.0
                loop = true
            }
            PREFAB_PARTICLE
            {
                name = StarboardSmoke
                prefabName = fx_smokeTrail_light
                transformName = StarboardSmoke
                emission = 0.0 0.0
                emission = 0.05 0.0
                emission = 0.075 0.25
                emission = 1.0 1.25
                speed = 0.0 0.25
                speed = 1.0 1.0
                localOffset = 0, 0, 1
                localRotation = 1, 0, 0, -90
            }    
            PREFAB_PARTICLE
            {
                name = PortSmoke
                prefabName = fx_smokeTrail_light
                transformName = PortSmoke
                emission = 0.0 0.0
                emission = 0.05 0.0
                emission = 0.075 0.25
                emission = 1.0 1.25
                speed = 0.0 0.25
                speed = 1.0 1.0
                localOffset = 0, 0, 1
                localRotation = 1, 0, 0, -90
            }
        MODEL_MULTI_PARTICLE
            {
                modelName = Squad/FX/shockExhaust_blue_small
                transformName = FXpoint
                emission = 0.0 0.0
                emission = 0.05 0.0
                emission = 0.075 0.25
                emission = 1.0 1.25
                speed = 0.0 0.5
                speed = 1.0 1.2
            }
        }
        engage
        {
            AUDIO
            {
                channel = Ship
                clip = sound_vent_soft
                volume = 1.0
                pitch = 2.0
                loop = false
            }
        }
        flameout
        {
            AUDIO
            {
                channel = Ship
                clip = sound_explosion_low
                volume = 1.0
                pitch = 2.0
                loop = false
            }
        }
    }
MODULE
    {
        name = MultiModeEngine
        primaryEngineID = ClosedCycle
        primaryEngineModeDisplayName = #autoLOC_6001898 //            #autoLOC_6001898 = ClosedCycle
        secondaryEngineID = AirBreathing
        secondaryEngineModeDisplayName = #autoLOC_6001897 //            #autoLOC_6001897 = AirBreathing
    }

MODULE
    {
        name = ModuleEnginesFX
        engineID = AirBreathing
        runningEffectName = running_open
        thrustVectorTransformName = thrustTransform
        exhaustDamage = True
        ignitionThreshold = 0.1
        maxThrust = 105
        heatProduction = 60
        fxOffset = 0, 0, 0
        engineSpoolTime = 1.5
        spoolEffectName = running_open
        EngineType = Turbine
        PROPELLANT
        {
            name = LiquidFuel
            ratio = 0.9
            DrawGauge = True
        }
        PROPELLANT
        {
            name = IntakeAir
            ignoreForIsp = True
            ratio = 1.1
        }
        atmosphereCurve
        {
            key = 0 900
        }
    }
}

So..currently for both modes. the particles, smoke trail and sounds seems to be identical. The only thing thats absent seems to be the orange glow from the exhaust port during the new air breathing mode.

screenshot: https://1drv.ms/u/s!AjOhSRn-M-XfjwFC5DrNLucSrm_o

the screenshot is during closed cycle. When airbreathing is activated..it goes back to black like engine was turned off or something

Thoughts? Thanks Peeps

I can go post in the mk2x thread if this is more appropriate there..but I figured this was a more likely a problem with my MM patch

Not strictly a ModuleManager question, but you probably need to set preferMultiMode = true on the FXModuleAnimateThrottle so that it finds the multi-mode engine module and not the first of the two engine modules.

[zer0Kerbal]

1 hour ago, nmc said:

@zer0Kerbal glad you liked it

 

Last points:

• I was not sure about @PART without a name selector because I have not seen it properly documented, but if it works then it is fine
• This does not do anything and can be removed:

@name = ModuleCommand

• The FOR clause is reserved for the mod author, it tells ModuleManager that the config is part of the OrbitalTug mod (mainly to be able to use OrbitalTug in BEFORE/AFTER/NEEDS clauses), you should not use it in your custom patches; the NEEDS clause should be enough to make sure that the OrbitalTug parts are loaded before your patch applies; if you want a FOR, it should be using your custom name like "_Me" or "ZZZ_CustomPatches" or something (but it should not be necessary)
• If your patch works without FINAL then I agree that there is no need for it

HAS/NEEDS are limiting factors, not timing factors.

in order to address best practices, there should always be a timing factor, and if FINAL is essentially worthless because every Jeb, Bill, Harry, Frank, Bob, Rob, Job, Val is using it.. so just saying that if one is say putting on a TweakScale patch, that would be a :FOR[TweakScale] time - and yes, reserved for Mod Authors as well. Without a :FOR - there can be no :LAST,FIRST,AFTER if I understand correctly.

So I for one will always put a :FOR because that is my best practices. In fact I am going back and effecting this change retroactively on all my patches.

Concerning the @name =ModuleCommand after @MODULE[ModuleCommand] does do something, it acts as an anchor - plus best practices says that always having it is less confusing than sometimes having it.

Yes making sure that every line starts with a @#%& et al is important to me for best practices - since there is no ambiguity and exiguity to Module Manager in what you want to it to do. 

Probably not making sense, need some sleep I do.

 

do have a query:

so if one were to write a patch with the following in it:
&MODULE[animateKerbal] {

 lefthand = raised

}

would MM process anything after the & (create only) if there was already a MODULE[animateKerbal] present? I am thinking not - but thought would ask.

[nmc]

Wow thanks @zer0Kerbal for all the info!

 

31 minutes ago, zer0Kerbal said:

HAS/NEEDS are limiting factors, not timing factors.

in order to address best practices, there should always be a timing factor, and if FINAL is essentially worthless because every Jeb, Bill, Harry, Frank, Bob, Rob, Job, Val is using it.. so just saying that if one is say putting on a TweakScale patch, that would be a :FOR[TweakScale] time - and yes, reserved for Mod Authors as well. Without a :FOR - there can be no :LAST,FIRST,AFTER if I understand correctly.

So I for one will always put a :FOR because that is my best practices. In fact I am going back and effecting this change retroactively on all my patches.

Concerning the @name =ModuleCommand after @MODULE[ModuleCommand] does do something, it acts as an anchor - plus best practices says that always having it is less confusing than sometimes having it.

Yes making sure that every line starts with a @#%& et al is important to me for best practices - since there is no ambiguity and exiguity to Module Manager in what you want to it to do. 

 

On NEEDS => yes my answer above was badly written, I got confused between you using FOR and not needing FINAL for ordering, sorry about that

 

On re-writing "@name" => I did not know that was a best practice, and I do not understand what you mean by "it acts as an anchor", could you elaborate?

 

On FOR => I agree that using it is a best practice, however I believe the name should correspond to the author:

If I write a mod called "MyMod" which contains a TweakScale patch, I should use :FOR[MyMod]:NEEDS[TweakScale], should I not?

Does :NEEDS[OrbitalTug]:FOR[OrbitalTug] not defeat itself? It simultaneously defines and requires "OrbitalTug"... I'm confused

 

Cheers

[nmc]

One more thing: I cannot find any reference to "&" as an operator

 

The wiki says an operator can be either one of:

• nothing for insert
• @ for edit
• + or $ for copy
• - or ! for delete
• % for edit-or-create.

 

What am I missing?

[Jesusthebird]

7 hours ago, blowfish said:

Not strictly a ModuleManager question, but you probably need to set preferMultiMode = true on the FXModuleAnimateThrottle so that it finds the multi-mode engine module and not the first of the two engine modules.

Ill give that a shot tonight. Thanks!

[zer0Kerbal]

14 hours ago, nmc said:

Wow thanks @zer0Kerbal for all the info!

thank you for the great conversation.

I'm still a novice beginner at MM patch writing, and as much as I'd love to read all 260+ pages of this thread to compile a updated wiki, I don't have the time nor the attention span to do so. (I have rockets to spectacularly  blow up. )

14 hours ago, nmc said:

On NEEDS => yes my answer above was badly written, I got confused between you using FOR and not needing FINAL for ordering, sorry about that

no need to apologize. ModuleManager patch writing is often confusing.

14 hours ago, nmc said:

On re-writing "@name" => I did not know that was a best practice, and I do not understand what you mean by "it acts as an anchor", could you elaborate?

let me clarify: My best practices. Hard to explain why I like having that seemingly extraneous bit of code.

I like it because MM discards the codeblock's originating line (the @MODULE[ModuleThat]... but will keep the @name = ModuleThat. Call it personal preference, that I suspect has value.

 

14 hours ago, nmc said:

On FOR => I agree that using it is a best practice, however I believe the name should correspond to the author:

If I write a mod called "MyMod" which contains a TweakScale patch, I should use :FOR[MyMod]:NEEDS[TweakScale], should I not?

Does :NEEDS[OrbitalTug]:FOR[OrbitalTug] not defeat itself? It simultaneously defines and requires "OrbitalTug"... I'm confused

 

Cheers

I do agree on that. My personal best practices though is slightly different.

14 hours ago, nmc said:

Does :NEEDS[OrbitalTug]:FOR[OrbitalTug] not defeat itself? It simultaneously defines and requires "OrbitalTug"... I'm confused

yes and no. first I always place the :NEEDS before the :FOR (oops)

I believe that this doesn't defeat itself, rather it removes ambiguity and therefor removes chances to confuse ModuleManager or make a mistake. Yes, you can have a :NEEDS without a :FOR and a :FOR without a :NEEDS - This is allowed and is lacking in preciseness - or rather lacking in specificity.

My best practices [WIP] says Specificity is desired; which in this case means always having a :FOR on all patches; so even though the NEEDS is present, the FOR is also since one is a limiting factor and the other is a timing factor. We always want to control the timing, but don't always need a limiting factor.

Another way of saying this is :NEEDS[x] only says that [x] must be present in order to process the patch or codeblock; while :FOR[x] says when to process the patch or codeblock.

I really should define codeblock vs. patch. A patch is the entire patch (obviously) starting with @PART or @xxx and contains codeblocks. Codeblocks in this instance is defined as the originating code line and the {} belonging to it that resides withing a patch.

On a side note, am working on adding a little bit of debug code to my personal patches - so within every code block there are two cut-and-paste (boilerplate) code snippets.

Spoiler

&dBug:NEEDS[Debug=1] = DEBUG:  
@dBug:NEEDS[Debug=1] ^= :$: (authorName) - (name of patch) adding {something).:

I will define dBug in a file named myModConfigs.cfg

Spoiler

MyMODCONFIGS
{
 dBug = 1 // 0 off / 1 on - if on, puts debug code in all patches
  ...
}

 

This will only show up when turned on and when the command line switch "-mm-dump" is present. Its a work in progress - but will show who/what/when patches have modified a part. By doing it this way, a chronological order can be established as well for use in forensical bug swatting.

14 hours ago, nmc said:

One more thing: I cannot find any reference to "&" as an operator

 

The wiki says an operator can be either one of:

• nothing for insert
• @ for edit
• + or $ for copy
• - or ! for delete
• % for edit-or-create.

 

What am I missing?

I was just told about the & operator in a recent request to help with a patch - I now use it with codeblocks instead of most :HAS[!] or :NEEDS[!]

& for Add only - which makes it very handy and very practical.

makes me wonder what else is missing in the docs?  

Edited June 19, 2019 by zer0Kerbal

[Jesusthebird]

@blowfish Just wanted to say Thank You! that tip (preferMultiMode = true on the FXModuleAnimateThrottle) did the job! You da Man!

[Eklykti]

Am I really supposed to write something like:

 

@PART[*]:HAS[@MODULE[Experiment]:HAS[#experiment_id[dmNAlbedoScan]]]:NEEDS[DMagicOrbitalScience,FeatureScience]:AFTER[Kerbalism]
{
	
	@MODULE[Experiment]
	{
		%unsamplify = True
	}
}

@PART[*]:HAS[@MODULE[Experiment]:HAS[#experiment_id[dmXRayDiffract]]]:NEEDS[DMagicOrbitalScience,FeatureScience]:AFTER[Kerbalism]
{
	
	@MODULE[Experiment]
	{
		%unsamplify = True
	}
}

@PART[*]:HAS[@MODULE[Experiment]:HAS[#experiment_id[dmlaserblastscan]]]:NEEDS[DMagicOrbitalScience,FeatureScience]:AFTER[Kerbalism]
{
	
	@MODULE[Experiment]
	{
		%unsamplify = True
	}
}

@PART[*]:HAS[@MODULE[Experiment]:HAS[#unsamplify[True]]]:NEEDS[DMagicOrbitalScience,FeatureScience]:AFTER[Kerbalism]
{
	@MODULE[Experiment]
	{
		-unsamplify = True
		-sample_mass = anything
		-sample_collecting = True
		-sample_reservoir = 0
	}
}

instead of just:

 

@PART[*]:HAS[@MODULE[Experiment]:HAS[#experiment_id[dmNAlbedoScan|dmXRayDiffract|dmlaserblastscan]]]:NEEDS[DMagicOrbitalScience,FeatureScience]:AFTER[Kerbalism]
{
	@MODULE[Experiment]
	{
		-sample_mass = anything
		-sample_collecting = True
		-sample_reservoir = 0
	}
}

Or am I missing something about why the later doesn't work?

Edited June 22, 2019 by Eklykti