Jump to content

[0.20] Modular Fuel System 1.3/realistic fuels, reconfigurable fuel tanks and engines

ialdabaoth

By ialdabaoth
in KSP1 Mod Releases

 Share

Recommended Posts

erbmur

erbmur

Posted
Posted
No, thats working as intended (atm) since in their primary mode they only use LH2. When the HybridEngine module gets added it will be working like the rocket engines.

Thanks for the explanations Chesterbuster.

Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted (edited)
Is there a formula or something to help me getting the right mixture ratios? I'm using this site for information gathering atm.

Yep, let's walk through it with Liquid Oxygen + Liquid Hydrogen.

LOX:

Density - 1.14

RESOURCE_DEFINITION density - 1.14 * 0.00625 = 0.007

Ratio - 5.00

density ratio: 5.00 / 1.141 = 4.38

LH2:

Density - 0.071

RESOURCE_DEFINITION density - 0.071 * 0.00625 = 0.00044

Ratio - 1.00

density ratio: 1.00 / 0.071 = 14.1

so your density ratios are 4.38 and 14.1; or, if you want to make them add to 1, 4.38 / (4.38 + 14.1) = 0.24 and 14.1 / (4.38 + 14.1) = 0.76. I believe I used closer to a 6:1 ratio instead of a 5:1 ratio, which is also a NASA standard, so I wound up with 0.27 and 0.73.

Does that make sense?

Oh! Also, all your files have @MaxTemp instead of @maxTemp, this won't work. KSP's node system is case-sensitive.

Edited by ialdabaoth
Link to comment
Share on other sites
Chestburster

Chestburster

Posted
Posted (edited)

I call shenanigans! Notepad++ must be playing pranks on me.. xD

Going to figure that whole mixture out later when i get home. its currently way to hot here..

Edit:

MFS Configs V1.2b released!

- fixed the maxTemp issue.

Download V1.2b

Didnt notice that since DeadlyReentry automaticly did what i did there^^

Edited by Chestburster
Link to comment
Share on other sites
erbmur

erbmur

Posted
Posted

Me again, sorry.

I still don't quite get how this is supposed to work.

Using an FL-T400 tanks with an LV-909:

standard liquidfuel + oxidizer, action group menu says 370 isp, mechjeb delta-v/engineer redux give 3663 delta-v

liquidH2 + LiquidOxygen, action group menu says 460 isp, which would lead me to believe that it would be a lot more efficient and therefore provide more delta-v, but mechjeb/engineering redux say 1481 delta-v

Seriously, what is is i'm missing with this mod?

Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted
Me again, sorry.

I still don't quite get how this is supposed to work.

Using an FL-T400 tanks with an LV-909:

standard liquidfuel + oxidizer, action group menu says 370 isp, mechjeb delta-v/engineer redux give 3663 delta-v

liquidH2 + LiquidOxygen, action group menu says 460 isp, which would lead me to believe that it would be a lot more efficient and therefore provide more delta-v, but mechjeb/engineering redux say 1481 delta-v

Seriously, what is is i'm missing with this mod?

Actually, this isn't bugged. Look at the mass of your rocket.

LiquidH2 is significantly more efficient than LiquidFuel, kilogram-for-kilogram. But it is much, MUCH lighter.

Try this instead:

Fill with standard liquidfuel + oxidizer, note delta-V.

Now, empty and refill with liquidH2 + liquidOxygen, and then *keep adding more fuel tanks* until you reach the same vehicle mass that you had with liquidfuel + oxidizer.

THOSE are the delta-V's you should be comparing.

This is why LiquidH2 is usually an upper-stage decision in real life, btw - because the consideration isn't just how much delta-V you can get, it's how much delta-V you can fit in an upper stage with a given payload weight.

Your bottom stages are better off with LiquidFuel + LiquidOxygen; down in the lower atmosphere the delta-V differences won't be that substantial anyways. Save the LH2 for when you reach space, unless you're using SABREs or something.

Link to comment
Share on other sites
Chestburster

Chestburster

Posted
Posted

Well, something is bugged. If you take an engine, like the Titan-T1, and put it into LF+LOX you get 320 ISP with engineer, switching it to LH2+LOX or LF+OX doesnt change the ISP in engineer (and the MFS UI) and leading to miscalculated dV. Its just an VAB/SPH bug, on the launchpad the ISP and dV are correct.

