Writing code with deferred events is super painful right now. Traditionally you listen to Destroying to know if something is destroyed, but with deferred events you can have code run between Destroy and Destroying. I need a function that tells me whether an object is destroyed or not.
function IsObjectDestroyed(Object)
return Object == nil
end
local instance = Instance.new("Part")
instance:Destroy()
print(IsObjectDestroyed(instance)) --> false
That doesn’t check if an object is destroyed.
function isDestroyed(object)
return object == nil or object.Parent == nil
end
-- Attempt to find the object in the Workspace
local Object = workspace:FindFirstChild("Silly")
if Object then
-- Check if the object is destroyed (should be false initially)
print(isDestroyed(Object))
-- Destroy the object
Object:Destroy()
-- Check if the object is destroyed (should be true after destroying)
if isDestroyed(Object) then
print("object has been destroyed.")
else
print("object is not destroyed.")
end
end
Sorry about that try this
We can check if the Parent in nil
, but that could just mean the instance hasn’t been instantiated or was removed without being destroyed.
It would be nice if we had a method which returned if the instance was removed with :Destroy()
, :ClearAllChildren()
or some other engine means.
Keep in mind this would not return true for parts that get removed at FallenPartsDestroyHeight
, because those aren’t actually destroyed and can even be restored.
Can you explain what’s going on in your control flow that is causing problems like this? It smells like bad architecture.
You should probably handle the lifecycle of your objects with tag bindings or with a module like Trove/Maid so there’s no chances of anything executing past the cleanup of whatever object you are destroying.
Calling Destroy
is deferred as well, so you can count on the cleanup code running before Roblox actually destroys the instance.
function isDestroyed(object)
return object == nil or object.Parent == nil
end
funny = Instance.new("Part")
isDestroyed(funny) -- True???
An actor is running something for itself every frame.
Something outside the actor destroys it.
The actor doesn’t know that it’s been destroyed because its Destroying event won’t fire until later, so it continues its normal operation and errors because objects are missing.
Also this is not true
(Post must be long enough)
Mmmm, yeah I can understand this being a nightmare in the context of Actors. My apologies.
Maybe in the meantime you could tag the object as being destroyed to tell the code that it’s about to be destroyed? That or an attribute, just some kind of immediate context that would tell you it’s no longer worth operating on. Avoid traversing the DOM as much as possible too if you can help it.
Hi, what’s a DOM and why do you recommend not traversing it? (curious)
You’re using an instance that doesn’t have a parent meaning it’s going to return nil
Your so wise . Pardon me, but what is an “Actor”? I’m guessing it just refers to something “acting” on something else. If so, in the case of OP, is his hierarchy / workflow unavoidable to achieve what he wants? Thanks
Actors are used for Parallel Luau; It allows you to run multithreaded code (the cpu kind, not the luaState kind) to enhance performance for certain computationally expensive tasks
What returns nil? isDestroyed
? It literally can’t do that.
I think the responses in this thread indicate a need for this API. People obviously don’t understand what destroying even is.
i truly feel your pain, DevForum is becoming Twitter
just some assurance, yes I support your feature request and I understand why we need it