z.mcc, where x and z are the chunk's coordinates, instead of the usual position. If the value of compression scheme increases by 128, the compressed data is saved in a file called c. Note that chunks are always saved using compression scheme 2 by the official client. 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. There are currently three defined compression schemes: Note that this padding is not included in the length field. Minecraft does not accept files in which the last chunk is not padded. 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). The following byte indicates the compression scheme used for chunk data, and the remaining (length-1) bytes are the compressed chunk data. The entries in the timestamp table are individual four-byte big-endian integers, representing the last modification time of a chunk in epoch seconds.Ĭhunk data begins with a (big-endian) four-byte length field that indicates the exact length of the remaining chunk data in bytes. because it hasn't been generated or migrated yet), both fields are zero.Ī chunk with an offset of 2 begins right after the timestamps table. If a chunk isn't present in the region file (e.g. Chunks are always less than 1MiB in size. 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). Its timestamp can be found 4096 bytes later in the file. To prevent this, use the AND operator (&) instead of modulo: 4 * ((x & 31) + (z & 31) * 32). When using certain languages (such as Java/C/C++), the values of x mod 32 and z mod 32 can be negative. The offset of a chunk (in chunk coordinates) in the first table can be found by using this formula: 4 * ((x mod 32) + (z mod 32) * 32). The first containing the offsets of chunks in the region file itself, the second providing timestamps for the last updates of those chunks. Region files begin with an 8KiB header, split into two 4KiB tables. division int regionX = ( int ) floor ( chunkX / 32.0f ) int regionZ = ( int ) floor ( chunkZ / 32.0f ) // bit shifts int regionX = chunkX > 5 int regionZ = chunkZ > 5 Structure Header The difference in a world's total file size between the Region file format and the Alpha level format is negligible. JahKob has claimed that this format is up to 7 times faster than the previous system. The McRegion format was adopted nearly unchanged, except for the addition of a table of chunk update timestamps. The system is based on McRegion, a mod by Scaevolus, also known for his development of the Optimine project. 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 file does not begin with a magic number, unlike other file formats, and begins directly with the header. 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. Each file stores a group of 32×32 chunks called a region. The Region file format is the binary file format for storing Java Edition chunks from Beta 1.3 to release 1.2. This feature is exclusive to Java Edition.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |