CaptainArbitrary

So I'm working on some mod engines, and in the process I build a sort of reference stack with an engine on the bottom, then a few small fuel tanks above it. I do some flight tests and all is well. I start working on my next engine, so I just pop the engine off that reference stack and replace it with a different engine … which I've set up using the exact same config parameters. You know, just to have someplace to start, right? It puts out exactly the same thrust, it has exactly the same heatProduction. It varies only in the specific impulse, because the new engine has a smaller nozzle than the other one so it gets less specific impulse at sea level for the same exhaust pressure. I do my first flight test, and … kaboom. It's not the engine that explodes, though. No, it's the propellant tank immediately above it. It exceeded its temperature tolerance. (I play with Deadly Reentry, so propellant tanks weaken when they get hot.) I figured out, after a hell of a lot of testing, that the difference between these two engines is their center of mass. Not mass itself; both of these engines have exactly the same mass, 'cause I set 'em up that way. No, the only difference is where their center of mass is, 'cause they're using different 3D models. Heat conduction in KSP depends on where your center of mass is. We all know how heat dissipation works; that's heat flowing out of your ship and into the environment (or vice versa) lowering (or raising) the temperature of each part independently. It's just Newton's law of cooling with a fixed cooling constant: ÃŽâ€T = (Tâ‚‘ – Tâ‚€) k where k is fixed, by the game, at 0.12 per second. That's an annoyingly inflexible approximation, but it works, so no biggie, we can work with it. But conduction is a different animal. You'd think that heat conduction between adjacent parts would depend on (a) the difference between their temperatures, ( some thermal properties of the parts, which might be approximated as a universal constant the way the cooling constant is, and © the surface area of contact between the parts. Since the game doesn't really do surface areas of contact, we can imagine abstracting that away such that, for sake of consistency, heat always flows between adjacent parts at a rate proportional to the difference between their temperatures. I mean, I'm not crazy, right? That makes sense to y'all too? The way it actually seems to work, though, is that conduction is somehow proportional to distance between parts … and not just distance, but distance between centers of mass. If the center of mass of two adjacent parts is close together, heat will flow between those two parts faster than if the centers of mass are farther apart. Even if the parts stay the same and you just move the CoM around. That's why my propellant tank exploded. Because the second engine I was modding had a higher center of mass in its 3D model than the first one did, heat flowed into the above tank faster. Too fast, in fact, for the tank to radiate the heat away, so it overheated and failed about twenty seconds after liftoff. Short of just arbitrarily dialing down the heatProduction parameter of that engine, I have no idea how to go about fixing this. I mean, in a sane world the heatProduction of an engine would depend on the engine itself, its thermodynamics and whatnot. But instead, it seems like we have to set it based on how we hope heat flows out of it as its running, which is a function of what it's attached to. Does anybody have any advice for me at all on this? Cause seriously, I'm this close to just changing all my heatProduction parameters to give my engines a full-throttle equilibrium temperature of boiling water.

Yes, it does. In point of fact, it works on any part that's got a ModuleEngines module on it. The way it works is this: At flight start, the plugin looks at every ModuleEngines module on the active vessel, and makes a note of the maxThrust parameter and the sea-level and vacuum Isps. Then it calculates, from the maxThrust and vacuum Isps, the maximum mass flow through the engine (dm = F / Isp g0). From then on, on every physics frame, it dynamically adjusts that engine's maxThrust parameter based on the static pressure of the atmosphere around the vessel. So, unless I've overlooked something (which I almost certainly have!) it should "just work" on every engine on every vessel, stock, modded, whatever.

Keeping with the spirit of "this is where I put all my little stuff that nobody would care about but me," I've added info about my Thrust Corrector plugin to the top post.

You can get it to be anywhere in that neighborhood, depending on which stock part you choose as your reference and what utilization factor you assume for it. But for me, the controlling factor is that if you peg the conversion factor at 5 liters to the "fuel unit," you get a utilization factor of around 85%, and also both the stock "LiquidFuel" and "Oxidizer" resources have exactly the same density as water. So I settled on 5 liters to the "fuel unit" last year sometime. I thought it was universally agreed upon, but maybe there's been new debate about it since that I didn't see.

Actually? Um … yes! I can, and did, do that thing. EDIT: I've removed the source code and download link to the little plugin I wrote, because I decided I'd done it wrong. I implemented it originally as a PartModule you had to apply through config-file editing to every engine, but it really works a lot better as an AddOn instead.

