Northstar1989

That's, ummm, an extremely high Thrust rating for the Specific Impulse, to put it lightly... How much power is that receiving again? The context-menu in your screenshot says it's producing over 60 kN for a mere 30 MW of actual power received... Can the menu be trusted? Remember that a thermal rocket only produces around 0.3-0.2 kN/MW at 850-1000 seconds ISP in real life (depending on nozzle expansion-ratio among other things...) and a real fission-fragment rocket operates at millions of seconds ISP but only a few newtons of Thrust at most... Regards, Northstar

Regex, the values I suggested were based on realism considerations. You don't store cryogenics at their boiling-point in real life, you store them at substantially colder temperatures to reduce evaporation and increase density (see the Wikipedia article on Liquid hydrogen, for instance- you store at at 20 K even though it boils as 33 K in order to prevent it from rapidly evaporating...) Cryogenic densities are often listed at boiling-point simply for convenience: because the temperature will tend to stall at that point while additional heat-input goes into overcoming the Enthalpy of Vaporization- making the precise temperature+density combination easier to measure... And the density of 187.07 kg/m3 is for LOX in liquid form at its boiling-point. Once it actually boils its density falls to around 4 kg/m3. Also, why do you insist on treating me as if I have no place in this discussion? I have just as much right to be here as you do- I help develop KSP-Interstellar Extended in the same way that you help develop RealFuels. I'm newer at modding to be sure, but I've definitively taken the leap from "player" to "modder" and and am learning all I can to make myself more capable and useful in this regard... Indeed. Liquid Ammonia is a resource also used by KSP-Interstellar. And a rather important one for the mod at that (it is used for Thermal Rocekts, Electric Thrusters, and ISRU production of Monopropellant- to name just its most important uses...) Which is why I suggest we actually go with a density at least equal to its density at -40 C (the ambient temperature in Low Earth/Kerbin Orbit), as we already use densities for other resources that are not equal to their densities at their boiling-points (LOX, for example. As I pointed out before, Liquid Oxygen reaches densities of less than 200 kg/m3 before it officially boils...) - - - Updated - - - Sounds like quite an exciting way to fly. Regards, Northstar

Because at the time I wasn't aware of the fact that graphene could be nano-engineered to achieve meta-material properties of thermal emissivities higher than 1.6 So it was a comparison between a thermal emissivity of 0.99 and 0.90-0.95, and ultimately he didn't feel it made a big enough difference to simulate... That would work. I look forward to seeing it! Indeed. I think there is meant to be some room for safety and durability with the Molybedenum radiators, as well as to create more of a distinction with the upgraded version, which is why the basic radiators only operate to a bit less than 1700 K in-game (just like you made the Particle Bed Reactors only operate at 2500 K when the real life version operates at 3000 K), but Tungsten alloys could certainly provide an intermediate performance. Maybe they could operate at up to 2100 K... Regards, Northstar

