Wow - Impressive fortress Japa!
This program works by converting each square in Dwarf Fortress into a NxNxN group of cubes in Minecraft.
It first reads the tile type (floor, wall, ramp, tree, shrub, etc.) and material (stone/dirt type - marble, slate, obsidian, etc. - or for constructions the type (bar/block/log) and specific material), does a look up into the xml file for the conversion, and writes those blocks into the minecraft map it is building in memory.
Then it reads the building that is there (if one is there), does a look up for the conversion, and writes those blocks ONLY into air blocks - it won't overwrite non-air blocks.
Then it looks if the block has some liquid - water or magma - and does a look up to convert that level of liquid into minecraft blocks - and again will only write those blocks into air/empty blocks. This is so that a mined out area with a workshop that is flooded will still have the floor and workshop there, with the water filling the remaining air spaces
Finally, if the area is 'Dark', 'Inside', or 'Subterranean', and not covered with spatter (mostly for muddy caverns, which should remain dark) there is a chance a torch will be added to the location. This is the only random part of the conversion. Without torches being added, the insides of fortresses would be completely dark in Minecraft, but adding a torch to the floor tile by default would make outside areas and caves have torches when they shouldn't.
As for part of the map being 'cut off' - that is somewhat intentional, but controllable. The top of the settings file contains settings for limiting the area of the map output. While testing, I found that larger maps caused Minecraft Indev to crash. The Indev applet is limited to 256MB of ram, and maps larger than 512x512x128 seems to cause it to use too much memory.
In DF, each 'box' in the embark screen seems to be 48x48 by ? layers tall, or 3x3 'blocks; of 16x16 squares, which translates to 144x144 minecraft blocks. So you can output a bit larger than a 3x3 embark area without issue in my experience.
Additionally, using the default settings file which converts each square to a 3x3x3 group of cubes, you can get 42 layers output. The default setting is to find the top (largest Z) 39 interesting layers, and 3 empty air layers above them. 'Interesting' is defined as layers that have a floor, ramp, ramp top, pillar or fortification. Layers of just walls or stairs are discarded. The purpose of this is to 'compress' those tall stairs to the caves, raising the caves closer to the surface, so that they can be explored in minecraft. I all of my test fortresses, the first level of caves can be fully explored, and one of the test fortresses, a second layer of caves can be partially explored before the bottom of the minecaft level.
Choosing the spawn point from the cursor position is a good idea, and I'll hopefully have it implemented this weekend. I'll have to check that it is in the area being output, and use the center anyway if it isn't, but it sounds like a good solution to that problem. Hopefully I understand enough about how the spawn point is saved to safely place the spawn in a mined out area without placing you in a wall or floor (which did happen at one point in early testing).
G-Flex:
As stated above, each square in minecraft is converted to a NxNxN group of cubes. The size of N and the conversion for the DF location to the MC group of cubes is stores in a settings.xml file. The default file has N set at 3, wich is the smallest practical value.
That is the bottom layer of cubes represents the floor, and then two layers of cubes for air 'walking space' (you are 2 cubes high in minecraft), or that will be filled in if the wall hasn't been mined out yet. Workshops and other items also have to fill this 2 cube high space (hence the road problem for indoor roads [I never considered building roads indoors, only outside to prevent trees from growing and blocking access to the Depot]).
Other sizes besides 3x3x3 are possible (but untested as of yet). 4x4x4 would fix the indoor road problem, as you could have 1 layer for the floor and 3 of air, so the 1/2 high road tile would still leave room to walk. A 5x5x5 conversion would also be interesting as you could do 2 layers for floor and 3 of air, allowing you to use sand or gravel tiles in the floor (for sand / sandy loam, etc) without the sand falling by having a layer of dirt under it (sand and gravel fall in Minecraft, most other tiles will 'float' unsupported). 5x5x5 could also solve the 'diagonal problem' (strictly diagonal hallways are passable in DF, but not once converted), by cutting off the 4 corners of a wall, without that wall then looking like a pillar or a support.
For those of you wondering about the 'floating' torches in the image - I use torches to indicate the outlines of piles in DF (all defined and changeable in the settings file). apparently piles were either defined to pass through the boundaries of the levels there, or the piles were define and the floor/walls mined out after. There is one bug that I noticed in the current version - DFHack reports piles along with buildings. But because of the way there are defined (only top left and bottom right corner supplied), it is possible to have a pile and a normal building overlap, either from having a building and defining a pile over/around it, or by have a pile, un-designating part (corner) of it, and then building a workshop / other building there. I have a fix for this which made piles not show on a particular square if an actual building is also in that location.
I'm going to more some more on this, adding the spawn fix, and hopefully getting plant types in (so that tower-cap trees don't look like above ground trees) and get a new release out this weekend. From there is it work on the lighting calculation (no idea how to do - probably will need to look at code of some minecraft level editors), or work on start on the Minecraft Alpah file save routine (which will need the proper lighting calculation eventually as it is stored as a separate field in Alaph). And maybe get to finishing Starcraft's campaign, which I put on hold to do this project
Author
Topic: DF to Minecraft utility (Read 200600 times)