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&#124;Contribs) 19:37, 2 March 2011. Please sign your posts with

format of level.dat not in here?
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&#124;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)

Move: Region File Format
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)

How do I find relative chunk coordinates?
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 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 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 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 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)

Format version number update
This page says, " As part of the conversion, level.dat will be updated with TAG_Int("version") (note case) set to 19132 ." 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 18:10, 12 June 2013 (UTC)