I wanted to turn a player’s character into a ragdoll when they leave the game. So naturally, I tried to just tinker with the character in Players.PlayerRemoving but oh no - by the time that signal runs, the character has already been destroyed. I eventually solved this problem in a more hacky way, but I think making it possible to do it this way would be way nicer.
I’m proposing a new bool property, Players.KeepCharacterWhenPlayerLeaves. When set to true, characters of leaving players will NOT be destroyed, or even touched at all in any way.
This will be incredibly useful for the thousands of games that currently need to create fake/dummy characters when the player leaves, for all intents and purposes.
2 options 1 create after model then player die(if multiple peoples die can be laggy) 2 if player died then you can pickup items but if they leave body disappear and they disappear then respawn time is end
This in itself doesn’t disable character deletion, it just parents the character to nil when being removed instead of calling a full Destroy on the model.
This works. I tinkered around with it and ended up with this:
local clones = {}
game.Players.PlayerAdded:Connect(function(plr)
plr.CharacterAdded:Connect(function()
if clones[plr] then
clones[plr]:Destroy()
clones[plr] = nil
end
end)
plr.CharacterRemoving:Connect(function(char)
char.Archivable = true
clones[plr] = char:Clone()
end)
end)
game.Players.PlayerRemoving:Connect(function(plr)
local clone = clones[plr]
-- Do what we want to do!
end)
The only difference between this approach and the feature request would be it getting cloned, but it might not matter for my particular use case. It also works with deferred signal behavior!
Just clone the character whenever it’s added to the workspace and then parent it when they die/leave.
This feature is a thing for a very good reason; it used to be the case that event connections created on players and characters wouldn’t be disconnected automatically as the Destroy function wouldn’t be called internally on these objects when removed from the game, which would lead to huge memory leaks if developers weren’t careful.
Please don’t set deferred signal behavior to immediate or player destruction behavior to disabled. Both of these are three phased rollouts that are explicitly intended to be forced away from what you are setting them to.
This feels a significantly niche footgun, so I don’t expect it to be added. I recommend something like this instead:
local savedCharacters = {}
Players.PlayerAdded:Connect(function(player)
player.CharacterAdded:Connect(function(character)
local existingCharacter = savedCharacters[player]
if existingCharacter ~= nil then
existingCharacter:Destroy()
end
character.Archivable = true
savedCharacters[character] = character:Clone()
end)
end)
Players.PlayerRemoving:Connect(function(player)
local savedCharacter = savedCharacters[player]
savedCharacters[player] = nil
-- Do stuff with savedCharacter
end)
The same code works with .CharacterRemoving, so that’s nice! .CharacterRemoving is more useful in my case since I want the limb positions to be up to date. On a side note, using features that are being phased out is a way of pushing back against unwelcome changes, I’m aware of them not receiving support.
Defferred nor PlayerCharacterDestroyBehavior are unwelcome, deffered stops people from relying on execution order in their code, while PlayerCharacterDestroyBehavior fixes a long standing memory leak that existed if you didnt destroy player instances after that player leaves, and if you didnt destroy character instances in character removing as they’d otherwise just persist in memory forever.
For you - perhaps, but I personally dislike deferred signals. They are unwelcome in my eyes, I’m not speaking for others; I apologize if it came off that way.
)