RFC: Tag Schema

[nevercast]

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 😃

[dthigpen]

I support this implementation. I like having the tags on the blocks, items, etc and tags.json's separation of tag objects. At least for my purposes it has everything I need.

[nevercast]

Glad to hear it meets your requirements for #462

Hopefully we get some contributors' eyes on this so we can move along with a PR for the schema and a PR for burger-extractor

[rom1504]

Seems reasonable to me The only drawback is any future feature relying on that will not work for all versions before 1.16 since they won't have tags. (Unless we could think of a way to backport them ?)

[nevercast]

Either backporting, or guarding the functionality behind a feature flag and have a fall back behaviour, or allow the objects to be defined / overridden by the bot author in both cases.

I look forward to exploring those solutions in upcoming iterations of tag support.

I'll move my PR out of draft if we can start the process of getting it merged and any final changes if applicable can happen there.

[nevercast]

https://github.com/PrismarineJS/minecraft-data/pull/464 is ready for review