+1
Fixed

PRT first impressions / issues

Mr. Fusion 6 years ago updated by Tyler Owen (Lead Developer) 6 years ago 12

Finally found a PRT (of course it was at the last spot of the map where I looked for it :), so I could do a little test drive... after I managed to get it come down from the 10-15 meter height where it was floating in the air.


I found it next to the North-East Hab which ended to be my Gamma. When I initially approached the habitat, the PRT was on the ground, but after I entered the Hab to rest, then exited again, I found it floating in the air above the spot it was originally at. Reentering and exiting the Hab again did not change this, but exiting to the main menu and continuing the save placed it back to the ground.


Driving it feels a bit odd as the speed control seems to be half way between a car and a train: forward/backward acts as if it was setting a tempomat or something, but not entirely. Under certain circumstances it will lose speed over time, holding forward down for a longer period causes it to accelerate to a max speed, but when releasing it, it only slows down to about half speed then maintains that, more or less. Some kind of visualization for this throttle setting mechanism would probably make it easier to have a sense for and control this set speed + overdrive control scheme.


Its terrain climbing capabilities should be limited somehow, as I could drive it up on hillsides which looked to be much steeper than what any wheeled wehicle could climb, especially something that looks to have such a high center of mass as the PRT, without sliding back/toppling over.


The default "Exit" control for the PRT is "Q", which is also the default for the scanner in walk mode, which results in the scanner turning on every time you exit the PRT unless/until you change it.


Exiting the PRT with its lights turned on results in the suit lights also being turned on. It's not necessarily a bad thing, but this automation, if we consider this a feature, isn't really consistent. The player character doesn't automatically turn the suit light on when it's dark, so why would she do it when exiting the PRT?


While these are probably planned features, but being able to look around (within at least a limited field of view) while driving is pretty much a standard feature in similar elements of other games, and not being able to use the datapad makes any kind of navigation impossible, and it's also needed for managing suit supplies, checking vitals etc. when driving, just as much as when walking.

The "levitating PRT" issue appears to occur only as long as the PRT is still at its original location. If it is, every time you enter the habitat it is next to, rest for any non-zero amount of time then exit the habitat, it will be high in the air above the spot it was on the ground before.


Once you have moved it off of its initial spot, this seems to be no longer happening.

Another issue related to resting: the bounding boxes/colliders seem to dissociate from the visible model after having rested, making it possible to partially walk into the model at certain parts, and hitting the invisible, offset colliders some distance away in the other direction. Getting into the PRT and moving it a bit reunites the colliders with the visible model.


The distance and direction of the colliders becoming offset may have something to do with how the terrain is slanted at the spot where the PRT is; is feels as if the colliders were somehow "sliding out" of the visible model in the direction where the terrain slopes downward.

Actually, it doesn't even need resting. The colliders are slowly, constantly moving out of the visible model in the direction of the downwards slope of the local terrain. Walking around and bumping into the model/collider from various directions may accelerate this process, but even without that, in a few realtime minutes a distinct offset can be observed between the visible model and the colliders.

Under review

I'm having trouble recreating the collision offset issue, but I believe I've solved the floating rovers bug. I'll try to get a hotfix out soon.

And you were correct that I'm planning to allow operation of the datapad while driving, but I ran into problems with that and didn't want to delay a new update any longer. I worked on it some more today though and I might even get it pinned down enough to put out with the hotfix.

I have a suspicion about the collider offset issue possibly being caused by parts of the graphical and physics processing running on different threads/CPU cores, and getting desynced when the game as a whole experiences transient performance issues. At least I seem to recall that newer versions of Unity introduced a higher level of thread separation between physics processing and everything else.


As I mentioned some months back, for some reason I get uncharacteristically poor performance around the North-East habitat location where I happened to find the PRT; the game stutters a lot and there are recurring, long periods of heavy drive activity. Maybe parts of the processing gets properly paused/suspended while waiting for these I/O operations to finish, while other parts/threads, related to managing the colliders, still run on a different core without being also paused, so they "get ahead" of / desync from the rest that got properly paused.


I made a save snapshot of the situation where I observed this: prt_collider_offset_save.zip


The PRT is parked just a little to the right and back from the Hab entrance as you exit, on a slight slope towards the habitat. All I need to do is exit the habitat and walk around for a few real time minutes, bump into the PRT a few times, try to climb on top of it, etc. After a short while it becomes possible for me to clip into the visible model from the side away from the habitat, and the collider itself will be well offset towards the habitat.

Fixed

Well, I was never able to recreate the collider desync issue, but like you said it may be related to performance in some way. My computer isn't like a super rig or anything, but it doesn't struggle at all to hit 60 fps anywhere in the game. Anyways, I did make a small change to the physics scripting for the stationary rovers that should keep them locked in place while not in use. But you will have to confirm for me after the update goes live later tonight/early tomorrow. I'm going to mark this Fixed since floating rovers issue should be solved, but if the collider issue persists I will reopen it.

The other good news is that I did manage to add support for viewing the datapad while driving and in the process I fixed another minor camera jitter issue in the process. This will be in the update as well.


I think I will probably keep the headlamps/headlights linked between walking and driving because it feels more natural to me. The player did make the choice to enable or disable headlamps at some point either while walking or driving. It makes sense to me that if you needed them on for one then you would want them on for the other. Even though the lights are narratively two different sources, as far as the code is concerned they are the same source with a different mask shape. This is partly why there is no way to have the PRT headlights on while you are not in it. Enabling that would add extra lights sources to the scene and decrease performance.

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.

This is actually a problem, at the same base, that I had. Same situation, found rover but it was after deciding to accidentally leave auto walk on as I took a leak. I rushed to turn the base on and get inside, eat etc. Made sure everything was ready for my move to that base, then went outside. Broken PRT, got stuck underneath a wheel because magic. PRT also had no collision.

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.

This is a result of how the sound effects are handled. A good number of sound effects are not able to be paused right now. That may change in time. 

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?

This was not intentional. I'll see about improving the in-game documentation about the PRT, but the survival stats issue while driving should be fixed for the upcoming patch.