bo3 Support integration for MCEdit

[Estevo-Aleixo]

Bo2/Bo3's are biome objects that are used by a variety of plugins and programs to populate worlds with everything from trees to custom buildings. The formats originally made for the old phoenix mod have been ported to implement new functionality and more customization. (block generation)

This issue is for bo3 support

bo2 parsing support was added in https://github.com/Khroki/MCEdit-Unified/pull/371 bo3 support was added [1] but was stubbed [2]

Datastructure definitons are

1. bo2: [3]
2. bo3: [4]

There are some BO3 files in issue https://github.com/Khroki/MCEdit-Unified/issues/201

[1] a406c2af4b8a91b0577f0aecc9907ab019c17de7 [2] 7ca64b97e8db668cbc9f0a1ed71ce609d75a3767 [3] http://pastebin.com/FVr9f52y [3] https://github.com/MCTCP/TerrainControl/wiki/BO3-objects

[Podshot]

For anyone who wants to tackle this: The file needs to be parsed into a schematic. The BO2 system should give a little insight into how I shifted the coordinates, because schematics can only have positive coordinates on all axis's, 0,0,0 being the lowest (coordinate-wise) corner. The commented out system might work, but there was a lot of reused code from BO2, which is probably why it had so many problems

[LaChal]

I just pushed a commit (https://github.com/Khroki/MCEdit-Unified/commit/4330ebc4eb24384cacbef3d9e5725b4da66c9f6f) which handles the Block() tags in the BO3 format.

However it was tested only with the dragonnest.bo3 found in #201. It will be usefull to have some other ones...

[Estevo-Aleixo]

here are some objects http://forum.mctcp.com/t/resources-index/18

[Estevo-Aleixo]

How should the random selection bit go? Should it just run the random algorithm on load or should we add some UI to re-roll? for example: from the RandomLoot.rar Loot-Basic.bo3

RandomBlock(0,0,0,
  CHEST,Container/BasicLoot/Basic-01.nbt,7,
  CHEST,Container/BasicLoot/Basic-02.nbt,7,
  CHEST,Container/BasicLoot/Basic-03.nbt,8,
  CHEST,Container/BasicLoot/Basic-04.nbt,8,
  CHEST,Container/BasicLoot/Basic-05.nbt,9,
  CHEST,Container/BasicLoot/Basic-06.nbt,10,
  CHEST,Container/BasicLoot/Basic-07.nbt,11,
  CHEST,Container/BasicLoot/Basic-08.nbt,12,
  CHEST,Container/BasicLoot/Basic-09.nbt,14,
  CHEST,Container/BasicLoot/Basic-10.nbt,16,
  CHEST,Container/BasicLoot/Basic-11.nbt,19,
  CHEST,Container/BasicLoot/Basic-12.nbt,24,
  CHEST,Container/BasicLoot/Basic-13.nbt,33,
  CHEST,Container/BasicLoot/Basic-14.nbt,50,
  CHEST,Container/BasicLoot/Basic-15.nbt,100)

[LaChal]

Thank you for the links!

For now, the BO3 support is very basic. It only loads the file through the 'Import' tool.

The random algorythm for the RandomBlock() tag will be run at load time. An UI will may be built to edit BO3 specific stuff, but it depends on whet we want to do with BOB in MCEdit.

For now, I'll mess with importing as much data as possible, and write an export function to build BO3 files from selected aera.

Another question: I've remarked that some block IDs doesn't match Minecraft ones. 'STEP' does not exists and must be converted to 'stone_slab'; 'WOOD' is in fact 'log' or 'log2' (acacia only). Is there a correspondance table we can use to convert these names?

[Estevo-Aleixo]

I looks like bo3 blocks are implemented here [1] which calls readMaterial with blockname which is here [2] but that calls another method TerrainControl.readMaterial which is implemented here [3] and calls engine.readMaterial. engine is added in the same class with setEngine(TerrainControlEngine engine). TerrainControlEngine is abstracted here [4]. (and has some nice info on how its parsed) it uses several lookups including modblocks but what you are looking for is here [5] found via [6]

[1] https://github.com/MCTCP/TerrainControl/blob/master/common/src/main/java/com/khorn/terraincontrol/customobjects/bo3/BlockFunction.java

[2] https://github.com/MCTCP/TerrainControl/blob/master/common/src/main/java/com/khorn/terraincontrol/configuration/ConfigFunction.java

[3] https://github.com/MCTCP/TerrainControl/blob/master/common/src/main/java/com/khorn/terraincontrol/TerrainControl.java

[4] https://github.com/MCTCP/TerrainControl/blob/master/common/src/main/java/com/khorn/terraincontrol/TerrainControlEngine.java#L278

[5] https://github.com/MCTCP/TerrainControl/blob/master/common/src/main/java/com/khorn/terraincontrol/util/minecraftTypes/DefaultMaterial.java

[6] https://github.com/MCTCP/TerrainControl/blob/master/common/src/main/java/com/khorn/terraincontrol/LocalMaterialData.java

I hope that ramble was useful.

So WOOD is a wooden plank (used to be id 5)

While LOG is a log (used to be id 17)

and a LOG_2 is the acacia log or mcedit log2 (id 162)

Step is id 44

[LaChal]

Thank you for the imformation.

What I was looking for (an I did not find) is in the 5th link. The block definitions will be added as a resource to MCEdit.

[LaChal]

The map from BO3 block names to block IDs has been added by the commit https://github.com/Khroki/MCEdit-Unified/commit/2e2265d2fa3ce58acd5d884936ce75c3d97a4475. And few bugs fixed in https://github.com/Khroki/MCEdit-Unified/commit/cd79135cebe04eddf3a1948ae9fe778977b89858. Can you tell me if this is the right behaviour when a RandomBlock() chances are less than 100 (eg: RandomBlock (1, 2, 3, STONE, 70))? MCEdit curently handles this by choosing Air by default.

[Estevo-Aleixo]

It looks like it leaves it unchanged if the random misses https://github.com/MCTCP/TerrainControl/blob/master/common/src/main/java/com/khorn/terraincontrol/customobjects/bo3/RandomBlockFunction.java#L108

So this is an implementation difference does mcedit allow a block to be vacant in a region?

for example consider this Block(1,1,1,STONE) RandomBlock(1,1,1,BRICK,50)

The BO3 spawn would either put STONE or BRICK but would not put AIR in the coordinate 1,1,1

[LaChal]

So this is an implementation difference does mcedit allow a block to be vacant in a region?

No block will be vacant. It will be filled with Air, at least in Minecraft. The code has been changed and now acts like https://github.com/MCTCP/TerrainControl/blob/master/common/src/main/java/com/khorn/terraincontrol/customobjects/bo3/RandomBlockFunction.java#L108.

Block(1,1,1,STONE) RandomBlock(1,1,1,BRICK,50)

The BO3 spawn would either put STONE or BRICK but would not put AIR in the coordinate 1,1,1

If the 'STONE' line is put after the 'BRICK' one, 'STONE' will be always spawned? In other words, are the lines in BO3 files parsed one after another, or are the Blocks() one parsed before the RandomBlock() ones?

[Estevo-Aleixo]

Initially it looks like it just gets a list of block functions and calls spawn on each in order. [1]

Wherever that list is created might have a filter on it but I doubt it.

No no filter. [2]

Block(1,1,1,DIAMOND_BLOCK)
Block(1,1,1,COAL_ORE)
Block(1,2,1,COAL_ORE)
Block(1,2,1,DIAMOND_BLOCK)

Should result in a diamond block on top of a coal ore (unless I got my y axis wrong)

[1] https://github.com/MCTCP/TerrainControl/blob/master/common/src/main/java/com/khorn/terraincontrol/customobjects/bo3/BO3.java#L166

[2] https://github.com/MCTCP/TerrainControl/blob/master/common/src/main/java/com/khorn/terraincontrol/customobjects/bo3/BO3Config.java#L212

[LaChal]

All right. That's what I thought looking at the TerrainControl sources, but I wasn't sure.

The BO3 support will be marked as 'beta' in the next release. (Unless we find serious bugs...) Obviously, test and reports from users are welcome ;)

Thank you for the resoureces and the answers!

[Podshot]

This is now included in our current release.