NonWonderDog

February 5, 2015

I'm not sure I said anything about textures. I'm not changing the part sizes, just how much they weigh. I can't get away from that -- a hydrogen tank has to weigh less than a kerosene tank or nothing makes sense. This is all done programmatically, and I'm going to try as hard as I can to keep all mods compatible without having to tweak each part individually.

The 6.4x mod doesn't change part sizes either, just the planet sizes and interplanetary distances. Although I guess the terrain doesn't look quite as nice as stock.

@thorfinn

H2O2/kerosene sounds utterly mad, but I like it. I'll look into that. It might be hard to get to work at 55/45, though.

February 5, 2015

I don't see the point. Better would be to just remove reaction wheels from plane cockpits, if the problem is reaction wheels in atmosphere. If someone still wants to throw a reaction wheel on instead of using control surfaces... let them? Cut the reaction wheel torque by 5x or so and nobody would even want to do it (I have a modulemanager config to do this for myself -- mostly because I don't like how ridiculously fast the pods can spin themselves).

And who cares if someone parks on a slope.

There are no gravity gradient (tidal) effects on spacecraft anymore in KSP since 0.10 or something. Without those, there are very few ways to permanently store significant angular momentum on a spacecraft outside of physics glitches. Really the only way you'd notice is if you spun up before decoupling something heavy. There would be a smaller effect if you spun while thrusting due to the loss in propellant mass. But if you just turn from one vector to another, the net angular momentum is zero. The reaction wheel spins to start you turning, and stops spinning to stop you turning.

It really seems like people are misunderstanding why this is an issue for real spacecraft. Even if implemented, it wouldn't change anything about space operations without HarvesteR making gravity work on every part individually again. And even then, I can't think of any in-game reason you wouldn't just let your ship align to the gravity gradient. And even then, it wouldn't do anything during time acceleration, so you'd have to be fighting gravity gradient for a week straight at no more than 4x normal speed before the gyros saturated.

February 4, 2015

One question that I did before and nobody answer me.
This mod will have configs only for 6.4x version? Also, what does it mean in scale? Kerbin scale and solar system scales? Why RSS is 64x? I thought that RSS was 10x
Now.. about balance.. I guess you will make a mistake that many mod developers do; try to match real physsics and numbers with low KSP scales.
Squad implement low kerbin system scales to avoid wait 10 mins for each test or attempt to reach orbit. But they wanted to had (even at low scales) similar rocket looks and masses (with fuel consumptions in %), with similar deltav losses in % due atmosphere drag.
For example, FAR improves all the aerodynamics system with real values and equations, but it does not match deltav % losses due drag in low scale kerbin.
Another example: If you want to make real solar panels for low kerbol system scale, then you take 1 au as kerbin-kerbol distance, then you match 1366w/m2 at that distance and apply this equation using AU as distance unit:
E = 1366 Ã¢â‚¬Â¢ (1/Distance)2 to find how radiation incidences decrease or increase due distance.
With RSS is easy, you just match real equations and numbers and thats it. But you need to work a bit more.
You need to find the right parameters on engine mass, or fuel consumption equations to match similar rocket aspects at 6.4x
Then you decrease your time to orbit, but it will still looks like real in all the other aspects.

There's a config for RSS that scales the Kerbol system to 6.4x it's normal size. The idea is that, with realistic thrust, mass, Isp, and aerodynamics, if Kerbals lived on a planet 6.4x the stock size they would build rocket parts as big as they are in stock. That way we can all be happy; we have realistic aero and materials, the game isn't trivially easy, it's still possible to go to Jool or fly to space in an SSTO, and it's still a game focused on little green men who live on a little green planet. Note that the concept of realism I want here has nothing to do with what kind of rockets the US and USSR built in the 60s; I just want planets that have densities more similar to those of planets than neutron stars, fuel tanks with the density of aluminum instead of lead, and rocket engines that have thrust-to-weight values greater than those of jet engines. All the systems in stock KSP work together to give something mostly reasonable most of the time, when combined in the expected way, but there's little room to squeeze multiple fuel types in there without breaking things horribly. And in the end, I'd rather just have things that work like the things they're supposed to be.

I'm just not interested in making up fantasy fuels and giving them fantasy performance just to try to fit a stock KSP balance that might change drastically when 1.0 comes out. First of all I don't think I'm a good enough game designer to make anything more interesting than real astronautics, but moreover if I base performance on physics it's just physics and it doesn't change. Also, the idea isn't to make you build rockets as big as in real life. Kerbals don't live on Earth. The idea is to make the rockets work like rockets, and scale the universe until it's a good game. I just happen to think that 6.4x is about the right gameplay scale.

But as a more direct answer to your question, there's a parameter called "useRealisticMass" in the config (since this is based on RealFuels). If set to "false", the masses are multiplied by a factor in order to give delta-v values more like stock. Or at least they will be, once I've tuned it to do that. Using it will probably make liquid hydrogen pointless, but if real fuel tanks weighed as much as Kerbal fuel tanks we wouldn't use liquid hydrogen in real life much either. (That of course means nuclear engines are useless, too, so they'll have to use denser fuels. And from there it's only another round or two of cascading balance changes before we're back to one fuel type for all engines.)

