Habitat & atmosphere refactor

[ghost]

The current system treats crew module atmospheres as being pure nitrogen with kerbals breathing directly from an oxygen bottle. Pressurisation is done with only nitrogen and only nitrogen is lost to space. There's also no ambient oxygen atmosphere in the capsule from which kerbals can draw if the bottled oxygen runs out, which would normally extend the time to asphyxiation by several minutes or even hours for large habs if emergency scrubbers work.

Ideally it'd be nice to see a monitor for oxygen levels like with humidity, and leakage rates for oxygen and nitrogen, but a quick fix for the leakage issue could be to simply pressurise with oxygen and treat the hab atmospheres as 100% oxygen.

[gotmachine]

We have the project to rewrite the whole habitat/atmosphere/pressure thing at some point, as there are many issues with the current implementation. Changing how things currently work is just not an option, the code has zero flexibility due to the whole system being based on resources / pseudo-resources.

Here are some rough notes on my ideas for this (this is in no way a definitive plan) :

• Habitat is now internally managed "per section" instead of per part. When you add parts in the editor, they are in a single "section".
• You can split the vessel in multiple "sections" by clicking the 2 parts separating them.
  • This add a hatch (that maybe could have cost/weight) between the 2 parts.
  • Docking ports add hatchs by default, and hatchs can be closed/opened in flight.
  • Sections can be depressurized / repressurized. EVAs will trigger a depressurization of the section the kerbal is in.
  • Depressurization might (?) be able to reclaim/store some of the atmosphere contents back to the tanks (could be a capability added to some parts, or maybe a configurable thing).
• Each section is independent in terms of pressure, atmosphere content, radiation shielding, supply (resources) availability. Internally, they are managed like independent vessels.

Possible implementation of atmosphere contents/pressure :

• The habitat code store the amount of O2/CO2/N2 (as "virtual amounts") present in the whole section or vessel (multiple parts)
• Based on the "target composition" (ex : 22% O2/ 78% N2, could be a global setting or something the user can choose between presets) and the current proportion of O2/CO2/N2, deduce in which proportion they need to be added or removed. lets call this the "gas balance needs"
• Based on the ideal gas law formula and the section volume, deduce current pressure.
• Based on the "target pressure" (again this could be made configurable), "pressurization units capacity" and current pressure, deduce the amount of each gas needs / excess
• Those amounts are converted in "real" resources production/consumption requests
• Based on the availablility of said resources (either in storage or producing/consuming capacity of the ECLSS processes), add/remove the "virtual amounts" in the section (will need "virtual resource recipes" to define custom outputs in recipes).

This would get ride of all the habitat pseudo resources and allow things that are currently impossible, like airlocks
The resources (O2/CO2/N2) would be config-defined, for example to allow a more simple "Air/BadAir" system.

As for processes / controlers, the idea would be to globalize the capacity of all parts in the section and allow editor configuration / in flight usage "per section" in a non-PAW dedicated UI.
In the editor, you would be given "a process capacity" as points/slots, that you could distribute among all the available processes
And depending on the choices made, we would distribute the mass/cost evenly on all parts.
From this system, we can imagine some constraints on what processes can be put onboard. Example : "basic process slots" / "advanced processes slots".

[ghost]

IMO, I'm not sure if that considers some of the edge cases. Optimum values are all fine and dandy, but I don't think you'd always want to stick to them. If you're running low on nitrogen, for example, it might be worthwhile to shift to a pure oxygen atmosphere, or if temperature control energy requirements are too high, it might be easier to adjust humidity till the the wet bulb temperature is comfortable.

If we consider what exactly a kerbal needs from ambient atmosphere,

• oxygen ( o2 partial pressure with reference to total pressure, has min. and max. thresholds)
• carbondioxide (poisoning, co2 partial pressure wrt total pressure, min. for plants, max. for crew)
• total pressure (vacuum exposure, needs a bleeding threshold)
• wet bulb temperature (dry temp, from temp. control, humidity, total pressure)
  It's probably worth it to build a monitor that can track minimum and maximum allowed levels and react appropriately, especially since many of these values are a combination of multiple things.

[gotmachine]

Optimum values are all fine and dandy, but I don't think you'd always want to stick to them.

What you describe is way too complex. While a super-realistic simulation with atmo composition customization, temperature/humidity relationships, etc could seems appealing, it usually result in things being buggy, hard to understand and impossible to balance properly.

