Northstar1989

Albert Einstain once said: "If at first the idea is not absurd, then there is no hope for it." It's good that you think the idea of a Big Dumb Booster is crazy, because that's *precisely* why it will work. In all actuality, Big Bumb Boosters are far from unproven pipe-dreams. The Sea Dragon, the proposal that gave Big Dumb Boosters their name, was confirmed by NASA as being feasible and having accurate price-estimates: "TRW conducted a program review and validated the design and its expected costs, apparently a surprise to NASA." http://en.wikipedia.org/wiki/Sea_Dragon_%28rocket%29 The point of a Big Dumb Booster is that it relies on cheap technologies (like Pressure-Fed engines, which are used all the time in space programs- so don't call them absurd or terrible), and wide engineering margins (to bring down cost by allowing the components to be produced at much less specialized/precise factories), NOT that it has low ISP. The Sea Dragon still used LH2/LOX for the second stage- it just did so with a Pressure-Fed rocket engine (which admittedly hurt its ISP, but did not make it "abysmally low" by any means) and much wider engineering margins. The bottom-line difference between a Big Dumb Booster and a "smart" booster is, once again, payload fraction and cost-per-kg. A Big Dumb Booster might have a 1% payload fraction instead of a 3% payload fraction, but makes up for it with less than 1/3rd the overall cost for a rocket of that size/mass. That's the basic principle- not low ISP, not low reliability (in fact, a Big Dumb Booster can be made MORE reliable than a "smart booster" thanks to much wider engineering margins). Of course, if you're also willing to sacrifice reliability, then you get something like the Aquarius (which also was a *small* rocket designed to take advantage of mass-production techniques...) The Russian rockets are actually LOWER performance (as measured by mass and payload fractions) than American rockets. They are generally built to wider engineering margins, and are much closer to the Big Dumb Booster concept than anything utilized by NASA, the NSA, or Air Force- which is one of the reasons their rockets tend to get payload to orbit cheaper than American designs. It's ironic that you would mock the Big Dumb Booster concept, and then hold up the country that in real life comes closest to actually implementing it... On the note of re-usability, yes, Space-X is going in the right direction for chemical rockets. But if you want to focus on performance and reusability, the ultimate end isn't chemical rocketry at all (which is more or less a peak technology- the only significant improvements we can make, like Full Flow Staged Combustion, tri-propellant fuel mixes, and Air Augmented booster stages; all yield relatively minor net improvements in performance and cost after the various trade-offs they require...) The ultimate end for high-performance rocketry is THERMAL rockets- specifically Microwave Thermal rockets and spaceplanes in the short run (Microwave Thermal has ISP's up to 850-1000 seconds when using Liquid Hydrogen, and 2-3 times the maximum TWR of chemical rockets), and Fusion Thermal spaceplanes somewhere decades or centuries down the road... (Fusion Thermal rockets have much better ISP than Microwave Thermal rockets, due to the much higher temperatures possible...) And if you think Big Dumb Boosters are a pipe-dream, I can't imagine what you think of MICROWAVE THERMAL ROCKETS- even though the necessary technologies have all been demonstrated (one rocket scientist, Kevin Parker, literally built a test-thruster out of less than a hundred dollars of supplies in the lab- some of the parts literally being spare copper funnels from gardening... Gyrotrons are regularly used in some high-tech foundries and other parts of the metalworking industry, and a scientists demonstrated the ability to run a small toy electric helicopter off Microwave Power using a gyrotron and a rectenna in the 1960's...) Here's are some articles as an introduction to Microwave Beamed Power, by the way- I've actually done my research. I challenge you to read them http://en.wikipedia.org/wiki/Beam-powered_propulsion http://www.cnet.com/news/rocket-scientist-aims-to-relaunch-propulsion-technology/ https://physics.le.ac.uk/journals/index.php/pst/article/view/190 http://nextbigfuture.com/2014/02/escape-dynamics-and-microwave-power.html http://authors.library.caltech.edu/3304/1/PARaipcp04b.pdf http://authors.library.caltech.edu/3303/1/PARaipcp04a.pdf NASA doesn't think the concept is dumb either, or they wouldn't have spent $2 million buying a 1-MW gyrotron unit *specifically* for studying Microwave Thermal propulsion: http://callcenterinfo.tmcnet.com/news/2011/04/30/5477779.htm Regards, Northstar

This indeed turned out to be the case. Good foresight. Regards, Northstar

