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

[GunsForGuns34]

I would love to be able to turn off FallingPartsDestroyHeight it causes alot of bugs in my game, I already have custom systems that prevent things from falling into the void so FallingPartsDestroyHeight just breaks things if they get flung due to jank physics.

Also,
another Enum I would like to see is Enum.FallenPartsMode.LoopParts, this would make any part or assembly of parts simply teleport back to the top of the map instead of being destroyed, perhaps another property for this height could be added. Perhaps FallingPartsLoopHeight could work? Either that, or they just use the inverse of FallingPartsDestroyHeight.

[Troy_Devv (Jovem)]

Yeah, i know there’s an way to “disable” FallingPartsDestroyHeight by setting it to nan using the developer console, dividing 0/0. But it is also a workaround and not official way that uses a bug to accomplish that.

And I noticed a new property has appeared in the Workspace called “FallHeightEnabled”:

From what I’ve found, it was added a while ago, and doesn’t work yet. Still, it’s good to see that they are implementing something like that. The only problem is that it doesn’t fix the problems that FallingPartsDestroyHeight has. It will continue to be an unreliable way of clean up falling parts and a wasted potential