Northstar1989

I don't want LqdWater added to a specific tank- I'm want it added to the list of fuels that can be included in *ALL* tanks- but only when KSP-Interstellar is installed. And yes, I know it would be through ModuleManager. Saying that isn't giving me any useful information. HOW would I actually go about doing it through ModuleManager? What files what I (or somebody more capable of coding than me) need to patch so that it shows up on the modular fuels list when KSP-Interstellar is installed? Patching just specific tanks WON'T accomplish what is necessary/desired here... Also, it appears the base RealFuels mod missed the K1 Heavy Lifter fuel tanks from NovaPunch- they still only hold LFO: Since these are the first seriously-large 2.5 meter tanks available in my tech progression, it's kind of annoying to be unable to use them... Regards, Northstar

A few new mods I've installed that felt significant enough to be worth mentioning. First of all, there's RealFuels mod. NathanKell just released a new update of it that adds all sorts of deadly-toxic fuels that were actually considered during the Cold War era thanks to their superior performance characteristics... Should be fun. Also, I've been working quite ardently to try and get a better RealFuels/KSP-Interstellar integration config out. So far, I've come up with a few lines of code myself, and got another player involved in writing more to fix whatever other issues he can identify (as well as ones I pointed out to him- like the inability to store LqdWater resource in the RealFuels modular fuel tanks; or the inaccurately-low ISP of the Interstellar Meth/LOX engine compared to its real-life analog currently in-development: the Space-X "Raptor"). Still, more players with some experience using either KSP-Interstellar or RealFuels mod (or especially, both), and preferably with some understanding of how to roll configs would be appreciated. Message Dreadicon if you're interested in helping... Second, I installed Procedural Parts, Procedural Fairings, and NovaPunch2. So expect MUCH bigger rockets in the not-too-distant future. Finally, Flight Manager for Reusable Stages makes a comeback in this Career playthrough. It's worked out a few of its bugs/issues since previous versions, and although not half as necessary this time around (while not using Real Solar System), it's still a nice utility that makes Space-X style reusable stage *much* easier, if I want to bother with them (something that was *HIGHLY* necessary to keep down costs with RSS 6.4x, but is not nearly as vital now without it...) I was tempted to start over with RSS 6.4x again, now that it and so many of the mods that make it playable are up-to-date, but decided against it: I intend to rely *heavily* on Microwave Beamed Power in this save, and would require exponentially more of it to accomplish the same goals with RSS installed (due to the larger Delta-V requirements for almost any missions in turn necessitating higher thrust on my spacecraft and launch platforms). In real life, they can do things like build a single MASSIVE beamed-power array, and make 300 launches a year to amortize its cost: but I don't have that kind of time in my playthroughs of KSP... Regards, Northstar

Eeek, it appears the code patches I made and posted here were *already* outdated for RealFuels 8.0 by the time I re-posted them here! Apparently, NathanKell decided to change the name of the LiquidOxygen resource again for some reason, and so now it needs to read "LqdOxygen" instead of "LiquidOxygen" in the patch I posted here earlier... So here's the updated version: @BASIC_NTR_PROPELLANT[Methalox] { @guiName = Methalox @PROPELLANT[LqdMethane] { @ratio = 0.443 } @PROPELLANT[Oxidizer] { @name = LqdOxygen @ratio = 0.557 @DrawGauge = False } } @BASIC_NTR_PROPELLANT[Ammonia] { @guiName = Ammonia @PROPELLANT[Ammonia] { @name = LqdAmmonia } } @PART[FNAmmoniaTank] { MODULE { name = ModuleFuelTanks volume = 10731 type = Default } } Also, how would one go about adding another resource (such as "LqdWater") to the list of resources that can be added to a tank through the modular fuel tanks part of RealFuels? Specifically, how would one go about doing that so a resource only shows up *when a particular mod in installed* (such as KSP-Interstellar). THAT'S the tricky part... LqdWater is a resource that is needed in large amounts with KSP-Interstellar and RealFuels installed, so the single tiny dedicated radial tank that normally comes with KSP-Interstellar is not nearly enough storage (normally, you immediately want to electrolyze LqdWater into LiquidFuel/Oxygen, but with RealFuels installed the LqdHydrogen and LqdOxygen you produce would immediately begin to slowly boil-off, so you want to keep things in water form as long a possible...) It needs to be stored in large amounts, so it can be electrolyzed at will to produce fuel for maneuvers, rather than immediately out of necessity... Regards, Northstar

Let me start off by saying that I highly respect the great deal of work you do for KSP modding, and the input you have on most forum threads- but there's no reason to roll eyes at me... I've got to make sure it's seen by all the related parties. In this case, it's perfectly appropriate- as the other places this is cross-posted are the base RealFuels thread (only AFTER the code changes were first introduced here, and as they didn't come to NathanKell's attention from this post), and in the "Stockalike" engine config for RealFuels- due solely to the fact that you seemed to think it more appropriate for ISP/TWR changes to the Meth/LOX engine to be included in the engine config than in the base mod... First of all, creating a separate config that applies a MM patch to the same part could create potential issues, could it not? Thus, it would seem to me that whatever lines on code were created to address this issue should best be integrated into the same config file as the MM changes to the resources consumed by the Meth/LOX engine... Now I can see two potential fixes to this problem... The first, is that the engine ISP/TWR fixes simply be integrated into the same RealFuels/KSP-Interstellar integration config already present in the base RealFuels install that changes the resources consumed by this (and a number of other) engines. Then, if any engine config wanted to change the engine values further (say to scale the engine up to Realism Overhaul scale with one of the two scaled-up engine configs), they would release a version of the KSP-I integration config that overwrote the one in the base install. The second, is that the engine ISP/TWR fixes be left out of the base RealFuels install, but the fixes/changes I already came up with be included (the modular fuel tank fix for the Ammonia tank and the additional NTR fuel mixes I provide MM patches for here- which are in exactly the same spirit as the fixes in the config already in the base RealFuels install: of simply causing existing Interstellar fuel-modes to use RealFuels resources and density-adjusted ratios rather than the Interstellar resources being replaced in the fuel tanks and such...) as well as any similar changes that myself or Dreadicon come up with before the integration config is revised (or in second revisions later, if this is done quickly). But any ISP/TWR changes to the Interstellar Meth/LOX engine myself/Dreadicon come up with be left out, and those be included in an alternate version of the integration config for the "Stockalike" engines config that would then have to overwrite the base RealFuels integration config when installed. Either solution will require some instance of re-writing, and require at least *some* of the engine configs to check that they're not overwriting a more updated base-config with a more out-of-date engine config in the future, when further changes might be made to the base config by other people. But the first solution at least ensures that thhe "Stockalike" config doesn't need to do this- and honestly, I doubt many/any players using the "Real Engines" or "Reaching for the Stars" engine configs would want to play with KSP-Interstellar installed anyways, as there aren't "real" engines/technologies yet... (but instead reside in the realm of the moderately-distant but definitely-feasible future...) A THIRD, and possibly best, solution; would be to include the engine ISP/TWR fixes in a separate config file from all the other KSP-Interstellar integration changes, which would reside in the config in the base RealFuels mod. But my concern is, once again, wouldn't applying two different MM patches to the same Meth/LOX engine (one to change the resources used, and another to change the TWR/ISP) cause issues? Regards, Northstar