Link to comment
Share on other sites
cardajowol

cardajowol

Posted
Posted

There is also alot of

"[Exception]: NullReferenceException: Object reference not set to an instance of an object "

When I go in to the action menu and very laggy at times... this suppose to be doing this?

Link to comment
Share on other sites
CaptainArbitrary

CaptainArbitrary

Posted
Posted

I've got a bit of a stupid question, I'm afraid. What's the purpose and function of the "modded" parameter to ModuleEngineConfigs? From glancing through the source code, it looks like if you set "modded = true" in your config file, the mod is supposed to replace the part's ModuleEngines with the one from ModuleEngineConfigs whose name parameter matches the module's configuration parameter. In other words, if your config (run through ModuleManager, duh) looks like this:


@PART[someEngine]
{
	MODULE
	{
		name = ModuleEngineConfigs
		configuration = someConfig
		modded = true
		CONFIG
		{
			name = someConfig
			et cetera…
		}
	}
}

Then as soon as that part gets loaded, either in the editor or on the pad, its engine config is supposed to be completely replaced by the one from ModuleEngineConfigs. Do I have that right?

This isn't working for me. If I set up a config file exactly that way, the engine still comes into the VAB configured according to the default parameters given in its part.cfg. Is using "modded = true" this way something that's not currently working and I should ignore it, or am I getting it wrong somehow or what?

It's totally not a big deal. It only matters in that if I want to replace the default engine configuration entirely, not just add other options that can be chosen in the VAB, then I have to both have a ModuleEngineConfigs config and also use the @-syntax of ModuleManager to change the part's configuration directly. It works fine, I just have to have the same information in two places in the config file, and I've been making a lot of dumb mistakes involving forgetting to change both when I tweak something, et cetera.

Thanks for the mod. It's super-rad.

Link to comment
Share on other sites
SchroedingersHat

SchroedingersHat

Posted
Posted (edited)

There's a bug somewhere involving this. At least there's something odd going on with some of the KW rocketry engines with regards to this. I've had a vague inkling that something is off with a few designs, but I tested the KW Vesta (120 kN 1.25m one) against the wildcat (230kN).

Giving them identical tanks, the Vesta ran out first. Also a single long 1.25m tank of H2 + LOX is enough to get the apoapsis out past Jool with the wildcat.

It looks like it might have something to do with using the H2+LOX at the same rate as the fuel the engine started with as the vesta defaults to H2 (i think) and I first started to notice it with other similar engines (default to liquid fuel and changable to H2)

Edit: Just tested with one of the default engines (1.25m vectored one) and the same thing happens.

Edited by SchroedingersHat
Link to comment
Share on other sites
Chestburster

Chestburster

Posted
Posted (edited)

Check the weight of your rocket. Thats just 3 tons with 220 KN thrust. Its no wonder why it can go as far out as Jool ;) H2 doesnt weight much, its supposed to propell lighter upper stages. Add something with more weight and it wont go very far. Even a 0.7t payload wont make it far (260km if you go straight up xD).

Edit: But after testing the vesta with LH2+LOX and RP-1+LOX i found out that with the RP-1 setup the ISP wont stop at 380, instead going up to 465 like the LH2 version o.O

Edited by Chestburster
Link to comment
Share on other sites
erbmur

erbmur

Posted
Posted

I appear to be having the same issue as Hades described a couple of pages back.

The configurable ASAS modules for the core probes appear to make them uncontrollable. They only rotate if they are turned by a gimbled rocket engine. Apart from that, they no longer want to turn.

Any hints on how I should be setting up the Kp/Kd values?

Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted
I appear to be having the same issue as Hades described a couple of pages back.

The configurable ASAS modules for the core probes appear to make them uncontrollable. They only rotate if they are turned by a gimbled rocket engine. Apart from that, they no longer want to turn.

Any hints on how I should be setting up the Kp/Kd values?

I just figured out what's causing that bug, actually - apparently, I accidentally disabled the internal gyro forces. :( Working on a fix now.

Link to comment
Share on other sites
grom

grom

Posted
Posted

@ialdabaoth are you aware that you have already unpacked RealFuels? I only wanted the basic edition for being able to have empty (or partial full) tanks and the configurable ASAS. So I copied the ModularFuelTanks folder deleting out RuelFuels. Also what is ExsurgentEngineering used for? I never copied that over either.

Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted

