The 4,096 “bug”

If you have been using the Hypergrid you probably heard about the 4,096 “bug.” This post explains what the “bug” is about, how it manifests itself, and how I came to peace with it. It’s also a call for action for grid operators to consider placing their grids below cell 4,096-4,096 on the map. Starting in the previous release, D2 worlds are placed around 2,048 by the configuration tool.

UPDATE 6/10/2011: It turns out that the map breakage starts at 2,048, not 4,096.

Let me start by the observable consequences of this “bug.” (btw, I’m quoting this word because, as you will see, I came to realize that this is not a bug) There are at least two observable consequences:

  1. The first observable consequence was first reported here 3 years ago in the context of OGP work between SL and OpenSim. In short: if you try to teleport between regions that are more than 4,096 cells apart in either X or Y, the teleport succeeds, but the viewer is blanked out. No crashes, but nothing rezzes. This issue, also known as the “long jump” issue, doesn’t just affect  interoperability mechanisms such as OGP and the Hypergrid; it affects teleports within the same grid too. As long as the regions are more than 4,096 cells apart, the viewer blanks out.
  2. The second observable issue is a lot more subtle and more difficult to notice, but it’s there for those who care to notice. Here is the map of OSGrid around Wright Plaza: OSGridMapDo you notice something strange? No? Look again. After waiting several minutes, we get only the -4/+4 map tiles around Wright Plaza. There’s regions beyond that, in fact the whole space around Wright Plaza is filled with regions; but the map doesn’t show them… unless we explicitly click on one of those water tiles — that gets us another -4/+4 around that tile that we clicked. (depending on which version the sim you’re on is running, this may be +/-8 instead of +/-4).
    This happens because OSGrid is placed around 10,000-10,000 in grid coordinates. For grids whose coordinates are below 4,096 2,048 the map is always complete as far as there are regions in cells.

Very likely there are other subtle consequences of these numbers 4,096 and 2,048 which I haven’t come across yet.

Now that I described the observable consequences, you may want to know why this happens. I don’t know the answer to that question, I have just a few clues and hypotheses. Here’s what I know.

First of all, this is not an OpenSim issue, it’s a Second Life issue. It happens to affect OpenSim only because we use the Second Life viewers while deviating from how Linden Lab uses their servers. In Second Life, all the regions are placed between 0 and 4,096 in both dimensions. In OpenSim, for unawareness of any limitations, grid operators started placing their grids in arbitrary coordinates above 4,096. The main culprit was OSGrid, and then other grids followed.

I wish I knew the exact technical explanation for this issue, but I don’t know. It seems to be related to how the viewer represents region coordinates, but that doesn’t quite add up. Here’s the Math. The viewer represents grid coordinates using 64-bit unsigned integers which are, in essence, two 32-bit unsigned integers concatenated together, one for X and one for Y. Each number represents a point on the map in meters. So for example, the SW-most point of cell 1,000-1,000 is point 256,000-256,000. In principle, we ought to have 32 bits to represent these dimensions, which would give us 2^24 cells in each dimension (that’s 2^32 divided by 2^8 (=256), the size of regions in meters). Instead, we seem to be hitting the ceiling at 2^12 cells (4,096). There’s a tempting relation here — 12 is half of 24. Where that halving comes from… I don’t know. Maybe some optimization of Second Life. Perhaps some viewer developer could shed some light here having seen the viewer code?

Whatever the issue is, it seems to pervade the viewer code base in profound ways. Even though this issue has been know for 3 years, no viewer has it fixed. At least a couple of viewer developers have attempted fixing it; one even submitted a patch to Linden Lab (see the original bug report which still contains that patch). Unfortunately, I heard that that patch proved to break other things. In talking with Imprudence devs briefly, they mentioned that they, too, attempted to fix the issue in the viewer and came to the conclusion that the changes were so many that it wasn’t worth the trouble.

I made peace with the issue a few weeks ago. My peace with it started when I noticed, in horror, the second observable effect — the missing map tiles. It turns out that OpenSim has a horrible hack to cope with this behavior, that’s why we see +/-4 regions around, otherwise we would see only the current region and nothing else. It’s a horrible hack, and it’s there just because OSGrid is placed above 4,096-4,096. If we didn’t have the hack there, OSGrid would have no map! This horror was the beginning of my coming to terms with what’s going on.

The issue is not a bug at all. It’s a fundamental design decision of Second Life. Second Life assumes that a grid will never be larger than 4,096×4,096 regions. That design decision is reflected pervasively in the viewer code to the point that very smart developers don’t think it’s worth the trouble changing it. If you think about it, this is not an unreasonable assumption. That’s 16,777,216 regions! Would anyone in their right mind ever operate a virtual world with 16 million SL-like regions?! Very unlikely.

The argument so far for calling it a “bug” seems to have been this: “well, if this is the basis for the 3D web, then clearly there will be more than 16 million regions, just like there are more than 16 million web servers.” True. But not on the same map! Not under the same authority! Seeing the map as one single shared space between all virtual worlds is just… wrong! The map is a grid resource; different virtual worlds should have their own maps. They should be able to have regions on the same coordinates — region placement should not require global coordination. Sure, there are interesting things that one can do with shared maps, but in my view of things, the starting point for interoperability is 1 grid = 1 map. As opposed to all grids = 1 map.

So, having finally realized that this is not a bug, but a not-unreasonable design decision of Second Life, I came to peace with it. It won’t be “fixed” because that would require rewriting the viewers to the point of being unmergeable with the official SL viewer. It would be nice if Linden Lab hadn’t made this assumption. But they did, and we have to live with it.