Regex, that density is too low even for Ammonia at boiling-point. The density at boiling-point is 682.78 kg/m3, not 681.9 kg/m3. But, once again, the ambient temperature of Low Earth Orbit is -40 C. The ambient temperature of deep space is below -80 C (colder than the freezing-point of Ammonia, so you're already going to want to heat it to keep it liquid- but preferably as little as possible...) The boiling-point of other cryogenics you would want to store it alongside is much lower still (-182.96 C for LOX, for example). Why would you ever want to store Ammonia at -34 C when you could get a higher density and reduce heating-requirements by storing in at -40 or -50 C? Using the density at -34 C instead of the density at -40 C (which I posted here) makes even less sense from an immersion perspective because when you right-click on a fuel tank in the context menu, it normally shows an ambient temperature of -40 C in Low Kerbin Orbit, and a fuel tank temperature to match. You would need to implement some sort of active-heating module for Ammonia storage in order for using the temperature at -34 C to be realistic- and why would you ever do that when it would just be extra mass/complexity in order to reduce the density of a resource and increase its rate of boil-off? If a convention doesn't make sense, abandon it. As long as there are notes in the CRP document as to the temperature and pressure we assumed for the resource, it should make sense to future modders. Also, if you change all cryogenics to their boiling point, you would need to reduce the density of LOX from the currently-used 1141.00 kg/m3 to 187.07 kg/m3 (the density of LOX at 1 atm and -183 C, yeah LOX density declines extremely rapidly as you approach its boiling-point). Are you sure you want to stick with using the boiling-point of cryogenics at 1 atm pressure? (don't forget, boiling-point goes up at higher pressures) That's an enormous (almost 10-fold) nerf to the density of LOX from what you've previously been using in RealFuels if you stick with that... Regards, Northstar - - - Updated - - - Also, speaking of the most practical/sensible densities for different resources, the density of LH2 needs to be increased to 70.99 kg/m3 from 70.85 kg/m3 (the density at 20 K - according to Wikipedia you need to cool it to at least 20 K to prevent rapid evaporation, even if the triple-point is 33 K).

Centralization. Economies of scale. The relative costs of transport vs. processing/refining. Good stuff like that. In KSP (with 1.0), I expect similar dynamics to emerge- you should have to figure out whether it's worth the time and cost to land a refinery right there with your extractor, or whether you're better off leaving the refinery in orbit. Obviously the permanence of the outpost or length of the mission come into play- if you're just swinging by Dres for a quick visit you probably don't want to land a refinery there, whereas the Mun/Minmus or even Duna/Ike might become a major center of operations for your space program where your rockets stop to refuel on the way to Jool and other locations further out (Gas Planet 2 anyone?) Regards, Northstar

Hi RoverDude, Without de-railing the conversation too much, a quick pull- I was wondering if I could recruit you to produce some resource-conversion reactions for ISRU with KSP-Interstellar Extended and Regolith? I've been thinking about the best way to implement some of these reactions- and after seeing first-hand what a headache ORS code for ISRU can be (even if it can do some rather cool stuff, it's mind-numbingly complicated) I was thinking Regolith might actually be the best direction to turn to for some of these new ISRU reactions- especially as they will be purely resource-to-resource conversions (rather than extraction reactions) and thus shouldn't need to interact directly with any of the ORS-based ISRU code already in KSP-Interstellar... Specifically, the reactions are to produce RealFuels propellants out of certain resources that can easily be harvested with KSP-Interstellar equipment. These are: MMH, UDMH, and Aerozine- from Hydrazine and Methane (a production-reaction for Monopropellant already exists in KSP-Interstellar that is based on Hydrazine chemistry). These are useful hypergolic fuels when combusted with NTO (N2O4) in hypergolic rocket-engines in RealFuels. MMH is just Hydrazine plus one methyl-group (CH3- so you will end up producing some H2 as a by-product), and UDMH Hydrazine plus two methyl-groups. Aerozine is typically either a 50/50 or 25/75 mixture of MMH and UDMH, respectively. Kerosene- from Carbon Dioxide and Hydrogen (Carbon Monoxide is an inferred intermediate for the Fischer-Tropsch Process, but not one we have a resource for yet- speaking of which, could we get that in CRP? I'm planning on adding a CO/O2 chemical rocket to KSP-Interstellar Extended just as soon as I can find the time to write up a config for it and find a model- to allow players to simulate certain real mission plans that would operate such a rocket on Mars to hop around on rough terrain using locally-derived CO and O2 for propellant...) NTO (N2O4) - from Nitrogen and Oxygen obtained via ISRU. Is a useful oxidizer with MMH/UDMH/Aerozine for hypergolic rockets in RealFuels... I wasn't planning to bother with actually creating resources for the catalysts or co-reagents for any of these reactions: as long as something isn't consumed by the reaction we can just assume it to be part of the KSP-Interstellar ISRU Refinery part where I would want all these reactions to take place (although if necessary I suppose they could also take place in a Karbonite-derived converter part). All of these reactions are physically possible, and in the case of Kerosene production we already have a reaction (the Fischer-Tropsch Process) that has received significant investigation recently for its potential ISRU applications on Mars... Regards, Northstar P.S. PM me if you're interested and don't want to discuss this in public. And I'm sorry I offended you before with your treatment on Regolith- I didn't give it due credit when I was discussing it before, and I apologize for that.

