Edit: This program is meant for batch processing all the regions with a world and covering them with beta 1.7 biomes. For a more versatile tool, please see my new post: http://www.minecraft...-biome-painter/
This program goes through every chunk in a Minecraft world (which needs to already have been converted to the new "Anvil" format introduced in 12w07a) and fills out the biome information with what biome would have been at any given x and z coordinates if this was still before the introduction of the dramatically different terrain generation in Beta 1.8 last September.
This program is meant to be used on worlds that were mostly or entirely generated under Beta 1.7 or prior. The goal is to be able to use older worlds and have biomes begin and end where they used to, instead of finding snow and ice forming where it never did before, et cetera.
Notes and caveats:
You seriously need to make a backup copy of your world before you run this program on it, just in case.
If your world contains chunks generated with Beta 1.8 or later, this program will still work, however it will still blindly force biomes as they were located in Beta 1.7 over every single chunk, regardless of when that chunk was generated. If that isn't what you want, I'm sorry but all I can suggest is digging into the source code yourself or waiting for someone to develop a better tool.
Not all the old biome types exist in the current version of Minecraft. For instance, this program takes all locations that in 1.7 on back would have been "Shrubland", "Seasonal Forest", or "Forest" and tags them as being in a "Forest" biome because the first two biomes no longer exist Minecraft. For more information, see "MCWorld.cs", the function "GoGoGadget()".
There appears to be a bug in at least 12w07b where weather properly recognizes the specified biome in every way except for the rain/snow falling through the air effect. So, the rain sound or silence, droplets splashing off the ground or not, and ice or snow accumulating or not all work properly. It just may look like it still is raining or snowing or not where it shouldn't until Jeb hopefully fixes this bug.
I wrote this in C#, mostly for the sake of still using my main single player world I created back during Beta 1.2. Hopefully people will find the program useful, or at lest parts of its source code for use in other projects.
The code under the project "Minecraft" are a few classes copied in part or entirely from decompiled sources for Minecraft Beta 1.7.3. Along with a C# implementation of Java's random number generator, that is what I use to determine the temperature, humidity, and therefore biome for a seed and set of coordinates.
Anyone should feel free to reuse any of the code under the main project, "MinecraftRetroBiomes", if you find any part of it useful. If you really need me to, I can slap whatever license you want on any part of it.
Useful information for anyone developing tools that need to work with the new save format:
The format for the region file and chunk headers and compression of the individual chunks doesn't seem to have changed. To read the NBT structures of decompressed chunks, however, you'll need to add support for a new tag type, #11: TAG_Int_Array.
With the "Biomes" TAG_Byte_Array for each chunk, it's 256 bytes long and can be indexed as [x + z * 16] for x and z each being 0-15. As for what byte value means what biome:
I grabbed the source and modified it for my needs. I needed to take a map (my Pokemon map actually), convert the entire map into one biome (Forest), then change some select chunks into Desert and Ice Plains.
I call it BiomeEdit. It works similarly to Minecraft Retro Biomes, but it doesn't have anything to do with pre-1.8, seeds, or combining new biomes anymore. It reads a list of chunk ranges from biomes.txt and sets those chunks to a given biome. If biomes.txt includes the line "default=4" (or any other biome id), it'll set the rest of the world to that biome as well. Otherwise, it'll only change the biome for the chunks you specify in biomes.txt.
A typical chunk entry looks like:
x=4 z=5,10 biome=2
The x, z, and biome parameters can be in any order, and the coordinates can be either a single number, or a comma-separated range. That line would change chunks 4,5 through 4,10 to 2 (Desert). You can combine multiple entries to create non-rectangular areas, but there's no way to change the biome of each individual block in a chunk (yet).
I found that the easiest way to figure out the coordinates of the chunks you need to change is:
EITHER run the map with Bukkit + WorldEdit, stand in the desired chunk and type /chunkinfo
THEN you should be able to figure out the range of chunks, getting the coordinates of nearby chunks if necessary.
MCEdit and its Chunk View can be very useful, but only if you have a pre-Anvil copy of your world (MCEdit doesn't open Anvil worlds yet). It doesn't show chunk coordinates, but once you get the coordinate of one chunk (using one of the above methods), you can figure out the range of chunks pretty easily
I also made some minor changes to output, layout, etc., made it only load the region files that contain the chunks selected, and made it only save a region file if any biome data in it was actually changed (saving region files is the vast majority of the time it takes to run, and it's unnecessary if no biomes were altered). I also gave it a crappy icon.
I can't thank you enough for the source code, I've been wanting to write a tool like this but I didn't want to write the backend for reading the region files.
I don't take credit for any part of the program except my additions, and it still belongs to 31stCenturyMatt. I figured somebody might find my fork of it useful, so that's why I'm sharing it.
AS BEFORE, PLEASE BACK UP YOUR WORLD BEFORE YOU MODIFY IT WITH THIS PROGRAM. if the program crashes or is closed partway through the conversion, corruption is easily possible, especially if you interrupt it during a region save.
Any chance of a version of this that supports the 1.0/1.1 biome algorithm?
I'm a coder so I'd be happy to work on it but I don't know the first thing about extracting / decompiling the appropriate classes from 1.1. If we had algorithms from multiple versions of the game then you could pick the one you wanted.