Since this still continues to bug me, as the game hovers just on the border of playability for a considerable part of a play session (near constant drive use for extended periods, 2-3 seconds freezes every few seconds, complete lock ups for anwyhere between 10-30 seconds), I monitored it's memory / page file related performance and compared it to other games of moderate / high resource utilization.

The primary problem I saw (and which is a strong indication that the game is severely memory constrained) is that the game is generating an extreme amount of page faults: about 30-35 million per hour, as opposed to other games with similar memory requirements and use I've monitored in a similar way, which tend to be not higher than between 500,000 - 2 million page faults per hour (and hardly cause any noticeable drive activity and related stuttering / freezing).

Anhother proof is that if I stand still while outside and keep turning around constantly at a steady turn rate, after a turn or two the game starts using the drive constantly and doesn't stop until I stop turning. This indicates that it almost immediately drops graphics related resources once they are not needed (out of view) and thus is forced to reload them again on the next turn, then drop again, then reload again and so on. Effectively, at this point the game will start to run from disk, so to speak.

And while all this goes on, the game never uses more than 1.2 GB physical memory, with another 2 GB left available to it if it wanted to use it, but it does not, instead it relies on high page file utilization and reloading assets from the game files every time they are needed (likely this is what primarily goes on, and the reason why all this is a lot less apparent on a system with a lot of memory, as in, 16-32 GB; there the OS likely ends up having cached most/all game files in memory after a while so the need of actual drive access gets all but eliminated, thus even tho the game technically still rereads those files constantly, they are served from memory instead of actual disk access so the delay all this causes is reduced by at least one magnitude).

The system I run it on is capable of providing a single process with up to 3.2-3.4 GB physical memory (out of a total of 4 GB present) if requested, as another Unity based game demonstrates this, which has a very high memory use, but even in spite of it using literally every bit of physical memory availalbe except what needed for the parts of the OS that absolutelly have to stay in memory and cannot be paged out, it hardly ever just so much as noticeably stutters, let alone completely freezes.

There must be some way to configure how Unity should handle system memory and page file, the level of asset caching and persistence etc, because as of now Lacuna Passage is the worst performing game I've struggled with playing in a long time on this system, even amongst a fair number of Unity based games I played. Even most games that had considerably higher minimum system requirements than what my system has tended to run better, especially in terms of memory management and drive access related stuttering as a result of less system memory present than the minimum indicated.

If I brake the vehicle to a complete halt, I don't expect it to suddenly jump back to full speed for no reason, so no, this is not what I'd expect.

To clarify, it's not that the game completely stops running during cell load (which of course would also cause the PRT to appear not moving for the duration, along with everything else), then it continues to run and thus the PRT also starts moving again. When the cell loading starts, the game continues to run and can be interacted, the PRT can be accelerated/decelerated/turned/etc during the load duration (with varying levels of stuttering). Then when loading is completed (which can take up to 20-30 seconds, in part due to the incorrect memory use behaviour) and the load indicator goes away, the speed of the PRT will be changed back to what it was when the loading started, instead of what it had become due to me actively and visibly having changed it during the load period.

So if I start breaking when the loading starts, the PRT will gradually come to a halt the same way it would if I started breaking at any other time outside a loading period, while the loading is in progress. Then it will sit there not moving, since I just stopped it, for the rest of the load period (I could start accelerate it again, or turn or whatever, while the load process continues). Then when the loading finished, the PRT will jump back to the previous speed without me accelerating it, or even an acceleration phase. It's just suddenly moving again.

Maybe it's still worth taking a look, since my second radiation storm in my current playthrough (0.64.2p1) was pretty much the same lenght as the first one, again less than a sol, somewhere around 16-18 hours tops. Unless the range is very narrow to begin with, it feels a bit unlikely to get two of the same very short length one after antoher.

Further oddities regarding the extended Inspect PRT range:

• It's more likely to happen when the front of the PRT is tilted slightly upwards from horizontal, and almost never happens when it is tilted downwards.
• When it's in its "extended" state, physically bumping into the front of the PRT (the rollcage around the driving seat) resets the interaction distance to what it normally should be.

