Implement PlayerRemoved

Feature Requests Engine Features
#1

The current PlayerRemoving is very useless to me because the player’s parent is still Players so without passing auxiliary information to a function/creating a new function specifically for PlayerRemoving/doing a lot of hacks, it is impossible to know from within the function if the player has left the game

Right now I will be using ChildRemoved instead (which fires only after the parent property has been set to nil), but it would be nice if there were a PlayerRemoved event because up until now I have been struggling with PlayerRemoving, and I assume many others have been too due to the implied superiority it gets from its name
I would want PlayerRemoved to function exactly like ChildRemoved, but only get called for Player Instances

The specific use case that sparked me to write this feature request is a pre-saving callback that relies on in game data which also needs to be deleted on player leave (to prevent a memory leak)
I used to [think I was, this rbx bug actually prevented it] erase the data on PlayerRemoving but that created a race condition between if the temporary data would be accessed by the pre-saving callback and if it would be cleared

This is what I can easily do now by using ChildRemoved (notice the very simple if not plr.Parent check)

_G.stats.base.saving:bind(function(plr,data)
	for k,v in next,data do data[k]=nil end
	local base=bases[plr]
	for k,v in next,base do
		if typeof(k)=='Instance'and type(v)=='table'then
			data[#data+1]=v
		end
	end
	if not plr.Parent then
		for i=1,#workspace.plates:GetChildren()do
			if plates[i]==plr then
				plates(i,nil)
				break
			end
		end
		base:kill()
		base.elevator:Destroy()
		base.plate:ClearAllChildren()
		for k,v in next,base do
			if typeof(k)=='Instance'and type(v)=='table'then
				k:destroy()
			end
		end
		bases[plr]=nil
	end
end)

So if PlayerRemoved were implemented, I think more people would use it over PlayerRemoving because it would sound just as reputable, or is everyone already using ChildRemoved and am I just clueless?

To clarify again, this is not asking for a rename like this feature request, but instead is asking for a new method

Also it would be nice if DescendantRemoved were added for the exact same reasons

2 Likes
#2 
Players.PlayerRemoving:connect(function(player)
     player.AncestryChanged:wait()
     -- Code
end)

?

#3

Sure but I prefer (server side, I’m not going to parent non player objects to Players)

Players.ChildRemoved:connect(function(player)
     -- Code
end)

And I did not know (or I forgot) PlayerRemoving did not fire after the player was parented to nil

This is more about clarity than about functionality (as stressed in the op)

#4

I think this naming convention is somewhat of a standard in API design. The meaning of PlayerRemoving is that the Player hasn’t been removed yet (gerund vs. participle), but is about to be removed. Additionally, especially with events like DescendantRemoving, the instance’s Parent may be useful information, and it is most naturally found by accessing the .Parent property (of course, we could have DescendantRemoved(instance Instance, oldParent Instance), but I think that is needlessly complicated compared to the current API.

In your use case, it doesn’t make sense to handle plr.Parent == nil in a handler for an event named stats.base.saving. IMHO, you should have a separate handler that does the cleanup after the base has been saved.

However, I do agree that the API is a bit inconsistent with these events (ChildRemoved vs DescendantRemoving).

1 Like
#5

I agree it is useful to know the old parent of an object, so if DescendantRemoved were to be implemented it should pass the oldParent as you said

the base saving is just one of the stats that is saved, and since others can precede it (I don’t want to lock order because that is hacky), there may have been yielding between when the playerremoving event was fired and when that code ran~meaning the player parent may/may not be nil if this were binded to PlayerRemoving

So how can you guarantee to cleanup the base data if it saved for the last time before the player left?

1 Like