PlayerCharacterDestroyBehavior doesn't function on the Client

PlayerCharacterDestroyBehavior was recently implemented, which runs Destroy() on any character and player instances when they die or leave. However, I’ve encountered an issue where connections will not disconnect, even after the player has died and respawned, meaning the connection should have disconnected.

On the server, this behavior functions as intended, as you can test with the code attached:
(Script within ServerScriptService)

local Players = game:GetService("Players")

local connection: RBXScriptConnection

local function CharacterAdded(character)
	if connection then
		print(connection.Connected)
	end
	
	connection = character:WaitForChild("Humanoid").Running:Connect(function()
		
	end)
end

Players.PlayerAdded:Connect(function(player)
	player.CharacterAdded:Connect(CharacterAdded)
end)

On the client, if code very similar to that script (modified so it works on the client) is ran within StarterPlayerScripts, the connection will STILL stay connected.

You can see how this behavior works here:
https://gyazo.com/11a24600274bc5135a26434635a57fa3

Reproduction Steps

  1. Open up a blank baseplate.
  2. Set PlayerCharacterDestroyBehavior within Workspace to Enabled
  3. Create a LocalScript within StarterPlayerScripts
  4. Paste in the following code:
Code and Explanation
local LocalPlayer = game:GetService("Players").LocalPlayer

local connection: RBXScriptConnection

local function CharacterAdded(character)
	if connection then
		print(connection.Connected)
	end

	connection = character:WaitForChild("Humanoid").Running:Connect(function(speed)
		
	end)	
end

CharacterAdded(LocalPlayer.Character or LocalPlayer.CharacterAdded:Wait())

LocalPlayer.CharacterAdded:Connect(CharacterAdded)

This code is a simple character-added method, in which upon the character is created, a new connection is set to the .Running event within the Humanoid. If the connection is already defined, it will print whether it is connected or not.

  1. Run the game, and reset your character.
  2. See unintended behavior: Connection stills says it is connected, despite another player being spawned in.

This is just the replication steps on the client, but you can also paste the first code sample in a ServerScript to see the difference from the Client and Server.

6 Likes

We’ve filed a ticket to our internal database, and we’ll follow up when we have an update!

Thanks for the report!

4 Likes

They mentioned it was intended; I want this to be changed as I still need to rely in disconnecting stuff from Players in a leaderboard client side. I want to also have the convenience of doing Player.Destroying or Character.Destroying on client as well.

Quote From The Announcement:

1 Like

Well that’s disheartening. If replication rules still apply, then this connection should be disconnected though, as the instances should be destroyed anyway. It’s not like the client doesn’t replicate info from the server.

Even if it is intended, then this is something that should be at least implemented then, as it does impact game performance. It’s implied that if PlayerCharacterDestroyBehavior works on the Server, then it should most definitely work on the client, which is not the case here.

Edit: If replication rules apply, then this feature should work, as destruction from the server does and should replicate from the client, thus disconnecting said events. (But it doesn’t.)

2 Likes

It’s been a solid few months, and this bug is still present from what I know. Not only that, but the impact of this bug is particularly high, meaning that every single developer is affected by this bug, leaving many games with memory leaks. While this can be fixed by manually destroying the character, not all developers know to implement this.

Is this bug still being classified and assigned to a team, or is it just a lower priority than other bugs?

1 Like

How strange, I will add this to my games right now. I hope Roblox will let us know if or when they put a fix out for this. Thanks

I have been informed by @WheretIB about the fact that Destroy() Can Now Replicate to Clients.

I have re-tested this bug and it still seems to be occurring. (On entirely new baseplate.) The property mentioned in the thread above no longer exists as a property of the workspace as well.

Proof below.

Hopefully we can get this fixed soon.