[WIP] NearFuels (Design Stage)

[NonWonderDog]

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.

[NonWonderDog]

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...)

Edited February 4, 2015 by NonWonderDog

[AngelLestat]

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.

[RoverDude]

Hi! Just noticed this thread, had a couple of points

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.

Conservation of Mass is up to the user, and in some cases is irrelevant. For example, converting fuel to EC will result in mass dropping. Converting a raw material to a finished good can also result in mass loss. Gathering stuff from an atmosphere or ocean results in mass increases. Also, all of the core libraries that we interface with deal in adding/moving/checking for units, not weight.

Which leads to the second point - CRP exists to sort some of this out

So. If there is stuff you feel is missing from CRP, let me know. Always interested in more mods working together.

[Raptor831]

In the Kethane/RealFuels config I set up, conservation of mass is respected (or at least honored...). You just end up having to translate from volume => mass => moles, do your reaction, and figure your moles => mass => volume. The one thing KSP doesn't have out of the box is molar mass, which you need to do that on the fly. Density is a bit easier to use, which is probably why the devs chose that value to store in the resource nodes.

[NonWonderDog]

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.)

[thorfinn]

I think that adding H2O2, if not just replacing storable oxidizer with it, would help a lot in emphasizing the differences: H2O2/RP-1 is very dense and with a ultimate Isp similar to N2O4/UDMH, giving the option of very heavy but very high mass-ratio storable stages (or boosters). Monoprop H2O2 has very bad Isp but could be a nice low-tech/very low-cost choice also.

[AngelLestat]

Ok @NonWonderDog I understand you.

I am not sure yet how masses and scales would fit, but I will love helping in testing if this mod reach alpha.

You said that the rocket scales are the same that stock?

This mean that all mods will be compatible?

In your first post you said that even at 6.4 scale we wouldn't notice textures degradation, how's that?

[NonWonderDog]

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.

[thorfinn]

It's not so mad, it's British (The tiny launcher that the UK built alone in the late sixties was based on that).

I didn't think about the mixture ratio though, you are right - and it's totally different from the stock propellant, something like 7:1 (!) So a if a "backwards compatible" mixture has to exist that's a problem.

Edited February 5, 2015 by thorfinn

[blowfish]

Why do LiquidFuel and Oxidizer need to be retained as the defaults? Isn't that what ModuleManager is for?

@PART[*]:HAS[@MODULE[ModuleEngines*]]
{
    @MODULE[ModuleEngines*]:HAS[#PROPELLANT[LiquidFuel],#PROPELLANT[Oxidizer]]
    {
        @PROPELLANT[LiquidFuel]
        {
            @Name = UDMH
            @Ratio = whatever
        }
        @PROPELLANT[Oxidizer]
        {
            @Name = NTO
            @Ratio = whatever
        }
    }
}

That might not be 100% correct but I know for a fact that it's doable.

[thorfinn]

Nice: so LiquidFuel/Oxidizer could be just an alias for RP-1/LOX or RP-1/H2O2, whatever the densities?

Then MonoPropellant could also be an alias for Hydrazine or, if you want to aggravate people, H2O2

Jokes aside, H2O2 was the earliest RCS fuel and it would make the upgrade to N2H4 very desirable.

Edited February 5, 2015 by thorfinn

[blowfish]

Changing @Name doesn't alias, it replaces it with an entirely different resource.

[NonWonderDog]

Changing @Name doesn't alias, it replaces it with an entirely different resource.

Yep, there's no way to add an alias. It could probably be done by building off of KSPAPIExtensions to take a guiName field for each resource, but you'd have to re-implement a lot of classes. I'm not familiar enough with the Kerbal API to even know which ones. You can change all the engines to use your new resource instead, but there's a lot more than engines that uses resources nowadays.

For compatibility's sake, LiquidFuel is called LiquidFuel and is mixed with Oxidizer in a 55/45 O/F ratio (by units, not mass or, indeed, volume). Changing the mass of a unit will change Karbonite balance a bit, but I don't think it breaks anything. Changing the volume per unit definition (nominally 5 L/u) makes fuel tanks very confusing to set up, but doesn't have any other ill effects.

So I have some leeway, but things are most straightforward if we stick to 5 liters per unit -- or at least the same definition for both LiquidFuel and Oxidizer. NTO/UDMH works great here since, in addition to being the world's most common storable propellant, it can be burned at a 55/45 volume ratio with decent efficiency (that's a 2.22 mixture ratio, whereas optimal is 2.5-2.7 but several spacecraft run at 1.9 so the tanks can be the same size).

