Fraz86

@ShotgunNinja EnergyTweaks.cfg concerns me. These tweaks make Kerbalism effectively incompatible with any mod that has EC-generating or EC-consuming parts. Compatibility patches will be difficult to write, as there are no easy-to-follow rules about the adjustments that need to be made - EC rates are variously cut by 0% (ISRU, drills), 33% (RTG), 50% (radiators, lights), 67% (fuel cells), 75% (wheels, alternators), ~72% (ion engine), ~77% (static solar panels), and >90% (deployable solar panels). Furthermore, there is some discrepancy/imbalance among these tweaks (e.g., the OX-STAT generates 16 EC/mass while the OX-STAT-XL generates only 10 EC/mass) that exacerbates the lack of clarity. Because all EC rates are decreased except mining/ISRU, the primary effects of these tweaks are to increase the relative significance of batteries and make mining/ISRU more difficult. Personally, I would have preferred that you accomplish these effects by the opposite approach; i.e., increase battery capacities and mining/ISRU EC-consumption (with perhaps a modest decrease in solar panel output if necessary), while leaving other EC rates untouched. If you stick with the current implementation, I would ask that you please provide clear documentation on the recommended compatibility tweaks for other mods.

This mod looks amazing! ShotgunNinja, it seems you have an impeccable vision for game mechanics that introduce fun, interesting new elements without becoming overly complicated or burdensome. I read the wiki, but I'd like to know more on the specific mechanics of quality of life. How do you calculate living space? Is it just based on the number of seats? Are living space, entertainment, and social needs tracked as three separate needs, or do they combine into a single quality of life value? Any chance we could see a zero-G deconditioning mechanic in the future, encouraging the use of centrifuges (cf. Porkjet's hab mod)?

Fair enough. Your approach makes sense if you're starting with structural parts rather than fuel tanks.

Hmm, I get the idea - that, theoretically, dry mass comprises both a fixed "structural mass" and a variable "tank mass," but it strikes me as needlessly complicated. Config mass obviously already includes both, and we can easily leave the implied "structural" element constant by simply making adjustments based on differences in tank mass alone (with no need to modify the config mass). See my above numbers for examples. I believe that this approach is easier, more robust, and more precise in reproducing stock masses and costs.

Well, because of the silly way that KSP calculates cost (where dry cost = config cost - fuel cost), I would need to experiment with the fuel switcher to see how exactly it interacts with those calculations. If tankCost is modifying the total cost, including fuel, akin to the config cost, I think the following should be right: LFO, LH2Cryo = 0 (default configurations; no modification of config cost) LF = 0.341 OX = -0.279 LH2 = -0.0915 LH2O = -0.1665 LH2OCryo = [deleted - see below] EDIT - It turns out there isn't a way to accurately calculate LH2OCryo's cost using the tankCost variable alone, due to non-linear scaling. Instead, we need both of the following: costOffset = -0.2 * config cost tankCost = -0.1116 EDIT 2 - If the part switcher doesn't have a costOffset variable, or if the use of this variable is deemed undesirable, I came up with an alternate solution: Modify the part configs for all ZBO tanks, cutting their config costs in half (matching the costs of their stock analogues). Then, set tankCost at 1.0 for LH2Cryo, and 0.4884 for LH2OCryo. The resulting costs would scale a bit more linearly than other fuel tanks, but it would be reasonably similar.

Actually, there are important exceptions to the standard tankMassPerUnit (0.000625), namely, all spaceplane parts (0.0007125), multi-purpose modules (with fuel + X, e.g., batteries or MP), and your truss tanks. Granted, we could find a way to zero out config mass and still account for these variances, but I think it would be a more robust and simpler implementation to leave config mass untouched. It would also allow for better consistency with tankCost calculations, where we definitely can't zero out the config costs because they scale non-linearly. Here are the tankMass values for this approach: LFO, LF, OX, and LH2Cryo = 0 (these configurations should use the unmodified config mass) LH2 = -0.000375 LH2O = -0.000225 LH2OCryo = 0.000125 With these values, there would be no need for any massOffset or modification of existing config mass values.

Ah, that makes a bit more sense. But then, shouldn't tankMass = 0 for LFO, LF, and OX? If the mass specified in the part config is left untouched, then shouldn't stock tanks already have the correct mass for those fuel types? I do think this approach makes more sense overall, as opposed to zeroing out the part config mass. Nertea, I'd be happy to provide corrected tankMass and tankCost values for this implementation.