February 4, 2015

Things are progressing:

Javascript is disabled. View full album

That (very stupid) rocket has about 6 km/s delta-v with stock KW parts, which jumps to 8 km/s using realistic tank and engine masses (the capsule is still insanely heavy). That's probably okay for 6.4x, maybe a bit low; I'll make an option to scale it back later. You don't need a first stage *quite* that big for hydrolox to be so obviously the best choice, but it's good to see that it comes out on top at some point. (Methalox is always just kinda average.)

Fuel tanks in NearFuels are about 6% dry mass, compared to 11% dry mass in stock and 2.7% dry mass in RealFuels. Hydrolox tanks are about 8%. I've defined a thinwall tank at about 4% for less-structural things like the Shuttle ET. As far as I know these are representative numbers; Atlas V and Ariane 5 are significantly better, Soyuz and Energia are a bit worse, and maybe 5.5% is a more reasonable average. I think RealFuels uses paper-thin tanks to make up for the way everything else on the rocket is too heavy, but I'm not going to do that.

I did have to slightly go back on my pledge and change the masses of LiquidFuel, Oxidizer, and MonoPropellant. The 55/45 unit ratio was most important in the end, and with real densities that's a perfectly realistic mixture ratio for NTO/UDMH. I still won't touch any of the Community Resources Pack resources.

I am going to reduce the thrust-to-weight, or at least the thrust and weight, of the high-Isp engines further than what's in those screenshots. Currently the TWR are scaled based on the density of the combustion chamber gasses assuming a constant pressure (less dense = bigger chamber for same thrust = lower TWR). That makes sense, but it ignores the turbopumps. I'll probably just keep the masses constant like now but scale thrust to a constant volumetric flow rate, so burn time doesn't depend on fuel. Right now hypergol launch engines have a TWR of 100 while hydrolox is at 60; after the change hydrolox engines will fall to I think 40 or so. (Compare RD-264 at ~130 TWR vs RS-68 at ~50 TWR.)

As of now all engines are launch engines, and they all have the same Isp and TWR. I'll work that out before I release something. My idea at the moment is to define a standard engine, find a deviation from that standard for each engine, and apply the difference (at some power) to the final modular engine. I already have standards for launch, upper stage, vacuum, etc. engines. The implementation is simple; I just have to work out what the powers need to be.