A bit more about thermal emissivity since that whole paragraph may have been confusing (and unclear as to its relevance) without some background... All bodies emit thermal energy as radiation via the Stefan-Boltzmann Law. This law, in its idealized form, says that the thermal-radiance of any body can be described as follows: Thermal Radiance = Constant of Proportionality * (Absolute Temperature)4 As such, this is the law that Fractal_UK based heat-radiator performance off of (and why a small difference in the temperature of a reactor makes an enormous difference in the effectiveness of its heat radiators). The "Constant of Proportionality" is just a physical constant that relates the magnitude of thermal radiance to the magnitude of temperature, by the way, and relatively unimportant for the rest of this explanation... However, the actual equation in practice, rather than its idealized form, is a bit more complicated than the idealized form above: Thermal Radiance = EMISSIVITY * Constant of Proportionality * (Absolute Temperature)4 Notice the term "emissivity" above? (which I have taken the liberty of writing in capital letters to add emphasis). This is a number between 0 and 1 for all standard materials (nano-engineering allows one to overcome the limitations of this range, as I'll get to in a second) that modifies the absolute magnitude of thermal radiation of a body based on how "black" a body is. Any body with a thermal emissivity between 0 and 1 is thus known as a "grey body", and this encompasses most known materials in the universe, including anything you would normally make a heat radiator out of without nano-engineering... (Note the white and light-colored materials have low thermal emissivity, whereas dark-colored materials have high thermal emissivity. Thus while dark-colored materials absorb thermal radiation more readily, they also give it off much more readily as well...) As I said, Fractal_UK assumes a thermal emissivity of somewhere between 0.90 and 0.95 for both the "Mo Li" and Graphene thermal radiators in KSP-Interstellar... This is fine for the "Mo Li" radiators, which can be assumed to be made out of standard materials, but what about graphene? Well graphene, as it turns out, is an amazing material. Through the wonders of nano-engineering we have been able to create graphene with thermal emissivity exceeding 0.99, and in fact with thermal emissivity quite a lot greater than 1- that is graphene that is blacker than perfect black. This is known as "hyper-conductive" or "hyper-emissive" graphene. See for instance the following scientific article, for which if I do say the title is very apt and fitting: "Beyond Stefan-Boltzmann Law: Thermal Hyper-Conductivity" This is accomplished through Metamaterials- materials typically created via nano-engineering that have properties not yet found anywhere in nature... Nano-Engineered Graphene is just one example of such a meta-material, and not coincidentally, we already have a tech node in KSP called "MetaMaterials", which can obviously be concluded is referring in the name to the technology to create precisely these kinds of materials... So, if meta-materials are already a thing that Kerbals clearly can come to understand (as it has a tech-node in KSP), and graphene radiators are already a thing in KSP-Interstellar, then why exactly can't we put two and two together and give graphene radiators meta-material properties? What I suggest is the following: provide Graphene Radiators with a proportional boost to their thermal radiance at a given temperature of approximately 60-75% (easily within the range of what can be achieved in terms of improved emissivity with nano-engineered graphene). This should be in addition to, and in no way replace, the higher heat-tolerance of graphene that enables these radiators to operate up to potentially higher temperatures and is another beneficial feature of graphene in real life... Regards, Northstar - - - Updated - - - 60-75% higher emissivity may seem outrageous, but see this article where the authors achieved thermal emissivity of 1.6 (that's 68.42% higher than a thermal emissivity of 0.95, and 77.78% higher than a thermal emissivity of 0.90, which is the range of emissivity that Fractal_UK said he assumes the "Mo Li" radiators fall within) with "biased" graphene made to have higher thermal emissivity than 1... Thermal Infrared Emission from Biased Graphene The really astounding thing about that article is that the authors didn't do anything particularly outrageous- this is just one article in a huge pile of other articles with similar results for nano-engineering graphene to provide meta-material properties of extremely high thermal emissivity and temperature tolerances... Regards, Northstar

KSPI Extended has a realistic density of Water, with the definition drawn from Community Resource Pack (an older version, not the newer consensus-version being worked on) of 1000/ kg/m3 (this value will remain the same in the newer CRP, by the way). TAC Life Support has an absolutely arbitrary density for water- which is surprising considering that the density of water was one of the measurements the metric system was founded on in the first place (to the degree that a kilogram is defined as the mass of 1 liter of water). So under absolutely no circumstances whatsoever should the TACLS density-definition of water be used- instead I strongly recommend modding TAC Life Support so that it will use the Community Resource Pack definition of water now rather than later when 1.0 comes out (the new CRP will only be implemented for TAC Life Support and many other mods after 1.0) Regards, Northstar - - - Updated - - - OK, also, the TweakScale version of the Particle Bed Reactors still don't seem to be up to snuff... FreeThinker, didn't you say you were going to use a reactor core temperature of 2750 Kelvin? The Timberwind Reactors on which they are based operated at 3000 K, and we had already come to an agreement to use a compromise value of 2750 K for balance... 2750 K is 10% hotter than 2500 K, and as heat-radiation is to the fourth-power of radiator temperature, this makes a BIG difference in the efficiency of electric generators and required mass of radiators... Did you end up using a ISPMultiplier for the Thermal Rockets such that you felt it necessary to reduce the reactor temperatures versus what we decided on before or something? If so, it's worth considering that the effect of that is that the reactors require quite a bit more radiator mass when not running in open-cycle mode (that is, when not pumping their ThermalPower into the propellant stream of a Thermal Rocket), thus effectively posing a significant penalty to nuclear electric propulsion when using Particle Bed Reactors... Of course, maybe that was your intention all along (Molten Salt Reactors sill have the 3200 K operating temperature we decided on- so they are unaffected), I just wanted to make sure you were aware of the effects on nuclear-electric propulsion and Microwave Beamed Power, etc... Also, did you fix TweakScale being unable to recognize when players have upgraded heat radiators and defaulting to the "Mo Li" version rather than graphene-radiators? Last I checked this was still an issue- which means you end up needing even more radiator mass for your Gas Core Reactors... (which operate hot enough to benefit from the radiator upgrades, and don't have their ThermalPower adversely affected by temperature to the degree that you need such a large amount of radiator mass as that you never benefit from the higher maximum temperature of the radiators regardless like with Dusty Plasma and Particle Bed reactors...) One last but major note about Graphene radiators- they are currently too weak compared to real life. I discussed this with Fractal_UK, but back then I didn't have the science I did now... Currently, radiators are based on an assumed thermal emissivity of approximately 0.90-0.95, according to a conversation I had with Fractal_UK a while back. Which is great, except that one of the advantages of graphene, besides being able to operate at higher temperatures than other materials (hence the higher radiator temperature-limit in KSP-I) is that it has a thermal emissivity that can reach 0.99, or even, with nano-engineered "biased emissivity" actually EXCEED a thermal emissivity of 1.0 (which is the value for a theoretically perfect blackbody). See, for instance, this scientific article by an MIT researcher who looks into using such nano-engineered Graphene for improved thermoelectric systems (which research, more likely than not, would be used in space programs- as this is the only place where such expensive nano-engineering of Graphene is really worth the extra cost and effort for the improved performance...) http://www.mit.edu/~soljacic/near-field-TPV_OE.pdf Regards, Northstar

As I've stated, that won't be necessary- very soon TACLS will be going in on the Community Resource Pack consensus-resources, and RealFuels will be adding Water as a native resource then to my understanding... If you try to define the same resource twice, with different densities, bad things will happen. Both TACLS and KSP-I Extended each have their own resource-definitions for Water- which is precisely the kind of thing CRP aims to solve... Yes, one radial water tank is native to KSP-I. It's not very useful for most designs though. Regards, Northstar

Option 1 would prevent anyone using RealFuels and KSP-I Extended, but not TACLS, from storing Water in their RealFuels tanks. As for Water being Water, unfortunately that's not currently the case. Different mods have different definitions for Water and other resources- which is what Community Resource Pack is currently trying to fix by coming to consensus values for the resource densities and costs... Regards, Northstar

SpaceHungryMan, I might consider looking for mod-conflicts. I am currently running KSP-Intestellar Extended and RealFuels together without this issue (although I am running RealFuels 8.3). However if your code solves the issue, and others are experiencing the same issue, I can't see why not to use it... TACLS and NFT aren't part of RealFuels. They will be going in on CRP, but that hasn't been finalized yet. So, there shouldn't be any reason a RealFuels config can't add these resources to RealFuels tanks- the tank definitions do not include any data on the resources they contain except the name. Thus, there should be no conflict with adding these resources to RealFuels tanks (although KSP-Interstellar should have compatibility issues even loading up in the first place if another mod has identically-named resources with different densities/costs... Any naming conflicts with TACLS and NFT will also become moot when the next CRP is out anyways (as we will have a communal Water and CarbonDioxide resource). Regards, Northstar - - - Updated - - - On an entirely different note- the plasma thrusters aren't working anymore... Besides displaying an ISP of "0" or "infinity" in the VAB and not giving a Delta-V readout with the Kerbal Engineer sub-module of MechJeb, now they say they're propellant-deprived even when they have plenty of propellant available... Regards, Northstar

Well first I need to know what your intentions were for each line of code... What does this mean, first of all? What is it there for? What is it supposed to do? Does "_current_power" represent the currently available power-levels or the amount available relative to the needs of the reaction? And what does "rate_multiplier" indicate? Does "rate_multiplier" indicate the rate the reaction proceeds at relative to the amount of power consumed? (where higher "rate_multiplier" indicates a faster reaction) The more energy-hungry the reaction the slower it is going to proceed at a given amount of available power. The faster the reaction's inherent progress the faster it will proceed for a given amount of power. Where is the term for the amount of electricity available for the reaction in the first place though? If this is what "_current_power" indicates, then it should be *completely* unrelated to the power requirements or rate_multiplier of the reaction and should be derived solely from the reactor/solar panel capacities and other energy-demands of the ship where this is all taking place... This one makes a lot more sense. Reaction rate (what I assume "_current_rate" indicates) should indeed be proportional to the available power levels ( is this what "CurrentPower" means? How does this relate to "_current_power" from before?) and inversely-proportional to the power-requirements per ton of the reaction. This is where the "rate_multiplier" should factor in though- the available power on the ship should be completely unaffected by a reaction's rate-multiplier, but rate for a given reaction should of course be affected by it... So, the above two equations should probably look more like the following: CurrentPower = reactor_capacity - Other_PowerRequirements and _current_rate = rate_multiplier * CurrentPower / PluginHelper.HaberProcessEnergyPerTon You'll notice I assumed "_current_power" and "CurrentPower" were the same thing (why have two terms with confusingly similar names?), and made up two terms to reflect the reactor capacity on the ship and other power-requirements on this ship... It doesn't make sense to ignore other power-draws on the ship when calculating available power-levels (like you appeared to do earlier) and even less sense to calculate the available power-levels in terms of the inherent rate (the rate-multiplier) of a chemical reaction: two terms that should be completely independent of each other... Please see where I clarified this is my last post. The nitrogen-fraction of ammonia is always equal to 1 minus the nitrogen-fraction of hydrogen (and vise-versa) so there is absolutely no need for the "double" modifier here (it is completely inappropriate to be doubling, halving, etc. anything in this calculation) ammoniaNitrogenFractionByMass = (1 - GameConstants.ammoniaHydrogenFractionByMass) The above accurately describes the relationship of the two. Why is nitrogen-fraction not also a GameConstant though? Like ammonia's hydrogen-fraction it never changes... Or, does "double" refer to double floating-point accuracy in the calculation (in which case nothing needs to be changed). What do these terms even mean? The current rate of what, exactly? If it's the current rate the Haber Process is proceeding at, it's completely inaccurate. These would be calculated one of two ways depending on whether rates are in terms of volume or mass (please see my post earlier- I asked a lot of questions that would have helped with teasing apart this code...) If the rates are already mass-rates, then the following equations apply: hydrogen_rate = _current_rate * GameConstants.ammoniaHydrogenFractionByMass nitrogen_rate = _current_rate * ammoniaNitrogenFractionByMass Once again, no multiplication of either value is required. Or, did the "double" term refer to using double floating-point accuracy of the equation? In which case what you had before was fine... OK, so back to the question I asked before: are rates given in terms of volume or mass-rates? Either way, if I'm reading this equation correctly, you multiply by a TimeWarp-factor only to divide it right back out, and divide by hydrogen_density only to multiply it back in. What's with that? It means the current equation is just a much more complicated way of writing: _hydrogen_consumption_rate = _part.RequestResource(InterstellarResourcesConfiguration.Instance.Hydrogen, hydrogen_rate) Whatever that even means... You're going to have to explain what this whole "InterstellarResourcesConfiguration.Instance" bit means if you want me (or most anyone else) to help you better... Will analyze the rest of the code in a little bit. Need to take a bathroom-break and grab some food right now... Regards, Northstar

I'm glad you liked them. Regards, Northstar

OK, I'm not sure I understand any of this or why it's coded the way it is... What does "double nitrogen_rate_to_add_t" mean, first of all? Specifically, is the rate in terms of Liters/second or in terms of mass-rate (kg/s, tons/s, etc.)? And why are you solving for "double nitrogen_rate_to_add_t" when it looks like you should be solving for "ammonia_rate_to_add_t" instead? Wouldn't it make the most sense just to add Ammonia (the Haber Process is N2 + 3 H2 --> 2 NH3) at the mass-rate nitrogen is consumed divided by the mass-fraction of nitrogen in ammonia (82.242%) as follows: Ammonia_rate_to_add_t = nitrogen_rate_t / GameConstants.ammoniaNitrogenFractionByMass Or, barring that (if "nitrogen_rate_t" isn't currently a function) then just do it in terms of hydrogen-consumption like such: Ammonia_rate_to_add_t = hydrogen_rate_t / GameConstants.ammoniaHydrogenFractionByMass If "nitrogen_rate_t", "hydrogen_rate_t", and "Ammonia_rate_to_add_t" (if that last one is a valid function) are in terms of Liters/second (as 1 unit = 1 Liter) instead of mass-rate (kg/second, tons/second, etc.), then simply compensate for the density-ratio of the two resources and use one of the following equations: Ammonia_rate_to_add_t = (nitrogen_rate_t * density_nitrogen) / (GameConstants.ammoniaNitrogenFractionByMass * density_ammonia) Ammonia_rate_to_add_t = (hydrogen_rate_t * density_hydrogen) / (GameConstants.ammoniaHydrogenFractionByMass * density_ammonia) FreeThinker, the second equation you posted is overly-complicated. For example, it calculates GameConstants.ammoniaHydrogenFractionByMass by subtracting GameConstants.ammoniaNitrogenFractionByMass from 1, instead of just using GameConstants.ammoniaHydrogenFractionByMass directly. Regards, Northstar

