Minecraft Wiki
Register
Don't have an account?
Sign In
Advertisement
Minecraft Wiki
Minecraft Wiki
8,119
pages
in: Data packs
English

Loot table

Edit
watch 28:07
Minecraft Interactive Experience
Do you like this video?
Play Sound

Loot tables are technical JSON files that are used to dictate what items should generate in various situations, such as what items should be in naturally generated containers, what items should drop when breaking a block or killing a mob, what items can be fished, and more. It does not affect dropped experience, or dropped non-item entities such as slimes from larger slimes or silverfish from infested blocks.

Usage[]

The loot tables are structured as a String tag that determines the table to use, and a Long tag determining the seed. Containers or mobs with the same seed and table drop the same items. Loot tables do not determine the container's slot to be used; that is randomly determined based on the seed.

For chests, trapped chests, hoppers, storage minecarts, minecarts with hoppers, dispensers, droppers, shulker boxes and barrels:

    •  LootTable: Loot table to be used to fill the container when it is next opened, or the items are otherwise interacted with. When the container is a chest that is part of a double chest, only the half corresponding to the tagged single-chest is affected.
    •  LootTableSeed: Seed for generating the loot table. Works similarly to the seeds for worlds. 0 or omitted uses a random seed.

These tags are removed once the items have been interacted with (by opening the container, breaking the container, etc.), and only then are items put in the container.

For mobs:

  • The root tag.
    •  DeathLootTable: Loot table to be used for the items that drop when the entity is killed.
    •  DeathLootTableSeed: Seed for generating the loot table. Works similarly to the seeds for worlds. 0 or omitted uses a random seed.

The loot tables of mobs and containers can be altered with /execute store and /data merge. The player could also grant a loot table to an entity or drop it in the world with /loot.

Tags[]

Loot tables are defined using the JSON format. Below are a list of tags used.

  •  Root tag
    •  type: Optional, specifies the context in which the loot table will be invoked by. All loot functions and conditions are then validated to ensure the context type specified here will cover all requirements of the functions and conditions, and prints a warning message in the output log if any function or condition requires a context parameter that is not covered. Valid loot context types are described below.
    •  functions: Invokes loot functions, in order, upon all item stacks produced by this table.
      • A loot function. The JSON structure of this object is described on the Item modifiers page.
    •  pools: A list of all pools for this loot table. Each pool used generates items from its list of items based on the number of rolls. Pools are applied in order.
      • A pool.
        •  conditions: A list of loot conditions that must all pass for this pool to be used.
          • A loot condition. The JSON structure of this object is described on the Predicates page.
        •  functions: Invokes loot functions, in order, to all item stacks produced by this pool.
          • A loot function. The JSON structure of this object is described on the Item modifiers page.
        •  rolls: A Number Provider. Specifies the number of rolls on the pool.
        •  bonus_rolls: A Number Provider. Specifies the number of bonus rolls on the pool per point of luck. Rounded down after multiplying.
        •  entries: A list of all things that can be produced by this pool. One entry is chosen per roll as a weighted random selection from all entries without failing conditions.
          • An entry.
            •  conditions: A list of loot conditions that must all pass for this entry to be used.
              • A loot condition. The JSON structure of this object is described on the Predicates page.
            •  functions: Invokes loot functions to the item stack(s) being produced by this entry.
              • A loot function. The JSON structure of this object is described on the Item modifiers page.
            •  type: Namespaced ID of the type of entry. Set to one of the following values:
              • item for an entry that drops a single item stack.
              • tag for an entry that drops item(s) from an item tag.
              • loot_table to produce items from another loot table.
              • group for a group of child entries of which all are dropped. Can be used for convenience, e.g. if one condition applies for multiple entries.
              • alternatives for a group of child entries of which only the first successful entry in order is dropped.
              • sequence for a group of child entries that are dropped in sequential order, continuing until an entry cannot be dropped, then dropping no more entries from the children.
              • dynamic for loot tables of type block only, an entry that generates block-specific drops.
              • empty for an entry that generates nothing.
            •  name: The value of this tag depends on the  type of this entry:
              • For type item, the resource location of the item to be produced, e.g. minecraft:diamond. The default, if not changed by loot functions, is a stack of 1 of the default instance of the item.
              • For type tag, the resource location of the item tag to query, e.g. minecraft:arrows.
              • For type loot_table, the resource location of the loot table to be used, e.g. minecraft:gameplay/fishing/junk.
              • For type dynamic, can be contents to drop block entity contents or self for banners and player skulls.
            •  children: A list of child entries. Can only be used when  type is set to group, alternatives, or sequence. The behavior of the child entries depends on the type of the parent entry, described above.
              • An entry.
            •  expand: For type tag, if set to true, chooses one item listed in the tag, each with the same weight and quality. If false, generates one of every listing in the tag. Required when type is tag.
            •  weight: Determines how often this entry is chosen out of all the entries in the pool. Entries with higher weights are used more often. The chance of an entry being chosen is [this entry's weight ÷ total of all considered entries' weights].
            •  quality: Modifies the entry's weight based on the luck attribute of the killer_entity (for loot tables of type entity) or the this entity for all other loot table types. Formula is floor(weight + (quality × generic.luck)).

