Talk:Java Edition Alpha level format

!I've restored this page from a google cache. it needs to be checked for lost formatting and broken/missing links Eminence

"due to the sheer size of the map (several times the surface area of the Earth)." Can someone explain what this is refering to? The map has a potential of reaching TB sizes, no doubt. Anyhow the surface of the Earth (refering to our reallife planet) is about 510 million km² (source en.wikipedia.org/wiki/Earth) If you think of a block in minecraft to be 1 m² that would make 510 billion blocks. There is no way for minecraft to reach as many blocks as just once "the surface area of the Earth"... If this refers to the surface of the explored map itself then please rephrase it. There is no "the Earth" in Minecraft. happymoep

Alpha maps support 64 million blocks in both directions (or 64,000km if we want to talk about square-footage in square kilometers). 64000km*64000km = 4,096,000,000km², or 4,096 million km², which is, indeed, several times the surface area of the Earth. Xolotl 13:42, 1 November 2010 (CDT)

235 Petabytes

I'm not sure where you got the 235 petabyte value for maximum map size. Care to show your work? Here's mine.

The limits of the X and Z dimensions are plus and minus 32 million. Discover this by examining the game's code. The level is 64 million blocks wide. Calculate the volume: 64M * 64M * 128 = 524288 * M * M or about 524 petablocks. Each block requires 2.5 bytes to store, making the total around 1.2 yottabytes.

Does not include entities, chests contents, or etc - A level containing only fully packed chests will take some thousand of yottabytes to store.

Besides, the maximum file size is a pretty useless thing to know. It's probably more useful to put the +/- 32 million figure there instead.

Tile entity details

I just added a few more details to tile entities like sign text and chest contents - I'm not that much of a documenter or wiki-guru, so I'd be happy if someone could make it a bit more "wiki-like" :) --Flippeh 21:01, 14 September 2010 (CDT)

Must Index chunks?

Not sure but I think maybe the folders or something don't match the xpos/zpos calculation. So I scanned the dirs and read the xPos zPos out of the chunks.

Or maybe I was just trying to load non-existent chunks.

players/*.dat

Need info on the .dat files per player, what format is that in?

See the "Player" compound of a level.dat

Can't make sense of folder names

* The first folder name is base36(-13 % 64). This is base36(51) which is "1f".

How does that work? -13 % 64 does not equal 51. Then again, I can't comprehend how modulus even works with negative numbers. Can someone explain this further or point me to some PHP code to calculate this with negative numbers? Cheers. --Gnu32 17:26, 26 November 2010 (UTC)

That part confused me a lot as well when I was writing a plugin for the server. So I ended up looking at the decompiled code and found out that bitmasks are used for the folders. In Java, it looks like this:

public String getChunkName(int x, int y) {
	String name1 = Integer.toString(x, 36);
	String name2 = Integer.toString(y, 36);
	String subdir1 = Integer.toString(x & 0x3F, 36);
	String subdir2 = Integer.toString(y & 0x3F, 36);

	return String.format("%s/%s/c.%s.%s.dat", subdir1, subdir2, name1, name2);
}

The PHP implementation could be written like this:

<?php
function base36($value) {
	$string = '';

	if ($value < 0) {
		$string .= '-';
	}

	$string .= base_convert((string)$value, 10, 36);
	
	return $string;
}

function getChunkName($x, $y) {
	$name1 = base36($x);
	$name2 = base36($y);
	$subdir1 = base36($x & 0x3F);
	$subdir2 = base36($y & 0x3F);

	return sprintf("%s/%s/c.%s.%s.dat", $subdir1, $subdir2, $name1, $name2);
}
?>

It's probably better to rewrite that part in the article... --Barracuda 18:36, 26 November 2010 (UTC)

Aha, brilliant. In my code I used some modulus function which supports negatives but this code is even better and cleaner. Cheers bro. --Gnu32 13:12, 26 November 2010 (CST)

Chunk position

Well, one thing that might be worth mentioning is that chunk position (as encoded in filename) is actually world coordinates divided by 16. Yeah, seems obvious, but took me one hour to figure that out... Tpierron 20:40, 15 February 2011 (UTC)

Multiple Chunks wish same xPos and zPos

I'm writing an NBT decoder in golang and i'm noticing that when decoding the chunks there are almost always multiple chunks with the same xPos and zPos. Particularly around xPos == 0 or zPos == 0. Is there something I'm missing? It also seems like the non-unique chunks aren't always around the origin's row and column either they occur elsewere as well.

-Bemasher 04:48, 11 December 2011 (UTC)