CaptainArbitrary

At standard temperature and pressure. Xenon propellant is stored in a supercritical state at around 1450 psia, which would have a density of around 0.538 kilos per liter. Because the game doesn't. The game requires that densities be specified in metric tons per volume unit, where the stock volume unit is arbitrary (and incredibly wrong). It's possible to do a total conversion of all volumetric units over to liters, which I've done in my game, but it's a huge pain in the butt, and you're still locked in to using metric tons per liter in the resource config file.

The broad strokes of the thing really aren't that complicated, to be honest. Conceptually, a rocket engine is somewhat less complex than the engine in a car. The actual engineering of the thing is far more complicated, of course, but as far as the overall big-idea aspect of the thing, rocket engines are really not that complex. Cold thing goes in, hot thing comes out, and the interesting stuff revolves around how you make the cold thing hot.

It's really hard to imagine how you'd do that with a chemical rocket. Not only are the pumping systems completely different for different kinds of propellants, but also the combustion chamber and nozzle have to be designed completely differently. For instance, a typical RP1/LOX rocket engine might have a chamber pressure of 75 atmospheres while a typical LH2-burning engine would have a chamber pressure of 200 atmospheres or more.

Because the specific impulse of LH2/LOX is on the order of 30% higher than the specific impulse of RP1/LOX or RP1/N2O4. You get more thrust per unit of weight of propellant if you're using LH2/LOX. The trick to exploiting this, though, is to not do what you did. You compared two rockets with the same propellant volume. Instead, compare rockets with the same propellant mass. Since LH2 is so much lighter than RP1, you need a much bigger tank to carry an appropriate propellant mass. But that's okay, because that much bigger tank of LH2 will end up being lighter than the smaller tank of RP1, because you need less propellant mass if you're using LH2, because the specific impulse is higher. To really get an intuitive grasp of how liquid hydrogen works in the real world, look at things like the Space Shuttle external tank and the Delta IV common booster core. They're both bloody enormous, but because they're filled with mostly liquid hydrogen, they're very lightweight for their size, and make very efficient rockets. It's stupid, yeah, but not quite as stupid as you might think. One of the virtues of a thermal rocket is that you can use anything as reaction mass. The chemical properties of your reaction mass don't matter, because you're not reacting them chemically. If you want, you can use plain water as reaction mass in a thermal rocket, and get perfectly acceptable results. What is very stupid, though, is pumping "liquid fuel" and "oxidizer" through a thermal rocket and getting an Isp in the 800s. In a thermal rocket (whether it be nuclear or any other kind) the exhaust velocity of your reaction mass goes by the square root of the exhaust's enthalpy. At NERVA temperatures and pressures, pure hydrogen has an enthalpy of nearly 40,000 kilojoules per kilogram, giving it an exhaust velocity of over 8,500 meters per second! That's where the sky-high Isps in the 800s come from. When you pump through other fluids, you get lower exhaust velocities. Pumping pure water through a NERVA-type engine, for instance, would give you an Isp in the 200s, if I remember right. Which frankly isn't that bad when you consider that you're using water.

Believe it or not, the stock NERVA's sea-level Isp is far higher than it should be. I know you know this already, Scott, but for others: The reason rocket engines have different specific impulses at sea level and in vacuum is because of something called pressure thrust. Everybody knows this equation already: F = dm ve + (Pe – Pa) Ae. The thrust an engine develops is the sum of two components: the momentum thrust (mass flow times exhaust velocity) and the pressure thrust (difference between the exhaust pressure and the ambient pressure times the area of the nozzle exit). The first term is constant for a given throttle setting. But the second term varies depending on where you are. At sea level, the pressure term is generally going to be negative, because the exhaust is expanded to a lower pressure than ambient pressure. The result is less thrust at sea level, and a lower specific impulse. I ran the numbers for the LV-N engine, as it's modeled in the game. It's got a nozzle exit diameter of 80 centimeters, and given its nature we can safely assume it's designed to work at altitudes above 30 kilometers. That makes the pressure thrust at sea level just a hair over –50 kilonewtons. And remember that in a vacuum the LV-N only develops 60 kilonewtons! That means it should develop less than 10 kilonewtons at 100% throttle on the launchpad, and have a sea-level specific impulse of only 123 seconds. (For the geeks like me: If we assume the LV-N exhaust pressure is 0.0025 atm, indicating an operating altitude of 30 kilometers above Kerbin sea level, we get a pressure thrust in vacuum of 0.0025 atm times the area of the nozzle exit, or 0.126247 kN. So the momentum thrust is 60 kilonewtons minus that number, or 59.8738 kilonewtons. Solving F = dm Isp g₀ with that value for F and the vacuum Isp of 800 seconds, we get a mass flow rate through the engine of 7.63178 kilograms per second. At sea level, the total thrust is the momentum thrust plus the difference between ambient pressure and the exhaust pressure times the area of the nozzle exit. The pressure thrust term at sea level, then, is –50.8053 kilonewtons, making the total thrust at sea level 9.19475 kN. Solving F = dm Isp g₀ again with that F and the mass flow rate we calculated before gives us a sea-level Isp of 122.855 seconds.) As for the thrust, though, you're absolutely right. The stock NERVA engine has a throat diameter of 20 centimeters (measured off the 3D model), which is fricking enormous. In order to have the exhaust flow reach the speed of sound at the nozzle throat, the mass flow rate out the nozzle needs to be a mind-boggling 639.075 kilograms per second (assuming NERVA-like chamber temperature and pressure of 2360°K and 30 atm). That comes out to a thrust of 5,598.1 kilonewtons … which is actually not unrealistic for a NERVA-type engine of those dimensions and specifications. It's just that that kind of thrust is completely bonkers for KSP. So the developers arbitrarily set the thrust very low for, as you said, reasons of gameplay. (On a personal note, Scott, I have absolutely devoured your Reusable Space Program series, and eagerly await future installments. Thanks so much for making it.)