ExsurgentEngineering was a compatability fix for B9; it will no longer be included as of the next version of ModularFuelSystem.

I will make sure to keep RealFuels.zip packed in the next release, thank you.

Link to comment
Share on other sites
SchroedingersHat

SchroedingersHat

Posted
Posted (edited)
Check the weight of your rocket. Thats just 3 tons with 220 KN thrust. Its no wonder why it can go as far out as Jool ;) H2 doesnt weight much, its supposed to propell lighter upper stages. Add something with more weight and it wont go very far. Even a 0.7t payload wont make it far (260km if you go straight up xD).

The issue isn't thrust, it's how long the H2 lasts (an equal volume tank should run out much quicker in some circumstances). That's well over 5000 delta-V (my ascent profile wasn't very efficient) on a mass ratio of 2.

For that test rocket here is some maths:

Dry mass of 2.87

Full mass of 4.96

Bang that into the rocket equation gives you 5.37 * Isp of delta-V or 2470m/s

In further testing, the mechjeb ascent stats say I am getting 6000m/s of dV which seems right as I'm moving at 4000m/s on escape from Kerbal and I know from experience it takes about 5000m/s to encounter Jool. This gives an effective Isp of 1120s -- mostly in atmosphere.

Edit: But after testing the vesta with LH2+LOX and RP-1+LOX i found out that with the RP-1 setup the ISP wont stop at 380, instead going up to 465 like the LH2 version o.O

Engines on different fuels are reporting the same Isp during flight for me too. This is the Isp of their default fuel.

Next experiment:

Two wildcats on LiquidFuel/Oxidizer and one on H2/LOX.

All three have their own tank.

Put 100 fuel in each tank.

They ran out at almost exactly the same time (there was 1.6 out of 73 units of H2 left when the LiquidFuel ran out)

Hypothesis:

The modified engines are burning their alternate fuel at the Isp of their default confguration in the correct ratios but as if it had the mass of LiquidFuel.

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

Addendum:

Experiment 3:

1 nerva, 100 units of H2.

Everything works correctly

Experiment 4:

Vesta running on H2 then LiquidFuel

The Vesta works correctly and performs as MechJeb and manual calculations predict when running on H2/LOX.

Putting a similar amount (but much greater mass) of LiquidFuel/Oxidizer in produced slightly lower dV.

Experiments 3 and 4 agree with my hypothesis.

Edited by SchroedingersHat
Extra Experiments
Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted
The issue isn't thrust, it's how long the H2 lasts. That's well over 5000 delta-V (my ascent profile wasn't very efficient) on a mass ratio of 2.

For that test rocket here is some maths:

Dry mass of 2.87

Full mass of 4.96

Bang that into the rocket equation gives you 5.37 * Isp of delta-V or 2470m/s

In further testing, the mechjeb ascent stats say I am getting 6000m/s of dV which seems right as I'm moving at 4000m/s on escape from Kerbal and I know from experience it takes about 5000m/s to encounter Jool. This gives an effective Isp of 1120s -- mostly in atmosphere.

Engines on different fuels are reporting the same Isp during flight for me too. This is the Isp of their default fuel.

Next experiment:

Two wildcats on LiquidFuel/Oxidizer and one on H2/LOX.

All three have their own tank.

Put 100 fuel in each tank.

They ran out at almost exactly the same time (there was 1.6 out of 73 units of H2 left when the LiquidFuel ran out)

Hypothesis:

The modified engines are burning their alternate fuel at the Isp of their default confguration in the correct ratios but as if it had the mass of LiquidFuel.

Confirmed; this will be fixed for the next release. This is what happens when you muck with ModuleEngines blind. ;) Squad could really use a 'decompiling any class descended from PartModule for the express purpose of plugin compatability' exception to their EULA.

Link to comment
Share on other sites
erbmur

erbmur

Posted
Posted

Yeah, I seem to have this happen on occasion. But it only happens as long as the ship is connected to the stability enhancers. As soon as I launch and leave the docking clamps the fuel is consumed as per normal.

Link to comment
Share on other sites
CaptainArbitrary

CaptainArbitrary

Posted
Posted

I've got a feature request wrapped inside a bug report, having to do with how tank definitions are initially applied.

