Otoa Kiyori
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:
(Many of the middle sections of the crossing process may be skipped or simplified for the crossing within the Linked-Region.)