That's for confirming that. My plans for modding Kethane to do vaguely-realistic in situ resource utilization are going to have to change. It's disappointing, but hey, new challenge.

This is correct. Since I don't use anything like that in my game, it never occurred to me to check for it in the plugin.

I have what feels like a stupid question. I've skimmed the thread, but at 182 pages so far, it's a bit much. Is it possible to have a kethane converter output multiple resources simultaneously? For example  since this is what I'm trying to do  have it take one unit of water and convert it to 0.9 units of oxygen and 0.1 units of hydrogen? Everything I've seen (including looking at the source code) suggests this isn't something the mod presently does, but I figured it couldn't hurt to ask in case there was an undocumented interface for it or something.

That'd be terrific. The only quibble I have about the mod is that the bases are a little clunky-looking. I really like the look of the KW fairing bases. They look like they were built to be as lightweight as possible, because you know, space. But I couldn't make a 3D model if you paid me (I know; people have tried), so I'm the last person to complain about that kind of thing.

The time-honored trick of telling MechJeb to keep your acceleration at terminal velocity through the ascent isn't really a very good practice, to be honest. See, the optimal ascent trajectory (in terms of delta v expended) is a zero-lift turn, which means your angle of attack is always zero. Put another way, your rocket's nose is pointed straight at the prograde marker on the navball at all times, throughout the ascent. If you're burning such that your rocket is at terminal velocity during the early part of your ascent, you're going to end up burning way too hard. Sure, you'll save some delta v that would otherwise be lost to gravity drag, but you'll pay for it in delta v spent pushing your rocket in a direction other than along your ascent path. So the best strategy for FAR, in my opinion, is to use MechJeb's acceleration limiter and experiment with ascent trajectories. The kinds of rockets I build tend, as a rule, to get very close to a zero-lift profile when I limit MechJeb to 18 meters per second, start turning at 500 meters, finish turning at 40 kilometers, and set the curve parameter to 60%. I got there empirically, by trying different strategies with the same rocket and dialing it in to the point where varying any parameter significantly cost me delta v. I could optimize things further, but I'm happy with where I ended up, so I'm sticking with it.

I'm running OS X.

Not in my game. In my game it works as one would expect. But I do tend to just keep the fairings and the first-stage interstage in the same … um … stage. The first stage burns out, then the interstage fires and the fairings jettison simultaneously. Works a treat.

I must be doing something obviously wrong, but I can't figure out what. This addon simply does not work in my game. It loads the DLL: Load(Assembly): SubassemblyManager/SubassemblyManager AssemblyLoader: Loading assembly at [redacted]/KSP_osx/GameData/SubassemblyManager/SubassemblyManager.dll Non platform assembly: [redacted]/KSP_osx/GameData/SubassemblyManager/SubassemblyManager.dll (this message is harmless) But it simply never instantiates the addon. There's no reference to it after that in the log file at all. No exceptions, no nothing. Any idea what could be going wrong? I'm stumped.

Actually I think it might slow things down. It might be a coincidence or something else going on, but I'm getting significantly worse performance now. I'm in the middle of my first reentry with FAR 0.9.5.2, and I'm dropping frames like mad, whereas before things weren't so severe. Not entirely sure how to isolate the cause, though, short of reverting to 0.9.5.1 and flying this mission again.

The procedural-fairings change certainly seems to work. I've got a vehicle on the way up right now, and the fairings are working perfectly. However, did you leave some debugging code in? Every part is showing me Cl, Cd and Cm in the right-click menu all the time.