KSP-Interstellar's Meth/LOX engine lags far behind the Space-X "Raptor" in almost every possible design criteria, and needs to have its TWR and ISP adjusted to better match real-world specs for the Stockalike config (unless I can convince FractalUK to make the engine more realistic in KSP-Interstellar to begin with- I made a similar post there). Here are just *SOME* of the specifications for comparison: Interstellar's "Deinonychus 1-D" Thrust 1425 kN (thrust does not vary with atmospheric pressure in stock engine module) Mass 3500 kg (for the record- what TWR is that?) ASL ISP 309 s VAC ISP 368 s Space-X's "Raptor" ASL Thrust 6900 kN VAC Thrust 8200 kN Mass Unknown- but TWR predicted likely to exceed 120 ASL ISP 321 s VAC ISP 380 s Keep in mind that the "Deinonychus 1-D" is not available until "Experimental Rocketry" - the *very last* tech node in the rocketry series of the tech-tree! So, it would be perfectly reasonable to expect it to significantly out-perform Kero/LOX engines in many ways, considering its higher tech level (and as a Meth/LOX engine, it is in fact a bit further towards the "high ISP" end of the fuel-density vs. ISP spectrum than Kero/LOX engines...) Also, a potential issue that I'm worried about is that there are already ModuleManager patches made to the Meth/LOX engine in the *base* RealFuels mod to change the resources it consumes from LiquidMethane/Oxidizer to LiquidMethane/LiquidOxygen (through its KSP-Interstellar integration config, which is currently outdated and incomplete- I even went so far as to suggest some additions to it to make it more complete recently...) So, could it potentially cause issues applying a *separate* MM patch through the "Stockalike" engine config to also change the TWR/ISP of the engine? Maybe the best solution is to simply add my code additions to the integration config into the base integration config, and then use *that* as a starting point to add in further lines of code to create an alternate Stockalike engine config version of the integration config that *also* changes the Meth/LOX engine's TWR (reduces mass) and ISP (increases ISP) to better match real-world values; and have players replace the base integration config with *that* expanded config when installing the Stockalike engine config... However, I am currently talking with Dreadicon, who is trying to create an even more complete version of the RealFuels/Interstellar integration config. So maybe it might be wise to work off *that*, or have him write in a version with changes to the engine ISP/TWR as well and kick it over here??? Regards, Northstar

@Regex I just went and double-checked, and it does indeed seem that the existing integration config for KSP-Interstellar is actually part of the BASE RealFuels mod. The problem is, it changes the resources consumed/stored by the Interstellar Hybrid Rockets (similar to an SRB, it is both a tank and engine) and Meth/LOX engines with a MM patch already. So if changes to the TWR and ISP of either of these parts were included in an *additional* config file that came with the "Stockalike" config, how would this work? Wouldn't editing a part once with MM, and then going back and editing the same part again with MM create issues? The following changes are already made in the *EXISTING* integration config (which is part of the BASE RealFuels mod, not any engine config) to three Interstellar engine parts: @PART[AluminiumHybrid1] { @MODULE[ModuleEngines] { @PROPELLANT[Oxidizer] { @name = LiquidOxygen @ratio = 4.05 } } @RESOURCE[Oxidizer] { @name = LiquidOxygen @amount = 1543 @maxAmount = 1543 } } @PART[FNMethaneEngine] { @MODULE[ModuleEngines] { @PROPELLANT[LqdMethane] { @ratio = 0.443 } @PROPELLANT[Oxidizer] { @name = LiquidOxygen @ratio = 0.557 } } } @PART[vista] { @MODULE[ModuleEngines] { @PROPELLANT[LiquidFuel] { @name = LiquidH2 @ratio = 20 } } } That's not even counting the changes made to NTR or electric engine propellants, *exactly* in the same manner as the ones I suggest adding below, for NTR fuels that weren't part of Interstellar back when the integration config was written... (based on version dates) Here are the changes to NTR and electric engines that are already part of the config found in the *base* RealFuels mod: @BASIC_NTR_PROPELLANT[Hydrolox] { @guiName = Hydrolox @PROPELLANT[LiquidFuel] { @name = LiquidH2 @ratio = 0.73 } @PROPELLANT[Oxidizer] { @name = LiquidOxygen @ratio = 0.27 @DrawGauge = False } } @BASIC_NTR_PROPELLANT[Hydrogen] { @guiName = LiquidH2 @PROPELLANT[LiquidFuel] { @name = LiquidH2 } } @BASIC_ELECTRIC_PROPELLANT[Hydrogen] { @guiName = LiquidH2 @PROPELLANT[LiquidFuel] { @name = LiquidH2 } } Note that for some strange reason, the last MM patch (the one to LiquidFuel --> LiquidH2 in electric engines) is duplicated, and an identical version is present again just a few lines later in the same config (the line above it is provided for context, so you can see it's a duplicate and not just a copy of the same line as before) @WARP_PLUGIN_SETTINGS { @HydrogenResourceName = LiquidH2 @OxygenResourceName = LiquidOxygen } @BASIC_ELECTRIC_PROPELLANT[Hydrogen] { @guiName = LiquidH2 @PROPELLANT[LiquidFuel] { @name = LiquidH2 } } The MM patches I already wrote up (also posted below) are in *exactly* the same spirit as the ones in the base RealFuels config (in fact they were derived from the original integration config code). So regardless of whatever is done with the more complete integration config Dreadicon is working on (if/when he finishes it), or the problems with the Meth/LOX engine ISP/TWR I mentioned here, the changes below should be integrated into the .CFG that comes with the *base* RealFuels mod: @BASIC_NTR_PROPELLANT[Methalox] { @guiName = Methalox @PROPELLANT[LqdMethane] { @ratio = 0.443 } @PROPELLANT[Oxidizer] { @name = LiquidOxygen @ratio = 0.557 @DrawGauge = False } } @BASIC_NTR_PROPELLANT[Ammonia] { @guiName = Ammonia @PROPELLANT[Ammonia] { @name = LqdAmmonia } } @PART[FNAmmoniaTank] { MODULE { name = ModuleFuelTanks volume = 10731 type = Default } } If it wasn't clear from the actual code, two of these MM patches fix new modes of NTR propulsion not addressed in the existing config (as they weren't part of Interstellar back when the integration config was written), and the other makes a fuel tank found in Interstellar into a modular one- which said tank was either overlooked or not present before... Regards, Northstar