Not that I think this is necessarily your answer, but just in case … remember that due to the specific-impulse bug in the current version of the game, lighting up an engine with a low sea-level Isp while you've still got air around you will cause it to suck down propellant at an insane rate. The stock nuclear thermal rocket has a vacuum Isp of 800-something, but it has a sea-level Isp of only 200-something. What should happen (and one of the devs agreed that this is a bug in some other thread, but it hasn't been fixed yet) is that the engine should put out lower thrust if there's air around it. What does happen is that it puts out the maximum rated thrust, but goes bananas on your propellant tanks to make that happen. I've thought about trying to create a simple ModuleEngines subclass addon that would change this behavior, but a glance at the API suggests it wouldn't be super-trivial to do. All the fuel-consuming code is in one method that'd have to be overridden, and that's just more work than I've wanted to put into it. So maybe that's related to what you're seeing. Don't light up low-sea-level-impulse motors in the atmosphere, is the workaround right now, really.

Other way around. It's exactly 5 liters per unit of "fuel" in the stock game. Fixing that is always the first thing I do on a new install of the game.

These are the most beautiful things I've seen in a long, long time. I don't even need them, for the way I play, but I'm going to install them anyway because it'll please me to look at them. You even got the font right, man. I'm gobsmacked. There's one bit of bad news, though. No offense meant to anybody, but … um … next to these, the game's UI kinda looks like day-old dogfood. These are that pretty.

Okay, let's be a little fair here. The Shuttle and Buran were essentially the same thing, and neither was a "space plane" in any meaningful sense nor a single-stage-to-orbit vehicle. Buran (the one time it flew) went up on a two-stage Energia lifter, and the Shuttle was a traditional stage-and-a-half design used for manned flight since Project Mercury. Both went up like rockets, attaining altitude through thrust and not (insignificantly) through lift. The two Virgin Galactic things are suborbital, so they can't reasonably be said to count either …*and they're also not single-stage anythings, since both are ferried to altitude. If we're gonna use the term "space plane" in any meaningful way at all, we really need to agree on what it means. In this context  talking about reentry  it's obvious that it has to mean an orbital vehicle, since descending from high altitude but at suborbital speeds doesn't really count as reentry at all in this sense.

So I'm throwing my little Remission addon on here, because why not, I guess. Somebody might like it, if they play like I do.

Yeah, man, I know exactly what you mean. I hope my thing didn't come across as bitching. It was less frustrating and more "Huh, that's a weird one." Being a combination of how the ConfigNode structure works (I guess) and the fact that the game calls GetInfo() on each module in the order they appear in part.Modules, it was just a bizarre and pretty funny situation. Fortunately there's no functional problem here. As near as I can tell, everything works, as long as you don't do something stupid and make modules throw uncaught null-reference exceptions if they don't get initialized in just the right order (ahem). The only lingering effect is a cosmetic thing, which drives my OCD completely freaking bananas but which doesn't actually change the way the game works at all. Frankly, stuff like ModuleManager is kind of like what they say about the singing dog at the circus. It doesn't have to sing perfectly. The fact that it sings at all is really impressive.

Well, yeah, that would work …unless it's somebody else's ModuleManager config file that's screwing you up. As it was in this case; it was actually Deadly Reentry, not my own config file, that caused the original problem. I guess for the time being, at least, the workaround is to have a custom ModuleManager config file that touches every part where the order of part modules matters, as it does with engines. That's …*bleurg. I'm not loving that, but it'll work, I guess.