Recurring JSON structures within loot tables and other data pack files[]

Loot conditions[]

Main article: Predicate

Loot conditions are JSON structures that are used within loot tables to add requirements to a drop, pool, or function. They can also be used in standalone files called predicate, where they can be called upon from multiple different contexts.

The specific structure of a loot condition is shown on the Predicates page.

Loot functions[]

Main article: Item modifier

Loot functions are used within loot tables to apply modifications to the item stack being produced, such as adjusting the stack size or adding enchantments. They can also be used in standalone files called Item modifiers, where they can be called upon to modify items in an already existing item slot within a block or entity's inventory.

The specific structure of a loot function is shown on the Item modifiers page.

Number Providers[]

Loot tables use number providers in some places that accept an int or float. They can either be defined as a constant value or as an object.

  • : Constant number provider.
  • : The root tag.
    •  type: The number provider type.

The possible values for  type and associated extra contents:

  • constant—A constant value.
    •  value: The exact value.
  • uniform—A random number following a uniform distribution between two values (inclusive).
    •  min: Number provider. The minimum value.
    •  max: Number provider. The maximum value.
  • binomial—A random number following a binomial distribution
    •  n: Number provider. The amount of trials.
    •  p: Number provider. The probability of success on an individual trial.
  • score—To query and use a scoreboard value.
    •  target: To choose which player name or entity UUID to query.
      •  type: Set to fixed to manually specify a player name or UUID. Set to context to use an entity from loot context.
      •  name: Included only if  type is set to fixed. Specifies the name of the player, or the entity's UUID (in hypenated hexadecimal format) whose score to query.
      •  target: Included only if  type is set to context. Specifies an entity from loot context to query the score of. Use this for the invoking entity, killer for the entity that killed the invoking entity, direct_killer for the entity that directy killed the invoking entity, or player_killer to select the killer only if they are a player.
    •  score: The scoreboard objective to query on the selected player name or UUID.
    •  scale: Optional. Scale to multiply the score before returning it.

Loot context types[]

Loot tables, loot conditions, and loot functions all receive context parameters upon being invoked. Depending on the method of invocation, different parameters may be supplied to them. Below is a list of all possible methods of invocation for a loot table/condition/function, and the parameter:

Loot context type When it is used Loot context parameters that are supplied Loot context parameters that may be supplied
empty Supplies no loot context parameters. None None
chest
  • Opening of a chest.
  • The command /loot … loot <lootTable>.
  • Origin position: The position of the chest.
  • this entity: The entity that opened the chest.
command
  • Commands such as /item modify or /execute (if|unless) predicate.
  • Origin position: The position where the command is run.
  • this entity: The entity that is @s when the command is run.
selector
  • Origin position: The position of the entity being checked.
  • this entity: The entity being checked.
fishing
  • Origin position: The position of the fishing bobber.
  • Tool: The fishing rod item that the player cast
  • this entity: The fishing bobber.
entity
  • An entity's death.
  • this entity: The entity that died.
  • Origin location: The location of the entity's death.
  • Damage source: The source of the damage that caused the entity to die.
  • Killer entity: The entity that was the source of the final damage to the victim entity.
  • Direct killer entity: The entity that directly contacted the victim entity to kill them.
  • Last damage player: The player that most recently damaged the victim entity.
gift
  • Gift from a cat or villager.
  • Origin location
  • this entity
barter 
  • this entity: The piglin bartered with.
