Future problem: Minecraft save file format.

[endofzero]

This has already been iterated in other places.

I open this to point out that seems likely the save file format is going to change in the next release of Minecraft:

http://twitter.com/#!/jeb_/status/33465975114305536

Here is the mod they want to use:

http://www.minecraftforum.net/viewtopic.php?f=25&t=120160

The next update is in ~2 weeks.

[udoprog]

Yeah, this is gonna be fun : ).

[endofzero]

it may be a good time to factor in Biome color calculations as well..... depending on what is released...

[rmmh]

I tried to reduce the difficulty of updating 3rd-party utilities that handle map chunks when I wrote McRegion.

Here's the ~70 line function that lets Minutor (an interactive mapping tool) handle McRegion:

http://seancode.com/hg/hgweb.cgi/minutor/file/2d9a041cc820/MinutorMap/region.c

I was looking at making c10t work with it as well, but the changes would have had to be a bit more intrusive, and I'm not very familiar with c10t's organization.

Hope this helps!

[udoprog]

For c10t It's just gonna be a matter of modifying the chunk iteration. The specs are nice and compact - nice work. The biggest problem will be handling chunk based caching, would have been nice if a header record would contain modification times and such.

[rmmh]

Ah, I didn't consider that at all. You could use the Adler32 hash (the last 4 bytes of the chunk data) to detect modifications, but a timestamp would be handy.

The last time I used c10t's caching it was creating a single file for each chunk-- does it still do that? That has the same problems with high seek time that the original chunk format does.

[EdGruberman]

It's heeeeeeeeeeeeeeeeerrrrrrrrrrrrrrreeeeeeeeeeeeeeeeeee! :) <3

[udoprog]

oh yeah, time to go to work

[udoprog]

The region support is as good as done : ).