ialdabaoth

Repeating my request for modellers, since it might have got lost in the flames: Would anyone be willing to re-do the heat shield models so that they have (short) auto-shrouds? It'd allow us to remove the extra decouplers, and just use standard decoupler parts. This would be especially cool for the inflatable shield.

That would be pretty amazing, actually. If Kerbol is 0.8 solar masses / 0.73 solar radii and Kerbin is at 0.6 AU, then that scales up all the orbital distances by exactly 6.4.

An Effects has a single power level. You'd have to have a separate Effects node for each thruster port, and then my RCS mod would need some way of wiring them all up right.

New .zip posted; anyone who wants to make integrated pod RCS should now be able to do so.

NO! DON'T GET THE DLL FROM GITHUB! THERE IS A HORRIBLE NULLREFERENCEEXCEPTION BUG! Let me continue work on it tonight, and THEN I will post a new .zip link. EDIT: IGNORE ME! The DLL is just fine, it was someone else's mod that was causing my NREs

I *think* it will, but there may be some bugs due to my not quite understanding part.Effects() yet.

A request: is there any way to remove engines (for example, sepratrons and the launch escape tower) from the staging list? It would be really cool to have ullage and escape motors that can only be activated via action groups.

...yes. Yes I can.

update: just fixed a minor bug where sometimes RCS thrusters would still appear active when RCS is off. Please re-download.

So, :NEEDS[...] gets applied to a :BEFORE or :AFTER in the same way that :HAS gets applied to the part name filter. i.e., it's not just @PART[...]:NEEDS[OtherMod] it's actually @PART[...]:BEFORE[OtherMod]:NEEDS[AnotherMod, !YetAnotherMod] which says "Apply this node before the :FOR[OtherMod] pass, but ONLY if AnotherMod is also installed AND YetAnotherMod ISN'T installed." Just doing @PART[...]:NEEDS[OtherMod] is identical to doing @PART[...]:FIRST:NEEDS[OtherMod] in the same way that @PART[...] is identical to @PART[...]:FIRST; if you want it to happen in the FINAL pass, do @PART[...]:FINAL:NEEDS[OtherMod] So, in your example, rather than: @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]]:NEEDS[MechJeb2]:FINAL You need to do: @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]]:FINAL:NEEDS[MechJeb2] You can't do :NEEDS[MechJeb2]:FINAL or :NEEDS[MechJeb2]:BEFORE[blah] any more than you could do @HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]]:PART[*] The order MUST be: *NODE:HAS[FilterOptions]:PASS:NEEDS[NeedOptions] Where: - '*' can be one of '@', '!', '%' - NODE can be PART, RESOURCE_DEFINITION, or any other root-level node, and can optionally include [nodeNameFilter] and/or ,index - HAS[FilterOptions] is optional - PASS can be FIRST, BEFORE[modname], FOR[modname], AFTER[modname], or FINAL. BEFORE[modname] and AFTER[modname] only get called if the FOR[modname] pass will be called. If PASS is not specified, it defaults to FIRST. - NEEDS[NeedOptions] is optional. Does that make sense?

I'm not sure how ModuleManager could properly control that, though. Short of scanning the PART node, storing the order of each node, wiping all of them, and rebuilding them carefully, I have no idea what could be done - and even then, if two nodes have the same type and name, it won't be able to remember which one is which when it rebuilds everything. This is really an issue with KSP more than MM.

Request for modellers: Would anyone be willing to re-do the heat shield models so that they have (short) auto-shrouds? It'd allow us to remove the extra decouplers, and just use standard decoupler parts. This would be especially cool for the inflatable shield.