Say you set up a tank definition like this … 'cause I have:


// RP1-LOX

TANK_DEFINITION
{
	name = CommonBulkheadStandard
	basemass = 0.000108649774484067 * volume
	TANK
	{
		name = LH2
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		temperature = -253.8
		loss_rate = 0.0000000000422720017314612 // 0.1% per day at 20°C
		amount = 0.0 // liters
		maxAmount = 0.0 // liters
		note = 
	}
	TANK
	{
		name = RP1
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		amount = 0.35 * volume // liters
		maxAmount = 0.35 * volume // liters
		note = 
	}
	TANK
	{
		name = LOX
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		temperature = -184
		loss_rate = 0.0000000000567356572258533 // 0.1% per day at 20°C
		amount = 0.65 * volume // liters
		maxAmount = 0.65 * volume // liters
		note = 
	}
	TANK
	{
		name = Hydrazine
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		amount = 0.0 // liters
		maxAmount = 0.0 // liters
		note = 
	}
}

Just to make my intentions clear: This tank can hold LHâ‚‚, RP1, LOX and hydrazine. But by default, it holds only RP1 and LOX. The volume is meant to be divided 35% RP1 and 65% LOX, and each tank in the part has a utilization factor of 85%. That's the idea, kay?

Then you create a tank part config file what looks like this:


@PART[fuelTank]:Final
{
	!RESOURCE[LiquidFuel] {}
	!RESOURCE[Oxidizer] {}
	MODULE
	{
		name = ModuleFuelTanks
		volume = 2100 // liters
		type = CommonBulkheadStandard
	}
}

This is supposed to take the stock fuelTank part, remove the LiquidFuel and Oxidizer resources entirely, then configure it using the above tank definition, with a total volume of 2100 liters. Kay so far?

What I expect to happen, given this setup, is that the tank will come into the VAB with its 2100 liters of interior volume divided up into 624.75 liters of RP1 and 1160.25 liters of LOX, ± a liter or so for rounding. That's 2100 liters × 35% × 85% for the RP1, and 2100 liters × 65% × 85% for the LOX.

What actually happens is that the tank comes into the VAB with 735 liters of RP1 and 1049 liters of LOX, and I don't know why.

bxeH0EW.png

If I add an RP1 engine, then use the "remove all tanks" and "configure remaining volume for engines", the results end up being correct.

qlhOypn.png

To try to nail this down, I tried swapping the positions in the config file of the RP1 and LOX tank entries, so LOX came before RP1, like so:


// LOX-RP1

TANK_DEFINITION
{
	name = CommonBulkheadStandard
	basemass = 0.000108649774484067 * volume
	TANK
	{
		name = LOX
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		temperature = -184
		loss_rate = 0.0000000000567356572258533 // 0.1% per day at 20°C
		amount = 0.65 * volume // liters
		maxAmount = 0.65 * volume // liters
		note = 
	}
	TANK
	{
		name = LH2
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		temperature = -253.8
		loss_rate = 0.0000000000422720017314612 // 0.1% per day at 20°C
		amount = 0.0 // liters
		maxAmount = 0.0 // liters
		note = 
	}
	TANK
	{
		name = RP1
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		amount = 0.35 * volume // liters
		maxAmount = 0.35 * volume // liters
		note = 
	}
	TANK
	{
		name = Hydrazine
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		amount = 0.0 // liters
		maxAmount = 0.0 // liters
		note = 
	}
}

Again, I don't know why, but I got the wrong answer in the VAB. It's 1365 liters of LOX, which adds up to 2100 liters × 65% leaving 735 liters left over, but there's only 420.7 liters of RP1, which is like 57.2% of that and which doesn't add up to anything. So I haven't figure out where that came from. But the point here is that the order of the tank config nodes in a tank definition matters.

lx9Lh3I.png

Next test was to try combining proportional maxAmounts with fixed ones. This tank definition is the same as the first one I showed you, only it also has 100 liters of hydrazine monopropellant in it.


// RP1-LOX-Hydrazine

