Loot tables are a data-driven method of defining a set of items to provide to relevant context, such as mob loot or mob equipment.

This guide for the Bedrock codebase (includes Pocket Edition & Windows 10 Edition) is an extension of my Java Edition guide. Many details are the same, so this guide will instead cover the differences between versions. Please view the other guide for more extensive details.

Editing

Please view the Creating Behavior Packs wiki page for details on setting up behavior packs, as well as recommended programs for editing.

Pools

Tiers

Tiers are an alternative method of selecting entries as compared to basic rolls. Rather than a random entry being selected from within the list, each entry is a tier, with the tier increasing for each entry specified. The entry to select is dependent on tier options provided. The following table indicates that "stone" is tier 1, "sand" is tier 2, and "grass" is tier 3.

Without using tiers, the specified order is irrelevant and a random entry is selected as usual.

When the "tiers" object is specified, the "rolls" option for pools is ignored, rendering "weight" and "quality" for entries useless. For example, given the following table, rolls, weight, and qualities should be removed because tiers have been specified:

An initial range of tiers can be defined as the starting position, intended to be mixed with bonus rolls, specified in the "initial_range" integer (must be 1 or higher). The value of the initial range will correspond to the highest tier that you want to have selected by default, regardless of bonus rolls. For example, given the following table:

"stone" is tier 1, "sand" is tier 2, and "grass" is tier 3. The initial range's value is 2, meaning all tiers between 1 and 2 ("stone" and "sand") will be selected by default. At that point, all of those selected tiers will have an equal chance of being selected. The basic formula for determining the chance of a tier within the range being selected would be:

chance = 1 / initial_range

As there are two tiers being selected, each has a 50% chance of being selected, while "grass" has a 0% chance due to having a tier too high for the initial range.

Bonus rolls & bonus chance

When bonus rolls are specified, the tier selected from the initial range will increase depending on the values of "bonus_rolls" (the number of times to try moving up a tier, must be 1 or higher) and "bonus_chance" (the percent chance between 0.0 and 1.0 that a single bonus roll succeeds in moving up a tier). Given the following table:

"stone" will always be the initial tier selected due to "initial_range" being 1. However, there is a 100% chance (via "bonus_chance") of increasing the tier by 1 per bonus roll. In this case, the selected entry will always be "sand" because it is the next tier up. If "bonus_rolls" were 2, then "grass" will always be selected due to it being a 100% per bonus roll to move up 1 tier.

"stone" is always the initial tier due to the initial range of 1. This time there is a 50% chance per bonus roll of increasing the tier by 1. Assuming the first of the 2 bonus rolls succeeds and causes tier 2 to now be selected, there is another 50% chance to use up the last bonus roll to move to tier 3. Thus there is a 25% chance of "stone" remaining as the selected tier after 2 bonus rolls, a 50% chance of "sand" both being bonus-rolled into and kept from there, and a 25% chance of "grass" being selected after both "stone" and "sand" are skipped by the 2 bonus rolls.

The initial range encompasses all available tiers, meaning each has a 33% chance of being initially selected. There is only 1 opportunity to move up a tier as defined by "bonus_rolls", and that has a 25% chance of succeeding. Thus if "stone" is initially selected, there is a 25% chance that it moves up to "sand" instead. If "sand" is initially selected, it has a 25% chance of becoming "grass". And if "grass" is initially selected, then it has a 25% chance of moving to the next tier. However, there is not a next tier, which means no item will be provided in those cases.

Entries

Nested pools

Unlike Java edition, entries are allowed to have pools of their own. However, this only works if the entry type is "item" or "loot_table", meaning "empty" will not work. The entry must successfully provide item(s), meaning you cannot use the "loot_tables/empty.json" table to stop the entry itself from providing items. Pools can continue to be nested within nested pools. The structure is simply a raw loot table:

The table will provide either "stone" or "stick" at a 50% split chance, but if "stone" is selected, it will also provide items from the nested pool (3 rolls, with "sand" and "grass" also being split at 50% chance).

Functions

minecraft:enchant_book_for_trading

Enchants an item using a predetermined algorithm for enchanting items sold by villagers. Takes four modifiers with unknown usage: "base_cost", "base_random_cost", "per_level_cost", and "per_level_random_cost". These modifiers may actually do nothing in the context of a loot table, though the item will still be enchanted using whatever default values.

minecraft:enchant_random_gear

