Talk: Loot table

luck_multiplier

Looking through the code, it appears that the variable is supposed to vary the weight of the item based on some input variable (which we may as well call "luck"): the formula is effectiveWeight = floor( weight + weight * luck_multiplier * luck ). But it looks like in all cases the "luck" input is currently zero. Anomie x (talk) 12:40, 23 October 2015 (UTC)

I would assume that is related to the Potion of Luck Dinnerbone mentioned. The idea is things like potions and enchantments could affect loot even from chests. –KnightMiner ^t/_c 13:28, 23 October 2015 (UTC)

set_damage

The information on the page is true, tested in 15w43c. 84.10.230.247 11:57, 24 October 2015 (UTC)

Thanks for testing that. I removed the verify tag. –KnightMiner ^t/_c 15:22, 24 October 2015 (UTC)

"Modded/Custom Maps"

Just wanted to point out that custom namespaces ("thaumcraft" from the example) will work. Loot tables are already set up for mods and custom maps. However, I'm not sure how to rewrite it since there's a lot of redundancy or false information; there probably doesn't need to be two separate sections. We are expected to not use the "minecraft" namespace unless we're specifically overwriting the default tables. As such, we should not be adding new tables inside "minecraft", but rather inside our own namespace ("thaumcraft", "custom_vanilla_map", "skylinerw_tests", etc). I have examples of usage here if needed. Skylinerw (talk) 07:39, 28 October 2015 (UTC)

If we need to mention mods at all (IMO we probably don't, we don't mention mods in most other places on the "main" wiki), something like this should do: Loot tables for mods will similarly go into paths under the data/loot_tables/ directory, e.g. the loot table for a "Scary dude" in "MyCoolMod" might go in data/loot_tables/mycoolmod/scarydude.json with LootTable set to "mycoolmod:scarydude". See each mod's documentation to determine which loot table names are used by default. Anomie x (talk) 10:36, 28 October 2015 (UTC)

