Generic info

Intro

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]

Common errors

1. Couldn't find resource table minecraft:tablename

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.

Files

Location

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.

Editing

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.

Loot construct

General info

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

"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.

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.

Entries

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.

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.

Rolls

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.

Bonus rolls

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.

Items

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.

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.

minecraft:stone, minecraft:stick, minecraft:stick

Quality

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

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.

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.

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).

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.

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".

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.

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.

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.

Conditions

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.

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.

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).

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.

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.

Duplicate functions & conditions

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.

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.

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.

Usage

generic.luck, Luck, Unluck, Luck of the Sea

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:

/effect @p minecraft:luck 30 9
/effect @p minecraft:unluck 30 3

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):

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.

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

Custom table example

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&A

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: 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: 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.

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).

The latest snapshot 15w43c introduced a new loot table mechanic, alongside new loot tables for fishing that make use of this mechanic. Instead of the "item" key we now have the "entries" key, and each entry (previously item) in the list must now define a "type" key. So far I have seen the types "item", which produces an item as before, and "loot_table", which allows you to include one loot table as an entry in another.

You can check out the new fishing loot tables for proof. They also make use of a (what seems to be) new "luck" mechanic. I'm not sure what this is about yet.

I have testing to do, but I think this sub-table property will allow for the reuse of loot tables and potentially very complex loot table hierarchies. This new loot table system is really turning out to have a lot of potential!

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.