Randomly enchants the item using a predetermined algorithm used for enchanting worn gear on mobs. Takes a "chance" modifier to manipulate the algorithm. Note that a "chance" modifier of 1.0 does not mean a 100% chance that gear will become enchanted. The following enchants the item based on these factors:

While this function exists in Java edition, there are a couple differences. Bedrock edition accepts a "treasure" boolean, allowing treasure enchantments to be toggled when applying random enchantments. However, unlike Java edition, there is no "enchantments" list that allows you to directly specify a list of enchantments to randomly select from.

The following allows you to enchant randomly but exclude treasure enchantments:

Expected to transform a map into an exploration map (though I could not personally get it to work; might only be usable within villager trading context). Accepts a "destination" string, specifying which structure to locate, with valid values being "monument" and "mansion".

minecraft:looting_enchant

While both Java and Bedrock editions have this function, Bedrock does not have the "limit" integer to act as a cap on the number of new items provided through the Looting enchantment.

minecraft:random_aux_value

Unknown. Takes a "values" array that crashes the game when inputting more than 1 element.

minecraft:set_data_from_color_index

Sets the data value of the item depending on internally-provided context. Because this context cannot be specified manually, this function is useless for all but a few cases, such as sheep wool color (killed or sheared). There are no options for this function. The following table provides stained hardened clay blocks with a data value corresponding to the color of a sheep's wool, provided this table is either used for sheep-killing or sheep-shearing:

The "minecraft:set_nbt" function from Java edition does not exist in the Bedrock edition.

minecraft:set_attributes

The "minecraft:set_attributes" function from Java edition does not exist in the Bedrock edition.

Conditions

NOTE: Currently conditions may not use namespaces for Bedrock edition. Please keep that in mind when porting over any Java edition loot tables, which accept namespaces for conditions.

minecraft:killed_by_player

While both Java and Bedrock editions have this function, Bedrock does not have the "inverse" boolean to only allow the condition to succeed if the mob was not killed by a player.

minecraft:random_difficulty_chance

This condition will be true based on a chance, modified by the difficulty setting. A base value specified in the "default_chance" double represents the chance that all unspecified difficulties have. Each difficulty, specified as "peaceful", "easy", "normal", "hard", can have their own chance that overwrites the default chance.

The following table has a 50% chance of succeeding on all unspecified difficulties, while easy and hard difficulties have a 10% and 100% chance respectively.

This condition will be true based on a chance, related to a chunk's regional difficulty. Only a "max_chance" double can be provided. Unsure exactly how chances are modified by regional difficulty.

minecraft:entity_scores

The "minecraft:entity_scores" condition from Java edition does not exist in the Bedrock edition.

If there is information that needs to be added, corrected, or clarified, please post! I do not play Bedrock edition, so I can only go so far with this myself.

The table will provide either "stone" or "stick" at a 50% split chance, but if "stone" is selected, it will also provide items from the nested pool (3 rolls, with "sand" and "grass" also being split at 50% chance).

I'm rather inexperienced with loot tables. Is this an example of something that Java's loot tables cannot do?

I'm rather inexperienced with loot tables. Is this an example of something that Java's loot tables cannot do?

That's correct, loot tables in Java cannot do this. I'm not sure you could easily replicate it either; that is, have a set of items that always accompanies another set of items. Not without some external force like the "entity_scores" condition, which I just realized is not present in PE/Win10 and have now fixed the thread to include that difference.

A little bit of thread necromancy here, forgive me.

I've run into a bit of a snag when working on a custom loot table for a behavior pack I'm working on. The idea is to have endermen, on an extremely rare chance, be able to drop mob spawners and all mobs (hostile and not) drop their respective spawn egg. For the purposes of testing, I've got the random chance greatly increased, and I have successfully had drops of both spawners and spawn eggs. The problem is, it's a generic/unusable spawn egg and I have been unsuccessful in my research for how to designate it with a mob type. The relevant bit of code is below:

## Index

Generic info1. Intro

2. Editing

Pools3. Tiers

Entries4. Nested pools

Functions5. minecraft:enchant_book_for_trading

6. minecraft:enchant_random_gear

7. minecraft:enchant_randomly

8. minecraft:exploration_map

9. minecraft:looting_enchant

10. minecraft:random_aux_value

11. minecraft:set_data_from_color_index

12.

~~minecraft:set_nbt~~13.

