The following code has recently (we estimate since 1 week or so) been broken when ‘PlayerCharacterDestroyBehavior’ is set to true.
Previously the humanoid would still be inserted for the copy, now that is no longer the case. Setting the toggle to false fixes this, but is undesirable because it’ll most likely be phased out eventually.
-- NOTE: This code only works for a single character spawn/reset
game.Players.PlayerAdded:Connect(function(player)
local playerChar = player.Character or player.CharacterAdded:Wait()
player:GetPropertyChangedSignal("Character"):Once(function()
playerChar.Archivable = true -- So ':Clone()' works
local clone = playerChar:Clone()
-- NOTE: This will print 'nil', whereas previous behavior would have the humanoid included in the copy
print(clone:WaitForChild("Humanoid", 1))
end)
end)
The following file provides a minimal reproduction for the bug:
CharacterDestroyBehaviorBug.rbxl (55.2 KB)
Reproduction steps:
- Start a studio server with a single player
- Exit the client-side (simulate player leaving)
- Notice the server will print ‘nil’; this statement will become ‘Humanoid’ when you set ‘workspace.PlayerCharacterDestroyBehavior=false/default’
Expected behavior
I expect the humanoid, and other children of the character to still be accessible for the character clone. This was the previous behavior, but it recently changed.
The usecase is that I want to create a ragdoll rig that is a clone of the player character when they leave while in-combat.
Current workaround I use is to set ‘workspace.PlayerCharacterDestroyBehavior=false’. I’m unaware of any way to approach creating a ragdoll rig on player leave with the behavior set to true.