Looking at CryoTanksFuelTankTypes.cfg, I believe there are a few other issues to address: Oxidizer's tankMass should be 0.000625 Based on the values in B9PartSwitch.cfg, I think tankCost is meant to be the dry cost per unit volume (I imagine it adds the fuel cost automatically), whereas LH2 and Oxidizer's tankCost is currently set equal to the fuel cost per unit volume I believe we need two more tank types (LH2Cryo and LH2OCryo) in order to give ZBO tanks their higher mass and cost; tankMass should be 0.0003125 for LH2Cryo and 0.0004375 for LH2OCryo Edit - It should also be noted that B9PartSwitch.cfg appears to contain errors/misinformation, and thus should not be relied on as the basis for setting your variables. For example, based on stock values, rocket mass should be 0.000625, and spaceplane mass should be 0.0007125, in disagreement with the comment section at the top of the config: // Structural values (should be set by user) // Rocket // Mass = 0.0005 // Cost = 0.25 // Spaceplane (re-entry shielded, maxTemp > 2000) // Mass = 0.000625 // Cost = 0.375

Two of Nertea's mods - CryoEngines and KerbalAtomics - use IFS. See the ModuleManager file at the bottom of my post for specifics. It seems to work as intended, however, a couple interface issues have been noted. First, the "Engineer Report" in the VAB appears to miscalculate the mass of the fuel tanks, using twice the actual dry mass. Second, when you right-click one of the tanks in-flight, there is a line that reads "Dry mass: 0t." Both of these errors don't appear to have any real effect (the game still uses the correct mass values), but it's annoying nonetheless. If there's a different way to write the IFS config that would avoid these issues, please let me know. // 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.08 } }

I think 16L/day is meant to include water used for hygiene, food preparation, etc.

@mikegarrison @blowfish @Crzyrndm I noticed the same issues regarding the dry mass indicated in the Engineer's Report (doubled) and in-flight right-click (zero). As far as I can tell, they're purely display errors with no actual impact on gameplay, but annoying nonetheless. If any of you know a different way to set up the IFS config that avoids these issues, I'd be happy to re-work the fuel-switching patch.

Sounds good. However, the Mobile Processing Lab's recycler (added by LSModule.cfg) still consumes replacementparts.

Good find! Nertea, do you have any teasers regarding what this might entail?

That tank should hold 4800 LH2 and 320 OX. Either something went wrong with the latest release, or you have some other mod that is overwriting the tank capacities.

No, I am not using any other USI mods. Regardless, I don't think the USI-LS settings have any impact on Recycler ReplacementParts consumption (it's simply an INPUT_RESOURCE for the recycler module).

It bothers me that Recyclers consume ReplacementParts even when ReplacementParts consumption is otherwise disabled (i.e., when "ReplacementPartAmount = 0," as in the default settings for USI-LS). Not only does this result in faster-than-expected depletion of habitation time, as you observed, but it also means that Recyclers will eventually deplete all available ReplacementParts and stop working. @RoverDude I believe there's a way to set the Recyclers' ReplacementParts consumption based on ReplacementPartAmount. "Ratio = #$@LIFE_SUPPORT_SETTINGS/ReplacementPartAmount$" ought to work. Add another line that reads "@Ratio *= 10" if you want "ReplacementPartAmount = 0.000001" to correspond to a Recycler consumption rate of 0.00001 (the current rate).

I agree. The NFE implementation will be all around much more interesting and well balanced. The modulegenerator version is the problem; it's overpowered. For example, the Poseidon's modulegenerator (100 EC/s) is equivalent to 133 stock RTGs, which corresponds to a mass of 10.7t and a cost of 3,106,667 funds - for the generator alone. A lower mass and cost relative to RTGs can be justified for the NFE version, because it comes with additional challenges and limitations. But the "free electricity forever" version (i.e., modulegenerator) should probably produce substantially less EC in order to maintain reasonable balance.

I'm looking forward to NFE integration, however, I'm curious - do you plan to include any positive balancing factors to compensate for the challenges/limitations that NFE will add to the engines? A FissionGenerator producing 100 EC/s is significantly inferior to a ModuleGenerator producing 100 EC/s (no fuel required, no heat generated, etc.). It would strike me as fair if the NFE version was capable of producing at least twice as much EC as the ModuleGenerator version.