It turns that “living with it” is not a big deal at all. It’s as simple as placing all the regions between 0-0 and 4,096-4,096 2,048-2,048, because that’s what the viewers expect. What could possibly make this an undesirable situation?

Perhaps OSGrid will have a hard time coordinating this change, precisely because it uses a global resource (the map) shared among hundreds of people. (This comes to prove what a bad idea that is…) I hope the OSGrid administrators will also come to terms on this, and force the coordinates change, so that we can finally have an open Metaverse free of hicups.

9 replies on “The 4,096 “bug””

  1. heh I am not sure you understand how much of a disaster trying to coordinate this would be for osgrid, I honestly just do not see it happening. We currently have aprox. 6000 regions and literally 100’s of region owners/operators, trying to coordinate everyone so they can keep their same exact spot without loosing it would be nearly impossible and frankly not worth the stress it would be on our volunteer staff trying to resolve disputes and mediate the arguments that would arise in such an undertaking. Is there really nothing we can do on the simulator side to overcome this problem? Some kind of virtual coordinates, IE 4097 actually = 0 or something like this on the simulator, it just seems crazy that there is nothing we could do on the simulator side to overcome this problem.

  2. another problem that arises is there are already a lot of regions down in this zone, which would make an absolute shift completely impossible as there would be a lot of overlap.

  3. Peter host says:


    Thx for clarifying this point. And also hoping Osgrid will become more HG friendly

    I personally can’t agree more about the limitations of grids in terms of a network of virtual worlds and your HG protocol got me convinced as soon as I begun using Opensim, 2 years ago. The one thing I haven’t yet found an analogy for ( maybe because it’s totally irrelevant) is the equivalent of “world popularity/influence” (or in google terminology, pagerank) in virtual-world space. Avatar influence could be achieved by measuring ocurences of a creator name’s in virtual props, but what is a “one directional hard link” between two grids ?

  4. BlueWall says:

    We saw this in OSgrid a good while before the OGP days. I put some regions at about 30000, 30000 and jumped back to my regions which were located just south of Wright Plaza. This was the first time I saw it. We assumed that we were doing something wrong (or missing something) to cause the phenomenon. And that it was an OpenSim issue. Afterward we were careful to put our regions closer to the center of the grid.

    Later, when the OGP project was started by Linden Lab, we were given some ranges of coordinates to place our regions. They happened to be in meters, not region units. But, we didn’t know this. So, as we entered the coordinates as-is our regions were very far apart. And some who jumped to the Linden regions on Agni saw this bug on the LL regions.

    With the onset of Hypergrid, I added a gateway region between my OSgrid regions and my original OGP regions that were within jumping distance of the Agni regions. Then, it was possible to login to Agni and travel via the gateways to OSgrid, then on to Wright Plaza. Whump Linden was the first person to make the OGP/Hypergrid trip through the gateway from Agni to OSgrid.

    Good point about the map. I don’t believe I have ever been in a block of regions large enough to fill the map. Most of us have just thought it was something that needed addressing on the OpenSim side.

    Thanks for the info!

  5. Thanks so much for the explanation! Do you know if this issue is being addressed in the non-SL viewers such as by the realXtend folks or Tipodean?

    Peter — Grid popularity can be measured by the number in inbound hypergates that point to your grid. We’re starting to see some of these one-to-one links appearing (I’m putting a few on my not-yet-officially-launched Hyperica grid), and Pathfinder has some up, as well. However, there aren’t nearly enough of these gates yet for any realistic measurement of popularity. The most common gates are menu-driven gates that give access to a large collection of destinations — The Hypergates is the most common example of these. You can’t (yet) pick and choose which destinations appear in The Hypergates hypergate on your region. I’m sure that functionality is coming, however, as the number of hypergrid destinations is exploding.

  6. Ai Austin says:

    We also seem to get confusion when trying to teleport back to a region on another grid that happens to be placed at the same xloc,yloc as an existing region on OSGrid. For example, Vue-9000 on Openvur grid was originally at 9000,9000 on that grid, but when teleporting back from OSGrid, e.g. Wright Plaza, I ended up in the OSGrid region that happened to be at 9000,9000 and got a confused map that mixed Openvue and OSGrid regions. Maybe this was a 0.6.9 thing? At some sage if you think it’s worth it I’ll reset Vue-9000 again to be at 9000,900 and try again?

  7. Ai —

    It’s always a good idea not to put your regions on round-numbered locations. There’s a good chance that some other grid already has regions there, and you won’t be able to teleport directly to them if you want to — you can’t jump from one region to another if they have the same coordinates.

    (Is that another SL-related viewer issue?)

    But I’ve never heard of teleporting to one region and ending up at the same coordinates on another grid. I *have* heard of maps not being updated immediately after you teleport from one grid to another, so you’re still seeing the old regions on the map for a little while.

  8. Ener Hax says:

    nicely put and thank you for the thorough explanation (while the online Ener Hax is very much a naive and carefree 14 year old inner child, her agent has a minor in mathematics) =)

  9. I think the argument of the amount of regions enabled by a 4kx4k grid is only partially valid. What if one wants to use real-world coordinates for regions? I mean placing a full-sized region map-tile on top of openstreetmap at the point where one in-world meter is about one pixel on the map is approximately at zoomlevel 17. This requires a 2^17 sized grid-axis for region coordinates, in order to place regions at any location on the openstreetmap map. I’m quite sure this is useful for gis-like applications, so I’ll dig into the viewer code and ask some viewer devs for help. Maybe it’s not impossible to solve. This seems indeed like a viewer issue.

Comments are closed.