~~minecraft:set_attributes~~Conditions14. minecraft:killed_by_player

15. minecraft:random_difficulty_chance

16. minecraft:random_regional_difficulty_chance

17.

~~minecraft:entity_scores~~Conclusion18. External links

19. Conclusion

## Generic info

## Intro

Loot tables are a data-driven method of defining a set of items to provide to relevant context, such as mob loot or mob equipment.

This guide for the Bedrock codebase (includes Pocket Edition & Windows 10 Edition) is an extension of my Java Edition guide. Many details are the same, so this guide will instead cover the differences between versions. Please view the other guide for more extensive details.

## Editing

Please view the Creating Behavior Packs wiki page for details on setting up behavior packs, as well as recommended programs for editing.

## Pools

## Tiers

Tiers are an alternative method of selecting entries as compared to basic rolls. Rather than a random entry being selected from within the list, each entry is a tier, with the tier increasing for each entry specified. The entry to select is dependent on tier options provided. The following table indicates that "stone" is tier 1, "sand" is tier 2, and "grass" is tier 3.

Without using tiers, the specified order is irrelevant and a random entry is selected as usual.

When the "tiers" object is specified, the "rolls" option for pools is ignored, rendering "weight" and "quality" for entries useless. For example, given the following table,

rolls, weight, and qualities should be removedbecause tiers have been specified:## Initial range

An initial range of tiers can be defined as the starting position, intended to be mixed with bonus rolls, specified in the "initial_range" integer (must be 1 or higher). The value of the initial range will correspond to the highest tier that you want to have selected by default, regardless of bonus rolls. For example, given the following table:

"stone" is tier 1, "sand" is tier 2, and "grass" is tier 3. The initial range's value is 2, meaning all tiers between 1 and 2 ("stone" and "sand") will be selected by default. At that point, all of those selected tiers will have an equal chance of being selected. The basic formula for determining the chance of a tier within the range being selected would be:

As there are two tiers being selected, each has a 50% chance of being selected, while "grass" has a 0% chance due to having a tier too high for the initial range.

## Bonus rolls & bonus chance

When bonus rolls are specified, the tier selected from the initial range will increase depending on the values of "bonus_rolls" (the number of times to try moving up a tier, must be 1 or higher) and "bonus_chance" (the percent chance between 0.0 and 1.0 that a single bonus roll succeeds in moving up a tier). Given the following table:

"stone" will always be the initial tier selected due to "initial_range" being 1. However, there is a 100% chance (via "bonus_chance") of increasing the tier by 1 per bonus roll. In this case, the selected entry will always be "sand" because it is the next tier up. If "bonus_rolls" were 2, then "grass" will always be selected due to it being a 100%

per bonus rollto move up 1 tier.As another example, given the following table:

"stone" is always the initial tier due to the initial range of 1. This time there is a 50% chance per bonus roll of increasing the tier by 1. Assuming the first of the 2 bonus rolls succeeds and causes tier 2 to now be selected, there is another 50% chance to use up the last bonus roll to move to tier 3. Thus there is a 25% chance of "stone" remaining as the selected tier after 2 bonus rolls, a 50% chance of "sand" both being bonus-rolled into and kept from there, and a 25% chance of "grass" being selected after both "stone" and "sand" are skipped by the 2 bonus rolls.

As a final example, given the following table:

The initial range encompasses all available tiers, meaning each has a 33% chance of being initially selected. There is only 1 opportunity to move up a tier as defined by "bonus_rolls", and that has a 25% chance of succeeding. Thus if "stone" is initially selected, there is a 25% chance that it moves up to "sand" instead. If "sand" is initially selected, it has a 25% chance of becoming "grass". And if "grass" is initially selected, then it has a 25% chance of moving to the next tier. However, there is not a next tier, which means no item will be provided in those cases.

## Entries

## Nested pools

Unlike Java edition, entries are allowed to have pools of their own. However, this only works if the entry type is "item" or "loot_table", meaning "empty" will not work. The entry

mustsuccessfully provide item(s), meaning you cannot use the "loot_tables/empty.json" table to stop the entry itself from providing items. Pools can continue to be nested within nested pools. The structure is simply a raw loot table:The table will provide either "stone" or "stick" at a 50% split chance, but if "stone" is selected, it will also provide items from the nested pool (3 rolls, with "sand" and "grass" also being split at 50% chance).

## Functions

