Module talk:LootChest

We may need some special thing that accounts for whatever shenanigans they are pulling that adds Golden Apples to Igloo chests, whenever we figure out exactly what is going on. – Sealbudsman ^talk/_contr 00:55, 22 October 2015 (UTC)

FYI, the "update (correct?)" was an update, not a correction. I re-confirmed that the module before your edits was correct for 15w42a and at least the bits you changed are correct for 15w43a. Anomie x (talk) 05:40, 22 October 2015 (UTC)

Thanks for double checking, that's great. – Sealbudsman ^talk/_contr 12:51, 22 October 2015 (UTC)

The golden apple is not in the igloo loot table, making me assume the golden apple is added before the loot chest is loaded, meaning it will almost always be added in the center slot, but then could rarely be overwritten by another item. –KnightMiner ^t/_c 14:33, 22 October 2015 (UTC)

I tend to agree. Anomie x, based on your explanation at Talk:Igloo#Verify_Golden_Apple, would you say that's accurate enough? Or based on your comment about it being buggy, do you think more is going on? – Sealbudsman ^talk/_contr 14:42, 22 October 2015 (UTC)

It was accurate enough. Specifically, the golden apple is included in the NBT data when the chest is placed from igloo_bottom.nbt, exactly like if you used /setblock. The buggy part is that saving loses the golden apple, so it gets lost if the chunk is ever unloaded before you open the chest.

Looking at 15w43b, though, they got rid of the buggy placement in favor of it actually being in the loot table. Anomie x (talk) 15:04, 22 October 2015 (UTC)

Note the loot table for igloo chests is now "2–8 from the list, plus one golden apple always", the apple isn't included in the 2–8. Anomie x (talk) 15:44, 22 October 2015 (UTC)

Ah, that's great. Yeah they added a second pool with the apple, after the 2–8 pool. Good solution. – Sealbudsman ^talk/_contr 16:30, 22 October 2015 (UTC)

So as of 15w44a, the abandoned mineshaft, desert pyramid, simple dungeon and bonus chests all use multiple pools. I suppose that's on my to-do list.. until multiple pools are implemented, those chests and the items in them can't be in any way accurate. Side note; showing 'weight' on the charts is becoming less and less useful I think. – Sealbudsman ^talk/_contr 15:50, 28 October 2015 (UTC)

All set. – Sealbudsman ^talk/_contr 14:30, 29 October 2015 (UTC)

At Chest loot, the Igloo column shows no items. Is this because it's incorrectly included in the main section rather than the "Upcoming" section? Seahen (talk) 05:00, 10 November 2015 (UTC)

👁 Image
 Fixed. – Sealbudsman ^talk/_contr 16:46, 10 November 2015 (UTC)

Good call, KnightMiner, your edit fixed the all-columns, all-chests variant. I agree with removing allRollsSpan, because I think you're right, its entire purpose is to factor in the empty columns, whereas the entire purpose of this edit was to hide them. – Sealbudsman ^talk/_contr 17:29, 10 November 2015 (UTC)

Since the only case they are needed now is for broken data (which should be fixed anyways), I say they can be safely removed. Though from a quick test I've noticed the third creation of the variable allRollsSpan does actually get "0" values. Since I am not exactly sure what it is doing there (in loop for j = 1, #ordered_item_rows[i] do), I don't have much to say on that one. The other two definings of allRollsSpan get only 1 or higher, so they should be safe to remove. –KnightMiner ^t/_c 17:54, 10 November 2015 (UTC)

In the big table, enchanted books are split into two lines, showing far apart, due to separate notes. This is probably fine, but ideally the initial sort ought to put them next to one another (somehow), and generally for any such other future split item. It took me several minutes to figure out why the first Ench book entry was not showing all chest entries; it wasn't obvious where the other entries were. I'll take a look if nobody does within a few days. – Sealbudsman ^talk/_contr 19:07, 5 March 2016 (UTC)

In the interest of not adding too much more complexity, I'm going to just leave it, because someone can just sort the table by name if they want similar names to group together as I'd described. – Sealbudsman ^talk/_contr 17:45, 6 January 2017 (UTC)

