SimpleDestroy Module | Know when your parts will be destroyed, connect it to events!

Hello there, everyone.

I’m pretty sure that, at some point, you’ve also run into a situation where if Roblox were to make available an Instance event like .OnDestroy, your script would become way more practical or just over all better.

This module will do this favor for you! By using SimpleDestroy you’ll know when your parts will be destroyed and will be able to link that to certain events.

How does it work?
All instances share four properties, one of them is the most interesting one, “Archivable”, Archivable can be used to determine if an Instance can be cloned or not, it is somewhat important but not in the scenario we’re looking at since the objective is to delete the Instance.

How can I delete parts with the module?
Simple enough!

local Destroy = require(modulePath)
Destroy(Instance, optional time)

You can add a little delay to when you want your part to be destroyed, just like Debris. The module will not yield, so you can have multiple pending deleting parts and they’ll all be deleted respecting their delays.

Practical Use

local targetPart = game.Workspace.Part
local destroy = require(modulePath)

targetPart:GetPropertyChangedSignal("Archivable"):Connect(function()
 print("Part has been deleted")
end)

destroy(targetPart)

Here’s the model for sale:
https://www.roblox.com/library/6043659336/SimpleDestroy

7 Likes

Archivable does have a purpose though and it has nothing to do with DataStores.

I’m not sure how the Archivable property ties into your module, but it’s useful for preventing plugin items from lingering in Studio mode upon saving or publishing and in live games it’s useful for making Clone calls fall through (although this is useless if used in cases of security rather than functionality).

I feel like you could do something better here, such as using CollectionService or doing your tracking from the module itself.

3 Likes

I thought of the idea of using Collection Service, but I think that by using Archivable it would be the ultimate simplicity.

I understand that Archivable has some purposes but none would conflict with what I’m aiming for. The objective of the module is to delete an instance, so if it’s used, the affected part would just be deleted a heartbeat after having that property switched.

Thanks for the tips!

EDIT: Also, about the datastores, think I was mistaken with another property, I’ll edit it out.

1 Like

Could be wrong but can’t you already check if a part is being removed like this:

local part = Instance.new("Part")
part.Parent = workspace

part:GetPropertyChangedSignal("Parent"):Connect(function()
    if not part.Parent then
        print("i am destroyed :(")
    end
end)
2 Likes

Yes, that does work. I actually used to do it like that, cause I thought it was a reliable method.

As time went on sometimes that method left my hanging, due to lag or the script just not being able to catch the change of parents for some reason, it does work as well and it’s reliable for the most part.

The difference between using my module and that method is that my module waits a heartbeat before destroying the instance, which makes it work pretty much 100% of the time.

1 Like

There is another method determining if a instance was destroyed that I use without any noticable issues:

local Part = Instance.new("Part")
Part.Parent = game.Workspace

Part.AncestryChanged:Connect(function(_, Parent)
    if Parent == nil then
        print("Destroyed")
    end 
end)

The developer hub actually uses this method as an example:

4 Likes

That’s great, thanks for the tips, I’ll make sure to look into it.

1 Like

That method has issues too. =(
The same applies to @Thezi’s method.

1 Like

Oh, I didn’t knew that, after all it appears my module does serve a good purpose, thanks for letting me know!

1 Like

While this is true, I don’t believe the ops module is capable of solving this issue without the use of remotes. You may as well fire a remote to the client under ancestry changed.


Speaking in functionality, the op has basically created a debris service with one extra feature and seems to run under heartbeat (haven’t read the script, read from replies). No offence but doesn’t seem vastly useful, I guess some may benefit from this. I’d recommend making sure that the client is able to tell when an object is destroyed (if not already done).

1 Like

It’d be preferable not to reuse the archivable property. You could have a function “getDestroyEvent” of the module which returns the event signal of a bindable event and fire that when the instance is destroyed instead of changing the archivable property.