Good point- and I should have remembered this by now. I'll kick this over to the Stockalike integration config- since that engine pack balances engine TWR and ISP against real-world norms while not directly converting any stock or mod engine into an actual real-world one; and as I've never actually played with either of the other engine configs, and have no idea whether they have any Interstellar compatibility to begin with... EDIT: But didn't the base RealFuels mod already have at least some KSP-Interstellar compatibility? If I remember correctly, there is already an integration config in the base RealFuels that switches over the Interstellar methane tanks to be modular- which would be the kind of thing that fits in the base RealFuels mod. And it also set the Nuclear Thermal Rocekts in Interstellar to use the new resources (it doesn't cahnge thrust or ISP, just the resource names), if I remember correctly. So wouldn't *THAT* be the kind of thing that fits in the base mod. And if the Meth/LOX engine is already being modified via a MM patch in the base RealFuels mod to burn the new resources (also in the same file with the changes to the fuel tanks and NTR's), then would it work to apply a separate MM patch to the same part to fix the ISP and TWR? I guess I'll need to go and check whether it's the base mod of Stockalike config that owns the existing integration config... Regards, Northstar

Also, for reference when considering what else needs fixing for an integration-config: KSP-Interstellar's Meth/LOX engine lags far behind the Space-X "Raptor" in almost every possible design criteria. Here are just *SOME* of the specifications for comparison: Interstellar's "Deinonychus 1-D" Thrust 1425 kN (thrust does not vary with atmospheric pressure in stock engine module) Mass 3500 kg (for the record- what TWR is that?) ASL ISP 309 s VAC ISP 368 s Space-X's "Raptor" ASL Thrust 6900 kN VAC Thrust 8200 kN Mass Unknown- but TWR predicted likely to exceed 120 ASL ISP 321 s VAC ISP 380 s Keep in mind that the "Deinonychus 1-D" is not available until "Experimental Rocketry" - the *very last* tech node in the rocketry series of the tech-tree! So, it would be perfectly reasonable to expect it to significantly out-perform Kero/LOX engines in many ways, considering its higher tech level (and as a Meth/LOX engine, it is in fact a bit further towards the "high ISP" end of the fuel-density vs. ISP spectrum than Kero/LOX engines...) Regards, Northstar

KSP-Interstellar's Meth/LOX engine lags far behind the Space-X "Raptor" in almost every possible design criteria. Here are just *SOME* of the specifications for comparison: Interstellar's "Deinonychus 1-D" Thrust 1425 kN (thrust does not vary with atmospheric pressure in stock engine module) Mass 3500 kg (for the record- what TWR is that?) ASL ISP 309 s VAC ISP 368 s Space-X's "Raptor" ASL Thrust 6900 kN VAC Thrust 8200 kN Mass Unknown- but TWR predicted likely to exceed 120 ASL ISP 321 s VAC ISP 380 s Keep in mind that the "Deinonychus 1-D" is not available until "Experimental Rocketry" - the *very last* tech node in the rocketry series of the tech-tree! So, it would be perfectly reasonable to expect it to significantly out-perform Kero/LOX engines in many ways, considering its higher tech level (as a Meth/LOX engine, it is in fact a bit further towards the "high ISP" end of the fuel-density vs. ISP spectrum than Kero/LOX engines...) Regards, Northstar