TANK_DEFINITION
{
	name = CommonBulkheadStandard
	basemass = 0.000108649774484067 * volume
	TANK
	{
		name = LH2
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		temperature = -253.8
		loss_rate = 0.0000000000422720017314612 // 0.1% per day at 20°C
		amount = 0.0 // liters
		maxAmount = 0.0 // liters
		note = 
	}
	TANK
	{
		name = RP1
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		amount = 0.35 * volume // liters
		maxAmount = 0.35 * volume // liters
		note = 
	}
	TANK
	{
		name = LOX
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		temperature = -184
		loss_rate = 0.0000000000567356572258533 // 0.1% per day at 20°C
		amount = 0.65 * volume // liters
		maxAmount = 0.65 * volume // liters
		note = 
	}
	TANK
	{
		name = Hydrazine
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		amount = 100.0 // liters
		maxAmount = 100.0 // liters
		note = 
	}
}

Here I expect the tank to end up with 100 liters of hydrazine, 590 liters of RP1 and 1095 liters of LOX. (See below for how I got there.) Instead, I get this:

FHBnfzJ.png

Note that this is exactly the same as the first example, only with the tiny leftover space (left out by rounding off) filled with hydrazine. Which isn't right at all. Again, if I go into the UI, remove all tanks, manually create a 100-liter hydrazine tank, then tell it to auto-configure for an RP1/LOX engine, I get the right result:

BwUwskm.png

Just to confirm things, I then edited the config file to move the hydrazine entry to the top, like so:


// Hydrazine-RP1-LOX

TANK_DEFINITION
{
	name = CommonBulkheadStandard
	basemass = 0.000108649774484067 * volume
	TANK
	{
		name = Hydrazine
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		amount = 100.0 // liters
		maxAmount = 100.0 // liters
		note = 
	}
	TANK
	{
		name = LH2
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		temperature = -253.8
		loss_rate = 0.0000000000422720017314612 // 0.1% per day at 20°C
		amount = 0.0 // liters
		maxAmount = 0.0 // liters
		note = 
	}
	TANK
	{
		name = RP1
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		amount = 0.35 * volume // liters
		maxAmount = 0.35 * volume // liters
		note = 
	}
	TANK
	{
		name = LOX
		fillable = true
		efficiency = 0.85 // common bulkhead
		mass = 0.0
		temperature = -184
		loss_rate = 0.0000000000567356572258533 // 0.1% per day at 20°C
		amount = 0.65 * volume // liters
		maxAmount = 0.65 * volume // liters
		note = 
	}
}

Again, I got the wrong answer in the VAB.

oTuBz4i.png

The 100 liters of hydrazine is right, obviously. But the other two are both wrong, and I haven't figured out how the plugin got them.

So there's the bug-report part of this: The plugin is assembling tanks incorrectly. If you use both proportional tanks ("## * volume") and efficiencies of less than 1, the plugin does the math wrong.

My workaround is to leave all maxAmounts in the tank definition set to zero, then build my tanks manually in the VAB. This gives me the right answers always; the auto-configure button has never failed me so far. But it's an extra step for every single tank on every single spacecraft, and that's annoying. It works, it doesn't stop me using your (super-awesome) mod, but it's annoying.

Here's the feature-request part. In messing around with this, it occurred to me that the way tank definitions work could be changed to make it all much simpler. Now, I'm about to propose a big change, one that breaks compatibility, so I won't be offended if you laugh and walk away at this point.

The tank definition syntax could look like this:


TANK_DEFINITION
{
	name = CommonBulkheadStandard
	basemass = 0.000108649774484067 * volume
	TANK
	{
		resourceName = Hydrazine
		utilization = 0.85 // common bulkhead
		type = fixed
		maxAmount = 100.0 // liters
		amount = 100.0 // liters
	}
	TANK
	{
		resourceName = LOX
		utilization = 0.80 // common bulkhead, insulated
		type = proportional
		maxAmount = 0.65 // 65% of the remaining usable volume
		amount = 1.0 // this tank starts out 100% full
		temperature = -184
		loss_rate = 0.0000000000567356572258533 // 0.1% per day at 20°C
	}
}

1. Change "name" to "resourceName" for consistency.

This confused me at first. The name parameter to the TANK_DEFINITION node can be anything you want, but the name parameter under the TANK node must match a resource name. The stock modules tend to use resourceName for this, so I suggest it be changed.

2. Change "efficiency" to "utilization" for clarity.

