1.9 has introduced an organized collection of loot tables that determines what type of items are acquired from chests, hoppers, dispensers, droppers, mob drops, chest/hopper minecarts, and fishing. They allow a map/mod maker or server owner to modify what items are obtained as default loot, as well as add custom tables to be used alongside NBT data.
Loot tables are highly customizable, allowing numerous conditions with varying depths as well as functions to further modify the item(s) to provide. For command mechanisms, they will replace most loot-providing systems, such as those that use the HandItems and ArmorItems lists.
Loot tables use the JSON format to store the loot information in external files.
Errors
When a loot table fails to provide an item due to an error with the loot table itself (whether it is related to the file or the JSON structure itself), the Game Output tab in the launcher will provide the error. If you are experiencing problems with your loot tables, you may be able to find the answer within the output.
To see the output, you must keep the launcher visible while playing. You can enable this by opening the Minecraft launcher, clicking on "Edit Profile", and changing the "Launcher Visibility" to "Keep the launcher open":
Feel free to comment here for help with an issue while providing your loot table. Ensure you paste both the loot table you're using and the error (if applicable) in spoiler tags:
[spoiler]Paste loot table and error here[/spoiler]
Ensure the loot table exists in the correct file location and has the .json extension.
2. Expected value at line # column #
Your JSON structure is invalid. Double-check your syntax or use any JSON validator.
3. Missing [key], expected to find a [type]
Your structure does not match what's required for loot tables. "key" is the name of the key you are missing, such as "type".
4. Expected loot table to be a JsonObject, was "??"
This error may occur if your JSON is not structured as the game requires it, but can also occur if the file encoding is not correct (you should be saving files in UTF-8).
JSON Structure
The following is a list of all possible keys for loot tables. The wiki also includes the structure here.
Loot tables are saved within the world folder to be distributed with the world itself. More specifically, inside the data/loot_tables folder, which will not be created automatically. Here is an example structure within the world folder, where "New World" is the name of the world folder:
Namespaces
The folder that you create within the loot_tables folder will be referred to as the "namespace". This is what separates collections of loot tables, such as for different mods or maps. File/folder names must all be lowercase to circumvent issues with differing operating system file structures.
From the image example above, "skylinerwloot", "mocreatures", "anothermod", and "minecraft" are the namespaces.
The "minecraft" namespace in particular should only be used to overwrite default loot tables, such as replacing natural zombie drops. Place any new loot tables in a new namespace and not within "minecraft".
Referencing
When referencing a loot table, whether it's from within loot tables or in NBT data, you must follow the following format excluding the .json extension:
[namespace]:[filepath/to/table]
Example, targeting the file anothermod/bears/grizzly.json:
anothermod:bears/grizzly
By excluding the namespace, it will automatically assume it's meant to be "minecraft":
entities/zombie
Replacing default tables
You can create a loot table within the "minecraft" namespace with the same name as the default loot tables. Anything that uses these default tables will then use your custom one, without the need to modify NBT.
For example, given the filepath minecraft/entities/zombie.json, the following loot table will cause all default zombies to drop 0-2 feathers when killed, instead of the default rotten flesh.
You will need to use a UTF-8 compliant text editor when creating and saving loot tables that use unicode characters (such as the section symbol). By not encoding in UTF-8, special characters may not be saved correctly and Minecraft may fail to parse the data.
File/folder names must all be lowercase to circumvent issues with differing operating system file structures.
1. Windows Notepad is capable of saving as UTF-8, though will default to ANSI. Instructions for saving a .json in UTF-8:
1. Click Save or Save As.
2. Set "Save as type" to "All files (*.*)".
3. Name your file and append the name with ".json".
4. Set "Encoding" to "UTF-8".
5. Save.
Image example:
2. Notepad++ is a great alternative to using plain Notepad. Instructions for saving a .json in UTF-8:
1. Change the encoding to either "UTF-8" or "UTF-8 without BOM" under the "Encoding" menu. See image below.
2. Click Save or Save As.
3. Set "Save as type" to "All files (*.*)".
4. Name your file and append the name with ".json".
5. Save.
When a loot table is accessed, some specific information is passed to it for the parser to work with. For example, a killed entity will be stored and passed to the loot table to use for features that look for a "this" entity (such as the "entity_properties" condition).
Not all of the necessary information is stored. Depending on the feature using the loot table, a "damage source" is not relevant (such as opening a chest). The following will describe the information that can be stored, when it actually is stored, and how it is used and can be used.
All cases when info is stored:
1. When a mob dies
2. When minecart chests are opened
3. When minecart hoppers are opened
4. When chests are opened
5. When hoppers are opened
6. When dispensers are opened
7. When droppers are opened
8. When fishing
"Luck" is stored as a single float value, usually being the final "generic.luck" attribute value of the player but will also be modified by the player's "Luck of the Sea" enchantment level for fishing.
Note that while this value is obtained from a relevant player, that player does not necessarily get stored as player context.
1. When a mob dies
2. When minecart chests are opened
3. When minecart hoppers are opened
4. When chests are opened
5. When hoppers are opened
6. When dispensers are opened
7. When droppers are opened
8. When fishing
Looted entity ("this")
Stores the entity class that was looted.
Hard-coded usage:
None
Loot table usage:
1. Accessed when using the "this" context for conditions.
When it is stored:
1. When a mob dies
Player context ("killer_player")
Stores the player class, intended to signify that the player had been the one who killed the looted entity. This does not mean the player was the one who dealt the final blow. Technically it does not even have to mean the player did any killing at all, as there is a possible player for the game to potentially store when opening a chest or fishing, but is only stored in cases where a mob dies.
Hard-coded usage:
1. The "killed_by_player" condition.
Loot table usage:
1. Accessed when using the "killer_player" context for conditions.
When it is stored:
1. When a mob dies (as long as the player had struck the mob within 3 seconds before death, or as long as a zombie pigman is angry at the player)
Damage source ("killer")
Stores information concerning the final blow to the killed entity. The killing entity that dealt the final blow, if applicable, is stored alongside this information.
However, only the killing entity is ever accessed and the rest of the damage information that is stored (such as the type of damage, like "fall" or "thorns") is not yet used. Even if there was no killing entity, the damage source will still be stored but is also still unused.
Hard-coded usage:
1. The "looting_enchant" condition, obtaining the killing entity info.
2. The "random_chance_with_looting" condition, obtaining the killing entity info.
Loot table usage:
1. The killing entity info is accessed when using the "killer" context for conditions.
When it is stored:
1. When a mob dies.
Customizing tables
Pools
The collection of different items that can be dropped, dependent on conditions or other factors, stored within the "pools" list. Every record within the pool will be accessed, each of which has its own set of entries, conditions, and rolls. The following has two different records within the pool; the first record will always result in stone, while the second record will be either another stone or a stick. The end result is either 2 stone or 1 stone and 1 stick.
Each pool requires a declaration of entries via the "entries" list. Each entry will then require stating what type of entry it is with the "type" string key. The accepted types are "item", "loot_table", and "empty".
The following will provide either an item, a nested loot table, or nothing.
States that the entry will be an actual item. The "name" string key is required and defines the item ID to be used. This particular type supports the use of "functions". See the Items section for extended usage of this type.
The following will provide either a stone or a feather.
States that the entry will be another loot table. This simplifies loot tables that uses the same data as another. The "name" string key is required and defines which loot table is to be used. Does not support "functions".
Note that the other loot table's provided item is not affected by this loot table. If the other loot table has 3 rolls while this one has 1, the other loot table will cycle through all 3 of its own rolls.
A loot table may not point to itself in any manner. If the root loot table points to a second loot table that selects the root in a loop, the loot table will not function and no item will be provided.
The following will provide either an item from its own loot table, or provide item(s) from another loot table.
States that the entry will be nothing. No item will be provided. Does not support "functions" and the "name" string key cannot be used. While "conditions" may be used, they are essentially useless.
The following will provide either nothing or a stone.
A roll is the number of times the loot table will pick an item from its pool. It can either be defined as a "roll" integer key or a "roll" compound with "min" and "max" keys defined. In either case, a roll amount is required.
The following will provide exactly 3 results from the list of items.
The player's "generic.luck" attribute can optionally modify the number of total "rolls" a pool will perform. The number of bonus rolls is specified with the "bonus_rolls" integer/compound key. If compound, it defines a minimum and maximum range with the "min" and "max" integers.
The formula is:
rolls + (bonus_rolls * generic.luck)
As such, if the bonus roll is negative while luck is positive, the number of total rolls provided is decreased. For example, with 1 roll, -1 bonus rolls, and a luck value of 1, the result is 0 rolls from that pool:
1 + (-1 * 1) = 0
The following will always provide 2 stone (due to 2 initial rolls), and will also provide 1 extra stone for each point of "luck" the player has. If the player has 0 luck, they will be given 2 stone. If they have 1 luck, they will be given 3 stone.
A weight determines the chances of an item being picked in comparison to the weights of other items. If all items have the same weight, they all have the same chance of being picked. A weight is defined by the "weight" integer key and is optional. If not specified, the value defaults to 1. The following will provide 1 stone at half the rate as 1 stick.
To get an idea of how weights are used, imagine the instance of each item being multiplied by its weight. Using the above table, the following is a visual representation in which there are 2 sticks (weight of 2) and 1 stone (weight of 1). Since there are 2 sticks, they have a higher chance (exactly double) of being chosen compared to stone.
Optionally changes the "weight" of the entry based on the killing/opening/fishing player's "generic.luck" attribute value. The attribute can be modified by either worn gear with the "AttributeModifiers" list or by giving the player the "Luck" potion effect.
The formula is:
weight + (quality * generic.luck)
The following will provide either stone or diamond at equal rates while the player does not have any Luck, but if the player has a Luck value of 2, the diamond will have its "weight" changed to 7.
Functions are optional operations to perform on the item, such as providing it a count between two values, giving it NBT data or a Damage value, as well as enchanting it using a random enchantment. The "functions" list will hold multiple compounds, while the "function" string key states which function is to be used. Individual functions may ask for more data, which is covered in the next section.
The IDs for functions will have the resource namespace default to "minecraft" (e.g. "minecraft:set_attributes") when not specified. If using mods, the namespace will be whatever the mod has implemented. Note that you cannot create your own functions without modding.
The following is a list of all possible functions that can be used, along with any extra applicable data. Open the spoiler before clicking a link to be taken to the description.
Sets the "Count" NBT value of the item either to an exact value or randomly between a minimum and maximum value. The range is defined within the "count" integer or compound. If this function is not used, only one of that item will be dropped.
Sets the "Damage" NBT value of the item to the specified value or randomly between a minimum and maximum value. The exact value is defined with the "data" integer key, while the range is defined within the "data" compound.
Cannot be used with items that have durability.
The following provides a mob head with a Damage value of 3 (resulting in a player head).
Sets the percentage of durability remaining for items that have durability. 1.0 is 100% of durability remaining (undamaged) while 0.0 is no durability remaining. Does not function for items that have no durability. The "damage" float/compound keys will define the value.
The following will either provide either an item at half durability or an item between 75% to 100% durability remaining.
Sets the "tag" NBT value of the item. The input is raw NBT data, just like the show_item action for hoverEvents in the JSON text component. The value is defined within the "tag" string key. Be sure to escape nested double quotes!
Applies attribute modifiers to the item via the "modifiers" list.
Each modifier will require:
1. An "attribute" string that states the attribute ("generic.maxHealth", "generic.armor", etc).
2. A "name" string that states the custom name of the attribute. Can be anything.
3. An "amount" float or compound, stating how much to modify the attribute. If compound, "min" and "max" floats define the range.
4. An "operation" string, stating which operation to use. The accepted inputs are "addition", "multiply_base", and "multiply_total".
5. A "slot" string or list, stating which one of the specified slots the item can be used in. Note that if using it as a list, it will randomly selecting one of the specified slots. Accepted slots are: "mainhand", "offhand", "feet", "legs", "chest", "head".
Optional input:
1. An "id" string tag that specifies the UUID of the modifier.
The following will provide a diamond sword that will increase the "generic.maxHealth" attribute, choosing a value randomly between 3.5 and 6.0, using the "addition" operation. The slot it is applied to will either be "mainhand" or "offhand".
The following will apply a "generic.attackDamage" modifier of exactly 1.0 in specifically the "chest" slot. The UUID is 00000000-0000-0001-0000-000000000001.
Randomly applies a single enchantment from a list of enchantment IDs, specified with the optional "enchantments" list. If "enchantments" is not specified, the item will be enchanted randomly with a compatible enchantment for that item.
The following will apply a random enchantment and level of either Looting, Depth Strider, or Sharpness, along with a secondary enchantment that is compatible with the item.
Applies an enchantment as if it were enchanted through an enchanting table, using a minimum and maximum level defined through the "levels" integer key or compound. The range of levels are the experience levels required for the enchantment, not the level of the enchantment applied.
The "treasure" boolean key will allow treasure-only enchantments to be used (such as Mending or Frost Walker). If not defined, it will default to false.
The following provides a diamond sword enchanted at exactly level 30 while allowing the use of treasure-only enchantments.
The number of extra items to drop if the entity has the Looting enchantment on the item in their mainhand. Does not need to be a player entity, but must extend "LivingBase" (essentially all mobs, whether hostile or passive, as well as armor stands). Uses the same "count" integer/compound as set_count. The "limit" tag ensures that the resulting number of items cannot exceed that value.
The following provides an extra 30 stone for each level of Looting, but the player can receive no more than 80.
Conditions are a list of requirements that must be met before either a pool can be used, an individual item can be selected, or before a function can be run. All conditions are stored within the "conditions" list, with the "condition" string key stating which internal condition function is used. Conditions may be applied at the same depth as "items", alongside each individual "item", or within "functions".
The IDs for conditions will have the resource namespace default to "minecraft" (e.g. "minecraft:random_chance") when not specified. If using mods, the namespace will be whatever the mod has implemented. Note that you cannot create your own conditions without modding.
Each condition runs one at a time. If any condition fails, the remainder in the same list will be ignored.
The following only provides items within the pool if the condition is met. Both the stone and stick will only be provided when killed by a player, otherwise nothing is provided.
The following only provides the individual item if the condition is met. The stone will always drop, but the stick will only drop when killed by a player. If the conditions are not met when selecting an item, the entry will not be selected. The pool will not re-roll and ignores the entry instead.
The following will only run the individual function if a condition was met. The following will run the "furnace_smelt" function only if the mob was killed by a player. If a player kills the mob, smooth stone will drop. Otherwise, cobblestone will drop.
Adds a modifier to the drop chances of the item/pool or chance to execute a function. The "chance" float key will hold a value between 0.0 and 1.0, with 1.0 being 100% chance.
The following has a 30% chance to provide smooth stone. Otherwise, it provides cobblestone.
Modifies the chances of success based on the Looting enchantment on the item in the mainhand of the killing entity. Does not need to be a player entity, but must extend "LivingBase" (essentially all mobs, whether hostile or passive, as well as armor stands). The "chance" float key holds the base chance value while the "looting_multiplier" float key modifies the chances based on the Looting level.
The following formula is used to determine the chances.
chance + (looting_level * looting_multiplier)
The following will smelt the cobblestone at a base 10% chance, increasing by 15% with each level of Looting. For example, with Looting 3, the following smelts cobblestone 55% of the time (0.1 + (3 * 0.15) = 0.55).
Provides an item/pool or executes a function if the mob was specifically killed by a player. The "inverse" boolean key, when set to true, will only do so if the mob was not killed by a player.
The following will smelt the cobblestone only if the mob was not killed by a player.
Provides an item/pool or executes a function if the target entity defined by the "entity" string key has the properties defined within the "properties" compound.
The IDs for properties will have the resource namespace default to "minecraft" (e.g. "minecraft:on_fire") when not specified. If using mods, the namespace will be whatever the mod has implemented. Note that you cannot create your own properties without modding.
"on_fire" (boolean)
The following will only provide a stick if the mob was killed while it was on fire.
Provides an item/pool or executes a function if the target entity defined by the "entity" string key has the scores defined within the "scores" compound.
"entity" is restricted to: "this", "killer", and "killer_player". Target selectors or exact names do not work. Note that because of this, you may need to copy fake player scores to your desired killers/victims.
Within the "scores" compound will either be an integer or another compound, both of which uses the objective name for its own key name.
The following will only provide stone if the killing player had an "ObjA" score of exactly 1, as well as an "ObjB" score between values 1 and 25.
Multiple of the same functions and conditions can be applied, though not all will work or are useful.
Functions
set_count
Only the last "set_count" function specified will be used.
set_data
Only the last "set_data" function specified will be used.
set_damage
Only the last "set_damage" function specified will be used.
set_nbt
NBT data will merge. If duplicate tags are declared, the last "set_nbt" function specified will take precedence. For example, the following would provide an item that contains the lore from the first function, but the second function overwrites the display name from the first.
Attributes will be appended. Note that if "id" is duplicated, the game will not account for it. Do not use multiple of the same UUID.
enchant_randomly
Enchantments will be appended, rather than merged. Note that if the same enchantment is picked twice, they will not merge together and will instead be listed one after the other (and does not have to have the same level).
enchant_with_levels
Enchantments will be appended, rather than merged. Note that if the same enchantment is picked twice, they will not merge together and will instead be listed one after the other (and does not have to have the same level).
looting_enchant
Counts will be merged. For example, the following provides 42 stone with Looting I; 1 for initial, an extra 30 for the first function, and an extra 11 for the second function.
Each function will run one at a time, processing the item before moving on to the next. For example, in the following, the first function will turn the cactus into green dye, and the second function will fail because green dye has no smelting recipe.
Each condition runs one at a time (so long as no conditions fail), which can greatly change the rate of selection. For example, the following has a 50% chance for the first function, and if the first function succeeded, a 25% chance for the second function.
Each condition runs one at a time (so long as no conditions fail), which can greatly change the rate of selection. See Duplicate random_chance, which essentially functions the same way (albeit without a looting multiplier).
killed_by_player
Each condition runs one at a time (so long as no conditions fail). However, since the only option is whether or not the mob was killed by a player, it would be pointless to have multiple of these conditions at the same depth.
entity_properties
Each condition runs one at a time (so long as no conditions fail). It would be pointless to have multiple of these conditions if "entity" remained the same. However, it will function well for different targets. For example, the following would provide stone so long as both the mob and the killer were on fire.
Each condition runs one at a time (so long as no conditions fail). It would be pointless to have multiple of these conditions if "entity" remained the same. However, it will function well for different targets. For example, the following would provide stone so long as the killed mob had an "ObjA" score of 1, and the killer had an "ObjA" score between 1 and 2.
There are numerous features in-game that refer to "luck", such as the attribute, potion effect, and enchantment. Luck is specifically used with loot tables in order to modify potential loot chances. See "bonus_rolls" and "quality" for implementing into loot tables.
In default vanilla, the only thing that "luck" affects is fishing. It is a common misconception that "luck" does anything else. It does not affect mob or chest loot because the default loot tables for them do not implement the "bonus_rolls" or "quality" tags. Custom loot tables would need to be created to implement them. As well, the "Lure" enchantment no longer affects loot chances.
The "generic.luck" attribute is what controls the player's current luck value, with a base value of 0. The player can be given items that modify this value using all of the features of attribute modifiers. For example, the following provides the player with an iron ingot that, when held in the off-hand, increases the player's "generic.luck" attribute by 2.0:
The "Luck" and "Unluck" potion effects will apply modifiers to the player's "generic.luck" attribute, adding 1.0 per effect level of "Luck" or removing 1.0 per effect level of "Unluck". For example, the following gives the player "Luck" 10 and "Unluck" 4, which has a final resulting "generic.luck" value of 6:
The "Luck of the Sea" enchantment does not directly add an attribute modifier like the "Luck" or "Unluck" effects. Instead, the level of the enchantment is added onto the player's final"generic.luck" value (but only when obtaining fishing loot). As such, the enchantment supersedes other modifiers placed on the player. If the player had a modifier that reduced their attribute value by 100% (which occurs after any addition modifiers), their enchantment would still work because it is adding the enchantment level onto the final base of 0.0.
For example, the following provides the player with a "multiply total" attribute modifier, reducing their "generic.luck" by 100%, as well as a fishing rod with a high "Luck of the Sea" enchantment. The result is the player being guaranteed to fish treasure items because the enchantment value is added after obtaining the final attribute value (0.0 attribute + 85 enchantment = 85 "luck", the lowest value needed to guarantee treasure from fishing):
After all of these values are totalled up, the resulting value is what loot tables will use when modifying the "bonus_rolls" and "quality" tags.
For example, the following gives the player an iron helmet that, when worn, increases the player's "generic.luck" value by 100% (doubling their value), a "Luck" effect of 40 (which provides a modifier of +40.0), and a fishing rod with a "Luck of the Sea 5" enchantment. The result is a final attribute value of 80.0 (40 * 2), with 5 added on from the enchantment, finally resulting in 85 (guaranteeing treasure while fishing):
The "LootTable" tag holds the filepath to the desired loot table. This tag's usage is restricted to the following: chests, hoppers, dispensers, droppers, minecart chests, minecart hoppers.
The following will create a chest that will populate with items from the "chests/simple_dungeon" loot table:
Instead of being random every single time, inventory population can be deterministic based on seed. A default survival world will use this to always generate the same loot whenever a new world with the same seed is created. Value must not be 0, otherwise a new seed will be chosen randomly. This tag's usage is restricted to the following: chests, hoppers, dispensers, droppers, minecart chests, minecart hoppers.
Mobs use this tag to determine what loot table is used when killed. Note that the "HandItems/ArmorItems" data for mobs is unrelated to loot tables and can drop separate items.
An empty loot table may be declared by using "minecraft:empty". This will prevent any default loot from generating, provided that this table has not been overwritten with a custom table.
Since the "LootTable/DeathLootTable" tags states the path to the desired loot table within the target folder, rather than using hard-coded tables, you can add your own table to the mix.
The following is an example of a loot table named custom_table_a.json within the "entities" folder, inside the "customloot" namespace. It has a 1% chance of providing TNT, so long as it was on fire and killed by a player, otherwise it provides nothing.
And then using that in-game is the same as before, replacing the name with the name given to the JSON file. The following summons a creeper that, when killed, has a 1% chance to drop TNT when killed by a player and on fire.
Q: Is there an easy way to reload loot tables in-game if I've made changes?
A: Yes, hold F3 and press T to reload all resources.
Q: Do custom loot tables work on servers?
A: Yes, the file structure is exactly the same. A singleplayer world with custom loot tables can be copied to a multiplayer server with no need to change the tables.
Q: Are loot tables a part of resource packs?
A: No. Loot tables (and structures) are server-side, while resource packs are client-side. The difference is the client themselves being unable to change server resources. Loot tables and structures are not packaged with a resource pack.
Q: Where can I find the default loot tables?
A: You will need to extract "assets/loot_tables" from: /.minecraft/versions/15w49a.jar (or higher)
Q: There is no "loot_tables" folder within my world save, does it get created automatically?
A: It does not; the folder must be created manually.
Q: Why should I not use the "minecraft" namespace for new tables?
A: It is bad practice to use the default namespace for tables that are not default. There is also the risk of the filename you create being used in the future, resulting in unexpected overwriting of default resources. You should always put new loot tables into a separate namespace.
Q: Can I use target selectors for "entity"?
A: No, we are currently restricted to "this", "killer", and "killer_player".
Q: Can I use fake player scores for "entity_scores"?
A: No, we are currently restricted to "this", "killer", and "killer_player". You can use /scoreboard to duplicate the desired fake player score onto the killer or victim. You'll want to apply the score to as few targets as possible to save on scoreboard.dat bloating. For example, there will likely be fewer players compared to mobs in a CTM map, so you'll copy the fake player scores to the players ("killer_player") rather than to the killed mob ("this").
Q: Do I have to include "minecraft" before item IDs, condition IDs, and function IDs in loot tables?
A: No, the namespaces will default to "minecraft" when not defined.
Q: Accented characters/section symbol does not show up correctly in-game. What happened?
A: Your JSON file was not encoded in UTF-8. See Editing for info.
Q: What does "luck" do for default vanilla Minecraft?
A: The only thing luck affects in default vanilla is fishing loot tables. It is a common misconception that it affects mob drops or chest loot, but that is incorrect because default loot tables do not incorporate luck into anything except the fishing loot tables.
Yep, you can essentially create as many loot tables as you want. NBT data can be applied with the "set_nbt" function. You can use the section symbol to change colors, but be aware that the section symbol's usage it deprecated. You'd essentially be providing the loot table the same NBT data provided in /give, although you will need to escape quotation marks:
As of 15w43b, custom loot tables now work (and we also have a new condition called "entity_scores", example). I'll be fixing up the thread later today/tonight to include new information and correct other things.
Could you fix the set_nbt function nbt tag? When I try to put nbt data within the curly brackets, the command doesn't update. Otherwise, this is a perfect tool! Thank you so much!
Could you fix the set_nbt function nbt tag? When I try to put nbt data within the curly brackets, the command doesn't update. Otherwise, this is a perfect tool! Thank you so much!
Fixed, one of the new things learned from 15w43b is that both "weight" and "rolls" are required. The JSON for set_nbt, as well as the other examples, were missing "rolls".
What do you mean by namespace? If I named a folder "Loot" and in that folder I had a folder named "chests" that contained the .json file for a custom loot table called "dogfood", I think I'd have to use a command like this: /blockdata ~ ~-1 ~ {LootTable:"Loot:chests/dogfood"} to set that as the loot table for a chest, but I don't know where to put the folder named "Loot".
What do you mean by namespace? If I named a folder "Loot" and in that folder I had a folder named "chests" that contained the .json file for a custom loot table called "dogfood", I think I'd have to use a command like this: /blockdata ~ ~-1 ~ {LootTable:"Loot:chests/dogfood"} to set that as the loot table for a chest, but I don't know where to put the folder named "Loot".
You've got the correct format! The filepath on the hard drive will be: /[world]/data/loot_tables/Loot/chests/dogfood.json
I've rewritten the section concerning location and attempted to clarify namespaces, so hopefully that helps.
I've also added the different conditions and corrected some minor mistakes with key types.
Last things left for the 15w43b rewrite are the "luck_multiplier" key and the Q&A.
EDIT: Seemingly finished, though I'll add more to Q&A as I think of other things or see other questions that would fit there. "luck_multiplier" happens to be unused. Apologies for the weird formatting for some of the examples, trying to figure out how to stop that from happening (since it seems to be totally random).
if I make a server to play a map with custom loot tables with my friends, they will be fine or it will be affected as the resource packs?
sorry if my English is wrong
Loot tables are server-side, so the players cannot use resource packs to change it. To put it into perspective: it wouldn't make sense if a player's resource pack changes what a mob drops, otherwise anybody on a server could make cobblestone drop diamonds. The players themselves need nothing on their end.
you misunderstood me (my fault... my english is awful) I mean whene someone makes a resourcepack intended for a custom map in single player you just need to put a rar file in the saves folder of the world...but it won't work in the same way if you make a server with some friends to play the same map so you will need to modify the server files to use the resource pack...I understood that this is not a resource pack my question is...if I make a map for multiplayer and make custom loot tables the folder with the JSON's will keep working?
again sorry if my english is wrong...
you misunderstood me (my fault... my english is awful) I mean whene someone makes a resourcepack intended for a custom map in single player you just need to put a rar file in the saves folder of the world...but it won't work in the same way if you make a server with some friends to play the same map so you will need to modify the server files to use the resource pack...I understood that this is not a resource pack my question is...if I make a map for multiplayer and make custom loot tables the folder with the JSON's will keep working?
again sorry if my english is wrong...
In that case yes, you can keep the "loot_tables" folder with the save on a multiplayer server and it will still work.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffIndex
Generic info
1. Intro
2. Errors
3. JSON Structure
Files
4. Location
5. Referencing
6. Replacing default tables
7. Editing
Loot Construct
8. General info
9. Luck
10. Looted entity ("this")
11. Player context ("killer_player")
12. Damage source ("killer")
Customizing tables
13. Pools
14. Entries
15. Rolls
16. Bonus rolls
17. Items
18. Conditions
19. Duplicate functions & conditions
Usage
20. generic.luck, Luck, Unluck, Luck of the Sea
21. NBT data
Conclusion
22. Custom table example
23. Q&A
24. External links
25. Conclusion
Generic info
1.9 has introduced an organized collection of loot tables that determines what type of items are acquired from chests, hoppers, dispensers, droppers, mob drops, chest/hopper minecarts, and fishing. They allow a map/mod maker or server owner to modify what items are obtained as default loot, as well as add custom tables to be used alongside NBT data.
Loot tables are highly customizable, allowing numerous conditions with varying depths as well as functions to further modify the item(s) to provide. For command mechanisms, they will replace most loot-providing systems, such as those that use the HandItems and ArmorItems lists.
Loot tables use the JSON format to store the loot information in external files.
When a loot table fails to provide an item due to an error with the loot table itself (whether it is related to the file or the JSON structure itself), the Game Output tab in the launcher will provide the error. If you are experiencing problems with your loot tables, you may be able to find the answer within the output.
To see the output, you must keep the launcher visible while playing. You can enable this by opening the Minecraft launcher, clicking on "Edit Profile", and changing the "Launcher Visibility" to "Keep the launcher open":
Feel free to comment here for help with an issue while providing your loot table. Ensure you paste both the loot table you're using and the error (if applicable) in spoiler tags:
Common errors
1. Couldn't find resource table minecraft:tablename
2. Expected value at line # column #
3. Missing [key], expected to find a [type]
4. Expected loot table to be a JsonObject, was "??"
The following is a list of all possible keys for loot tables. The wiki also includes the structure here.
{ "pools": [ { "rolls": 1, "rolls": { "min": 1, "max": 1 }, "entries": [ { "type": "[item|loot_table|empty]", "name": "[ID|LootTable]", "weight": 1, "quality": 1.0, "functions": [ { "function": "[FunctionID]", "treasure": true, "tag": "{display:{Name:\"Test\"}}", "data": 1, "data": { "min": 1, "max": 1 }, "damage": 1, "damage": { "min": 1, "max": 1 }, "count": 1, "count": { "min": 1, "max": 1 }, "levels": 1, "levels": { "min": 1, "max": 1 }, "limit": 1, "conditions": [ (see "conditions" below) ] } ], "conditions": [ (see "conditions" below) ] } ], "conditions": [ { "condition": "[ConditionID]", "chance": 1.0, "looting_multiplier": 1.0, "inverse": true, "entity": "this", "properties": { "minecraft:on_fire": true }, "scores": { "[ObjectiveName]": 1, "[ObjectiveName]": { "min": 1, "max": 1 } } } ] } ] }Files
Loot tables are saved within the world folder to be distributed with the world itself. More specifically, inside the data/loot_tables folder, which will not be created automatically. Here is an example structure within the world folder, where "New World" is the name of the world folder:
Namespaces
The folder that you create within the loot_tables folder will be referred to as the "namespace". This is what separates collections of loot tables, such as for different mods or maps. File/folder names must all be lowercase to circumvent issues with differing operating system file structures.
From the image example above, "skylinerwloot", "mocreatures", "anothermod", and "minecraft" are the namespaces.
The "minecraft" namespace in particular should only be used to overwrite default loot tables, such as replacing natural zombie drops. Place any new loot tables in a new namespace and not within "minecraft".
When referencing a loot table, whether it's from within loot tables or in NBT data, you must follow the following format excluding the .json extension:
Example, targeting the file anothermod/bears/grizzly.json:
By excluding the namespace, it will automatically assume it's meant to be "minecraft":
You can create a loot table within the "minecraft" namespace with the same name as the default loot tables. Anything that uses these default tables will then use your custom one, without the need to modify NBT.
For example, given the filepath minecraft/entities/zombie.json, the following loot table will cause all default zombies to drop 0-2 feathers when killed, instead of the default rotten flesh.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:feather", "weight": 1, "functions": [ { "function": "minecraft:set_count", "count": { "min": 0, "max": 2 } } ] } ] } ] }List of default tables
The wiki has a description for each of the default loot tables here.
minecraft:empty
minecraft:chests/abandoned_mineshaft
minecraft:chests/desert_pyramid
minecraft:chests/end_city_treasure
minecraft:chests/igloo_chest
minecraft:chests/jungle_temple
minecraft:chests/jungle_temple_dispenser
minecraft:chests/nether_bridge
minecraft:chests/simple_dungeon
minecraft:chests/spawn_bonus_chest
minecraft:chests/stronghold_corridor
minecraft:chests/stronghold_crossing
minecraft:chests/stronghold_library
minecraft:chests/village_blacksmith
minecraft:chests/woodland_mansion
minecraft:entities/bat
minecraft:entities/blaze
minecraft:entities/cave_spider
minecraft:entities/chicken
minecraft:entities/cow
minecraft:entities/creeper
minecraft:entities/donkey
minecraft:entities/elder_guardian
minecraft:entities/ender_dragon
minecraft:entities/enderman
minecraft:entities/endermite
minecraft:entities/evocation_illager
minecraft:entities/ghast
minecraft:entities/giant
minecraft:entities/guardian
minecraft:entities/horse
minecraft:entities/husk
minecraft:entities/iron_golem
minecraft:entities/llama
minecraft:entities/magma_cube
minecraft:entities/mule
minecraft:entities/mushroom_cow
minecraft:entities/ocelot
minecraft:entities/parrot
minecraft:entities/pig
minecraft:entities/polar_bear
minecraft:entities/rabbit
minecraft:entities/sheep
minecraft:entities/shulker
minecraft:entities/silverfish
minecraft:entities/skeleton
minecraft:entities/skeleton_horse
minecraft:entities/slime
minecraft:entities/snowman
minecraft:entities/spider
minecraft:entities/squid
minecraft:entities/stray
minecraft:entities/vex
minecraft:entities/villager
minecraft:entities/vindication_illager
minecraft:entities/witch
minecraft:entities/wither_skeleton
minecraft:entities/wolf
minecraft:entities/zombie
minecraft:entities/zombie_horse
minecraft:entities/zombie_pigman
minecraft:entities/zombie_villager
minecraft:entities/sheep/black
minecraft:entities/sheep/blue
minecraft:entities/sheep/brown
minecraft:entities/sheep/cyan
minecraft:entities/sheep/gray
minecraft:entities/sheep/green
minecraft:entities/sheep/light_blue
minecraft:entities/sheep/lime
minecraft:entities/sheep/magenta
minecraft:entities/sheep/orange
minecraft:entities/sheep/pink
minecraft:entities/sheep/purple
minecraft:entities/sheep/red
minecraft:entities/sheep/silver
minecraft:entities/sheep/white
minecraft:entities/sheep/yellow
minecraft:gameplay/fishing
minecraft:gameplay/fishing/fish
minecraft:gameplay/fishing/junk
minecraft:gameplay/fishing/treasure
You will need to use a UTF-8 compliant text editor when creating and saving loot tables that use unicode characters (such as the section symbol). By not encoding in UTF-8, special characters may not be saved correctly and Minecraft may fail to parse the data.
File/folder names must all be lowercase to circumvent issues with differing operating system file structures.
1. Windows Notepad is capable of saving as UTF-8, though will default to ANSI. Instructions for saving a .json in UTF-8:
1. Click Save or Save As.
2. Set "Save as type" to "All files (*.*)".
3. Name your file and append the name with ".json".
4. Set "Encoding" to "UTF-8".
5. Save.
Image example:
2. Notepad++ is a great alternative to using plain Notepad. Instructions for saving a .json in UTF-8:
1. Change the encoding to either "UTF-8" or "UTF-8 without BOM" under the "Encoding" menu. See image below.
2. Click Save or Save As.
3. Set "Save as type" to "All files (*.*)".
4. Name your file and append the name with ".json".
5. Save.
Image example:
3. Atom has multiple platform support.
Loot construct
When a loot table is accessed, some specific information is passed to it for the parser to work with. For example, a killed entity will be stored and passed to the loot table to use for features that look for a "this" entity (such as the "entity_properties" condition).
Not all of the necessary information is stored. Depending on the feature using the loot table, a "damage source" is not relevant (such as opening a chest). The following will describe the information that can be stored, when it actually is stored, and how it is used and can be used.
All cases when info is stored:
1. When a mob dies
2. When minecart chests are opened
3. When minecart hoppers are opened
4. When chests are opened
5. When hoppers are opened
6. When dispensers are opened
7. When droppers are opened
8. When fishing
See also: bonus_rolls, quality, Luck usage
"Luck" is stored as a single float value, usually being the final "generic.luck" attribute value of the player but will also be modified by the player's "Luck of the Sea" enchantment level for fishing.
Note that while this value is obtained from a relevant player, that player does not necessarily get stored as player context.
Hard-coded usage:
None
Loot table usage:
1. The "bonus_rolls" parameter for pools.
2. The "quality" parameter for entries.
When it is stored:
1. When a mob dies
2. When minecart chests are opened
3. When minecart hoppers are opened
4. When chests are opened
5. When hoppers are opened
6. When dispensers are opened
7. When droppers are opened
8. When fishing
Stores the entity class that was looted.
Hard-coded usage:
None
Loot table usage:
1. Accessed when using the "this" context for conditions.
When it is stored:
1. When a mob dies
Stores the player class, intended to signify that the player had been the one who killed the looted entity. This does not mean the player was the one who dealt the final blow. Technically it does not even have to mean the player did any killing at all, as there is a possible player for the game to potentially store when opening a chest or fishing, but is only stored in cases where a mob dies.
Hard-coded usage:
1. The "killed_by_player" condition.
Loot table usage:
1. Accessed when using the "killer_player" context for conditions.
When it is stored:
1. When a mob dies (as long as the player had struck the mob within 3 seconds before death, or as long as a zombie pigman is angry at the player)
Stores information concerning the final blow to the killed entity. The killing entity that dealt the final blow, if applicable, is stored alongside this information.
However, only the killing entity is ever accessed and the rest of the damage information that is stored (such as the type of damage, like "fall" or "thorns") is not yet used. Even if there was no killing entity, the damage source will still be stored but is also still unused.
Hard-coded usage:
1. The "looting_enchant" condition, obtaining the killing entity info.
2. The "random_chance_with_looting" condition, obtaining the killing entity info.
Loot table usage:
1. The killing entity info is accessed when using the "killer" context for conditions.
When it is stored:
1. When a mob dies.
Customizing tables
The collection of different items that can be dropped, dependent on conditions or other factors, stored within the "pools" list. Every record within the pool will be accessed, each of which has its own set of entries, conditions, and rolls. The following has two different records within the pool; the first record will always result in stone, while the second record will be either another stone or a stick. The end result is either 2 stone or 1 stone and 1 stick.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:stone", "weight": 1 } ] }, { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:stone", "weight": 1 }, { "type": "item", "name": "minecraft:stick", "weight": 1 } ] } ] }Each pool requires a declaration of entries via the "entries" list. Each entry will then require stating what type of entry it is with the "type" string key. The accepted types are "item", "loot_table", and "empty".
The following will provide either an item, a nested loot table, or nothing.
item
States that the entry will be an actual item. The "name" string key is required and defines the item ID to be used. This particular type supports the use of "functions". See the Items section for extended usage of this type.
The following will provide either a stone or a feather.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:stone", "weight": 1 }, { "type": "item", "name": "minecraft:feather", "weight": 1 } ] } ] }loot_table
States that the entry will be another loot table. This simplifies loot tables that uses the same data as another. The "name" string key is required and defines which loot table is to be used. Does not support "functions".
Note that the other loot table's provided item is not affected by this loot table. If the other loot table has 3 rolls while this one has 1, the other loot table will cycle through all 3 of its own rolls.
A loot table may not point to itself in any manner. If the root loot table points to a second loot table that selects the root in a loop, the loot table will not function and no item will be provided.
The following will provide either an item from its own loot table, or provide item(s) from another loot table.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:stone", "weight": 1 }, { "type": "item", "name": "minecraft:feather", "weight": 1 }, { "type": "loot_table", "name": "minecraft:entities/zombie", "weight": 1 } ] } ] }empty
States that the entry will be nothing. No item will be provided. Does not support "functions" and the "name" string key cannot be used. While "conditions" may be used, they are essentially useless.
The following will provide either nothing or a stone.
A roll is the number of times the loot table will pick an item from its pool. It can either be defined as a "roll" integer key or a "roll" compound with "min" and "max" keys defined. In either case, a roll amount is required.
The following will provide exactly 3 results from the list of items.
{ "pools": [ { "rolls": 3, "entries": [ { "type": "item", "name": "minecraft:stone", "weight": 1 }, { "type": "item", "name": "minecraft:stick", "weight": 1 } ] } ] }The following will provide between 1 and 5 results from the list of items.
See also: quality, Luck usage
The player's "generic.luck" attribute can optionally modify the number of total "rolls" a pool will perform. The number of bonus rolls is specified with the "bonus_rolls" integer/compound key. If compound, it defines a minimum and maximum range with the "min" and "max" integers.
The formula is:
As such, if the bonus roll is negative while luck is positive, the number of total rolls provided is decreased. For example, with 1 roll, -1 bonus rolls, and a luck value of 1, the result is 0 rolls from that pool:
The following will always provide 2 stone (due to 2 initial rolls), and will also provide 1 extra stone for each point of "luck" the player has. If the player has 0 luck, they will be given 2 stone. If they have 1 luck, they will be given 3 stone.
{ "pools": [ { "rolls": 2, "bonus_rolls":1, "entries": [ { "type": "item", "name": "minecraft:stone", "weight": 1 } ] } ] }The following will provide between 2-6 extra stone.
Weight
A weight determines the chances of an item being picked in comparison to the weights of other items. If all items have the same weight, they all have the same chance of being picked. A weight is defined by the "weight" integer key and is optional. If not specified, the value defaults to 1. The following will provide 1 stone at half the rate as 1 stick.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:stone", "weight": 1 }, { "type": "item", "name": "minecraft:stick", "weight": 2 } ] } ] }To get an idea of how weights are used, imagine the instance of each item being multiplied by its weight. Using the above table, the following is a visual representation in which there are 2 sticks (weight of 2) and 1 stone (weight of 1). Since there are 2 sticks, they have a higher chance (exactly double) of being chosen compared to stone.
Quality
See also: bonus_rolls, Luck usage
Optionally changes the "weight" of the entry based on the killing/opening/fishing player's "generic.luck" attribute value. The attribute can be modified by either worn gear with the "AttributeModifiers" list or by giving the player the "Luck" potion effect.
The formula is:
The following will provide either stone or diamond at equal rates while the player does not have any Luck, but if the player has a Luck value of 2, the diamond will have its "weight" changed to 7.
{ "pools": [ { "rolls": 20, "entries": [ { "type": "item", "name": "minecraft:stone", "weight": 1 }, { "type": "item", "name": "minecraft:diamond", "weight": 1, "quality": 3 } ] } ] }Functions
Functions are optional operations to perform on the item, such as providing it a count between two values, giving it NBT data or a Damage value, as well as enchanting it using a random enchantment. The "functions" list will hold multiple compounds, while the "function" string key states which function is to be used. Individual functions may ask for more data, which is covered in the next section.
The IDs for functions will have the resource namespace default to "minecraft" (e.g. "minecraft:set_attributes") when not specified. If using mods, the namespace will be whatever the mod has implemented. Note that you cannot create your own functions without modding.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:diamond_sword", "weight": 1, "functions": [ { "function": "set_damage", "damage": 0.6 }, { "function": "minecraft:enchant_with_levels", "levels": { "min": 20, "max": 30 } } ] } ] } ] }List of functions
The following is a list of all possible functions that can be used, along with any extra applicable data. Open the spoiler before clicking a link to be taken to the description.
1. set_count
2. set_data
3. set_damage
4. set_nbt
5. set_attributes
6. enchant_randomly
7. enchant_with_levels
8. looting_enchant
9. furnace_smelt
set_count
Sets the "Count" NBT value of the item either to an exact value or randomly between a minimum and maximum value. The range is defined within the "count" integer or compound. If this function is not used, only one of that item will be dropped.The following provides exactly 4 stone.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:stone", "weight": 1, "functions": [ { "function": "minecraft:set_count", "count": 4 } ] } ] } ] }The following provides between 3 and 5 stone.
set_data
Sets the "Damage" NBT value of the item to the specified value or randomly between a minimum and maximum value. The exact value is defined with the "data" integer key, while the range is defined within the "data" compound.Cannot be used with items that have durability.
The following provides a mob head with a Damage value of 3 (resulting in a player head).
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:skull", "weight": 1, "functions": [ { "function": "minecraft:set_data", "data": 3 } ] } ] } ] }The following provides a dye with a Damage value randomly chosen between 1 and 4.
set_damage
Sets the percentage of durability remaining for items that have durability. 1.0 is 100% of durability remaining (undamaged) while 0.0 is no durability remaining. Does not function for items that have no durability. The "damage" float/compound keys will define the value.The following will either provide either an item at half durability or an item between 75% to 100% durability remaining.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:diamond_sword", "weight": 1, "functions": [ { "function": "minecraft:set_damage", "damage": 0.5 } ] }, { "type": "item", "name": "minecraft:diamond_sword", "weight": 1, "functions": [ { "function": "minecraft:set_damage", "damage": { "min": 0.75, "max": 1 } } ] } ] } ] }set_nbt
Sets the "tag" NBT value of the item. The input is raw NBT data, just like the show_item action for hoverEvents in the JSON text component. The value is defined within the "tag" string key. Be sure to escape nested double quotes!set_attributes
Applies attribute modifiers to the item via the "modifiers" list.Each modifier will require:
1. An "attribute" string that states the attribute ("generic.maxHealth", "generic.armor", etc).
2. A "name" string that states the custom name of the attribute. Can be anything.
3. An "amount" float or compound, stating how much to modify the attribute. If compound, "min" and "max" floats define the range.
4. An "operation" string, stating which operation to use. The accepted inputs are "addition", "multiply_base", and "multiply_total".
5. A "slot" string or list, stating which one of the specified slots the item can be used in. Note that if using it as a list, it will randomly selecting one of the specified slots. Accepted slots are: "mainhand", "offhand", "feet", "legs", "chest", "head".
Optional input:
1. An "id" string tag that specifies the UUID of the modifier.
The following will provide a diamond sword that will increase the "generic.maxHealth" attribute, choosing a value randomly between 3.5 and 6.0, using the "addition" operation. The slot it is applied to will either be "mainhand" or "offhand".
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:diamond_sword", "weight": 1, "functions": [ { "function": "minecraft:set_attributes", "modifiers": [ { "attribute": "generic.maxHealth", "name": "More Health", "amount": { "min": 3.5, "max": 6 }, "operation": "addition", "slot": [ "mainhand", "offhand" ] } ] } ] } ] } ] }The following will apply a "generic.attackDamage" modifier of exactly 1.0 in specifically the "chest" slot. The UUID is 00000000-0000-0001-0000-000000000001.
enchant_randomly
Randomly applies a single enchantment from a list of enchantment IDs, specified with the optional "enchantments" list. If "enchantments" is not specified, the item will be enchanted randomly with a compatible enchantment for that item.The following will apply a random enchantment and level of either Looting, Depth Strider, or Sharpness, along with a secondary enchantment that is compatible with the item.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:diamond_sword", "weight": 1, "functions": [ { "function": "minecraft:enchant_randomly", "enchantments": [ "minecraft:looting", "minecraft:depth_strider", "minecraft:sharpness" ] }, { "function": "minecraft:enchant_randomly" } ] } ] } ] }enchant_with_levels
Applies an enchantment as if it were enchanted through an enchanting table, using a minimum and maximum level defined through the "levels" integer key or compound. The range of levels are the experience levels required for the enchantment, not the level of the enchantment applied.The "treasure" boolean key will allow treasure-only enchantments to be used (such as Mending or Frost Walker). If not defined, it will default to false.
The following provides a diamond sword enchanted at exactly level 30 while allowing the use of treasure-only enchantments.
The following provides a diamond sword with a random enchantment obtained between levels 25 and 30, disregarding treasure.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:diamond_sword", "weight": 1, "functions": [ { "function": "minecraft:enchant_with_levels", "levels": { "min": 25, "max": 30 } } ] } ] } ] }looting_enchant
The number of extra items to drop if the entity has the Looting enchantment on the item in their mainhand. Does not need to be a player entity, but must extend "LivingBase" (essentially all mobs, whether hostile or passive, as well as armor stands). Uses the same "count" integer/compound as set_count. The "limit" tag ensures that the resulting number of items cannot exceed that value.
The following provides an extra 30 stone for each level of Looting, but the player can receive no more than 80.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:stone", "weight": 1, "functions": [ { "function": "minecraft:looting_enchant", "count": 30, "limit": 80 } ] } ] } ] }The following provides between 10 and 20 extra stone.
furnace_smelt
If the item to drop has a smelted crafting recipe, that resulting item will be supplied instead. The following provides charcoal instead of a log.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:log", "weight": 1, "functions": [ { "function": "minecraft:furnace_smelt" } ] } ] } ] }Conditions are a list of requirements that must be met before either a pool can be used, an individual item can be selected, or before a function can be run. All conditions are stored within the "conditions" list, with the "condition" string key stating which internal condition function is used. Conditions may be applied at the same depth as "items", alongside each individual "item", or within "functions".
The IDs for conditions will have the resource namespace default to "minecraft" (e.g. "minecraft:random_chance") when not specified. If using mods, the namespace will be whatever the mod has implemented. Note that you cannot create your own conditions without modding.
Each condition runs one at a time. If any condition fails, the remainder in the same list will be ignored.
The following only provides items within the pool if the condition is met. Both the stone and stick will only be provided when killed by a player, otherwise nothing is provided.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:stone", "weight": 1 }, { "type": "item", "name": "minecraft:stick", "weight": 1 } ], "conditions": [ { "condition": "killed_by_player" } ] } ] }The following only provides the individual item if the condition is met. The stone will always drop, but the stick will only drop when killed by a player. If the conditions are not met when selecting an item, the entry will not be selected. The pool will not re-roll and ignores the entry instead.
The following will only run the individual function if a condition was met. The following will run the "furnace_smelt" function only if the mob was killed by a player. If a player kills the mob, smooth stone will drop. Otherwise, cobblestone will drop.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:cobblestone", "weight": 1, "functions": [ { "function": "minecraft:furnace_smelt", "conditions": [ { "condition": "minecraft:killed_by_player" } ] } ] } ] } ] }List of conditions
The following is a list of all conditions that can be used. Open the spoiler before clicking a link to be taken to the description.
1. random_chance
2. random_chance_with_looting
3. killed_by_player
4. entity_properties
5. entity_scores
random_chance
Adds a modifier to the drop chances of the item/pool or chance to execute a function. The "chance" float key will hold a value between 0.0 and 1.0, with 1.0 being 100% chance.The following has a 30% chance to provide smooth stone. Otherwise, it provides cobblestone.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:cobblestone", "weight": 1, "functions": [ { "function": "minecraft:furnace_smelt", "conditions": [ { "condition": "minecraft:random_chance", "chance": 0.3 } ] } ] } ] } ] }random_chance_with_looting
Modifies the chances of success based on the Looting enchantment on the item in the mainhand of the killing entity. Does not need to be a player entity, but must extend "LivingBase" (essentially all mobs, whether hostile or passive, as well as armor stands). The "chance" float key holds the base chance value while the "looting_multiplier" float key modifies the chances based on the Looting level.The following formula is used to determine the chances.
The following will smelt the cobblestone at a base 10% chance, increasing by 15% with each level of Looting. For example, with Looting 3, the following smelts cobblestone 55% of the time (0.1 + (3 * 0.15) = 0.55).
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:cobblestone", "weight": 1, "functions": [ { "function": "minecraft:furnace_smelt", "conditions": [ { "condition": "minecraft:random_chance_with_looting", "chance": 0.1, "looting_multiplier": 0.15 } ] } ] } ] } ] }killed_by_player
Provides an item/pool or executes a function if the mob was specifically killed by a player. The "inverse" boolean key, when set to true, will only do so if the mob was not killed by a player.The following will smelt the cobblestone only if the mob was not killed by a player.
entity_properties
Provides an item/pool or executes a function if the target entity defined by the "entity" string key has the properties defined within the "properties" compound."entity" is restricted to: "this", "killer", and "killer_player". Target selectors or exact names do not work.
The IDs for properties will have the resource namespace default to "minecraft" (e.g. "minecraft:on_fire") when not specified. If using mods, the namespace will be whatever the mod has implemented. Note that you cannot create your own properties without modding.
"on_fire" (boolean)
The following will only provide a stick if the mob was killed while it was on fire.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:cobblestone", "weight": 1, "conditions": [ { "condition": "minecraft:entity_properties", "entity": "this", "properties": { "minecraft:on_fire": true } } ] } ] } ] }The following will only provide cobblestone if the killing player was not on fire.
entity_scores
Provides an item/pool or executes a function if the target entity defined by the "entity" string key has the scores defined within the "scores" compound."entity" is restricted to: "this", "killer", and "killer_player". Target selectors or exact names do not work. Note that because of this, you may need to copy fake player scores to your desired killers/victims.
Within the "scores" compound will either be an integer or another compound, both of which uses the objective name for its own key name.
The following will only provide stone if the killing player had an "ObjA" score of exactly 1, as well as an "ObjB" score between values 1 and 25.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:cobblestone", "weight": 1, "conditions": [ { "condition": "minecraft:entity_scores", "entity": "killer_player", "scores": { "ObjA": 1, "ObjB": { "min": 1, "max": 25 } } } ] } ] } ] }Multiple of the same functions and conditions can be applied, though not all will work or are useful.
Functions
set_count
Only the last "set_count" function specified will be used.
set_data
Only the last "set_data" function specified will be used.
set_damage
Only the last "set_damage" function specified will be used.
set_nbt
NBT data will merge. If duplicate tags are declared, the last "set_nbt" function specified will take precedence. For example, the following would provide an item that contains the lore from the first function, but the second function overwrites the display name from the first.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:cobblestone", "weight": 1, "functions": [ { "function": "minecraft:set_nbt", "tag": "{display:{Name:\"Function 1\",Lore:[\"text\"]}}" }, { "function": "minecraft:set_nbt", "tag": "{display:{Name:\"Function 2\"}}" } ] } ] } ] }set_attributes
Attributes will be appended. Note that if "id" is duplicated, the game will not account for it. Do not use multiple of the same UUID.
enchant_randomly
Enchantments will be appended, rather than merged. Note that if the same enchantment is picked twice, they will not merge together and will instead be listed one after the other (and does not have to have the same level).
enchant_with_levels
Enchantments will be appended, rather than merged. Note that if the same enchantment is picked twice, they will not merge together and will instead be listed one after the other (and does not have to have the same level).
looting_enchant
Counts will be merged. For example, the following provides 42 stone with Looting I; 1 for initial, an extra 30 for the first function, and an extra 11 for the second function.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:stone", "weight": 1, "functions": [ { "function": "minecraft:looting_enchant", "count": 30 }, { "function": "minecraft:looting_enchant", "count": 11 } ] } ] } ] }furnace_smelt
Each function will run one at a time, processing the item before moving on to the next. For example, in the following, the first function will turn the cactus into green dye, and the second function will fail because green dye has no smelting recipe.
Conditions
random_chance
Each condition runs one at a time (so long as no conditions fail), which can greatly change the rate of selection. For example, the following has a 50% chance for the first function, and if the first function succeeded, a 25% chance for the second function.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:stone_sword", "weight": 1, "conditions": [ { "condition": "minecraft:random_chance", "chance": 0.5 }, { "condition": "minecraft:random_chance", "chance": 0.25 } ] } ] } ] }random_chance_with_looting
Each condition runs one at a time (so long as no conditions fail), which can greatly change the rate of selection. See Duplicate random_chance, which essentially functions the same way (albeit without a looting multiplier).
killed_by_player
Each condition runs one at a time (so long as no conditions fail). However, since the only option is whether or not the mob was killed by a player, it would be pointless to have multiple of these conditions at the same depth.
entity_properties
Each condition runs one at a time (so long as no conditions fail). It would be pointless to have multiple of these conditions if "entity" remained the same. However, it will function well for different targets. For example, the following would provide stone so long as both the mob and the killer were on fire.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:cobblestone", "weight": 1, "conditions": [ { "condition": "minecraft:entity_properties", "entity": "this", "properties": { "on_fire": true } }, { "condition": "minecraft:entity_properties", "entity": "killer", "properties": { "on_fire": true } } ] } ] } ] }entity_scores
Each condition runs one at a time (so long as no conditions fail). It would be pointless to have multiple of these conditions if "entity" remained the same. However, it will function well for different targets. For example, the following would provide stone so long as the killed mob had an "ObjA" score of 1, and the killer had an "ObjA" score between 1 and 2.
Usage
There are numerous features in-game that refer to "luck", such as the attribute, potion effect, and enchantment. Luck is specifically used with loot tables in order to modify potential loot chances. See "bonus_rolls" and "quality" for implementing into loot tables.
In default vanilla, the only thing that "luck" affects is fishing. It is a common misconception that "luck" does anything else. It does not affect mob or chest loot because the default loot tables for them do not implement the "bonus_rolls" or "quality" tags. Custom loot tables would need to be created to implement them. As well, the "Lure" enchantment no longer affects loot chances.
The "generic.luck" attribute is what controls the player's current luck value, with a base value of 0. The player can be given items that modify this value using all of the features of attribute modifiers. For example, the following provides the player with an iron ingot that, when held in the off-hand, increases the player's "generic.luck" attribute by 2.0:
/give @p minecraft:iron_ingot 1 0 {AttributeModifiers:[{AttributeName:"generic.luck",Name:"More Luck",Amount:2.0,Operation:0,Slot:"offhand",UUIDLeast:1l,UUIDMost:1l}]}The "Luck" and "Unluck" potion effects will apply modifiers to the player's "generic.luck" attribute, adding 1.0 per effect level of "Luck" or removing 1.0 per effect level of "Unluck". For example, the following gives the player "Luck" 10 and "Unluck" 4, which has a final resulting "generic.luck" value of 6:
The "Luck of the Sea" enchantment does not directly add an attribute modifier like the "Luck" or "Unluck" effects. Instead, the level of the enchantment is added onto the player's final "generic.luck" value (but only when obtaining fishing loot). As such, the enchantment supersedes other modifiers placed on the player. If the player had a modifier that reduced their attribute value by 100% (which occurs after any addition modifiers), their enchantment would still work because it is adding the enchantment level onto the final base of 0.0.
For example, the following provides the player with a "multiply total" attribute modifier, reducing their "generic.luck" by 100%, as well as a fishing rod with a high "Luck of the Sea" enchantment. The result is the player being guaranteed to fish treasure items because the enchantment value is added after obtaining the final attribute value (0.0 attribute + 85 enchantment = 85 "luck", the lowest value needed to guarantee treasure from fishing):
/give @p minecraft:iron_helmet 1 0 {AttributeModifiers:[{AttributeName:"generic.luck",Name:"100% reduction",Amount:-1.0,Operation:2,Slot:"head",UUIDLeast:1l,UUIDMost:1l}]} /give @p minecraft:fishing_rod 1 0 {ench:[{id:61s,lvl:85s}]}After all of these values are totalled up, the resulting value is what loot tables will use when modifying the "bonus_rolls" and "quality" tags.
For example, the following gives the player an iron helmet that, when worn, increases the player's "generic.luck" value by 100% (doubling their value), a "Luck" effect of 40 (which provides a modifier of +40.0), and a fishing rod with a "Luck of the Sea 5" enchantment. The result is a final attribute value of 80.0 (40 * 2), with 5 added on from the enchantment, finally resulting in 85 (guaranteeing treasure while fishing):
/give @p minecraft:iron_helmet 1 0 {AttributeModifiers:[{AttributeName:"generic.luck",Name:"100% More",Amount:1.0,Operation:2,Slot:"head",UUIDLeast:1l,UUIDMost:1l}]} /effect @p minecraft:luck 30 39 /give @p minecraft:fishing_rod 1 0 {ench:[{id:61s,lvl:5s}]}"LootTable" (string)
The "LootTable" tag holds the filepath to the desired loot table. This tag's usage is restricted to the following: chests, hoppers, dispensers, droppers, minecart chests, minecart hoppers.
The following will create a chest that will populate with items from the "chests/simple_dungeon" loot table:
/setblock ~ ~1 ~ minecraft:chest 0 false {LootTable:"minecraft:chests/simple_dungeon"}"LootTableSeed" (long)
Instead of being random every single time, inventory population can be deterministic based on seed. A default survival world will use this to always generate the same loot whenever a new world with the same seed is created. Value must not be 0, otherwise a new seed will be chosen randomly. This tag's usage is restricted to the following: chests, hoppers, dispensers, droppers, minecart chests, minecart hoppers.
/setblock ~ ~1 ~ minecraft:chest 0 false {LootTable:"minecraft:chests/simple_dungeon",LootTableSeed:123L}"DeathLootTable" (string)
Mobs use this tag to determine what loot table is used when killed. Note that the "HandItems/ArmorItems" data for mobs is unrelated to loot tables and can drop separate items.
/summon Creeper ~ ~1 ~ {DeathLootTable:"minecraft:chests/simple_dungeon"}"DeathLootTableSeed" (long)
Same as "LootTableSeed", except for mobs.
/summon Creeper ~ ~1 ~ {DeathLootTable:"minecraft:chests/simple_dungeon",DeathLootTableSeed:123L}Empty tables
An empty loot table may be declared by using "minecraft:empty". This will prevent any default loot from generating, provided that this table has not been overwritten with a custom table.
/summon Creeper ~ ~1 ~ {LootTable:"minecraft:empty"}Conclusion
Since the "LootTable/DeathLootTable" tags states the path to the desired loot table within the target folder, rather than using hard-coded tables, you can add your own table to the mix.
The following is an example of a loot table named custom_table_a.json within the "entities" folder, inside the "customloot" namespace. It has a 1% chance of providing TNT, so long as it was on fire and killed by a player, otherwise it provides nothing.
{ "pools": [ { "rolls": 1, "entries": [ { "type": "item", "name": "minecraft:tnt", "weight": 1, "conditions": [ { "condition": "minecraft:random_chance", "chance": 0.01 }, { "condition": "minecraft:killed_by_player" }, { "condition": "minecraft:entity_properties", "entity": "this", "properties": { "minecraft:on_fire": true } } ] } ] } ] }And then using that in-game is the same as before, replacing the name with the name given to the JSON file. The following summons a creeper that, when killed, has a 1% chance to drop TNT when killed by a player and on fire.
/summon Creeper ~ ~1 ~ {DeathLootTable:"customloot:entities/custom_table_a"}Q&A last updated: 16w02a.
Q: Is there an easy way to reload loot tables in-game if I've made changes?
A: Yes, hold F3 and press T to reload all resources.
Q: Do custom loot tables work on servers?
A: Yes, the file structure is exactly the same. A singleplayer world with custom loot tables can be copied to a multiplayer server with no need to change the tables.
Q: Are loot tables a part of resource packs?
A: No. Loot tables (and structures) are server-side, while resource packs are client-side. The difference is the client themselves being unable to change server resources. Loot tables and structures are not packaged with a resource pack.
Q: Where can I find the default loot tables?
A: You will need to extract "assets/loot_tables" from: /.minecraft/versions/15w49a.jar (or higher)
Q: There is no "loot_tables" folder within my world save, does it get created automatically?
A: It does not; the folder must be created manually.
Q: Why should I not use the "minecraft" namespace for new tables?
A: It is bad practice to use the default namespace for tables that are not default. There is also the risk of the filename you create being used in the future, resulting in unexpected overwriting of default resources. You should always put new loot tables into a separate namespace.
Q: Can I use target selectors for "entity"?
A: No, we are currently restricted to "this", "killer", and "killer_player".
Q: Can I use fake player scores for "entity_scores"?
A: No, we are currently restricted to "this", "killer", and "killer_player". You can use /scoreboard to duplicate the desired fake player score onto the killer or victim. You'll want to apply the score to as few targets as possible to save on scoreboard.dat bloating. For example, there will likely be fewer players compared to mobs in a CTM map, so you'll copy the fake player scores to the players ("killer_player") rather than to the killed mob ("this").
Q: Do I have to include "minecraft" before item IDs, condition IDs, and function IDs in loot tables?
A: No, the namespaces will default to "minecraft" when not defined.
Q: Accented characters/section symbol does not show up correctly in-game. What happened?
A: Your JSON file was not encoded in UTF-8. See Editing for info.
Q: What does "luck" do for default vanilla Minecraft?
A: The only thing luck affects in default vanilla is fishing loot tables. It is a common misconception that it affects mob drops or chest loot, but that is incorrect because default loot tables do not incorporate luck into anything except the fishing loot tables.
- Generic JSON Validator
- Minecraft Wiki: Loot table
- Javascript loot table generator by MrPingouin1
If there is information that needs to be added, corrected, or clarified, please post!
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
-
View User Profile
-
View Posts
-
Send Message
Retired StaffFixed, thank you! I'll be writing more about conditions once the custom tables bug is fixed for next snapshot.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
This is the only thing I can give...
*claps*
*claps*
*claps*
*claps*
*claps*
Oh, just 1 thing to ask:
If you can create a custom death loot by yourself,
does it mean you can create
infinity amount of different death loots
for every custom Mobs?
Erm... how to say....
I mean... Can I make an item,which has
a display name,lore, exact enchantment,
HideFlags like command blocks did?
Also, as it's javascript(I guess)
can I make that death loot with different
colors like the NBTEditor-S did?
Ya... just a question with bad english,
I hope for a complete and impressive reply.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffYep, you can essentially create as many loot tables as you want. NBT data can be applied with the "set_nbt" function. You can use the section symbol to change colors, but be aware that the section symbol's usage it deprecated. You'd essentially be providing the loot table the same NBT data provided in /give, although you will need to escape quotation marks:
{ "pools": [ { "rolls": 1, "items": [ { "item": "minecraft:diamond_sword", "weight": 1, "functions": [ { "function": "set_nbt", "tag": "{display:{Name:\"§kCustom Name\",Lore:[\"Line 1\",\"Line 2\"]},ench:[{id:1,lvl:3}],HideFlags:63}" } ] } ] } ] }As of 15w43b, custom loot tables now work (and we also have a new condition called "entity_scores", example). I'll be fixing up the thread later today/tonight to include new information and correct other things.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
So does it mean I can make a red-color-named item without any NBTEditor-S?
I want to make item have green lore and red name, but I can't do it in vanilla
as command blocks don't accept "§" this thingy.
Can you tell me, is this death loot the only way to make a colorful named item
without any plugins nor mods?
(Again, sorry for my bad english.)
Could you fix the set_nbt function nbt tag? When I try to put nbt data within the curly brackets, the command doesn't update. Otherwise, this is a perfect tool! Thank you so much!
-
View User Profile
-
View Posts
-
Send Message
Retired StaffThis is probably the easiest way, yes. There's another method using a sign's clickEvent alongside unicode, but that's a bit complicated.
Fixed, one of the new things learned from 15w43b is that both "weight" and "rolls" are required. The JSON for set_nbt, as well as the other examples, were missing "rolls".
Currently updating beyond that now.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
What do you mean by namespace? If I named a folder "Loot" and in that folder I had a folder named "chests" that contained the .json file for a custom loot table called "dogfood", I think I'd have to use a command like this: /blockdata ~ ~-1 ~ {LootTable:"Loot:chests/dogfood"} to set that as the loot table for a chest, but I don't know where to put the folder named "Loot".
-
View User Profile
-
View Posts
-
Send Message
Retired StaffYou've got the correct format! The filepath on the hard drive will be: /[world]/data/loot_tables/Loot/chests/dogfood.json
I've rewritten the section concerning location and attempted to clarify namespaces, so hopefully that helps.
I've also added the different conditions and corrected some minor mistakes with key types.
Last things left for the 15w43b rewrite are the "luck_multiplier" key and the Q&A.
EDIT: Seemingly finished, though I'll add more to Q&A as I think of other things or see other questions that would fit there. "luck_multiplier" happens to be unused. Apologies for the weird formatting for some of the examples, trying to figure out how to stop that from happening (since it seems to be totally random).
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHow I can give myself a chest with LootTable? I tried /give @p chest 1 0 {LootTable:"minecraft:chests/end_city_treasure"}, but doesn't work
-
View User Profile
-
View Posts
-
Send Message
Retired StaffThe "BlockEntityTag" holds potential tile data:
/give @p minecraft:chest 1 0 {BlockEntityTag:{LootTable:"minecraft:chests/end_city_treasure"}}Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOh, Thank you!
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttps://discordapp.com/channels/154777837382008833/412220958196367361/601600912187719711
Does the game automatically reload these lists (after saving edited list) or do I have to do something to reload them?
-
View User Profile
-
View Posts
-
Send Message
Retired StaffI'll update the thread later today to contain the changes. As of right now none of the examples will work in 15w43c.
You can press F3 + T in-game to reload resources, including loot tables. You can also exit the world and re-enter. I'll add that to the Q&A later!
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
if I make a server to play a map with custom loot tables with my friends, they will be fine or it will be affected as the resource packs?
sorry if my English is wrong
-
View User Profile
-
View Posts
-
Send Message
Retired StaffLoot tables are server-side, so the players cannot use resource packs to change it. To put it into perspective: it wouldn't make sense if a player's resource pack changes what a mob drops, otherwise anybody on a server could make cobblestone drop diamonds. The players themselves need nothing on their end.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
you misunderstood me (my fault... my english is awful) I mean whene someone makes a resourcepack intended for a custom map in single player you just need to put a rar file in the saves folder of the world...but it won't work in the same way if you make a server with some friends to play the same map so you will need to modify the server files to use the resource pack...I understood that this is not a resource pack my question is...if I make a map for multiplayer and make custom loot tables the folder with the JSON's will keep working?
again sorry if my english is wrong...
-
View User Profile
-
View Posts
-
Send Message
Retired StaffIn that case yes, you can keep the "loot_tables" folder with the save on a multiplayer server and it will still work.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
Oh.. I have something similar to ask.
I found that the loot table is in the version file.
How can I apply the custom loot table into different worlds?
(I heard that you can put a resource pack file into a world file,
so everytime a player enters the world, the resource pack will
immediately apply to it.Does this custom loot table need this way
to... work on independent worlds like the resource pack did?)