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
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.
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
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.
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.
There has still been no response on this from any engineers and it’s been nearly a year
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.
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.
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
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.
I’m just bumping this to keep it relative. There needs to be a setting to disable this, really really bad.
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.