This one might only make sense to me. In the literature (aw haw haw haw, how good of you to come for tea Lord Wobblypants) there's consistent talk of utilization fractions of propellant tanks, given as a percentage. You could adopt the same vocabulary if you wanted. I think it'd be a little clearer, but it might only be clearer to me.

3. Give tanks a "type" that's either "fixed" or "proportional."

I'm not married to the terms, obviously. The idea is that either a tank is defined to have a specific number of volumetric units of the resource in it (both maxAmount and amount), or it's defined in a proportional way, such that maxAmount is the fraction of the tank's usable volume and amount is the fraction of the tank's capacity.

How's this work in practice? Lemme walk you through a kinda complex example.


TANK_DEFINITION
{
	name = ServiceModule
	basemass = 0.000108649774484067 * volume

	// Oxygen supply, for use with IonCross
	TANK
	{
		resourceName = CompressedOxygen
		utilization = 0.90
		type = fixed
		maxAmount = 10.0 // liters
		amount = 10.0 // liters
	}

	// Waste COâ‚‚, again for IonCross
	TANK
	{
		resourceName = CarbonDioxide
		utilization = 0.90
		type = fixed
		maxAmount = 1.0 // liters
		amount = 0.0 // liters
	}

	// RCS monopropellant
	TANK
	{
		resourceName = Hydrazine
		utilization = 0.85 // common bulkhead
		type = fixed
		maxAmount = 200.0 // liters
		amount = 200.0 // liters
	}

	// Bipropellants for the main SPS engine
	TANK
	{
		resourceName = RP1
		utilization = 0.85 // common bulkhead
		type = proportional
		maxAmount = 0.35 // 35% of the remaining usable volume
		amount = 1.0 // this tank starts out 100% full
	}
	TANK
	{
		resourceName = LOX
		utilization = 0.80 // common bulkhead, insulated
		type = proportional
		maxAmount = 0.65 // 65% of the remaining usable volume
		amount = 1.0 // this tank starts out 100% full
		temperature = -184
		loss_rate = 0.0000000000567356572258533 // 0.1% per day at 20°C
	}
}

This is a notional tank definition file for an Apollo-esque service module. It's got life support tanks (assuming you're using IonCross, 'cause really, who isn't?) and a monopropellant tank, both of which have fixed volumes. The rest of the usable volume is divided up into 35% RP1 and 65% LOX for the SPS engine. That's the contrived example.

To parse this, start by setting the tank's remaining usable volume to its total volume, obviously. In this example, I'm gonna say that's 3000 liters, just to pick a round number.

Now iterate over the "TANK" nodes. For each one of type "fixed," divide the maxAmount by the utilization and subtract that from the remaining usable volume. In pseudocode:


remainingVolume = volume
foreach tank {
	if tank is fixed {
		remainingVolume -= tank.maxAmount / tank.utilization
	}
}

Just to walk through that, in this case we'd start out with a volume of 3000 liters, then subtract 10.0 ÷ 0.9 from it (2988.8), then subtract 1.0 ÷ 0.9 (2987.7), then subtract 200.0 ÷ 0.85, leaving us with about 2752.5 of remaining volume.

Then we iterate again, looking this time at the proportional tanks. For each one, take the remaining usable volume, multiply it by the amount (which is a fraction less than or equal to one), then multiply by the utilization.


foreach tank {
	if tank is proportional {
		tank.maxAmount = remainingVolume * tank.maxAmount * tank.utilization
	}
}

Here we have two proportional tanks, RP1 and LOX. For RP1, that'd be 2752.5 liters × 0.35 × 0.85, or about 818.9 liters. For LOX, it's 2752.5 liters × 0.65 × 0.80, or 1431.3 liters.

If we add it all up to check our work, we have the 10 liters of Oâ‚‚, the liter of COâ‚‚, 200 liters of hydrazine, 818.9 liters of RP1 and 1431.3 liters of LOX, all of which come to a total of 2461.2 liters, giving us an overall utilization fraction of 82.04%, which is right on the money.

Now, just to reiterate, this is only a suggestion. I think this would be an easy-to-use, (relatively) easy-to-code and pretty darned flexible system for allocating tank volume. It wouldn't be way better than what you have now, but I think it'd be better, and if I'm suggesting you need to open up the patient anyway, 'cause of my aforementioned bug, then I think changes along these lines might be worth considering.

Bottom line, though? Spectacular mod, as always, and thanks very much for it.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...