New Player and Character Destroy Behavior

I will be using custom characters a lot as well, along with Player.CharacterAutoLoads disabled.

In this case it seems the workflow shouldn’t differ from what you’re doing right now, as the new feature will clean up the old character if it still exists when the new one is added, as visible in the code below.

CharacterAdded always fires before Destorying.

The new feature is pretty neat, and is compatible with manual removal of the character.

Code (try resetting)
local Players = game:GetService("Players")
Players.CharacterAutoLoads = false

Players.PlayerAdded:Connect(function(player)
	player.CharacterAdded:Connect(function(character)
		local humanoid = character:WaitForChild("Humanoid")
		
		humanoid.Died:Once(function()
			task.wait(3)
			player:LoadCharacter()
		end)
		
		character.Destroying:Once(function()
			print("Character destroying")
		end)
		
		print("Character added")
	end)
	
	player:LoadCharacter()
end)
17 Likes

Wow, honestly, this is a real announcement, unlike the other one. :smirk:

Also, this feature is super cool tbh.

11 Likes

Yooo, update that fixes long present memory leak?

That’s a W in my book.
I didn’t even know characters were just parented to nil, there was a memory leak I didn’t even know existed.

13 Likes

Love this update. Now I can delete all my player and character handling on remove!

12 Likes

Does this mean if a character dies I don’t have to update the character variable in scripts?

10 Likes

Connecting to Players.PlayerAdded and Players.PlayerRemoving does not necessarily create a memory leak, because the connection is only related to the Players service. If you maintain references to the Player argument that gets passed by those events however, that’s where you could see a memory leak.

To give some examples:

Fixed by this change (because the CharacterAdded connection would have maintained the reference under current behavior)

game:GetService("Players").PlayerAdded:Connect(function(player: Player)
    player.CharacterAdded:Connect(function()
        print("New character!")
    end)
end)

Not fixed by this change (because the instance reference exists indefinitely in the AllPlayers table)

local AllPlayers = {}
game:GetService("Players").PlayerAdded:Connect(function(player: Player)
    AllPlayers[player] = true
end)

The above example, manually patched

local AllPlayers = {}
game:GetService("Players").PlayerAdded:Connect(function(player: Player)
    AllPlayers[player] = true
end)
game:GetService("Players").PlayerRemoving:Connect(function(player: Player)
    AllPlayers[player] = nil
end)

As for a reduction in server memory usage, you will a change to the rate at which memory increases if you had a memory leak patched by this. It will likely not have an impact on baseline memory usage.

12 Likes

If it is no longer possible to reparent characters on CharacterRemoving please add an alternative such as a character property to avoid being destroyed immediately on player death/leave.

This would be useful in cases where a death animation is played on a character and would be much simpler to play it on the existing character rather than having to clone it.

7 Likes

They should have called it :SweepUnderRug() because that’s what it is really doing.

9 Likes

You could probably work with this: New Player and Character Destroy Behavior - #12 by WheretIB

7 Likes

Well this is surprising, I kinda thought the new behavior was how it worked the whole time so this is a neat history lesson for me. Glad to see Roblox continuing to improve their core tech stack.

7 Likes

This is a great update and I have already been doing this in my game for a long time with a custom script. Will events like Players.PlayerRemoving() and Player.CharacterRemoving() be affected by this? Will the :Destroy() function happen after these events have run?

EDIT: This is the answer!

  • When a player leaves the experience, the Destroy method is called on the Player Instance. This task is deferred and occurs after bound event connections are invoked.
6 Likes

I had no idea that Players and Characters were not destroyed.
I’m sure I had leaks because of that assumption.

Thank you for finally fixing that hidden issue.

8 Likes
-- Broken by PlayerCharacterDestroyBehavior = Enabled

Players.PlayerRemoving:Connect(function(player)
    task.wait(1) -- Because we are deferring, this code will not work
    local points = player.leaderstats.Points.Value
    print(`player.Name left with ${points} points!`)
end)

-- Still works, even with PlayerCharacterDestroyBehavior = Enabled
Players.PlayerRemoving:Connect(function(player)
    local points = player.leaderstats.Points.Value
    print(`player.Name left with ${points} points!`)
end)

I got a concern, does the “task.wait()” still breaks even so it is not at the start of the function.
Below is a summary of how I use “task.wait()”

game:GetService("Players").PlayerAdded:Connect(function(Player)
	Player.CharacterAdded:Connect(function(Character)

      local StatsInfo = Player:WaitForChild("StatsInfo") 
		local PlayerLevel = StatsInfo:WaitForChild("PlayerLevel")
		local PlayerClothes = StatsInfo:WaitForChild("PlayerClothes")
      local FakeServerhop = game.ServerStorage.FakeServerhop


---About 40 ~ 50 lines down of info for Player
 

task.wait(1) --- I add this to let the info load, while the player respawns.
-- for I need the player to spawn to give them their clothes.


---About 40 ~ 50 lines down to Add Player Info to Gui, etc.

    Character:WaitForChild("Humanoid").Died:Connect(function()
         FakeServerhop:Fire(Player, 'PlayerClothesRenew')
       end)

		


   end)
end)

EDIT:

This is used every time the player dies. (And a few corrections)

6 Likes

Wow, I never knew this was even a thing, even after looking into oddities with removing players’ characters years ago (there was some change that made simply setting a player’s character to a different humanoid model cause a respawn… I never fully figured it out, but my current assumption is a change to the order objects are loaded into the player character model, and when removed, it would remove either the head or torso before the humanoid object, causing the Died event to fire?)

Any chance of getting a setting to control that? Manually controlling respawns fixed it, but I’d rather not have to do that in the first place.

3 Likes

I wonder why this wasn’t released by default, I see no negatives here, can you (or someone) explain to me the limitations/down sides of this feature that make it an “opt in” feature instead of just a general rollout/bugfix?

3 Likes

Well written explanation! Good comms :slight_smile:

5 Likes

The player’s character is only destroyed on the server which appears to be a bug. It is not destroyed on the client:
image

When the Character property is set to nil the character is destroyed on the server, which is inconsistent (or just confusing) with this language:

7 Likes

For the purpose of ragdolls;

Due to this change it’s no longer possible to preserve the Character model to re-use for a ragdoll. The reason to keep the entire model is to prevent the need for re-replicating any of its contents to clients.

If nothing is done to solve this issue, ragdolls will need to be fully replicated to clients, increasing latency upon player death and thereby worsening game feel.

The only solution is to introduce a setting that prevents the Character model from destroying (and / or having its parent set to nil). Hopefully this is something you will consider before the opt-out period ends!

This change affects my game’s ragdolls. Ragdolls were designed to re-use Character models after death, and now that they’re being destroyed, the game simply spams errors and displays no ragdolls. My only choice is to abandon the optimization I’ve created.

5 Likes

About time this was addressed. This is something people have been complaining about for awhile now. I’ve had to resort to manually calling destroy on the player’s character when they died, and when they left the server to make sure it was cleaned up properly.

3 Likes

That’s actually a good point. Probably introduce a time setting to where after this many seconds, the character is destroyed. Probably two separate settings:

  1. Player died and respawn, must be less than the respawn time.
  2. When the player leaves the server.
5 Likes