(Source is here, but I don't recommend it yet. I need to update the readme, too...)

January 31, 2015

I dunno, I kind of like the bumpy runway. I like that it's silly.

Actually, with BahamutoD's Adjustable Landing Gear, FAR, and a joystick, I don't really have any problem landing a (very small) plane on the bumpy dirt runway. I think the problem here is the suspension on the stock landing gear, not the bumps.

January 28, 2015

The whole point of this mod is to reduce the number of fuels used in standard engines. It simply replaces the stock "liquidfuel/oxidiser" with a handful of different types of liquid fuels and oxidisers, but far fewer than the RealFuels mod adds.
It does not however affect the total number of resources, so KSPI resources are entirely untouched.

Mostly this. I'm not even replacing LiquidFuel/Oxidizer (I'm just pretending they're named UDMH/NTO), and the only resources I'm adding are LiquidOxygen and Kerosene (as of two posts ago). I might add AvGas as well, just for the AJE piston engines.

All the other resources are from the Community Resources Pack, wherever they got them from. Mostly I'm just allowing engines and fuel tanks to use the CRP resources in a way that follows reality at least a little bit.

Nuclear engines can in principle run on anything, but I haven't decided how far I want to take that. I'll start with LiquidHydrogen and LqdMethane, at least. Ammonia, LqdHelium, and Water are the other reasonable choices, but all are terrible propellants (with helium being particularly pointless). Kerosene and UDMH could even make the list, but I don't really know what their performance would be like. Bipropellant NTRs I haven't given much thought to.

January 27, 2015

EDIT: Also, the SLS SRBs should, all going well, have the Space Shuttle ones replaced by "advanced ones". Sadly, I can't seem to find any concept art of them other than this. Might be groovy to model the NASA SRBs (..Sally) after those.

I think those "advanced" things are just some NASA artist's imagination. Drawings of the "real" ones are in the ATK catalog (as 1, 1.5, 2, 2.5, 3, 4, and 5 Segment RSRM, both fixed and vectorable nozzles), and they look pretty much exactly like the Shuttle SRBs. The advanced ones haven't finished bidding, so there's not really any design you pin things on.

That catalog is fun, by the way. It has thrust curves for a large percentage of all the solid rocket motors ever flown in or on the way to space.

[EDIT]

Here's the closest thing to the advanced SRBs: http://www.nasaspaceflight.com/2013/01/the-dark-knights-atks-advanced-booster-revealed-for-sls/

Here's the F-1 engine booster referenced by GregroxMun: http://www.nasaspaceflight.com/2012/11/dynetics-pwr-liquidize-sls-booster-competition-f-1-power/

January 27, 2015

I spent more time playing with the numbers, and it's actually looking a lot better than I thought.

Javascript is disabled. View full album

If I go with LiquidFuel/Oxidizer as UDMH/NTO, then I gain in compatibility and realism, but lose any last vestige of the tank units as volume.

By setting LiquidFuel/Oxidizer to Kerosene/LOX, all I really gain are whole numbers in single-resource tanks.

[EDIT] I've understood the RealFuels math a bit better, and managed to get whole numbers into all the bipropellant tanks. I've updated the images.

Any thoughts? I think I'll go with this unless anyone can give me a good reason not to.

January 27, 2015

Another example is Topaze (the second stage of the Diamant rocket):
http://www.avas.free.fr/aventure/lrba/diamant/histoire%20diamants%20a/diamantA%20etage2.jpg

But the RT-10 is almost exactly the same size and shape and propellant mass as the Orion 50 (Pegasus second stage). Just without the vacuum nozzle and twice as much thrust:

January 26, 2015

I haven't had a chance to play the game really at all, but your failure check seems pretty harsh. It's got an exponentially increasing *chance* (not rate) of failure, and after the "MTBF" time parts have a 50% chance of failing every five seconds. That's probably fun for testing the mod, but seems like it would be impossibly aggravating if you were to play with this mod on all the time.

For a "correct" MTBF implementation this:

survivalChance = Mathf.Pow(Mathf.Exp(1), currentFailureRate * operatingTime * -0.693f);

should probably be:

survivalChance = Mathf.Exp(-currentFailureRate * (operatingTime-lastcheck));

or equivalently:


protected double lastReliability = 1;
protected double currentFailureRate = 1/MTBF;

public double reliability(operatingTime) {
    // assuming MTBF and operatingTime are in the same units
    return Mathf.Exp(-currentFailureRate * operatingTime);
}

...

    r = reliability(operatingTime);
    survivalChance = r / lastReliability ;
    lastReliability = r;

That would give a perfectly constant chance of failure over time, no matter how often you check (with max reliability in the last case set by the resolution of "Random.value", unless you can use "Random.NextDouble()"?). If you wanted a different failure distribution you could just extend the class and change the reliability function.

If I went that route I'd probably also make it ignore all failures past the first when resuming from time acceleration, as a difficulty option. Just so things don't get out of hand.

(I don't have any experience with C# or Unity; is there some reason you're using "Mathf.Pow(Mathf.Exp(1),...)" instead of "Mathf.Exp(...)"?)

January 26, 2015

Please do not call Liquid Oxygen (LOX) a.k.a. "Oxidizer" when the game representation is clearly similar to Dinitrogen Tetroxide (NTO) as KSP "Oxidiser" can be stored indefinitely
Question what ratio do you use Hydrolox (LiquidHydrogen and LiquidOxigen) as a rocket fuel?

The problem with that is that Oxidizer and LiquidFuel have the same density, and although the relative densities are wrong they yield a combined density very similar to LOX+Kerosene when used together.

Real NTO is nearly twice as dense as UDMH, and when used together are stored at a density 15% greater than that of LOX+Kerosene.

That, and most of the resources in the Community Resources Pack are given densities assuming that LiquidFuel+Oxidizer represents kerolox. If I want to use Oxidizer for anything, it has to be LOX. I'm planning on setting most rocket engines to use NTO/UDMH by default to keep things close to stock.

Mixture ratios by mass and volume are in the "propellant details" box. None of them are "right," but they should be "near enough." I've set hydrolox to a mixture ratio of 5.36 (a bit too hydrogen rich), but since CRP's LiquidHydrogen is too dense the tanks are only 70% hydrogen by volume. It ends up taking up as much total space as if you were running a mixture ratio of 5.85 (but if you run NTRs on straight hydrogen you can carry 10% too much).

[EDIT]

It's not impossible to set Oxidizer to mean NTO, it just means I have to give up on tank volume being consistent.

With the system described in the OP, a 200 unit tank holds 200 units (or 250 for MonoPropellant or methane). If I set it so that Oxidizer means NTO, that isn't true anymore. See next post...

January 24, 2015

-Names propellants using a (simplified) kerbal psuedo-chemistry rather than RL options with kerbal element names. This should produce fuel consumption (and ISRU yields) that are round numbers
-Exaggerates performance differences between fuels slightly to make for a more important choice
-Using the kerbal pseudo-chemistry create the opportunity for interesting ISRU cycles that are a bit less involed than, say, KSPI's

I've thought about using some gamey names for UDMH and NTO, just because I want them to be the default and it seems stupid to switch from NTO/UDMH to Oxidizer/LiquidFuel, but I can't come up with anything catchy.

UDMH is obviously RocketFuel, but that seems slightly wrong when contrasted with LiquidFuel.

NTO I have no idea. StorableOxidizer isn't punchy enough, and doesn't communicate why you can't use it with LiquidFuel.

They're all going to remain real chemistries, though, if only so I have a sane starting point for balancing. I'm not getting involved in ISRU other than supporting it implicitly through the Community Resources Pack, so Karbonite can continue to use whatever fantasy chemistry it wants.

Anyway, I have a spreadsheet that I've been working on, a bit less far along that I would have hoped: https://docs.google.com/spreadsheets/d/1KSPXBB7VRV1kYvwpdRBPyFg87KAmiN1FJNQKBQJN-AE/edit?usp=sharing

(I have Office365 through work, so that's just a copy of my Excel sheet. It's spectacularly overcomplicated (although a bit better in Excel).)

The "Propellants" tab shows the current plan. The "PropellantsRemass" tab shows a perfect world where I'm free to change masses to whatever I want. I got them closer than I expected after a bit of fiddling, and with whole numbers in the fuel tanks. The only really wrong things are the volume ratio of kerolox and the density of methalox. The "Tanks" and "Engines" tabs are what I'm doing next.

Also, please make all engines universally compatible. I would personally prefer making Storeable Fuel and Monoprop one and the same. It's a lot cleaner and I don't really see a compelling reason for the distinction between Hydrazine and UDMH.

UDMH and hydrazine are separate because I think they're different enough (hydrazine is 20% denser), and I want to allow a bipropellant RCS mixture somewhere in the tech tree. Soyuz uses NTO/UDMH for all the spacecraft thrusters now, after all, and the Shuttle used something close enough (MON3/MMH). I also want to make certain tanks -- the ones in command pods, or the radial spheres -- capable of holding only a single fuel type at once. Combined with the different flow behaviors you'd get a choice between simplicity (Hydrazine) or efficiency (NTO/UDMH), made more complicated if you aren't using NTO/UDMH for your service engine.

But I'll take that as a vote for option 5 in the OP.

(Of course in real life Buran used GOX/Kerosene RCS, and LOX/LH2 and LOX/LCH4 RCS are under heavy development. Maybe for the end of the tech tree.)

January 20, 2015

I don't remember it that way, but I guess I never found getting to orbit as challenging as others did, and with all the time I spent on the Mun (and Duna when it came out... ohhh the heady days of discovery!) it likely didn't stick in my mind.

Yeah, that was nostalgia from 0.7.3. I did manage to make it to orbit, once. It took a *lot* of boosters, and after that I basically considered the game beaten. (According to the wiki on 0.7.3: "It is nearly impossible to achieve orbit." Bah!)

The great atmosphere thinnenning happened well before the Mun, but my memory's hazy on when C7 aerospace started. A quick jump to the wiki says the atmosphere changed in 0.10.1. Before that it was basically 1 bar right up to 34500m, where it just ended.

January 20, 2015

As to your MonoPropellant problem, I'd just change the densities to match what you need. It's pretty easy to do a MM config to globally adjust the amount of a resource, so you can scale your density change to your resource change. For example, in my RF configs for Karbonite, I scale karbonite's mass down 1/5th, but increase the amount of resources in each karbonite-carrying part by 5x. Ends up with the same mass anyway. I'm not sure specifically how your math would end up. Alternatively, we're dealing with little green people in a game. If anyone is going to be upset with hydrazine or UDMH not being exactly the right stats, then they should be playing full-on Real Fuels anyway.

The problem there is ISRU mods. For some reason nobody thought to make ModuleResourceConverter or REGO_ModuleResourceConverter obey conservation of mass. Instead of outputting a mass ratio of resources at an efficiency they output volumes, which is just silly. There might be other mods that start violating basic laws of physics if I go around changing resource densities willy-nilly as well, which one of the reasons the CRP exists.

That said, it's pretty trivial to change all the ModuleResourceConverter nodes that touch MonoPropellant using ModuleManager. Changing REGO_ModuleResourceConverter and KolonyConverter nodes that way is much, much harder, but it's probably possible with a combination of regexes and variables.

It's easier just to let you store hydrazine at 20% compression. I think that's all I actually need to do. I don't want to do that to adjust the bipropellant densities because I'd rather the tanks stay one volume, so I didn't really think it over.

What are you plans concerning engines that already run off monoprop such as RLA stockalike's engines?

I guess they'd get the choice of MonoPropellant or UDMH/NTO, just like RCS. For MonoPropellant engines I might gate UDMH/NTO in the tech tree, or maybe having to send fuel to your RCS with big yellow pipes would be penalty enough. Maybe I could add a late-game HAN fuel (250 Isp, 1.6 kg/L), but that would probably just obsolete MonoPropellant.

January 19, 2015

I saw the old mod, briefly, and saw a few problems:

It was a ground-up implementation, when RealFuels already existed. It was a lot of duplication of effort for what turned out to be no benefit in the end, as RealFuels has all the same features.
ModuleManager variable support didn't exist. The only way to do it was either to edit every single mod engine by hand or build a re-implementation of ModuleManager in "a .dll so massive, that it would have appreciable gravity."
It (apparently) made minimal effort to approximate realistic fuel trade-offs. This isn't a killer, but hydrolox was (apparently) unrealistically impossible to use due to the bulk.
It tried to set up a new ISRU framework. Na ga ha pen. That's better left to ISRU mods, using the Community Resources Pack as an interface.
As a meaningless nitpick, including Aerozine-50 is way too US-focused.

I'm doing this on top of RealFuels and ModuleManager, and I'll probably need to do very little by way of C#. Everything I'm thinking of should be doable with ModuleManager configs, as excessively complicated and hard to debug as they might end up having to be. I'm still working through the math on tanks and engines, though, and haven't really gotten to the implementation stage. At least the generic Modular Fuel Tanks config is already half-done and working.

Available mixture ratios should be gateable by the specific impulse and thrust of the original engine in ModuleManager with a bit of outside-the-box thinking (by using progressive string comparison on numbers, or possibly by doing stack-style math with variables), if we don't just want to give every mixture to every engine. Or something more complicated (and easier) in C#. I'll have to see if RealFuels allows me to gate fuels by tech level, as well. Anything more specific would need a config. I'm not really against every fuel on every engine, though. UDMH/NTO was responsible for a LOT of first stage launches (Proton, every Chinese rocket, Ariane-1), and even more if we count UH25 and Aerozine-50 (which we should). And the Soviet N-1 rocket used kerolox on every stage, and was possibly the most kerbal rocket ever developed, so why not allow kerolox upper-stage engines?

It's probably better to make UDMH/NTO the default, with kerolox an option for cheaper, more efficient launch vehicles. My problem with that is mostly terminology: the generic "LiquidFuel" and "Oxidizer" wouldn't be the defaults. Those need to be kerolox for the math to work. (If only there were a "PartResourceDefinition.displayName")

Nuclear-thermal rockets can be expanded upon later, but that's one for the roadmap. The problem there is the tangled web of other mods adding specific nuclear-thermal rockets. I don't really want to step all over them, but then again I do need to make sure they don't run on kerolox.

Finally, active boiloff mitigation is a funny thing. I'm actually tangentially related to such a project IRL, but the physics are very unintuitive. I have to confess that I don't understand any of it. I'm just going to blindly follow the RealFuels implementation for now, since I don't know enough to improve on it. There does need to be a cryocooler part somewhere in the tree, though. Perhaps one that runs on electricity, and a more realistic one that runs on hydrolox just to confuse people.

January 18, 2015

The spaceplane parts were originally a mod that Chad (and IIRC WinterOwl contributed a few parts as well) created back around the .13 era of KSP. Prior to the Aerospace Pack (which was the second mod to be made stock), I don't believe there were any form of aerodynamics at all (let alone orbital mechanics or an actual requirement for oxidizer).
Based on posts and podcast comments made by HarvesteR and C7 here and on other forums, Squad pushed aerodynamics back as it wasn't an urgent priority (likely since since FAR was available) compared to post-kerbin features that they needed to implement, and both HarvesteR and C7 assured us that once the game was scope complete that they would focus on fixing the aerodynamics and rebalancing the parts.

We had orbital mechanics of a sort before we had a map screen, and well before we had time warp (if you consider "Kerbin as the center of the solar system" to be "orbital mechanics"). Of course, back then the rockets were a lot wobblier than today, could barely stand more than eight or ten tanks tall, and barely had the power to push themselves through the atmosphere. Making it to orbit was difficult until struts came along. Really the only thing the game had going for it was potential and Jeb's smiling face.

We're actually on Souposphere Mk 2, which I think I remember being driven by C7's mod. Souposphere Mk 1 was MUCH thicker.

January 18, 2015

This doesn't exist yet.

I'm fully intending to implement this as a branch of RealFuels, but for now I'm just wondering if anyone has any comments on a bit of a design document I've put together:

NearFuels

by NonWonderdog, based on work by taniwha, NathanKell and ChestBurster for

Modular Fuel Systems Continued.

ialdabaoth (who is awesome) created Modular Fuels, and this is a fork of the RealFuels branch.

License remains CC-BY-SA as modified by ialdabaoth.

ModuleManager is required.

KSP Alternate Resource Panel is recommended to show friendly resource pictures, in addition to all its other great features.

DESCRIPTION

NearFuels is a minimal implementation of RealFuels, intended to provide maximal mod compatibility. LiquidFuel, Oxidizer, and MonoPropellant are still present, but now represent actual chemistries. 100% Community Resources Pack compatibility is assured -- installing this won't prevent you from colonizing Duna.

The major goal of this mod is to allow more choices in design, without forcing them upon you. You'll be able to choose whether to build a kerosene or hydrogen launch vehicle, but if you don't care to do so you can just slap parts together and hit launch. Storable propellants or off-world refueling will be necessary for long missions, however, due to cryogenic boil-off.

A secondary goal of this mod is to allow realistic Kerbal-scale rockets in a 6.4x scale solar system. The desired effect will be similar to using RealFuels in 64K, but without the sacrifice in mod compatibility that comes along with that. Game balance should be only slightly "harder" than stock, but will allow realism mods such as FAR and AJE without having to design around super-heavy engines and fuel tanks. An investigation of command pod and structural part densities is planned for the future.

Kerosene (Kero) - Kerosene
Low sulfur grade A-1 kerosene. Jet fuel. Truck fuel. Boat fuel. Rocket fuel. High energy density and stability makes it very flexible.

Liquid Hydrogen (LH2) - LiquidHydrogen
The most efficient fuel available, with Isp values some 30% better than Kerosene mixtures. Unfortunately the low density means huge tanks are required for sufficient delta-v, and the extremely low cryogenic temperature leads to significant boil-off.

Liquid Methane (LCH4) - LqdMethane
A denser fuel than hydrogen, with boil-off rates similar to liquid oxygen. It's a middle of the road solution, providing neither the density of Kerosene, nor the Isp of hydrogen, but it's easy to synthesize from just about anywhere in the solar system.

Hydrazine (N2H4) - MonoPropellant
Simple hydrazine provides better performance then UDMH, but is too difficult to use in large rockets. It's used as a monopropellant.

Unsymmetrical dimethylhydrazine (UDMH) - LiquidFuel
A more stable, but no less dangerous, formulation of hydrazine used in bipropellant rockets. It's liquid at room temperature and can be stored indefinitely. It differs from regular old hydrazine by increased thermal stability and a lower freezing point, making it useful for cooling rocket engine nozzles. It's also quite cheap -- at least if you don't read the warning labels.

Liquid Oxygen (LOX) - LiquidOxygen
The most obvious oxidizer, and the easiest way to make things burn. It's stored at low temperature, so some will be lost to boil-off.

Dinitrogen Tetroxide (NTO) - Oxidizer
A powerful oxizider that bursts instantly into flames when put in contact with any of the various forms of hydrazine. Like hydrazine it is liquid at room temperature and can be stored indefinitely.

NTO/UDMH
This is what people usually think of when they think "rocket fuel." Explosive, caustic, volatile, and near instantly lethal if inhaled. Naturally, it's your default fuel. The two propellants can be stored indefinitely and ignite instantly when in contact with each other, making it popular for spacecraft and launch vehicles alike. This mixture can be used in any size of engine, from RCS thrusters to massive launch cores.

Kerolox
Kerosene and liquid oxygen. It's easy to handle, cheap, and performant. This is the generic fuel for launch vehicles and spaceplanes, and the oxygen boil-off is irrelevant over short periods.

Hydrolox
A difficult fuel to use due to the low density and rapid boil-off, but by far the most efficient. It has the further benefit that it can be produced from water, given exorbitant amounts of electricity.

Methalox
A middle of the road fuel that excels at nothing, and will rarely be the best option for a rocket. If you can make it on Duna, however...

Kerosene
Kerosene is jet fuel, we just happen to be using it for bigger explosions most of the time. Feel free to run it in your jet engines as well.

Hydrazine
Hydrazine passed over an alumina-iridium catalyst, yielding a high-temperature mixture of nitrogen, hydrogen and ammonia. This is the default option for RCS thrusters.

Solid Fuel
Ask Jeb.

Liquid Hydrogen
Nuclear engines get best efficiency with light propellants, and so they use the lightest substance available -- pure hydrogen.

Liquid Methane
Putting a heavier fuel in a nuclear rocket, however, gives greater thrust. Increased density means it might also yield more delta-v in practice

Ammonia
Ammonia is not a very good nuclear rocket propellant, but it has a very, very low boil-off rate.

Enriched Uranium
Fuel for nuclear reactors. Decays into depleted uranium over time.
Electric propulsion using Xenon and Argon isn't covered by this mod, partly because the storage density of Xenon is wrong by a factor of 65 (supercritical Xenon is *heavier* than liquid oxygen). I'll leave that to others to contemplate.

| Propellant | Name | Real Density | mass | L per unit | price |
|------------|----------------|--------------|------------|------------|--------|
| 100LL | AvGas* | 0.72 | 0.0036 | 5.000 | 0.1 |
| Kerosene | Kerosene* | 0.82 | 0.0041 | 5.000 | 0.1 |
| LH2 | LiquidHydrogen | 0.07085 | 0.0004 | 5.649 | 0.5 |
| LCH4 | LqdMethane | 0.42262 | 0.00186456 | 4.333 | 0.2* |
| UDMH | LiquidFuel | 0.791 | 0.004* | 5.000 | 0.8 |
| N2H4 | MonoPropellant | 1.004 | 0.005* | 5.000 | 1.2 |
| LNH3 | Ammonia | 0.682 | 0.000681 | 1.000 | 0.2* |
|------------|----------------|--------------|------------|------------|--------|
| LOX | LiquidOxygen* | 1.141 | 0.0057 | 5.000 | 0.1 |
| NTO | Oxidizer | 1.45 | 0.00725* | 5.000 | 0.18 |
|------------|----------------|--------------|------------|------------|--------|
| Solid | SolidFuel | 1.75 | 0.0075 | 4.292 | 0.6 |
| Xenon | XenonGas | 1.36 | 0.0001 | 0.074 | 4 |
| Argon | ArgonGas | 0.54 | 0.00005 | 0.093 | 0.25 |
Asterisks mark new or changed resources. Real densities are in kg/L. Mass is tonnes per unit, while the last column shows the number of liters in each unit.
AvGas, Kerosene, and LiquidOxygen are new, while LiquidFuel, Oxidizer, and MonoPropellant have tweaked masses. LqdMethane and Ammonia have no prices defined in the CRP, so I added some. AvGas is just there for mod propeller engines, just so they don't have to run on Kerosene.

| Mixture | Mass Ratio | Volume Ratio | Bulk Density | BD (kg/L) |
|---------------|------------|--------------|--------------|-----------|
| NTO/UDMH | 2.22 | 55/45 | 0.00579 | 1.158 |
| Kerolox | 2.32 | 62.5/37.5 | 0.0051 | 1.02 |
| Hydrolox | 6.11 | 27.5/72.5 | 0.00178 | 0.365 |
| Methalox | 3.46 | 56.67/43.33 | 0.00416 | 0.832 |
Mass ratio is the mixture ratio I ended up at, oxidizer/fuel. Volume ratio is the mixture ratio using CRP densities. The volume ratios were adjusted to be whole numbers that give something between a reasonable mass ratio and a reasonable volume ratio, with weight given to the mass ratio. Bulk densities are within 2% of reality assuming 1 Unit = 5 L. That ends up being true for methalox, too; a tank of methalox in game has a mass within 2% of what the equivalent volumes of methane and oxygen would weigh at the same mixture ratio, because methalox tanks are magically bigger.
For nuclear engines, pure LH2 or pure LCH4 tanks hold 10% more than they should.

---------------------------

Essentially, there are low efficiency/long duration, high efficiency/short duration, and intermediate options. The mixture ratios of the engines are set to semi-believable whole number ratios that yield a realistic combined fuel/oxidizer density. This isn't even a stretch, as real rocket engines can run a wide range of mixtures with little impact on efficiency (Saturn IVB could even vary mixture ratio in flight, and Soyuz and Fregat runs their engines extra rich in order that the UDMH and NTO tanks can be the same size.) Obviously in real life thrust and Isp change by a few percent dependent on mixture ratio according to the chamber pressure, the expansion ratio, the altitude, and some horrifically complicated chemistry... but that's real rocket science, and I'm not touching it.

This will depend on a generic Modular Fuel Tanks configuration that applies to every fuel tank, except for those explicitly exempted or overridden. A FL-T400 will mostly still hold 400 units, however. That will be true for both Oxidizer/LiquidFuel (which still uses a 55/45 ratio) and LiquidOxygen/Kerosene. Due to the way LiquidHydrogen and LqdMethane are defined by other mods fuel tank amounts get more complicated with those fuels.

The plan is to change engines in a generic way as well. I want to do as little work as possible here, partly out of laziness but mostly for the sake of mod compatibility. I'll attempt as much as possible to write ModuleEngineConfigs using the new Module Manager variable support, change things only as much as necessary, and do minimum curation. I may end up bending ModuleManager to the breaking point, but that's sarbian's fault for adding variables . I'll probably end up with two options using the UseRealMass flag from RealFuels -- one for stock 1x Kerbin balance, and a 6.4x focused set that represents my best guess of what real Kerbal-sized rocket engines would do.

I've decided, however, that I won't be keeping the default LiquidFuel and Oxidizer masses, and maybe not the MonoPropellant and SolidFuel masses. They're just too restrictive when it comes to balancing the new fuels (no real fuel/oxidizer combination uses propellants of the same den, and changing them should have the least impact on compatibility of any of my options -- or at least, the most knowable effect on compatibility. No resources from other mods will be changed.

January 18, 2015

OK, found the source of at least SOME of the errors in that MM config - one bit needs an @:

I'd updated my post #366 a few times yesterday to say I'd fixed all the ModuleManager errors, sorry if you wasted time looking for them.

Also, be careful: MFT will change the mass of parts it's applied to unless you tell it not to, so parts that should keep their dry mass (like service modules, pods, etc) need special handling.

Understood, but I still think it's better to support all tanks by default and call out special cases as they come up than to leave everything unsupported until someone gets around to fixing it, especially if I end up adding CRP resources as I'm currently trying to spec out.

January 17, 2015

Kind of.

6.4x itself is version independent, but it depends on RSS. This download includes a version of RSS that isn't compatible with 0.90.

All you need to do is replace RealSolarSystem.dll with the version in the current download of RealSolarSystem.

January 17, 2015

Hmm... ModuleManager tells me that my generic file has 77 errors, which is impressive since there are only 45 lines. It doesn't tell me what any of those errors are, though...

"RESOURCE[Xenon]" should read "RESOURCE[XenonGas]". That fixes 8 of them.

"volume += #$../RESOURCE[Oxidizer]/amount$" needs a '@' in front of it. That's the rest of them -- it wasn't adding the Oxidizer volume to the modular tank.

I did have to add ":FINAL" to the generic config for mod compatibility, as well. The proper way would be for the other mods to use '%MODULE[ModuleFuelTanks]' to override the generic tank if necessary, but that's not going to happen.

I've updated my zip: http://www./download/iu9p1ds2rtc2y8e/GenericModularFuelTanks.zip

I think I might end up branching either this or RealFuels on GitHub and trying to make a generalized 6.4x-focused NearFuels out of it.

January 17, 2015

Players make their planes have delta wings because it's a common and simple concept that going faster means that your craft will have to look more streamlined and thin. You don't really need the extra bells and whistles of supersonic physics to tell people that. I'm not going to assume that fellow players are too stupid to not know something this intuitive already.

Isn't that an argument in support of realistic aerodynamics? I want aerodynamics in which craft that go faster need to look more streamlined and thin. That isn't true in the stock aerodynamics, at all. It's only partly true in NEAR (it doesn't apply to wings). It is true in FAR. Physics models that match (correct!) intuitions are good. Physics models that contradict them are bad.

