Recipes, loot and tags

Status: Partly implemented. Recipes, loot tables and tags work as data from the mod’s datapack/ folder, mod blocks drop from their own loot table <ns>:blocks/<path> (mod items allowed in it), recipes (smithing and brewing too) can use and make mod items, item tags can list mod items, and block.break can change the XP and suppress drops. An API to read recipes, roll loot or query tags from code, new recipe types and loot functions are Planned.

Concepts: Data-driven content. Guide: Recipes and loot.

Recipes (data)

datapack/<ns>/recipe/<name>.json

Every vanilla recipe type works (crafting_shaped, crafting_shapeless, crafting_transmute, smelting, blasting, smoking, campfire_cooking, stonecutting, smithing_transform, smithing_trim). Mod items work as ingredients and results (by id, "my_mod:ruby"): a mod item matches only itself, never its base item, so nine rubies make a ruby block and nine emeralds still make an emerald block. An item tag that lists a mod item (see Tags below) matches it in ingredients. Smithing results and brewing outputs can be mod items. A smithing transform works like vanilla: the result keeps the base item’s components (name, enchantments, damage, trim) and then gets the result’s own on top (for a mod item: its id, model and name; for a "components" object in result: those, "!id" removes one). A world data pack with the same recipe id overrides the mod’s.

Loot (data)

datapack/<ns>/loot_table/blocks/<path>.json      drops of the mod block <ns>:<path>
datapack/<ns>/loot_table/...                     any other loot table (chests, entities, ...)

A mod block uses <ns>:blocks/<path> for player breaks, explosions and /loot; without one it drops its item. Mod items can be entries ("name": "my_mod:ruby"). Set CL_BLOCK_NO_LOOT_TABLE in cl_block_desc.flags to drop nothing.

From code, block.break has two mutable fields:

Field	Effect
xp	The experience the block drops. The value is vanilla’s own roll (rolled on a copy of the random source, so vanilla’s sequence stays the same); change it to replace it.
drop_items	0 drops nothing (the block is still removed)

cl.on("block.break", function(event)
  if event.block == "minecraft:diamond_ore" then event.xp = event.xp * 2 end
end)

Tags (data)

datapack/<ns>/tags/<registry>/<name>.json        e.g. tags/block/mineable/pickaxe.json

Tags work like in vanilla for vanilla content. Mod blocks and items behave as their base block or item for vanilla tags (the base’s tool, mineable/*, and so on).

Item tags can also list mod items by id, in your own tags and in additions to vanilla ones (datapack/minecraft/tags/item/piglin_loved.json with { "values": ["my_mod:ruby"] }). A listed mod item is in the tag for recipes ("#my_mod:gems" as an ingredient), for game logic that checks the tag (piglins, arrows, foods, repair materials and the rest), for item predicates in commands and advancements, and for "type": "minecraft:tag" loot entries. A mod item stays in its base item’s tags too. A tag entry naming a mod item that is not installed fails the tag like any missing entry (use { "id": "my_mod:ruby", "required": false } for optional ones). Clients get the tag without the mod items (they only know the base item).

Planned

Planned
Reading data from code	Recipe lookup, loot table rolls with parameters, tag contents and membership
New types from code	Recipe types and serializers, loot functions and conditions
Loot changes from code	An event when a loot table loads, to add or remove pools
Data events	recipes_updated, tags_updated