Ah, ok, that does sound like something that should not have happened; the question is what caused it to happen in your particular case, since I don't remember anyone ever having mentioned an issue like this, while I do know that players regularily have slots broken and repaired, so an issue that breaks the entire mechanism so thoroughly should've become pretty apparent by now. But since you managed to grab the save file in this broken state, there's hope the developer can dissect it and figure out what may have gone wrong, so not much point in guessing.

Sadly, crafting is not available if electrical is off, so you can't make a new portable panel. However, I don't think I ever had a game in which there wasn't at least one portable panel installed on a hab system panel mount, so there's a good chance you can pick one up from there. But, random being random, there's always the chance of a worst case scenario no one encountered until now, so nothing is guaranteed.

I don't quite understand the "after removing them" part. A broken component cannot be directly removed (the remove option is greyed out and cannot be selected), only maintenance is available, after which the slot becomes empty and a broken component is placed in the inventory automatically.

Unless there is an issue which causes the slots/components to break in a different manner, one that does not disable the remove option as it should, than when they start out in an already broken state.

As suggestions to try to salvage the game: the loss of Electrical means that you can't keep the other systems operational for the night, but you can still generate water and oxygen during the day (they work as long as their own solar panels provide enough power, only they can't charge the battery without Electical). The bigger issue is suit power, since the only way to recharge it is by transferring from the hab reserves. However, using suit power sparingly (scanner only for quick 360 sweeps, minimizing headlight use during the night or not exploring at all at night), a full charge should last about 3 sols (longer if you keep a portable panel equipped during all daylight hours), during which time it should be possible to find at least equipment caches which may contain a few more batteries, but also likely to find another hab (unless you got really unlucky with the locations).

Actually, the second issue might be related to the messages themselves, and not the PRT. I only had the PRT to interact with when I got a "canister broken" message so I noticed with that that it has blocked the left click interaction, but maybe if I had anything else but the PRT to click on, it would've been the same. So it might be worth checking if those messages cause an issue in general, not only with the PRT.

After using A PRT quite a lot to cover large distances across several cells, and getting in and out quite frequently, I've observed the following oddities which might help figuring out what can cause instabilities:

• While driving a PRT, if you manage to stop just before a cell transition, get out of the PRT and cross the transition threshold on foot while looking back at the PRT, you might see it jump in the air to about 1-1.5 meters height just as the "Loading" marker appears, staying there for several seconds (roughly for the duration of the "Loading" marker), then quickly extending its wheels to the ground then slowly settling back down. It looks quite funny, actually. :)
• When you are driving the PRT across a cell border, getting out of it while the "Loading" marker is visible may result in the PRT getting suspended in the air at about the same height as in the above example, except it never comes back down in this case until you board it again.
• On rare occasions it will become "rigid" when getting out of it, instead of aligning to the terrain and setting the wheel suspensions individually according to the slope and other terrain features as it normally does, it will be level and some of the wheels won't touch the ground (the ones where the ground is lower than for the other wheels) as if it was standing on an invisible plane which is at level with the highest point of the terrain under the PRT.

I did not, however, had the PRT not settling properly under "normal" conditions such as finding it for the first time, entering/exiting the hab it was parked next to (including doing it after continuing a game). I did not yet try to leave the cell on foot then return later to see how that behaves.

Considering the first two, you are probably right about something preventing the settling code to run its course at the times when the PRT stays in the air, and since both those cases happen while the game is busy loading things, it might be related to that, the asset loading thread/function interfering with the PRT handling.

This doesn't appear to be (completely) fixed in 0.64.2p1. There are some behaviour changes but it's mostly inconsistent.

Here's what I observed:

1. Radiation storm started while on EVA during the night, "Radiation Zone" warning appeared as before instead of "Radiation Storm".
2. Entering the radiation zone on the map edge the first time didn't result in any change.
3. Entering the radiation zone a little later a second time caused the warning to change to "Radiation Zone + Storm".
4. Even after leaving the radiation zone the warning remained "Radiation Zone + Storm" through the rest of the night.
5. At sunrise (I'm guessing when the radiation went from the night time low to the day time high value) the warning finally changed to "Radiation Storm".

The research station appears to be working correctly in 0.64.2p1, rock samples are displayed, and are displayed where they should be. I haven't encountered the problem where they all appeared in the Gamma section in 0.64.2 nor in 0.64.2p1.

I haven't started collecting atmospheric samples yet, so can't report on those.