@FractalUK I've been buzzing around this topic for a while, over in my Request thread for a RealFuels/KSP-Interstellar integration config, but haven't actually mentioned it over here yet... http://forum.kerbalspaceprogram.com/threads/95671-RealFuels-KSP-Interstellar-Integration-Config Anyways, it seems that the Meth/LOX chemical engine in KSP-Interstellar (the Deinonychus 1-D) has significantly lower Specific Impulse than the real-life Raptor Meth/LOX engine design concept that I assume it is modeled after... (what else could "Elon Kerman's Space Exploration Corp" refer to if not real-life "Elon Musk's Space Exploration Corp." aka, "Space-X"?) The Space-X Raptor engine would have a sea level ISP of 321s, and a vacuum ISP of 380s. http://en.wikipedia.org/wiki/Raptor_%28rocket_engine%29 (I know this link is to Wikipedia- but I also found a number of other sources confirming this is accurate information- just Wikipedia has it in an easier-to-digest format...) This may seem rather high to you, compared to the stock engines, until you consider that most stock engines appear to be modeled after Kerosene/LOX performance specs, whereas Meth/LOX falls a *little* more towards the high-ISP low fuel-density end of the spectrum (LH2/LOX is capable of MUCH better ISP- with some engines measuring over 460s, but has a *much* lower still fuel density). Since KSP-Interstellar already has a lower fuel-density for Methane/Oxidizer than the standard LFO fuel tanks (that is, less fuel mass is held per cubic meter), it would only make sense to realistically balance the engine by increasing its ISP to real-life levels. Right now, its performance lags too far behind its LFO cousins (due to lower fuel-density) and the real-life Raptor designs (which would have better ISP, if they ever get built...) In fact, KSP-Interstellar's Meth/LOX engine lags far behind the Space-X "Raptor" in almost every possible design criteria. Here are just *SOME* of the specifications for comparison: Interstellar's "Deinonychus 1-D" Thrust 1425 kN (thrust does not vary with atmospheric pressure in stock engine module) Mass 3500 kg (for the record- what TWR is that?) ASL ISP 309 s VAC ISP 368 s Space-X's "Raptor" ASL Thrust 6900 kN VAC Thrust 8200 kN Mass Unknown- but TWR predicted likely to exceed 120 (yes, I know this is a *very* high TWR- and might be over-optimistic) ASL ISP 321 s VAC ISP 380 s (this prediction by Space-X *IS* possible: the theoretical maximum for Meth/LOX is a bit over 400s) Keep in mind that the "Deinonychus 1-D" is not available until "Experimental Rocketry" - the *very last* tech node in the rocketry series of the tech-tree! So, it would be perfectly reasonable to expect it to significantly out-perform Kero/LOX engines (assuming LFO engines represent Kero/LOX) in many ways, considering its higher tech level (and as a Meth/LOX engine, it is in fact a bit further towards the "high ISP" end of the real-life fuel-density vs. ISP spectrum than Kero/LOX engines...) Regards, Northstar

Indeed, but he *MAY* have a point. The 443:557 ratio of Methane to LOX for the Interstellar Meth/LOX engines (this was the ratio already included in the pre-existing and incomplete/outdated integration config) seems far too fuel-rich to me, considering Methane and LOX burn in a close to 1:4 mass ratio... CH4 + 2 O2 --> CO2 + 2 H2O Also, yes Kejchal, I think you did it wrong. It doesn't appear you entered the correct balanced reaction into that website to start with... If you used the densities for LiquidMethane and LiquidOxygen currently used in RealFuels (I posted these on the first page, it doesn't matter what densities you could find on Wikipedia- they may not be at the same temperature/pressure conditions), the LiquidOxygen is 2.698249 times more dense than LiquidMethane, but burns in a 16.043 : 63.996 mass-ratio according to the website you linked to, meaning the stoichiometric reaction ratio in KSP (in terms of units/volume) should be... 1 : 1.477514 Or, when set to volume-fraction as KSP uses (i.e. if only 2/5ths of the volume fed into a reaction was of a given resource, its ratio would be "0.40") LiquidMethane: 0.40363 LiquidOxygen: 0.59637 Notice those two numbers have to add up to 1 for it to work properly in KSP, hence I chose a # of significant figures such that I could do that while minimizing rounding errors... (my actual results could have been to more sig. figs., but it would have only complicated things) The current integration-config, on the other hand, uses 0.443 and 0.557 for the volume-fractions. EDIT: Some more research reveals the ratio currently in use is probably fairly accurate. Meth/Lox engines actually are a LOT more efficient when run fuel-rich, unlike Kero/LOX or Hydro/LOX, which both pay significant penalties for running fuel-rich (but are often built as-such because running Oxygen-rich requires much more advanced metallurgy to do properly- of the sort that only the Russians had until recently, when the US bought several such Russian engines and associated documentation in order to figure out how to replicate them...) The ISP of the KSP-Interstellar Meth/LOX chemical engine still isn't up to snuff yet, though- the REAL engine has a sea-level ISP of 321s and a vacuum ISP of 380s, whereas the specs of the current RealFuels/Interstellar engine are significantly worse... (this is a holdover from normal Interstellar- RealFuels simply doesn't do anything to increase the ISP to accurate levels, while decreasing the fuel density and thus nerfing Meth/LOX...) Regards, Northstar

Well apparently the smaller tanks than whichever one you set to have a 700 lb/hour boil-off rate had a much LOWER boil-off rate than they should have, then, assuming you scaled boil-off linearly instead of by an exponent less than 1... Also, though this is by no means a new issue to RealFuels, I would like to see RealFuels be able to fill any tank with KSP-Interestellar LiquidWater through its modular fuel system when both RealFuels and KSP-Interstellar are installed. This would be an EXTREMELY useful feature that by all means *should* be a part of RealFuels, because it would allow players to store LiquidHydrogen and LiquidOxygen in the form of water (and then electrolyze them when the fuels are needed) to avoid boil-off, and there is no real reason any normal fuel tank should NOT be able to hold a modular amount of water. KSP-Interstellar solves all the problems with energy-demands this imposes by allowing players to either carry nuclear reactors on their spacecraft, or beam the power via microwaves from a solar or nuclear power satellite in orbit elsewhere... I've already been following up a little with Dreadicon about trying to get this in the new RealFuels/KSP-Interstellar Integration Config he is drawing up, but I figured I should follow up on this along as many lines of inquiry as possible to make sure it gets implemented/fixed... Also, NathanKell, did you see the lines of code I already drew up to be added to the RealFuels/KSP-Interstellar Integration Config? http://forum.kerbalspaceprogram.com/threads/95671-RealFuels-KSP-Interstellar-Integration-Config?p=1459379&viewfull=1#post1459379 My lines of code are already complete (for the functions they are trying to accomplish- admittedly there are still a fair number of features that need to be fixed for *FULL* compatibility between RealFuels and KSP-Interstellar, such as the LiquidWater storage in modular fuel tanks issue I raise above...) and have been tested with both RealFuels and Interstellar installed- they work like a charm, even if others might eventually come up with more elegant solutions... Even though I've been talking with Dreadicon, who is trying to get a more elegant and complete set of solutions up; mine are of equivalent complexity to the ones already in the incomplete integration config that comes with RealFuels (in fact, they are basically just copy-pastes of the existing solutions with changes in the names of parts/resources and ratios to apply fixes to other parts/resources/features than the ones already fixed in the config), so they're not *bad* by any means- and I'd like to see them make their way into the integration config that comes with RealFuels just in case Dreadicon doesn't get something more complete out anytime soon (or misses some of the fixes I already posted, assuming they would already be included in the config). Regards, Northstar

