Jump to content

Mod idea: Cabin Temperature Equilibrium


Recommended Posts

Allowing radiators to do their true first job. Featuring @benjee10 and @AtomicTech.

We all know that life support mods tend to follow the trend of "Kerbals must have continuous access to ElectricCharge and at least one resource that represents food, water and/or air." We also know that there is a very important dynamic that all life support mods have failed to touch on because either, there's a technical hurdle due to the game's spaghetti code, or no one has thought long enough on how to approach it. This dynamic is crewed space temperature, and with it comes the elephant in the room: Radiators in KSP don't do the primary thing that we the players (not the devs) expect of them... provide the "EC" in "ECLSS" (Environmental Control and Life Support System for those who don't know the acronym).

My proposal is that, rather than have kerbals require something that's constantly threatening to run out (food or ElectricCharge) have the kerbals require to avoid something filling up (an EH: Enviro-Hostility gauge). The layout of this life support dynamic is then:

(Basic) Conditions

  • Just like with thermal mass, each part that holds crew has a capacity for heat (concerning life support only) and the rate it collects heat is determined by the part's volume and the number of occupied seats.
  • Each kerbal produces heat and is a danger to itself on EVA and in an environment which doesn't provide convective cooling and whose ambient temperature is outside of an ideal, tolerable range.
  • Heat absorption through insolation is a core issue and is part of why the ISS has its radiators. If a vessel is under some measurable sun exposure in vacuum, it should produce some E-H just by existing, therefore, it should need ECLSS. Technically, this feature already exists in stock KSP but Kerbin would need to orbit lower than Moho for this to work properly so maybe this bit can be left out entirely, saving on some complexity.
  • Equilibrium in this context is defined as whether the current internal temperature of a kerbal or crewed part is within or very near a given ideal temperature range such as 289 ~ 300 K. The more that the part or kerbal deviates from this equilibrium range is the faster that the E-H gauge fills (it's like a timer, not a resource holder) and if it fills completely, kerbals die, even inside the part.
  • Radiators can opt in as protections against positive E-H (Overheat), but only the white, low temperature ones should as they are meant to be used for ECLSS. The gray metal and black Graphene high temp ones are meant to be used with things that normally run super hot and should not opt in as ECLSS parts. This keeps the white radiators fully relevant on a vessel that has heavy smelters or atomic devices on it.
  • Optionally, the actual heat of a part doesn't always need to be respected (as to avoid disastrous interference by the timewarp heat bug) but a form of "virtual heat" alone could be respected. Maintaining equilibrium then comes down to just having enough compatible radiators to offset the total E-H produced by kerbals and resource converters.

(Advanced) Conditions

  • Enviro-Hostility goes both ways. Negative E-H (Overcool) of a part or kerbal can arise from a ship or kerbal: Being far enough from a star that it gets 0 insolation; Orbiting in the shadow of a planet; Being landed or splashed under a frigid atmosphere.
  • Adjacent crewed parts (see: Connected Living Spaces) can serve as buffers to one another and slow the increase of E-H.
  • There is only one bar for E-H and its value is always positive. The measure of hostility is only the effect of how far the ambient temp deviates from the ideal temp and this measure only needs to have positive numbers.
  • Parts that have resource converters in them can also produce E-H as an effect of their modules running (such as the LS recyclers in MKS' habitation parts).
  • Some parts can opt in as heat producers and protections against negative E-H. Some may find plenty value in the idea of the threat of freezing death in their Mars/Duna base.

 

In summary, the idea of this life support is that there is an environmental hostility gauge whose fill rate depends on how much the environment temperature differs from the ideal temperature of a kerbal. Some but not all radiators are ECLSS compatible and allow for minimizing this differential. While kerbals have a melting point of a whopping 800 K, death by overheating doesn't wait for that temperature. (If kerbals are anything like humans they would die at just under 400 K.) The ideal temperature range could always be configurable so users of Deadly ReEntry could tighten this as they need.

Edited by JadeOfMaar
Link to comment
Share on other sites

9 hours ago, Spaceman.Spiff said:

Interesting idea. Seems like it could be potentially be achieved with some kind of Kerbalism and SystemHeat integration?

The only likeness to System Heat is that there is or should be a restriction on what radiators should be usable. It's indeed about maintaining a heat loop that doesn't concern ISRU and engines. This is within scope for Kerbalism, I think, but I'd rather that it has compatibility without dependency and without coming close to provoking Kerbalism's incompatibility with mods like MKS.

If you're suggesting that this could be done by wedging those two mods tighter together somehow then you're free to experiment and I'd like to see if and how that works out. But ideally this gameplay loop should start from the ground up and be as simple as USI LS or Snacks. That means more players and the more basic of players are willing to install it.

Link to comment
Share on other sites

On 7/6/2023 at 10:03 PM, JadeOfMaar said:

The only likeness to System Heat is that there is or should be a restriction on what radiators should be usable. It's indeed about maintaining a heat loop that doesn't concern ISRU and engines. This is within scope for Kerbalism, I think, but I'd rather that it has compatibility without dependency and without coming close to provoking Kerbalism's incompatibility with mods like MKS.

If you're suggesting that this could be done by wedging those two mods tighter together somehow then you're free to experiment and I'd like to see if and how that works out. But ideally this gameplay loop should start from the ground up and be as simple as USI LS or Snacks. That means more players and the more basic of players are willing to install it.

From a technical perspective, the input and output temperatures are far lower, necessitating a different working fluid. For a life support radiator, you're basically limited to either water or ammonia. Ammonia is more efficient, and to date nearly all LS radiators in the real world use Ammonia. I've been thinking for a while about trying to model this in KSP via System Heat and possibly a modified version of TAC-LS or a custom mod, but I've been either too lazy or too busy to start creating one.

Link to comment
Share on other sites

I've been thinking for a while of changing Simplex Kerbalism so all the life support modules (scrubbers, air presure) are on radiators rather than crew cabins.  This would only be for the statics, the larger extendible ones generate a  made up coolant which ISRU and nuclear generators need.

What yiu are suggesting might be possible someway with Snacks.  Kerbals require a certain amount of coolant across a vessel, this is a balance for number of kerbals and volume or surface area of parts.  @Watermel00n's  new mod may offer a plugin for this somehow as well. The trick would be for working in the cases that you thought of.  Frigid sea et al. 

 

 

 

Link to comment
Share on other sites

On 7/8/2023 at 11:44 AM, SpaceFace545 said:

You would also have to work with a lot of parts from mods which have integrated radiators in the SM or in the capsule itself.

This shouldn't be a big issue. I've gotten myself plenty experience by creating one or more mods that reduce the wanting player's work to just tagging the appropriate parts with the key and value the mod will look for. All I have to care about is ensuring a working, error-free system as far as my config skills allow. As for whoever wants parts to be supported, it will (in large part, if not entirely) be up to them to make the effort to sift out parts and tag them. And all they have to do is something basic like:

@PART[thisMod_this|thisMod_that|thisMod_thistoo]
{
  	EqRad = yes
}

Like @theJesuit mentioned, things do get more interesting (if it's implemented) when you have to face atmos and oceans where it's below freezing and your kerbals need access to something that generates heat so their suits and cabins don't become their meat lockers. Choosing parts and modules that qualify may be the hardest part.

Edited by JadeOfMaar
Link to comment
Share on other sites

  • 2 weeks later...

I'm going to attempt to make this mod idea. However, since I'm not that good at modding, I will try to simplify it a bit.

  • Only one factor, CabinHeat
  • CabinHeat grows linearly.
  • Not affected by sun, water or outside temperature.
  • No UI to easily view the stats of each vessel

It's pretty dumbed down, but when I get more confident I'll try to add these in

Link to comment
Share on other sites

As someone who tried to design and implement such a system for Kerbalism, this is a technically difficult feature, especially if you want to factor environmental conditions in a stable and coherent behavior, especially during timewarp.

Aside from the technical difficulties, one pain point is designing proper planning tools in the VAB so the user can know how much cooling/heating will be required for the mission profile.

I would suggest a simplified system like Kerbalism does : compute an analytic "average environment temperature" at the vessel position (ideally using simplified rules), get the difference between that and the "ideal" temperature, scale that diff by some measure of hab size (amount of crew seats is a decent proxy), then have :

- Integrated "heater" in crewable parts consuming EC to make up for a negative scaled diff.

- Radiator parts consuming EC to make up for a positive scaled diff.

This would result in a stateless, vessel wide system (avoiding some timewarp related issues) that is relatively simple and predictable, as by the custom temperature evaluation can be simulated for various situations in the VAB.

There is a major difficulty in the temperature evaluation if you try to account for dynamic solar occlusion (ie, time spent in shadow/eclipse), as this fundamentally won't work at mid-high timewarp speeds. Simplifying the problem to some average solar exposure has the drawback of eliminating a lot of gameplay aspects, like intentionally choosing specific orbits or locations where you are always in sunlight or in the shade of something, and proper solutions to solar exposure evaluation are quite complex and performance intensive.

I would advise against any kind of interop with the "usual" KSP thermal stuff, be it general part thermodynamics, core heat or its modded replacement (SystemHeat). They are complex and finnicky systems each having specific purposes and area of application, extending or interoperating with them is hard and limiting.

Link to comment
Share on other sites

  • 5 months later...
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...