Converting minecraft classic to minetest?

[Sokomine]

I'd like to import my buildings/maps from Minecraft classic into Minetest to walk around in them. The maps are up to 512 blocks in width and up to 128 blocks high. They were saved using the World of Minecraft client (called "wom"; generates level.dat files which can be decompressed with gunzip) and can be edited by open source software, e.g. mcedit. While the blocks are not identical, they are still similar enough and those missing/looking diffrent could be replaced by custom Minetest blocks from a very simple mod. Dropping sand/gravel (coud be replaced by similar looking blocks not affected by physics) or floating water/lava would destroy quite a lot of buildings.

Both file formats are accessible through open source software and Minecraft classic's blocks and abilites are a subset of Minetests. It ought to be possible. Question is: Did anyone do this yet? Is there a converter?

[sfan5]

You could convert MC Classic Levels to MT WorldEdit 0.5 Schematics with Python.
If you have Programming Experience your could write a Program yourself

[Sokomine]

Excellent! That save file format of yours is easy to read and create. Now I have to find a good description of wom's level.dat format. And...how will my computer behave if it has to insert an area of 512x512x128 blocks? (most of them air but still...). I'll ask a few questions concerning your worldedit in the right thread. It seems to be another very useful mod.
[Edit: How do I specify "air"?]

[Mito551]

could you please be more specific and describe process of convertion?

[Sokomine]

Well, WorldEdits Savefile looks like this:

Code: Select all

0 0 0 default:dirt_with_grass 0 0
0 0 1 default:dirt_with_grass 0 0
0 3 1 default:torch 0 0
0 4 0 default:cobble 0 0
0 4 1 default:cobble 0 0
1 0 0 default:dirt_with_grass 0 0
1 0 1 default:dirt_with_grass 0 0
1 4 0 default:cobble 0 0

Ok, I don't know what the two zeros at the end stand for and which coordinate is which one (will need a few simple experiments anyway - since I don't know which direction is is x,y and z ingame anyway), but they seem relative to pos1. That is a format that can be used and created by a to-be-written converter. I have no idea how it will perform. Maybe accessing Minetests sqlite-DB directly might become necessary or at least more efficient. WorldEdits format is easy to use. For now I'll have to figure out the level.dat format. If that's done and more exists I'll write it here.

[Edit] Is there a limit to the filesize for the savefiles? Writing all those names in the long version *will* take space.

[cornernote]

[Edit: How do I specify "air"?]

Leave a blank line, WE does not save air.

You can also try this if you want to force air to replace of whatever was there:

Code: Select all

0 0 0 air 0 0

[cornernote]

Ok, I don't know what the two zeros at the end stand for and which coordinate is which one

Code: Select all

x y z mod:node param1 param2
0 0 0 default:dirt_with_grass 0 0

(will need a few simple experiments anyway - since I don't know which direction is is x,y and z ingame anyway), but they seem relative to pos1.

Press F5, then watch the numbers at the top of the screen change.

[Edit] Is there a limit to the filesize for the savefiles? Writing all those names in the long version *will* take space.

Only the OS limits. And the memory limit trying to read the data into the game.

If the files are too big then you could try loading them in smaller chunks.

[sfan5]

[...]Now I have to find a good description of wom's level.dat format[...]

http://www.minecraftwiki.net/wiki/Classic_level_format

[Nexdah]

You could just do it the old fashioned way and just rebuild it.

[Sokomine]

Press F5, then watch the numbers at the top of the screen change.

Thanks! That might be helpful in regular gameplay as well :-)

@sfan5: Thanks for the link. I found that one already and eventually got to the block ids for classic. The offset where the real data starts in my files is diffrent from that given in the documentation. That may be due to a diffrent server software. I have found no pracitcal way to determine map size yet and assume for now that all maps are n^2xn^2xn^2

Even moderate sized maps contain quite some data. Most of those I'm interested in contain half dirt half air and a grass surface on which the buildings are constructed. It helps if I can ignore dirt and air. Otherwise there would be millions of blocks to insert just for a "small" 256x256x256 map. The flatland mod might be helpful there; however, I didn't get it to work.

You could just do it the old fashioned way and just rebuild it.

Um, no. Not rebuilding. It takes quite some time to construct buildings that size! Those arn't just small houses...

[Sokomine]

Importing does work to some degree. There are still some unsolved issues:

Getting a sufficiently large free flat space on a slower computer is not easy. The no_mapgen and flatland mod help a bit. Still - much ends up in the next hill (which ought not to be there) or high in the sky (at least no hills there!). I need more efficient flatland.

Dirt (without grass) and air are not copied over. This is done to limit the amount of blocks from millons to mere tens of thousands. Other maps may have diffrent requirements.

The import function plugs into worldedits import mechanism whenever there isn't a .we but a .dat file. The conversion itself is done in a function similar to worldedits deserialize. Thus worldedit doesn't have to parse a huge textfile. A better mechanism to handle the plugin would be good.

