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 ~~~~

Location of Nether and End?

"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)

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|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|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)

Format version number update

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)

Pretty sure the formula is wrong

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)

renaming

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)