It would be kind of nice to keep LiquidFuel as fuel for jets as well as rockets, if only so that fancy IVA fuel gauges still work, but I don't see an easy way. NTO/Kerosene burns at a 70/30 volume ratio, while HTP/Kerosene burns at an 80/20 volume ratio. (Christ, 80% of your propellant would be high test peroxide...)

The Oxidizer as HTP idea would require that HTP be stored at around 16 L/u, while Kerosene is stored at 5 L/u. A 100 unit tank would hold about 25+20 units instead of 55+45 units. I don't think the benefit is enough to make up for the annoyance.

Edited February 6, 2015 by NonWonderDog

[blowfish]

Yep, there's no way to add an alias. It could probably be done by building off of KSPAPIExtensions to take a guiName field for each resource, but you'd have to re-implement a lot of classes. I'm not familiar enough with the Kerbal API to even know which ones.

For compatibility's sake, LiquidFuel is called LiquidFuel and is mixed with Oxidizer in a 55/45 O/F ratio (by units, not mass or, indeed, volume). Changing the mass of a unit will change Karbonite balance a bit, but I don't think it breaks anything. Changing the volume per unit definition (nominally 5 L/u) makes fuel tanks very confusing to set up, but doesn't have any other ill effects.

So I have some leeway, but things are most straightforward if we stick to 5 liters per unit -- or at least the same definition for both LiquidFuel and Oxidizer. NTO/UDMH works great here since, in addition to being the world's most common storable propellant, it can be burned at a 55/45 volume ratio with decent efficiency (that's a 2.22 mixture ratio, whereas optimal is 2.5-2.7 but several spacecraft run at 1.9 so the tanks can be the same size).

It would be kind of nice to keep LiquidFuel as fuel for jets as well as rockets, if only so that fancy IVA fuel gauges still work, but I don't see an easy way. NTO/Kerosene burns at a 70/30 volume ratio, while HTP/Kerosene burns at an 80/20 volume ratio. (Christ, 80% of your propellant would be high test peroxide...)

The Oxidizer as HTP idea would require that HTP be stored at around 16 L/u, while Kerosene is stored at 5 L/u. A 100 unit tank would hold about 25+20 units instead of 55+45 units. I don't think the benefit is enough to make up for the annoyance.

What exactly would break if MM was used to batch replace LF/O with UDMH/NTO as above?

[NonWonderDog]

Karbonite, for one, and Karbonite's resource converters are very difficult to edit with module manager (I haven't worked out a general way yet).

Various IVA props by various modders use LiquidFuel and Oxidizer levels to show fuel gauges.

I think there's a Station Science sub-mod that uses LiquidFuel to run science experiments.

In general, I don't want to have to know about every mod that might use LiquidFuel and Oxidizer for something other than engines and write a compatibility config for it, nor do I want every other mod author to have to know about NearFuels and spend time writing the compatibility config himself. It's easier just to live with an imprecise name.

[Raptor831]

Karbonite, for one, and Karbonite's resource converters are very difficult to edit with module manager (I haven't worked out a general way yet).

There is a way to do this, I just worked it out the other day. You can do something like this:

@PART[*]:HAS[@MODULE[REGO_ModuleResourceConverter]]
{
  @MODULE[REGO_ModuleResourceConverter],*
  {
    @RecipeOutputs ^= :LiquidFuel:UDMH:
    @RecipeOutputs ^= :Oxidizer:N2O4:
  }
}

That should change all LiquidFuel to UDMH and all Oxidizer to N2O4 in any Regolith converter output. It's not pretty, really, but it'll do. More details here: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax (specifically the regular expression parts)

That said, sticking with LiquidFuel and Oxidizer is probably a good thing. One negative about RealFuels is that to use it, every part (especially engines and fuel tanks) needs to be configured to use it properly. You can't just pop in a brand new mod's engines and expect them to work. Using LF/O is one way to at least keep a semblance of compatibility with new mods or ones that you haven't supported officially yet. EDIT: ...which is pretty much what you just said, now that I re-read it.

[NonWonderDog]

Yeah, a regex replacement is enough to change the names. I'm sure I can work out a regex to change the ratios, too, or I probably shouldn't be allowed to call myself a Vimmer. Something simple like

@RecipeOutputs ^= :LiquidFuel,[.0-9]*:Kerosene,0.625:

But I don't see an obvious way to modify the ratios in Module Manager, as in multiply one of them by 1.5. It might actually be impossible, but I'm willing to bet it can be done with enough regexes. Somehow.

