Tonka Crash Posted June 13, 2019 Share Posted June 13, 2019 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. Quote Link to comment Share on other sites More sharing options...
zer0Kerbal Posted June 13, 2019 Share Posted June 13, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Tonka Crash Posted June 13, 2019 Share Posted June 13, 2019 @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. Quote Link to comment Share on other sites More sharing options...
zer0Kerbal Posted June 13, 2019 Share Posted June 13, 2019 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. Quote Link to comment Share on other sites More sharing options...
Tonka Crash Posted June 13, 2019 Share Posted June 13, 2019 @zer0Kerbal Try this out and see if it's doing what you want. Quote Link to comment Share on other sites More sharing options...
zer0Kerbal Posted June 14, 2019 Share Posted June 14, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
zer0Kerbal Posted June 15, 2019 Share Posted June 15, 2019 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! Quote Link to comment Share on other sites More sharing options...
4x4cheesecake Posted June 15, 2019 Share Posted June 15, 2019 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 Quote Link to comment Share on other sites More sharing options...
nmc Posted June 15, 2019 Share Posted June 15, 2019 @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... Quote Link to comment Share on other sites More sharing options...
blowfish Posted June 17, 2019 Share Posted June 17, 2019 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? Quote Link to comment Share on other sites More sharing options...
TriggeredSnake Posted June 17, 2019 Share Posted June 17, 2019 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. Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted June 17, 2019 Share Posted June 17, 2019 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 Quote Link to comment Share on other sites More sharing options...
TriggeredSnake Posted June 17, 2019 Share Posted June 17, 2019 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 Quote Link to comment Share on other sites More sharing options...
Jesusthebird Posted June 17, 2019 Share Posted June 17, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
sarbian Posted June 17, 2019 Author Share Posted June 17, 2019 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. Quote Link to comment Share on other sites More sharing options...
zer0Kerbal Posted June 18, 2019 Share Posted June 18, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
nmc Posted June 18, 2019 Share Posted June 18, 2019 @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 Quote Link to comment Share on other sites More sharing options...
blowfish Posted June 18, 2019 Share Posted June 18, 2019 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. Quote Link to comment Share on other sites More sharing options...
zer0Kerbal Posted June 18, 2019 Share Posted June 18, 2019 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. Quote Link to comment Share on other sites More sharing options...
nmc Posted June 18, 2019 Share Posted June 18, 2019 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 Quote Link to comment Share on other sites More sharing options...
nmc Posted June 18, 2019 Share Posted June 18, 2019 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? Quote Link to comment Share on other sites More sharing options...
Jesusthebird Posted June 18, 2019 Share Posted June 18, 2019 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! Quote Link to comment Share on other sites More sharing options...
zer0Kerbal Posted June 18, 2019 Share Posted June 18, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Jesusthebird Posted June 19, 2019 Share Posted June 19, 2019 @blowfish Just wanted to say Thank You! that tip (preferMultiMode = true on the FXModuleAnimateThrottle) did the job! You da Man! Quote Link to comment Share on other sites More sharing options...
Eklykti Posted June 22, 2019 Share Posted June 22, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.