Your comments

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.

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.