- All Feedback
-
Bugs/Crashes
Floating PRT, take 2
The PRT appears to be still prone to not settling properly to the ground under certain circumstances, and it migth be either the result or the cause of a massive transient performance issue.
When I left a "cell" with a PRT in it on foot, then returned to that cell later, the PRT was in the air with the wheels being at about eye height, but overall aligned to the slope of the terrain under it. The odd thing is that it did not not occur on the initial discovery of the PRT(s), at that time it was properly on the ground. It also doesn't occur after a transition to hab interior then back out when the PRT is in the same cell (ok, not sure about if it's true for the entire cell, but it doesn't happen with the PRT right next to the hab I'm exiting from).
The other issue is that when entering (on foot, at this time I'm not sure if it happens when driving a PRT too, when you have two of them available) into a cell which has a PRT in it that's already been discovered (but not necessarily moved / used), the game goes through a really bad stall. First I get the usual short cell load period, which causes a slight stutter, then massive HDD usage starts, the game locks up, the system cursor appears over it, then the game minimizes itself and cannot be brought back up by clicking on its taskbar icon. During this time, there's constant HDD activity, but the memory/CPU use of the game process does not change from what it normally is. Then after about a minute the HDD activity suddenly stops and the game pops back up on its own with the pause menu open, and from there it runs with the expected performance again.
A factor in all this might be that in this game I have two PRTs, however, they are in different cells, so not loaded together.
Brief description of what happened and when:
- Initial discovery of first PRT at a random location, no issues with cell load, PRT was on the ground.
- Moving the PRT to home base, entering/exiting the hab multiple times but not leaving the cell, no issues (other than the loading indicator being stuck as reported in another topic).
- Driving the PRT to another cell with the third hab and a second PRT in it, which is the initial discovery of both, no issues with cell load, second PRT was on the ground.
- Driving first PRT back to home base (second stays where it was, never having been entered), entering/exiting the hab multiple times but not leaving the cell, no issues.
- Exploration on foot to a third cell with no PRT in it (first PRT is at home base, second PRT is in the cel it was discovered), no issues.
- Returning from third cell to the one where the home base and the first PRT is, game stall on cell load, PRT is in the air once reached.
- Exploration on foot to the same third cell as before with no PRT in it (first PRT is at home base, second PRT is in the cel it was discovered), no issues. Continuing from that cell to the one where the second PRT is, game stall on loading the cell which has the second PRT, second PRT is in the air once reached.
Customer support service by UserEcho
Are you only experiencing these performance issues in playthroughs with 2 confirmed PRTs spawned? Since only one of the two rovers seems to be floating I'm wondering if there is an issue with my code that is causing a conflict when there is more than one.
It's not certain if only one PRT would float as I never tested it with leaving both at the same locaion, moving out of the cell on foot then moving back. I know I saved once in a hab with both PRTs parked outside, but in that situation it doesn't happen with a single PRT either; I had to move to a different cell then back to get a floating PRT.
I found a save snapshot that might have been made when I encountered this; I'll have to load it up and see if it indeed is the one with two PRTs and then I can do some tests. However, it was made in 0.64p1, so the version difference might introduce some "false positives" to the testing.
I'm getting performance issues in general, due to the artificial memory limit the game apperars to impose on itself (never using more than exactly 1.2 GBs, no matter what) as I've mentioned elsewhere, but these severe stalls I've only seen in that game and only when I entered a cell with an already discovered PRT in it.
It could be that I'm just completely missing something, but I'm doing nothing to artificially cap the ram usage. I think the 1.2gb "limit" that you are seeing is just the natural maximum ram needed for all the normal assets that are loaded while exploring. I'm running the 64bit exe on my machine (which most players probably also have if they are running a 64bit OS) and I'm getting the same 1.2gb showing in the task manager. Garbage collection is being run regularly so it stays pretty solid at that figure. Once the terrain quadrants around you have finished loading there's almost no other loading happening while playing. The performance issues you are experiencing then are more likely a result of some rogue programming loop where it is trying to resolve the state of something every frame and it is getting stuck in that loop. In this case I'm assuming that the internal flag has been checked to detect when the PRT wheels have settled into position on the terrain, but for some reason the PRT is not dropping at all, so the wheels never collide with the terrain and never settle. As usual, a save file with two discovered PRTs would be very useful, but I'll try to recreate the issue on my own as well. Thanks for the extra details.
I just finished a lengthy test session in 0.64.1 with the save from 0.64p1 I mentioned above and I could not recreate the issue in about ten test passes under various circumstances. The PRTs in 0.64.1 appear to be settling on the ground properly every time (save for one odd incident not related to the original report: at one time after I got out of one I heard several "thud" noises behind me and when I turned aroubnd I found the PRT to be doing a hand stand, so to speak, It was hanging in the air almost vertically and tilted to the right, with only the right front wheel touching the ground), regardless if there's one or two at the given location. I think loading into a cell with one or more PRTs still causes a lot of extra loading and freezes, but nothing on the magnitude I reported above.
So whatever was causing it previously either was some transient thing (I did several tests back then and the behaviour was consistent within one game session), or some change between 0.64p1 and 0.64.1 made it go away.
Ok. Yeah, I haven't been able to recreate this either so I'm going to mark it as resolved for now and we can just keep an eye out for it in the future. I think it might have been resolved when I fixed the issue causing the loading indicator to stay on screen permanently. I know that was tied to the PRTs. I think I know what might cause the physics freak out that you described, but it's a difficult problem to fix. Physics and collisions are hard to test for reliably. Feel free to start another topic for that issue if you want, but right now I'm pushing through some feature additions before the end of the month.
Apparently another player has encountered the floating PRT issue again in 0.64.2, so there must be some yet to be identified cause that makes it happen intermittently.
https://lacunapassage.userecho.com/communities/1/topics/479-another-year-and-some-really-great-improvements-have-been-made
Damn. Was really hoping it was fixed. I'll get to it again.
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:
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.