DestroyHeight v1.6 | Flexible FallenPartsDestroyHeight

Resources Community Resources
,
1

DestroyHeight

A FallenPartsDestroyHeight alternative

destroyHeight
destroyHeight200×200 33.6 KB

Get the module here

How to use:

  1. Make sure you’ve disabled FallenPartsDestroyHeight by running this in the console: workspace.FallenPartsDestroyHeight = 0/0
  2. Require the module and call the initialize function in a server script

How it works:

DestroyHeight uses a “monitoring” system where it has a constantly updating table of supported parts utilizing workspace.DescendantAdded and workspace.DescendantRemoving.

Every 0.25 seconds (by default) the table gets looped through to check if any part in that table is below the destroy height.

A part is unsupported (thus won’t be in the table) if it’s either:

  • Anchored (unless DestroyAnchoredParts is enabled in settings)
  • Has one of the exclusion tags in settings

Due to necessary optimizations, unsupported parts that become supported won’t reappear in the table (e.g. unanchoring an anchored part)
To fix this, you need to manually call DestroyHeight.MonitorPart(Part) in another script (otherwise it’ll fall forever and cause a memory leak!)

Available settings include:

  • Height at which the parts destroy at

  • Delay between each height check (Lower delay increases lag)

  • A table of tags to exclude. A part with at least one of the tags from the table won’t be destroyed if it’s below the destroy height (This is why this module exists in the first place)

  • Whether to destroy non-character ancestors of monitored parts that are direct CHILDREN of Workspace (Do you sort your Workspace by models? Then turn this on)

  • Whether to also destroy anchored parts or not (Huge toll on performance, not recommended at all. Someone might need this though)

  • Debugging but like who cares

You can tweak the destroy logic inside the DestroyHeight module itself and I even left a little example there of what custom stuff you can do.

I’m surprised something like this hasn’t been made before. I honestly had a lot of fun coding this as well

Feedback and suggestions appreciated!

5 Likes
2

I really am curious if this is a performant way to do it.
image

1 Like
3

I figured that it’d be more efficient to make my own parts table and update its contents by using workspace.DescendantAdded and DescendantRemoving, and not just loop through the entire workspace each heartbeat.

If your question is more about… my code just being bad, then take a look at this answer to a thread asking about GetPropertyChangedSignal(“Position”) not working. Unfortunately, it seems like there’s no better way to do this.

2 Likes
4

The least you can do is throttle execution little bit, you don’t really need to check all of parts each every frame.

2 Likes
5

Good idea. I’ll implement this hopefully tomorrow as it’s late right now for me

6

I think you can disable this officially using workspace.FallHeightEnabled now

7

It doesn’t actually do anything right now

8

DestroyHeight v1.1 Changelog:

  • Fixed a lot of bugs, memory leaks, etc. (I’m kind of ashamed that I released DestroyHeight at such a raw state honestly)
  • Removed option to fully destroy humanoid models as you wouldn’t be able to respawn if it’s turned on
  • Added a delay option that delays the height check loop
    (Suggested by @UniDevx)
  • Added an option to not destroy non-humanoid ancestors of monitored parts that are direct children of Workspace (For anyone who sorts their Workspace by models like me)
  • Added a debug option
9

DestroyHeight v1.2 Changelog:

  • Removed leftover unused code
  • Optimized the isSupportedPart and isSupportedAncestor functions a bit by putting a guard clause
  • When a player is found, now it checks if the part is the character’s primary part instead of checking if the name is “HumanoidRootPart”
  • Parts table and the DestroyLogic function can now be accessed by other scripts
  • Removed the empty task.wait() in the parts table loop
10

DestroyHeight v1.3 Changelog:

  • Now if a part has changed from being supported to unsupported, it will be removed from the parts table. This fixes a potential memory leak
  • Settings have been moved to a module under DestroyHeight
  • More guard clauses because I think they’re pretty
11

DestroyHeight v1.4 Changelog:

  • Fixed a bug where non player humanoid models would get all their parts monitored instead of their primary part
  • Added more comments to a few functions and elaborated on a few more things
  • Absolutely microscopic code changes

These few things have been bothering me, but hopefully this is the last update :pray: (Because these updates are useless at this point)

12

I recently found out that FallenPartsDestroyHeight removes joint connected parts of a part when it falls into the void. Whoops

DestroyHeight v1.5 Changelog:

  • Parts that don’t have their root part set as themselves won’t be monitored
  • When destroying a part, it will also call DestroyLogic to every connected part
  • Removed tons of code related to humanoids as they’re irrelevant and stupid
  • Instead of checking for a humanoid for the ExcludeWorkspaceChildren setting, it now uses players:GetPlayerFromCharacter()
  • Removed useless MonitorPart calls
  • With debug enabled, DestroyHeight will print a table of connected parts that it’s about to destroy
13

DestroyHeight v1.6 Changelog:

  • A part will now be supported if its root part doesn’t equal to itself (made this change because when a player uses a seat the hrp assemblyrootpart changes)

Nothing else just one single major bug fix

14

What is the point of using this over the roblox’s built in?

15

My game had a problem where I didn’t want specific parts to get sucked up by the void, so I made this module to include an “exception tag” setting that wouldn’t destroy a part if it has a specific tag and lots of other settings for people that might need them.

If you’d read the post carefully, I already made a remark on the exception tags being the reason why this module exists in the first place

1 Like