## minecraft:enchant_book_for_trading

Enchants an item using a predetermined algorithm for enchanting items sold by villagers. Takes four modifiers with unknown usage: "base_cost", "base_random_cost", "per_level_cost", and "per_level_random_cost". These modifiers may actually do nothing in the context of a loot table, though the item will still be enchanted using whatever default values.

## minecraft:enchant_random_gear

Randomly enchants the item using a predetermined algorithm used for enchanting worn gear on mobs. Takes a "chance" modifier to manipulate the algorithm. Note that a "chance" modifier of 1.0 does not mean a 100% chance that gear will become enchanted. The following enchants the item based on these factors:

## minecraft:enchant_randomly

While this function exists in Java edition, there are a couple differences. Bedrock edition accepts a "treasure" boolean, allowing treasure enchantments to be toggled when applying random enchantments. However, unlike Java edition, there is no "enchantments" list that allows you to directly specify a list of enchantments to randomly select from.

The following allows you to enchant randomly but exclude treasure enchantments:

## minecraft:exploration_map

Expected to transform a map into an exploration map (though I could not personally get it to work; might only be usable within villager trading context). Accepts a "destination" string, specifying which structure to locate, with valid values being "monument" and "mansion".

## minecraft:looting_enchant

While both Java and Bedrock editions have this function, Bedrock does not have the "limit" integer to act as a cap on the number of new items provided through the Looting enchantment.

## minecraft:random_aux_value

Unknown. Takes a "values" array that crashes the game when inputting more than 1 element.

## minecraft:set_data_from_color_index

Sets the data value of the item depending on internally-provided context. Because this context cannot be specified manually, this function is useless for all but a few cases, such as sheep wool color (killed or sheared). There are no options for this function. The following table provides stained hardened clay blocks with a data value corresponding to the color of a sheep's wool, provided this table is either used for sheep-killing or sheep-shearing:

~~minecraft:set_nbt~~The "minecraft:set_nbt" function from Java edition does not exist in the Bedrock edition.

~~minecraft:set_attributes~~The "minecraft:set_attributes" function from Java edition does not exist in the Bedrock edition.

## Conditions

NOTE:Currently conditions may not use namespaces for Bedrock edition. Please keep that in mind when porting over any Java edition loot tables, which accept namespaces for conditions.## minecraft:killed_by_player

While both Java and Bedrock editions have this function, Bedrock does not have the "inverse" boolean to only allow the condition to succeed if the mob was not killed by a player.

## minecraft:random_difficulty_chance

This condition will be true based on a chance, modified by the difficulty setting. A base value specified in the "default_chance" double represents the chance that all unspecified difficulties have. Each difficulty, specified as "peaceful", "easy", "normal", "hard", can have their own chance that overwrites the default chance.

The following table has a 50% chance of succeeding on all unspecified difficulties, while easy and hard difficulties have a 10% and 100% chance respectively.

## minecraft:random_regional_difficulty_chance

This condition will be true based on a chance, related to a chunk's regional difficulty. Only a "max_chance" double can be provided. Unsure exactly how chances are modified by regional difficulty.

~~minecraft:entity_scores~~The "minecraft:entity_scores" condition from Java edition does not exist in the Bedrock edition.

## Conclusion

## External links

- Generic JSON Validator

- Minecraft Wiki: Loot table

- Javascript loot table generator by MrPingouin1 (for Java edition)

## Conclusion

If there is information that needs to be added, corrected, or clarified, please post! I do not play Bedrock edition, so I can only go so far with this myself.

I'm rather inexperienced with loot tables. Is this an example of something that Java's loot tables cannot do?

That's correct, loot tables in Java cannot do this. I'm not sure you could easily replicate it either; that is, have a set of items that

alwaysaccompanies another set of items. Not without some external force like the "entity_scores" condition, which I just realized is not present in PE/Win10 and have now fixed the thread to include that difference.A little bit of thread necromancy here, forgive me.

I've run into a bit of a snag when working on a custom loot table for a behavior pack I'm working on. The idea is to have endermen, on an extremely rare chance, be able to drop mob spawners and all mobs (hostile and not) drop their respective spawn egg. For the purposes of testing, I've got the random chance greatly increased, and I have successfully had drops of both spawners and spawn eggs. The problem is, it's a generic/unusable spawn egg and I have been unsuccessful in my research for how to designate it with a mob type. The relevant bit of code is below: