The ability to disable FallenPartsDestroyHeight

As a Roblox developer, it is currently difficult to have space games that allow as much movement along the Y world coordinates as across the X and Z axes - at some point or another, someone is going to run into the FallenPartsDestroyHeight. In cases where Workspace.Gravity is set to 0, having this feature makes no sense anyway, as parts won’t fall into it unless actively pushed down.

I propose allowing us to disable this feature in our games, or at least uncapping it. This would greatly benefit open 6DoF space games, at the very least. Again, it’s kinda useless having FallenPartsDestroyHeight if parts aren’t going to fall into it by default.

Edit: Yes, I’m aware of imprecision far away from world origin. All I’m asking for is the option to disable an artificial barrier. Let whether developers want to risk rendering errors at extreme distances be up to them.

61 Likes

I assume you’ve heard about how objects fairly far from the origin start acting quirky.

First off, how will you solve that?

2 Likes

Given that there’s already freedom of movement across the X and Z axes and even along positive Y, this isn’t adding a new problem - it’s the same problem we already see along ±X, ±Z and +Y. Given that the problem’s already there, I don’t see why I should solve it just because I want freedom of movement along -Y.

I’m also pretty sure zeuxcg talked about improving precision far from origin on multiple occasions. Don’t ask me about rendering stuff, I have no clue.

13 Likes

Mind linking me to the thread?

1 Like

No guarantees, he only mentioned it in passing. I have a lot of threads to go through.

Edit:

Yes, the one specifically mentioning floating-point precision is from a while back, but the forum search function isn’t great to work with unless you already know exactly what you’re looking for, and I’d imagine any improvements to floating-point precision would be made incrementally over time, so it would still apply anyway.

Included the one on rotation because it may or may not be more noticeable further from origin and thus exacerbate the other imprecision issues.

I can’t stress this enough: I’m not an expert on rendering. At all. This has derailed the thread somewhat.

3 Likes

Agreed. Support though. Ideally, I’d set it to math.huge/inf and expect it to work. That seems friendly for new devs.

2 Likes

I’m all for uncapping FallenPartsDestroyHeight if it functions past 50k, but is there a reason you can’t just shift your world up so the bottom is at -50k? There’s no top constraint.

Also, I think you underestimate how much 50k is. Even for a space game, it’s a lot.

Keep in mind that space station is 1500x1500, and it’s barely visible at 50k studs away. The capital ship is just a spec.

4 Likes

It’s not infinite. That’s his concern. Having to handle players moving too far down either with a warning UI or teleportation is bad UX in my mind.

2 Likes

If there’s nothing down there, players won’t fly further down. If they want to fly through emptiness for a few minutes, then there aren’t any UX concerns for showing them a warning to turn back.

8 Likes

You have a point. However, it’s still a bit jarring to have an alert pop up telling you “the world stops here, you will be removed from existence if you continue”, and just making ships explode if they get too close feels cheap.

Also worth noting is that the earthlike planet I currently have has a radius that puts the very bottom at Y-25,000, and that’s at surface level. Adding another 50% to that for the FTL exclusion zone doesn’t give much freedom between it and the destroy height.

I suppose I could move everything up 50k studs to mitigate it, but then floating point imprecision would be more pronounced if players flew up. There’s not really any way to win, as it currently stands. Rock and a hard place.

2 Likes

Couldn’t you use places in some way to mitigate this?

IE: Player X flies past 50,000 studs: teleports player to a new place, which matches the stuff that should be past 50,000 studs

Of course, you’d need some wizardry to get the char and leaderboard to work (save the server data to a unique id, perhaps?), and things like BasePart:MoveTo would need an additional wrapper around it to move to the correct place, but I can’t see why it wouldn’t work.

Sounds interesting. Definitely possible with a custom loading screen. How would you map that, though?

You would definitely need to map the borders to each place with this in account.

Perhaps you can just build it all in once place, and use a script to split it into different regions,and then publish those regions as separate places?

I meant that mapping players that could be anywhere in a 3D space is hard enough, although it can be somewhat lazily solved by a radar-esqe 2D plane with blips accompanied by altitudes.

That could definitely work.

Alternatively, you can datastore player locations, and update from those (there might be some sort of delay, though)

EDIT: A quick search reveals that datastore data is cached for 4 seconds, so this wouldn’t be responsive at all. You’d have to justify the lag using some ingame lore or something

Radar range
EM interference

I guess you might be able to use httpservice as well to further reduce lag?

500 requests/min puts it at 1 second delay time, easily.

But then you’d have to make your own game servers lool

1 Like

Heyo @RoughSphereBlox

Could we have any staff response regarding this feature? :slight_smile:

5 Likes

Gonna go ahead and bump this.

This is a feature that needs to be added. I don’t see why all other directions are practically infinite while -Y is limited.

It seems like a remnant of Roblox’s past to be honest.

14 Likes

I need this for procedurally generating multiple planets. By limiting how far the player can go down on the Y axis, the play area gets halved. I’d have to either spawn the player at the edge of a universe, or spawn them at Y = 1 billion

4 Likes