I don't know if this was worked on and partially addressed, but the behaviour slightly changed so that the resolution now seems to be reset only when entering / leaving a habitat after having used Alt-Tab, and not immediately and every time when switching back to the game from the desktop.

Now I had this happen with a fuse, a storage tank and a carbon filter, all of which were in initially broken slots of a hab I discovered just then.

I wonder if it may happen only for system slots which were initialized / created as broken with a (should be failed) component in them, but not when slots / components break later due to over time degradation?

This still seems to behave oddly in 0.63.2. Since I'm not sure which parts are intended, I describe the whole situation I observed.

I found Hab Beta, did some repairs and started up all systems, then checked status. Temp was below zero, reoxy reported water deprived, water reclaimer showed [100%] with no liters value. I switched off the reclaimer, removed then replaced the tanks, but did not turn it back on. At this point, the hab status screen showed [0%] 0.0L. Then I turned the reclaimer back on, and it's status went back to [100%] (no liters value) again. Hab temp was still likely below zero at this time, I did not wait to see what happens when it goes above zero.

I've now checked the memory use both at quality preset 5 and 6, and it was still capped at 1.2 GB in both cases with the same level of storage activity and OS level choking when exiting the habitat, still with at least 1 GB reported by the OS as being available.

I suspect the cap is being set based on either total system memory (4 GB in my case) or video card memory (1 GB in my case), but I have no idea why. I'm certain the game used to be able to use pretty much all available memory in the past, which resulted in much smoother performance.

PC, Win7 64 bit, and Steam launches the 64 bit version as expected.

I have a suspicion which I didn't have time to test yet. Is it possible that the game (incorrectly) limits its requested working set based on the quality setting in options (it appears to control texture quality, amongst other things, and that's one of the biggest impact factor on memory use in general)? I used to have it at 5 for a very long time, but since I switched to a larger resolution monitor a few months ago, I had to drop it back to 4, being somewhat GPU capped, not to have a lower than pleasant framerate.

And if I think about it, that's kind of when I started to notice a lot more storage access than before, to the point where the game often feels near unplayable since it very frequently and repeatedly freezes for several seconds, or stutters for minutes with constant storage activity, while there's still plenty of available memory left it could use, but it does not.

Storms do severely impact power generation. You can, and need to, actively manage power during a storm to keep even just a single system running for any meaningful amount of time. Depending on the speed and direction of the storm, the Weather app usually can be used to get an advance warning of a day or two, and start preparing by limiting your power use to ensure you'll have 100% charge (and possibly charged backup batteries) when power generation gets all but killed off by the storm.

Power cells already exist, there are rechargeable backup batteries which can be used to rechage the suit, the rover and (indirectly) the habitats.

Oxygen canisters already exist which can be filled when you have excess oxygen and used to refill the suit and (indirectly) the habitats.

The wind power generator isn't necessarily a bad idea but it would just negate the biggest negative effect of a storm which you have to deal with, so it doesn't add to gameplay, it actually takes away from it.

I kind of like the solar panel and oxygen generator idea to the rover, but not the rest. The rover is an extremely powerful range extender as it is, I'd say making it even more independent would, again, hurt the gameplay more than it would help it. Even the ability to recharge it on the go and use it as an oxygen source feels too much so likely shouldn't be implemented.

I like the radiation storm having the potential to shut down all hab systems, needing a manual restart.

Some more complex and involving, maybe minigame based, approach to system maintenance, and more things to diagnose/fix also sounds interesting. Implementation could be tricky, tho, requiring coming up with some interesting game mechanisms to begin with, coding them, and then all the UI work and possibly asset creation to visualize all of it.

I actually like the rover sounds very much the way they are now. I somewhat agree with that they are a bit louder and "clearer" than what might feel right, but otherwise I think it provides a great "feel" for travelling with a vehile.

One thing that's difficult to grasp regarding the atmosphere of Mars is that it's not simply thinner, but extremely thin (about 2% of that of Earth iirc), down to hardly existing at all in terms of being able to propagate sound. So about the only sound you'd hear in any situation is what can travel as vibration from the source being in direct physical contact with the EVA suit into the pressurized interior of the suit.

In this specific case it'd be mostly the vibration of the mechanical parts of the rover, dampened by all the joints and materials it has to go through to reach the EVA suit. It could include some rolling noise from the wheels, but likely nowhere near as much as we'd expect to hear based on what we hear in this situation here on Earth.

One thing that could actually be an interesting and reasonable change is modulating the frequency / intensty of the motor noise between acceleration and coasting, but I'm not quite sure if that isn't already a thing actually as I didn't drive around in it as much yet. And with the terrain being as uneven as it is, I think there'd be hardly any coast phases to begin with most of the time. It's not like you are driving around on a perfectly flat highway where you only need to compensate drag forces once the vehicle's mass has been accelerated and its momentum carries it along.

Another way to decrease the length of loading periods would be to reduce the amount of data needed to be loaded in one resouce load session by reducing the size of terrain they represent; instead of loading a large section of the map and all model and texture data associated with it less frequently, smaller chunks loaded more frequently migh give shorter individual loading times, possibly down to the point of not being noticeable at all.

The primary problem or drawback of this might be related to view distance; if the terrain data is split up to chunks so small that the next one being loaded is within view distance, it'll cause "terrain pop in" of various degree. Another Unity game with a huge explorable terrain I'm playing these days has this very issue: there you don't have dedicated "loading freezes" like here as the game world is split into very small tiles with at least 2 LOD levels each, so moving around in the game world is seamless, at the price of the tiles being visibly loaded / swapped from the low quality version with no detailing to the high quality version with all the small details (and sometimes even lagging behind so that there are "voids" where the low quality terrain is not loaded at all for a few seconds while the game tries to catch up with the movement of the player, even on an SSD) since they are well within view distance when the loading / swapping happens.

However, the terrain in Lacuna Passage is a lot less detailed than in that game (simply because what that terrain is, not having to deal with a lot of very complex terrain features, animated vegetation, etc.), so maybe with a similar approach the smaller amounts of data for the smaller tiles could load so fast that would be near unnoticeable.

I suppose changing the streaming of terrain data like this would require a huge amount of terrain / texture re-authoring, and likely coding, so it's another question if it would be feasible at all in terms of added development time.

I dug up some of my old notes, and as it appears, without any actual calculations, I ended up with a similar ratio of power requirements for the systems just based on what "feels" right for their functions and likely technical implementation.

I may have also suggested back when the major power rework was made that a less uniform power requirement could add another layer to power management in shortage situations. 15/10/10/5 for a simple "offset" ratio with a total of 40, but even 20/5/10/5 would work and that would be really close to the technical estimates presented above.

I had a suspicion that it might be intentional, but it also sounded very much like those odd audio artifacts that render engines may produce at times due to some weird frame / memory access timing, and which are really annoying to hear for a longer period of time.