Also, regarding swept wings, even without mach effects, we should have a reason to use them.
Swept wings are inherently yaw stable. That is why every flying wing has a swept wing.
That is why hang gliders (which I fly) have swept wings... its certainly not mach effects.

Well, yeah, but a fuselage also provides yaw stability. But certainly it should make a difference to any Kerbal hang gliders!

January 17, 2015

So would this do what I'm looking for? Which is:
1. Find a part with LiquidHydrogen in it
2. Apply MFT to that part, but
3. Set the "volume" of the MFT tank to be the amount of LiquidHydrogen divided by 2.5:

That should do it. You probably want to define a cryogenic tank for that, though.

January 17, 2015

Alright, this didn't actually take very long (I'm glad I learned Vim).

Delete every .cfg except for MFSSettings.cfg and Propellants.cfg from your ModularFuelTanks directory, and drop in the "Tanks" folder below. You can just leave it as a subdirectory ('ModularFuelTanks/Tanks/zzGeneric.cfg', etc.).

http://www./download/iu9p1ds2rtc2y8e/GenericModularFuelTanks.zip

This should have exactly the same tanks as before, but will also apply generic Modular Fuel Tanks to every tank from every mod that isn't already covered.

This uses the variable support that was added to ModuleManager recently. Basically, ModuleManager can now read config files as well as just edit them. This config tells it to find out how much fuel, oxidizer, monoprop, or xenon each part carries, and to generate a modular fuel tank of that size.

