Allow us to customize FallenPartsDestroyHeight behavior

[Troy_Devv (Jovem)]

As said in the FallenPartsDestroyHeight documentation, the purpose of this functionality is to prevent parts from falling forever. What I want to request is a better use of this property, because while it solves the problem that it is made to resolve, it causes some other problems.

Problems

1. Parts affected by FallenPartsDestroyHeight don’t get :Destroy()'ed; only parented to nil.

   Can lead to memory leaks, as parts aren’t actually destroyed, therefore, their connections aren’t disconnected.
   That can cause confusion while developing, and makes it not entirely reliable for cleanup.

2. Only BaseParts are removed (and models, sometimes).

   if you have a structure like this:
   
   When all of its parts falls into the void, it will become that:
   

   (If this Folder were a Model, everything would be parented to nil, but in this case it’s not)
   There are several problems that this can cause, such as NPCs, tools and other objects with a complex hierarchy not being “cleaned up”:

   NPC hierarchy after falling off the map

   

3. It’s hard to keep track of parts removed

   There are no events that tell us when a part gets removed by FallenPartsDestroyHeight.
   AFAIK, the only way to detect that, is to use part:GetPropertyChangedSignal(“Parent”), which fells unintuitive for detecting actions made by a property designed to handle falling parts.

If Roblox is able to address these issues, it would improve my development experience because

It would become a reliable functionality and easier to work with, avoiding the use of workarounds.
For example: I wouldn’t spend hours trying to figure out why my Enemies NPCs were spawning without any body parts, but with everything else (They were spawning inside trees and getting flung to the void. But the .Destroying event wasn’t doing the cleanup, because the model wasn’t getting destroyed).

💡 What could be a solution

Simple answer: Make it customizable

Not so simple answer:

• New event signal Workspace.PartFalling(Instance)
• New property Instance.EnableFallDestroy (only visible when Workspace.FallenPartsBehavior = Enum.FallenPartsMode.DestroyParts)
• New property Workspace.FallenPartsBehavior with new Enum Enum.FallenPartsMode:
  • [Legacy/DetachParts]: Current behavior
  • [DestroyParts]: Destroys everything when past the FallenPartsDestroyHeight limit, stopping when found an ancestor which EnableFallDestroy parameter is false.
  • [None]: Will make nothing. But the Workspace.PartFalling event will still be fired (same as other Enums), allowing developers to custom handle destroying/teleport back to map/what fits better.

[Enum.FallenPartsMode.DestroyParts] behavior: When used, Instance.EnableFallDestroy property will be shown, and behave similar to GuiObject.Interactable. When set to true, the Instance and its children will be qualified to be destroyed by FallenPartsDestroyHeight. In that case, it will not allow to set Instance.Children.EnableFallDestroy = false (like GuiObject.Interactable):

Instance.EnableFallDestroy will prevent cases where the folder that is meant to contain Instances that can be destroyed by FallenPartsDestroyHeight, from being destroyed too. Like this Enemies folder here:

Note: The implementation details above are just suggestions. What really matters is solving the problems i listed above