Allow the behaviour of FallenPartsDestroyHeight to be disabled

As a Roblox developer, it is currently too hard to work around FallenPartsDestroyHeight.

If Roblox is able to address this issue, it would improve my development experience by eliminating unexpected bugs and replication issues resulting from this behaviour.


In the past couple years I have unfortunately only ever experienced FallenPartsDestroyHeight destroying things I do not want to ever be destroyed by the engine, and this has resulted in me having to manually limit the position I place certain things, which is problematic, and can be ugly.

While I feel the behaviour can be useful to specific projects, and for beginners, I have never relied on this behaviour, and would prefer not to have it in certain projects of mine.

14 Likes

What exactly don’t you want Destroyed?

If it’s a spaceship/planet type game that you explore in all directions?

Otherwise if I read this right you want Parts to fall forever, causing issues with the engine trying to keep them around forever?

There may be a simple way to fix this that someone can help out with.

1 Like

Well, for the most part, every time I’ve had it destroy something, it’s when I don’t want it to. That’s just a matter of the kinds of things I work on, but, I personally find it to be an overall hindrance to me.

I’ve never had it really save the day or anything, and, if I really wanted it, I could just write the code to emulate it myself, and then I get full control too, I can pick and choose which things are destroyed when they’re low.

I’m not denying that it is convenient in some cases but it simply isn’t something I want to be confined by.

The thing is, this happens any time there is a continuous force involved. It’s not just specific to falling objects. FallenPartsDestroyHeight is a solution to the issue of parts falling forever, but, what if that’s not what I want?

Properly cleaning things up is your responsibility as a developer, and I want the ability to take over this responsibility for myself when it comes to things low in the world.

The problem is simply that there needs to be “a fix” at all. I don’t really need help fixing anything, because there’s not really anything to fix, I simply just want to disable this behaviour, so I can utilize area lower down in the world, without needing to account for placing things too low. I just don’t want to have a bunch of math.max expressions everywhere I think there’ll be a problem or something, and I want to be able to have the space be useful.


Tl;dr it really should just be within your control, it doesn’t serve any further purpose unless you actually want it. It’s a lot better as an opt-out feature.

4 Likes

I simply don’t want Player.Character to be destroyed

FallenPartsDestroyHeight is really annoying it has a cap of 50k both ways

Super annoying and causing unnecessary bugs in my game that are out of my control

3 Likes

You can do this by running this code in the command line in Studio

workspace.FallenPartsDestroyHeight = 0/0

10 Likes

This is most likely a bug, neither math.huge nor -math.huge work but 0/0 seems to only work since any comparisons with NaN return false. But it does seem to break FallenPartsDestroyHeight, which makes sense.

Nonetheless I still want an officially supported, forwards compatible way to do this. I wouldn’t expect this to work forever.

13 Likes

To add, if I have an unanchored model, I expect it to stay the way it is as it’s part of my game’s map. If a player does something absurd, I shouldn’t have to keep a backup copy of this model in memory to respawn it, I should be able to simply move it back to where it needs to be if it goes somewhere inaccessible.

1 Like