Currently, removing the Player object from the DataModel will not result in a disconnect. This results in broken/unusable behaviors because complex systems in the Engine/Roblox rely on a Player Instance existing for each player.
To address these concerns, we will be rolling out a change on November 28, 2022 that will disconnect a player if their corresponding Player object is removed from the DataModel (on the Server or Client side).
Please let us know if you have any questions or see any bugs due to this change.
I thought this was the case? It was a sort of “hacky” way to get the player kicked with a “Roblox has shut down the server for maintenance” message. I guess this is probably just solidifying this behaviour and making the destruction of a player instance disconnect the player properly rather than kicking the player after a while due to a service failing to recognise the player?
Will there be any other changes to the way player the player gets destroyed on leaving? Currently when a player leaves, they just get parented to nil and gradually get cleaned up in memory by GC, but that is not the case if there is a strong reference to it.
Yeah, one of our other recent changes gave us better coverage for properly disconnecting, but we’re solidifying the behavior to cover all cases with this change.
Yeah, this is also something we’d like to change. Unfortunately, solutions we come up with could potentially be a breaking change (fixing this could change the behavior of scripts), so we’re still in the process of thinking through what the best solution would be.
I actually liked some of the stuff you could do with this, was useful for developers to hide themselves on the leaderboard so players wouldn’t nag them to death
In most cases this wouldn’t really be a bothersome change… But I have a specific use case where I parent my Player instance to nil on other clients (excluding myself), so I can quietly debug and investigate issues in servers in peace.
Will there be any way for developers to have anonymity in the future? Being able to get rid of the developer icon in the player list should be enough. I’d like to be able to use the Developer Console and avoid having other people intentionally trying to cause issues for me while debugging.
Curious, what code patterns would break from the proposed “destroy Players on leave” change that would not break from this one (disconnect player on removal from datamodel)? I can’t think of anything
Destroying a player instance just for the sake of hiding them from the leaderboard seems rather buggy and hacky than an actual feature. If being able to hide yourself on the leaderboard is something desperately needed, you could look into implementing a custom one considering you could probably find an open sourced custom leaderboard if you look hard enough or you could also just make a feature request if it bothers you that much🙂
It’s definitely an unintended feature, but I don’t want to go through the trouble of programming a custom player-list just for the sole purpose of being able to obscure myself from players.
There’s also not being able to hide yourself from the player-list in the ESC menu anymore due to this change, which makes a custom player-list redundant if people happen to check it.
Please don’t change that! I think it could cause a lot of confusion for things like accessing the Player’s userID to save data to a datastore upon PlayerRemoving, for example.
I think this only changes what happens when you manually call Player:Destroy, it shouldn’t change .PlayerRemoving's behaviour.
The exact issue with unintended behaviour is that it mostly is or results in a bug (or bugs). Maybe you should look for a feature a request (or make one) to get intended behaviour into Roblox to hide developer’s usernames from the leaderboard and Esc menu player list (this would also probably prevent chatting or voicechat, now that I think about it, as the old behaviour would have prevent players from reporting developers).
yay no need to use kick anymore! But, will other players be able to disconnect other players through the client? It seems like a security issue to allow that inside the client?
I’m certain nothing has changed on that end, deleting a player on the client will just result in them being deleted only on that client, but will stay as normal for everybody else.
I think it’s worth bringing up here in this thread as that’s what some people used this behavior for. Outside of it, I can’t really think of any other use case for this.
