PlayerCharacterDestroyBehavior now destroys Humanoid

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:

  1. Start a studio server with a single player
  2. Exit the client-side (simulate player leaving)
  3. 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.

1 Like

After reviewing the report and code for potential changes to event ordering, we were unable to find evidence that there were any behavior changes here.

PlayerCharacterDestroyBehavior always destroys Character (including Humanoid) and Player.
Character change was always performed last, after the CharacterRemoving is signaled and after auto-destroy is performed (if enabled).

If you still like to use PlayerCharacterDestroyBehavior, consider cloning in CharacterRemoving before it is destroyed.

1 Like

CharacterRemoving does indeed work as a drop-in replacement of GetPropertyChangedSignal("Character"). A bit confusing for me, but with your explanation it makes sense.

Thanks for the help.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.