I also feel that electrical power generation is a bit over-abundant with the current production capability of the various panels. I may have been just extremely lucky, but in my first playthrough all 3 habs had more than enough panels installed right when I found them, plus I found a lot more panels (2 large, 5 or 6 meds and 3 or 4 portables) so I had plenty of spares too. Maybe a slight adjustment/reduction would be in order, something like this:

Large Panel - 40% system power (currently 50%)

Medium Panel - 25% system power (currently 30%)

Portable Panel - 15% system power (currently 20%)

Or maybe medium and portable could go to as low as 20% and 10% respectively so that they can complement each other better with no 5% overheads that would just get lost anyway. And yes, I realize that this way you couldn't run a system on portables alone, but to be honest, I don't think you should be able to. Those are rather small ones, I don't see a way for even 5 of them combined to power systems that supply an entire habitat.

Heart rate...! Could there anything more straightforward than that? I really like this solution. The 60-ish base rate may be a bit low tho. I'd say an EVA, even for an otherwise trained and experienced astronaut, is a somewhat stressful situation so heart rate would be slightly elevated even when at rest, plus, she's carrying the weight of the EVA suit (and whatever else she has at that time) so not really "at rest" even when not specifically moving.

I also have to mention that that low "huh" sound the player character makes when recovered her stamina and is able to run again is a nice touch. Maybe you could slightly increase its volume to make it a bit more noticeable?

While I understand that some form of tradeoff would be required for gameplay purposes in case of the RTGs, but given what they are and how they work, they are practically incapable of causing radiation exposure even if physically damaged to the point where the heating pellets themselves are exposed. (Barring nonsensical things like carrying the exposed heating pellets in your pocket, and even then, since they are designed to emit very little to none beta, gamma and neutron radiation, the alpha radiation has the least penetration energy easily stopped by "regular" materials, even simply by the human skin.)

Another thing is that RTGs have rather low power output, typically a few hundred watts at most, so a single unit alone would be incapable of powering a complex and large electromechanical system like any of the hab modules by itself (especially the heater, which would have to require power supply on the order of several kilowatts to be able to heat something as big as the habitat). The most they could do is supplement an insufficient amount of solar panels during the day, and slow the deplettion of the reserve batteries during the night.

I can confirm this. Between my previous and current play session, a number of white locations have disappeared from the map but still there physically, others are still marked on the map but not actually there anymore, and yet others have refilled their inventory.

I also had a curious case of an unmarked WayStat showing on the scanner for a while in an area where it couldn't possibly be undiscovered as I've been in that general area several times (being between two Habs) then at some point just disappearing from the scanner while I was moving towards its general direction.

Additionally, some of the locations that are still there but disappeard from the map are not saving their discovered state, always resetting to undiscovered between play sessions (after having saved by sleeping, of course).

