Instance.Destroyed event would fire once after all other events have disconnected, then it will disconnect itself. It would fire when the
Instance can no longer be parented to or interact with the game world. It would allow for ‘extensions’ of existing Instances without messy or inefficient cleanup code.
It is very common that I have an ‘extended’ instance that needs to terminate some running code when the actual instance it uses in the hierarchy is deleted. Currently there is no signal for when an Instance is destroyed other than checking behavior after it is parented to nil. This is a messy solution to a simple problem.
- A controls display GUI that needs to listen to
UserInputService.LastInputTypeChangedin order to update the displayed control. When the actual GUI object is destroyed it can disconnect the
LastInputTypeChangedevent automatically by connecting to the
Instance.Destroyedevent on the GUI.
- A custom effects/particles system based on existing ROBLOX Instances. When the Instances it’s based on are destroyed it can disconnect any
RenderSteppedevents it’s connected to, remove itself from effects index tables, etc.
- Special objects with unique behavior in the game world that are listening for user events or other events not directly related to the Instance they are based on. For example, a physical keyboard that watches for user presence to open up a keyboard GUI. It needs to stop watching for user presence when the keyboard model is destroyed.
Most of these apply when a single script such as a
ModuleScript is handling these objects. With normal
LocalScripts parented to such objects, connections and programming will automatically be disconnected and stopped. It is often more efficient and easier to manage such systems when all the programming is contained within one place instead of being duplicated into each object. We need a way to know when to disconnect and stop programming in these sort of systems.