Fraz86

January 29, 2016

46 minutes ago, RoverDude said:

I'm fine with the threshold as-is, especially given the MKS changes and it's expected effect on base size. As always, we'll see how I feel about it after a few playthroughs.

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?

January 28, 2016

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

January 28, 2016

@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?

January 25, 2016

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.

January 25, 2016

7 hours ago, Technologicat said:

There are some parts, where this is useful - e.g. in the Mk2 Stock-a-like Expansion, there is the Mk2 Mobile Processing Lab MPL-SM, which has a hatch at the top. The hatch is clearly meant for EVA, and it has no attachment node, but it could conceivably be kerbalized to bolt a passable part onto it instead (which may be useful if building a space station out of these parts).

The structural fuselages are also an example of a part where punching random holes may be useful for particular craft designs.

(But granted, such parts are in a minority.)

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.

January 25, 2016

4 hours ago, Kerbal101 said:

But it works to 2/3!
"Attachable Surface / Surface Attachable" works to 1/3, because I only understand "Passable".

Machine Washable
Washable Machine

Fruity Juice
Juicy Fruit

Program Kerbal
Kerbal Program

Bad interface design burrows any excellent concept.

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.

January 24, 2016

On 1/22/2016 at 7:34 AM, Kerbal101 said:

CLS Passable -> Is passable (because, CLS manages ability to pass anyway)

CLS Surface Attachable -> Also surface passable (because manual talks about how it causes "passability when the part is attached radially to another part" (ie somthing is attached as surface to it), not about it restricting ability to attach things as surface; also because this does not work, if its not passable, hence "Also").

CLS Attachable Surface -> And forces it on child (because this is about part forcing "surface passable" onto anything attached to it via surface method, and not about "attachable surface")

On 1/22/2016 at 10:34 AM, Papa_Joe said:

I like that. I never liked the cloudy relationship those two have... it is necessary, but it isn't well described and I could not think of a better way. Look forward to a better naming convention there. Thanks!

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:

Quote

Generally speaking, punching holes at random locations on meticulously designed spacecraft components does not make much sense (even if it would shorten Jeb's trip to the snack storage). The exception are things such as structural fuselages, where the inside consists of pretty much empty space.

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.

January 23, 2016

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?

January 22, 2016

12 hours ago, RoverDude said:

No. Again, it's a multiplier. We tally total KM them multiply it by the crew ratio.

So a vessel designed to hold 10 crew for 20 months will hold 1 crew for 200 months. Again, this is absolutely by design. This is not a defect, this is the way it works. Provide your Kerbals a lot more space, and the hab value is extended by the ratio of current crew to the maximum crew of the vessel.

Even a Mk-1-2 pod with zero extra bonus can go from 30 days (3 crew) to 90 days (1 crew). Same formula. This is why the hab month bonuses are fairly low.

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.

January 22, 2016

1 hour ago, RoverDude said:

The ratings are based on max crew. If you reduce crew, you dramatically increase available space, reduce crowding, and reduce wear and tear on the various systems. So, your setup above would be perfectly fine for a pair of Kerbals to do a jaunt to and from Duna - plenty of space. But not so good if you stuffed it to the max.

Just because I can sit seven people in my SUV and can tolerate stuffing seven people in it to go out to lunch does not mean I'd want to stuff seven people in it for a cross-country road trip, despite being the same SUV, and having the same (optimistic) listed capacity as 'seven adults'.

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.

January 22, 2016

5 hours ago, RoverDude said:

Not quite.

It is 1 month per crew cap (configurable) then we add in the KerbalMonths. The only multiplier is if you have a HabMultipler.

KerbalMonths is turned into seconds for computation purposes - a KerbalMonth being equal to 30 6-hour days (so 180 hours).

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.

January 21, 2016

2 hours ago, RoverDude said:

The general rule of thumb is that something is either a multiuplier, or adds KerbalMonths.

If it adds more space (KerbalMonths) add months equal to mass * 5

If it is a multiplier, set multiplier equal to the mass.

In either case, make sure you add ReplacementParts equal to: crew capacity + Kerbal Months. * 100

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?

January 21, 2016

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?

January 20, 2016

4 hours ago, Nertea said:

@Fraz86, that table you posted, that's total masses, not dry masses, right? Just asking because you mention adjusting in the cfg, where dry masses are specified.

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.

January 17, 2016

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

January 16, 2016

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
	}
}

January 16, 2016

1 hour ago, Psycho_zs said:

Is everything right with LH2/OX volume ratios?

I've found the separate configuration that very closely matches the current LH2/OX ratio and by volume it looks awkward.

Upper tank is LH2, Lower tank (75% of Jumbo) filled with OX. If simplified as cylinders, their volume ratio is somewhere around 1.5.

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

January 15, 2016

4 hours ago, Nertea said:

Trimodal reactor generators use up uranium? Open to discussion

Why not give them the same mechanics as NFE reactors? I like consistency.

Quote

??? (what have I missed to release these versions of mods)

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.

January 15, 2016

54 minutes ago, Nertea said:

@Fraz86I think I forgot a few things. Hazard of putting a build together right before work, some things didn't propagate right...

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

January 15, 2016

12 hours ago, Nertea said:

Newest balance fixes to CryoTanks fuel switch patches

What changes are these? I'm not seeing any differences from the prior version.

31 minutes ago, Nertea said:

10 Ec/s for a large 3.75m tank is a bit of an ouch, given that most stock panels generate 2 Ec/s

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.

January 15, 2016

1 hour ago, Jimbodiah said:

Even with cooling, you would expect some kind of loss. A lossless system IRL would be larger than the tanks themselves. Liquid N also just evaporates, even with 20cm of insulation and storage in a freezer.

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.

January 14, 2016

1 hour ago, Jimbodiah said:

15 mondo-60 tanks for LH2, and 1 mondo-60 for Oxidizer.

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.

January 14, 2016

13 minutes ago, Captain Sierra said:

I was using a mock-up interplanetary vessel which uses ZBO tanks and the Posdeidon NTR (also tested at one point with 3 neptunes). I was swapping between LH2/Ox and pure LH2 in the fuel switch options. The only thing I was changing was what was in the tanks. All other things held constant.

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.

January 14, 2016

4 hours ago, RoverDude said:

We also track a few things - how long you've been in your current vessel, when you were last on Kerbin, and the most comfortable hab you've been in. We then compare two things - have you been in your current vessel for too long (i.e. have exceeded it's hab value compared to your time in vessel), and have you been away from Kerbin too long (by looking at your Kerbin time and your best historic hab time). This lets us do scenarios like having crew in a nice multi-year base still have issues if they go gallivanting off in a rover for too long (and justifies the Karibou's emergency shelters). It also lets you set up nice R&R stations that you can rotate larger crews through to bump up the time before they get homesick. At the same time, it prevents players from 'resetting the clock' by just hopping in and out of a base.

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?

January 13, 2016

7 hours ago, riocrokite said:

@Fraz86

From my perspective a substantial penalty for ZBO tanks makes sense since it allows to build more interesting gameplay. For example just-in-time ISRU production of fuel or storing LOX/LH2 on orbital stations as water (then all those fancy heat radiators and big panels on space stations finally make sense since it takes quite a lot of energy or heat dissipation to convert lh2/lox into water and other way round ;)) I'm thinking here about a gameplay without stock ISRU since it's imho too op (should be able to produce only oxidizer from ore and at much slower pace).

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

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by Fraz86