1. Move the large data table to its own module so it can be imported with mw.loadData for better performance.
2. Store the JSON data in pages directly to reduce maintenance and use mw.text.jsonDecode( mw.title.new( [[Module:LootChest/village_blacksmith.json]] ):getContent() ) to load it in the data table module (need to test jsonDecode performance though).
3. Reduce the HTML output so pages like [[Chest loot/All]] actually work (Tip: Special:ExpandTemplates doesn't have a limit, so you can load the template there to see the full output).
   1. Get rid of entirely empty columns (and maybe rows?).
   2. Set the entire table to be centred, then overwrite the centring for the few columns that need it (use col-n-left/right classes if possible), to reduce all the inline styles.

–Majr ᐸ Talk
Contribs 04:38, 11 April 2018 (UTC)

👁 Image
 Agree.  Cuervo^Talk 10:22, 18 June 2019 (UTC)

When does the random loot inside a Treasure Chest actually become generated? Specifically for Bedrock Edition, though this would surely be useful for other versions (if different). Is it possible to reload a past save before opening a chest to reroll the contents, and how far back would it have to be if so? (just before interacting with the chest, before generating the Chunk, etc. Jariesuicune (talk) 02:33, 2 August 2018 (UTC)

I'm almost entirely sure it happens when the chunk generates. Depending on how exactly the code works, it may be the case that the same chest on the same seed in the same version of Minecraft always generates with the same contents, too (IIRC speedrunners choose seeds partly based on exactly this behavior). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 08:46, 2 August 2018 (UTC)

So, that's talking Java Edition. Bedrock has a lot of "minor" changes (general gameplay-wise probably don't make much difference, but hard-core short-cutting/mechanics-oriented gamers switching over seem to be the ones that rage about them), and it seems that Java seeds do preset everything based on the seed, but in Bedrock it's much more relaxed on a number of things, allowing more variety even within a seed... I guess? Jariesuicune (talk) 23:47, 2 August 2018 (UTC)

There's a lot about Bedrock that I don't really know, since I've played very little of it myself, and almost all of that was years ago. Truth be told, this never even occurred to me as a potential difference between Java and Bedrock. If someone wants to, though, it'd be a good thing to test. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 01:06, 3 August 2018 (UTC)

In Java Edition, loot is only rolled at the moment the player opens the chest. You can use an NBT editor to check this. These chests will always contain a reference to a loot chest .json file, and no items, until the player opens it.

In Bedrock Edition, loot seems to be rolled sometime after chunk generation, but not very long after. I haven't been able to pinpoint it. In Bedrock Windows 10, you can generate a new world, or move around and generate new chunks, then open the level's ldb file or whatever it is, and see references to loot chest .json files, but when I would go to the area where that chest is, and check the ldb file again, those references were gone, which I took to mean that the loot has been rolled. One thing I haven't checked but I suspect, is whether it might roll loot when the chest is in simulation range. – Sealbudsman talk | contribs 17:29, 3 August 2018 (UTC)

Is there a reason there are two separate table for notes, one with the raw note text and one for the note text (duplicated) wrapped in ref tags? At one point in the code, the raw note text is used and the code handles wrapping it in a ref, but elsewhere the pre-wrapped notes are used instead. As far as I can see, there is no difference in the final result, and after checking, the actual note text is identical between them. Is there something preventing from just having a single table with the raw text and a simple function that wraps it in a ref tag? 「ディノ奴千？！」^{☎ Dinoguy1000} 17:19, 11 November 2018 (UTC)

That is just me not finishing my work yet, my apologies. Background: there's a discussion about using the French module's version of p.base2, which you currently see here as p.base3. That code uses the non-wrapped notes. The original English code in p.base and p.base2 uses the wrapped notes. I have kept both in the interim, intending to clean it up at the last step. – Sealbudsman talk | contribs 20:29, 13 November 2018 (UTC)

Fair enough, carry on. =) 「ディノ奴千？！」^{☎ Dinoguy1000} 21:06, 13 November 2018 (UTC)

I noticed that in all of the "enchant randomly" notes for Java Edition, it explicit excludes treasure enchantments from the possibility of random enchantment, saying "all enchantments are equally likely except treasure enchantments". This is just outright false, as this note appeared marking enchanted leather armor from shipwrecks, and I remember getting a mending leather shirt from a shipwreck once.--Milo359 (talk) 02:33, 13 February 2019 (UTC)

