Fraz86

It's been ~30 hours since Kerbal Planetary Base Systems updated from 0.2.7b to 0.2.8, but CKAN has yet to recognize that an update is available. Any idea what the problem is?

Making base parts usable only when landed is a reasonable option, but would likely be controversial. The Dirt option (or something similar) would allow players to continue using the parts in space, but ensure that surface usage has a clear advantage. I actually kind of like the idea of using KPBS parts as hab modules on an interplanetary ship, which are then landed and reconfigured into a planetary base upon arrival. If you decide to condone use of the parts in space, I would love to have a CLS-passable version of the Bi-Cupler (it would obviously need to be much thicker to plausibly accommodate crew movement through it). Mining Fertilizer from the ground would still require adding resource definitions to make Fertilizer present on planetary surfaces. Also, the concept of harvesting Fertilizer from planetary surfaces may be confusing or immersion-breaking for some players. Frankly, I'm not a fan of Fertilizer in the first place - it doesn't really add meaningful/interesting gameplay, it just requires the player to do extra math to calculate the optimal ratio of supplies/fertilizer/greenhouses. Moreover, mulch (Kerbal poop) and fertilizer seem conceptually redundant. Using Ore would avoid the need for new resource definitions, but - again - may be confusing or immersion-breaking. Also, it forces the player to bring a mining drill to cultivate plants, which is a bit odd. I like Dirt because it's intuitive and allows for a harvesting method separate from drills (e.g., airlocks in my patch above). Indeed, looks like there's a missing {. By the way, Nils, there's really no need to add CLS modules to parts that are both non-crewable and impassible.

The Flexible Corridor's max length of 100m seems rather excessive. For comparison, the parts included in KAS have max lengths of 8m for the CS-R2 Strut and 20m for the CC-R2 Connector port. Also, the K&K Two-End Corridor 3 has the same mass as two Flexible Corridors, but is only 2.5m long. Granted, the Flexible Corridor has lower crashTolerance, but this minor weakness cannot justify its 4000% 'length per mass' advantage. A max length of 10m might be reasonable, but even at 10m, I might also suggest increasing its mass to 0.15t.

The Mk3 Cargo Bays and Z-4K Battery (which has crew hatches) are missing CLS support. Here is a patch: @PART[batteryBankLarge]:Final { %MODULE[ModuleConnectedLivingSpace] { %passable = true } } @PART[mk3CargoBay*]:Final { %MODULE[ModuleConnectedLivingSpace] { %passable = true } }

I wanted to share a patch I made for KPBS and USI-LS. I had three goals in mind: Create a gameplay incentive to build on a planetary surface, as opposed to KPBS modules having identical functionality in space. Give airlocks a practical gameplay purpose. Keep supply management simple. The recent release of MKS-Lite provided some inspiration. MKS-Lite introduced 'Dirt', a resource abundant on all planets and required to operate the 'Agricultural Module', restricting its use to planetary surfaces. I decided to replicate this arrangement for KPBS, but without the additional complexity of MKS-Lite (I prefer the simplicity of 'dirt + mulch -> supplies', without involving fertilizer/organics). Airlocks are used to collect dirt (but only with an engineer on-board), based on the idea that an airlock is necessary to facilitate the frequent excursions & hauling of materials necessary to gather soil for plant cultivation. I'm quite happy with the result, so I thought I'd post it here for others who might be interested. This patch adds the functionality described above for the KPBS greenhouse and airlocks: @PART[KKAOSS_Greenhouse_g]:Final { @RESOURCE[Fertilizer] { @name = Dirt @amount = 0 @maxAmount = 500 } @RESOURCE[Mulch] { @maxAmount = 500 } @RESOURCE[Supplies] { @amount = 500 @maxAmount = 500 } @MODULE[PlanetaryGreenhouse] //supplies output 0.000225 = 4.5 Kerbals { @INPUT_RESOURCE:HAS[#ResourceName[Fertilizer]] { @ResourceName = Dirt @Ratio = 0.01 } @INPUT_RESOURCE:HAS[#ResourceName[Mulch]] { @Ratio = 0.0001 //2 Kerbals } @INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]] { @Ratio = 6 } } } @PART[KKAOSS*airlock*]:Final { @description = Airlocks are essential for tasks requiring frequent excursions. This module can facilitate the gathering of soil for plant cultivation, if an engineer is on-board. MODULE { name = ModuleResourceHarvester HarvesterType = 0 Efficiency = 0.00000001 ResourceName = Dirt ConverterName = Soil Gathering StartActionName = Start Gathering Dirt StopActionName = Stop Gathering Dirt AutoShutdown = false GeneratesHeat = false UseSpecialistBonus = true SpecialistEfficiencyFactor = 100000000 SpecialistBonusBase = 1 Specialty = Engineer EfficiencyBonus = 1 } } And this patch adds Dirt as a planetary resource (copied from MKS-Lite): RESOURCE_DEFINITION { name = Dirt density = 0.0016 flowMode = ALL_VESSEL transfer = PUMP isTweakable = true unitCost = 0.3 color = 1,1,0 } PLANETARY_RESOURCE { ResourceName = Dirt ResourceType = 0 PlanetName = Jool Distribution { PresenceChance = 0 MinAbundance = 0 MaxAbundance = 0 Variance = 0 Dispersal = 0 } } GLOBAL_RESOURCE { ResourceName = Dirt ResourceType = 0 Distribution { PresenceChance = 100 MinAbundance =20 MaxAbundance = 50 Variance = 50 Dispersal = 3 } }

Nils277, It looks like the new airlocks are lacking CLS support. Also the Flexible Corridor. Unrelated question: what's the difference between PlanetaryGreenhouse and ModuleResourceConverter?

I recommend a few tweaks for CLS support. Add passability: Service Bay Two-End Corridor Habitat MK2 Restrict passability to hatches only: Command Module Cupola Service Bay Laboratory LV25 "Meerkat" Landing Assist Planetary Adapter Two-End Corridor Greenhouse Habitat MK1 Habitat MK2 See the patch below for details: @PART[KKAOSS_Control_g] { %MODULE[ModuleConnectedLivingSpace] { %impassablenodes = front, back } } @PART[KKAOSS_Cupola_g] { %MODULE[ModuleConnectedLivingSpace] { %impassablenodes = back } } @PART[KKAOSS_Service_g] { %MODULE[ModuleConnectedLivingSpace] { %passable = true %impassablenodes = front, back, inner_bottom, inner_top } } @PART[KKAOSS_Science_g] { %MODULE[ModuleConnectedLivingSpace] { %impassablenodes = front, back } } @PART[KKAOSS_engine_g] { %MODULE[ModuleConnectedLivingSpace] { %impassablenodes = front, back, leg_1, leg_2 } } @PART[KKAOSS_adapter_g] { %MODULE[ModuleConnectedLivingSpace] { %impassablenodes = front, back, leg_1, leg_2 } } @PART[KKAOSS_gangway_2_adapter] { %MODULE[ModuleConnectedLivingSpace] { %passable = true %impassablenodes = leg_1, leg_2 } } @PART[KKAOSS_Greenhouse_g] { %MODULE[ModuleConnectedLivingSpace] { %impassablenodes = front, back } } @PART[KKAOSS_Habitat_MK1_g] { %MODULE[ModuleConnectedLivingSpace] { %impassablenodes = front, back } } @PART[KKAOSS_Habitat_MK2_g] { %MODULE[ModuleConnectedLivingSpace] { %passable = true %impassablenodes = front, back } }

Sure, no problem! Here is my current patch for the Sifter: @PART[MKSL_Sifter] { @MODULE[ModuleResourceHarvester]:HAS[#ResourceName[Ore]] { @Efficiency = 0.1 } } And here is the info displayed for the Sifter in the VAB, which is the same with or without the above patch: It seems that "max output" = "1.00/sec" regardless of what changes I make within ModuleResourceHarvester. I'm trying to figure out if I'm doing something wrong, or if this is expected behavior.

Thanks for the tip. It looks like "Max outputs" remains "1.00/sec" regardless of Efficiency (or other values). Is that working as intended?

It appears that any part placed using KIS is given a thermalMass of 1.0. The thermalMass for most parts is ordinarily in the hundreds or thousands - even the smallest parts have a thermalMass > 10. Thus, a thermalMass of 1.0 is extremely low, and potentially prone to random explosions. Is this a known bug?

Roverdude, I'm attempting to modify the Sifter such that it is much less effective at harvesting ore. Could you give a brief explanation of Efficiency, EfficiencyBonus, SpecialistEfficiencyFactor, and SpecialistBonusBase in ModuleResourceHarvester?

I can't find an explanation of ModuleResourceHarvester. I'm interested in understanding Efficiency, EfficiencyBonus, SpecialistEfficiencyFactor, and SpecialistBonusBase. For reference, here is the module on the radial drill: MODULE { name = ModuleResourceHarvester HarvesterType = 0 Efficiency = 1 ResourceName = Ore ConverterName = Surface Harvester StartActionName = Start Surface Harvester StopActionName = Stop Surface Harvester ImpactTransform = ImpactTransform ImpactRange = 5 AutoShutdown = false GeneratesHeat = false UseSpecialistBonus = true SpecialistEfficiencyFactor = 0.2 SpecialistBonusBase = 0.05 Specialty = Engineer EfficiencyBonus = 1 INPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 15 } } Anyone know what these values do?

I tested & confirmed that this method worked as intended in 1.02 when I made a very similar patch for Nertea's Stockalike Station Pack. So unless there's been a change since 1.02, it should work. It does indeed add (and not replace) the specified part.

I can't seem to find this mod on CKAN. Anyone have an idea what I might be doing wrong?

Here's a patch that allows the K&K Planetary Cupola to satisfy a copula request in a base construction contract: @Contracts { @Base { @PART_REQUEST:HAS[#Part[cupola]] { Part = KKAOSS_Cupola_g } } }

Glad to hear it! I am very much looking forward to the new mechanics, however, I'm slightly disappointed by the idea of rest/comfort resetting every time the Kerbal enters a vessel. Instead, I wish rest/comfort = [habitation rating of current vessel (KM/crew)] - [elapsed time since Kerbal was in a vessel with habitation rating > current vessel (or elapsed time since launch, if the Kerbal has never been in a vessel with a greater habitation rating)]. This would function basically the same as your current comfort system, except that EVA/re-entering the same vessel (or transferring between vessels of similar size) would not extend Kerbals' comfort. It would also eliminate the usefulness of exploitive gameplay, e.g., building a massive habitation complex at the launchpad.

I'm very excited for the upcoming habitation mechanics. Will gravity have any advantage over non-gravity (e.g., planetary surface vs orbit, centrifuge vs fixed module) with respect to comfort/homesickness?

It's been ~36 hours since Cryogenic Engines updated to version 1.9, but CKAN still shows the latest version as 1.81. Is this a CKAN issue?

I'm happy to help! The table in my prior post preserves your model-based volumetric measurements for determining relative capacities. As an alternative, please consider the following values, which conform your tanks to the logic of stock fuel tanks. Basically, if a tank is twice as long, it holds twice the volume (e.g., FL-T800 = 2x FL-T400 = 4x FL-T200 = 8x FL-T100). If a tank has twice the diameter, it holds 4x the volume (e.g., X200-32 = 4x FL-T800). Personally, I like the simplicity of these relationships. The values I selected provide perfect correspondence with the volumes of stock tanks (e.g., Centi-3 = FL-T800, HI-M-21 = Jumbo-64, Mondo-60 = S3-14400), which guarantees good balance when using the fuel-switching patch. This version has the added benefit of producing nice round capacity numbers in all configurations (LH2 only, LH2/OX, and OX only). EDIT: Updated the table with rounded off dry masses.

From the FAQ on the first page: Q: RealFuels support? A: I will be making a special RO version of this pack in the future. It will have correct sizing, thrusts, transform locations and such. The ETA on this is unknown.

For anyone who would like to use static radiators with NFE reactors, I wrote a ModuleManager patch that changes static panels from passive to active. The new heat parameters are identical to folding radiators. I also decreased static radiators' cost so there is a reason to consider using them. Nertea, you're welcome to include this as an optional patch for NFE if you like. @PART[radPanelSm] { @cost = 50 @heatConductivity = 0.001 %skinInternalConductionMult = 2000 @radiatorHeadroom = 0.75 @thermalMassModifier = 2.5 MODULE { name = ModuleActiveRadiator maxEnergyTransfer = 500 } } @PART[radPanelLg] { @cost = 250 @heatConductivity = 0.001 %skinInternalConductionMult = 2000 @radiatorHeadroom = 0.75 @thermalMassModifier = 2.5 MODULE { name = ModuleActiveRadiator maxEnergyTransfer = 2500 } }

This doesn't work for two reasons: The static radiators receive heat from other parts by conduction alone; they lack the active heat transfer ability of the folding panels. Reactors are very well insulated, and therefore conduct very little heat. Even if static radiators were able to actively transfer heat, they also have much less surface area than the larger folding panels recommended for an MX-2, and it would require a huge number of them to radiate its heat. EDIT: Upon further inspection, the surface area : mass ratio is actually reasonably consistent between static and folding radiators, but still, there is very little reason to ever use static radiators.

Yes, exactly. The following table summarizes my recommendations (values to be defined in part configs are highlighted in red): EDIT: This will require an update to the fuel switch patch as well. Here is my recommendation for the new patch to accompany the above changes (removes cryoFudgeFactor and updates dry mass offset calculation): // LF/O tanks @PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines],!MODULE[FSfuelSwitch]]:NEEDS[!modularFuelTanks]:NEEDS[!RealFuels] { %LF = #$RESOURCE[LiquidFuel]/maxAmount$ %OX = #$RESOURCE[Oxidizer]/maxAmount$ %totalCap = #$RESOURCE[LiquidFuel]/maxAmount$ @totalCap += #$RESOURCE[Oxidizer]/maxAmount$ %LH2FudgeFactor = 1.5 // <- EDIT HERE (effectively multiplies LH2 density by this number) %mixOXProportion = 0.45 // <- EDIT HERE (proportion of tank volume containing OX; this value should be set approximately = 5.5 / [5.5 + [10 / LH2FudgeFactor]]) %massPerUnitLH2 = 0.000035 // <- EDIT HERE (dry mass per unit LH2 capacity) %onlyLH2 = #$totalCap$ @onlyLH2 *= 5.5 @onlyLH2 *= #$LH2FudgeFactor$ %mixOX = #$totalCap$ @mixOX *= #$mixOXProportion$ %mixLH2 = #$mixOX$ @mixLH2 *= 10 %tempVar = 0 %dryCost = 0 @dryCost = #$cost$ %LFCost = 0 %OXCost = 0 %LH2Cost = 0 %mixLH2Cost = 0 %mixLFCost = 0 // compute cost of stock tank fuel @tempVar = #$RESOURCE[LiquidFuel]/maxAmount$ @tempVar *= 0.8 @mixLFCost += #$tempVar$ @tempVar = #$RESOURCE[Oxidizer]/maxAmount$ @tempVar *= 0.18 @mixLFCost += #$tempVar$ @dryCost -= #$mixLFCost$ @cost -= #$mixLFCost$ // Cost LF only @tempVar = #$totalCap$ @tempVar *= 0.8 @LFCost += #$tempVar$ // Cost OX only @tempVar = #$totalCap$ @tempVar *= 0.18 @OXCost += #$tempVar$ // Cost LH2 only @tempVar = #$onlyLH2$ @tempVar *= 0.03675 @LH2Cost += #$tempVar$ // Cost mix @tempVar = #$mixLH2$ @tempVar *= 0.03675 @mixLH2Cost += #$tempVar$ @tempVar = #$mixOX$ @tempVar *= 0.18 @mixLH2Cost += #$tempVar$ // masses %massOffset = #$mass$ @tempVar = #$totalCap$ @tempVar *= 0.000625 // standard dry mass per units of LF/OX @massOffset -= #$tempVar$ // this value accounts for any non-standard fuel tank mass, which should remain constant across fuel configurations, e.g., extra mass for spaceplane tanks %mixLH2mass = #$mixOX$ @mixLH2mass *= 0.000625 @tempVar = #$mixLH2$ @tempVar *= #$massPerUnitLH2$ @mixLH2mass += #$tempVar$ @mixLH2mass += #$massOffset$ %onlyLH2mass = #$onlyLH2$ @onlyLH2mass *= #$massPerUnitLH2$ @onlyLH2mass += #$massOffset$ @tempVar = 0 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$ //tankCost = #$../mixLFCost$;$../mixLH2Cost$;$../LFCost$;$../OXCost$;$../LH2Cost$ displayCurrentTankCost = true hasGUI = true showInfo = true availableInFlight = false availableInEditor = true basePartMass = 0 tankMass = #$../mass$;$../mixLH2mass$;$../mass$;$../mass$;$../onlyLH2mass$ } !RESOURCE[LiquidFuel] {} !RESOURCE[Oxidizer] {} } // Pure LH2 tanks @PART[*]:HAS[@RESOURCE[LqdHydrogen],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines],!MODULE[FSfuelSwitch]]:NEEDS[!modularFuelTanks]:NEEDS[!RealFuels] { %LH2 = #$RESOURCE[LqdHydrogen]/maxAmount$ %LH2FudgeFactor = 1.5 // (this should match LH2FudgeFactor for stock tanks above) %mixOXProportion = 0.45 // (this should match mixOXProportion for stock tanks above) %massPerUnitLH2 = 0.000025 // <- EDIT HERE (dry mass per unit LH2 capacity; this should be < massPerUnitLH2 for stock tanks) %massPerUnitOX = 0.0005 // <- EDIT HERE (dry mass per unit OX capacity; this should be < the standard stock value of 0.000625) %OX = #$LH2$ @OX /= #$LH2FudgeFactor$ @OX /= 5.5 %mixOX = #$OX$ @mixOX *= #$mixOXProportion$ %mixLH2 = #$mixOX$ @mixLH2 *= 10 // masses %onlyLH2mass = #$LH2$ @onlyLH2mass *= #$massPerUnitLH2$ %massOffset = #$mass$ @massOffset -= #$onlyLH2mass$ // this value accounts for any non-standard fuel tank mass, which should remain constant across fuel configurations, e.g., lower dry mass ratios for larger tanks @onlyLH2mass += #$massOffset$ %mixLH2mass = #$mixOX$ @mixLH2mass *= #$massPerUnitOX$ %tempVar = #$mixLH2$ @tempVar *= #$massPerUnitLH2$ @mixLH2mass += #$tempVar$ @mixLH2mass += #$massOffset$ %onlyOXmass = #$OX$ @onlyOXmass *= #$massPerUnitOX$ @onlyOXmass += #$massOffset$ @tempVar = 0 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$ } !RESOURCE[LqdHydrogen] {} }

Nertea, Though not an urgent issue, I suggest editing the part configs of the cryogenic LH2 tanks to adjust their masses and capacities, such that they are consistent with those set by the fuel switching patch. Currently, anyone who chooses not to use the fuel switching patch will have fuel tanks with very different properties. Another potential issue to address while editing part configs, is that the fuel switching patch preserves absolute offset in dry mass relative to the "standard" dry:wet ratio (extra dry mass for small tanks, less dry mass for large tanks), while decreasing dry mass across the board, which has the result of exaggerating differences in dry:wet ratios between LH2 tanks. For example, the 10m tank currently has a dry:wet ratio around 1:7.7, which is probably too good for any LH2 tank. If you'd like, I can look through the part configs and make some specific recommendations.

Are you using the latest release? The current fuel switching functionality leaves other resources (e.g., monoprop in Nertea's service tanks) untouched.