"Second" PRT is not marked on the map

Mr. Fusion 2 years ago updated by Tyler Owen (Lead Developer) 2 years ago 7

Should the player end up with two PRTs in a game, only one of them gets marked / tracked on the map even after both have been discovered. I'm not quite sure which of the two, but I think it's whichever was discovered second.

In between (re)loading saves of a game with two PRTs, I think there also was one time when I "rediscovered" one of them, as in, I got the "PRT discovered and added to map" message again, however, I think it was not even actually added.

The logic that tracks the discovery state and map marker of the PRT(s) appears to get a bit confused when there are two of them in a game.

(There also was an odd occurence where the "Inspect PRT" interaction hotspot for one fo the two PRTs parked close to one another could be accessed even from about 10-15 meters distance, while the other was working as it should, but it did not persist through a save and I couldn't recreate it so I have no idea what could have caused it.)


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.

This is a save with 2 PRTs, but only one of them being marked on the map. Both are by the hab the save was made in. The one across the airlock door is marked, then one to the left of it (as you exit) isn't. 2_prts_map_marker_issue_save.zip

This game was originally started in 0.64p1, then loaded into 0.64.1 for testing some PRT related things. I cannot remember if the map markers behaved differently originally in the previous version and only got broken during the transition, but only one being marked appears to be a consistent behaviour now.

Perfect. Thank you. I will take a look at this today.


So it seems that this save file does confirm that one of the two PRTs is being "undiscovered" somehow. But unfortunately, I think that happens at the time of saving. I don't think this save file will help me pinpoint the issue, because I need to now compare the game state prior to saving and after saving. What I will probably need is a save file that has both PRTs discovered that then "undiscovers" one of them after saving again. This will require some planning on our parts. I've already tried it myself, but I've not had any luck getting them to become "undiscovered". If you think of it next time you are playing and you find two PRTs, ensure that they are both discovered and then backup your save file before saving again. Does that make sense? It's possible that the update I'm putting out today has inadvertently fixed the issue already which is why I haven't experienced it yet, but just keep an eye out for it.

Just a wild guess, since I can't know what data, in what format and through what process does the game store and save about the PRTs (and I don't know / can't remember if the markers were ever saved and restrored properly and just got broken somewhere along the line, or they never saved properly to begin with).

Could it be possible that somewhere along the saving process some overlapping data related to the "first" (in the order of discovery) PRT gets lost / overwritten by the data of the second, because somewhere during procesing it you expect(ed) only one PRT to exist and use only one object/variable/dataset/whatever to store the discovery flag and/or the fact that that specific PRT needs to be readded to the map? Or maybe when restoring the map markers from a save, only one PRT position gets added for the same reason, bacuse somewhere you went "there will be only one so I'm not iterating though a dataset, just read and mark one PRT"? As in, you store / process it as "the PRT was discovered" instead of "this PRT was discovered".

If only one marker persists through a save from the beginning (which I don't know if true or not), then something like this could be a prime suspect, some unintended data loss either at writing the gamestate (the data related to one of the PRTs is only partially saved) or restroring it (the data related to one of the PRTs is only partially restored). If they persist through several saves and then one disappears for no apparent reason at some point, then its more like related to something with the discovery system itself (still could be some partially overlapping data, where an event triggered by one of the PRTs affects / corrupts the data stored about the other).

The "extended" interaction hotspot doesn't appear to be linked to having 2 PRTs on location. I just got it twice in a row in 0.64.2p1 with only one PRT present. It affects only the "Inspect PRT" hotspot, but not the storage one.

It was in this state when exited a hab with the PRT next to it (which I did several times before and it did not cause the issue to happen until now), and it persisted between entering the hab and exiting again (which it did not on the previous occasion). However, it didn't persist through a save and I still don't know what could have caused it. However, it seems to be not that rare (it happened 3 times in 2 game sessions with PRTs present) so maybe you could try to play around a bit with PRTs (drive around a bit, exit, enter a hab, exit a hab, walk away a bit, walk back, walk to the next cell and back etc. and check the PRT in between these actions) to see if it triggers in a reasonable amount of time.

You probably do play the game more than I "play" it, but I do enter and check PRTs regularly and I have never experienced this bug yet. It has to be something related to the physics of the PRTs settling on the ground after dropping from their spawn positions. Somehow the trigger volumes are getting locked in place while the model itself continues to move. I'll have to try and figure out a fix without actually being able to test for it. It might be difficult.