Java 1.14 and Bedrock 1.11.0 were released yesterday. -BDJP ^(t|c) 12:17, 24 April 2019 (UTC)

👁 Image
 partially done; I updated the "dev" pools to become the normal pools, but there is a scattering of loot information on the Villager page, which just serves to remind us that we should do a final correctness-check of both the Java and Bedrock pools, and clean up that mess. – Sealbudsman talk | contribs 04:47, 30 April 2019 (UTC)

In Chrome on Android, the top-left cell is one row too tall, and everything on the first item row is shifted one column to the right. Currently noticing this on Shipwreck (all three tables). Seahen (talk) 23:46, 12 May 2019 (UTC)

I noticed discrepancies like enchanted apple on bedrock. In game loot table suggests:

 chestName: abandoned_mineshaft
 appleEnchanted weight: 1 totalWeight: 71 minRoll: 1 maxRoll: 1
 calculated chance: 1.408%

 chestName: desert_pyramid
 appleEnchanted weight: 2 totalWeight: 232 minRoll: 2 maxRoll: 4
 calculated chance: 2.562%

 chestName: simple_dungeon
 appleEnchanted weight: 2 totalWeight: 127 minRoll: 1 maxRoll: 3
 calculated chance: 3.117%

 chestName: woodland_mansion
 appleEnchanted weight: 10 totalWeight: 645 minRoll: 1 maxRoll: 3
 calculated chance: 3.069%

Which is different from the Lua. --- Dualie (talk) 01:18, 27 July 2019 (UTC)

I noticed discrepancies like enchanted apple on bedrock. In game loot table suggests: Why is Bedrock missing so much data? Is anyone going to bring it complete and up to date? --- 107.3.140.189 02:25, 27 July 2019 (UTC)

So, I updated Bedrock 1.13.3 values (only Bonus chest affected)

I notice that large amount of missing data on the Chest loot bedrock table has something to do with the chest having poolsBedrock = {}.

It is only displaying values for the chests that differ from Java, not empty "{}"

From the notes in the module...

-- NOTE: ...
-- * If poolsJavaUpcoming is omitted, poolsJava will be used. To omit a pool entirely, set it to {}.
-- * If poolsBedrock is omitted, it implies that Bedrock has the same pools as Java. This is a shortcoming; it ought to be made explicit somehow.

If poolsBedrock = {} is used, this does not 'omit the pool entirely,' but just leaves all data missing/dashed "--" on Chest loot page.

Commenting out poolsBedrock line (possibly to 'imply same pools as Java') actually omits the chest entirely from the table (messes up the columns.)