All of these sound great to me. In real life, the Thermosphere starts at 80 km and reaches to 500-1000 km (depending on relative solar activity), so making it run to 700 km sounds good to me... Not a bad idea- considering most Propulsive Fluid Accumulators rely on energy-hungry high-vacuum pumps in order to concentrate the gasses they use. However, keep in mind that the Atmospheric Scoop itself already has some intake area built into it, and should be capable of operating on its own at a slower rate. Giving the Atmospheric Intake part the *additional* ability to increase the gathering rate (but also the energy consumption) of a Propulsive Fluid Accumulator would be a good idea. I wouldn't create a separate part, as there's no reason to think a simple intake couldn't funnel the gasses to the same vacuum pump as the intake built into the Atmospheric Scoop part itself- rather the Atmospheric Intake should be toggleable to act as additional intake-area for the Atmospheric Scoop through the right-click menu. This should also be made to somehow work in-atmosphere, so if a player decides to scoop BELOW the Karman Line, the Atmospheric Scoop can still be used to increase their gathering rate (perhaps by allowing the Atmospheric Scoop to convert the IntakeAtm resource into the relevant resource being scooped, at an efficiency depending on the abundance of that gas?) The important thing about Atmospheric Scooping Ship design (whether a Propulsive Fluid Accumulator that operates near the Karman Line, or a winged vessel that operates lower in the atmosphere) is the ratio of drag to intake area. Intakes necessarily improve this ratio, with a theoretical (but impossible) maximum for a vessel being when 100% of drag comes from the intakes themselves. This same principle actually also applies to spaceplanes- you want the best ratio of intake flow to drag possible (hence the phenomenon of Air Hogging in KSP, which takes this to physically-impossible extremes)- but lift and the necessary to pre-cool air for the engines at high compression-factors also becomes essential in that case... - - - Updated - - - That's a good way to simulate drag due to cross-sectional area, but there is also such thing as skin friction (although it is a less important factor). A 80 meter long cylinder with a 2 meter diameter encounters more drag than a 8 meter long cylinder with a 2 meter diameter... Ballistic Coefficient * Mass already gives you the drag experienced by the vessel in terms of Newtons... Keep in mind that a space station could still make an efficient Propulsive Fluid Accumulator if enough of its cross-sectional area were coated with intakes for the scooping unit... (the unit that cools/compresses the harvested gasses to usable densities) Once again, its a matter of total drag vs. intake flow... Regards, Northstar

Thought I'd revive this thread after all this time to announce that I ended up forking the Mass Driver parts from the Stanford Torus mod (which was last updated for 0.25), and will be doing my best to keep them maintained for future versions of KSP. They currently work on 0.90, but I'm hoping to get help from other players in maintaining the mod so that I have somebody with the expertise for bug-fixing or a re-compile for a newer version of KSP by the time either becomes necessary (I know how to do neither). With luck, this post will also attract a few people to give the pre-release (linked in my signature) a try. Regards, Northstar

It sometimes shows up for a tank in the part catalog on the right side (in the same column you'd see an engine's ISP and such) alongside the fuels it contains. More often, though, the only way to determine it is trial-and-error or by looking at the final version (after all MM patches have been applied) out-of-game (I forget how I did it, but I had to use the latter method to determine the built-in tanks in the KSP-I ISRU refinery were not insulated, after noticing cryogenic fuels produced with the refinery were boiling off far more quickly than they should have...) Regards, Northstar

Fixed. Had to upload the file again- previously you could only download it through the Changelog tab for some reason... Enjoy the awesomeness! Feel welcome to post your videos, screenshots, etc. here! I will be selecting the best ones for the first post of the official release thread (when there's been enough time to work out all issues, set up a Github page for the source code, etc.) Regards, Northstar - - - Updated - - - I'd love your help FreeThinker! I just got the mod working for 0.90, but I'll need help maintaining the mod if future revisions of KSP actually require a re-compile (luckily this one didn't), or if players find any bugs that I don't know how to fix...