I have a hunch that it may have something to do with game updates, which somehow may break the existing saves. I started this save with v0.55, and the update to 0.56 did not cause issues (actually, I'm not even entirely sure about that as there are parts of the map that I explored in the early days of this playthrough and had no reason to go there since then, so I may not have noticed any possible change in those old locations since then). Then, when loaded the save that was made by v0.56 into v0.56.1, I noticed these issues (the locations detailed in the attached save were discovered during the last play session, so they got bugged between then and now, with the only thing changed being the v0.56.1 update).

lp_save_disappearing_sites.zip - See included notes for instructions on finding some of the bugged locations. Some are also tagged with ingame photos for easier navigation.

While walking 1500-2000 meters in "real time" between two habs several times does feel somewhat of an empty time sink, being able to magically teleport from one to another (even with consumable use and travel time simulated) would be way too out of place for me here. You would end up just jumping between locations for short bursts of activities without taking an actual step anymore, and the feel of the size of the world you are stranded in would get lost as a result.

I think vehicle travel, once implemented, should be enough to shorten travel time in a way that fits the overall theme of the game better. Even that should come with some limitations, like it would take a lot of time to recharge the vehicle, and it would deplete its power much faster than it takes to recharge, forcing you to occasionally still walk to places as the vehicle is currently in recharge for another Sol or two.

A bit of feedback on this if I may resuse this topic...

Slightly moving up the sensitivity range represented by the 1-10 setting range might be in order as I found that it starts to become convenient around the 7-8 setting. I know it's rather subjective, but the half a meter mouse movement you need to do for a 180 on the low end is unlikely to be preferred by a lot of people, so with the current setting-to-sensitivity mapping, most of the setting range is ineffective. I'd say the current 6 (maybe even 6.5) should be the new 5 or thereabouts.

A way to mark visited/explored areas could be to have a monochrome and a colored version of the map, the monochrome being the default, and where the player has been would get colored. Sort of like as if the suit would be constantly gathering more detailed terrain data around itself by some built in automatic imaging tech and updating the map to a higher resolution/detail version with the results (actually, the monochrome map could also be "degraded" a little to include visible pixelation, and the colored map would be in the original, current resolution).

As for specific implementation, it could be a smooth 300 m radius around the player as they move (probably difficult to implement, and especially save the explored vs. non-explored area), or the map texture could be split into evenly sized rectangular tiles (of a size that somehow correlates to the 300 m scan range of the suit, like 300m x 300m tile size, or maybe only 200x200 to compensate for the circular scan area vs. rectangular map tile), and they would get swapped from the monocrome to the colored tile (and their state saved) once the player entered the corresponding area of the game world.

I managed to figure out when does it happen. For testing, I had one of those "3 solar panel" locations to interact with, but it also happens when you try to use a "buried" cache location without an excavation tool.

To test with the solar panels location:

1. Fill your inventory to capacity so that you can't pick up anything.
2. Go to the test location.
3. Open the Datapad, navigate to any screen except the Home screen, then put the Datapad away with "E'" while leaving the Datapad on that screen.
4. Left click on the large solar panel, at which point you get a message that you don't have enough space in your inventory.
5. Press "E" to open the Datapad.
6. Note how the selection highlight is missing. Using the arrow keys or Enter produces the navigation/selection sound, but nothing actually happens. You can put the Datapad away with "E" and take it out again with "E", the condition persists.
7. When the Datapad is open, hit Esc to dismiss it. You can already see how it jumps back to the Home screen and the selection highlight appears before the Datapad is lowered.
8. Open the Datapad with "E" again and now it will function correctly.

You can repeat steps #3 to #8 to reproduce the issue by this process as many times as you want. Which screen you set the Datapad to doesn't matter as long as it's not the Home screen, the issue does not occur on that one.

After re-watching your developer video about the health/vitals system, and assuming it still works more or less the way demonstrated there, I think the problem is that there's a fundamental conflict between your concept of what and in what way the health system should tell the player, and what the player unavoidably needs to allow them to utilize their health level as a survival resource.

You wanted to avoid representing health itself as a simple numeric value that just goes up and down, since that's not how it works in real life, and I do agree with that, it's a nice idea, at least in theory. So instead, you created a number of "healthness factors" to manage, which represent your body's ability to maintain (or lose) its "health" over time. This is clearly visible in the video, as you modify the hunger and thirst conditions: a hidden health value starts dropping more and more rapidly over time the worse those conditions get. This is what the 4 displayed vitals categories actually represent, and what I think is the primary source of confusion: they are not "flat" or direct health indicators (like, if you have 3 red lines in hunger, you are missing, say 30% of your max health, and if everything everywhere is red you die; no, you just lose a hidden health value more and more rapidly), they only show the rate at which you gain or lose health. But your actual health itself is not represented in any way, only these "health changer" factors are, which do not and can not tell you anything about how long can you last with the current health loss rate.

It's like flying an airplane with only a variometer but no altimeter: you know how fast you climb or descend, but you have no idea about how far the ground is so you don't know when you have to stop your descent not to crash. And while it would be easy to say "just never allow negaive RoC and you'll be fine", that's just not possible.

The problem is that from a gameplay perspective, the player has to be able to have at least a rough idea about how long it will take for the character to die due to the effect of the "health changer" factors, to be able to make decisions like "can I keep going towards that sensor ping, or I have to turn back now as my health won't last long enough". And I don't see any way to avoid some kind of "flat" health indication to be able to make such decisions as the health change rate alone can't give you a "time left to live" when you don't know the value the rate is applied to, and currently you don't.

That's why I think what I wrote previously is what the vitals system could (should?) be reworked into. You have the 3 "tiered" health changers: hunger, thirst and exhaustion (weighted, so that hunger gives the highest delta per tick, thirst gives a moderate one and exhaustion gives the lowest, set in such way that it's not possible to compensate hunger and thirst both being in the red by just sleeping). You have 2 "direct" health changers: accumulated radiation and body temperature, low temperature acting much more aggressively than any other factor. The positive cap of the tiered modifiers (all green) should be somewhat lower than the negative cap (all red) so that it takes longer to regain health than it takes to lose it, ad no health gain from no radiation nor acceptable temperature, those can only degrade health or not, but not improve it. And then you have "<quality> Organ Integrity" which is the representation of that previously hidden health value which all the above modifiers decrease or increase over time. The modifiers show you in which direction your health changes over time and allow you to influence/manage this change. Organ Integrity shows you clearly how far away you are from fatal organ failure, which means death right there and then (currently it means "nothing", except being another rate changer, as at some point in the video it drops to its lowest value, yet the player character does not die), but you cannot directly modify it by flat values (but there could be a medical/medicine mechanism, which slightly boosts the recovery rate on top of what you get by keeping the modifiers in the green). When the modifiers are already red but integrity is still "greenish", you can risk keep going. When the modifiers are red and integrity also starts turning red, you must improve the modifiers or you will die soon. This would also give a long term time delayed effect to overstressing your body: go with red modifiers for too long to have integrity to drop to orange and for the next few days you won't be able to go as far as you did before, since integrity now starts dropping from much a lower value than before unless you allow yourself to recover first.

The screen itself should also get reorganized a bit to communicate this. Organ Integrity should have its own line either at the top or bottom, as if saying "organ integrity is influenced by the below factors" or "organ integrity is the result of the above factors" (you could further emphasize this by making a boundig box with organ integrity as the "title" of it, which box then contains the 4 modifier group boxes), and the 4 groups could remain and work the way they are (with their boxes slightly made smaller to make room for the organ integrity line, and Exposure missing Organ Intergrity due to having it repurposed).

(I hope you don't mind the wall of text, I'm just trying to find a middle ground between what you have in mind for health management, which I think is a great idea in general, and what I think would be needed to better support gameplay considerations at the same time.)

Discovered WayStats, being what they are, should be selectable as waypoints the same way habitats are. And then, piggybacking on this functionality, the selected WayStat could display its slot states (let's say, basic telemetry of the selected beacon is encoded into its signal for remote monitoring) on a small overlay next to its icon on the map.