Oh, okay, my mistake. Sorry. In point of fact, it seems to anyway. I've got the problem conclusively narrowed down, I think. I created a whole new game folder (0.20.2, just for the record) and removed all the Squad parts except probeStackSmall, fuelTank, liquidEngine1 and liquidEngine2. Then I installed ModuleManager, just by copying the latest .dll file into my GameData directory. Then I threw a little debugger I wrote on the two engines; all it does is, during OnAwake, print out the names of the part modules attached to it. Here's the source code: using System; namespace ProjectArcturus { public class ArcturusDebugger : PartModule { public override void OnAwake () { base.OnAwake (); print ("*** Debugger.OnAwake() on " + this.part.name); print ("*** " + this.part.Modules.Count + " PartModules found"); foreach (PartModule m in this.part.Modules) { print ("*** " + m.ToString()); } } } } And here's the relevant output: [LOG 10:49:44.641] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine1/part/liquidEngine' [LOG 10:49:44.653] Added sound_rocket_hard to FXGroup running [LOG 10:49:44.655] Added sound_explosion_low to FXGroup flameout [LOG 10:49:44.659] *** Debugger.OnAwake() on liquidEngine [LOG 10:49:44.659] *** 0 PartModules found [LOG 10:49:44.680] *** Debugger.OnAwake() on liquidEngine(Clone) [LOG 10:49:44.681] *** 5 PartModules found [LOG 10:49:44.681] *** liquidEngine(Clone) (ProjectArcturus.ArcturusDebugger) [LOG 10:49:44.681] *** liquidEngine(Clone) (ModuleEngines) [LOG 10:49:44.681] *** liquidEngine(Clone) (ModuleJettison) [LOG 10:49:44.681] *** liquidEngine(Clone) (ModuleAnimateHeat) [LOG 10:49:44.681] *** liquidEngine(Clone) (ModuleAlternator) [LOG 10:49:44.688] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine2/part/liquidEngine2' [LOG 10:49:44.694] Added sound_rocket_hard to FXGroup running [LOG 10:49:44.694] Added sound_explosion_low to FXGroup flameout [LOG 10:49:44.696] *** Debugger.OnAwake() on liquidEngine2 [LOG 10:49:44.696] *** 0 PartModules found [LOG 10:49:44.712] *** Debugger.OnAwake() on liquidEngine2(Clone) [LOG 10:49:44.712] *** 6 PartModules found [LOG 10:49:44.712] *** liquidEngine2(Clone) (ProjectArcturus.ArcturusDebugger) [LOG 10:49:44.712] *** liquidEngine2(Clone) (ModuleEngines) [LOG 10:49:44.712] *** liquidEngine2(Clone) (ModuleJettison) [LOG 10:49:44.712] *** liquidEngine2(Clone) (ModuleGimbal) [LOG 10:49:44.713] *** liquidEngine2(Clone) (ModuleAnimateHeat) [LOG 10:49:44.713] *** liquidEngine2(Clone) (ModuleAlternator) As you can see, the order of part modules in the list is the same as the order in which they appear in the config file. Unsurprisingly, the VAB info GUI looks normal: Next, I put a test.cfg file in my GameData folder, to call ModuleManager. It just looks like this: @PART[liquidEngine] { @maxTemp = 1800 @MODULE[ModuleEngines] { @heatProduction = 200 } } @PART[liquidEngine2] { @maxTemp = 1800 @MODULE[ModuleEngines] { @heatProduction = 200 } } That should look familiar; you wrote it. It comes from Deadly Reentry. Here's the resulting debug log: [LOG 10:52:24.040] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine1/part/liquidEngine' [LOG 10:52:24.052] Added sound_rocket_hard to FXGroup running [LOG 10:52:24.055] Added sound_explosion_low to FXGroup flameout [LOG 10:52:24.058] *** Debugger.OnAwake() on liquidEngine [LOG 10:52:24.058] *** 0 PartModules found [LOG 10:52:24.079] *** Debugger.OnAwake() on liquidEngine(Clone) [LOG 10:52:24.079] *** 5 PartModules found [LOG 10:52:24.079] *** liquidEngine(Clone) (ProjectArcturus.ArcturusDebugger) [LOG 10:52:24.079] *** liquidEngine(Clone) (ModuleJettison) [LOG 10:52:24.079] *** liquidEngine(Clone) (ModuleAnimateHeat) [LOG 10:52:24.079] *** liquidEngine(Clone) (ModuleAlternator) [LOG 10:52:24.079] *** liquidEngine(Clone) (ModuleEngines) [LOG 10:52:24.086] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine2/part/liquidEngine2' [LOG 10:52:24.091] Added sound_rocket_hard to FXGroup running [LOG 10:52:24.091] Added sound_explosion_low to FXGroup flameout [LOG 10:52:24.093] *** Debugger.OnAwake() on liquidEngine2 [LOG 10:52:24.093] *** 0 PartModules found [LOG 10:52:24.109] *** Debugger.OnAwake() on liquidEngine2(Clone) [LOG 10:52:24.109] *** 6 PartModules found [LOG 10:52:24.109] *** liquidEngine2(Clone) (ProjectArcturus.ArcturusDebugger) [LOG 10:52:24.109] *** liquidEngine2(Clone) (ModuleJettison) [LOG 10:52:24.109] *** liquidEngine2(Clone) (ModuleGimbal) [LOG 10:52:24.109] *** liquidEngine2(Clone) (ModuleAnimateHeat) [LOG 10:52:24.109] *** liquidEngine2(Clone) (ModuleAlternator) [LOG 10:52:24.109] *** liquidEngine2(Clone) (ModuleEngines) Notice how ModuleEngines has gotten moved down to the bottom, where previously it came second (because it was second in the config files, after my debug module). You wouldn't think this matters, but here's what the VAB GUI looks like now: In order to generate the VAB GUI, apparently the game sends GetInfo() to each PartModule in the order they appear in part.Modules, so the result ends up in the wrong order if the order of the modules in the list gets rearranged. To test it just one step further, I changed my test.cfg file to look like this: @PART[liquidEngine] { @maxTemp = 1800 @MODULE[ModuleEngines] { @heatProduction = 200 } } @PART[liquidEngine2] { @maxTemp = 1800 @MODULE[ModuleGimbal] { @gimbalRange = 2 } @MODULE[ModuleEngines] { @heatProduction = 200 } } And here's the debug output: [LOG 10:55:47.334] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine1/part/liquidEngine' [LOG 10:55:47.346] Added sound_rocket_hard to FXGroup running [LOG 10:55:47.349] Added sound_explosion_low to FXGroup flameout [LOG 10:55:47.352] *** Debugger.OnAwake() on liquidEngine [LOG 10:55:47.352] *** 0 PartModules found [LOG 10:55:47.373] *** Debugger.OnAwake() on liquidEngine(Clone) [LOG 10:55:47.373] *** 5 PartModules found [LOG 10:55:47.374] *** liquidEngine(Clone) (ProjectArcturus.ArcturusDebugger) [LOG 10:55:47.374] *** liquidEngine(Clone) (ModuleJettison) [LOG 10:55:47.374] *** liquidEngine(Clone) (ModuleAnimateHeat) [LOG 10:55:47.374] *** liquidEngine(Clone) (ModuleAlternator) [LOG 10:55:47.374] *** liquidEngine(Clone) (ModuleEngines) [LOG 10:55:47.380] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine2/part/liquidEngine2' [LOG 10:55:47.386] Added sound_rocket_hard to FXGroup running [LOG 10:55:47.387] Added sound_explosion_low to FXGroup flameout [LOG 10:55:47.389] *** Debugger.OnAwake() on liquidEngine2 [LOG 10:55:47.389] *** 0 PartModules found [LOG 10:55:47.404] *** Debugger.OnAwake() on liquidEngine2(Clone) [LOG 10:55:47.404] *** 6 PartModules found [LOG 10:55:47.404] *** liquidEngine2(Clone) (ProjectArcturus.ArcturusDebugger) [LOG 10:55:47.404] *** liquidEngine2(Clone) (ModuleJettison) [LOG 10:55:47.404] *** liquidEngine2(Clone) (ModuleAnimateHeat) [LOG 10:55:47.404] *** liquidEngine2(Clone) (ModuleAlternator) [LOG 10:55:47.404] *** liquidEngine2(Clone) (ModuleGimbal) [LOG 10:55:47.404] *** liquidEngine2(Clone) (ModuleEngines) The part modules appear in the order in which they appeared in the config file, except for modules touched my ModuleManager. Those ones get appended to the end of the list, in the order in which they appear in the relevant .cfg file … is my guess.