January 17, 2015

I think we can actually replace most of the config files with this now:


// generic tank replacement
@PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[ModuleFuelTanks]]:FINAL {
    MODULE {
        name = ModuleFuelTanks
        volume = #$../RESOURCE[LiquidFuel]/maxAmount$
        @volume += #$../RESOURCE[Oxidizer]/maxAmount$
        type = Default
    }
}

@PART[*]:HAS[@RESOURCE[LiquidFuel],!RESOURCE[Oxidizer],!MODULE[ModuleFuelTanks]]:FINAL {
    MODULE {
        name = ModuleFuelTanks
        volume = #$../RESOURCE[LiquidFuel]/maxAmount$
        type = Fuselage
    }
}

@PART[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleCommand],!MODULE[ModuleFuelTanks]]:FINAL {
    MODULE {
        name = ModuleFuelTanks
        volume = #$../RESOURCE[MonoPropellant]/maxAmount$
        type = RCS
    }
}

@PART[*]:HAS[@RESOURCE[XenonGas],!MODULE[ModuleFuelTanks]]:FINAL {
    MODULE {
        name = ModuleFuelTanks
        volume = #$../RESOURCE[XenonGas]/maxAmount$
        type = Xenon
    }
}

@PART[*]:HAS[@MODULE[ModuleFuelTanks],@MODULE[ModuleEngines]]:FINAL {
    @MODULE[ModuleFuelTanks] {
        %basemass = -1
    }
}

@PART[*]:HAS[@MODULE[ModuleFuelTanks],@MODULE[ModuleEnginesFX]]:FINAL {
    @MODULE[ModuleFuelTanks] {
        %basemass = -1
    }
}

@PART[*]:HAS[@MODULE[ModuleFuelTanks]]:FINAL {
    !MODULE[FSfuelSwitch] {}
}

I'm still working out all the files I need to change, nosecones, special tanks and the like. I haven't tested this yet.

EDIT: It should work as a patch to existing installs now.

January 17, 2015

That's not much of an argument. I mean, the X-15 fly-by-wire system was literally called SAS. It did exactly what SAS does in KSP (although better tuned).

More generally, just try it! Install FAR and try it. It's not hard to fly a supersonic plane. It's not hard to make a plane that's flyable while supersonic and can pull 10 g turns. Or even pull 10 g turns while supersonic.

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by NonWonderDog