I normally play on the 'Java Edition' and have written some command block creations for it, but since the Better Together update just came out, I've decided to check out the Win10 version of the game.
With the Java Edition, you can have a command block summon a falling_sand entity that becomes another block, and by having other falling sand entities rising the first one as passengers, you can spawn and activate multiple command blocks from an initial command block.
Looking at the Win10 version of the game, command blocks and even most of the commands I'm used to exist and work, however, the summon command doesn't list falling_sand as a spawnable entity.
Questions:
1. Is it possible to spawn a falling sand entity in the Win10 / Better Together version?
2. If not, then how does falling sand work in this version of the game?
3. If falling sand isn't spawnable, is there a different way to create 'one command block' commands that create multiple command blocks to implement changes in the game?
Thanks for any help you can provide!
FYI, I have a utility that imports .schematics files into Java Minecraft using only command blocks that I'm hoping to update to support Better Together, assuming I can find a way to have one command block run multiple commands.
If the intent is that players not be able to write command into books, then the UI should be preventing that (by not accepting JSON, or at least interpreting what was typed as plain text and encoding it as JSON when the book is signed).
Preventing a command from creating an object (writable book with two lines of text with enter pressed between them) that is simple for the player to create sounds like the wrong fix to me. If anything, commands run from command block, or functions or from the console should allow creation of at least all normal in game objects, if not items more powerful than normal (Sword with sharpness 10, for example).
It the text of the writable_book was stored as JSON tellraw format, I don't see how this would allow the player to write commands. If the player tried to write '{text:"some stuff here"}' then the JSON should look like '{text:"{text:\"some stuff here\"}"}', and it would be double encoded and not interpret what the player typed as commands.
You can created a writable book (book and quill) and put in two lines of text in it and then put it in a chest, but not be able to use a setblock command to create the same thing.
However, change it to a written book (uneditable), and you can create in game, and created it with a setblock command.
To me, either of these should work. The first uses the tellraw format for the book pages, while the second uses a plain string.
What results is a chest containing a book, but the first command the tellraw format is just right there on the book's page, with the \\n displaying as a backslash followed by an 'n' . The second example results in a similar book, the the \\n appearing as \n in the book. However, trying to use \n instead of \\n in the commands results in the error I initially posted about.
So it seams to me that parsing of \\n is inconsistent, and sometimes it seems like it is decoding the \\ to a \ first.
Any idea how to get this setblock version working? Thanks.
I'm working on a rather complex utility that generates structures using command block, but the issue I'm currently having is how to use a command that creates a book that has new new line characters (blank lines) in the text.
However, when I enter that command into chat while in creative mode in 1.12, I get the following error:
Data tag parsing failed: Invalid escape of 'n' at:
...hor:"test",pages:["{text:\"Line\n<--[HERE]
Anyone know if and how it is possible to spawn a book with commands that has a blank lines (newline character) in 1.12? Or should the bug I linked be re-opened?
The current Dwarf Fortress version's levels typically have more than 128 levels, and if you attempted to do the same type of conversion where each 3x3x3 section became one tile in dwarf fortress, you would wind up with only 42 layers. Many formations in minecraft wouldn't make sense in dwarf fortress using such a conversion; how should a 3x3x3 area with the bottom 2 layers full of dirt and the top open be converted? To a wall or a floor?
However, a 1:1 conversion could be possible, where each block in minecraft would be converted to 1 tile in Dwarf Fortress. The 128 layers would be no problem (most fortresses have at least that many), but the size north-south and east-west would have to be limited to less than about 512 blocks or so (512 would be about an 11x11 embark size in Dwarf Fortress, where 4x4 is the default).
For 1:1, if the block is there, it is a wall in Dwarf Fortress, if not, it would be an empty block, unless there is a block below, in which case this tile would be a floor. Stairs in Dwarf Fortress could be generated from ladders. You could then either leave the fortress 'blocky', or convert tiles at the edges of a layer to ramps, if the layer below has material.
You could either convert everything to a few basic materials (rock to granite, iron ore to magnetite, diamond ore to diamond gems, etc.) or try to randomize it a bit (although working with veins in DF is a bit complex). Plant life wouldn't be too bad except for trees, which are out of scale with the rest of the conversion (you would probably just convert a log on top of dirt or stone to a tree / towercap in DF, and ignore the rest of the tree).
So, I guess it is possible, but I'm not going to do it. :wink.gif:
I'm actually not loading the DF save file; I don't think anyone outside of Toady One knows it's format. I'm using a utility written by the community called DFHack which actually hooks in to DF's memory, pauses DF, then reads out data from various memory locations where information about the level and the items and creatures in the level are stored. Using this data, I then do the conversion and write out a Minecraft save file/directory, as Notch has released the information on how to write a valid save file for Minecraft.
this looks really nice so far, the only problem I've noticed is that the converter thinks it's a good idea to replace whole layers with bedrock ( :opblock:).
Well, that may be a few thing at work here.
1. You may have has the conversions setup so the level shown in the DF screenshot is the bottom level in in the conversion. A layer of 'Adminium' is placed at the bottom of the converted area to prevent you from falling out.
2. The layer in the DF screenshot is not the bottom most layer in the conversion, however there are no other interesting layers or cave layers below you. The 'smart' conversion setting (the default) tries to get the cave layers in the .31 DF line closer to the surface, so they are more easily explorable. In .28 most fortresses were 15 layers above the highest ground level and 15 layer below the lowest ground level (although I've seen fortresses approach 100 layers in mountain regions). In DF .31, fortress typically have 150 or more layers that can be dug through. Because Minecraft only has 128 layers, and each DF layer is converted to 3 Minecraft layers, only 42 layers can be converted from DF at one time. Because not all the layer can be converted over, the 'smart' routine picks the top 39 (or so) layers that have walkable floor, leaving 3 (or so, it is settable) layers if you want to build higher in Minecraft. It does this by removing layers that don't have ant floor or ramps (layers with only solid wall, open spaces or stairs), this has the effect of raising the caves to a higher location in the ground, usually making the first level of caves fully explorable and sometime even the second layer is partially explorable. In your case, this may have cause the 'hidden fun stuff' which is also build out of the unbreakable admin blocks, to be raised to just below the surface level.
In either case, you can control the conversion by opening the settings fiel in a text edit editor such as notepad. There you can control the area of the fortress that gets converted, or change the method for removing layers to turn off 'smart' mode, and switch to the 'top' X layers or specify the range of layers that should be used.
[*:2zsatkx9]Uses DFHack, 0.5.0.2, so supports .13.16 on Window
[*:2zsatkx9]Directional buildings: buildings can be different shapes depending on surrounding building or surrounding walls; the no longer always have to face north. Chairs face tables or away from walls. Torches are placed on the sides of adjacent walls.
[*:2zsatkx9]Directional Walls: Diagonal hallways are now navigable in MineCraft. Corners are kept square unless it would block a diagonal hall, in which case only the corner blocks are removed to allow passage (making diagonal hallways width vary from two to three blocks wide diagonally).
[*:2zsatkx9]New Object / Material system defines object shapes separately from the material definitions, so now objects are 'carves' out of solid blocks of material.
This means that now I have unique definitions for every Stone, Ore, Soil, Sand, Metal Bar, and several other objects (potash, coal, etc.) Gems also have the correct color and you can tell their worth (Ornamental, semi-presious, precious, rare) just from looking at them (more info than DF will give you without using loo(k) ), although gems of the same color and worth are converted identically currently (although you should be able to tell many apart from the stone they are in. All materials attempt to replicate the color of the object in DF.
For Stone, the center block of each face indicates the rock 'class' (Sedementary = Rock, Igneous = Obsidian, Metamorphic = Cobble). Vein stone are similar to the layer stones
in which they are found, varying only by the corners.
Metals: 'Monitary' metals are mostly gold blocks, where as usefull metals are mostly iron blocks. Pure metals have top and bottom layers of only Iron or Gold blocks, their center layers being different, while Alloy metals have a different blocks in their top and bottom layers as well. Admantine is made out of all Diamond Blocks, its ore is pure Redstone.
Ores have a similar system. The more usefull ores have more iron in them where the more valuable ones have more gold.
Constructed stone walls should have a cobble center (natural is a smooth rock center), but this isn't apparent without breaking things.
In general, diamond, redstone and gold ore, if seen in the corners of of a block are used to indicate blue, red and yellow coloration respectively, and aren't necessarily indication the DF block is an ore. Occasionally redstone and diamond are used together to indicate purple, kimberlite being an example.
With the new material system, sand and gravel are used for various sands (together and separtely) and gravel is also used in various ashes (ash, potash, etc.). However, this causes issues if you have such material over an open space (as sand and gravel are the only materials that fall if air is below them). There is now an option (default on) to replace sand and gravel in such situations with dirt. (I also originaly had the soil 'peat' made out of dirt and leaves, but that caused other problems with most of the leaves disappearing or turning into saplings. This is also the reason green glass uses mossy cobble instead of leaves).
Additionally, I've improved performance in fortresses that have a large number of constructions. For me Flarechannel now completes in under an hour rather than the 'almost one whole day' that it took previously (I'm no longer looping through all the constructions to find the construction for the current location, I'm looking it up in a map based on position, a big speedup when your fortress has 300,000+ constructions like Flarechannel does).
Speaking of Flarechannel, some screenshots:
The above were all done a few days ago when glass was not converting correctly. Here is a shot of inner keep's green glass, microcline (blueish stone) and orthoclass (yellowish stone) floor:
This was a lot of work, and not as easy as I originally though it was going to be. Mostly as there are more materials than I thought there were, and that I've have to define each material multiple times. For example, gems are typically 'vein' material. However, you you mine the gem, and have a 'gem floor' that later gets covered by mud, if a plant grows there, the gem floor's basic material is then reported as soil, because of the plant is growing there. I'm not sure the circumstance, but at lest one fortress show some gems basic material as Obsidian (maybe the gems were in an obsidian layer). Materials used in a construction aren't report the same as as the same material unmined, ans it could be in the form of stone, block, boar or logs. So, most materials are defined at least three times, and some are defined 4 times.
Additionally, many material names aren't consistent with how they are displayed in games. For example, opal gems are reported as opal_<type> but are displayed as <Type> Opal in game. This is due to how they are define in the raws. In most cases, I have both versions defined in the settings file.
Well, it's been over a month, but this release has a lot of good features. I'm probably missing a few rare materials, so there may be a few small fixes soon, but the next major release probably won't be until after the Halloween Minecraft Update, to take advantage of things added then, such as biomes or new block types.
I have most of the feature that I wanted in the code now that are possible to do (DFHack doesn't really support items yet or location names). If you have any ideas for features or improvements, mention them and I'll see if I can implement them.
The version you have turn all 'vein' material into a mix of coal, iron gold, redstone, and one diamond ore. 'Vein' material in DF is anything that is not a 'layer stone' in this list: http://df.magmawiki.com/index.php/DF201 ... de_to_Rock
I'm working on an update that will allow you to do one of two things.
1. material correct replacement: replace all iron ores with iron ore in Minecraft, gold veins with gold ore, gems with diamond ore, etc.
2. color based replacement. This is more appropriate for people who have made impressive fortresses in Dwarf Fortress, and want to see how they look in 3D. This will attempt to preserve as much as possible the material color of the stones used in Dwarf Fortress. This was you you used microline and orthoclass in DF to make blue and yellow patterned buildings, they should be appear that way in Minecraft (using gold and diamond ore).
The next update will also have 'buildings' (chairs, chests, doors, etc. ) that are more sensible, being fit better to the surrounding objects. Doors will fit into walls without the 'extra' doors that are there currently. Chairs will face tables they are next to, or away from walls if they are next to a wall. Chests and cabinets will be along walls. Torches will be placed on walls if a tile next to a wall is chosen for the torch.
I'll hopefully have it done by this weekend, I just have to fix some strange interactions with buildings and the new material system.
Anyway, I have most of the new code ready for easier / proper material conversion in, but buildings aren't quite right as the parts that are supposed to be made out of a specific material aren't showing up at all. I'll have to fix that tonight. Then I still have to come up with decent conversion for the stone and soil types in Dwarf Fortress, but that shouldn't take too long. I'm not gong to have different wood types, as there is only really one type of wood boards in Minecraft, but if someone else want to do it (maybe using chests or record players for different wood types), you can just modify the settings file.
I had previously created a thread for my Dwarf Fortress to Minecraft conversion utility ( viewtopic.php?f=25&t=27744 ), but it always seemed to slip off the first page of this forum as this modding forum is rather active.
As there didn't seem to be as much interest here as there has been in the Dwarf Fortress forum thread, I've been mostly posting updated there, and only updating the thread here when I would make a release.
Anyway, I'm currently reworking the code to separate out the definition of the tile shape from the definition of the material. This way, one section of the setting file can define how all the different materials in Dwarf Fortress should be converted to Minecraft . For example, I'll be able to define olvine as a 3x3x3 block of stone with some mossy cobble for the green coloration, and cinnabar as as a 3x3x3 block of stone with some redstone ore (or maybe bricks) blocks for the red coloration. The program will then take the material, and carve out of it the shape that it needs, be that a wall, a ramp, a floor, or a building. This will be much easier that the current system, where you would need to a version of each object made out of a particular material separately.
Also, I want to upgrade to the latest version of the DFHack library to read the data from Dwarf Fortress, but only if they can get it working with the newly released DF updated (which it currently doesn't work for on Windows). Hopefully I'll have a new release ready with a new release by the middle of next week.
I've just released the latest version of DF2MC that converts Dwarf Fortress levels into Minecraft maps. Now with ALPHA support and (nearly) properly lighting!
Limitations:
The conversion converts each square in Dwarf Fortress into a 3x3 block of cubes in Minecraft. Because of this, only 42 levels can be converted at once. For most of the examples, I use a 'smart' mode that removes layers that don't have 'explorable' space, which causes the caves to be closer to the surface to be included in the converted region. Building are converted, but things like tables chairs and doors don't have a direction (yet), and so may appear somewhat awkwardly.
I have to give a big thanks to codewarrior, author of MCEdit, for help in diagnosing issues in my save routine and explaining how to do proper lighting. I'd still be trying to figure out what was wrong with my alpha saves without his help!
Take a look at the example maps, or try some conversions yourself and tell me what you think!
I've found the problem in my code with the height map not writing to the correct position in the array.
Yes the player position is not in the area output by my program, I'll have to fix that. It is a result of a last minute attempt at a fix (I originally was outputting from 0,0 in the positive X but negative Z direction).
How would I go about calculating the light (skylight or block light)? None of the descriptions that I found for the save formatting described the light calculation (except for the wiki's mention of each chunk's 'TerrainPopulated' tag, which I am setting to false). Hopefully this is the last hurdle to getting a working alpha level output.
0
Hi,
I normally play on the 'Java Edition' and have written some command block creations for it, but since the Better Together update just came out, I've decided to check out the Win10 version of the game.
With the Java Edition, you can have a command block summon a falling_sand entity that becomes another block, and by having other falling sand entities rising the first one as passengers, you can spawn and activate multiple command blocks from an initial command block.
Looking at the Win10 version of the game, command blocks and even most of the commands I'm used to exist and work, however, the summon command doesn't list falling_sand as a spawnable entity.
Questions:
1. Is it possible to spawn a falling sand entity in the Win10 / Better Together version?
2. If not, then how does falling sand work in this version of the game?
3. If falling sand isn't spawnable, is there a different way to create 'one command block' commands that create multiple command blocks to implement changes in the game?
Thanks for any help you can provide!
FYI, I have a utility that imports .schematics files into Java Minecraft using only command blocks that I'm hoping to update to support Better Together, assuming I can find a way to have one command block run multiple commands.
0
If the intent is that players not be able to write command into books, then the UI should be preventing that (by not accepting JSON, or at least interpreting what was typed as plain text and encoding it as JSON when the book is signed).
Preventing a command from creating an object (writable book with two lines of text with enter pressed between them) that is simple for the player to create sounds like the wrong fix to me. If anything, commands run from command block, or functions or from the console should allow creation of at least all normal in game objects, if not items more powerful than normal (Sword with sharpness 10, for example).
It the text of the writable_book was stored as JSON tellraw format, I don't see how this would allow the player to write commands. If the player tried to write '{text:"some stuff here"}' then the JSON should look like '{text:"{text:\"some stuff here\"}"}', and it would be double encoded and not interpret what the player typed as commands.
0
Ok, interesting.
I would consider that a bug in the game.
You can created a writable book (book and quill) and put in two lines of text in it and then put it in a chest, but not be able to use a setblock command to create the same thing.
However, change it to a written book (uneditable), and you can create in game, and created it with a setblock command.
Thanks for your help!
0
ok, now I'm confused.
While the /give command above seemed to work, using a /setblock command doesn't
/setblock ~1 ~ ~2 chest 3 replace {Items:[{Slot:13,id:"minecraft:writable_book",Count:1,tag:{pages:["{text:\"Line 1\\nLine 2\"}"]}}]}
/setblock ~1 ~ ~2 chest 3 replace {Items:[{Slot:13,id:"minecraft:writable_book",Count:1,tag:{pages:["Line 1\\nLine 2"]}}]}
To me, either of these should work. The first uses the tellraw format for the book pages, while the second uses a plain string.
What results is a chest containing a book, but the first command the tellraw format is just right there on the book's page, with the \\n displaying as a backslash followed by an 'n' . The second example results in a similar book, the the \\n appearing as \n in the book. However, trying to use \n instead of \\n in the commands results in the error I initially posted about.
So it seams to me that parsing of \\n is inconsistent, and sometimes it seems like it is decoding the \\ to a \ first.
Any idea how to get this setblock version working? Thanks.
0
Thanks, that works perfectly!
/give @a written_book 1 0 {title:"Test",author:"test",pages:["{text:\"Line 1\\nLine 2\"}"]}
0
Hi,
I'm working on a rather complex utility that generates structures using command block, but the issue I'm currently having is how to use a command that creates a book that has new new line characters (blank lines) in the text.
I ran across this bug: https://bugs.mojang.com/browse/MC-52919
The suggestion there is to use a command like:
/give @a written_book 1 0 {title:"Test",author:"test",pages:["{text:\"Line 1\nLine 2\"}"]}However, when I enter that command into chat while in creative mode in 1.12, I get the following error:
Anyone know if and how it is possible to spawn a book with commands that has a blank lines (newline character) in 1.12? Or should the bug I linked be re-opened?
0
The current Dwarf Fortress version's levels typically have more than 128 levels, and if you attempted to do the same type of conversion where each 3x3x3 section became one tile in dwarf fortress, you would wind up with only 42 layers. Many formations in minecraft wouldn't make sense in dwarf fortress using such a conversion; how should a 3x3x3 area with the bottom 2 layers full of dirt and the top open be converted? To a wall or a floor?
However, a 1:1 conversion could be possible, where each block in minecraft would be converted to 1 tile in Dwarf Fortress. The 128 layers would be no problem (most fortresses have at least that many), but the size north-south and east-west would have to be limited to less than about 512 blocks or so (512 would be about an 11x11 embark size in Dwarf Fortress, where 4x4 is the default).
For 1:1, if the block is there, it is a wall in Dwarf Fortress, if not, it would be an empty block, unless there is a block below, in which case this tile would be a floor. Stairs in Dwarf Fortress could be generated from ladders. You could then either leave the fortress 'blocky', or convert tiles at the edges of a layer to ramps, if the layer below has material.
You could either convert everything to a few basic materials (rock to granite, iron ore to magnetite, diamond ore to diamond gems, etc.) or try to randomize it a bit (although working with veins in DF is a bit complex). Plant life wouldn't be too bad except for trees, which are out of scale with the rest of the conversion (you would probably just convert a log on top of dirt or stone to a tree / towercap in DF, and ignore the rest of the tree).
So, I guess it is possible, but I'm not going to do it. :wink.gif:
I'm actually not loading the DF save file; I don't think anyone outside of Toady One knows it's format. I'm using a utility written by the community called DFHack which actually hooks in to DF's memory, pauses DF, then reads out data from various memory locations where information about the level and the items and creatures in the level are stored. Using this data, I then do the conversion and write out a Minecraft save file/directory, as Notch has released the information on how to write a valid save file for Minecraft.
0
Well, that may be a few thing at work here.
1. You may have has the conversions setup so the level shown in the DF screenshot is the bottom level in in the conversion. A layer of 'Adminium' is placed at the bottom of the converted area to prevent you from falling out.
2. The layer in the DF screenshot is not the bottom most layer in the conversion, however there are no other interesting layers or cave layers below you. The 'smart' conversion setting (the default) tries to get the cave layers in the .31 DF line closer to the surface, so they are more easily explorable. In .28 most fortresses were 15 layers above the highest ground level and 15 layer below the lowest ground level (although I've seen fortresses approach 100 layers in mountain regions). In DF .31, fortress typically have 150 or more layers that can be dug through. Because Minecraft only has 128 layers, and each DF layer is converted to 3 Minecraft layers, only 42 layers can be converted from DF at one time. Because not all the layer can be converted over, the 'smart' routine picks the top 39 (or so) layers that have walkable floor, leaving 3 (or so, it is settable) layers if you want to build higher in Minecraft. It does this by removing layers that don't have ant floor or ramps (layers with only solid wall, open spaces or stairs), this has the effect of raising the caves to a higher location in the ground, usually making the first level of caves fully explorable and sometime even the second layer is partially explorable. In your case, this may have cause the 'hidden fun stuff' which is also build out of the unbreakable admin blocks, to be raised to just below the surface level.
In either case, you can control the conversion by opening the settings fiel in a text edit editor such as notepad. There you can control the area of the fortress that gets converted, or change the method for removing layers to turn off 'smart' mode, and switch to the 'top' X layers or specify the range of layers that should be used.
0
Download: http://github.com/TroZ/DF2MC/downloads
New features:
[*:2zsatkx9]Uses DFHack, 0.5.0.2, so supports .13.16 on Window
[*:2zsatkx9]Directional buildings: buildings can be different shapes depending on surrounding building or surrounding walls; the no longer always have to face north. Chairs face tables or away from walls. Torches are placed on the sides of adjacent walls.
[*:2zsatkx9]Directional Walls: Diagonal hallways are now navigable in MineCraft. Corners are kept square unless it would block a diagonal hall, in which case only the corner blocks are removed to allow passage (making diagonal hallways width vary from two to three blocks wide diagonally).
[*:2zsatkx9]New Object / Material system defines object shapes separately from the material definitions, so now objects are 'carves' out of solid blocks of material.
This means that now I have unique definitions for every Stone, Ore, Soil, Sand, Metal Bar, and several other objects (potash, coal, etc.) Gems also have the correct color and you can tell their worth (Ornamental, semi-presious, precious, rare) just from looking at them (more info than DF will give you without using loo(k) ), although gems of the same color and worth are converted identically currently (although you should be able to tell many apart from the stone they are in. All materials attempt to replicate the color of the object in DF.
For Stone, the center block of each face indicates the rock 'class' (Sedementary = Rock, Igneous = Obsidian, Metamorphic = Cobble). Vein stone are similar to the layer stones
in which they are found, varying only by the corners.
Metals: 'Monitary' metals are mostly gold blocks, where as usefull metals are mostly iron blocks. Pure metals have top and bottom layers of only Iron or Gold blocks, their center layers being different, while Alloy metals have a different blocks in their top and bottom layers as well. Admantine is made out of all Diamond Blocks, its ore is pure Redstone.
Ores have a similar system. The more usefull ores have more iron in them where the more valuable ones have more gold.
Constructed stone walls should have a cobble center (natural is a smooth rock center), but this isn't apparent without breaking things.
In general, diamond, redstone and gold ore, if seen in the corners of of a block are used to indicate blue, red and yellow coloration respectively, and aren't necessarily indication the DF block is an ore. Occasionally redstone and diamond are used together to indicate purple, kimberlite being an example.
With the new material system, sand and gravel are used for various sands (together and separtely) and gravel is also used in various ashes (ash, potash, etc.). However, this causes issues if you have such material over an open space (as sand and gravel are the only materials that fall if air is below them). There is now an option (default on) to replace sand and gravel in such situations with dirt. (I also originaly had the soil 'peat' made out of dirt and leaves, but that caused other problems with most of the leaves disappearing or turning into saplings. This is also the reason green glass uses mossy cobble instead of leaves).
Additionally, I've improved performance in fortresses that have a large number of constructions. For me Flarechannel now completes in under an hour rather than the 'almost one whole day' that it took previously (I'm no longer looping through all the constructions to find the construction for the current location, I'm looking it up in a map based on position, a big speedup when your fortress has 300,000+ constructions like Flarechannel does).
Speaking of Flarechannel, some screenshots:
The above were all done a few days ago when glass was not converting correctly. Here is a shot of inner keep's green glass, microcline (blueish stone) and orthoclass (yellowish stone) floor:
A map of the fortress, for comparison is available here:
http://mkv25.net/dfma/map-7268-flarechannel
And this is the save file I converted from:
http://dffd.wimbli.com/file.php?id=1817
Converted Fortress:
http://troz.shackspace.com/minecraft/df2mc/flarechannel/Flarechannel.rar
This was a lot of work, and not as easy as I originally though it was going to be. Mostly as there are more materials than I thought there were, and that I've have to define each material multiple times. For example, gems are typically 'vein' material. However, you you mine the gem, and have a 'gem floor' that later gets covered by mud, if a plant grows there, the gem floor's basic material is then reported as soil, because of the plant is growing there. I'm not sure the circumstance, but at lest one fortress show some gems basic material as Obsidian (maybe the gems were in an obsidian layer). Materials used in a construction aren't report the same as as the same material unmined, ans it could be in the form of stone, block, boar or logs. So, most materials are defined at least three times, and some are defined 4 times.
Additionally, many material names aren't consistent with how they are displayed in games. For example, opal gems are reported as opal_<type> but are displayed as <Type> Opal in game. This is due to how they are define in the raws. In most cases, I have both versions defined in the settings file.
Well, it's been over a month, but this release has a lot of good features. I'm probably missing a few rare materials, so there may be a few small fixes soon, but the next major release probably won't be until after the Halloween Minecraft Update, to take advantage of things added then, such as biomes or new block types.
I have most of the feature that I wanted in the code now that are possible to do (DFHack doesn't really support items yet or location names). If you have any ideas for features or improvements, mention them and I'll see if I can implement them.
0
The version you have turn all 'vein' material into a mix of coal, iron gold, redstone, and one diamond ore. 'Vein' material in DF is anything that is not a 'layer stone' in this list: http://df.magmawiki.com/index.php/DF201 ... de_to_Rock
I'm working on an update that will allow you to do one of two things.
1. material correct replacement: replace all iron ores with iron ore in Minecraft, gold veins with gold ore, gems with diamond ore, etc.
2. color based replacement. This is more appropriate for people who have made impressive fortresses in Dwarf Fortress, and want to see how they look in 3D. This will attempt to preserve as much as possible the material color of the stones used in Dwarf Fortress. This was you you used microline and orthoclass in DF to make blue and yellow patterned buildings, they should be appear that way in Minecraft (using gold and diamond ore).
The next update will also have 'buildings' (chairs, chests, doors, etc. ) that are more sensible, being fit better to the surrounding objects. Doors will fit into walls without the 'extra' doors that are there currently. Chairs will face tables they are next to, or away from walls if they are next to a wall. Chests and cabinets will be along walls. Torches will be placed on walls if a tile next to a wall is chosen for the torch.
I'll hopefully have it done by this weekend, I just have to fix some strange interactions with buildings and the new material system.
0
http://www.indiegames.com/blog/2010/09/ ... inecr.html
It's mentioned at be beginning, about 4:45 in.
Anyway, I have most of the new code ready for easier / proper material conversion in, but buildings aren't quite right as the parts that are supposed to be made out of a specific material aren't showing up at all. I'll have to fix that tonight. Then I still have to come up with decent conversion for the stone and soil types in Dwarf Fortress, but that shouldn't take too long. I'm not gong to have different wood types, as there is only really one type of wood boards in Minecraft, but if someone else want to do it (maybe using chests or record players for different wood types), you can just modify the settings file.
0
I had previously created a thread for my Dwarf Fortress to Minecraft conversion utility ( viewtopic.php?f=25&t=27744 ), but it always seemed to slip off the first page of this forum as this modding forum is rather active.
As there didn't seem to be as much interest here as there has been in the Dwarf Fortress forum thread, I've been mostly posting updated there, and only updating the thread here when I would make a release.
Anyway, I'm currently reworking the code to separate out the definition of the tile shape from the definition of the material. This way, one section of the setting file can define how all the different materials in Dwarf Fortress should be converted to Minecraft . For example, I'll be able to define olvine as a 3x3x3 block of stone with some mossy cobble for the green coloration, and cinnabar as as a 3x3x3 block of stone with some redstone ore (or maybe bricks) blocks for the red coloration. The program will then take the material, and carve out of it the shape that it needs, be that a wall, a ramp, a floor, or a building. This will be much easier that the current system, where you would need to a version of each object made out of a particular material separately.
Also, I want to upgrade to the latest version of the DFHack library to read the data from Dwarf Fortress, but only if they can get it working with the newly released DF updated (which it currently doesn't work for on Windows). Hopefully I'll have a new release ready with a new release by the middle of next week.
0
Download converter: http://github.com/TroZ/DF2MC/downloads
Example output (4-6 fortresses per rar, except Flarechannel):
http://troz.shackspace.com/minecraft/df ... resses.rar
http://troz.shackspace.com/minecraft/df ... orts31.rar
http://troz.shackspace.com/minecraft/df ... rts40d.rar
http://troz.shackspace.com/minecraft/df ... hannel.rar
warning: some fortresses are prepared to self-grief, with lava (in smelters/furnaces) close to wood or ice (Roadraced and Frozenhalls in particular).
Maps for my fortresses can be found here: http://mkv25.net/dfma/usermaps.php?sear ... rch=Search
Undergrotto is split into 3 parts (42 layer limit, it has 99) - 1 is the top 42 levels, 2 is from ground level up, 3 is the bottom 42 levels.
Flarechannel is the top 42 layers, still working on the conversion of the bottom. For some reason it take hours to convert this game, while other take less than 10 minutes.
Limitations:
The conversion converts each square in Dwarf Fortress into a 3x3 block of cubes in Minecraft. Because of this, only 42 levels can be converted at once. For most of the examples, I use a 'smart' mode that removes layers that don't have 'explorable' space, which causes the caves to be closer to the surface to be included in the converted region. Building are converted, but things like tables chairs and doors don't have a direction (yet), and so may appear somewhat awkwardly.
I have to give a big thanks to codewarrior, author of MCEdit, for help in diagnosing issues in my save routine and explaining how to do proper lighting. I'd still be trying to figure out what was wrong with my alpha saves without his help!
Take a look at the example maps, or try some conversions yourself and tell me what you think!
0
I'll get to work on this at once.
Thanks for all the help!
0
I've found the problem in my code with the height map not writing to the correct position in the array.
Yes the player position is not in the area output by my program, I'll have to fix that. It is a result of a last minute attempt at a fix (I originally was outputting from 0,0 in the positive X but negative Z direction).
How would I go about calculating the light (skylight or block light)? None of the descriptions that I found for the save formatting described the light calculation (except for the wiki's mention of each chunk's 'TerrainPopulated' tag, which I am setting to false). Hopefully this is the last hurdle to getting a working alpha level output.