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.
There is in fact already a feature request!
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.
So plr:Destroy() or plr.Parent = nil is equivalent to plr:Kick().
Will it display the same text for the client disconnection.
Calling :Remove() or :Destroy() on the player (in dev console) result in various kick messages. That is cool, but will it happen after the update?
Glad it’s on my birthday too!
Please just destroy the Player. When examined in context, it’s wholly nonsensical that Players and their characters are still not being properly cleaned up. :Destroy() has been the standard for destructing instances for roughly a decade now. Very few scripts rely on the Player instance’s connections to persist after the player has disconnected. Many scripts have memory leaks, because their creators assume that these instances will be destroyed.
The decision here should be clear. Roll the update out as a beta to give developers ample time to check over their code, and then push the change. If there are systems on Roblox’s end standing in the way of this, they should gradually be updated in preparation of meeting this goal.
Does player get kicked if the current player model from Workspace is removed?
While good, this change is a bit of a bummer for me, as my favorite game I’ve made relied on exploiting this oversight in a couple of ways to confuse the player and add to its strangeness, with things like completely deleting the CoreGui menus or preventing the game from appearing on your “Last Played” page.
Then again, these behaviors could very well be used maliciously, so props to you I suppose.
This is desperately needed, so I wish you luck in finding a speedy solution! 
Ah okay, yeah this lead way to a lot of critical bugs, good to see it being cleaned up.
Not to devalue the issue, but I think it’s worth noting that these connections only linger if a circular reference is formed with the instance that the signal connection belongs to.
As such, the code pattern you mentioned should only leak if the Player, or some object which strongly references the Player, is accessed from within the function connected to .CharacterAdded.
-- Irreproachable, as far as memory leakage dictates concern
Players.PlayerAdded:Connect(function(Player)
local PlayerName = Player.DisplayName
Player.CharacterAdded:Connect(function(Character)
print(PlayerName.."'s character has spawned!")
end)
end)
-- Causal of memory leak, as closure references Player
Players.PlayerAdded:Connect(function(Player)
Player.CharacterAdded:Connect(function(Character)
print(Player.DisplayName.."'s character has spawned!")
end)
end)
No, and this will not be changing.
You can safely reparent (including to nil) or destroy a character model (it may - however - cause issues with the control scripts). If you destroy a character model, it will not be recreated until LoadCharacter is called.
Add a opt-in mode, just so people dont complain about this lmao
Update is good, but add previous behavior back and make it toggla-able feature
This is a good change. Players should be kicked when their player object is destroyed. Otherwise, their character would be destroyed and they would be stuck watching everybody else. This was a bug, so it was going to be fixed eventually.
I really don’t understand what this is about
It is a change that will Disconnect Player on Removal from DataModel.
But its not really needed nor worth making a toggle