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.
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.
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.
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.
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.
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.
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.
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.
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
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
