Your comments

From some testing Ive done, the difference is nowhere near drastic. I got apporximately 1.2% power drain per hour without a panel equipped and 1% / hour with it with. While technically it's a 20% improvement, effectively it's meaningless.

This actually seems to be some general issue with how the timescale is applied when "skipping" time, since resting does the same, eg. setting 1 hour rest time will result in 4 hours passing, but 1 hour worth of calories are used (as far as I could tell).


I suspect it also affects hab system resource production and electricity use while in "time skip" mode, and the rate at which the hab loses temperature when the heater is off, everything being much lower than it should be. I guess that for these purposes the set time is used, but the game time is skipped forward 4 times as much, that's why the effect of passing time appears to be less (eg. 1 hour worth of change is applied over 4 hours).

I wonder if there would be a way to add something (some kind of a "driving safety system") which would somehow prevent it from climbing anything so steep that there's a risk of flipping? I'd say something like that would make sense both in terms of a safety system for a vehicle lke this, and also to deal with the issue that it currently has very unrealistic terrain climbing capabilities.


Not sure how to implement it tho, the part where its pitch/roll angle would be calculated and checked against a safe/allowed threshold is the straightforward part, but what should happen when it's exceeded? How would movement become restricted in such way that it can't be driven further up the slope, only back down from it?

Just out of curiosity, if you have a spare minute to answer: how does the rover end up on the interior hab map to begin with? I'd expect the hab interiors being essentially completely separate, stand alone maps where the player is "transported to" upon entering, with no connection to the exterior "world map", where the rover is located / saved at. Does it happen because of something like the rover position somehow getting incorrectly transferred from the world map to the hab interior map when it's loaded, and since it's position is invalid in that world space, it is placed at some kind of origo?

Suit power is not being drained while driving the PRT for heating nor for the suit lights (which get turned on/off along with the PRT light, by the way). This might be intentional as the suit might be connectd to the PRT's power system while driving, which would actually make sense, in which case it could be mentioned somewhere. Is there (or will there be) a manual in the datapad about the PRT?

During sector transition (while the "...LOADING..." text is up) the motor humming noise stops playing until the loading finished, but other noises, such as the suspension "bumping up" on rough terrain are still audible.

Some good and some bad news regarding the colliders in 0.62.1.


The good news is that the sliding issue appears to have stopped, I kept poking the PRT and walking around it and jumping onto it for a good 5 minutes several times and the colliders stayed where they should be.


However, it feels to me as if there is actually a set of several colliders linked together to make up the volume of the PRT, and they can and do reposition themselves into slightly different configurations depending on the pitch and roll of the PRT as it follows the local terrain slope. And some of these small changes appear to be causing gaps or excess surfaces between these individual elements in which the player can get permanently stuck.


In the save I linked earlier, there are a number of differences between the left and right side of the PRT:

  • The wheels on the right side have this "stickyness" which causes the player to slide on top of them when walking into the wheels from most directions (eg. directly from the side, parallel to the wheel hub). From some angles it can happen even if you just walk past the wheel, not explicitly towards it; you may get drawn on top of it even perpendicular to your actual movement. This is not present for the left side wheels.
  • Again on the right side, there's an invisible ledge along the side of the PRT, slightly above the height of the top of the wheels, as if there was a bridge between the two wheels. You can climb onto one of the wheels, then jump towards the other wheel and slightly towards the center of the PRT to get onto this invisible ledge, then you can walk along it in the air between the two wheels. This, again, is not present on the left side.
  • If you walk right up to the wheels on the left side then try to jump onto any of them, from between them facing backwards (aft wheel) or forward (front wheel), you'll get stuck and you can hear the step/jump nosie keep repeating endlessly ("taptaptap-tap-taptaptap...") and you have to quit and reload the save. If you don't get stuck right then and actually get onto the wheel, try jumping again, you will almost certainly get stuck this time. You can still jump, but not move.
  • And the interesting part. Get into the PRT, turn it around and park it to the same place it was before, only looking the other direction, and this will cause all the above to reverse (as the PRT will now lean in the other direction than before, causing the individual colliders to shift to the other side, I guess). The left wheels will be "sticky", the invisible ledge will have moved to the left side, and you get stuck if trying to jump onto the right wheels.

An additional, smaller issue is that if you crouch and crawl under the PRT, you can stand up and clip into the model, then walk through and out of it towards the front or the back.

Yes, I think it would be a reasonable tradeoff. I'm not even sure about reducing the oxygen use when inside; it does make sense in terms of less activity meaning less oxygen used, but I don't think the oxygen budget is that tight in general that an occasional 10% loss would seriously upset it and needing to be given back in another way. That wouldn't really be added usage, just converting an over time use into a single one time use.


Actually, putting more stress on it would probably work towards making exploration feel more risky again, so maybe even the deployment cost could be a little higher, 15%, or even 20%, since, as you've also mentioned, it would, in a way, include the air that needs to be used to refill the tent every time the player leaves and reenters.

A whole canister felt to be a bit too much even to me, actually, so draining a smaller amount from the suit suit supply indeed sounds better. This, however, will require an extra check somewhere in the deployment process to ensure that the player won't run out of suit oxygen immediately during deployment or during the next few in game minutes of being inside. Can't deploy if suit oxygen is below 20-25% or something?

I have also encountered oddities with the airlock doors on rare occasions, but just as you said, when I tried to find a way to reliably reproduce or trigger the unexpected behaviour, it felt like needing an extremely specific timing and character movement to cause them to happen, so much so that it could be considered more of a "quirk" than an actual issue. None of what I've encountered was game breaking, just a bit of a "What was that?!" kind of annoyance.


What I've observed so far in various game versions with the outer door of the external airlock:

  • The door closing while you are in the doorway and either pushing you back, pushing you upwards (sometimes ending up on top of the floodlight above the entrance), or launching you backwards in the air.
  • The door closing while you are in the doorway, causing the player to clip into the door model and get stuck, but I think the door reopened a moment later in these cases so you could get out.
  • The door opening for a moment when you approach but immediately closing again right before you could actually go through (potentially resulting in the first group of issues). With this one, I could half-identify a trigger point where the stairs leading up to the entrance connect to the hab model itself: if I managed to stop just at the right spot somewhere near that connection point, it caused the door to start closing as if there was an extremely narrow gap in the detection volume which controls the door. However, I could get this happen very rarely even when I explicity tried for quite some time, and I'm not sure if it was specific to one habitat or to all of them.