If you can save the result of a regex in a variable, and then use that variable in a regex, it should be pretty easy. But I don't think you can do that.

Or if you could use a variable to index an array, and multiply an indexed variable by a constant, you could still get at it. But you can't do that either.

I think you'd have to write a multiplier in regex (it's just barely possible, I think), assuming that nobody would use more than 6 digits or something. It might take fifty or so expressions, and there's really no excuse for not writing a new plugin at that point.

Edited February 6, 2015 by NonWonderDog

[Mecripp]

Yeah, a regex replacement is enough to change the names. I'm sure I can work out a regex to change the ratios, too, or I probably shouldn't be allowed to call myself a Vimmer. Something simple like

@RecipeOutputs ^= :LiquidFuel;[.0-9]*:Kerosene;0.625:

But I don't see an obvious way to modify the ratios in Module Manager, as in multiply one of them by 1.5. It might actually be impossible, but I'm willing to bet it can be done with enough regexes. Somehow.

If you can save the result of a regex in a variable, and then use that variable in a regex, it should be pretty easy. But I don't think you can do that.

Or if you could use a variable to index an array, and multiply an indexed variable by a constant, you could still get at it. But you can't do that either.

I think you'd have to write a multiplier in regex (it's just barely possible, I think), assuming that nobody would use more than 6 digits or something. It might take fifty or so expressions.

Did you see

@PART[somePart1]
{
    // Unindexed - edits the first
    @name = somePart2
    // Arithmetic - add 5 and multiply by 20. Unindexed so edits the first one.
    @numeric += 5
    @numeric *= 20
    // Regexp expression. Replaces any instance of "tw" with "mo", so would turn "twotwo" into "moomoo"
        // Note also the index.
    @multiVal,1 ^= :tw:mo:
}

EDIT- Are you just wanting to use REGO_ModuleResourceConverter , Why not just pick a part and use ModuleGenerator ?

EDIT-

MODULE
{
	name = ModuleGenerator
	isAlwaysActive = false
        activateGUIName = activate Converter
        shutdownGUIName = Deactivate Converter
        INPUT_RESOURCE
	{
	    name = ****
	    rate = **
	}
	OUTPUT_RESOURCE
	{
	   name = ****
	   rate = **
	}	
}

Edited February 6, 2015 by Mecripp2

[NonWonderDog]

Karbonite uses nodes like this:

MODULE
{
	 name = REGO_ModuleResourceConverter
	 ConverterName = LFO Mix
	 StartActionName = Start LFO 
  	 StopActionName = Stop LFO
	 RecipeInputs = ElectricCharge,6,Karbonite,4
	 RecipeOutputs = Oxidizer,0.275,False,LiquidFuel,0.225,False
}	

RecipeOutputs isn't a number, so it can't be multiplied. You can use RecipeOutputs[2] in a variable, but maybe not as the target of an assignment? ":\([^,]*\),[.0-9]*:\1,0.3:" would be the way to replace the second field with 0.3 in Vim, but I don't know the equivalent Module Manager syntax or if it would be applied once or as many times as possible. Even so, I wouldn't want to change the second field, I'd want to change the first field after "Oxidizer". With a regex this would be something like ":\(Oxidizer\),[.0-9]*:\1,0.3:", but that still doesn't *multiply* the second field by a number.

Anyway, this is all academic. I don't need to do this, because I'm not changing the LiquidFuel and Oxidizer ratios. If I was I'd rather write some kind of compatibility plugin.

Edited February 6, 2015 by NonWonderDog
regexes never get easy.

[Mecripp]

Did you try something like

@PART[REGO_ModuleResourceConverter]
{
  @RecipeInputs[ElectricCharge]
    {
    ElectricCharge *= 1.5
    }
}

Or 

@PART[REGO_ModuleResourceConverter]
{
  @RecipeInputs,0
    {
     @ElectricCharge *= 1.5
    }
   @RecipeInputs,1
    {
     @Karbonite *= 1.5
    }
}

[NathanKell]

NonWonderDog: 1. Mixture ratio varies with cycle. Closed cycle Russian engines use very high O:F mixture ratios, whereas US open-cycle engines tend to run comparatively fuel-rich. Compare 2.63 for RD-170 with ~2.2 for LR-89. That means if you keep 55/45, you can just claim they're all open cycle, fuel-rich (for the gas generator) engines.

As for multiplying things, check out what I did here, that might help.

https://github.com/KSP-64k/64k/blob/master/64k/Compatability/DeadlyReentry_64k.cfg

You can use a regexp to pick out a value, set some other variable to it, multiply *that* variable, and then chuck it back in.