If you go too far from the origin you’ll end up with floating point errors anyways which result in some really weird behavior
Either way, this would still allow more playable area as floating point errors occur pretty far out, and centered around the world origin. You could argue allowing us to disable the destroy height alleviates the floating point issue by giving us more space close to 0,0,0 to work with.
3 Likes
This suggestion will greatly benefit my game.
-50k does sound like a lot but huge worlds such as my spaceship game are limited by this, i have stars at position (0, 0, 0) and objects such as space stations or asteroids that are at 75k studs away horizontally from the center.
It’s also very annoying to account for the case where a spaceship flies below the destroy limit, this could be easily avoided with an option to simply disable that void.
Together with the promised large worlds feature that is planned in the roadmap (64-bit Servers for Large Worlds), makes this idea very much worth considering.
6 Likes
There has still been no response on this from any engineers and it’s been nearly a year 
5 Likes
I imagine it’s pretty far down their priority list, given the physics and rendering improvements we’ve been getting as of late (and what’s still scheduled). I’d still like to see this, but I understand other features with more use-cases come first.
1 Like
As a workaround, it looks like setting workspace.FallenPartsDestroyHeight = 0/0 (AKA NaN) prevents the height comparison from working, effectively disabling this feature.
Obligatory disclaimer: You probably shouldn’t rely on this.
22 Likes
2 Likes
I saw this got bumped so I’ll bring it up again
I remember the docs mentioning that parts under 50,000 studs dont physically render, unless thats not the case anymore, then again, this was posted two years ago so things can change
1 Like
They seem to render just fine for me - setting FallenPartsDestroyHeight to NaN using 0/0 and lobbing my character off the world works as I’d expect. I can see my character continue to deform as they move further from the world origin.
Are you sure that 50k figure isn’t some general render limit? I recall the maximum render distance was increased to 100k studs at the highest settings a few years back.
1 Like
I’m just bumping this to keep it relative. There needs to be a setting to disable this, really really bad.
3 Likes
Also, I have an addition to this thread. Using a folder, and some hefty averaging, you can easily move the entire world to center it on the origin. That way, slowly the world doesn’t move away from the origin, wasting precious space in doing so. I recommend doing this every 60 seconds.
Another thing, using the Humanoid's scale properties, you can scale players down and therefore the entire game down, possibly.
Bump - if they don’t want to implement this then they can at least promote 0/0 to a feature.
7 Likes
You cannot disable FallenPartsDestroyHeight. FallenPartsDestroyHeight is one of Roblox’s ways to destroy parts that fall off the baseplate, that is because parts that still exist can cause lag especially if they are unanchored, FallenPartsDestroyHeight does this by setting the part’s parent to Nil and locks it.
Actually you can disable it, if you set it to NaN
workspace.FallenPartsDestroyHeight = (0 / 0)
3 Likes
Parts that fall out of the workspace aren’t destroyed, you can test this by listening to AncestryChanged (in another script), moving the part and parenting it back to the workspace.
Event connections aren’t cleared either, if anything’s eating performance its that.
But won’t you die since it’s set to NaN because it’s at 0?
And for you, when you run Destroy() on an instance, the parent property is locked so no script cannot bring it back. It’s gone for good.
“and for you”, if you’re going to give me that attitude then maybe you should check what you’re saying is true.
If you think I’m doing some under the hood magic, run this script and try it yourself (dont place the script in the part)
local part = workspace.Part
local e = part.Position
part.AncestryChanged:Connect(function(_, p)
if not p then
part.Position = e + Vector3.new(0, 5, 0)
part.AssemblyLinearVelocity = Vector3.new()
part.AssemblyAngularVelocity = Vector3.new()
part.Parent = workspace
end
end)
3 Likes
NaN isnt 0 NaN stands for Not a Number, so anything that would usually get destroyed at the destroy height won’t because there is no number defining the height
3 Likes
Parts won’t fall if gravity is set to zero - I already made this point in the original post, if you’d bothered to read it. Don’t patronise me.
1 Like