Minecraft Wiki
Advertisement
Old discussions (through October 2015)

Golden Apple in the Igloo[]

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)

Multiple pools[]

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)

Igloo loot table is empty[]

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)

 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)

Feature request idea[]

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)

Suggestions[]

  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.

MajrTalk
Contribs
04:38, 11 April 2018 (UTC)

 Agree.  CuervoTalk 10:22, 18 June 2019 (UTC)

Chest Loot Generation Timing[]

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)

Notes[]

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)

Treasure Enchantments[]

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)

Needs to be updated[]

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

 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)

Bug: extra header cell on mobile[]

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)


Is the data in the lua up to date for Bedrock?[]

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)

Bedrock Missing Data[]

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)

Extract data to their own modules[]

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)

Support for multiple of the same items in the same pool[]

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)

Blurry text[]

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)

data deviation[]

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

Chance calculation does not take min. 0 stack amount into account[]

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)

Error in line 3653 ![]

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)

Duplicate items within the same pool are ignored[]

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