Fraz86

Alright, fair enough. Any chance I could persuade you that the copula's other features (i.e., built-in battery, MP tank, reaction wheel, and command capabilities) collectively account for 0.26t of its mass, and therefore justify a decrease of HabMultiplier to 1.5?

@RoverDude I'm concerned regarding the current balance between parts that add a HabMultiplier (e.g., the cupola) vs those that add KerbalMonths (e.g., the Hitchhiker). Due to the nature of multiplication vs addition, there will always be a vessel hab rating threshold, above which the addition of a HabMultiplier part yields a greater increase in Habitation time for a given number of Kerbals, and below which, parts that add KerbalMonths are superior. That's fair enough. The problem is that this threshold is currently very low. If a vessel has at least 5 capacity (a total hab rating of 150d for a single Kerbal), the addition of a cupola will yield a greater increase in hab time per unit mass (((5 original capacity + 1 seat added by cupola) * (1 default multiplier + 1.76 HabMultiplier) - 5 original capacity) / 1.76 cupola mass = 6.5682 KM added per ton) than a Hitchhiker (((5 original capacity + 4 seats added by Hitchhiker + 12 KM added by Hitchhiker) * (1 default multiplier) - 5 original capacity) / 2.5 Hitchhiker mass = 6.4 KM added per ton). Basically, adding a cupola turns out to be the best choice for increasing hab rating, so long as you're starting with at least 5 crew capacity (e.g., a Mk1-2 pod and a lab). It seems to me that this threshold should be significantly higher.

@RoverDude I'd like to better understand your reasoning regarding the current cost of supplies. A Kerbal consumes 486 supplies per month. At a cost of 15 funds per supply, that's 7290 funds per Kerbal per month. As such, the cost of food and water to sustain one Kerbal for one month is more than 12x greater than the cost of a Mk1 Pod. This strikes me as wildly unrealistic; several orders of magnitude too high. Is this intentional, or just a placeholder value that wasn't ironed out for the initial release?

Roverdude, I briefly experimented with 0.3.4 this morning and got some bizarre results with the HabMultiplier. I used a simple ModuleManager patch to give the Cupola a HabMultiplier of 2 for testing purposes. Subsequently, in the VAB, a lone Cupola with one Kerbal gave a habitation rating of 2y410d (1260d). I can't figure out how it arrived at 1260d from a total crew capacity of 1 and a HabMultiplier of 2, but that can't possibly be correct.

Structural fuselages should already allow surface attachment, when using a part appropriate for such purposes (Surface Attachable parts, e.g., the Radial Attachment Point, are meant to allow passable attachment on suitable curved surfaces). In principle, I agree it would be reasonable to allow Surface Attachable parts to attach to EVA hatches. The problem is, there is no good way to allow attachment to EVA hatches without allowing attachment to the entirety of the part's surface. I suppose someone could write a ModuleManager config that adds passable nodes at the locations of EVA hatches, but then there wouldn't be a way to require Surface Attachable parts for these nodes (which would be ideal since EVA hatches are usually on curved surfaces), and not everyone wants extra nodes added to their parts anyway. I also question how important it really is from a design perspective, as there should generally be easy alternative solutions. For example, the Mk2 Clamp-O-Tron can fill the role you described.

I'm not sure what you mean by "it works to 2/3" vs 1/3. I agree that the terms could perhaps be more descriptive. Unfortunately the terms you proposed are just plain incorrect. I might suggest something like "Surface is suitable for passable attachments" for Attachable Surface, and "Passable when attached to a suitable surface" for Surface Attachable.

I don't like it, because it's incorrect. Attachable Surface doesn't force anything onto child parts. A passable radial attachment requires both a parent part that has an Attachable Surface and a child part that is Surface Attachable. Neither one alone is sufficient. Technologicat provided an excellent summary of the rationale for the "Attachable Surface" concept: Likewise for the "Surface Attachable" flag, the idea is that most parts' passable nodes are specifically engineered to be joined with other passable nodes, not bolted to random uneven holes punched in a compartment's exterior.

I'm not seeing Kerbal Atomics in CKAN, despite its KerbalStuff page having the CKAN tag. Yesterday's update for Cryogenic Engines also doesn't seem to be available in CKAN. Any idea what's wrong?

