local Players = game.Players
local function handlePlayerAdded(player: Player)
print("PlayerAdded")
player.CharacterAdded:Connect(function(character: Model)
print("CharacterAdded")
local localscript = script.LocalScript:Clone()
localscript.Destroying:Connect(function()
print(localscript, "Destroyed")
end)
localscript.Parent = character
end)
end
Players.PlayerAdded:Connect(handlePlayerAdded)
for _, player: Player in ipairs(Players:GetPlayers()) do
handlePlayerAdded(player)
end
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
Expected Behavior
I expect the server to fire / receive .Destroying when an Instance is destroyed from any context when the Instance’s change is replicated
Actual Behavior
.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)
I dont think this is a bug. because you destroying something from the client via local script, it will not replicate to the server.
Same thing goes for stuff like playing a sound locally, the server and other clients will never hear the sound unless replicated or played from a server script.
@Ethanthegrand14, I don’t think you understand how Roblox works.
The LocalPlayer has complete control over their Character, if they delete something INSIDE LocalPlayer.Character then it is Replicated.
The problem is .Destroying isn’t firing for that but it should because it is being replicated.
I wouldn’t be having this problem in the first place if what you said is true because the Sound is missing on the Server when it’s deleted from the Client
You don’t have to take my word for it, you can use the sample place and observe what happens.
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.