Talk:Region file format

"The coordinates for the region a chunk belongs to can be found by dividing the chunk coordinates by 32 and rounding downwards. For example, the chunk at chunk coordinates x=35, z=-3 can be found in the file region/r.2.-1.mcr"

This example appears to be wrong 35/32=1.09375 which rounds down to 1, would not the file name of the region be region/r.1.-1.mcr?

–Preceding unsigned comment was added by NobodyOfNaught ^{(Talk|Contribs)} 19:37, 2 March 2011. Please sign your posts with ~~~~

"Region files are located in a subfolder of the world directory called "region"" - only for Overworld. Nether and End are in descriptively named DIM1 and DIM-1 but which is which?? Sharfpang (talk) 08:26, 10 April 2020 (UTC)

The format is missing the level.dat format.

There is a reference in alpha that the level.dat is gzipped serialized java data.

In beta this does not seem to be true.

The data is gzipped, but the conent ist not java data.

Java serialized data starts with 0xACED. The data I found does not.

(java serialization info: http://download.oracle.com/javase/6/docs/platform/serialization/spec/protocol.html)

My data starts with

0A 00 00 0A 00 04 44 61 74 61 01 00 0A 74 68 75 ; ......Data...thu

–Preceding unsigned comment was added by Blindleistung ^{(Talk|Contribs)} 18:47, 30 September 2011. Please sign your posts with ~~~~

It helps if you sign your comments with four ~'s. Actually, the level.dat and chunk files have never used Java serialization. They use a custom format called NBT (Named Binary Tag). Notch has taken down the original documentation, but if you Google "NBT format" you'll find several libraries to read/write it. 99.46.157.221 00:11, 24 October 2011 (UTC)

There is also this nifty article: NBT Format. Enjoy! LB 02:03, 8 July 2012 (UTC)

I also agree with this proposition. --{ Fishrock123 } ^(Talk) 15:51, 19 November 2011 (UTC)

I think all the development resources about the current level formats are petty messy due to the constant stream of updates and additions between infdev and 1.0.0 and need to be reworked. Also, file formats and NBT structures need to be separated. And the way how the NBT structures are documented could be better... big nested lists aren't the best solution. So, yeah... lots of work to do here. --Barracuda 16:28, 19 November 2011 (UTC)

If my absolute chunk value is -29,42 (x,z) then my region's x coordinate is int(-29/32)=int(-0.90625)=0 but it's -1 because I have to subtract 1 from the before calculated value because my chunk was negative. And then my region's y coordinate is int(42/32)=1. But now what is my RELATIVE chunk coordinates? That is what are the chunk coordinates (from 0 to 31 are valid for x, and 0 to 31 are valid for y) WITHIN the above mentioned region?

Please help me to calculate this. Thanks in advance.

76.104.145.19 23:18, 27 December 2012 (UTC)

Multiply the region coordinates by 32, then find the difference between your current chunk location and that result. In your example, the region coordinates are (-1, 1), so the relative chunk coordinates are (-29 - (-32), 42 - 32) = (3, 10). For another example, chunk coordinates (-123, 456) are in region (-4, 14), and have relative chunk coordinates (-123 - (-128), 456 - 448) = (5, 8). -- Orthotope 02:59, 28 December 2012 (UTC)

How do you say -29/32 is 0 rounded down? As you said, that equates to -0.90625. You need to use floor() to round that number down, and the first integer value below -0.9 is -1. 0 would be ceil(-0.9). 78.144.106.211 22:58, 6 January 2013 (UTC)

In most languages you can cast to an integral type to truncate the decimal portion. LB^(T|C) 00:06, 7 January 2013 (UTC)

I believe truncation is what was causing the trouble addressed in (78.144.106.211)'s comment. --Quartzmmn (talk) 16:23, 28 September 2013 (UTC)

I had a very similar question along this line. I was looking at where the article says, "The location in the region file of a chunk at (x, z) (in chunk coordinates) can be found at byte offset 4 * ((x mod 32) + (z mod 32) * 32) in its region file. In case the values of x or z are negative, subtract their absolute value from 31 after calculating the modulo." The location in the region file is based on the "relative" chunk coordinates that (76.104.145.19) was asking for, and if I understand correctly this quote therefore describes an alternative to Orthotope's formula.

However, as I analyze this alternative I'm seeing a flaw in the instructions for negative numbers. It makes perfect sense if one assumes that the region at -1 owns the chunks from 0 to -31, but this is not the case; chunk 0 is owned by region 0, and region -1 owns chunks -1 to -32. So in case the chunk coordinates are negative, you also need to add 1 before calculating the modulus.

Is my math wrong? I often overlook some silly little detail for minutes on end with arithmetic like this. But if I'm correct, perhaps we should fix the article?

Thanks!

--Quartzmmn (talk) 16:23, 28 September 2013 (UTC)

What do you mean by "region -1"? Are we discussing where chunk information is inside the region file or how to determine which chunks are in which region file? LB^(T|C) 16:59, 30 September 2013 (UTC)

I believe the answer is the former, and the latter only insofar as it determines the former. So we're trying to find the relative/per-region chunk coordinate for a given chunk based on its global chunk coordinate, and where the boundaries of each region fall affect what that number will be. Is that any clearer? Sorry if I'm being confusing.

--Quartzmmn (talk) 13:48, 6 October 2013 (UTC)

Hm, I think the instructions should say "In case the values of x or z are negative, subtract their absolute value from 32 after calculating the modulo." instead of 31 - can you double check to make sure? LB^(T|C) 17:23, 7 October 2013 (UTC)

I thought about that, but I'm foreseeing trouble with the modulo if one does it that way. If x = -32, we know its index in region -1 should be 0. But the modulo of -32 is 0, whereupon subtracting from 32 yields the wrong index. To yield index 0, subtracting from 31 will work if we better emulate the input range of the positive numbers (i.e. [0 >> 31]) by shifting them by +1 before calculating the modulo, from [-1 >> -32] to [0 >> -31]. So the formula for negative numbers should, if I am correct, be 31-((x+1) mod 32). --Quartzmmn (talk) 15:29, 8 October 2013 (UTC)

P.S. Using my formula so far appears to work flawlessly in the C-based reading/writing library I'm writing. Not sure how confident that can make us at this point, but there it is. --Quartzmmn (talk) 17:32, 8 October 2013 (UTC)

32-abs(-32) is 0, modulus 32 is still 0. LB^(T|C) 01:08, 10 October 2013 (UTC)

I don't think that's the formula currently described in the article (which i interpret to be '31-abs(x mod 32)', or '32-abs(x mod 32)' with your proposed change), but I don't think even the formula you use there, '(32-abs(x)) mod 32', would work for any values at or below -33. To demonstrate: '32-abs(-33)' = -1, and '-1 mod 32' = -1, an incorrect index (should be +31). I'm sorry that we seem to be miscommunicating... I'm fairly confident that we can demonstrate my proposal to be accurate if we try one input value at a time, over a wide enough range. --Quartzmmn (talk) 02:49, 11 October 2013 (UTC)

Sorry, just noticed a typo in one of my comments. My proposed formula is either '31-abs((x+1) mod 32)' or '31+((x+1) mod 32)'; the latter works just as well because this formula would only be used when x is tested to be a nonzero negative number. --Quartzmmn (talk) 03:08, 12 October 2013 (UTC)

Both you proposed formulas are correct for negative x, but are waaaay too complicated. A general way is to test if x mod 32 is negative and if yes add 32. That works for all x. Alternatively you can use ((x mod 32) + 32) mod 32. --91.19.236.6 13:03, 18 November 2013 (UTC)

Just to be clear, I will leave the page in its current subtly inaccurate condition until explicitly asked to change it, especially considering the apparent disagreement over my suggestion. My voice has been heard, and I'm leaving the issue in more authoritative hands. --Quartzmmn (talk) 04:45, 10 November 2013 (UTC)

I just fixed the article. The issue with the expression "x mod 32" is that there are two kinds of moduli, the positive and symmetric modulos. x mod 32 in the article refers to the positive modulos. Java and other C-like languages use the symmetric modulos, which, in these languages, is called % and keeps the sign of x, so -34 % 32 = -2 but -34 mod 32 = 30. One can simply transform the symmetric modulos to the positive modulos, if you either define x mod m := ((x % m) + m) % m, or you define x mod m := x % m, if x >= 0, x mod m := (x % m) + m if x < 0. So in other words, they only differ by a "+ m" in the negative case. --91.19.236.6 13:24, 18 November 2013 (UTC)

Thank you, (91.19.236.6). I can corroborate that both methods in your comment from 13:03, 18 Nov 2013 should work perfectly. For the record though, the first one differs critically from LB's proposition in that you test for nonzero negativeness after calculating the modulus, where LB was (if I understood properly) testing before calculating the modulus. This would cause his formula to fail for x = -32, etc. (Beyond that, the comparative complexity among our methods appears to me as a simple matter of opinion.)

Along the same line, I should point out, the formulae-in-brief you presented at 13:24, 18 Nov 2013 seem to me to risk an interpretation with the same flaw as LB's formula, because you say 'if x < 0' instead of 'if (x % m) < 0', which might fail to leave at 0 the modulus of x = -32, etc. (Your wording in the actual article avoids this ambiguity.) --Quartzmmn (talk) 16:55, 19 August 2014 (UTC)

Modulus of negative numbers is undefined in some programming languages, which is why you should always check for negativity first. LB^(T|C) 18:33, 20 August 2014 (UTC)

I can't quite understand why no one yet thought about AND operator. We're performing division by 32, which is a power of 2 (2 ^ 5 = 32). So we can use optimized way: instead of N % 32 — N & (32 - 1). And in our case it behaves as positive modulus. For example: -32 & (32 - 1) = 0, -34 & (32 - 1) = 30 --Sigod (talk) 04:52, 27 April 2015 (UTC)

So [From 0,0 to 31,31 have region 0,0] , [From 0,-1 to 31,-32 we have region 0,-1] , [From -1,0 to -32,31 we have region -1,0] , [From -1,-1 to -32,-32 we have region -1,-1] .

Therfore if x/z > 0 then we divide by 32 and round down so: floor(((x or z))/32). If x/z < 0 then take we divide by 32 and round down: ceiling(((x or z))/32).

Examples:

If x = -2 then region = ceiling(-3/32) = -1,

If x = -32 then region = ceiling(-32/32) = -1,

If x = -33 then region = ceiling(-33/32) = -2,

If x = 4 then region = floor(4/32) = 0

If x = 31 then region = floor(31/32) = 0

If x = 32 then region = floor(32/32) = 1

Using both together,

If x=426 and z=-321 then region = floor(426/32) , ceiling(-321/32) = 13,-11

So all you have to do is write "If x/z > 0 , then , floor(((x or z))/32). If x/z < 0 , then , ceiling(((x or z))/32)." as a formula. DeleriousWraith (talk) 15:14, 14 May 2020 (UTC)

This page says, "<quote>As part of the conversion, level.dat will be updated with TAG_Int("version") (note case) set to 19132</quote>." I think this information is out of date, as the current PC release of Minecraft writes level files with a version number of 19133. As a n00b, I didn't dare go into the text and update this myself, hence this recommendation to those less timid. Elrac 12:27, 12 June 2013 (UTC)

You're confusing Anvil file format with Region file format. Prior to Beta 1.3, there was no version tag at all. Beta 1.3 started saving the version tag with value 19132. When Anvil was introduced the version number started saving as 19133. The line you quested is about pre-Beta 1.3 converting to Beta 1.3 or above (before Anvil ofc). LB^(T|C) 18:10, 12 June 2013 (UTC)

The formula included seems to assume the origin (x0 z0) is a corner where 4 regions meet. In fact it is the center of region 0,0. If it were a corner where 4 regions meet then no region could be numbered with a zero. You can't have four different "0,0" regions by just including - and + versions of the number after all. So block-wise x-256 z-256 to x+256 z+256 are region 0,0. You need to be adding or subtracting half a region in the formula.

"The formula included seems to assume the origin (x0 z0) is a corner where 4 regions meet." The formla is incorrect yes as this is exactly where 4 regions meet after carrying out some testing personally. DeleriousWraith (talk) 15:20, 14 May 2020 (UTC)

i think the page should be renamed MCRegion file format like the convesion screen said dont you think? --173.180.201.172 01:05, 15 June 2019 (UTC)

The page Anvil file format should be merged into here. The binary format is the same, with the only changes being to that of the chunk format. Thoughts? SWinxy (talk) 00:14, 31 January 2024 (UTC)

👁 Image
 Support. It's annoying having to reference two pages to get the complete current format. This page should have the latest information, with maybe a section at the bottom that describes the changes between mcr and mca. — Misode (talk) 15:08, 3 March 2024 (UTC)

in my opinion, its pretty stupid to merge them, since they are still 2 different file formats.

"This page should have the latest information"

Region was last used in 1.1

plus, why merge pages about something that wasnt used for a looong time, with something used today? Captain Dumb (talk) 09:36, 22 July 2024 (UTC)

👁 Image
 Comment. Honestly, it would be best if all information about the chunk format itself is stripped from both pages, since both formats are effectively chunk container formats, and could really store any arbitrary sequence of bytes. Leave the chunk documentation to Chunk format itself, where it can be kept up to date easier. Once that is done, it will be a lot more clear whether the pages should be merged. bigfoot (talk) 04:19, 3 December 2024 (UTC)

I would like to retract my previous support. I now 👁 Image
 Oppose merging. They are two separate file formats and I now see the use in separately documenting both of them fully without having to reference other articles or having information about the other format being mixed in a combined page. Having some information duplicated is not the end of the world. — Misode (talk) 04:31, 3 December 2024 (UTC)

👁 Image
 Oppose merging as well. This page describes the predecessor of the modern chunk container format, so it should just be kept for historical reference, not updated with newer developments. I support moving the compression data, which seems to be per chunk, to Chunk format and only leaving information about the actual chunk container format in the Region and Anvil pages. -- mschae23 (M_S_72 | talk) 07:17, 3 December 2024 (UTC)

👁 Image
 Comment: I believe the problem isn't really that Anvil has a separate page so much as that treating Anvil and Region as entirely separate conflates changes to the Region file format with the changes to where region files are stored and to the chunk format.

The Region file format from its introduction to modern versions has been a fixed constant with upgrades, in much the same way as that most Indev data values (except Cloth) directly translate 1:1 to pre-Flattening data values. Similarly, the Flattening rewrote the chunk format to a greater extent than Anvil ; and then again with the entity split.

If the unit of measurement is that the region file format is different because of where the files were stored, the splitting of entities into a separate directory in Java Edition 20w45a is as big of a change.

While putting all of this information in one place would probably improve things, really I'd argue that there needs to be a distinction between the world format and the binary format ; sort of as if the contents of this page were simply describing, say, the format of a ZIP file, detached from the difference between an old texture pack and a modern resource pack, both using that format.

To give an idea of what I'm suggesting, some example sentences:

"The extension of an MCRegion file is dependent on the world format it is a part of ; from its introduction in Beta 1.3, it is .mcr, while with the introduction of Anvil in Java Edition 1.2.1, it is .mca (avoiding conflicts during the migration)."

"MCRegion files are containers for NBT, but the contents of this NBT are based on the directory and world format."

"Changelog: (need to find version, but likely 1.15/19w36a due to MC-140507): From this version, if a chunk would otherwise be unsavable due to containing too much data, the chunk is instead exported to a separate .mcc file, marked with the addition of 128 to the compression type." (Something else to check is when .mcc support was introduced; in other words, if these files are read by earlier versions.)

- 20kdc (talk) 11:33, 14 April 2025 (UTC)

I was curious about topics such as making chunks unwritable using books and shulkers (should someone wish to poke at this themselves, I was trying 100 pages of separately generated 256 characters of chr(random.randint(0xE000, 0xF8FF)); a script to repeatedly copy this into your clipboard helps), but the information on the technique seemed inadequately documented, so I was experimenting in 1.21.4.

This is how I learned that 1.21.4 automatically uses the .mcc format (almost the Alpha format, but zlib rather than gzip) for 'oversized chunks', as given by the following error:

[11:08:35] [IO-Worker-21/WARN]: Saving oversized chunk [2, 2] (156725443 bytes} to external file /media/modus/External2/minecraft/PrismMC/instances/1.21.4/.minecraft/saves/New World/region/c.2.2.mcc

Testing the same technique in 1.12.2 (EDIT: change to 112 bytes twice per page, use character range 0x0020, 0x2000) meanwhile appears to create an interesting effect where the server simply reverts the contents of the chunk.

It seems like the history here isn't documented, possibly due to the Region/Anvil confusion mentioned by other topics. A problem I see is that the Region page is talking about features that were introduced in late versions of Anvil without always mentioning when support was actually introduced into the format. 20kdc (talk) 10:34, 14 April 2025 (UTC)

This was presumably fixed in snapshot 19w36a (or data version 2203) which can also be seen in MCA Selectors source code which refuses to store oversized chunks on data versions older than that. I do agree that this article being marked as deprecated is misleading and i do think this should be mentioned in the article Birnendampf (talk) 11:58, 5 February 2026 (UTC)

Retrieved from "https://minecraft.wiki/w/Talk:Region_file_format?oldid=3632199"