I have the weirdest, and least helpful, bug report ever. Somehow it's possible for ModuleManager to screw up the order of PartModules attached to a part. Now, this description is gonna be wonky, because at the moment I'm working with a very hacked configuration. I was testing out some engine designs (through ModularEngines), so I had just two engines installed in my game: a modified version of liquidEngine1 (the LV-T30) and a modified version of liquidEngine2 (the LV-T45). What I noticed first is that in the VAB, the part info for liquidEngine2 was all screwed up; instead of being listed in the normal way, with the ModuleEngines info first and then other lines after, it was backwards, listing the info in the reverse order from what I have in my part.cfg. After two solid days of investigating, including writing my own debugging PartModule that does nothing but print out the names of the modules in this.part.Modules in order at OnAwake(), I discovered that on liquidEngine2  and only liquidEngine2  the part module order was getting screwed up sometime between OnLoad() and OnAwake(). Now, in this game directory I had just a few parts, but several core mods installed, 'cause it was a copy of my normal game directory. I had FAR and Deadly and RemoteTech and such like that … all of which call ModuleManager, so obviously I had a ModuleManager.dll in my game data folder too (the latest one, 1.3). In a fit of just-isolate-the-damn-problem I started by pulling ModuleManager.dll out … and poof. The problem went away. I glanced through the ModuleManager.cs source file (https://github.com/Ialdabaoth/ModuleManager/blob/master/moduleManager%20copy.cs) just long enough to see that it does include code that removes all modules from a part then re-adds them … but weirdly, that code doesn't seem to be called anywhere that I can see. The rest of the code involves game database features that I'm not familiar with, so I haven't studied it too closely to figure out where exactly the problem lies. For myself, I've disabled ModuleManager.dll just for the moment, so I can get on with what I'm doing. I'm hoping that even this unacceptably vague "bug report" (as if it deserves being called that) will be enough, since you're so familiar with the code, to make you go "Oh, yeah, I totally know what's going on there." But if not, I'll try to come back with more info once I get my current project squared away and get back to a not-entirely-insane game setup.

