Loot tables: pools, rolls and the difference between entries and functions
A loot table that drops nothing usually has its weights or its conditions in the wrong layer. Here is what each nesting level controls, and the functions worth knowing.
Loot table JSON is four levels deep and each level means something different. Almost every "my table drops nothing" is a condition attached one level away from where it was meant to go.
The four levels
table
└── pools[] how many independent draws
└── entries[] what can come out of this draw
└── functions[] modify the item that came outrollson a pool is how many times that pool draws. One pool withrolls: 3draws
three times from the same entry list.
weighton an entry is relative within its pool. Weights do not need to sum to
anything; an entry with weight 10 against one with weight 90 comes up a tenth of the time.
conditionsexist at every level and mean different things. On a pool they gate
the whole draw. On an entry they gate that one option. On a function they gate the modification only.
Guaranteeing a drop needs its own pool
Weights cannot guarantee anything, because a pool picks exactly one entry per roll. A table that must always drop a map plus random loot needs two pools:
"pools": [
{ "rolls": 1, "entries": [ { "type": "minecraft:item", "name": "minecraft:filled_map" } ] },
{ "rolls": { "min": 2, "max": 4 }, "entries": [ … weighted list … ] }
]Pool one has a single entry, so it always produces it. Pool two rolls 2–4 times from the weighted list.
The functions worth knowing
| Function | Does |
|---|---|
set_count | a fixed number or a uniform range |
enchant_randomly | random enchantments, optionally from a list |
enchant_with_levels | as an enchanting table at N levels — includes treasure if asked |
set_components | custom name, lore, any data component |
looting_enchant | bonus per level of Looting; entity tables only |
set_damage | durability as a fraction, so 0.5 is half-worn |
furnace_smelt | the smelted form when the mob dies on fire |
enchant_with_levels and enchant_randomly are not interchangeable. The first mimics an enchanting table and respects level costs; the second picks arbitrarily and can produce combinations the game would never generate.
Conditions that people reach for
random_chance— a flat probabilityrandom_chance_with_enchanted_bonus— the modern Looting-aware chancekilled_by_player— the reason your rare drop never appears from a fall deathentity_properties— check the victim's type, state or equipmentmatch_tool— check the tool used, for block tables
Testing without rebuilding the world
/loot give @s loot my_pack:chests/treasuredrops the table straight into your inventory. /loot spawn, /loot insert <pos> and /loot replace cover the other placements. This is far faster than placing chests and reloading, and it is the only sane way to check weight distributions.
Build multi-pool tables with the functions and conditions attached at the right level in the Advanced Loot Table Builder.