Region file format

This article needs cleanup to comply with the style guide.

 ^[discuss]

Please help improve this page. The talk page may contain suggestions.

This page describes content that has been removed and was only present in earlier versions of Java Edition.

 

As of 1.2.1, this format is no longer used.

The Region file format is the binary file format for storing Java Edition chunks from Beta 1.3 to 1.1. Each file stores a group of 32×32 chunks called a region.^[a] The format took the place of the Alpha level format, which had been in use since the Infdev development phase, where chunks were stored in individual files on the file system. The file does not begin with a magic number, unlike other file formats, and begins directly with the header. The format has been superseded by the Anvil file format; however, the Anvil file format made changes only to the chunk format and changed the region file extensions from ".mcr" to ".mca".

The system is based on McRegion,^[2] a mod by Scaevolus, also known for his development of the Optimine project. The McRegion format was adopted nearly unchanged, except for the addition of a table of chunk update timestamps. JahKob has claimed that this format is up to 7 times faster than the previous system.^[3] The difference in a world's total file size between the Region file format and the Alpha level format is negligible.

Location

Region files have names in the form r.x.z.mcr, where x and z are the region's coordinates. The dimension of the region data dictates the sub-directory in which the region files are stored:

• Overworld: save_directory/region
• Nether: save_directory/DIM-1/region
• The End: save_directory/DIM1/region

The coordinates of a region file in which any given chunk resides in, can be acquired through taking the floor of dividing the chunk coordinates by 32. For example, a chunk at (30, -3) would be in the region (0, -1), and one at (1500, -600) would be at (46, -19).

Alternatively, the same can be achieved through performing an arithmetic shift 5 bits to the right. It is important that an arithmetic shift occurs, rather than a logical shift.

// float division
Int32 regionX = (Int32)floor(chunkX / 32.0f);
Int32 regionZ = (Int32)floor(chunkZ / 32.0f);

// arithmetic shift, important that `int` is signed.
Int32 regionX = chunkX >> 5;
Int32 regionZ = chunkZ >> 5;

Reciprocally, the starting block coordinate of a region can be calculated by multiplying the x and z region values (as defined by the region file's name) by 512. Likewise, each chunk's starting block coordinate can be calculated by performing either modulo or floor/integer division to the chunk's index in the header table (0 through 1023) and adding the result to the region's x and z values:

// get region x, z
Int32 regionX = x * 512;
Int32 regionZ = z * 512;

// get chunk x, z
Int32 chunkX = regionX + ((headerIndex % 32) * 16);
Int32 chunkZ = regionZ + ((headerIndex / 32) * 16);

Structure

Header

Region files begin with an 8KiB header, split into two 4KiB tables. The first containing the offsets of chunks in the region file itself, the second providing timestamps for the last updates of those chunks.

The offset of a chunk [x, z] (in chunk coordinates) in the first table can be found by using this formula: 4 * ((x mod 32) + (z mod 32) * 32). When using certain languages (such as Java/C/C++), the values of x mod 32 and z mod 32 can be negative. To prevent this, use the AND operator (&) instead of modulo: 4 * ((x & 31) + (z & 31) * 32). Its timestamp can be found 4096 bytes later in the file.

Chunk location

Location information for a chunk consists of four bytes split into two fields: the first three bytes are a (big-endian) offset in 4KiB sectors from the start of the file, and a remaining byte that gives the length of the chunk (also in 4KiB sectors, rounded up). Chunks are always less than 1MiB in size. If a chunk isn't present in the region file (e.g. because it hasn't been generated or migrated yet), both fields are zero.

A chunk with an offset of 2, therefore pointing to 0x2000 ($2\cdot 4096$ in hexadecimal), begins right after the timestamps table.

Chunk timestamps

The entries in the timestamp table are individual four-byte big-endian integers, representing the last modification time of a chunk in epoch seconds.

Payload

Chunk data begins with a (big-endian) four-byte signed length field that indicates the exact length of the remaining chunk data in bytes. The following byte indicates the compression scheme used for chunk data, and the remaining (length-1) bytes are the compressed chunk data.

Minecraft always pads the last chunk's data to be a multiple-of-4096B in length (so that the entire file has a size that is a multiple of 4KiB). Minecraft does not accept files in which the last chunk is not padded. Note that this padding is not included in the length field.

There are currently five defined compression schemes:

The uncompressed data is in NBT format and follows the information detailed on the chunk format article; if compressed with compression scheme 1, the compressed data would be the same as the on-disk content of an Alpha chunk file. Note that chunks are always saved using compression scheme 2 by the official client.

If the value of compression scheme increases by 128, the compressed data is saved in a file called c.x.z.mcc, where x and z are the chunk's coordinates, instead of the usual position.

Migration and level.dat

Beta 1.3 converts any "old" chunks into region files before loading the world, rather than incrementally, as they are loaded during play. As part of the conversion, level.dat is updated with TAG_Int("version") (note case) set to 19132. Beta 1.3 also introduces a new level name field, TAG_String("LevelName"). A new TAG_Byte("Sleeping") was introduced in player TAG_Compounds - level.dat in singleplayer, [player name].dat in multiplayer that indicates whether the player is in a bed. It has value of 1 (true) or 0 (false). In Beta 1.8, TAG_Int("GameType") was added. In 1.0.0, TAG_byte("hardcore") was added.

The format of level.dat is otherwise unchanged.

See also

• Java Edition level format
• Chunk format
• Anvil file format

External links

• Mojang announcement of new region format; Jeb helping tool-makers
• McRegion
• RegionFile in Java
• RegionFileCache in Java
• Find region file from coordinates

References

Notes

Software

The community has developed programs to work with region files:

Navigation