It doesn't, no. The basics of copyright law are universal, as established by international treaties.

I don't mean to be rude or anything, Entaran, but you would not believe how wrong you were just there. Copyright never "doesn't exist." It's automatic, always. Fair use is an affirmative defense, which means if you get sued you can claim your infringement of copyright was fair and ask not to be found liable by the courts. The scope of the fair-use defense is extremely narrow, and includes things like education and critique, most definitely not "but I said where I got it from so it's okay."

The new version is working well for me so far. I haven't really beat it up yet, but so far no complaints. Getting the Isp-reporting thing fixed is a real win, so thanks for that. I have a suggestion, though. In ModularEngines.cs, if you add a SetConfiguration call to the end of OnLoad, the module will apply whichever config is specified under "configuration" in the config file, if any, at load time, so it gets reported correctly in the VAB GUI. Specifically: ModularEngines.cs 292,294d291 < < if (!configuration.Equals("")) < SetConfiguration (configuration); This let me take my override file for the stock LV-T45 from this: @PART[liquidEngine2]:Final { @mass = 1.457 @MODULE[ModuleEngines] { @maxThrust = 200 @heatProduction = 200 @PROPELLANT[LiquidFuel] { @name = RP1 @ratio = 0.35 } @PROPELLANT[Oxidizer] { @name = LOX @ratio = 0.65 DrawGauge = True } @atmosphereCurve { @key,0 = 0 370 @key,1 = 1 300 } } MODULE { name = ModuleEngineConfigs configuration = RP1/LOX CONFIG { name = RP1/LOX thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 200 heatProduction = 200 fxOffset = 0, 0, 0.574338 PROPELLANT { name = RP1 ratio = 0.35 DrawGauge = True } PROPELLANT { name = LOX ratio = 0.65 DrawGauge = True } atmosphereCurve { key = 0 370 key = 1 300 } } CONFIG { name = LH2/LOX thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 200 heatProduction = 200 fxOffset = 0, 0, 0.574338 PROPELLANT { name = LH2 ratio = 0.73 DrawGauge = True } PROPELLANT { name = LOX ratio = 0.27 DrawGauge = True } atmosphereCurve { key = 0 420 key = 1 365 } } } } down to this: @PART[liquidEngine2]:Final { @mass = 1.457 MODULE { name = ModuleEngineConfigs configuration = RP1/LOX CONFIG { name = RP1/LOX thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 200 heatProduction = 200 fxOffset = 0, 0, 0.574338 PROPELLANT { name = RP1 ratio = 0.35 DrawGauge = True } PROPELLANT { name = LOX ratio = 0.65 DrawGauge = True } atmosphereCurve { key = 0 370 key = 1 300 } } CONFIG { name = LH2/LOX thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 200 heatProduction = 200 fxOffset = 0, 0, 0.574338 PROPELLANT { name = LH2 ratio = 0.73 DrawGauge = True } PROPELLANT { name = LOX ratio = 0.27 DrawGauge = True } atmosphereCurve { key = 0 420 key = 1 365 } } } }