I'm sorry, I don't think I'm expressing my point very clearly. I understand exactly how the habitation values are calculated, I hear you that it is by design, and I see how it makes some sense from a certain perspective. I'm trying to draw attention to to what I believe to be silly/counter-intuitive implications of the current system. Perhaps a more extreme in-game example would help. Imagine an enormous colonization ship with 10 Mk3 Passenger Modules. It can carry 160 Kerbals for 1 month. Seems reasonable. Add a single Hitchhiker, and now the ship can carry 164 Kerbals for 13 months. Thematically, the implication is that all 164 Kerbals onboard are somehow utilizing this single Hitchhiker in such a way that allows all 164 of them to remain comfortable 13x as long as they would without it. If we imagine that those 164 Kerbals are taking turns (in groups of 4) relaxing in the comfort of the Hitchhiker, each Kerbal would spend only ~8.8 minutes per day in the Hitchhiker, and yet those 8.8 minutes apparently allow them to tolerate 13 months of travel instead of only 1. That strikes me as rather incredible. My point is simply that, as the size of a vessel and its crew increases, one would intuitively expect a greater number of Hitchhikers would be required in order to achieve the same benefit. One would expect a cap on the number of Kerbals that can benefit from a single Hitchhiker, or at least diminishing returns. Instead, a Hitchhiker is cabaple of providing the same benefit per total crew capacity for any capacity. The silliness becomes more pronounced if viewed from the perspective of a single Kerbal (or with any low crew:capacity ratio) instead of max crew. With the above-described colony ship, the addition of the Hitchhiker takes the single-Kerbal habitation time from 160 months to 2132 months. That's an increase of 81.6 years resulting from the addition of a single Hitchhiker. If that's how you want it to work, of course that's your prerogative - I'm not trying to tell you what to do, and I don't mean to be a pain. I'm merely trying to illustrate that there are some thematically counter-intuitive consequences of the current calculation method, which you may or may not want to address.

I understand. My confusion is with respect to the manner in which ModuleHabitation's KerbalMonths dramatically enhances the habitation value of all seats on the vessel. To use your SUV example, adding a Hitchhiker is like towing a small camper trailer behind the SUV that can tolerate stuffing 4 people inside. Somehow, adding the camper makes it possible for 11 people to travel 13x as long as would be possible with 7 people in the SUV alone. Even if it were a large bus capable of carrying 50 people, towing a single small camper would allow 54 people to travel 13x as long as the bus alone. It just doesn't seem to make much sense that the Hitchhiker's effect scales perfectly with the total capacity of the vessel, providing more and more benefit the greater the total crew capacity.

My observations seem to demonstrate different behavior. Starting with a Mk1-2 Pod the total Habitation is 90d, as expected. The Hitchhiker should add 480d (120d from crew cap of 4 + 360d from ModuleHabitation with 12 KerbalMonths). Thus, a Mk1-2 Pod + Hitchhiker should have a total Habitation rating of 560d (1y135d). Instead, as seen in the screenshot below, it has 2730d (6y180d). Incidentally, 7 (total crew cap) x 13 (1 + 12KM) x 30d = 2730d, which is the basis for my previously posted formula. The same relationship can be demonstrated with every combination of parts I have tested. For example, the Mk2 Crew Cabin lacks a ModuleHabitation, and thus, typically adds only 120d (30d x crew cap of 4). This is confirmed in the below screenshot, which shows a total Habitation value of 210d for the Mk1-2 Pod (90d) + Mk2 Crew Cabin (120d), as expected. Given that the Mk1-2 Pod + Hitchhiker was previously shown to have a Habitation rating of 2730d, we might expect that adding a Mk2 Crew Cabin (120d) would give a total of 2850d (6y300d). Instead, as seen below, the total is 4290d (10y40d). Clearly the Habitation rating of this craft is not additive, as it is greater than the sum of its parts (4290d for all 3 parts versus 120d for only Mk1-2 + Cabin and 2730d for Mk1-2 + Hitchhiker). Again, this result is consistent with my previously posted formula, as 11 (total crew cap) x 13 (1 + 12KM) x 30d = 4290d (10y40d). EDIT: In retrospect, it's obvious that you meant that ModuleHabitation adds 12KM to the habitation rating of the vessel at max crew. This strikes me as an odd way to calculate the rating, though, as it means that the Hitchhiker adds 12KM to every seat on the entire vessel. Given that seats other than the Hitchhiker start with only a 1KM rating, the Hitchhiker basically increases the Habitation value of every seat by 1200%. This could be very powerful when applied to a vessel that already has a large number of seats (e.g., with a Mk3 Passenger Module), and I'm not sure it makes a lot of sense either. Though, if this behavior is intentional, I would be happy to better understand your reasoning.