LH2 boiloff isn't intended to feel like an "RO-like property." It's intentionally simplified and easily prevented, so hopefully it feels more like a small factor that sets LH2 apart from other fuels in an interesting way, as opposed to a rigorous simulation of real-world challenges. Haha, well, as I'm sure you're aware, that thing is very far from a typical craft. It may be the case that hydrolox engines and NTRs need some buffing to make them more attractive. I think Nertea has wisely approached these balancing issues conservatively, because we absolutely don't want to create uber-engines that outright obsolete LFO.

The LH2/OX tankage ratio is currently 3:2, which I think is plenty handy, and much easier than the stock LF/OX ratio of 9:11. It's true that real-world LH2/OX tankage ratio is closer to 2:1, but Nertea's cryogenic engines run a bit more fuel-rich than their RL counterparts. Regardless, these ratios are reasonably close to RL, and precise realism has never been a high priority in Nertea's mods - balance take precedence, and I believe the current volume ratio offers the best balance.

Fuel:dry mass ratios are certainly much more meaningful for analysis of performance. However, when arguing that LH2 tanks ought to be lighter, based on comparisons to specific real-world rocket stages or lack of need for internal bracing (as Bluebottle was doing), I believe it's useful to step back and remember that empty LH2 tanks are actually the lightest objects in the game for their size.

Nertea's LH2 tanks are incredibly light. An LH2-only ZBO tank has only half the dry mass of an equivalently-sized LFO tank. LH2 lifting tanks are even less. The fuel:dry mass ratio for oxidizer (8:1) is derived from stock KSP, and as such is not something we would alter. Nor would we add boiloff to a stock resource. Adding boiloff for LH2 but not LOX makes a certain amount of sense anyway, as boiloff is a much less severe problem for LOX compared to LH2 in the real world. Moreover, the mass "penalty" for extra insulation/refrigeration for LH2 is actually relatively minor - that is, the interval mass difference between LH2 lifting tanks and ZBOs is equivalent to only 10% of the dry mass of a volume-matched LFO tank. The true dry mass "penalty" for LH2 tanks is primarily related to fuel density. LH2 is far less dense than other fuels, and therefore requires much greater (~700%) tank volume for an equivalent fuel mass. Greater tank volume means greater tank mass, though the mass per volume is actually only half as much (or less), as mentioned above, which partially offsets this penalty. The penalty is further mitigated by using 2x the real-world density of LH2. What we're left with should be a bit inferior to LFO as a fuel type, but reasonably easy to balance by giving NTRs attractive properties. What kind of craft are you building that requires 2000 EC/s for ZBOs? That should correspond to 18 of the ridiculous 10 meter tanks. Yes, absolutely. I'm not aware of any significant problems with the current implementation. It may come to light that a few things need some minor balancing tweaks, but I think it's a very robust framework.

It was motivated by a balancing dilemma: how to give LH2O tanks a meaningful dry mass disadvantage relative to LFO, despite LH2 representing only a small percentage of the tanks' mass (mostly OX), without making LH2-only tanks unplayably terrible as a result. I would recommend reading the dev thread if you'd like to know more. In regard to realism, the LH2:OX mass ratio was a little below real-world before, and a little above real-world now. The LH2:OX volume ratio is now closer to real-world.

@Shadowmage Your interpretation is correct, and yes, it's completely intentional. With CryoTanks, LH2 is given 200% real-world density inside fuel tanks for gameplay and balance reasons. Even with 2x real-world density, it remains far less dense than other fuels (e.g., ~14% LFO density) and thus still poses an interesting challenge to the player without becoming un-fun. Ideally, it would be nice for the LqdHydrogen resource definition to reflect this greater density (rather than being fudged via configs), but it's a CRP resource and thus can't be altered ad hoc.

Currently all recyclers consume 1 EC/s. I wrote a patch that sets recyclers' EC consumption as the product of their capacity and efficiency. For example, the science lab consumes 3.5 EC/s (5 capacity x 0.7 efficiency). I'll post it here if anyone is interested: @PART[*]:HAS[@MODULE[ModuleLifeSupportRecycler]] { @MODULE[ModuleLifeSupportRecycler] { @INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]] { @Ratio = #$/MODULE[ModuleLifeSupportRecycler]/CrewCapacity$ @Ratio *= #$/MODULE[ModuleLifeSupportRecycler]/RecyclePercent$ } } }