See also: https://feedback.secondlife.com/feature-requests/p/full-sim-20

The problem is that the grid is premised entirely on 256x256 blocks. A hypo to demonstrate:

Say you're plotting out "gridwide" positions in LSL. Lots of use cases for this, like gridwide navigation. There are two functions relevant here:

llGetPos (and its derivatives) is always expected to return positions within 256x256m. (There are a few instances where you can get a position outside these bounds - I think raycasting can do that? - but that's by far the exception.) If that suddenly increases, that will break scripts that expect to only get 0-256.

llGetRegionCorner specifically returns the gridwide position of <0, 0, 0> in the current region. In other words, llGetRegionCorner + llGetPos will always get you the gridwide position of the object. Additionally, llGetRegionCorner historically can be divided by 256 to get the region offset, which is used for mapping out grid "cells" (regions) - if you look at the map, I think some TPVs have an option to show the region offset.

So expanding region sizes raises a question. How do you maintain the expectation for 256x256m regions without breaking existing content?

This feature request has been debated for years now and the only real solution has been to split these super-sized regions into 256x256 blocks internally.

Two problems with that. First, scripts that use position tracking to detect region edges will get confused, because there sometimes isn't actually a sim crossing anymore - you can jump from 255.9m to 0m (or vice versa) without actually crossing a region border.

Second, scripts that check for region names using llGetRegionName, or even track regions using llGetRegionCorner, may run into problems. If <128, 128, 0> can refer to four (or more!) separate positions within a larger region, there has to be a way to distinguish which of those it actually is. That could be done with a new script function, but existing scripts wouldn't be able to detect that.

I think it would make sense to be able to have adjacent regions on the same simulator, as used to be the case back when there were server "classes", and just optimize crossings between them. Since you don't need to request physics shapes, scripts, etc. from the asset server - you can quickly switch them into the other process for the other region - region crossings could be almost instantaneous.

See also: https://feedback.secondlife.com/feature-requests/p/mega-regions

The problem is that the grid is premised entirely on 256x256 blocks. A hypo to demonstrate:

Say you're plotting out "gridwide" positions in LSL. Lots of use cases for this, like gridwide navigation. There are two functions relevant here:

llGetPos (and its derivatives) is always expected to return positions within 256x256m. (There are a few instances where you can get a position outside these bounds - I think raycasting can do that? - but that's by far the exception.) If that suddenly increases, that will break scripts that expect to only get 0-256.

llGetRegionCorner specifically returns the gridwide position of <0, 0, 0> in the current region. In other words, llGetRegionCorner + llGetPos will always get you the gridwide position of the object. Additionally, llGetRegionCorner historically can be divided by 256 to get the region offset, which is used for mapping out grid "cells" (regions) - if you look at the map, I think some TPVs have an option to show the region offset.

So expanding region sizes raises a question. How do you maintain the expectation for 256x256m regions without breaking existing content?

This feature request has been debated for years now and the only real solution has been to split these super-sized regions into 256x256 blocks internally.

Two problems with that. First, scripts that use position tracking to detect region edges will get confused, because there sometimes isn't actually a sim crossing anymore - you can jump from 255.9m to 0m (or vice versa) without actually crossing a region border.

Second, scripts that check for region names using llGetRegionName, or even track regions using llGetRegionCorner, may run into problems. If <128, 128, 0> can refer to four (or more!) separate positions within a larger region, there has to be a way to distinguish which of those it actually is. That could be done with a new script function, but existing scripts wouldn't be able to detect that.

I think it would make sense to be able to have adjacent regions on the same simulator, as used to be the case back when there were server "classes", and just optimize crossings between them. Since you don't need to request physics shapes, scripts, etc. from the asset server - you can quickly switch them into the other process for the other region - region crossings could be almost instantaneous.

Variable region size would be good to have. More so if they can have enclaves inside them, ie surround a full region with a single 1km mega open space.

A 512x512 region with 50k prims would like having four standard regions with only 12.5k prims each. Considering the current standard capacity for a private sim is 20k, you might want to raise that.

an upgrade like this would also be amazing for sailing, since sim crossings while sailing is a huge issue and many people often fall off their boats at the sim crossings.

It is technically possible, but we'd run into floating point precision issue rather quick. We know LL is currently working on 64bit version for the server and if successful, we might have a chance to push for bigger sim.

Variable region size, I've been wanting it for over a decade.

Better still, also allow enclaves. So for example 1 or more full regions could be surrounded by a single km scale open space region.