Sounds good to me. The following corrections still need to be made: - LqdCO2 should be listed as used by KSP-Interstellar and RealFuels. Currently it is only listed for BioMass... - "Alumnia" is mis-spelled. It should read "Alumina", and is an intermediate resource in electrolysis of Munar/Ike regolith in KSP-Interstellar. - The density of Liquid Methane is too low. At 1 atmosphere and -161.68 C (its boiling point is a little less than -161.5 C), the highest temperature for which the Peace Software Thermodynamics Calculator I've been using will give me a liquid-phase density, the density is already 424.0175 kg/m3, not the 422.62 kg/m3 which is currently used. However it would likely be stored at a colder temperature to increase its density. At -180 C (still warmer than Liquid Oxygen's boiling point of -183 C) liquid methane has a density of 448.25 kg/m3. Since one major use for Methane is to burn it with LOX, it's quite likely that you would want to store it as a similar temperature to increase its density and minimize heat-leakage from the methane tanks into nearby LOX tanks... - What temperature is the density of LOX supposed to be based on? According to the Peace Software Thermodynamics Calculator at a pressure of 25 psia (approximately 1.7 atm, and the density NathanKell said the Saturn V LOX tanks were at) and a temperature of -198.4 C you get a density of 1141.75 kg/m3, which is close enough for comfort to the density of 1141.00 kg/m3 currently being used. However at 1 atm and -196 C the density is only 979.25 kg/m3, and a 1 atm and -200 C the density is 1223.00 kg/m3. The density of LOX is highly sensitive to even a few degrees of temperature-increase, so the current density of 1141.00 kg/m3 for LOX might be a little optimistic... - The current density of LqdAmmonia in the working document is far too low. What's more, I don't even know where it comes from. The density in the release of CRP included in the latest KSP-Interstellar 0.90 port is 681 kg/m3, but the density included in the current working-document is 604.00 kg/m3. Neither density is high enough. The ambient temperature of LEO is around -40 C, and deep space is -80 C or less (the freezing point of ammonia is -77.73 C, so in deep space you actually face the amusing problem of needing to heat the ammonia to keep it liquid, or thaw it before use...) so you're clearly not going to be storing it any warmer than -40 C. At -40 C and 1 atm the density is 690.2 kg/m3 according to the Peace Software Thermodynamics Calculator, and at -50 C and 1 atm (the lowest temperature the calculator will go for Ammonia, but probably still warmer than you'd want to be storing it) the density is 702.1 kg/m3. Even at -34 C and 1 atm, just below its boiling-point, Ammonia has a density of 682.78 kg/m3, which is higher than either the old or new density for it in CRP... NOTE: I provide multiple links to the Peace Software Thermodynamics Calculator because it has different pages for different molecules. Here is the english-language home page from which you can access the different molecule calculators (note that there are some typos in the spellings, such as of Oxygen, as the software was originally written in German- which I do know how to read- but the calculations yield numbers, which will be the same regardless of the language used...) Regards, Northstar

OOC: Oooh, you guys really aren't going to like this next one (I know I don't...) Northstar Kerman woke up sweating from another dream. "What is it with all these nightmares lately?" he thought. "I've got a speech this morning trying to get the space program re-instated, and now I'm up at 0400 drenched in sweat, and unable to get images of a giant squid out of my mind". Indeed Northstar Kerman had a terrible dream. In it, he had launched a glorious new space program starting with a return mission to the Mun when, out of nowhere, a giant squid-like creature everyone kept calling the "Kraken" appeared out of nowhere and devoured all the program's vessels in orbit... "Good thing we haven't begun the program yet" though Northstar. "Better go and prepare for that speech..." Later that morning Northstar Kerman did indeed make his third and final glorious speech arguing in favor of the Kerbal Congress proposal to re-instate the space program... Some of your have asked, what will be the benefit of these future colonies to Kerbals here on Kerbin? It's too expensive to ship materials from Duna back to Kerbin you say- and you are correct. Taxation, you insist, has little meaning and no sustainability if these colonies can provide no useful services to obtain this money that can't be more easily provided back at home- and that is true, although there will always be some services (such as software-development) where Dunan firms could someday sell their goods alongside local ones in markets here on Kerbin. What then can they provide? I answer your question with one word- knowledge. Knowledge not just of the solar system and the stars, but of the very nature of life- for if Duna should harbor life of its own, we will gain a great deal of insight into life here on our own planet from studying it. Knowledge not just of Dunan atmospheric chemistry, atmospherics, and geology- but a better understanding of how these processes work here on Kerbin. And, all the entrapments of civilization that are of benefit to improve no matter where we live... A Cure for Cancer has eluded our scientists for decades, but has a greater chance of being discovered by the combined scientific prowess of the greatest minds of two planets- rather than just one. A new hardy perennial version of an annual crop that never requires replanting and can survive on less water will be useful for farmers and agriculutral scientists struggling to raise crops in greenhouses in Duna's low-temperature, low-light, low-water conditions: but a handful of seeds of this new cultivar shipped back to Kerbin will be just as useful for farmers struggling to raise crops on the edge of the tundras and deserts here on Kerbin. A solution to the problems of high-energy physics and nuclear engineering that have held us back from developing practical fusion power and improved fission reactors for decades will solve our energy-crisis here on Kerbin just the same as fusion-rockets will ease interplanetary travel and improved fission reactors will better provide power-hungry Duna colonies with the electricity they need to grow and thrive. Many scientists on Kerbin have acquired the foul taint of becoming ivory-tower intellectuals who care little for the public good here on Kerbin, but on Duna practical results-driven science and engineering will not just be an ideal, it will be necessary just to survive. Someday, the benefits of this knowledge here on Kerbin will exceed our wildest dreams. OOC: Yeah... You read that right- the Kraken came and ate all my vessels in orbit. Something about updating TweakScale or Procedural Parts didn't sit well with the FAR aerodynamics module, and even after reverting both back to the previous versions (1.5.1 and 1.0.0) all my vessels continued to lose the majority of their parts upon loading (nothing but probe cores and solar panels remained- and even these would usually spontaneously explode upon physics loading...) So, I'm going to have to launch my Munar-1 mission all over again, although this time a set of edits I made (and then reverted, and then made again) to Procedural Parts to relax the tech-limits to generally match what is possible with NovaPunch2 or stock (whichever is more permissive) at a given tech-level means that I can likely carry out the mission with fewer, heavier launches... My primary crew members will be dead until re-spawn, though, due to the termination of their vessel (loading the LEM/CSM up crashes the game), so I might have to carry out some minor contracts (like a bunch of seismic scan contracts near the KSC I've been accumulating in preparation for a rover mission) in the meantime... As a side-note, technically this means I am no longer playing with the standard version of Procedural Parts. But the tech-limits for RealFuels tanks there had not been changed since before the Asteroid Redirect Mission update, and did not reflect what was available with mods at all (the comments indicated it was balancing against the Rockomax-64 being the largest fuel tank available at a tech level where stock 3.75 meter parts and NovaPunch2 5 meter parts would normally be available, for instance). The effect was that I could have 3.75-meter engines available, but not be able to build fuel tanks wider than 3 meters (not even 3.75 meters), which frankly I found ridiculous. So, I created a more reasonable tech-limits config file (the limits disappear at MetaMaterials anyways...) and posted it on the Procedural Parts thread as a new suggested standard for the RealFuels tank tech-limits... More launches (or takeoffs, or roll-offs) to come soon. Regards, Northstar

