local Players = game.Players
local function handlePlayerAdded(player: Player)
local localscript = script.LocalScript:Clone()
localscript.Parent = character
for _, player: Player in ipairs(Players:GetPlayers()) do
16:29:21.553 PlayerAdded - Server - Script:4
16:29:21.592 CharacterAdded - Server - Script:6
16:29:22.170 LocalScript Destrying in 5 4 3 2 1... - Client - LocalScript:7
16:29:27.174 LocalScript - Client
I expect the server to fire / receive .Destroying when an Instance is destroyed from any context when the Instance’s change is replicated
.Destroying doesn’t fire / received when an Instance is destroyed from Client when the instance is under LocalPlayer.Character
I think the problem is for the Server it just moves the Instance to nil instead of actually calling :Destroy on the Instance.
The reason why I’m having this problem is because I am controlling playback of Sounds and making them Stop and Destroyed after a period of time on each Client, this is because Replication can be slowed down and .Stopped .Played or whatever will not replicate in a timely manner and cause the Sound to still play which is bad UX and unwanted behavior.
Now when you fix this make sure .Destroying is fired properly on other Clients as well
Issue Area: Engine Issue Type: Other Impact: High Frequency: Constantly Date First Experienced: 2022-04-12 00:04:00 (+07:00) Date Last Experienced: 2022-04-12 00:04:00 (+07:00)
Yeah. This seems like the direct result of the lack of documentation [and making a new policy] for the against-the-FE-grain of having client destructive control of the Character.
Over the years many have posted on the subject and many improvement ideas have been shared as well.
The fact that this has been “swept under the rug” I bet is the reason it was “forgotten” about.
The article on the fixed Destroy() replication (and new Destroying Event) talks about how it is
Server-to-Client, and only mentions in passing the security implications of it going the other direction.
Given this, it appears that the special-case of the local character may have been completely overlooked.
And given this post, it’s not unreasonable at all to assume that this should work Client-to-Server:
We believe this issue should be solved with the introduction of Workspace.RejectCharacterDeletions. With this feature enabled, the server will no longer allow replication of deletions from instances inside your own character. Please let us know if you have any further concerns relating to this.