So here's a thing. I just had a satellite blow up on ascent. The flight logger said it exceeded its g-tolerance, but some investigation revealed that it was taking heat damage at the time. The ascent profile was too aggressive, and the part heated up to about 510°C from friction with the air. With a max temp of only 600°C on that part, it weakened and finally failed. Which is all well and good …*except the satellite was enclosed in a payload fairing at the time, one of the fairings from KW Rocketry. Shouldn't payload fairings shield parts from shockwave heating? Or are the KW fairings built in such a way that your raycast method isn't detecting them?

I'm using Modular Fuel System with my own set of hand-rolled config files. Sorry, probably should've disabled those for the screenshots.

Important disclaimer: I'm not really a modder. I made these addons for myself, and I'm releasing them just to share them. I'm not good at providing support. If something doesn't work for you, I'm very sorry. I'll help if I can, but I can't promise to fix or improve anything. All the source code is available. Anybody's free to take it and do whatever they want with it. Go nuts. Thrust Corrector 1.1 Download Thrust Corrector 1.1 Download Thrust Corrector 1.1 Source Code Y'know how engines in KSP have different specific impulses at sea level and in vacuum? That's because some of the thrust of a real rocket engine comes from the difference in pressure between the exhaust and the ambient air. No ambient air means more pressure thrust, and a higher specific impulse. A higher specific impulse means you get more thrust for the same propellant. Lower specific impulse means less thrust for the same propellant. Except that's not how it works in KSP. In KSP, you always get the same thrust out of your engine at 100% throttle. It's just that at sea level, where your Isp is lower, your engine sucks down more propellant per second to achieve that thrust. That's always bugged the heck out of me. I know, it's not a big deal, but it bugs me, it's bugged others, and at least one developer has suggested that it might be fairly considered a bug that deserves fixing. Rather than wait around for a very low-priority fix to make it into a future release, I just decided (based on a suggestion from Wolfling) to fix it myself, with an addon. Thrust Corrector is just a little plugin that dynamically changes the maximum rated thrust of every engine based on the current atmospheric conditions. That means the rate at which your engine consumes propellant at 100% thrust will be constant, but the maximum thrust the engine puts out will vary with altitude. In a vacuum, you'll get the rated maximum thrust, as defined in the config file. At sea level, you'll get the thrust you should get at your engine's maximum fuel flow, based on the sea-level Isp defined in the config file. In the screen shot above, you can see a static test of the LV-T30 engine from the stock game. The T30 has a rated maximum thrust of 215 kilonewtons, and a vacuum specific impulse of 370 seconds. That means at 100% throttle, the engine will consume about 59.25 kilograms per second of propellant/oxidizer mix. Its sea-level Isp is 320 seconds, and 320 seconds times 59.25 kilograms per second times g₀ gives you 185.95 kilonewtons of thrust. In the unmodded game, the T30 will still give you 215 kilonewtons of thrust on the launch pad; it'll just consume more than its maximum fuel pumping capacity to do it. But with my plugin installed, in static testing the T30 develops 186.4 kilonewtons of thrust on the launch pad at its maximum fuel-flow rate of 59.17 kilos per second of fuel mix. It performs slightly better on the pad than predicted because the pad is slightly above sea level. Cool, huh? You might notice the discrepency between the predicted fuel mixture flow rate of 59.25 kilos per second and the rate reported by the game of 59.17 kilos per second. There's a simple explanation for that: The game is wrong. Specific impulse is defined as the thrust developed by an engine per unit of weight of reactant; that's why it's F / dm g₀; the factor of g₀ is there to convert units of reactant mass to units of reactant weight. The constant g₀, which defines the newton as a unit of force, is fixed at exactly 9.80665 m/s², which is based on but not equal to or dependent on the average acceleration of gravity on the surface of the Earth. To convert kilograms to newtons, the game should multiply by 9.80665 … but ModuleEngines multiplies by 9.82 instead. So all the numbers end up being slightly wrong. Which is actually kind of fun, because it the results you see in the game slightly different from predictions, just like always happens in real life. Remission 1.0 Download Remission 1.0 Download Remission 1.0 Source Code The "rename vessel" functionality added in 0.18 (or whenever it was) is fantastic. No more having to hack the persistence file every time we want to launch the same saved ship twice as different missions! Only trouble is, "rename vessel" is something you have to do. You have to remember to hit the little button. And with it buried down in a right-click menu off an occasionally-hard-to-target command pod part, it's not really as convenient as it could be. That's where Remission comes in. Remission is a tiny little addon that automatically prompts you to rename your ship every time you take it to the launch pad. Say goodbye to the annoyance of ending up with three "Comsat 1" missions because you forgot to rename them; say hello to the annoyance of being prompted every time you launch a rocket! Range Safety 1.0 More pictures Download Range Safety 1.0 Download Range Safety 1.0 Source Code There've been a few range-safety and self-destruct addons released over the years, most notably TAC Self Destruct. They've all been really cool, but none worked exactly how I wanted. So I made my own. When activated, this system detonates your spacecraft. Your whole spacecraft, piece by piece. When it's done, there's no debris left over; your whole vessel essentially evaporates.* How do I install it? Start by downloading it. Install as usual, copying the ProjectArcturus folder to your GameData folder. If you have Module Manager installed already, you're done, basically. All the stock probe cores will have a range safety device installed on them the next time you start the game. (Not including cores on vessels that are already in flight in your save file.) If you don't have Module Manager, go download it, 'cause it's awesome … or else you can add the range safety device PartModule to whatever parts you like by hand. Pick a part somewhere in your GameData folder and edit its configuration file. Add the following lines to it somewhere between the opening "PART {" bit and the last "}": MODULE { name = ArcturusRSD } Then just make sure whatever part you modified is on your ship. How do I use it? Just hit the abort key. By default, that's the backspace/delete key on your keyboard; you can also activating it by hitting the on-screen button to the left of the altimeter. The range safety device(s) on your rocket add themselves to the abort action group automatically, so you never have to worry about sending a rocket to the launchpad with an unarmed self-destruct aboard. However, you do have to remember to remove any range safety devices from the abort action group if you don't want them to go off during an abort sequence. So there's that. Which brings up an important thing to remember: You can kill your crew with this. The range-safety system doesn't care whether you have live Kerbals aboard your spacecraft. If you hit the abort switch, they will be incinerated. The system isn't installed on crewed parts by default, but if you're using the tried-and-true "use a probe core to make your spent stages controllable" trick, be aware that fiery, terrifying death is just one button-press away. I wanna know more! Feel free to ask, or download the source code and have a peek under the hood. * Note that this only applies to parts that are actually attached to your vessel when you activate the range-safety system. Anything that's disconnected, like spent stages you've already jettisoned, are technically separate vessels, and aren't detonated automatically when you use this system.

