Your comments

Having said all that, I think the current implementation is fine for serving the purpose it needs to. This was just something I had fun with to think about so I posted the result here, but I think actually implementing it would likely take more work and dev time than what it would add to the overall gameplay experience.

I gave a bit of thought to this a short while ago, and some of the alternate methods could actually work even without having to change gameplay or assets, except for the description of the systems involved, although there would be some unexplained/omitted parts of the process in this case.


It would also be possible to take this change to the next level, which would require the additon of a number of new assets and gameplay elements, however, would also extend ther range of player activities, and as a result game complexity and difficulty.


Let's consider the following factors:

  • As pointed out here and in also in a topic on the Steam Discussions for the game, CO2 is abundant in the atmosphere of Mars and thus being a potentially better candidate for harvesting O2 than finding and thawing only locally present and non-renewing water ice then splitting it into (discarded) H2 and O2.
  • In a closed system such as the habitat, only relatively low amounts of "new" consumables need to be introduced: a considerable amount of water can be recycled from the interior atmosphere (exhaled water vapor and perspiration) and by processing waste water, and Oxygen can be partially recovered by re-splitting CO2 exhaled back to the interior atmosphere (save for the amount that has been bonded into other, non-recoverable/inaccessible molecules by human metabolic processes).
  • The habitats were obviously placed on the surface by a powered landing process: they are equipped with a set of landing thrusters, and by extension, it's reasonable to assume that they have on board fuel reserves, not all of which was used up during landing (emergency margin). It is also reasonable to assume that this fuel may be hydrazine, which, by a catalytic process, can be split into N2 and H2, both of which being usable for maintaning a habitable environment in one way or another.

Using the above, life support system of the habitats could conceivably work as follows:

  1. Reoxygenator draws CO2 from external and internal atmosphere, receives N2 from Water Reclaimer (see below), recycles internal air through a process that removes physical/chemical/biological contaminants partialy by using replaceable active carbon filter cardridges and excess humidity (passed on to the Water Reclaimer for further processing). By splitting the collected and stored CO2, Reoxygenator produces O2 part of which is used locally and other part is passed on to the Water Reclaimer, and elemental Carbon in the form of activated/absorbent carbon which can be collected to be used for making carbon filter cardridges.
  2. Water Reclaimer primarily recycles waste water and the humidity excess received from the Reoxygenator, partially by way of using replaceable active carbon filter cardridges. To cover for unavoidable water losses (which should be reasonably small compared to the amount that can be recycled) due to various reasons, it is capable of producing water by drawing reserve hydrazine from the fuel tanks of the habitat's landing system, splitting it into N2 and H2, passing N2 to the Reoxygenator to be used as atmospheric filler to maintain internal pressure, and burning the H2 with the O2 received from the Reoxygenator to produce water. Recycled and produced water is then stored in tank until used.

The basic level of implementation would be just to update the description of the systems involved to roughly what's described above, without actually implementing the new elements of the process such as the hydrazine reserves and the Carbon production. The only change needed would be that instead of the current dependency (Water Reclaimer needs to be running to produce Oxygen), the systems can run independently to produce their respective resource, but only at 50% efficiency if only one is running, and 100% efficiency would only be achieved when both are online at a given time.


The complex implementation would require adding a number of new game obejcts and gameplay processes:

  • New resource types: Hydrazine, Nitrogen, Hydrogen, Absorbent Carbon
  • New crafting plans for making canisters filled with Hydrazne, Nitrogen and Hydrogen at different crafting stations.
  • Changed crafting plan: Carbon Filter now requires a certain amount of Absorbent Carbon in addition to the current materials.
  • New (one time?) crafting plan to craft "Hydrazine Splitter" tool.
  • New tool: Hydrazine Splitter, to enable crafting of Hydrazine Filled Canisters into 1x Nitrogen Filled Canister and 2x Hydrogen Filled Canister per job.
  • New storage capacity in the Reoxygenator for N2 and Absorbent Carbon, and in the Water Reclaimer for H2 (O2 is seamelssly exchanged between the two as needed, drawing from the O2 reserve tank).
  • New interaction point somewhere on the exterior of the habitats to "craft" Hydrazine Filled Canisters using empty canisters and interacting with this interaction point, from a finite amount of Hydrazine reserves in the habitat's propellant storage tanks.

Gameplay then would be as follows:

  • Reoxygenator, when powered, produces a certain amount of Oxygen and Absorbent Carbon over time, but with different efficiency levels. If the Nitrogen tank is empty, efficiency is only 50%, if it contains reserves, then efficiency is 100% until Nitrogen reserve is used up. Absorbent Carbon tank is non-blocking: excess over 100% capacity (if not emptied regularily) is simply lost.
  • Water Reclaimer, when powered, produces a certain amount of (recycled) water over time, but with different efficiency levels. If the Hydrogen tank is empty, efficiency is only 50%, if it contains reserves, then efficiency is 100% until Hydrogen reserve is used up. Compared to the simple implementation, the premise here is that the Water Reclaimer was NOT meant to be able to produce water by burning H2 and O2, this option is only present due to some addition/reconfiguration supposedly (but not being an active part of the gameplay) done by the player character at some point. (Actually, it also could be implemented by some interaction: use those large Storage Tanks and some other materials in a one time, per Reclaimer, interaction that adds the H2 storage capacity and converts it from the regular configuration to one that is capable of H2+O2 burning to produce water instead of just recycling.) (Another thing could be to somehow limit the "recycling only" water production over time: the more days have passed since the system was first brought online in any given hab, the water recycled per day would constantly diminish towards a minimal, very low value, unless upgraded to the water producing variant and supplied with H2.)
  • To improve production efficiency, the player needs to acquire a Hydrazine Splitter crafting plan by some means, and craft the tool.
  • Wth the tool available, the player will be able to "craft" Empty Canisters into Hydrazine Filled Canisters at an exterior interaction point at a 1:1 ratio per job requiring a reasonably short time.
  • With the tool available, the player can craft, at the interior crafing station, 1 Hydrazine Filled Canister and 3 Empy Canisters into 2 Hydrogen Filled Canisters, 1 Nitrogen Filled Canister and 1 Empty Canister.
  • The Hydrogen/Nitrogen Filled Canisters can be used to manually fill the respective tanks of the Water Reclaimer and Reoxygenator, potentially raising their effectiveness from halved to nominal.
  • The Absorbent Carbon collected from the Reoxygenator is needed to craft replacement Carbon Filters which are required by both the Reoxygenator and Water Reclaimer to function.