I mean more in general terms, since custom loot tables are not restricted to mods. As it stands, the page implies you have to use the "minecraft" namespace to add new table, which is incorrect (and it's not recommended to do that). But there's still usage with the "minecraft" namespace to replace default tables, so the current "Custom maps" section does mention it correctly. I'm just not particularly good at wording something for a wiki! Skylinerw (talk) 11:02, 28 October 2015 (UTC)

I wrote the original "custom maps" section. I moved all the content into the Usage section and changed it to talk about namespaces. I'm new at this, though, so tell me if I did anything wrong. Update: I also just noticed I can't remove the old section because I'm a new user. --Kittycat3141 (talk) 11:16, 28 October 2015 (UTC)

What's the difference?

I don't know the difference between LootTable and LootTableSeed. I assume that LootTable lets you input your table right then and there, and LootTableSeed would be the pre-existing table you wish to use. However, a useful site tells that LootTable would be a pre-existing table, mainly tables that exist in that world. Could someone please tell me which one is which? The site is minecraft.tools. Fyreboy5 (talk) 20:41, 2 December 2015 (UTC)

LootTable is which loot table should generate the random loot, and LootTableSeed is a seed in the sense that it seeds the random number generator (see also wikipedia:Random_seed), much the same idea as the seed of a minecraft world. Each different seed will generate different loot from a given table. Make more sense? – Sealbudsman ^talk/_contr 20:57, 2 December 2015 (UTC)

No. I want to know if it is possible to set a chest with a loot table without going into the file, so I think that LootTableSeed would let me create one exactly, as to minecraft:diamond_chestplate. Fyreboy5 (talk) 13:17, 4 January 2016 (UTC)

If you define LootTableSeed, then that chest and any with the same seed will always have the same contents, the main point is to make sure Minecraft world and custom maps always have the same loot.

So you can add a chest with the loot table using /setblock, though if you want specific contents all the time (rather than starting with random ones) it might be easier to just /clone a filled chest. –KnightMiner ^t/_c 15:31, 4 January 2016 (UTC)

I want it to be random every time I open the chest, but I have a new idea how. RawLootTable and RawDeathLootTable will allow you to make a loot table for that mob or container in the command itself. If applied to a mob or container with another LootTable or DeathLootTable, it will roll so that 50% would be LootTable, and 50% would be RawLootTable. The way to put it in is to do it the same way as adding it to maps, but with the setblock or summon command in front, and no quotations. Fyreboy5 (talk) 18:09, 14 January 2016 (UTC)

This isn't the place for suggestions. For that, you want https://www.reddit.com/r/minecraftsuggestions. Anomie x (talk) 22:55, 14 January 2016 (UTC)

Thank you. I will suggest. Fyreboy5 (talk) 15:15, 28 January 2016 (UTC)

It is unclear that what is the order of application of functions.

111.194.108.33 12:28, 23 February 2016 (UTC)

List of loot tables link dead

There is a list in the "data packs" section to a list of loot tables. That takes you back to this page. Where is that list now?

5.71.59.57 14:07, 4 May 2019 (UTC)

It's collapsed (click the "Show" button to see it) in the section directly above. --AttemptToCallNil (report bug, view backtrace) 14:24, 4 May 2019 (UTC)

Ore Drops Formula

I can't seem to understand what the ore drops formula is. It says count * (max(0, random(0..1) - 1) + 1). However, this doesn't make sense. What I understand is count * (the highest value out of 0 and (random number between 0 and 1 subtracted by 1)) + 1. Wouldn't this always result in just the count? I'd love if someone could help me out, and I also think the formula needs rewriting on the main page to make it more easily understood. -PancakeIdentity (talk) 17:34, 9 June 2019 (UTC)

tool_enchantment

tool_enchantment is under conditions, but from the description of how it works, it sounds like it belongs under functions. I can't find it used anywhere in the vanilla datapack for comparison. Can someone check where this belongs? --NickNackGus (talk) 00:11, 13 July 2019 (UTC)

I've read it over again, and now it makes sense as a conditional and as a function.

The part that confused me was "List of enchantments that need to be applied to the tool." This can be read as:

• Stating an action that is to be taken: "List of enchantments that need to be applied to the tool by this function." This makes sense if the loot table contains a tool, and we are trying to enchant it.
• Stating a description that must be true: "List of enchantments that need to be applied to the tool used to generate this loot table." This makes sense if we're using a tool to get items from a loot table, such as killing a mob with a sword, or breaking a block with a tool.

Can anyone think of a less ambiguous, but not too verbose way of writing this? --NickNackGus (talk) 03:14, 13 July 2019 (UTC)

Seems like you've written it yourself, "List of enchantments that need to be applied to the tool to generate this loot table". -PancakeIdentity (talk) 03:18, 13 July 2019 (UTC)

Binomial distribution of rolls

I found in a loot table generator that rolls can also have binomial distribution. I haven't tested in game yet. Should I add that to the JSON format?--ManosSef (talk) 08:14, 26 April 2020 (UTC) Now I just found that all min-max values can also have binomial distribution. I will test in game.--ManosSef (talk) 08:25, 26 April 2020 (UTC)

Bedrock Edition

This page currently only covers Java Edition, while bedrock has loot tables too, it also has no exclusive template or link to a bedrock loot table page. Somebody mind adding the into/link? (I have no idea if the wiki has it at all) FVbico (talk) 16:04, 3 May 2020 (UTC)

tool_enchantment again

Misode in his loot table generator has not added this condition because as he said: "from my testing it appears this condition never made it to the final release". Maybe I will test it and remove it, but do not revert if I do. ManosSef (talk) 20:07, 23 June 2020 (UTC)

Formula to calculate the loot tables

Hello, I would like to know what is the formula to calculate the loot tables, I am creating a loot table and I would like to know the probability of each loot -Syhix

Hi, is there a part of the page that is unclear? Or is the info you seek missing from the page proper? If you could provide more detail on what you're looking for, that would help us figure out what to do. ExpertCoder14 (talk) 06:56, 4 March 2022 (UTC)

Hello, I would like to know the method of calculation to find the percentage of each item in a chest. For example, the chests of the Ancient City. SyhixTV (talk) 13:28, 4 March 2022 (UTC)

Custom Loot Table on Server

What path should I use to overwrite the loot tables on a server? For example, if I'm trying to override the fishing treasure table, do I make a file called treasure.json, and place it in [world]/data/minecraft/loot_tables/gameplay/fishing/? Or does it belong somewhere else? The article goes into great detail about how to modify aspects of loot tables, but I'm unclear as to where to put the relevant json file. 71.11.176.25 03:52, 7 July 2022 (UTC)

 Comment I think you would need to create a data pack. The file needs to be in a pack and in the right location, something like data/loot_tables. The wiki page should get you pointed in the right direction. - AD OffKilter (talk) 04:12, 7 July 2022 (UTC)

Ok, that's helpful! So should the path be [world]/datapacks/[datapack name]/data/minecraft/loot_tables/gameplay/fishing/? 71.11.176.25 04:21, 7 July 2022 (UTC)

I tried it but the server doesn't seem to recognize it as a valid datapack? 71.11.176.25 05:25, 7 July 2022 (UTC)

 Comment Hard to say. I just tried to make a pack here and replace fishing loot and it did work. Make sure you have the .mcpack file in [world]/datapacks/[datapack name] as mentioned on the data pack page. Inside that folder put the directory you pointed out above (data/minecraft/loot_tables/gameplay/fishing). The files must be named fish.json/treasure.json/junk.json. In my test I replaced all fish with just an item frame. If the pack is well-formed, it should in the list generated by /datapack list. I'm not sure if you can change the % of which file it pulls from. - AD OffKilter (talk) 06:46, 7 July 2022 (UTC)

What I didn't understand is that editing loot tables REQUIRES making a datapack, and datapacks require making a .mcpack file, so in order to edit loot tables you have to make that .mcpack file. I understand now! I think this article could be a little clearer on that all such changes require making a datapack. 71.11.176.25 20:55, 7 July 2022 (UTC)

Planned refresh upcoming to this page

It seems like this page has been edited to change the term “loot table entries” to the term “loot pool entry producers.”

These are terms that I don't recognize in the context of loot tables. It has been customary to always refer to them simply as “entries.”

As an experienced data pack developer, I plan to update this page similarly to how I have done so to the Predicate and Item modifier pages. I plan to revert this change in terminology as well as update the sections to look similar to those of the pages I have already refreshed. I may also choose to refine the treeview of the loot table fields, similarly to how I have refined those of Advancement/Conditions/entity and similar pages.

If there is any reason to why the term “loot pool entry producers.” should be kept, please let me know. Until then, more details of my works are to be announced.

Regards,
ExpertCoder14 (talk) 18:03, 15 July 2022 (UTC)

I was going to revert those because they were being added without explanation, but I was not familiar enough with the subject to revert edits made by someone who seemed more familiar. If they are wrong, then by all means revert them. We cannot have incorrect information here. Amatulic (talk) 18:45, 15 July 2022 (UTC)

Thanks for your input. It is possible that “loot pool entry producers” is the name used in the game's code to refer to these items, similar to the terms “loot condition ” and “loot function,” and the latest edit was made to make the article reflect that. However, the wording of the wiki should, in most cases, be the one that is accurate while still being easy to understand, not bent over backwards to appease the wording in the source code.
Therefore, I'll revert the latest edit and invite the editor to join the discussion if they like. ExpertCoder14 (talk) 04:36, 16 July 2022 (UTC)

While I've not heard the specific term 'loot pool entry producers', I do know that internally there is a concept of loot pools and loot pool entries. That said, I don't know if it's warranted to be that specific on this page or not. - AD OffKilter (talk) 19:14, 15 July 2022 (UTC)

In the context of loot tables, loot tables are comprised of pools, which each contain entries. The terms that would be the most intuitive, in my opinion, would be “loot table pool” and “loot table entry”, making it abundantly clear that these items are present in loot tables and loot tables only. ExpertCoder14 (talk) 04:38, 16 July 2022 (UTC)

I changed the term “loot table entries” to the term “loot pool entry producers” because they are not entries. And they cannot be called "entries" anyway.

If you are an experienced data pack developer, you can notice that the "weight" field doesn't take effect in "sequence", "alternatives" or "group". And, in the child of their "children" list, the "weight" field sometimes takes effect.

It's because that weight is applied on entries, instead of entry producers. When looting from a pool, in each roll, these entry producers will produce entries into the pool. Then one entry (rather than entry producer) is chosen as a weighted random selection from all entries in this pool. Producers with the type of "item", "tag", "loot_table", or "dynamic" will produce one or multiple entries with the specified weight into the pool. And "sequence", "alternatives" and "group" are special entry producers: they provides other entry producers (in their "children" list) instead of entries.

Only if we understand that "weight" is the weight of the entries in the pool, instead of entry producers in the json list, can we control the chance of each item stack being dropped, especially when "sequence", "alternatives" or "group" is used.

So I revert your edit, If you're still unclear, you can ask me and I can provide you some examples.--Chixvv (talk) 17:03, 25 July 2022 (UTC)

And fyi, they are called "loot entry" and "loot entry container" in the games's code. I called it "loot entry producer" because it's more aaccurate and easy to understand.--Chixvv (talk) 17:21, 25 July 2022 (UTC)

I would like to preface this by remarking that every fact that you have stated in this is correct. You are correct that technically, these aren't true “entries,” they are simply data that, when invoked, produce entries for the pool to consider when it is rolled. You are also correct in that weight is sometimes applicable, and sometimes it is not. I completely understand where you are coming from, which is why I have updated my opinion on these changes.

First, concerning the change in tree structure. Only after reading your reply here do I notice that you have made it more clear that  weight,  quality,  name, and  expand are only applicable to certain types of entries. I can agree that before, it may not have been clear that these fields only apply to certain types, so your edit certainly helped clarify things on that regard. When I jump in and make my planned refresh to this page, I will definitely ensure that the clarity of this is kept.

Then, regarding the changes in terminology. Your mindset while choosing the terminology to display on the page seems to match the ideology of prescriptivism, where there is a Correct Way to Speak Handed Down From High, in this case Mojang, and where every term must accurately portray that which Mojang coined while creating loot tables, “entry containers,” and the like by being either exactly, or close to that term. Unfortunately, I do not believe that this should be the case.

I believe that the job of the Minecraft Wiki is to be a useful reference to the community so that they can easily find the information they need, quickly, without being confused or disoriented. The best way to do that, in my opinion, is not by being prescriptivists, but by being descriptivists instead. The Minecraft Wiki should not dictate how people should call these items, it should dictate how people do call these items. If common terms for an item change, say, the entire community suddenly starts calling them “Geralds,” then the wiki's job is to adapt to that and change the name of the item so that they are called Geralds, whether Mojang intended to call them that or not.

So even if Mojang did coin the terms as “loot pool,” “loot entry container,” “loot condition,” and “loot function,” that doesn't mean they get to decide how the community commonly calls these items. Even the gold standard loot table generator, misode.github.io, still simply calls them “pools” and “entries.” Why? Because that's how the community commonly refers to them. Although your terms are technically correct, there's a good chance that the community may not understand them at first glance. And that, is what we don't want.

I used to have that same mindset that you had when you made this edit. I was actually the one who introduced the terms “loot condition” and “loot function” to the Minecraft Wiki in the first place, all the way back in revision 2071707, and also did the same to the Predicate page and the Item modifier page. But as I have realized, I was wrong the entire time. “loot condition” and “loot function” aren't common terms at all, in fact, I have probably never heard those terms anywhere besides people talking about the game code. I've tried making several more edits to make the pages more clear and correct, but I've never had the chance to reverse my mistakes entirely. That's why I planned to make an upcoming refresh to this page.

I now see that there is some merit to your edit to make additional distinctions. However, the issues of terminology are also ones that need to be corrected. What I will do at this point is to make a minor edit to correct the terminology issues, whereas the structure that you have created will remain intact. I still plan to return to this page at a later date to make further amends to this page.

Thanks,
ExpertCoder14 (talk) 23:56, 25 July 2022 (UTC)

Note that a "minecraft:group", "alternatives", or "sequence", etc. will never be chosen as an entry when looting from a pool, because they are entry producers rather than entries in the pool. When looting from a pool, each entry in the pool are considered as a weighted selection. However, a producer such as "group", "alternatives", etc. is never in the pool: only the entries produced by them are in the pool. The weighted selections are the entries produced by these producers.

I changed the term because it was wrong, not because of prescriptiveism. I hope you can figure out how these producers work in a loot table.--Chixvv (talk) 03:41, 26 July 2022 (UTC)

In other words, it is easy to mislead people into thinking that a "group" or a "sequence", etc. is an entry to be chosen as a single selection. In fact, these entry producers are never in the pool, and aren't selections that will be chosen when looting from a pool. They just provides other entry producers that add entries into the pool. The probability of each entry can be calculated only if you know what is an entry and that entry producers are not entries to be selected.--Chixvv (talk) 20:18, 26 July 2022 (UTC)

I can assure you that I have a solid understanding of how the group, alternatives, and sequence entries work. In fact, they are not actually real “entries” they are what I would call “entry groups.” These specific ones, instead of being an entry, they contain entries, and are expanded into entries when they are processed.

• Entry groups of type group expand by returning all children.
• Entry groups of type alternatives expand by returning the first child whose conditions pass.
• Entry groups of type sequence expand by returning all children in order up to the first child whose conditions fail.

The loot table does not roll and pick these “entry groups,” rather, these entry groups are expanded until the entire pool is contained of just single entries. Only then is the pool rolled, and the chosen entry dropped.

You stated that it is incorrect to refer to group, alternatives, and sequence entries as actual “entries,” and are correct that these terms need to be changed. However, by fixing one problem, you created another: the section titles were now terms that are not understood by the larger community as a whole. I made the same mistake by introducing the terms “loot condition” and “loot function” to the Predicate and Item modifier pages respectively.

We both know that the term “entry” is wrong. But unfortunately for us, most people use “entry” to refer to these, even though they are wrong! We are the small percentage of people who know what's actually up with these “entry producers” and we know what the technically correct terms are. We know the right terms, but unfortunately for us, the majority of the people use the wrong terms. In fact, I would reckon that the majority of people have probably never heard the term “loot pool entry producers” in their time as a data pack developer, and if they have, they probably needed clarification such as “sorry, you probably call them simple ‘entries.’”

It's not right to change the terms to be technically correct if no one will understand them. If you want the section headers to say “loot pool entry producers,” then what you have to do is you have to make that become the common term. If the majority of people start calling them by their technically correct name, then it would make total sense to update the section headers to reflect that. But unfortunately, that's not the case right now. Many loot table generators like misode.github.io, and many development communities like r/MinecraftCommands still use “entry” to refer to everything, including group, alternatives, and sequence. You'd be correct to say that they are wrong. But they have an influence too on how we call these items. In fact, I daresay they have almost as much influence as we do. To allow for the easiest cross-referencing, it is, honestly, probably better that we stick with terms that are somewhat incorrect, because they match with the terms of these websites.

It is, in my opinion, not a good idea to change the terms to be technically correct when only experienced developers will understand them. We want the Minecraft Wiki to be easily accessible and readable by all, no matter their developmental skill. The wiki is hard enough to understand by newcomers. Using technically correct but rarely used terms will only make it harder for them. I think it would be best if we compromise on being technically correct in favour of being easier to read and understand by people of all skill levels, including newcomers. Even if that means using an incorrect term.

I have full confidence that you are not a prescriptivist. I'd actually like to thank you for pointing out these issues, which are both relevant and important. However, the way that you suggested we correct these errors is, in my opinion, not the best for the Minecraft Wiki. In fact, after considering your perspective, I am willing to amend my current proposal of changes to reflect what you would like to see on this page. After all, this page is, at least in part, a form of technical documentation. So I can see where you are coming from when you propose that we use the technical terms instead of the common terms.

My proposal is that we include the technical term alongside the common term, as a form of a subtitle or part of the paragraph immediately following the section header. For example:

Predicates, technically known as loot conditions, are the main structure used to check conditions in loot tables.

This structure acknowledges the technical term, but uses the common term as primary. The same can be done with item modifiers, and the pools and entries that go here. We don't lose out on the technical terms, yet the page is still easy to understand, hopefully by newcomers as well, with the common terms, which are easy to understand. I'll even go with the actual term “loot entry container” for these subtitles to ensure that it is named with the correct technical name. Why can't we just put both terms? Satisfy everybody!

I'll probably push out these proposed changes in the coming days, and that may or may not be the day I complete my full page refresh, to look similar to Predicate and Item modifier. Either way, I hope that you are satisfied with my proposals, and if you would like to suggest changes, please feel free to get back to me anytime.

Regards,
ExpertCoder14 (talk) 01:13, 27 July 2022 (UTC)

Maybe you are right. I'm looking forward to your changes.--Chixvv (talk) 02:49, 27 July 2022 (UTC)

I checked yarn deobfuscation today, and they are called "loot choice" and "loot entry". Maybe these two terms also good choises that are easy to understand.--Chixvv (talk) 19:04, 27 July 2022 (UTC)

Clarification needed on loot table behaviours

I'm planning to revamp this page soon, similar to how I've done with Predicate and Item modifier. Recently, in the discussion directly above, I discussed several terminology choices to make the choice that would be the best for the wiki.

In my planning to revamp the page, I did come across a question that I would like to have clarified, so that I know what is the correct wording to write:

Previously, the descriptions for the alternatives and sequence entry group types read as follows:

A list of entries of which the first, and only the first, successful entry gets generated.

A list of entries that are used until the first entry fails. After an entry fails, no more entries of this list are generated.

In recent edits, this has been changed to say that alternatives picks the first child whose conditions pass, and sequence continues to return children in order until an entry's conditions fail. I would like to confirm that said edits are correct.

Is the only reason for a child to be considered “failed” because its conditions did not pass? Or are there other reasons, besides non-passing conditions, that would cause an entry to fail?

I would appreciate any answer that you can provide.

Regards,
ExpertCoder14 (talk) 18:09, 27 July 2022 (UTC)

I'm sure that the only reason is whether its conditions pass. Both practice and code prove so.--Chixvv (talk) 19:04, 27 July 2022 (UTC)

Sooner or later…

Just wanted to post a quick update just in case you were wondering about my wiki update.

I had some ideas for updating the page, but at this time I don't have the time on me to commit those to a fully-fledged new version of the page.

Due to personal reasons I probably will have to return at a later date when there is more time to consider this page. Feel free if you want to edit further; I'll reassess the page when I can return to work on it.

Regards,
ExpertCoder14 (talk) 05:44, 18 September 2022 (UTC)