Like this
destroyEvent:FireClient(player)
task.wait()
object:Destroy()
Because I need to perform disconnections client side before the destroy is replicated.
I’ve run some tests, and if the wait time is short (a few frames), the event handler might still run afterward.
If I wait something like 1 second, there shouldn’t be any problems? Or is this considered bad practice?
Use the .AncestryChanged signal on the client.
or just use instance .Destroying()?
That signal wouldn’t fire on the client if you call :Destroy on the server.
Am i misunderstanding something?
He wants the client to know that the object is being destroyed so that he can clean up some connections beforehand. In that case .Destroying absolutely works through boundary.
No. .Destroying does NOT replicate across the server-client boundary.
Well I’ll be damned, I recall it not working.
Can’t deferred behaviour be problematic with AncestryChanged ?
Don’t worry it’s not a big deal
Not sure how’d that be a problem, do you have code that relies on precise timing?
Thank you, I will do some tests with your suggestions to see if it works as expected
I tested it and found no issue.
I have issues with Destroying or AncestryChanged due to deferred behaviour. When this events are run, the object is already destroyed which could be problematic. short exemple to demonstrate the issue
Server
local testModel = workspace.testModel
local RemoteEvent = testModel.RemoteEvent
task.wait(10)
for i = 1,10 do
task.wait()
RemoteEvent:FireAllClients(i)
end
testModel:Destroy()
client
local RunService = game:GetService("RunService")
local testModel = workspace:WaitForChild("testModel")
local RemoteEvent = testModel.RemoteEvent
connection = RemoteEvent.OnClientEvent:Connect(function(i)
print(i, RemoteEvent.Parent)
end)
testModel.Destroying:Connect(function()
connection:Disconnect()
end)
Output
Whatever method i use, i have no choice to delay the Destroy() call. Or do additional checks in my code. I fell like deferred behaviour make coding way more complicated now…
I don’t see how it’s an issue in your example?
Because the model is not supposed to be destroyed in the connection and if I want to access to a child for exemple it will throw an error
Cache the instances you want to access, or if possible, just return if the object is already destroyed.
Sorry what does that mean ? Can you provide an exemple
Save references to the instances.
local foo = instance
Ok but what if i change a property on a destroyed instance ? Should i check for parent ~= nil before ?