A somewhat simplified version could be not to require a Hydrazine Splitter and the processes associated with it, only a one time per unit reconfiguration of the Water Reclaimers from the regular version to the water producing version, which adds an internal Hydrazine tank, which needs to be filled manually, from time to time, with Hydrazine drawn from the habitat propellant reserves.

No, it happened in a new game started in 0.56.2. I revisited the location two times after the initial "discovery", coming in from different directions and the "discovered and added to map" event consistently never triggered for that location.


I still have the save, I can check it once more to be sure, and can attach the save file if that helps figuring it out.

Now that I had a longer of time to see it in action, I think a bit of change/tweaking would be in order.


As far as I could determine, stamina loss (and lower vitals) currently lowers the heart rate cap, meaning that your heart rate increase stops at a lower value as you lose vitals and while under stamina "cooldown/recharge", but the heart rate delta is always the same (about 3-4 per "tick", however long ticks are).


I think what would be more realistic is that the heart rate cap stays the same and vitals/stamina level instead modifies the rate delta: the worse condition you are in in either/both regard, the higher the delta gets and thus the faster your heart rate builds up to the same cap (blood nutrients/oxygenation gets lowered by worse condition, so more blood needs to be moved in a given time interval to supply the same amount, meaning heart rate needs to go up faster, not that it can only get to a lower value; actually, I think that exhaustion / nutrients/oxygen deprivation condition in fact results in a higher heart rate under the same physical load than you see when in a better metabolic state, so the current cap lowering effect is sort of incorrect).

I, on the other hand, don't think it's necessary. Hit "v", check vitals screen, hit "v" again. 3 seconds tops.


Vitals tracking isn't really a function of the EVA suit itself, and isn't something you need a constant, second to second display of. You need to keep it in mind and go that extra mile to check it via the Datapad every now and then.

And how will you solve the part where the mouse would have to control both the cursor for using the datapad and the turn/look function of the player character?


I'm not sure why perople have such a hard time accepting this control scheme. It took me only a few minutes to get used to it, with the small limitation that while I move (left hand on WSAD keys) and manipulate the datapad (right hand on arrow keys + enter) I have no hand left for turning with the mouse. But I don't see a way to solve that part without adding a third hand to the players, so...

Apparently I missed your request for more information back then, sorry.


PC, Windows 7 64 bit, Firefox 54.0 32 bit


Activating the overlay on the browser window takes several seconds, but if you open the Task Manager, you'll see 2 instances of GameOverlayUI.exe. Setting Task Manager to show the command lines of the processes reveals that one of these instances are opened for the PID of the game, and another for the browser process.

Although the "right now" part may in fact hint at something like this, but maybe this could be communicated to an extent by placing am EVA suit / mannequin in a standing / suspended pose somewhere in the airlock room when the Hab is in a condition that allows you to fully remove it.

Preventing running indeed has been fixed, but it's still not getting unequipped when entering the habitat.


It's a problem since you don't have the option to unequip it while inside (when you select it in the inventory while inside, the unequip/drop options don't appear at the bottom of the left side panel), so you won't be able to run there either (yea, I know, I'm too impatient for wanting to run even in a small place like the hab interior :). I guess this was the reason why it's supposed to get uneqipped on entering.


Actually... can't run inside even when it's unequipped. Was it possible to run while inside previously at all, or I remember it wrong? I'm pretty sure it was. At any rate, the not being able to unequip it part still stands.

I also feel time might be going a bit too fast. Often I found myself waking up just around / before sunrise planning for a longer trip, then went to the storage to pick up some food to eat, water to take with me and make some inventory <-> storage arrangement, then eat and head out... and it's already past noon by the time I get out with only having done just those few quick things...?


So I'm also for considering slowing game time down just by a little bit. For me it's on the verge of being just about right but with times when it feels off, even taking the need of an acelerated rate into account.


Maybe slightly increse the time needed for system slot maintenance, crafitng and salvaging (does salvaging take time now, by the way? if it does't, it should since you're not just smashing things to pieces and picking up the debris, but carefully dismantling something to keep materias reusable as much as possible) to at least situationally compensate for the "extra" time changing the ratio would provide?


Another trick could be to make time go slightly slower while inside a habitat compared to whatever rate it goes by while outside. This could help keeping the visible effects of the passage of time noticeable when they are actually visible, and remedy the above mentioned "I only got up, ate, drank, grabbed my stuff, and yet it took me half a day" effect.


Also, while I've not explicitly tested this, but it seemed to me that game time is still passing while you are waiting for the load transition between interior to exterior, and if that's the case, that also can rob you of a fair amount of time. Granted, it's a lengthy process from an in-game perspective (getting into the EVA suit, sealing it, verifying integrity and systems, waiting for pressure equalization etc.) so it should take a fixed amount of time, but load time (which varies by software/hardware environment of the player) shouldn't add time on top of that if it's just done by a "mark the real time when transition begins, mark when transition ends and skip game time forward accordingly" method.