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:
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.
Customer support service by UserEcho