RFC: Tag Schema

Summary

I would like to open the discussion on Tags. Burger already supports tag data, so I would like to reach a conclusion on the schema for minecraft-data. Implementing "Tags" fully probably involves recipies and other aspects of minecraft-data and probably has a rolling effect in other prismarine-* libraries, and mineflayer itself. For now, let's just think schema; or more accurately the data files and we write the schema files after.

The tags data in the minecraft jar consists of these directories:

data/minecraft/tags/blocks
data/minecraft/tags/entity_types
data/minecraft/tags/fluids
data/minecraft/tags/game_events
data/minecraft/tags/items

Burger provides all of these.

It's my opinion that we should have a new schema for tags itself for tag -> object lookups, as well as modifying appropriate other schema for object -> tags lookups.

Blocks

/blocks is straight forward and maps to the blocks schema. I believe blocks.json should be modified to include tags as follows:

{
  "id": 1,
  "name": "stone",
  ...,
  "tags": [
    "base_stone_overworld",
    "dripstone_replaceable_blocks",
    "lush_ground_replaceable",
    "mineable/pickaxe",
    "moss_replaceable",
    "stone_ore_replaceables"    
  ],
  ...
}

Entity Types

/entity_types should map directly to the entities schema:

{
  "id": 2,
  "name": "arrow",
  "tags": [
    "arrows"
  ]
}

Fluids

/fluids is not something we treat differently to blocks in minecraft-data. Water and Lava should be handled as if it were blocks (above).

Game Events

/game_events is not something that I've seen mapped anywhere in minecraft-data and can be safely ignored.

Items

/items should map to the existing items schema and items.json

{
    "id": 101,
    "displayName": "Oak Log",
    "name": "oak_log",
    "stackSize": 64,
    "tags": [
      "logs",
      "logs_that_burn",
      "oak_logs"
    ]
  },

Tags

There should be a new file, tags.json with a new tags_schema.json that provides mappings from tag names to items, blocks and entities

Since I think it's improbable that we would ever want a tag to return a mixed array of Blocks, Items and Entities it seems obvious that the tags data should be separated by the object type such that we have "blocks", "items", and "entities" types. The data may appear as follows:

{ 
  "blocks": {
    "base_stone_overworld": [
      "stone",
      "granite",
      "diorite",
      "andesite",
      "tuff",
      "deepslate"
    ]
  },
  "items": {
    "doors": [
      "oak_door",
      "spruce_door",
      "birch_door",
      "jungle_door",
      "acacia_door",
      "dark_oak_door",
      "crimson_door",
      "warped_door",
      "iron_door"
    ]
  },
  "entities": {
    "arrows": [
      "arrow",
      "spectral_arrow"
    ]
  }
}

Assumptions:

• Namespaces: Wherever the object path would have been minecraft/foo or minecraft:foo e.g. minecraft:stone. The namespace minecraft has been removed. This is because I do not expect minecraft-data to support datapacks or other namespaces, and the rest of minecraft-data appears to also follow this assumption.
• Ids: It's my understanding that Minecraft moved away from ids several versions ago, and tags do not use ids for the tag name or their mapped objects (items, blocks, entities). Burger also does not use ids here. Therefore it seems incorrect to use them in the raw data. If we need id maps we can do that in node-minecraft-data but I wouldn't recommend it.
• Versions: There would be no backporting of tags. If the version of mc didn't release with it, it's not available in minecraft-data.
• The "replacable" flag on tags is to be ignored, due to assumption 1 "Namespaces". We don't support datapacks therefore we don't support overwriting data.
• The utility of tags is to find other items, blocks, entities that match each other. Therefore the implementation is motivated towards simplicity in achieving that utility. i.e. just strings, no complex objects.

Conclusion

I look forward to the discussion and hopefully, the eventual implementation of tags. My personal motivation is to improve mineflayer-pathfinder and this RFC is the first step on that path. Once we have a quorum on schema, I will happily implement and open a PR to get that done.

Please discuss 😃

Start by reviewing the proposed paths data/minecraft/tags/{blocks,entity_types,fluids,game_events,items} and the existing blocks.json and items.json schemas. The issue is an RFC, so first determine whether the proposed object-to-tags and tags-to-objects structure is accepted. Done means the schema discussion has a clear conclusion before implementation begins.