Thanks for pointing that out! I've went and added the Source Code to Kerbal Stuff (I hope they're OK with pages just for source-codes), and a link to the page in the OP... I had no idea the original mod author had packaged the source code in that! (I thought it was just some kind of tutorial for the Stanford Torus mod that went in KSP's Scenarios folder...) Maybe I should have more carefully investigated that folder before judging it by its title... Regards, Northstar

I was running 2.0.6 before, but I just updated to 2.1.1, and it's still not working. So, it appears the tank catch-all doesn't work... On which line of the config? A few lines of code here as a sample would be enormously beneficial... Actually, yes. The Firespitter propellers use the FSengine (plane propellers) and FSengineBladed (helicopter propellers) modules. Regards, Northstar

The problem you encountered was that the mod is not working in 0.90 yet (I am actively seeking somebody to help me fix it, as I don't know how- my "Recompile" comment was idiotic, as there is no .DLL anywhere in this mod, so nothing that could need re-compiling...) If the mod *HAD* been working, when you right-clicked on the Mass Drivers you would have seen a "Power Level" tweakable slider- and once you detached the payload (it needs to be a separate craft) you would have seen the option to "Arm" on the Mass Driver, and then to fire after 10 seconds... (giving you time to switch back to the payload). I would warn you though, these Mass Drivers follow Newton's laws- meaning that accelerating a payload will create some SERIOUS recoil. That tank-like thing probably would have exploded on the runway due to kickback without some sort of ground-pylons to better anchor it into the ground (Kerbal Attachment System provides those, by the way...) Regards, Northstar - - - Updated - - - It's ALIVE! Turns out all that was missing was a .DLL file. I didn't catch it on my initial testing of the mod because I also, incidentally, had that .DLL installed for testing some of the other features of the Stanford Torus mod for a fork (I've been thinking about forking the long-term science experiments as well). But when I updated to 0.90, it was a fresh install (because the laptop I had been running 0.25 on broke), so... Proof it's working now: Regards, Northstar

Yeah, there are HUNDREDS of different Lego sizes/shapes now, like I said, and often the challenge for a kid is finding the right part for the job rather than making the wrong part do the job... LEGO was never meant to be a game about making the wrong part work- just the opposite, it was a game about unleashing a child's creativity AS MUCH AS POSSIBLE (which is why they've kept expanding the variety of possible parts over the years...) So saying that Standard Parts would make KSP more like LEGO is a terrible/false argument. Standard-sized fairings just doesn't make any sense. It would create EVEN MORE lag in KSP (which in addition to procedural fuel tanks, BADLY needs an optimization update), and clutter the part catalog even more. Oh, and did I mention that it's not realistic (there are a LOT more than 3 diameters of rocket in real life, and thus a lot more than 3 diameters of fairing...) In the end, it comes down to what I said before, though: having too many legos in one place does NOT slow down or stop time, or cause spontaneous explosions! (LEGO would have been MUCH more interesting if it did...) Regards, Northstar - - - Updated - - - This. KSP is NOT a game without restrictions. It *NEVER* will be, no matter how many parts are made procedural (*cough* I still want stock procedural fuel tanks for memory-usage and historical-recreation reasons...) or how many shiny new futuristic techs (like the RAPIER, or someday maybe ISRU?) are added. The fact is, as a partial simulation game (HarvestR described KSP as "part simulation, and part sandbox" back when he was first describing the game to some other forum communities), you will ALWAYS be subject to real-world physics. How much so is determined by how far the devs lean towards realism (please NEVER use the phrase "realism vs. gameplay" with me- I STRONGLY believe realism ENHANCES gameplay 95% of the time...), but the limits of the Rocket Equation, gravity, orbital mechanics and such are always present... If the devs make the new aerodynamics system even a touch realistic, you guys will be BEGGING for procedural fairings. They allow you to do a LOT more than just have precisely the "right" fairing for the payload- they also allow you to easily do things like create an extra-long fairing with a more gradual taper (that is, more like a needle than a shallow cone) to reduce aerodynamic drag, determining for yourself *precisely* how sharp the nose of your rocket ought to be. For that matter, that's also PRECISELY one of the reasons why I want to see procedural fuel tanks, or procedural nosecones at the very least- so that for rockets WITHOUT fairings on the top, I can still determine how sharp vs. lightweight I want my rocket's nose to be (sharper noses are longer/heavier, but they GREATLY reduce aerodynamic drag...) Regards, Northstar

But I HAVE RealFuels+Stockalike installed. So clearly the tank catch-all MM patch didn't work??? How do I actually add a Cryogenic, rather than Default, tank to a part? Also, about the Firespitter propellers- I don't play with AJE, and have no intention to (the performance is nerfed too far back for jets for my taste- to 1970's tech instead of the current cutting-edge... I mentioned it to the AJE creator, and he suggested I create a current-tech alternate config: but that was/is a little beyond my capabilities at the moment, especially with all the work I've been doing trying to get KSP-I and RealFuels to play nicely together, and to try and fix the Mass Driver mod I released but is now broken....) But I want to be able to use them with Kerosene and RealFuels installed. Could you please throw a simple fuel-conversion into the Stockalike config for the remaining Firespitter engines Raptor? Speaking of the last of those, would anyone here have an interest in helping me get my Mass Driver mod working for 0.90? I need somebody with some modding experience, who knows how 0.90 could possibly break a mod without any .DLL such as this (it's just a part that relies off a little-used Unity module to create acceleration, to my understanding...) I've asked for help everywhere, I even had the Kerbal Podcast team make an announcement that I needed help with it, yet nobody's come forward to help... Regards, Northstar P.S. You can find the link to my (currently broken) Mass Driver mod pre-release in my signature, which I prematurely labeled as [0.90] simply because it loads and doesn't crash KSP in 0.90 (but it doesn't do anything in 0.90 other than act as dead weight!)

These soundtracks need more love. OP, have you *TRIED* asking SQUAD to make them part of the game's soundtrack? Since you composed them yourself, you could offer them for free or a very small price... Regards, Northstar

This. 10 char

So is he. Even with procedural tanks, you still get a LEGO-like effect (trust me, I play with Procedural Parts mod as a matter of course). You just do it with a lower part count and less RAM usage. It's not just a matter of creating one tank for the rocket and being done, factors you have to account for include: (1) Diameter changes in the rocket. If conical fuel tanks can be built (which should be allowed) then you are going to want at a bare minimum one cylindrical fuel tank and one conical tank for every stage with a smaller-diameter stage built on top of it. You also have to decide how gradual or sharp of a diameter transition you want (sharper transitions allow for shorter rockets, but more gradual ones are more aerodynamic in shape- which will actually matter in stock with the drag overhaul) (2) Fuel allocation within the rocket. It's strongly advisable with a realistic aerodynamics model (where drag depends on shape rather than mass) to place and keep your mass as high up on the rocket as possible. Thus, even with the stock LF/O (and *especially* with the RealFuels mod) it is often advisable to separate your fuel and oxidizer into separate tanks to influence how the Center of Mass shifts as you burn fuel. This is even more important in planes (you don't want CoM to shift too far backwards). In stock, where Liquidfuel and Oxidizer are the same density, you want to place your Oxidizer towards the bottom/rear of your plane/rocket as the Center of Mass will then shift away from it (Oxidizer is consumed in greater quantities of mass than Liquidfuel, even in KSP- although this tendency is much stronger in real life...) With realistic fuels (which I really think should be a part of the stock game, as they make the game more believable than LF/O and give players more options for fuel-density vs. ISP), you want to place your Liquid Oxygen higher up on the rocket, as it is denser than Liquid Hydrogen or Kerosene... (3) Drop-tanks and staging. It is generally advisable from a Delta-V perspective to stage and/or use drop tanks. This inherently requires you to design several different sizes of fuel tank if the tanks are procedural... Anyways, I'm glad the devs are moving towards procedural fairings. I just wish they would give fuel tanks the same treatment... - - - Updated - - - Lego's don't slow time or cause spontaneous explosions when you have too many of them in one place. Regards, Northstar

Fairings ABSOLUTELY need to be procedural. Nothing makes me sicker than players trying to get useful features excluded simply because it doesn't fit their playstyle. You can always standardize YOUR fairings if you want, but procedural fairings gives everyone else a lot of flexibility... As for realism, consider this: in real life there aren't just 3 major sizes of rocket. Rockets come in a variety of sizes and shapes, from the enormous 10 meter Saturn V and 8.4 meter SLS, to the tiny 1.7 meter Falcon 1. Different rockets need different size fairings. The fact is, it just doesn't make sense to have a standard size fairing, just like it doesn't make sense to have a standard size fuel tank (if it were up to me, I would toss ALL the standard fuel tanks and replace them with procedural fuel tanks with various different possible textures available. It would save memory/RAM while improving player options at the same time...) You build a rocket to the size you want, and then fit a fairing on top of it. Frankly, beyond engines, I see no use for standard-size parts... At the VERY least, fuel tanks and fairings should be stretchable to any length, even if they only come in certain fixed diameters. Too bad SQUAD isn't making the fuel tanks procedural as well... Regards, Northstar

Absolutely not. Fusion reactors would allow us to DRASTICALLY improve the ISP of our rockets through fusion-thermal rockets. You think fission-thermal has good ISP? Wait until you see what a fusion reactor can accomplish (much higher reactor temperatures equate to much higher propellant temperatures and much higher exhaust velocities...) With fusion reactors, true spaceplanes (Horizontal Takeoff, Horizontal Landing) become within reach. A fusion reactor should eventually (with enough technological advancement) even be able to out-perform Microwave Beamed Power (which is the key to a lot of things that are just beyond our reach, like spaceplanes and extremely low-cost rockets: when ISP improves you can build a rocket to much looser engineering margins, and costs decrease exponentially with decreasing precision...) - - - Updated - - - I don't even know how to BEGIN summarizing this thread. Would you like to give it a try- I'm sure you can do a much better job than I can. Just send me a PM with a link to your post when you come up with something. Regards, Northstar

@NathanKell I've been working with FreeThinker on some more KSP-Interstellar/RealFuels compatibility, and functionality extensions to KSP-Interstellar itself (I've been testing a bit, and providing background/research, he's been coding). Sorry I didn't warn him you didn't want to be bothered about this particular cross-compatibility on this thread... But, since the cat is already out of the bag, would you forgive me if I asked for help on figuring out how to implement the changes listed in this post to the integration config? I don't have any clue how to implement them- do you have any ideas? Dreadicon seems to have gone AWOL from the KSP Forums since early December of last year (his last post was December 4th), and I don't have the faintest clue how to do something like make the built-in fuel tanks within the KSP-Interstellar ISRU refinery insulated... By the way, FreeThinker, maybe you'd have some interest in helping me mop up some of the remaining issues I posted in that post on Dreadicon's development thread some time ago? (not realizing he had just gone AWOL at that time, and wasn't merely away for a few days...) Also, I tested out the Atmospheric Scoops from KSP-Interstellar just a little bit earlier, and I can confirm that they produce LiquidFuel and Oxidizer instead of LqdHydrogen and LqdOxygen (I posted screenshots of it in the post below the one I linked to). I *HIGHLY* recommend implementing FreeThinker's additional lines of code in the KSP-I_RF file of RealFuels- so far he's been right on the ball with all the coding he's done or suggested for KSP-I/RealFuels integration... Thanks for all your great work FreeThinker! Thanks for listening to me and not ban-hammering me NathanKell! Further, I am experiencing an issue with the KSP-Interstellar Meth/LOX fuel tank- it appears to have no mass or fuel-capacity! This may be fixed by the suggestion FreeThinker made earlier about replacing the "&" symbols with commas... Additionally, the KSP-Interstellar (2.5 and 3.75 meter) "Pure Liquid Fuel" tanks are only carrying LiquidFuel instead of RealFuels propellants (these tanks were designed to carry large volumes of LiquidFuel as a feedstock for the Sabatier Reaction on Duna, and for KSP-I plasma thrusters. They're meant to hold large quantities of LqdHydrogen, basically, and should be insulated...) Finally, none of the Mk3 spaceplane parts seem to hold RealFuels propellants instead of LF/O, and the C7 Aerospace adapter parts (new in 0.90) also don't carry RealFuels propellants... I'm surprised those slipped through, considering they're stock... Regards, Northstar - - - Updated - - - P.S. That's AWESOME Regex! I took a look at Bac9's work, and am thinking about switching over to it from Procedural Dynamics once it gets a bit more mature... - - - Updated - - - @Starwasher The following Firespitter parts need to be made to work with RealFuels, in addition to the parts I listed above: FS2CF Passenger Fuselage (part folder is called "FS_crewFuselage") FS3OT Oxidizer Tank (part folder is called "FS_oxidizerTank") FS3J Jerry Can (part folder is called "FS_jerryCan") Also, the following part from NovaPunch2, which is a fuel tank/engine hybrid, only holds LF/O in the fuel tank (does it get fixed here or in the engine configs?) Odin Heat Shield (part folder is called "OdinShield" and is in the "Odin2" folder of the Parts folder of NovaPunch2) Regards, Northstar

I can now confirm Atmospheric Scoop issues with Hydrogen/Oxygen and RealFuels using the current resource definitions. Thanks for catching that FreeThinker! Regards, Northstar

Dreadicon, one more confirmed issue that needs to be fixed. While the code you wrote up for re-defining the LOX/LH2 resources generated compatibility for all ISRU Refinery-related functions, it did NOT fix the KSP-Interstellar "Atmospheric Scoop" parts. They are currently scooping "Oxidizer" and "LiquidFuel" instead of "LqdOxygen" and "LqdHydrogen". The following code needs to be integrated into the integration config, according to FreeThinker, who I have been working with on some additional RealFuels/KSP-Interstellar cross-compatibility with, as well as extensions to the ISRU functionalities within KSP-Interstellar (adding the ability to scoop Nitrogen, and use it for electric propulsion, such as to enable Propulsive Fluid Accumulators, for instance) @ATMOSPHERIC_RESOURCE_PACK_DEFINITION[InterstellarAtmosphericPack] { @ATMOSPHERIC_RESOURCE_DEFINITION[KerbinOxygen] { resourceName = LqdOxygen } @ATMOSPHERIC_RESOURCE_DEFINITION[KerbinHydrogen] { resourceName = LqdHydrogen } @ATMOSPHERIC_RESOURCE_DEFINITION[JoolHydrogen] { resourceName = LqdHydrogen } @ATMOSPHERIC_RESOURCE_DEFINITION[LaytheOxygen] { resourceName = LqdOxygen } } These additional MM patches should allow Atmospheric Scoops to scoop LOX/LH2 with RealFuels installed. Can't say I didn't warn you before these lines of code would be necessary, and your resource re-names wouldn't be enough. BUT, it's my fault for not catching this bug sooner. I never thought to test the Atmospheric Scoop part when I was testing the KSP-I/RF integration config we created before... Regards, Northstar

I meant what specifically does the error message say, and how did you find it... You explain the error message below though, so never mind... The code re-named the resources instead of specifically changing the atmospheric definition. Are you able to actually scoop LOX/LH2 with RealFuels installed using an Atmospheric Scoop on the Launchpad? In orbit? I don't understand that statement at all... An effect on what? So, there is a Module Manager issue with using an "&" in code now? I'll have to look into getting this fixed... And see if the Methane Tank is still functional... Regards, Northstar

That seems like a valid method if the vessel is close enough to the edge of the atmosphere to collect gasses (remember, the edge of the atmosphere in KSP is at an altitude/pressure more analogous to the Karman Line in real life- vessels still encounter very dilute gasses they can scoop above it, and still experience *greatly* reduced levels of drag...) What do you do for scooping *beyond* the official edge of the atmosphere? I thought you already said over on the KSP-I 0.90 port thread that you implemented code to allow Atmospheric Scoops to function beyond the Karman Line/ "edge" of the atmosphere (where KSP thinks no air is present). Didn't you say that in time-warp the vessel just collects 95% of what it would w/o time-warp, and you assume the remainder to be going to fighting drag? I think you mean 1/ISP (the inverse of ISP). Otherwise vessels with better ISP will expend MORE fuel fighting drag, which makes no sense. Using mass to approximate drag is also a TERRIBLE idea. In real life, drag is completely unrelated to mass- only to shape- and even the TWR affects of increased mass don't matter here- more massive vessels may experience less acceleration from the same thrust due to their lower TWR, but they also experience less acceleration due to drag as a result of their greater momentum. Once you're in orbit, you could keep a 1 MILLION ton vessel at speed with a 1 kN thruster if the vessel only experienced 1 kN of drag... In stock KSP, mass and drag are currently directly related (which makes no sense- it means a feather and a lead ball dropped at the same time inside the atmosphere would hit the ground at *exactly* the same time and speed...) but the stock aerodynamics model is soon getting a much-needed overhaul. I suggest just sticking with your 95% approximation (that is, 5% of collected fuel being used to fight drag- which is actually EXTREMELY conservative... A streamlined vessel will expend considerably less fuel on fighting drag...) for the time being, until stock aerodynamics gets its overhaul at the very least... Once stock aero is overhauled, hopefully it will internally record the number you need to make an accurate approximation of drag- which is the Ballistic Coefficient of the vessel when facing prograde (this is an inherent property of a vessel of a certain mass and shape) although it changes as a vessel gains or loses mass, what you want to do is multiply that in as an additional factor. So, fuel-consumption is proportional to: [Delta Time] * [1/ISP] * [ballistic Coefficient] * [Vessel Mass] You can simplify this further by choosing an arbitrary vessel mass and the corresponding Ballistic Coefficient (say when the Propulsive Fluid Accumulator's Nitrogen tanks are completely full) and multiplying them together, and then using that number in *ALL* calculations for that vessel unless it gains or loses parts (parts, *NOT* mass- mass is irrelevant, but parts can change the shape and thus drag of the vessel). However, drag varies greatly by altitude, planetary atmospheric composition (Duna's Thermosphere would behave very differently from Kerbin's, for instance), magnetic field strength (having little or no magnetic field, as with Duna, will influence Thermosphere conditions GREATLY), and even distance from the sun (again, Duna differs from Kerbin). The requisite math involved, which must take into account all of these factors is far too difficult for a single feature of KSP-Interstellar in my opinion- and I suggest you just stick with the 95% approximation permanently. However, if you really want to figure it out, I suggest you approach Ferram4 (the creator of FAR, he will know a lot more about the Thermosphere above the Karman Line than me) and the creator of the Atmospheric Trajectories mod (he already figured out a way to get his mod to access FAR's data on Ballistic Coefficient, and I think also temperature/pressure variations with altitude, in order to make re-entry predictions fro spacecraft...) That's going to happen at pretty much any altitude much above the Karman Line, so long as the vessel doesn't have huge flopping solar panels to generate excess drag (and then again, even *with* those panels at a slightly higher altitude). I can easily design craft that can operate profitably *BELOW* the Karman Line with FAR (and a streamlined designed) and Nitrogen-utilizing plasma thrusters, even in Real Solar System 64K: I just don't WANT to operate there, as then I can't use nonphysical time-warp speeds... Actually, the Atmospheric Scoop part looks a lot like what the parts on a real Propulsive Fluid Accumulator would. A real PFA would probably have an aerodynamic nosecone (to minimize drag, especially while ascending to orbit in the first place, and if it ever dipped below the Karman Line while collecting...) with a couple inline/radial intakes for scooping desired gasses (the Atmospheric Scoop part looks a lot like those intakes probably would). A PFA with REALLY high power levels available would probably have something that looks like a Ram intake on the front (which would generate a lot of drag, but also collect proportional amounts of gasses from that atmosphere), and all sorts of cooling equipment arranged directly behind that to chill the gasses into liquid form. Basically, a Propulsive Fluid Accumulator is a lot like a spaceplane without wings (it operates too high up for there to be any lift- which becomes impossible above the Karman Line)- it should be designed to make as much of the surface, and especially cross-sectional, area it exposes to the "airflow" (though hardly a flow at that density- proper airflows only occur below the Karman Line) intake area, and the rest of it as streamlined as possible. So, it could look like anything from a fat cylinder with a big scoop over the entire front end, to a long/narrow cylinder with radial scoops scattered along its length. The current Atmospheric Scoop parts suffice for a first-generation design (which would likely take a more streamlined approach to minimize drag in case of power or engine-failure, to give rescue craft more time to reach it, rather than a design based on filling the tanks as quickly as possibly by maximizing scoop area...) I wouldn't worry too much about it... I assume that, once again, you're talking about gas composition *ABOVE* the Karman Line (the edge of space in KSP, and also the approximate start of the Thermosphere in real life...) Below the Karman Line, gasses are comparatively well-mixed. You know what, I think a couple lists are in order... Atmospheric Traits BELOW the Karman Line (100 km in real life, 70 km in KSP) - Gasses are comparatively well-mixed, gas composition does not vary greatly with altitude - Gas density varies GREATLY with altitude: pressure falls off in accordance with the planet's Scale Height - Gasses are comparatively dense compared to above the Karman Line (this is a RELATIVE term- at the Karman Line, atmospheric pressure is incredibly tiny at this altitude) - Aerodynamic Lift is possible - Drag is comparatively high relative to atmospheric density Atmospheric Traits ABOVE the Karman Line (100 km in real life, 70 km in KSP) - The Karman Line is roughly where the Thermosphere begins. The temperature of the atmosphere climbs to very high levels, increasing gradually with height. - Gasses start to become stratified by molecular weight above this point... - Atmospheric pressure falls off VERY gradually compared to at lower altitudes. - Aerodynamic lift is no longer possible - Drag is comparatively low relative to atmospheric density (which is even lower) as atmospheric particles become too far apart to be properly compressed above this point... (they are simply moved aside by a spacecraft) Regards, Northstar

The following code is already present- hammered out by myself and Dreadicon. There was some debate between the two of us about whether it would work, but it seemed to do the job just fine for tasks like Water Electrolysis (which produces Hydrogen and Oxygen). Does it not work for the Atmospheric Scoop? @WARP_PLUGIN_SETTINGS[*]:NEEDS[WarpPlugin]:FOR[RealFuels] { @HydrogenResourceName = LqdHydrogen //LiquidFuel @HydrogenPeroxideResourceName = HTP //H2Peroxide @AmmoniaResourceName = LqdAmmonia //Ammonia @OxygenResourceName = LqdOxygen //Oxidizer } Precisely what errors are you getting? Where do they show up, and how do you know that they are occurring? I have the game open in another window right this very moment with KSP-I 0.90 port and the 0.4.1 Extended Config, and I didn't notice any issues yet. That doesn't mean there aren't any- just that I haven't found them yet... Regards, Northstar

Oh, well then the KSP-I 0.90 ports needs to update to 2.5.9 (and I do as well) EDIT: Freethinker, the KSP-I 0.90 + 0.4.1 Extension Config at least loads fine for me with MM 2.5.8, RealFuels 8.3 + Stockalike Engines Config 2.0.6, Real Solar System 64K, Procedural Parts, Deadly Re-Entry, FAR, and quite a few other mods installed- so far so good... EDIT #2: A thought that occurred to me while I was waiting for a helicopter to fly the long distance to the mountains west of the KSC for some biome science... (the KSP-I 0.90 port locked my main launch vehicle, as it relied on the HECS probe core for a Space-X style reusable launch stage, and the KSP-I 0.90 port tech tree is broken in that it utilizes the 0.25 tech tree with regards to node locations for pre-existing parts such as the probe cores: which were moved to earlier tech nodes from 0.25 to 0.90) Could the code you utilized to allow Atmospheric Scoops just above the atmosphere operate while unloaded or in nonphysical time-warp also be utilized for Atmospheric Scoops on the ground? I ask this because certain resources are useful to gather from the local atmosphere using Atmospheric Scoops rather than shipping from Kerbin, such as Oxidizer/LOX on Laythe, and Argon on Duna... Right now, its possible to gather them with an Atmospheric Scoop in nophysical time-warp, but (to my knowledge) it has to be the loaded vehicle for this to work correctly- which could become EXTREMELY annoying with multiple active missions at a time... Regards, Northstar

Sorry for the solid wall of text, but two more things: @FreeThinker You should deleted the "Asteroid" and "Resources" .CFG files from the Regolith folder you included in the Extension config. I understand you need the Regolith .DLL for the ability to make Atmospheric Scoops work just outside the atmosphere, but you don't need the "Asteroid" or "Resources" files- which refer solely to asteroid-mining for resources. If players want to utilize that mechanic of Karbonite (which might be wise, since SQUAD has announced they will be using Regolith/Karbonite as a framework for some parts of their ISRU system, particularly when it comes to asteroid-mining), they can install Karbonite separately, and overwrite the Regolith folder with the more complete one including these files. Personally, I don't play with Karbonite, and don't need to waste a single Byte of disk space on my pathetically weak laptop (which currently has jsut over 1 GB of free disk space...) @Boris The KSP-Interstellar 0.90 port download should be updated to include the ModuleManager 2.5.8 .DLL instead of the 2.5.6 .DLL as older versions being present can create issues with the proper functioning of newer versions, and 2.5.8 is requited for some other mods. I assume KSP-Interstellar 0.90 still works correctly with MM 2.5.8 instead of 2.5.6? If not, I'm about to find out *VERY* soon, as I just installed the port (and FreeThinker's Extension Config- which I ardently suggest you integrate into the main 0.90 port version) and am about to run KSP for the first time since adding the new mods... Regards, Northstar - - - Updated - - - Wait a second- is it an elliptical orbit or a circular orbit the Atmospheric Scoop needs to function correctly? I made a point of indicating before that circular orbits work *better* for Propulsive Fluid Accumulators, because it means they have a lower average velocity when they are close enough to the planet to scoop significant amounts of the desired gasses (which for a low circular orbit, is all the time- whereas an elliptical orbit may pass in and out of this region), resulting in lower atmospheric drag. Objects in circular orbits are also slightly easier to target (with Microwave Beamed Power or communication systems) and communicate with, and there's no point in expending the energy putting a Propulsive Fluid Accumulator in anything higher than a circular orbit *just* above the atmosphere in the first place... When operating *below* the Karman line for part/all of the orbit, it's a slightly different case- because an elliptical orbit allows you to spend part of your time outside the atmosphere, making up the velocity you lose when near periapsis with your plasma thrusters. This allows a Propulsive Fluid Accumulator to get by on less thrust/power, but actually hurts the energy-efficiency per unit of gas collected (you might scoop 50% the gas for 75% the electrical requirements, to give some arbitrary numbers) as you benefit more from the Oberth Effect when traveling faster, and a low circular orbit has a higher average velocity and lower average altitude than an elliptical orbit with a higher Semi-Major Axis... But the bottom line is this: if you have enough power to run your plasma thrusters on a high enough setting to counteract drag at the same rate it is occurring, a low circular orbit is *always* more efficient for collecting a single type of gas (see my note below). An elliptical orbit is only desirable for collecting just one gas when your thrust is exceeded by drag at your target scooping altitude... Regards, Northstar P.S. There's one other potential advantage of an elliptical orbit. In the Thermosphere, gasses layer according to molecular mass, with lighter elements/molecules being found further up. So, with an elliptical orbit you can pass through the regions for multiple different gasses (say diatomic Nitrogen and ionized elemental Hydrogen) and collect several different resources with a single Propulsive Fluid Accumulator without having to perform burns to move to different orbital altitudes... However modeling different layers for different gasses above the Karman Line is a rather involved project (basically on the order of complexity of when Fractal_UK added magnetic field lines around the planets to determine Antimatter concentrations and radiation exposure), and not something I have the nerve to request you add into the Extension Config... (it may not even be worth the additional RAM usage from a gameplay perspective, considering how little of a Delta-V difference there is between the different Thermosphere layers...)

Hey, Just an update for y'all (sorry to necro an old thread, but it's better to necro a relevant thread than to create a redundant thread on the same topic and lose all existing conversation/thought...) FreeThinker has created an Extension Config for the KSP-Interstellar 0.90 port, which now allows any player to utilize RealFuels-compatible "Nitrogen" (or a new KSP-Interstellar specific "Liquid Nitrogen", which represents the cryogenic rather than gaseous form of Nitrogen, and is much denser but more expensive to purchase and store...) as an electric propellant for the KSP-Interstellar plasma thrusters, and allows Atmospheric Scoops to work *just* outside the edge of the atmosphere (in circular orbits up to +10% of atmospheric height, which represents the fact that most Propulsive Fluid Accumulators are designed to operate above the 100 km Karman Line in real life- which 70 km acts like in KSP...) thus allowing players to create Propulsive Fluid Accumulators schemes of their own in KSP-Interstellar without any additional mods or modding required (although installing RealFuels will also allow you to use "Nitrogen" for RCS, like in real life). Please take a look at the Extension Config, and let's get some Propulsive fluid Accumulators of our own up in KSP! Maybe it'll draw some attention (if it becomes a "thing" in KSP- remember many NASA engineers and administrators play KSP in their free time), and make NASA realize that for the past 10 years (since Microwave Beamed Power became feasible with recent advances in gyrotrons- no longer requiring a nuclear reactor to be launched to orbit for a PFA when you can just keep the reactor on the ground and beam the power to operate a Propulsive Fluid Accumulator to Low Earth ORbit instead...) we've had all the technology we need for *virtually unlimited* FREE (no marginal cost for additional fuel- decently expensive set-up cost for the whole system) propellant mass in the form of unlimited quantities of Nitrogen in space... (Nitrogen can be utilized for either electric propulsion, or in thermal rocketry where higher thrust-levels are required for manned missions... A heat source is still required for thermal rocketry, however- either a nuclear reactor, or Microwave Beamed Power from somewhere else, including coal/wind/natural gas/hydroelectric/nuclear power plants on Earth if desired...) Regards, Northstar