Is it possible for there to be two Player Instances in the Players service that belong to the same player, when they rejoin that same server? Or is their rejoin guaranteed to be delayed until any (possibly yielding) PlayerRemoving listeners for them have completed?
If there can be two Players, is there a way to detect if a Player Instance has left the game before it has been destroyed or reparented? Or, is there any guarantee for game.Players:GetPlayerByUserId() to return the newly rejoined Player and not the old leaving one?
Will PlayerAdded listeners at least not be called until the old Player Instance leaves?
If you listen for the Players.PlayerRemoving event it will provide the Player instance that is guaranteed to be the one that is exiting the game. Likewise from the Players.PlayerAdded event you can get the Player instance that just entered.
In case you are worried about potential issues caused by players rapidly leaving and returning, Players has additional events such as PlayerRejoining you could look into.
No, you will not have to handle this. The player instance gets removed and re-added when the player joins/leaves the game. From my current knowledge, you should be safe from a duplicate player instance.
Sorry about that, didn’t realize it. But honestly I wouldn’t worry about this if you are accessing players through PlayerAdded and PlayerRemoving. I’ve never had problems or seen anyone have problems with duplicate player instances.
Just to confirm, are you saying that there is a guarantee that the removal will occur before the player is added? So that even if a PlayerRemoving listener takes 300 seconds, it will delay a PlayerAdded being fired on the new player?
The problem is that if this were to occur, you’d likely only see player data loss as an occasional result (creation of player data from template and then removal routine saves data), and otherwise be completely unaware that this were a problem.
A player can’t join two games at once. Even if you click “Play” again without exiting, the client you are in will be forced to close and start up again. So PlayerRemoving should always fire before the same player is added. If you’re worried about asynchronous DataStore calls perhaps you could have the game wait a few seconds after the player joins before loading all of their data, allowing time for any previous data to be saved when the Removing event occurs?
I know that PlayerRemoving will fire. My question is whether or not there can be a new Instance of the player from a rejoin into the same server before the player removal routine is completed.
Waiting seconds is an unreliable hack, I know how to solve this problem if it exists (simply add newly joined players to a queue if they already have player data, and have player removal routine check if they are in queue at the end), but this is a bunch of boilerplate I’d like to remove if possible.