Block database

[macfreek]

Most Minecraft tools need some database for block IDs/data IDs, or even Biome IDs, entity IDs or item IDs.

Would this or would this not be part of NBT?

On one hand I'm not in favour of maintaing that list, and like NBT to be somewhat more generic than Minecraft-only (though I currently see little use of the NBT outside of the Minecraft community).

On the other hand, there is demand for such list, and in such cases a central repository is useful. With the easy collaboration in GitHub, I also hope to see some external input (so we the NBT maintainers don't need to maintain it themselves).

It made an attempt earlier at such name module in my experimental branch. I'm not satisfied yet. While it is extendable by external tools, it lacks any non-English support. Maintaining a non-English data list is out-of-scope in my opinion, but whatever is created should have hooks for others to easily plug in the non-English names.

However, before we even consider that, the first question is: is a block ID database in scope of NBT or not?

[stumpylog]

I definitely see the use of a database for at least names to ids/data. For example, chest_analysis currently outputs things like "2x Item 26", which is not the most informative. Since NBT is very much Minecraft specific, I think it would within the scope of the project to have a database for this.

Given the large number of blocks (and more now with Anvil), I think that an SQLite database might be a good backend. Python has an interface, it is well suited to storing data like this, other programming languages have interfaces, and text can be stored in Unicode for non-English support.

[macfreek]

I rather see a list of text-based files (UTF-8 encoded) with the data, and a separate parser for the data. Being text based means it is easier for others to submit changes.

Separate files even allow other programming languages to use the same data (meaning more people update it, meaning less work for me).

I'd say the parser is in scope of NBT, as for the data files -- I frankly don't know.

[stumpylog]

True, a text based version would be the most accessible for both tool makers, and anyone else. For simplicity of parsing, just a CSV would be good, since Python has library modules for both reading and writing to a CSV file.

[macfreek]

This has low priority for me. I'll just document what seems like the proper way to do this:

• Create a new repository (e.g. minecraft-data)
• Include this in NBT using a git submodule
• Use a YAML-formatted files (Python does not have a built-in YAML parser, but it is easy enough to create a parser that can handle the required subset of YAML features. If this is an issue, JSON is an alternative)
• Do not include (English) names, but instead include the language files which can be automatically extracted from the Minecraft.jar file. Include the data files

E.g. blocks.yml:

- name: tile.wood
  id: 5
  data: 0
  solid: Yes
  strength: 2.0
  resistance: 15.0
  slipperiness: 0.6
  lightemission: 0
  lightreduction: inf
  firespread: 5
  fireburn: 20
- name: tile.wool
  id: 35
  # Rest of data, but no data field. (meaning: this applies to any block with id=35, regardless of data value)
- name: tile.wool.red
  id: 35
  data: 14
  # Data specific to red wool, the rest is inherited from the list item with id=35.

[macfreek]

I think this is out of scope. NBT should not build it's own block database. It might at some point interface with a third party database:

• Bukkit
• oddItem
• The Minecraft API (if/when it arrives)