Your post made me sad, then angry, then laugh, then sad again... Do you realize how many DECADES we steal from people's lives when we pump pollution out into their environment from a coal power plant? Or even the many exhaust pipes of a highway full of cars? Or when we don't provide sufficient police protection to minority neighborhoods because politicians think people like them are "better" and worth more than those people? No, there's absolutely nothing unethical about allowing a willing/enthusiastic volunteer to give up years of his life for the sake of space exploration. Soldiers already willingly give up potentially ALL of their lives when they sign up to get shot at... Sign me up the next time NASA is doing a cryo-trip to Mars. Seriously, I'd do it. Regards, Northstar

Unfortunately (or fortunately, for the Russians and the science of space exploration), that's where you're wrong. Buran was designed to operate 100% unamnned on ANY mission type. Everything, from the robotic arms and cargo bay to the Angle of Attack during re-entry, could be and was remotely-controlled). It's not actually all that hard with today's computer technology- but you have to remember than Buran was designed with 1980's technology, and STS (which could NOT operate fully-unmanned like this) with 1970's tech. It probably would have been possible to retrofit STS to operate fully-unmanned, but such a complete overhaul of the computer systems and avionics was something that was never attempted, perhaps because at the price of doing something like that it would have been cheaper just to build a slightly-updated version of the Shuttle from scratch... Regards, Northstar

Your table is mostly right, but a minor correction- Karbonite has two converters (a "converter" and a "distiller"), one for the more "volatile" fuels such as LF/O, and one for the more "stable" fuels such as Xenon. Not a huge deal, but you asked, so I just though I'd point it out... Actually, I rather *LIKE* there being the need for separate tanks for a single, unrefined resource- since this would allow players to do things like send a mining rig down to the surface of a planet (especially somewhere with high gravity, like Tylo or Eve), and leave the refining infrastructure in orbit. Since there could be mass-losses in the conversion process, this might be less efficient that refining the resources on-site in the LONG RUN, but might allow for massive mass-savings in setting up the mining/refining system in the first place (if you don't bring the converter all the way down to the surface). I also don't think all the resources should be available everywhere on all the planets- the Mun should only have Oxidizer across most of its surface (representing aluminum-oxide regolith), but should have LiquidFuel deposits located in a few special craters near the poles (representing water ice)- forcing the player to go through a little extra effort of establishing a polar orbit and making a polar landing if they want to obtain both LiquidFuel and Oxidizer... Note the difficulty factor is in the mission planning and rocketry, *not* in the actual resource extraction/conversion process here- getting to the Mun's polar craters may be a bit harder than getting to the equator- but the challenge is in the rocketry, the same kinds of challenges players normally face with difficult landings- not in any actual feature of the resource extraction system. However, my previous idea of having separate tanks for the ISRU resource(s) doesn't match well with having only certain resources in certain locations (without having a dozen or so collectible resources), trying to go in both directions at once only over-complicates things and leads to part-spam, so I'm inclined to agree with you here- maybe it *IS* just a better idea to produce the resources directly, with no special tanks (or even converter parts- assume the converters are built into the harvesters) needed. Agreed. If Squad just makes a handful of extractor parts, and abstracts the conversion process by assuming it's built into the extractors, then this opens up more of their time to focus on correctly balancing the cost/mass of the different extractor parts (of which there should only be 2 or 3- a single general "drill" part would suffice for Duna ice or Munar regolith alike...) Agreed again. I'm really liking how you're knitting together a coherent system here. I think we need to be VERY CAREFUL about suggesting resource-interdependence here. As already pointed out, it could lead directly to grid-lock. I'm all for Liquidfuel and Oxidizer being found together 99% of the time to simulate water-ice, with a couple exceptions: Oxidizer should be found all over the Mun, but Liquidfuel only on the poles; and Kerbin/Laythe' atmospheres should contain just Oxidizer, while Jool's should have just LiquidFuel. Xenon should be a particularly rare resource, that is only found in a handful of places. But, I think the resources should be fairly abundant, like in Karbonite. The MAIN difficulty should be finding high-concentration deposits of them, with some planets/moons simply not containing any particularly great deposits- for instance the LiquidFuel at the Mun's polar craters should only be found in low concentrations. Of course, players could time-warp to get all they need (and I think the extractors NEED to operate while the vessel is unloaded- to make ISRU not feel like a grind), but Contracts, and possible some day life support, mean they would pay a price by doing this... I agree that Xenon should be rare- but for the sake of realism and balance/difficulty, it should be found in rocks through drilling, not in atmospheres (the main reservoirs of Xenon in the rest of the solar system are in rocks, and this would also allow it to be collected on airless planets/moons). Monopropellant should also be more abundant, since it represents a *variety* of different real-life possible propellants (ranging from Hydrazine to compressed N2/CO2). This would also work well with balancing, if it were more common than any of the other resources, but also yielded lower ISP... The monoprop engine isn't as broken as you think, by the way. While the fact that it currently has physics disabled is a problem, it would actually have a rather poor TWR if it used the mass stated on the part description. And it is QUITE expensive in Career Mode (both from a tech-tree and Funds perspective), so that's another balancing factor... More advanced engines SHOULD become available at higher tech levels- after all, otherwise what's the point in making technological progress? You need to reward players for their effort, and it also works with believability/realism to have better engines at better tech nodes (IIRC, the ISP of the Monoprop engine isn't all that outrageous compared to real-life engines based on LH2/LOX: the Space Shuttle Main Engines could attain ISP's of nearly 460s...) Regards, Northstar