So, now that this is all official-like, let's talk about what this would look like in the Real World. A really good example of this is RealFuels. All RealFuels confignodes should look like this now : @PART[liquidEngineMini]:FOR[RealFuels] //48-7S { @mass = 0.03125 @maxTemp = 2028 @MODULE[ModuleEngines] { @maxThrust = 30 @heatProduction = 191 @atmosphereCurve { @key,0 = 0 347 @key,1 = 1 285 } !PROPELLANT[LiquidFuel] {} !PROPELLANT[Oxidizer] {} !PROPELLANT[MonoPropellant] {} PROPELLANT { name = LiquidFuel ratio = 37.694087 DrawGauge = True } PROPELLANT { name = CryOx ratio = 62.305913 } } MODULE { name = ModuleEngineConfigs techLevel = 7 origTechLevel = 7 engineType = L+ origMass = 0.03125 configuration = LiquidFuel+CryOx modded = false CONFIG { name = CryoFuel+CryOx maxThrust = 22.5 heatProduction = 191 PROPELLANT { name = CryoFuel ratio = 0.7630831 DrawGauge = True } PROPELLANT { name = CryOx ratio = 0.2369169 } IspSL = 1.261 IspV = 1.3 throttle = 0 ModuleEngineIgnitor { name = ModuleEngineIgnitor ignitionsAvailable = 1 autoIgnitionTemperature = 800 ignitorType = Electric useUllageSimulation = true IGNITOR_RESOURCE { name = ElectricCharge amount = 0.3 } } } CONFIG { name = LiquidFuel+CryOx maxThrust = 30 heatProduction = 191 PROPELLANT { name = LiquidFuel ratio = 0.37694087 DrawGauge = True } PROPELLANT { name = CryOx ratio = 0.62305913 } IspSL = 1 IspV = 1 throttle = 0 ModuleEngineIgnitor { name = ModuleEngineIgnitor ignitionsAvailable = 1 autoIgnitionTemperature = 800 ignitorType = Electric useUllageSimulation = true IGNITOR_RESOURCE { name = ElectricCharge amount = 0.3 } } } CONFIG { name = Hypergolic+Oxidizer maxThrust = 30 heatProduction = 191 PROPELLANT { name = Hypergolic ratio = 0.49620149 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 0.50379851 } IspSL = 0.953 IspV = 0.952 throttle = 0 ModuleEngineIgnitor { name = ModuleEngineIgnitor ignitionsAvailable = 2 autoIgnitionTemperature = 800 ignitorType = Electric useUllageSimulation = true IGNITOR_RESOURCE { name = ElectricCharge amount = 0.3 } } } } !MODULE[ModuleEngineIgnitor] {} MODULE { name = ModuleEngineIgnitor ignitionsAvailable = 1 autoIgnitionTemperature = 800 ignitorType = Electric useUllageSimulation = true IGNITOR_RESOURCE { name = ElectricCharge amount = 0.3 } } } Note that :FOR[RealFuels] has replaced the :Final block! This allows other mod authors to create @PART[] patches with :BEFORE[RealFuels] and :AFTER[RealFuels], to tweak things before or after RealFuels gets to them. A mod author who releases their own parts - not mods of other people's parts - should just use the standard format. For example, from B9: PART { // --- general parameters --- name = B9_Utility_Leg_H50 module = HLandingLeg author = bac9 // --- asset parameters --- mesh = model.mu rescaleFactor = 1.25 scale = 1 animationName = leg_h50_toggle2 PhysicsSignificance = 0 // --- node definitions --- node_attach = 0.0, 0, 0, 0.0, 0.0, 0.0 // --- editor parameters --- TechRequired = advLanding entryCost = 6700 cost = 1250 category = Utility subcategory = 0 title = H50-A Landing Leg manufacturer = Tetragon Projects description = Landing leg for excessively heavy landers. We aren't sure how you got things like these into space in the first place, but this thing will help to get them back onto the ground. Probably. This model extends vertically and should be attached to the side of your lander. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 0,1,0,0,0 // --- standard part parameters --- mass = 0.2 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 120 maxTemp = 2900 CoMOffset = 0, 0, 0 breakingForce = 250 breakingTorque = 250 deploySpeed = 1 retractSpeed = -1 randomSpeedFactor = 0.05 } This is a standard configNode, NOT a ModuleManager patch node. When you make your own part, just define it as normal. So, let's say you have a mod with a plugin, that mixes original parts, adjustments to other parts, AND adjustments to other mod's adjustments. You will wind up with ALL THREE forms of configNodes. Original Parts/Resources/etc.: PART { name = myPart ... } Modifications to other parts, for my mod's DLL (which is called MyMod.dll) @PART[otherPart]:FOR[MyMod] { ... } Modifications to my parts OR other parts, for another mod's DLL (which is called OtherMod.dll) @PART[otherPart]:BEFORE[OtherMod] { ... } // or @PART[otherPart]:AFTER[OtherMod] { ... } NEVER EVER EVER use :FOR[OtherMod]. Only the mod author of a mod is allowed to use :FOR[mod]. if you are not the one providing SomeMod.DLL or a SomeMod.cfg "tweak pack", using :FOR[someMod] is like licking all the frosting off your co-worker's donut and then putting it back on his desk. No one's gonna STOP you, but you are a very naughty person and no one should be friends with you. Finally, there's :NEEDS[OtherMod] - this is for when you want to do thing in your :FOR[] pass, or another mod's :BEFORE[] or :AFTER[] pass, but only if yet ANOTHER mod is present. So you can do things like: @PART[mk1pod]:FOR[DeadlyReentry]:NEEDS[SolarSystemReplacer] { @MODULE[ModuleHeatShield] { // change the heat shield info to handle thicker atmosphere @reflective = 0.08 // 5% of heat is ignored at correct angle @dissipation { // dissipation is based on the part's current temperature key = 300 0 // begin ablating at 300 degrees C key = 1200 225 // maximum dissipation at 1200 degrees C } } @RESOURCE[AblativeShielding] { @amount = 500 @maxAmount = 500 } }

well what I really want is something that uses the normal Ion Engine's model, but scaled down and surface-mountable.

It's derived directly from ModuleRCS.

So, you know what would be awesome? If someone could make some part.cfg files to create single-port, surface-mountable IonRCS parts out of the Ion Engine models. I figure something like this: MODULE { name = ModuleRCSFX thrusterTransformName = RCSthruster thrusterPower = 0.5 runningEffectName = running flameoutEffectName = flameout engageEffectName = engage PROPELLANT { name = Xenon ratio = 1.0 } PROPELLANT { name = ElectricCharge ratio = 10.0 } atmosphereCurve { key = 0 5000 key = 1 100 } }

Updated 6/05/2014 0.3 - fixed bug where G and thrusterPower were not being used correctly (thanks NathanKell) Updated 4/25/2014 0.3 - now uses transform's position instead of part's position, so integral RCS on pods will work correctly. Updated 4/23/2014 0.2 - now includes useZaxis Updated 4/23/2014 0.1 - now properly turns of thruster effects when RCS is turned off. This is a pretty simple mod, which gives you RCS blocks with PROPELLANT {...} nodes and EFFECTS {...} nodes, so you can create Hall effect ion RCS, bipropellant RCS, anything you want - and then add sound and light effects. It also allows you to set 'useZaxis = true' to re-use thruster models as RCS models. Here's what a part.cfg looks like: PART { // --- general parameters --- name = RCSBlock module = Part author = NovaSilisko // --- asset parameters --- mesh = model.mu scale = 0.1 // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z node_attach = 0.45212, -0.0105571, -0.0059382, 1.0, 0.0, 0.0 // --- editor parameters --- TechRequired = fuelSystems entryCost = 3400 cost = 450 category = Control subcategory = 0 title = RV-105 RCS Thruster Block manufacturer = STEADLER Engineering Corps description = The recent discovery of a third law of physics made it possible for STEADLER Corps engineers to produce these small monopropellant thrusters, to help with attitude control and linear motion. Even though many Kerbal physicists still dispute the validity of this new law, studies show that the thrusters seem to work as advertised. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 0,1,0,0,0 // --- standard part parameters --- mass = 0.05 dragModelType = default maximum_drag = 0.001 minimum_drag = 0.001 angularDrag = 2 crashTolerance = 15 maxTemp = 3600 PhysicsSignificance = 1 // --- rcs module parameters --- MODULE { EFFECTS { running { AUDIO { channel = Ship clip = sound_rocket_mini volume = 0.0 0.0 volume = 1.0 0.2 pitch = 0.0 0.2 pitch = 1.0 1.0 loop = true } } 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 = 0.1 pitch = 2.0 loop = false } } } MODULE { name = ModuleRCSFX thrusterTransformName = RCSthruster thrusterPower = 1 runningEffectName = running flameoutEffectName = flameout engageEffectName = engage PROPELLANT { name = MonoPropellant ratio = 1.0 } atmosphereCurve { key = 0 260 key = 1 100 } } } Download from GitHub (includes source)

Because normally, either all the transforms are on, or none of them are. With RCS, different transforms are on based on which direction the RCS block is thrusting.

Excellent! Now as soon as I really grok EFFECTS and implement it into ModuleRCSFX, we're good to go EDIT: Oh, that's EASY. I think I've got it working! Bit of weirdness, though: since many RCS ports have multiple thrust transforms, you can use the EFFECTS block to define lights and sounds, but the actual sprays might need to be done the "old way".

really, the only mod this should effect is the RCSSounds mod, which will need to check for ModuleRCSFX in addition to ModuleRCS

That's actually precisely what I was intending to do, hence ModuleRCSFX. - propellant will be replaced with PROPELLANT {} nodes - EFFECTS system will be used

when you say it's non-derivatives, do you mean that ZRM won't allow others to modify and redistribute his? I.e., I have to rewrite it myself for a third time, because neither Squad nor ZRM will open their code?

Yup. Gonna do it. I'll send you a copy of ModuleRCSFX: ModuleRCS {...} when I'm done.

hrm. So I've been thinking really hard about how to do a Hall Effect RCS system, or really any generic bipropellant RCS. Is there a way to tell if an RCS thruster is currently firing?

hmm, looking at the math, I think kJ is the correct value. And yeah, 10 - 75 EC seems right for the engines (10 for the Squad engine and 75 for the KSPX one)