Things must stay at a reasonable level of abstraction.

An example of that :

We are thinking removing the whole atmospheric humidity thing altogether. From the gameplay POV, this is just redundant with the other life support needs. It doesn't involve any extra resource, it doesn't introduce anything new or different. It's just an extra line in the GUI.
And the problem is that it doesn't really work because we don't know where the atmospheric humidity is coming from (plants ? kerbals ? what is the proportion of transpiration/urine/feces ?).

The (currently broken) abstraction that was initially used for kerbalism's food/water cycle is as follow :

• The food resource always represent the "dry" content of the food.
• The water resource represent all water contained in the vessel : drinking water, washing water, food water content, atmospheric water.
• Kerbals turn water and food in waste water / waste food
• Recyclers turn back waste water into water (abstracting urine water reclaiming and atmospheric humidity control)

Now, the following is my own interpretation of what happened, and why humidity is a bad idea :

At some point, for some obscure reasons, greenhouses were made to output "non dry food" and not output waste water for its water consumption (I think because that required to have extra water recycling capacity when you have greenhouses) . This broke the whole paradigm, causing water to magically disappear, and the answer to that was to make water reappear trough the humidity thing, which did go even further in breaking the initial abstraction.

[SirMortimer]

At the same time, also look at the greenhouse code - it too has some hardcoded values in there.

  // WasteAtmosphere is primary combined input
  if (g.WACO2 && input.name == "WasteAtmosphere") recipe.AddInput(input.name, vd.EnvBreathable ? 0.0 : input.rate * elapsed_s, "CarbonDioxide");
  // CarbonDioxide is secondary combined input
  else if (g.WACO2 && input.name == "CarbonDioxide") recipe.AddInput(input.name, vd.EnvBreathable ? 0.0 : input.rate * elapsed_s, "");
  // if atmosphere is breathable disable WasteAtmosphere / CO2
  else if (!g.WACO2 && (input.name == "CarbonDioxide" || input.name == "WasteAtmosphere")) recipe.AddInput(input.name, vd.EnvBreathable ? 0.0 : input.rate, "");

[SirMortimer]

Get rid of the Atmosphere resource, or at least change the name to something else. See Kerbalism/Kerbalism#573

[Its-Just-Luci]

I can't even get greenhouses to appear in my save, I'll provide my ksp.log if needed when I get home

[gotmachine]

So, I'm working on a habitat / gravity ring / comfort merge and rewrite.
Objectives :

• Fix the bugs
• Ability to make radiation shelters by having the possibility to keep pressurized a disabled habitat. Disabled habitats can't be crewed and don't count for the stress/pressure/comforts/radiation modifiers.
• Depressurization is required for going on EVA. The per part pressure system works as follow :
  • Parts are considered depressurized if the pressure is below 0.3 atm (~7000m altitude on Kerbin)
  • Below that threshold, Kerbals automatically put their helmets (visible in the IVA / portraits)
  • Depressurized parts comforts are disabled and don't count toward the global comfort modifier
  • Depressurized parts volume don't count toward the living space modifier
  • Depressurized parts shielding still count toward the global habitat radiation [*]
  • Crew transfer between depressurized and pressurized parts is impossible
  • EVA is only possible from/to depressurized parts
  • When depressurizing, a % of the atmosphere is reclaimed as nitrogen (configurable per part)
  • Depressurization speed is configurable per part
  • Inflatables are deployed with pressure, they become fully deployed at 0.3 atm
  • Parts that are configured as non-pressurizable have their pressure equal to the external pressure if the atmosphere is breathable
  • Depressurized parts pressure is equal to the external pressure if the atmosphere is breathable
  • If the part is using the external pressure, Kerbals will get free CO2 scrubbing if they aren't in their helmets (so when pressure is > 0.3 atm)
• Separate configurable EC rates for
  • depressurization
  • deployement of inflatable/deployable habs
  • accelerating / decelerating centrifuges
  • steady rotation of centrifuges
• Per part configuration of the shielding capacity, allowing for radiation hardened parts (ex SSPX radiation shelter) or limited shielding (inflatables)

This is still the same system as before, based on pseudo resources, but using a cleaner and more abstract implementation that allow some tricks to make the above features possible. That also mean there are some technical limitations and hard to get around issues, but hopefully that should be pretty minor.

[*] : It should be possible, and a good thing to only make the depressurized hab parts surface count toward radiation protection only if there are kerbals in any of these parts.