Absolutely. A variety of opinions is useful and productive. But the problem ism there are *certain topics*, of which Resources is definitely one, that get buried under piles of "No, I don't want that. That idea sucks!" posts with no valid point included. *THAT* is the sort of thing that I will call the moderators in on, if people start trolling the post with that kind of thing. Luckily, it doesn't seem to have happened- so either my fears were overblown, or the warning actually worked. Regards, Northstar

Agreed- unless you're saying you don't want mining/refining to consume ElectricCharge (they should- and LOTS of it, to finally give a use for Gigantor solar panels...) Having Liquidfuel and Oxidizer generally (though not ALWAYS) found in the same place makes a lot of sense from a gaming perspective, and is realistic as well- as one of the most abundant/useful potential ISRU substrates in real life is water-ice (which is composed of a combustible ration of Hydrogen and Oxygen- one of the most common rocket fuel mixtures in use today). However I am STRONGLY against *combining* Liquidfuel and Oxidizer into a single "fuel" resource, if that's what you're suggesting- not only would this FURTHER break realism and immersion from the (already broken/ over-simplistic) stock system of fuels, it would also break a number of mods and existing saves/player vessels based on there being two separate resources. Keeping them separate also opens up the possibility for their being *some* places where you can find only one. For instance, Oxidizer but not Liquidfuel in the upper atmospheres of Kerbin and Laythe (Earth's atmosphere has plenty of Oxygen and Nitrogen- both of which can be used as oxidizer, as in N2O4, but very little free Hydrogen/Methane...), and Liquidfuel but not Oxidizer in Jool's atmosphere. What the devs need to do is strike a good balance between ease/usability and maintaining some challenge here. And, as it so happens, reality presents an EXCELLENT model for this- the real solar system already has water-ice in quite a few places, and Hydrogen or Oxygen in others. So they can strike this balance while at the same time still preserving some realism/believability of they rely on the real-life distribution of resources as a starting point... That's a very silly arrangement. A *better* one (in terms of fun/balance) follows real life more closely, and also is more believable: Drill gives LF/O (where you can find water-ice) or just Oxidizer (where you can only find oxidized rocks), and Xenon (found commonly in rocks on the moon, for instance). As a *special* bonus, I would like to see Aluminum/Oxidizer Hybrid Rockets added that can be refueled on the Mun or Ike to assist in heavy-lifting (assuming both moons are made of aluminum-oxide regolith). Al/Ox rockets are a lot like SRB's, with high thrust and density, except their ISP is a little better, and they have controllable throttle (this is controlled by changing Oxidizer flow- in fact Hybrid Rockets are often easier to throttle than liquid rockets...) Pump gives LF/O and Monoprop. Atmospheric Scoop gives *either* Liquidfuel or Oxidizer (depending on the planet- but the two can't both exist freely in the same atmosphere, or they would react), and Monopropellent. Notice I made it significantly harder to obtain Xenon. This is because Xenon is an *exceptionally* valuable resource (both in terms of Funds cost and ISP), and having it freely floating in atmospheres (which doesn't really happen in real life) would be far to easy, as well as straying hugely from reality... It should only be available by drilling, and only on *some* planets/moons, not all of them, to reflect its value/rarity... Apparently you mis-understand the relationship between molecular mass and ISP in real life, because you have it *precisely* reversed. Xenon, due to its very high moledular mass, would give TERRIBLE ISP in a nuclear rocket, but amazing thrust. Hydrogen (aka. LiquidFuel) gives great ISP but terrible thrust. In real life, Methane and Ammonia have also been considered as potential Nuclear Rocket fuels, since they have better thrust (but inferior ISP) to Hydrogen, and are also much easier to store... The only way Xenon would ever be used in RCS is if it were electrically-driven, otherwise the ISP would be laughably low. I'm 100% for ignoring any suggestions to give Xenon more uses besides electric engines, as the stock ion engines are already OP'd enough as-is... Currently there *is* no such resource as atomic fuel (I assume this would be used in LV-N's, like in RealFuels mod?) But if there *were*, there is no reason it shouldn't be extractable on other planets/moons- Uranium and Thorium exist throughout the solar system, not just here on Earth... The rest I ignored for one reason or another, usually because I strongly disagree but don't want to write a long argument why right now... Basically, in summary, though, I want to see the devs implement a system that is simple/ relatively light on parts (but expandable in mods), to help ensure the system survives, but also has enough realism/believability for players to try and re-create their favorite real-life space infrastructure ideas in-game: like atmospheric accumulators on Kerbin (skimming Oxygen off the edge of Earth's atmosphere is something that has really been suggested), which would work best if the atmospheric scoop worked *just above* the edge of the atmosphere like in Karbonite mod; atmospheric scoops skimming from Jool (like Hydrogen might be extractable from the edge of Jupiter's atmosphere in real life) ; regolith-extractors to refill Aluminum-Oxidizer Hybrid Rockets, or drills to provide LF/O from polar craters on the Mun (like could be done with the aluminum-oxide regolith, or water-ice near the poles, on Luna) ; or drills/ ground-based scoops on Duna to re-create something along the lines of the Mars Direct mission plan... Regards, Northstar

I'm not inventing any extra rules- simply only stating that I intend to try and get the moderators to enforce the existing Forum Rules if necessary. Forum Rule 2.3d states the following are banned: "Messages that purposefully change the subject of conversation in a thread without a natural tie to the topic at hand" Anyways, do the right thing and you've got nothing to worry about. I'm not *trying* to be a jerk. Regards, Northstar

I think the tech restrictions serve good purpose (although they need to be relaxed a little IMHO- at some points the largest ProceduralParts tanks I could make were *smaller* than available stock/ KW Rocketry tanks...) However, regarding the tech unlock at Meta Materials- are the tank sizes truly infinite? Or do they cap out at some modest value like 7 or 8 meters? That is what I was trying to figure out before... (also, if I install a mod that enlarges the VAB, could I build them to some insane size like 20 meters, if I had enough Funds?) @NathanKell Also, if you're running ProceduralParts, then this is all the more reason to fix the boil-off equation in RealFuels. Look at the post I made there: boil-off should probably increase at a lot LESS than the 2/3 power of tank volume. The 1/3 or 1/2 power seems about right, though actual real-world mathematical models can be found in this NASA article I'm going to try and read through: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080013162.pdf Regards, Northstar

Except Buran was designed to operate fully unmanned. In fact, in its one and only test flight it *did* operate fully unmanned, something STS could never do. And yes, Energyia also was the framework for a planned Space-X style reusable flight profile that the Russians never really got started on in earnest, where the boosters and the launch stage (but probably not the upper stage) would have sprouted wings and been fully-recoverable with flyback-capability on Energyia-2. In which case, a super-heavy lifter makes a LOT more sense- because you lose a lot of payload capacity when you build your launch vehicle to be reusable (meaning a fully-reusable Energyia, if it ever got to that point, might have only been able to lift 50 or 60 metric tons instead of 175...) Regards, Northstar

The Square-Cube Law (which I must remind you applies equally well to non-spherical shapes: in fact the "classic" case is a cube, not a sphere) actually gets factored in TWICE- once to determine the relative increase in Heat Leakage (which increases at the 2/3 power of volume), and once to determine the relative change in Surface Area through which the fuel can actually leak out: thus boil-off should only increase as the 4/9th power of volume- a little less than at the rate of the square root (1/2). The math probably gets a little more complicated than this, however, as the walls are thicker, and thus better insulators from the outside environment even without insulating foam (and any added insulating foam becomes exponentially more effective with a larger tank) in larger tanks, and the accumulation of vapors in the fuel tank suppresses the formation of additional vapor until the existing vapor can seep through the tank walls... I suggest reading the following NASA analysis of cryogenic boil-off for more detailed numerical models: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080013162.pdf I would say as a first approximation that the boil-off should increase at somewhere between the square (1/2 power) and cubic (1/3 power) roots of tank volume- although once again, the NASA document will be the best place to find hard numerical models (I'm going to sit down and try and read through some of it now- why did I turn myself into an engineer? I majored in biology to get *away* from having to do so much math...) Regards, Northstar

SQUAD has announced that there actually should be a Resources (In Situ Resource Utilization) system of some kind in Beta: "Deep Space Refueling - We’re aware there is one big end-game mechanic missing in the game: Being able to refuel a vessel once you’re out in Space. This is what we originally set out to achieve with the old Resource Mining plan and saw ourselves running into a very tedious dead-end. The Resources system was flawed because it overcomplicated accomplishing a basic need: To be able to find something out in space which can be used to fill up the tanks again. That’s the essence of it, and we don’t need 40+ single-purpose parts and 9 different resources to do it. In fact, all that complexity was going to be very effective at making sure most attempts to build a refueling outpost would fail. We are now planning a new, more elegant system, which hopefully will add a new, fun element of gameplay, as well as the massive boost to continuity this feature implies." No news could make me happier (and although some of you may be less enthusiastic about it- remember that it still won't be coming for quite a while, and you don't have to ever use it if you don't want to) Anyways, I'm ecstatic about the news, but I'm still slightly cautious/worried, considering how badly Squad lost sight of common sense last time they attempted Resorces. (if somebody could provide me a link to the flow-chart of the old attempt to place here, that would be wonderful) So, I'm opening up a Discussion about how YOU, the player think that Resources should best be implemented. Keep in mind that this is *NOT* a thread to say you think it shouldn't. It's not that I don't think that your opinion is valid- only that it would too badly de-rail the main topic. Any attempts at such discussion will be reprimanded, more than once if necessary, and if you keep persisting in trying to hijack the thread I will try to call in a Moderator to do something about it... You have been warned. My Take on the Planned Feature: Anyways, MY opinion on the matter is that, as much as I love realism and complexity, for the STOCK game, the best philosophy for Squad here is KISS (aka. "Keep It Simple Stupid"). Although I highly respect Squad's ability to interestingly model complex systems, I really want the system to survive and make it into the final game more than anything else. And we all know where things went the LAST TIME they let themselves get carried away with complexity... I am of the opinion that the best use of Squad's time/effort in implementing a FUN Resource system would be to create just a single collectable resource (similar to Kethane, or better yet, Karbonite), and 2-4 types of collectors (1 or 2 different sizes of drill, an atmospheric collector, and maybe an oceanic collector as well) *that all collect this one resource*, and thus are 100% interchangeable (and added for slightly more immersion/believability than having a single do-all collector part) so there is absolutely no need for players to actually have to learn how to use multiple different parallel resource trees stemming from a thousand different collector parts like in the original system- and then a single type of refinery (perhaps available in 2 different sizes) that can refine this resources into most or all of the different in-game fuels. This would also add interesting opportunities for Squad to add all sorts of fun part flavor text about how this resource works/ was discovered. And, of course, teachers in the classroom could do a whole segment on the real-life possibilities for In Situ Resource Utilization (Methane through Sabatier Process, Kerosene through Fischer-Tropsch, Oxygen from lunar regolith, etc.) as a means of teaching a bit of chemistry in a fun way when using the Kerbal.EDU version... But the Kerbal stock resource need not have any real-life name, and in fact it would probably be better if it did not. I also think Squad should focus HEAVILY on creating a good system for detecting the resource in the first place (Kethane and especially Karbonite mods are somewhat lacking in this regard unless you also install the ScanSat mod), perhaps also including a potential mapping feature for advanced players if ti could be done in a performance-friendly way (newbies could rely on atmospheric filtration on planets with atmospheres- which wouldn't require any use of maps...) as well as on creating good cost/mass balance (for this, real life relative costs of some of the cheaper ISRU systems might be a good starting-point, tweaked a bit for FUN of course) and visuals/animations in relation to the rest of the game... Regards, Northstar P.S. Another thought, in an entirely different direction than planet-based ISRU, that Squad could go in, is to make some asteroids mineable- to reflect some asteroid/comet compositions including not just water-ice, but also oxidized alumina and various simple organic ("organic" means carbon-based, NOT necessarily associated with life) compounds... Although, IMHO, I don't think asteroid-chasing would be NEARLY as fun (or practical) as, say, setting up a refueling base on Duna, and should only be added as a secondary method of obtaining the mineable resource(s), if at all

Hey swamp_ig, It's been a while since I actually managed to play through a Career or Science save up to the highest tech levels, thanks to real life and my love of discussing sstuff on the forums. The last time I actually managed to do so, I was running StretchyTanks rather than ProceduralParts... So, I was wondering- is it actually still possible to build a mammoth fuel tank large enough to, say, stick a cluster of 8 Mainsails (or better yet, the SLS-tyle upper stage engines) under and launch it? I'm aware that since fuel tanks are pressure vessels, there are limits to their absolute volume in real life. But hey, this is KSP, and besides, the limits are on the absolute volume of each individual tank, and are almost completely unrelated to shape, as it turns out (fuel tank mass actually has no relation to shape in real life- the mass necessary to hold a certain volume, ignoring extra mass for structural stability, actually scales more or less 100% linearly with volume, regardless of shape, in reality... This is because fuel tanks are pressure vessels- so shapes with more surface area can have proportionally thinner walls...) So there's no reason to think I couldn't build a fuel tank 25 meters wide and only 5 meters tall, for instance... Any limits on tank size in ProceduralParts *should* realistically be connected with tank volume (and increase with tech level) rather than tank dimensions, for realism... But besides that, a single "fuel tank" part could also just as well be envisioned as a number of smaller fuel tanks withing a single aerodynamic shell- an important distinction over using multiple smaller tanks for FAR, and one requiring far fewer struts and lower part-count... (Procedural Fairings could, in theory, be used to construct such an aerodynamic shell around smaller tanks instead- but the fairings/fuselage cost algorithm doesn't currently scale well for such gigantic applications, and quickly becomes disproportionately high...) So, anyways, the question is this- IS IT POSSIBLE? Will I be able to build the massive, giga-huge fuel tanks of my dreams once I unlock the final tech nodes (such as Experimental Rocketry)- or will I forever be limited to fuel tanks roughly in the 5 meter range and below? (Keep in mind that many rockets with diameters exceeding 10 meters- the size of Saturn V- have been proposed in real life, and would have been perfectly feasible...) Regards, Northstar P.S. The reason for my desire for huge rockets is actually, though this may sound strange, cost-savings. I am hoping to build enormous rockets to launch fuel extremely cost-effectively to LKO, as larger rockets require proportionately fewer guidance systems and have superior ballistic coefficients which cause them to experience relatively less atmospheric drag for their payload capacities. Also, if I can convince NathanKell to actually fix the boil-off equations for RealFuels so they are proportional to tank surface area rather than tank volume, like in real life, then the gargantuan orbital fuel depots this will allow me to support should also experience proportionally less losses to boil-off, again precisely like in real life- where bigger fuel tanks have relatively less boil-off due to their superior ratios of surface-area-to-volume, via the Square-Cube Law...

@NathanKell I recently came across a *MAJOR* realism/balance issue that is missing from RealFuels related to boil-off rates... APPARENTLY, larger fuel tanks suffer proportionally less boil-off as both heat leakage and the rate of escape of gasses through the tank walls is dictated by the Cube-Square Law... http://en.wikipedia.org/wiki/Propellant_depot#Boil-off_mitigation http://en.wikipedia.org/wiki/Square-cube_law It MAY also help that fuel tanks are pressure vessels, and thus their walls have to become thicker the greater their volume (this is also the reason why it turns out fuel tank mass scales more-or-less linearly with volume in real life), although the article never mentioned this. Do thicker vessel walls inhibit boil-off? I'd have to do more research on that... Anyways, larger fuel tanks should definitely have MUCH lower rates of boil-off for their volume due to the aforementioned heat leakage and surface area for gas escape issues I mentioned earlier... The BEST AND MOST REALISTIC way to simulate boil-off would actually be to give all fuel tanks a constant rate in direct proportion to their surface area. Yes, this would mean partially-empty tanks experience more boil-off than full tanks carrying the same volume of fuel- but this is actually *precisely* the case in real life- boil-off rate is determined mainly by fuel tank surface area rather than volume... Regards, Northstar P.S. I'm aware this would encourage "Bigger is Better" when it comes to rocket design- but IMHO that's a GOOD idea, as besides being very "Kerbal", it's also largely true in real life. Bigger rockets experience proportionally less atmospheric drag when ascending through the atmosphere. Guidance and control systems don't have to make up as large a percentage of their mass, since the mass of a guidance computer is roughly the same for a huge or a tiny rocket. Bigger fuel tanks have proportionally less surface area for their volume and the walls are thicker- which makes them easier/cheaper to manufacture. AND, bigger fuel tanks also apparently experience less boil-off. The one *major* disadvantage large rockets have in real life, besides the logistics of getting them assembled and set up on the launchpad in the first place, is that it's significantly harder and more expensive to manufacture/design larger rocket engines- a problem that can handily be circumvented by using engine-clusters instead...

@FractalUK Hey, just an article on ISRU on Mars here that I thought you might find relevant/inspirational: http://www.lpi.usra.edu/meetings/ISRU-III-99/pdf/8004.pdf Also provides validation for adding a Fischer-Tropsch reaction for use with RealFuels (to produce Kerosene on CO2-rich planets out of LiquidHydrogen and CO2...) if that's at all interesting to you... Regards, Northstar