Determining the map size would be helpful. Right now I can still only detect 2^nx2^nx2^n maps. But that is not a Minetest isssue :-)

The mod does not gunzip the level.dat. That has to be done manually. Not a big issue.

Water is not very convincing. Using default:water_source after checking the "environment" might be a possibility. Unfortionately the process is already quite slow. A map with a lot of water might be problematic.

Since I created extra nodes for each block type it would be good to do so with the stairs/slab block as well (stairs:slab_stone). Ought to behave like staris:slab_stone but maybe with a diffrent picture.

Those maps are sometimes used with texture packs. All the textures together form a single image. It would be nice to be able to extract the individual block images from that png (they are at fixed positions) and generate suitable textures for Minetest from them.

[cornernote]

do you have an example world you can share so we can see the data and images?

[Sokomine]

The example world I used for testing has not been built exclusively by me so I can't share it. It is a bit difficult to find *tiny* maps (less than 64x64x64 blocks). My own map is not finished yet. I'll see what I can do to get a sufficiently small one I can build on.
A conversion tool for a texture.png (texture atlas from Minecraft or from a texture pack) is necessary since I copied all textures together from other mods for testing and can't make it available this way.

[Sokomine]

I'd like to use stairs:register_slab(..) to get a slab - but that doesn't work due to namespace conflicts since register_slab adds the staris: to the object name. Thus I had to copy the code - not a very elegant solution. Might it be possible to change that funtion in the stairs mod (part of the default game) so that it accepts a prefix for the nodename? Other mods could use the functions there as well.

Another point is that larger imported maps look...griefed. Somehow the cave algorithm seems to cut in and cut parts of buildings out. Perhaps this is due to missing (i.e. not yet generated) parts of the map.

[sfan5]

You can just convert it to a WorldEdit Schematic

[Sokomine]

Did you try to import something really huge using worldedit? Especially on a map where the blocks the building is to be copied to have not been generated so far? Worldedit is bound to have the same problems - my import function places blocks exactly the same way worldedit does (in fact it just extends worldedit). It is derived from worldedit.deserialize, but instead of parsing a text file and doing a regmatch on the string read it takes the level.dat file itself and uses string.byte to get each byte directly.
Did you get my mail where I asked if worldedit could be equipped with a mechanism to support diffrent import functions? Seems my mails do get lost quite often :-(
Anyway, the import function could use some more parameters - e.g. mapsize (cannot be determined sufficiently reliable automaticly), grass level, skip air blocks yes/no, version of water to use ("stationary"/normal) etc. Maybe I'll place them in a seperate file and read the parameters from there. That would allow including target positions and I could make it independent of worldedit (even though in a world where one imports creative maps worldedit is a must have).

[sfan5]

Did you get my mail where I asked if worldedit could be equipped with a mechanism to support diffrent import functions? Seems my mails do get lost quite often :-(.

I found it in my Spam Folder today and replied

[Sokomine]

You've got new Mail :-) This time from another adress since I can't add attachments through the forum.

[Pythagoras]

if you are concerned about file size, you could just skip saving an intermediate file. make your .dat interpreter in lua and use the worldedit coding api directly, so that for each block read from .dat your mod would directly put the according one.

[Sokomine]

I did that already (lua reads the level.dat directly and does add_node for each node), but there are still some issues keeping me from releasing the mod. The most problematic factor is that the area the classic level is to be imported into has to be loaded. Otherwise the blocks don't get placed and those that do often get griefed by mapgen when nearby not-yet-generated areas get generated. With a mini-level of 16x16x16 blocks that does not matter - but if you go up to 512x128x512 you have to walk around quite a long time to get the area generated. Even then it most likely won't be loaded completely.

One approach might be not to place the nodes line-by-line for the entire map but to seperate it into chunks that correspond vaguely to the way Minetest works internally. That is, instead of placing a line of up to 512 blocks and then continue with the next line, switching to a version that does only 16 nodes of a line and then switches to the next line and does16 nodes of that one might help a bit. Plus moving the player around like in explore_map to make sure the area is loaded.

[Pythagoras]

i also was thinking about teleporting the player when he would be out of range, then waiting a few seconds before continueing putting blocks.

[Pythagoras]

the towntest mod has a npc who builds structures. needs testing if map generation can be triggered by such a npc.
http://forum.minetest.net/viewtopic.php?id=3223

[sfan5]

I've got good news for you all.
I wrote a java program that converts minecraft classic levels into worldedit schematics.
Download: https://dl.dropbox.com/.../mcclconvert.jar
How to use it:


EDIT:
Tip: You should disable the fire mod as lava is often used together with flammable blocks
EDIT2: The world seems to be mirrored, i'll fix that
-> I fixed the problem, make sure you use MCCLConvert v02

[socramazibi]

[...]

Not working, windows 7 64bit.

[sfan5]

[...]

Not working, windows 7 64bit.

Where did you take the level.dat file from?
I tested it with files generated by the "dump map" button in the wom client.
Also, you shouldn't run a shell as an Admin, but thats your decision