Principles

Principles

For this explanation, we will use a world with limits (-16, 16) on the X and Z axis.

Mechanics

World Limits

Each Level/Dimension can be configured with individual limits. This functionality was required to make sure nether portals (which operate on a 8:1 overworld block ratio) don't under-cut or over-cut the overworld's limits.[1^]

Chunk Limits

Because the coordinate (0, 0) starts on the north-west edge of chunk (0, 0), this means that chunk (0, 0) is part of the X+ and Z+ axis. This can be expressed as an algebraic limit with [-16, 16). It means that the edge of X- and Z- is chunk -16, and the edge of X+ and Z+ is chunk 15.

Chunk Loading

1. When the player approaches a X+ axis bounds, the server sends chunk -16 from the X- axis.
2. The client loads chunk -16 in place of chunk 16, because chunk 16 is the first wrapped chunk after the X+ bounds.
3. This process continues. If the player crosses the bounds to the other side, only the server teleports the player to the other side. On the client, the player isn't teleported. This means that as soon as the player crosses the bounds once, their coordinates are now relatively equivalent to the server.[^2]

[^1]: Originally, only one set of world limits was possible. While this meant that the limits could be accessed anywhere in the code through use of a singleton instance, it also meant that the nether would have a larger limit when it needed a smaller one, and the end would have a limit when it didn't need one at all. This does unfortunately mean that mixin methods now need some way to access their operating Level to apply the correct limit transformations. On the client side, this is fine, since it has a singleton level instance. Server-side however, if the Level isn't in the class of the mixin method, it has to be retrieved from further up the call stack.

[^2]: This has some advantages and disadvantages. For one, this means that every position the server sends the client, the client will have to translate it into its relative coordinate space. Also, shared code between the client and the server will have to be changed client-side, which is a massive amount of work. But, what this does mean is that vanilla-clients have the potential to connect without issue, and are able to walk across the bounds without being teleported. This means vanilla clients won't have to completely reload their chunk cache, which will cause visual abnormalities on the client and will require the server to resend all of the chunks the client already had. Alternatively in the future, modded clients will use the same coordinate space as the server, and when they teleport, they are smart enough to not request chunks they already have, or visually glitch. The server will accommodate vanilla clients by sending them unwrapped coordinates and chunks, essentially doing all the wrapping work for them.