Hmm, I apologize, but I'm still a bit confused. I'm specifically trying to understand exactly what this does: MODULE { name = ModuleHabitation KerbalMonths = 12 } My in-game testing indicates that it doesn't quite act through straitforward addition or multiplication of the habitation value. It looks like every seat on a vessel contributes a default of 1 KM to the habitation value. If a ModuleHabitation is present, then it looks like the aforementioned habitation value is multiplied by (1 + sum of KerbalMonths values defined in all ModuleHabitations). Is that right?

I've been trying to work out how exactly the HabitationModule works. I don't use MKS, but I intend to turn on the habitation mechanic and write configs for other mods to support it. I saw that LSModule.cfg gives the Hitchhiker a HabitationModule with 12 KerbalMonths (KM). At first, I assumed this would simply add 12 KM, or maybe 12 KM x # of seats (48 KM), but in testing I discovered that it's actually more complicated. It looks like the formula is Habitation = Vessel's total # of seats x (1 + Total of all KM added by HabitationModules). Is that correct and intended?

All of the numbers in that chart are meant to be plugged directly into the part configs. Thus, "mass" is dry mass, and "cost" is total cost.

@Nertea New fuel-switch config that properly discounts the cost of the LH2/OX configuration for ZBO tanks (because OX doesn't require fancy boiloff prevention). Requires the previously posted mass & cost changes for the ZBO part configs. // Lifting tanks @PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines],!MODULE[FSfuelSwitch]]:NEEDS[!modularFuelTanks&!RealFuels] { %LH2ConversionFactor = 10 // <- EDIT HERE (units of LH2 that occupy a volume equivalent to one unit of LF or OX) %LH2OUnitRatio = 15 // <- EDIT HERE (LH2:OX unit ratio for LH2O configuration; should correspond to burn ratio of cryogenic engines) %mixOXProportion = 0.4 // <- EDIT HERE (proportion of tank volume containing OX; should approximately = 1 / [1 + [LH2OUnitRatio / LH2ConversionFactor]]) %dryMassPerUnitLH2 = 0.000025 // <- EDIT HERE (dry mass per unit LH2 capacity) %LF = #$RESOURCE[LiquidFuel]/maxAmount$ %OX = #$RESOURCE[Oxidizer]/maxAmount$ %totalCap = #$RESOURCE[LiquidFuel]/maxAmount$ @totalCap += #$RESOURCE[Oxidizer]/maxAmount$ %onlyLH2 = #$totalCap$ @onlyLH2 *= #$LH2ConversionFactor$ %mixOX = #$totalCap$ @mixOX *= #$mixOXProportion$ %mixLH2 = #$mixOX$ @mixLH2 *= #$LH2OUnitRatio$ // masses %massOffset = #$mass$ %tempVar = #$totalCap$ @tempVar *= 0.000625 // standard dry mass per units of LF/OX @massOffset -= #$tempVar$ // accounts for non-standard tank mass, which should remain constant across fuel configurations, e.g., extra mass for spaceplane tanks %onlyLH2mass = #$onlyLH2$ @onlyLH2mass *= #$dryMassPerUnitLH2$ @onlyLH2mass += #$massOffset$ %mixLH2mass = #$mixOX$ @mixLH2mass *= 0.000625 @tempVar = #$mixLH2$ @tempVar *= #$dryMassPerUnitLH2$ @mixLH2mass += #$tempVar$ @mixLH2mass += #$massOffset$ // costs %LFOcost = #$LF$ @LFOcost *= 1.02 @cost -= #$LFOcost$ %mixLH2cost = #$mixLH2$ @mixLH2cost *= 0.03675 @tempVar = #$mixOX$ @tempVar *= 0.18 @mixLH2cost += #$tempVar$ %LFcost = #$totalCap$ @LFcost *= 0.8 %OXcost = #$totalCap$ @OXcost *= 0.18 %onlyLH2cost = #$onlyLH2$ @onlyLH2cost *= 0.03675 !RESOURCE[LiquidFuel] {} !RESOURCE[Oxidizer] {} MODULE { name = InterstellarFuelSwitch volumeMultiplier = 1 massMultiplier = 1 resourceGui = LF/OX;LH2/OX;LF;OX;LH2 resourceNames = LiquidFuel,Oxidizer;LqdHydrogen,Oxidizer;LiquidFuel;Oxidizer;LqdHydrogen resourceAmounts = #$../LF$,$../OX$;$../mixLH2$,$../mixOX$;$../totalCap$;$../totalCap$;$../onlyLH2$ displayCurrentTankCost = true hasGUI = true showInfo = true availableInFlight = false availableInEditor = true basePartMass = 0 tankMass = #$../mass$;$../mixLH2mass$;$../mass$;$../mass$;$../onlyLH2mass$ tankCost = #$../LFOcost$;$../mixLH2cost$;$../LFcost$;$../OXcost$;$../onlyLH2cost$ } MODULE { name = ModuleCryoTank FuelName = LqdHydrogen // in % per hr BoiloffRate = 0.05 } } // ZBO tanks @PART[*]:HAS[@RESOURCE[LqdHydrogen],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines],!MODULE[FSfuelSwitch]]:NEEDS[!modularFuelTanks&!RealFuels] { %LH2ConversionFactor = 10 // <- EDIT HERE (LH2 vs LF/OX capacity conversion; should be identical to LH2ConversionFactor for lifting tanks above) %LH2OUnitRatio = 15 // <- EDIT HERE (LH2:OX unit ratio; should be identical to LH2OUnitRatio for lifting tanks above) %mixOXProportion = 0.4 // <- EDIT HERE (proportion of tank volume containing OX; should be identical to mixOXProportion for lifting tanks above) %dryMassPerUnitLH2 = 0.00003125 // <- EDIT HERE (dry mass per unit LH2 capacity) %LH2 = #$RESOURCE[LqdHydrogen]/maxAmount$ %mixOX = #$LH2$ @mixOX /= #$LH2ConversionFactor$ @mixOX *= #$mixOXProportion$ %mixLH2 = #$mixOX$ @mixLH2 *= #$LH2OUnitRatio$ // masses %mixLH2mass = #$mixOX$ @mixLH2mass *= 0.000625 %tempVar = #$mixLH2$ @tempVar *= #$dryMassPerUnitLH2$ @mixLH2mass += #$tempVar$ // costs %LH2cost = #$cost$ @LH2cost *= 0.5 @tempVar = #$LH2$ @tempVar /= #$LH2ConversionFactor$ @tempVar *= 0.459 @LH2cost += #$tempVar$ @cost -= #$LH2cost$ %mixLH2cost = #$LH2cost$ @tempVar = 1 @tempVar -= #$mixOXProportion$ @mixLH2cost *= #$tempVar$ @tempVar = #$mixOX$ @tempVar *= 0.18 @mixLH2cost += #$tempVar$ !RESOURCE[LqdHydrogen] {} MODULE { name = InterstellarFuelSwitch volumeMultiplier = 1 massMultiplier = 1 resourceGui = LH2;LH2/OX resourceNames = LqdHydrogen;LqdHydrogen,Oxidizer resourceAmounts = #$../LH2$;$../mixLH2$,$../mixOX$ displayCurrentTankCost = true hasGUI = true showInfo = true availableInFlight = false availableInEditor = true basePartMass = 0 tankMass = #$../mass$;$../mixLH2mass$ tankCost = #$../LH2cost$;$../mixLH2cost$ } MODULE { name = ModuleCryoTank FuelName = LqdHydrogen // in % per hour BoiloffRate = 0.05 // in Ec per 1000 units per second CoolingCost = 0.10 } } EDIT: Corrected error in above fuel-switch config and added explicit cost calculation for lifting tanks.

This chart contains suggested mass and cost values for the ZBO part configs. Setting the correct mass in the part config will avoid the need for redundant calculation in the fuel-switch config. The suggested costs are 2x lifting tank costs, which corresponds to ~3x the "dry" cost for the tank itself (because ~1/2 of lifting tank cost is fuel). Mass Cost hydrogen-10-1 36 200000 hydrogen-25-1 2 11500 hydrogen-25-2 1 6000 hydrogen-25-3 0.5 3100 hydrogen-125-1 0.25 1600 hydrogen-125-2 0.125 1000 hydrogen-375-1 4.5 26000 hydrogen-375-2 2.25 13000 hydrogen-375-3 1.125 6500 hydrogen-radial-25-1 0.55 3400 hydrogen-radial-125-1 0.05 450 hydrogen-radial-375-1 2 11500 Once the above masses are implemented, the newest fuel-switch config is below. This update removes now-unnecessary mass calculations, adds a costOffset adjustment (to correct for IFS's faulty cost calculation), and removes OX-only ZBO tanks (no boiloff to prevent, and strictly inferior to OX-only lifting tanks). // Lifting tanks @PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines],!MODULE[FSfuelSwitch]]:NEEDS[!modularFuelTanks&!RealFuels] { %LH2ConversionFactor = 10 // <- EDIT HERE (units of LH2 that occupy a volume equivalent to one unit of LF or OX) %LH2OUnitRatio = 15 // <- EDIT HERE (LH2:OX unit ratio for LH2O configuration; should correspond to burn ratio of cryogenic engines) %mixOXProportion = 0.4 // <- EDIT HERE (proportion of tank volume containing OX; should approximately = 1 / [1 + [LH2OUnitRatio / LH2ConversionFactor]]) %dryMassPerUnitLH2 = 0.000025 // <- EDIT HERE (dry mass per unit LH2 capacity) %LF = #$RESOURCE[LiquidFuel]/maxAmount$ %OX = #$RESOURCE[Oxidizer]/maxAmount$ %totalCap = #$RESOURCE[LiquidFuel]/maxAmount$ @totalCap += #$RESOURCE[Oxidizer]/maxAmount$ %onlyLH2 = #$totalCap$ @onlyLH2 *= #$LH2ConversionFactor$ %mixOX = #$totalCap$ @mixOX *= #$mixOXProportion$ %mixLH2 = #$mixOX$ @mixLH2 *= #$LH2OUnitRatio$ // masses %massOffset = #$mass$ %tempVar = #$totalCap$ @tempVar *= 0.000625 // standard dry mass per units of LF/OX @massOffset -= #$tempVar$ // accounts for non-standard tank mass, which should remain constant across fuel configurations, e.g., extra mass for spaceplane tanks %onlyLH2mass = #$onlyLH2$ @onlyLH2mass *= #$dryMassPerUnitLH2$ @onlyLH2mass += #$massOffset$ %mixLH2mass = #$mixOX$ @mixLH2mass *= 0.000625 @tempVar = #$mixLH2$ @tempVar *= #$dryMassPerUnitLH2$ @mixLH2mass += #$tempVar$ @mixLH2mass += #$massOffset$ // cost offset - IFS adds fuel costs (contrary to stock) %costOffset = #$LF$ @costOffset *= 0.8 @tempVar = #$OX$ @tempVar *= 0.18 @costOffset += #$tempVar$ @cost -= #$costOffset$ !RESOURCE[LiquidFuel] {} !RESOURCE[Oxidizer] {} MODULE { name = InterstellarFuelSwitch volumeMultiplier = 1 massMultiplier = 1 resourceGui = LF/OX;LH2/OX;LF;OX;LH2 resourceNames = LiquidFuel,Oxidizer;LqdHydrogen,Oxidizer;LiquidFuel;Oxidizer;LqdHydrogen resourceAmounts = #$../LF$,$../OX$;$../mixLH2$,$../mixOX$;$../totalCap$;$../totalCap$;$../onlyLH2$ displayCurrentTankCost = true hasGUI = true showInfo = true availableInFlight = false availableInEditor = true basePartMass = 0 tankMass = #$../mass$;$../mixLH2mass$;$../mass$;$../mass$;$../onlyLH2mass$ } MODULE { name = ModuleCryoTank FuelName = LqdHydrogen // in % per hr BoiloffRate = 0.05 } } // ZBO tanks @PART[*]:HAS[@RESOURCE[LqdHydrogen],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines],!MODULE[FSfuelSwitch]]:NEEDS[!modularFuelTanks&!RealFuels] { %LH2ConversionFactor = 10 // <- EDIT HERE (LH2 vs LF/OX capacity conversion; should be identical to LH2ConversionFactor for lifting tanks above) %LH2OUnitRatio = 15 // <- EDIT HERE (LH2:OX unit ratio; should be identical to LH2OUnitRatio for lifting tanks above) %mixOXProportion = 0.4 // <- EDIT HERE (proportion of tank volume containing OX; should be identical to mixOXProportion for lifting tanks above) %dryMassPerUnitLH2 = 0.00003125 // <- EDIT HERE (dry mass per unit LH2 capacity) %LH2 = #$RESOURCE[LqdHydrogen]/maxAmount$ %mixOX = #$LH2$ @mixOX /= #$LH2ConversionFactor$ @mixOX *= #$mixOXProportion$ %mixLH2 = #$mixOX$ @mixLH2 *= #$LH2OUnitRatio$ // masses %mixLH2mass = #$mixOX$ @mixLH2mass *= 0.000625 %tempVar = #$mixLH2$ @tempVar *= #$dryMassPerUnitLH2$ @mixLH2mass += #$tempVar$ // cost offset - IFS adds fuel costs (contrary to stock) %costOffset = #$LH2$ @costOffset *= 0.03675 @cost -= #$costOffset$ !RESOURCE[LqdHydrogen] {} MODULE { name = InterstellarFuelSwitch volumeMultiplier = 1 massMultiplier = 1 resourceGui = LH2;LH2/OX resourceNames = LqdHydrogen;LqdHydrogen,Oxidizer resourceAmounts = #$../LH2$;$../mixLH2$,$../mixOX$ displayCurrentTankCost = true hasGUI = true showInfo = true availableInFlight = false availableInEditor = true basePartMass = 0 tankMass = #$../mass$;$../mixLH2mass$ } MODULE { name = ModuleCryoTank FuelName = LqdHydrogen // in % per hour BoiloffRate = 0.05 // in Ec per 1000 units per second CoolingCost = 0.10 } }

The volume ratio should be exactly 1.5L LH2 per 1L OX.

Why not give them the same mechanics as NFE reactors? I like consistency. There are a couple things to wrap up for LH2 tanks. We need to set tank costs. Do you have an idea of how much ZBOs should cost relative to lifting tanks? It may also be a good idea to change the mass in ZBOs' part configs to agree with the dry mass set by the fuel switch config. Lastly, I suggest eliminating the OX-only option for ZBO tanks, given that OX doesn't have any boiloff to prevent, and a ZBO OX-only tank will be strictly inferior to its lifting tank equivalent.

It also looks like the LH2 capacities of ZBO tanks are set based on the old LH2ConversionFactor of 8.25, so they'll need to be updated to hold 10x the total-stock-units instead. If it's helpful, here is my most recent recommendation for the fuel-switch config (one change not mentioned elsewhere; I now believe a BoiloffRate of 0.05 is plenty, given factors such as the 15:1 LH2O ratio, high LH2 dry mass, and narrowing the gap between ZBOs and lifting tanks): // Lifting tanks @PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines],!MODULE[FSfuelSwitch]]:NEEDS[!modularFuelTanks&!RealFuels] { %LH2ConversionFactor = 10 // <- EDIT HERE (units of LH2 that occupy a volume equivalent to one unit of LF or OX) %LH2OUnitRatio = 15 // <- EDIT HERE (LH2:OX unit ratio for LH2O configuration; should correspond to burn ratio of cryogenic engines) %mixOXProportion = 0.4 // <- EDIT HERE (proportion of tank volume containing OX; should approximately = 1 / [1 + [LH2OUnitRatio / LH2ConversionFactor]]) %dryMassPerUnitLH2 = 0.000025 // <- EDIT HERE (dry mass per unit LH2 capacity) %LF = #$RESOURCE[LiquidFuel]/maxAmount$ %OX = #$RESOURCE[Oxidizer]/maxAmount$ %totalCap = #$RESOURCE[LiquidFuel]/maxAmount$ @totalCap += #$RESOURCE[Oxidizer]/maxAmount$ %onlyLH2 = #$totalCap$ @onlyLH2 *= #$LH2ConversionFactor$ %mixOX = #$totalCap$ @mixOX *= #$mixOXProportion$ %mixLH2 = #$mixOX$ @mixLH2 *= #$LH2OUnitRatio$ // masses %massOffset = #$mass$ %tempVar = #$totalCap$ @tempVar *= 0.000625 // standard dry mass per units of LF/OX @massOffset -= #$tempVar$ // accounts for non-standard tank mass, which should remain constant across fuel configurations, e.g., extra mass for spaceplane tanks %onlyLH2mass = #$onlyLH2$ @onlyLH2mass *= #$dryMassPerUnitLH2$ @onlyLH2mass += #$massOffset$ %mixLH2mass = #$mixOX$ @mixLH2mass *= 0.000625 @tempVar = #$mixLH2$ @tempVar *= #$dryMassPerUnitLH2$ @mixLH2mass += #$tempVar$ @mixLH2mass += #$massOffset$ !RESOURCE[LiquidFuel] {} !RESOURCE[Oxidizer] {} MODULE { name = InterstellarFuelSwitch volumeMultiplier = 1 massMultiplier = 1 resourceGui = LF/OX;LH2/OX;LF;OX;LH2 resourceNames = LiquidFuel,Oxidizer;LqdHydrogen,Oxidizer;LiquidFuel;Oxidizer;LqdHydrogen resourceAmounts = #$../LF$,$../OX$;$../mixLH2$,$../mixOX$;$../totalCap$;$../totalCap$;$../onlyLH2$ displayCurrentTankCost = true hasGUI = true showInfo = true availableInFlight = false availableInEditor = true basePartMass = 0 tankMass = #$../mass$;$../mixLH2mass$;$../mass$;$../mass$;$../onlyLH2mass$ } MODULE { name = ModuleCryoTank FuelName = LqdHydrogen // in % per hr BoiloffRate = 0.05 } } // ZBO tanks @PART[*]:HAS[@RESOURCE[LqdHydrogen],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines],!MODULE[FSfuelSwitch]]:NEEDS[!modularFuelTanks&!RealFuels] { %LH2ConversionFactor = 10 // <- EDIT HERE (LH2 vs LF/OX capacity conversion; should be identical to LH2ConversionFactor for lifting tanks above) %LH2OUnitRatio = 15 // <- EDIT HERE (LH2:OX unit ratio; should be identical to LH2OUnitRatio for lifting tanks above) %mixOXProportion = 0.4 // <- EDIT HERE (proportion of tank volume containing OX; should be identical to mixOXProportion for lifting tanks above) %dryMassPerUnitLH2 = 0.00003125 // <- EDIT HERE (dry mass per unit LH2 capacity) %LH2 = #$RESOURCE[LqdHydrogen]/maxAmount$ %OX = #$LH2$ @OX /= #$LH2ConversionFactor$ %mixOX = #$OX$ @mixOX *= #$mixOXProportion$ %mixLH2 = #$mixOX$ @mixLH2 *= #$LH2OUnitRatio$ // masses %onlyLH2mass = #$LH2$ @onlyLH2mass *= #$dryMassPerUnitLH2$ %onlyOXmass = #$OX$ @onlyOXmass *= 0.000625 %mixLH2mass = #$mixOX$ @mixLH2mass *= 0.000625 %tempVar = #$mixLH2$ @tempVar *= #$dryMassPerUnitLH2$ @mixLH2mass += #$tempVar$ !RESOURCE[LqdHydrogen] {} MODULE { name = InterstellarFuelSwitch volumeMultiplier = 1 massMultiplier = 1 resourceGui = LH2;LH2/OX;OX resourceNames = LqdHydrogen;LqdHydrogen,Oxidizer;Oxidizer resourceAmounts = #$../LH2$;$../mixLH2$,$../mixOX$;$../OX$ displayCurrentTankCost = true hasGUI = true showInfo = true availableInFlight = false availableInEditor = true basePartMass = 0 tankMass = #$../onlyLH2mass$;$../mixLH2mass$;$../onlyOXmass$ } MODULE { name = ModuleCryoTank FuelName = LqdHydrogen // in % per hour BoiloffRate = 0.05 // in Ec per 1000 units per second CoolingCost = 0.10 } } And here are the recommended LH2 capacities for ZBO tanks: hydrogen-10-1: 1152000 hydrogen-25-1: 64000 hydrogen-25-2: 32000 hydrogen-25-3: 16000 hydrogen-125-1: 8000 hydrogen-125-2: 4000 hydrogen-375-1: 144000 hydrogen-375-2: 72000 hydrogen-375-3: 36000 hydrogen-radial-25-1: 17600 hydrogen-radial-125-1: 1600 hydrogen-radial-375-1: 64000

What changes are these? I'm not seeing any differences from the prior version. Also, solar panels are much less useful further out (e.g., 4% EC at Jool). While solar power might be a relatively easy solution at Kerbin's orbit, the EC requirment will be a much more significant obstacle for some destinations.

1. Realism for realism's sake has never been a high priority in Nertea's mods. There needs to be a compelling gameplay reason to introduce additional complexity/challenges. 2. ZBOs already have several unique challenges, including continuous EC requirement, the worst dry mass ratio in the game, and by far greater volume requirements than any other fuel type.

15:1 is the unit ratio. The volume ratio for LH2O is 3:2 (LH2:OX). @Captain Sierra If it's important for LH2 consumption to remain constant between modes (which I'm not sure that it is truly important), we need a total fuel mass burn rate for augmented mode that is ~5.706x that of LH2-only. Basically, the Augmented:LH2-only thrust ratio divided by the Augmented:LH2-only ISP ratio needs to equal 5.706. This would certainly be doable, it just depends whether or not Nertea cares enough about this detail to tune NTRs around it.

Total vessel mass needs to be held constant for a fair test. Fuel-switching alone will result in much lower fuel mass for the LH2-only mode, which will of course have lower Delta-V. LH2 needs much more tank volume.

Does going EVA reset the current-vessel time? For example, is it possible to set out from a multi-year base in a rover, but rather than bringing emergency shelters, just go EVA each time the current-vessel time approaches the rover's hab value? Regarding the historic-most-comfortable-hab rating, could the player build a super-comfortable hab structure adjacent to the launch pad, and simply transfer their Kerbals to the structure for a few seconds before embarking on missions? What are the implications of this rating?

Firstly, I believe balance decisions should be made independently of third-party mod mechanics/resources. Nertea's mods have always been tuned for stockalike gameplay. Secondly, frankly, over-incentivizing this kind of complex gameplay (just-in-time ISRU, etc.) is exactly what I'm worried about. Regardless of what balance we choose, it will be possible to utilize lifting tanks on interplanetary missions (in place of ZBOs) by relying on ISRU. If the performance gap between lifting tanks and ZBOs is too large, ISRU-based missions become basically the only smart way to use atomic rockets, and ZBOs will have limited use cases. We should remember that Nertea was very reluctant to implement boiloff at all - and for good reason! Boiloff has the potential to be an annoying, un-transparent, and un-fun game mechanic. Nertea only decided to implement boiloff because we couldn't think of a better way to make one set of tanks advantageous in atmosphere and the other set advantageous in space. There is a strong temptation to give boiloff highly sophisticated gameplay implications, but I believe it would be wise to stay focused on the original goal: ZBOs for space, lifting tanks for atmosphere. This goal is best accomplished with a small dry mass advantage for lifting tanks, in order to avoid creating too much incentive to find ways to use lifting tanks in space (though the option will still exist for those who are motivated to do so).