Optimal event for running code when a player leaves?

Hey, so yeah, just wondered if there’s an optimal event to use here besides from PlayerRemoving.

I wondered if maybe Changed could work? Or ChildRemoved, as before the actual character gets destroyed it’s interior children would get removed first, I would assume atleast.

Any help appreciated, thanks!

1 Like

This is what PlayerRemoving is for. Why would you want to use another event?

2 Likes

You could run down a range of different methods that exists. Check which one does it faster or better.

However, I think PlayerRemoving is already optimal as far as I know.

1 Like

I’m like 99% sure PlayerRemoving is the fastest way to accomplish this, however I guess you can check things such as Changed or ChildRemoved from workspace and/or the Players service. I think it’d require more work and you’ll probably see that PlayerRemoving is the most optimal option, but let us know what you find! :slightly_smiling_face:

1 Like

This seems like an XY problem… there really is no better event for checking when a player leaves while still having access to the player, at least for the moment.

If you are trying to check when the player’s character is destroyed when the player leaves, you could probably use player:GetPropertyChangedSignal("Character") to get the event for the Character property changing. It might be nil when the player is leaving. You could also probably use character:GetPropertyChangedSignal("Parent") to see when the character is destroyed, and probably connect the two events together to see when a certain condition is true, like connecting an event to Players.PlayerRemoving for 1.5 seconds or something like that and disconnecting after enough time has passed that it’s obvious that the player didn’t leave.

2 Likes

Thanks for the replies everyone. The reason why I was looking at something different was because of a round system I’m doing, and I need to run certain code if a player participating in the round leaves, and I figured it wouldn’t be a good practice to create a new connection using the PlayerRemoving event, I’d rather make a connection that’d be unique to that player alone. (Aka, ChildRemoved.)

:slight_smile:

Creating a connection for each player would be less efficient/worse practice than having a single connection for all players, so there’s no reason not to use PlayerRemoving.

1 Like

Hey guys, just a quick follow-up question. I’m gonna use the PlayerRemoving event instead, but I’m wondering if the character of the player will already be gone by the time it runs? I’m trying to spawn a key where ever the character died or where he left the game, and I’m not sure if this event runs for when the player leaves, and doesn’t take into account for the character.

Just wondered how this would work out. Thanks :slightly_smiling_face:

On the chance that the character is destroyed after the player is gone, you will theoretically still have access to the destroyed object’s properties because instances do not become nil when destroyed. Instances follow the same rules for garbage collection: they only get deleted when there are no references to the destroyed instance anymore.
This means that if you keep at least the character’s position in some kind of character cache, you would be able to deduce their position upon leaving, even if their character does not exist. Keep in mind that this can lead to memory leaks if the cache is not kept up with properly.

Maybe something like this code would work:

local HRPCache = {}

Players.PlayerAdded:Connect(function(plr)
	--...
	plr.CharacterAdded:Connect(function(chr)
		local hrp = chr:WaitForChild("HumanoidRootPart")
		table.insert(HRPCache, plr, hrp)
		
		local humanoid = chr:WaitForChild("Humanoid")
		local connection; connection = humanoid.Died:Connect(function()
			connection:Disconnect()
			PlaceDiedMarkerAt(hrp.Position)
		end)
	end)
	--...
end)

Players.PlayerRemoving:Connect(function(plr)
	--...
	local hrp = table.remove(HRPCache, plr)
	PlaceLeftMarkerAt(hrp.Position)
	--...
end)
1 Like