Summary: This is an idea to extend the simulator architecture to allow a simulator to have larger space by allowing it to host multiple regions within the simulator Details: The simulator hosting multiple sub-regions is called a "Linked-Region" here in this feedback Each sub-region hosted by the simulator remains a 256x256 area; let's call it a "Sub-Region" here The Linked-Region Simulator would have multiple global grid coordinates, one for each sub-region And so the Grid can identify normal regions or Linked-Region sub-regions with global grid coordinates in a similar manner; each coordinate is assigned to a sub-region The Linked-Region has a base region name, and each sub-region would have a region name with a post-fix number, like <Region Name> #2 , #3 , #4 , etc. There will be a primary sub-region that can be referred to by the base region name or <Region Name> #1 , while the rest of the sub-regions would have post-fix numbers The Grid would be able to identify the Linked-Region and its sub-regions by the base region name or <Region Name> #<Sub-Region Number> (or for the primary sub-region, just <Region Name> ) SLURL would be extended to resolve the Linked-Region and its sub-regions in the same way, like <Region Name> #<Sub-Region Number> The simulator would manage the agent/object/script information with an extended format, like {sub-region-id, <x, y, z>} , or by keeping objects in each sub-region separated in some way The simulator would know which agent/object/script belongs to which sub-region, so crossing between sub-regions of the same simulator would not require the data packing/transfer/unpacking process, making the crossing faster within the Linked-Region The simulator would check whether a crossing is between different simulators or within itself (meaning between sub-regions of the same simulator) and decide whether to use the normal region crossing process or an inter-sub-region crossing process What is currently inter-simulator communication can happen within the Linked-Region The agent/object/script count limits remain the same as the current simulator The settings related to the entire simulator—such as ownership, restart cycle, object lists, etc.—would be managed for the entire Linked-Region Simulator The region-wide settings such as terrain shape/texture/color, water height, wind, region-wide EEP, region-wide permissions, etc., would be managed for each sub-region The reason for the feedback: The main goal is to create more space for residents without adding too much running cost for LL or region owners Second goal is to make region crossing faster (between sub-regions of the same Linked-Region simulator) This can be used as filler regions like oceans between continents There are two bounds in SL spaces: area and agent/object count The 256x256 area boundary is so integrated into many parts of the system and is hard to change, but extending the simulator to handle area by changing "simulator = region" to "simulator = multiple regions" might help, especially around grid mechanics This is to extend the simulator so that the "space" boundary can be widened for vehicle enthusiasts What I wrote might not make sense or has prolems, but I would like to throw a rock into the pond to see if some (better) idea might come up from something like this. We can have giant space like in other platforms Reference: https://feedback.secondlife.com/feature-requests/p/mega-regions https://community.secondlife.com/forums/topic/503010-obscure-question-when-does-the-simulator-send-establishagentcommunication-to-the-viewer (Many of the middle sections of the crossing process may be skipped or simplified for the crossing within the Linked-Region.)