--49.178.18.246 13:23, 3 December 2019 (UTC) (I spent an hour trying to signup, but it's broken)

This is not acceptable at all. A module with >3000 lines, of which only some are code. I'd do that myself, but I'm doing other stuff now, so I'm leaving it here as a note. --AttemptToCallNil (report bug, view backtrace) 02:59, 16 March 2020 (UTC)

Many of the new 1.16 loot tables use multiple of the same item in the same pool. For example, the bastion treasure loot table has an entry for 1 ancient debris with a weight of 10 and another for 2 with a weight of 5. This currently isn't represented by the tables. -PancakeIdentity (talk) 20:36, 18 April 2020 (UTC)

Tables generated by this module on my machine have two rotateX(180deg) CSS modifiers which probably should cancel each other and do nothing but in practice it actually adds unpleasant blur effect to the table contents. Can someone fix it so that none are added? I'm using Firefox if that helps. 92.38.77.101 22:45, 27 January 2021 (UTC)

This module seems to have a small deviation in third decimal place, please verify.--Star Zero · 维基假期中 14:34, 27 April 2021 (UTC)

Chance calculation gives the wrong percentage when the minimum stack amount is 0. This can be seen in the loot table for the Buried Treasure where the the chance for the Potion of Water Breathing should be be 2/3 and not a 100%. Jopejoe1 (talk) 19:23, 19 February 2022 (UTC)

So every item that can naturally generate in chests shows an error in its 'Chest loot' and 'Natural generation' sections. The error is as fllows "Lua error in Module:LootChest at line 3653: attempt to index field 'items' (a nil value)". And therefore no Loot generation table is visible in any wiki page.Mr.Axe616 (talk) 09:45, 10 June 2022 (UTC)

Do you have a specific example? I ask because I just picked a page (music disc) and the table looked OK. - AD OffKilter (talk) 02:58, 11 June 2022 (UTC)

That's because it's been fixed in the meantime --MetalManiacMc at your service fellow human! (talk) 06:05, 11 June 2022 (UTC)

A few loot tables have entries for the same item twice within the same pool. For example, the first pool of JE's bastion-hoglin-stable has two entries for ancient debris. The first gives 1 ancient debris, and the second gives 2. In game, it's possible to roll either entry, but because of how the data is represented in Module:LootChest/chests, only the second entry is used in this module. This makes it seem like you can't get just 1 ancient debris from hoglin stable chests, which isn't the case. It also messes up the calculated probabilities of the items in the first pool.

Here is how Module:LootChest/chests represents that first pool's entries:

items = { ["damaged-random-enchanted-diamond-shovel-2"] = {1,1,15}, ["damaged-random-enchanted-diamond-pickaxe"] = {1,1,12}, ["netherite-scrap"] = {1,1,8}, ["ancient-debris"] = {1,1,12}, ["ancient-debris"] = {2,2,5}, ["saddle"] = {1,1,12}, ["block-of-gold"] = {2,4,16}, ["golden-carrot"] = {8,17,10}, ["golden-apple"] = {1,1,10}, }

This Lua table assigns a value to the key "ancient-debris" twice, so the second one overrides the first. ZachRW123 (talk) 05:01, 14 September 2023 (UTC)

Oops, this was already mentioned on this page. I assumed the top had the latest posts... ZachRW123 (talk) 05:06, 14 September 2023 (UTC)

Currently, all of the structure changes in the Villager Trade Rebalance are improperly listed as upcoming for 1.20.2 (additionally it says the current version is 1.20.1, also false). This is very misleading and has caused the loot table sections of the outpost, mineshaft, ancient city, desert pyramid, and jungle pyramid pages to be cluttered with additional incorrect information. Instead I believe there should be a new section added for the experimental changes or some similar solution. That way, these tables that have been made can be put to use in an appropriate section (either a new page on the villager trade rebalance, or onto the bottom of the 1.20.2 changelog page which currently hosts all of that new information).Quidvio (talk) 20:03, 6 October 2023 (UTC)

The reason for this is that the loot table on Vault's page says that it is loot for 1 container, but the vault is not an actual container. The vault's NBT data does not let it contain items directly at any point in time. Furthermore, functionally, the vault contains infinitely many items, since infinitely many different players can use it. Also, the vault's loot will be changed in the future, so there is no harm in giving it a separate loot table anyways. --Simanelix (talk) 15:51, 3 February 2024 (UTC)

👁 Image
I wasn't sure at first but I think I agree. Partially because Mojang is going to completely change the loot anyways. And partially so they loot chest item usage (on for example the Diamond article) mentions that it can both be found from vaults and from rewards chests. From a survival gameplay perspective these are totally different. — Misode (talk) 17:54, 3 February 2024 (UTC)

The vaults rewards are more complex now, and now I am wondering if the "reward chests" are different than the vault. --Simanelix ^(T|C) 16:30, 3 May 2024 (UTC)

👁 Image
I've went ahead and replaced the terminology of "reward containers" with that of the "vault". -- PanchamBro (talk • contributions) 19:17, 3 May 2024 (UTC)

Simply renaming the current one to vault is not correct. Because this table is also used in actual reward chests. — Misode (talk) 19:54, 3 May 2024 (UTC)

I thought the reward chests are their own separate loot table? Or are you saying that there are chests that pull from the loot table of vaults? I don't see this info on Trial Chambers. -- PanchamBro (talk • contributions) 20:03, 3 May 2024 (UTC)

There are no more reward chests. They have been completely replaced by vaults. Sorry to hijack this disscussion, but I'm actually trying to fix the line above the loot table for the vault. The one that says "In Java/Bedrock edition, each trial chambers vault and reward chest contains items drawn from 3 pools, with the following distribution:". Specifically, the part where it says "vault and reward chest contains". Since vaults completely replaced reward chests, I'm trying to remove the "and reward chest" part. So far, I've only managed to fix this description for the "container" type that appears when you go to a specific item's page (take Trident as an example and look at the generated loot table for that item). But the text above the loot table that I just mentioned seems to be in an entirely different place. Just wondering if any of you happen to know anything about where that might be, so I can fix it, because this has been bugging me for years almost a year now. Milo359 (talk) 14:48, 16 January 2025 (UTC)

Reward chests still exist and still share the same loot table as vaults; they generate in rubble. - Zamburger (talk) 20:56, 16 January 2025 (UTC)

Well, that's a critical reading/thinking failure on my part. I didn't look at combination of the timestamps and the fact that people were still talking about the reward chests as if they existed, and just assumed like an idiot that they were talking pretty soon after the vault was added. Even worse, I had checked which snapshot the vault was added, and it was added in a January snapshot! I guess I was just in a hurry this morning and didn't stop and think before editing... I'll go ahead and add some comments to the relevant pages so nobody else gets confused as to where these reward chests are.

On a related note, it seems like bug behavior, so I checked it out, and it's actually on the bug tracker too, at MC-275403.

Milo359 (talk) 22:03, 16 January 2025 (UTC)

Actually, is it possible to add this bug link to the table summary and the container field? Would be good to put there, as it's completely relevant and would help raise awareness for the bug. Milo359 (talk) 22:04, 16 January 2025 (UTC)

Understandable oversight! It's indeed a bit odd and has originally not been noticed on the wiki for months (Special:Diff/2746917)! :)

Referencing the bug might be a good thing to do, yep, though I personally wouldn't know how to do that without breaking the module or changing it too much.

Also, although they're named "reward chest" in the files, it might be for the best to name them "rubble chest" so that they cannot be confused with supply chests (entrance and cache_1). - Zamburger (talk) 22:15, 16 January 2025 (UTC)

Sorry, I should have made this clear. Do you know to which page I should go so I can edit the "In Java/Bedrock edition, each trial chambers vault and reward chest contains items drawn from 3 pools, with the following distribution:" description to add the bug link on? I'll also change "reward chest" to "rubble chest" to clarify that. Milo359 (talk) 23:08, 16 January 2025 (UTC)

I'm unsure, sorry. - Zamburger (talk) 09:58, 17 January 2025 (UTC)

The avg. # of containers to loot just takes the chance of item per container and takes its reciprocal. This is wrong since opening chests/container/whatever follows a binomial distribution. Pwaves (talk) 13:33, 23 August 2024 (UTC)

Right now, the page for Emerald says that you have a 4.4% chance of getting one from brushing suspicious gravel in a trail ruin, while the Music Disc Relic page says that you have a 8.3% chance of getting one. However, the tables don't specify that only "common" suspicious gravel blocks can contain emeralds, while only rare suspicious gravel blocks can contain music discs. I think the name of the "container" in that table needs to be updated to specify whether you get it from "common" or "rare" gravel blocks, but I don't know how to do that myself. The other items that drop from suspicious gravel blocks have the same issue. CitrusEgg7168 (🍊 ✏️) 00:04, 23 September 2025 (UTC)

👁 Image
 Fixed. --MinecraftExp123^{(talk|contribs)} 00:56, 23 September 2025 (UTC)

The spears appear to be missing from Module:LootChest/items and Module:LootChest/chests. I barely know Lua so I don't know how to add them, and also I don't know where in the game files are the loot tables stored. Can someone add them? --MinecraftExp123^{(talk|contribs)} 11:13, 12 October 2025 (UTC)

Update: I added the spears to the /item submodule by mimicking the syntax of the other entries. --MinecraftExp123^{(talk|contribs)} 11:20, 12 October 2025 (UTC)

Done. :) - Zamburger (talk) 11:45, 12 October 2025 (UTC)

Retrieved from "https://minecraft.wiki/w/Module_talk:LootChest?oldid=3419064"