Improve Debris service to handle post-destruct logic

Currently, the Debris service serves the single purpose of having the AddItem(object, lifetime) method. With this, it’s impossible to apply proper cleanup/aftermath logic to items that have been added to the queue without other workarounds.

It would be nice if AddItem could take a 3rd argument, for a callback function which is called just before or right after the object that was queued is destroyed. Alternatively, an event such as Debris.OnCollected/Destroyed/Removed could be provided which fires for objects being destroyed.

This change would make it easier to handle use cases such as destructing projectiles that have lived for too long while still applying an effect like an explosion in their position, or freeing Lua resources/interfaces being used to wrap Roblox objects in common OOP.

24 Likes

Can’t this already be easily done with delay and :Destroy()?

local part = Instance.new("Part",workspace)
delay(5,function()
    if part then 
        part:Destroy() 
        --stuff
    end
end)

However, a better way to improve Debris and turn it into something actually useful would be to add a method that fires an even if the parsed object is collected by the gc. That, or add a .Destroyed event.

Either ways, Debris seems like more of a relic from the old days.

This counts as a work around I mentioned, and creates a thread per object that might sit around doing nothing for a while, as opposed to potentially just adding things to a list that is periodically checked.

Not to mention, it’s ugly and not easily made generic.

3 Likes

Debris is far more reliable. Every single time I try to destroy stuff manually like that, something goes wrong somewhere. It would be so much easier if I could just avoid the headaches of manually managing threads and just directly do something straight from Debris.

2 Likes