This is a very elusive problem. Almost every time you post a bug I can eventually find the error somewhere in the code, but I've been looking over it and running test scenarios all morning and I can't figure it out. I'm pretty sure that I have run into this in the past, although at the time I didn't think much of it. Someone here on the forums shared a save file related to a different issue and when I ran it I walked outside the hab right after loading. There was a PRT right there outside the door and the discovery notification appeared. I thought it was odd, since you would think that if the PRT was right outside the door that the player would have discovered it previously. I'm guessing that this was an instance of the bug you've described. But I just ran two different test cases where I discovered both rovers without any issues. Both were tracked in navigation and both stayed in the "discovered" state between saves and loads. If you run across a save where you experience this again please send it my way. Thanks.

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.

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.

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.

Much appreciated. Got it pinpointed and fixed for the next update. 

Is it possible for you to redownload the save file you attached to this post and check if you still get the bug if you follow your own steps? If not that's fine. I do plan to restart the game several times to double check on my own.

This may be related to an issue that has now been fixed. Hopefully we won't see it again after the next update.

Is there a new save file you could provide that would demonstrate this issue? The original save file you posted no longer exhibits the behavior you described so I must have fixed that specific instance the issue. If it's still happening then it must be a similar but unrelated issue I need to address.

You made a larger suggestion post on this topic so I'm going to mark this one as "not a bug" until I have time to address your suggestions.

Ok, I think I got it this time. There's a few too many possibilities for me to test right now, but it's a fairly minor bug so I'm going to move on to some other fixes. This should be fixed in the next update.