But what about impurities? The stuff on the poles is dry ice snow- so it must contain dust particles it originally nucleated around, and it might be covered in some dust that settled there... It might still be necessary to have a refinery of some sort there to remove impurities... Beside, you need the dry ice to at least be ground into a finely-powdered form if you're going to gassify it in a controlled manner for your engines: the stuff on the poles is likely clumped together like snow gets when it sits out for a few weeks... (from small amounts of melting and re-freezing, or sublimation and immediate re-condensation in the case of dry ice...) Regards, Northstar

@FreeThinker Hey, just a thought, but I noticed here and there you added yourself as an author on some of the new tweakable-parts like the following: PART { name = DustyPlasma module = Part author = AAristisan & Fractal & FreeThinker I was wondering if you couldn't add me in as an author on some of these parts since I helped come up with the balance (and research on real designs/theory behind the balance) for some of them? It would be advisable to remove the "&" symbols anyways, as it would make it harder to find such symbols that might be messing up the actual code (where they are now considered readable characters) in the future. So, I suggest something like this instead: PART { name = DustyPlasma module = Part author = AAristisan, Fractal, FreeThinker, Northstar1989 Notice that I took the liberty of adding my name to the end of the authors list after yours? Regards, Northstar

Here is the original config: MODULE { name = ProceduralPart costPerkL = 0.00957 TECHLIMIT { // FL-200 - 1.25 x 1.1105 m = 1.363 kL name = start diameterMin = 1.0 diameterMax = 1.5 lengthMin = 1.0 lengthMax = 1.5 volumeMin = 1.0 volumeMax = 1.5 } TECHLIMIT { // FL-T400 - 1.25 x 1.87819 m = 2.305 kL // FL-T100 - 1.25 x 0.78125 m = 0.959 kL name = basicRocketry lengthMin = 0.5 lengthMax = 2.0 volumeMin = 0.7 volumeMax = 2.5 } TECHLIMIT { // FL-T800 - 1.25 x 3.75 m = 4.602 kL name = advRocketry lengthMax = 4.0 volumeMax = 5.0 } TECHLIMIT { // X200-16 - 2.5 x 1.875 m = 9.204 kL name = heavyRocketry diameterMax = 3.0 volumeMax = 10.0 } TECHLIMIT { // X200-32 - 2.5 x 3.75 m = 18.408 kL name = heavierRocketry volumeMax = 20.0 } TECHLIMIT { // Jumbo-64 - 2.5 x 7.5 m = 36.816 kL name = veryHeavyRocketry lengthMax = 8 volumeMax = 40.0 } TECHLIMIT { // Not in main sequence. Depends indirectly off basicRocketry only // X200-8 - 2.5 x 0.9375 m = 4.602 kL name = advConstruction diameterMax = 3.0 volumeMax = 5.0 } TECHLIMIT { // Not in main sequence. Depends indirectly off basicRocketry // Oscar-B - 0.625 x 0.3485474 m = 0.107 kL name = precisionEngineering diameterMin = 0.125 lengthMin = 0.125 volumeMin = 0.0625 } TECHLIMIT { // Make everything unlimited for metaMaterials name = metaMaterials diameterMin = 0.01 diameterMax = Infinity lengthMin = 0.01 lengthMax = Infinity volumeMin = 0.01 volumeMax = Infinity } } Here is config re-balanced to not disadvantage players who use Procedural Parts instead of stock/mod fuel tanks (fuel tank size-limits are adjusted to at least match sizes available with stock fuel tanks at a given node, and often to match the looser limits of NovaPunch2 or KW Rocketry instead, since players like myself delete those fuel tanks as well to save RAM...) Note the comments to explain each limit. Some of the 2.5 meter stock parts became available earlier in the tech tree than the original file indicated, in 0.23.5 with the introduction of SLS parts- so the outdated tech limits must have dated to before SLS parts were added in 0.23.5 MODULE { name = ProceduralPart costPerkL = 0.00957 TECHLIMIT { // FL-200 - 1.25 x 1.1105 m = 1.363 kL // NovaPunch2 2-meter 1.25-meter tanks tech here name = start diameterMin = 1.0 diameterMax = 1.5 lengthMin = 1.0 lengthMax = 2.0 volumeMin = 1.0 volumeMax = 2.5 } TECHLIMIT { // FL-T400 - 1.25 x 1.87819 m = 2.305 kL // FL-T100 - 1.25 x 0.78125 m = 0.959 kL // NovaPunch2 4-meter 1.25-meter tanks tech here name = basicRocketry lengthMin = 0.5 lengthMax = 4.0 volumeMin = 0.7 volumeMax = 5.0 } TECHLIMIT { // FL-T800 - 1.25 x 3.75 m = 4.602 kL // First NovaPunch2 2.5-meter parts tech here name = advRocketry diameterMax = 3.0 lengthMax = 4.0 volumeMax = 16.0 } TECHLIMIT { // X200-32 - 2.5 x 3.75 m = 18.408 kL // Most NovaPunch2 2.5-meter parts tech here name = heavyRocketry lengthMax = 6.0 volumeMax = 32.0 } TECHLIMIT { // Jumbo-64 - 2.5 x 7.5 m = 36.816 kL // NovaPunch2 3.75-meter parts tech here (72 kL) name = heavierRocketry diameterMax = 4.0 lengthMax = 8 volumeMax = 64.0 } TECHLIMIT { // Stock S3-14400 tanks available here (>80 kL) // NovaPunch2 5-meter parts tech here (>128 kL) name = veryHeavyRocketry diameterMax = 5.0 volumeMax = 128.0 } TECHLIMIT { // Not in main sequence. Depends indirectly off basicRocketry only // X200-8 - 2.5 x 0.9375 m = 4.602 kL name = advConstruction diameterMax = 3.0 volumeMax = 6.0 } TECHLIMIT { // Not in main sequence. Depends indirectly off basicRocketry // Oscar-B - 0.625 x 0.3485474 m = 0.107 kL name = precisionEngineering diameterMin = 0.125 lengthMin = 0.125 volumeMin = 0.0625 } TECHLIMIT { // Make everything unlimited for metaMaterials name = metaMaterials diameterMin = 0.01 diameterMax = Infinity lengthMin = 0.01 lengthMax = Infinity volumeMin = 0.01 volumeMax = Infinity } } Also, I hope it's not a problem for me to suggest, but I'd love to be put on the author list for the config if you're willing to use my changes // --- general parameters --- name = proceduralTankRealFuels module = Part author = AncientGammoner, NathanKell, Swamp Ig, Northstar1989 I usually went with the looser limit when NovaPunch2 parts exceeded the size/length of stock parts available at that tech node, and always stuck with the convention of using whole-meter diameter limits (so 3.0 meters when 2.5 meter parts are unlocked, 4.0 meters when 3.75 meter parts are unlocked, and 5.0 meters when 5-meter parts are unlocked), however at HeavierRocketry I decided to make the volume-limit 64 kL even though >72 kL parts are available in NovaPunch2 at this point, as it allowed a nice 16--> 32--> 64 --> 128 kL progression of volume limits as you climbed the tech tree... Regards, Northstar

Sounds great to me. I outlined what needs to be done in a bit more detail in the last paragraph of this post. Basically, you should always be able to build to at least the same height, diameter, or total volume as what you can achieve with stock or common mod (NP2 or KW Rocketry) tanks. The only tech-tree changes I know of were to the unmanned guidance systems (probe cores). They shouldn't affect fuel tanks at all. Not if the volume and height-limits are also configured correctly. You still end up having to stack a bunch of short 3.75 meter tanks on top of one another if your volume-limit is low but you're allowed 3.75 meter tanks, for instance... Besides, most players upgrade the VAB fairly quickly (unless you're silly/insane like me), so part-count limits aren't really a big deal. Players usually install Procedural Parts specifically to bring down their part-counts, anyways (I know I do). The size-limitations of the launchpad are much more important- and for this diameter limits are critical, since you usually bump up against height-limits long before any others (even mass-limits you can easily get around in RealFuels by using the fuel pumps built into the launch-clamps... Which is not an issue, as most players using RealFuels aslo use Real Solar System and need the heavier rockets at the same tech-level anyways...) I'll suggest some more reasonable size-limits for each tech node currently used to control Procedural Parts sizes in my next post... I have enough of a vested interest in making sure these limits do not disadvantage (or unfairly advantage) players who install Procedural Parts and delete all their fuel tank parts myself, since I fit into this category... Regards, Northstar

Just making a realism-point... Anyways, now that we've take a look at Electric thrusters, thermal thrusters, reactors, node sizes, warp drives, Propulsive Fluid Accumulators, and resource-densities; can we move on to improving the ISRU reaction repertoire? We still need a way to perform the Sabatier Reaction outside an atmosphere. Or to isolate Oxygen directly from the atmosphere of Duna via Solid Oxide CO2-Electrolysis (SOCE, which is CO2 --> C + O2) or Reverse Water Gas Shift Reaction (CO2 + H2 --> CO + H2O), which is how they would get O2 (for life-support and to burn with Sabatier Reaction methane) in real life on Mars (as the Sabatier Reaction requires a Hydrogen feedstock and produces more Methane than you can burn with the O2 you get out of it...) It would also be nice if we could have the ISRU refineries produce Hydrazine (N2H4) instead of Monopropellant when "Module RCSFX" (the RealFuels RCS module) is installed, and be able to produce hypergolic propellants like NTO (N2O4) or MMH (Hydrazine with a -CH3 group tacked on to replace one Hydrogen atom) with RealFuels and access to Nitrogen, Oxygen, and Methane... Every major propellant-combo (HydroLOX, Meth/LOX, Kero/LOX, or hypergolic) can be produced via ISRU on Mars/Duna (Nitrogen is 1.9% of the Martian atmosphere and can be collected locally, or can alternatively be shipped from LEO/LKO Earth/Kerbin Propulsive Fluid Accumulators). Even Kerosene can be produced via ISRU (using the Fischer-Tropsch Cycle: CO + H2 --> CnH2n+2 + H2O) if you have access to Carbon Monoxide (a product of the Reverse Water Gas Shift Reaction, CO2 + H2 --> CO + H2O) and Hydrogen... Regards, Northstar

Assuming you're using FAR (as was already suggested- you're punishing yourself without it), your problem appears to be that you lack pitch control. Just looking at your plane, I can visually tell this is the problem. All your elevators are located on the lagging surface of the wings- very close to the Center of Mass. You want your control surfaces to ideally be as far from the Center of Mass as possible in order to maximize control-authority. I wouldn't suggest removing those control surfaces- they're actually well-positioned to make great flaps or spoilers (they're close to the Center of Mass and Center of Lift, so they won't significantly destabilize your pitch-moment while being used to increase or decrease lift). But if you want to actually control your plane's Angle of Attack, you need to place control-surfaces oriented to control pitch on either the very front or the very rear of your aircraft. I suggest the front (canards) because they will be less likely to cause the tail to rip off at excessively high dynamic pressures there, and will shift your Center of Mass slightly forward (the canards have mass, after all). But if you want an airplane that looks more like a commercial airliner, place the elevators on the tail instead... Regards, Northstar

I just pause the game and press the spacebar a few times when I get that itch. It seems to do wonders for getting it out of my system... Regards, Northstar

Updated this to include mention of Karbonite as a possible ISRU solution. If any players notice anything else I missed or that has changed since I originally wrote this back in February 2014 and expanded it in May/July 2014, feel free to let me know! Regards, Northstar

Oddible, Are you using FAR or stock aerodynamics? If you're still using stock aerodynamics, I suggest installing FAR and forgetting everything you know about optimal gravity-turns. Gravity-turns should be performed much sooner in FAR, and become limited by how aerodynamically stable your rocket is (try to turn too fast and you'll spin out of control). Ideal TWR (to minimize Delta-V to orbit) also becomes much higher when you get rid of the unrealistic stock soup-o-sphere... Stock aero is getting replaced with a more realistic and FAR-like aero model in 1.0, so I strongly suggest getting used to realistic aerodynamics now before SQUAD forces you to do so... Who knows, you might even like FAR better, since in a few ways it looks like FAR will actually be easier than stock aero (it has body-lift, which will be absent from the new stock aero AFAIK, for instance...) Regards, Northstar