There really isn't anything to show a picture of here … unless it's a picture of a config file.

Oh! I see what you mean. The method I described gives you the "right" answer, in that it gives you exactly what you asked for … but what you asked for in the method I described didn't add up to what you really wanted. Duh. I totally should've thought of that. My blind spot is that I've been thinking in terms of pretty simplistic tank construction, with either common or separate bulkheads that give an overall utilization fraction that's true of both bipropellants. It didn't occur to me that somebody might want to specify different utilizations for each of the two biprops. So of course, doing it your way is way better. Thanks for explaining.

This is one of those things I didn't know I needed until I saw it, and now I can't imagine not having it. Thank you so much.

Really? Darn. I must have missed something when I was doing the arithmetic. Sorry about that. I should've pounded on it more before posting my suggestion. In any case, regarding the other changes you're going to make, thank you so much. That's awesome, and I'm really looking forward to what comes next. Your mods are on my relatively short list of won't-play-without.

I might be able to corroborate this. I've seen similar things a couple times on 2.2f  things not burning up when I expected them to  but I haven't investigated it until now. I was just deorbiting the upper stage of a GTO mission that failed to make its trajectory. It was a 1.25-meter upper stage with a KW fairing decoupler on it, and above that a satellite with no temperature tolerance to speak of. (I set my "fragile" parts to have maxTemps of 600°C, which is about where aluminum starts getting weak on you.) This time, during atmosphere interface, I turned on DR debugging and took screenshots. Note that the vessel was coming in retrograde, engine first. Here's what I saw: Note that DR thinks the engine is shielded from the shockwave. It's not, obviously. Also: This extending antenna (from the AIES part pack) is also showing as shielded from the shockwave. That might be behaving-as-expected, because I think the collider on the part is way smaller than the part looks in its extended state. But it's still counterintuitive. Under 10,000 meters, aerodynamic effects (note that I'm running FAR) flipped my vehicle over so it was falling right-side-up. As you can see, DR does not think the dish is shielded. It does still think the engine is, though, which is reasonable considering the vessel's attitude. Short version? However DR figures out that a part is shielded from the shockwave isn't working 100% reliably, is my guess. So sometimes reentry heating doesn't happen when it really should.