advancement_reward
  • this entity: The player that gained the advancement.
  • Origin location: The player's location when they gained the advancement.
advancement_entity
  • An advancement invokes a loot condition.
  • this entity: The entity being checked.
  • Origin location: The location of the entity being checked.
generic Not used. Supplies all loot context parameters. N/A N/A
block
  • Breaking a block.
  • Block state: The block that was broken.
  • Origin: The position of the broken block.
  • Tool: The tool used to mine the block.
  • this entity: The player that mined the block.
  • Block entity data: Any block entity data of the block that was broken, if it was a block entity.
  • Explosion radius: The radius of the explosion that broke the block, if broken via an explosion.

List of vanilla loot tables[]

Below is a list of all loot tables that exist by default. More tables can be added in the world save for use with custom maps. Note that some blocks, such as bedrock, end portals and other blocks unbreakable in survival do not have loot tables, some blocks share loot tables (namely wall and floor variants of blocks) and that certain drops, namely head drops from charged creepers and the wither's nether star, are currently not covered by loot tables.[1]

Data packs[]

Main article: data packs

Custom data packs use loot tables to change what loot can spawn in containers or drop by mobs. They can either change existing loot tables or create new ones. This is the file structure:

The JSON files go in this folder. Vanilla loot tables are grouped into 4 categories: gameplay (fishing), entities, blocks, and chests, with some tables being in subfolders of those. For example, the file for zombies would go in datapacks/pack name/data/minecraft/loot_tables/entities/zombie.json. This makes every zombie in that world use the datapack's loot table rather than the default zombie loot table.

Loot tables are namespaced. To create a custom loot table, first create a new folder for the custom namespace, and then create loot tables within following a similar structure. Then, summon the mob with the data tag DeathLootTable set to the name of the directory and file (without the .json extension), such as DeathLootTable:"custom_namespace:path/to/table".

History[]

Java Edition
1.9October 19, 2015Dinnerbone announces loot tables.
15w43aAdded loot tables.
15w43bAdded condition entity_scores.
15w43cRenamed "villager_golem.json" to "iron_golem.json"
Added fishing loot tables, sheep without wool, and zombie and skeleton horses.
Renamed the tag  item: to  name:, and the tag  items: to  entries:
Added the tag  type: and support to load a loot table instead of an item.
Added the tag  luck: to default files, though it currently does nothing in the code.
Added the function set_damage.
15w44aAdded the function enchant_randomly and set_attributes.
15w44bAdded the  quality tag.
Removed  luck and  luck_multiplier tags.
Added the  bonus_rolls tag.
15w51aA player in spectator mode no longer triggers a container to use its loot table to generate loot.
1.9.1pre1Loot tables now work with dispensers and droppers.
Added default table chests/jungle_temple_dispenser.
1.1116w32aDonkeys, mules, husks and zombie villagers now each draw from their own loot tables, rather than drawing from the horse and zombie loot tables, respectively
16w43aVillagers, vexes and ender dragons are now able to draw from their own loot tables.
1.1317w43aCustom loot tables have been moved into data packs.
1.1418w43aBlock drops have been changed to use loot tables too.
Loot tables received a bunch of new options.
Setting entity to "this" now refers to the player in chest and block loot tables.
18w44aAdded loot tables for cats, cat_morning_gift, players and withers.
Added loot tables for new blocks.
Added the function set_lore.
18w46aAdded loot table for illusioners.
18w48aAdded more loot tables for villages, some of which are currently unused.
Removed loot table: village_blacksmith.
18w49avillage_savanna_house and village_snowy_house loot tables are now used.
Added more loot tables for villages.
18w50avillage_desert_house and village_taiga_house loot tables are now used, making all previously unused loot tables no longer unused.
?Empty loot table is now hardcoded.
1.1519w34aAdded the function copy_state.
1.1620w12aAdded fishing_hook sub-predicate to check properties of the fishing hook.

Issues[]

Issues relating to "Loot table" are maintained on the bug tracker. Report issues there.

References[]

  1. ↑ MC-94610
Data packs
Components
Data packs
Tutorials
Categories
Languages
Deutsch Français 日本語 한국어 Nederlands Polski Português Русский 中文
Community content is available under CC BY-NC-SA 3.0 unless otherwise noted.
Advertisement

Fan Feed

More Minecraft Wiki
Explore Wikis