- 2010 – 2013
- Current
Block data/block entity data/block state for large chest[]
I see nothing in the data section that distinguishes a small chest from a large chest (such as whether it is one, and if so which block cell contains the other half). At the very least, this information is indispensable for rendering, and I would think for game mechanics such as shift-clicking. Is it missing, or is it stored somewhere we don't document? — Auldrick (talk) 02:46, 16 January 2017 (UTC)
- Additional info: This question came up when I was researching large chest behavior for MCPE-17964 (which I submitted quite some time ago but Mojang hasn't touched it yet). It turns out that in Win 10 Edition (at least) whichever small chest you place first becomes the top half of the inventory after you make it a large chest. It doesn't matter which side you place the second chest on, nor what compass direction they're facing (so long as they face the same direction; otherwise PE won't make it a large chest). This means that if you decide to reduce a large chest to a small one and it's not empty, you can't know how to pre-arrange the inventory to avoid picking items up off the floor unless you make it a habit to always enlarge chests on the same side…and of course you can't always do that. Anyway, this has always annoyed me but I didn't realize this behavior was deterministic until I started looking into this large chest cloning bug. The bug presents differently depending on which side the second small chest was placed on. So now I'm thinking that the real bug might not be in the
/clonecode, but in the code that links small chests into a large one: sometimes it links them in the wrong order. It would help if I knew they were supposed to be in a particular order—I've always just assumed the design left that to programmer discretion. But if PC edition has more predictable behavior, it might be that PE was supposed to as well. tl/dr: Does anybody know which side of a large chest is displayed in the top half of the inventory UI in PC edition? That is, is it (a) the side that was placed first, (b) the side that is farther north/south/east/west, or (c) something else, probably random? Thanks in advance for any info you can give! — Auldrick (talk) 04:14, 16 January 2017 (UTC)
- Partial answer: In PC, there's a class
net.minecraft.client.renderer.tileentity.TileEntityChestRenderer, which determines whether it's supposed to render a single normal, single trapped, double normal, double trapped, single christmas or double christmas chest. It distinguishes between single and double by checking four variables from thenet.minecraft.tileentity.TileEntityChestclass, corresponding to the four directions a neighboring chest might be. It directly checks these blocks, live, whenever the chest entity is updated. It doesn't ever save this data. - I suspect it must be different in PE, since you can have two single chests side-by-side, and I think Jocopa3 might be a good person to ask this question, so I summon him here. – Sealbudsman talk/contr 04:17, 16 January 2017 (UTC)
- In PC, the top half of the inventory UI is the chest to the West, or to the North. – Sealbudsman talk/contr 04:22, 16 January 2017 (UTC)
- Before anyone suggests adding this information to the article, let me point out that it already is, in the first paragraph of the section "Container". I'm not saying it's easy to find, but it is there. —munin ·
· 14:29, 16 January 2017 (UTC)
- Good catch, munin, thank you! I missed it because I'm a programmer so I only expected to see it in the data structures (Trust the code, Luke!). – Auldrick (talk) 15:46, 16 January 2017 (UTC)
- I can guarantee it's different in PE without seeing a line of code. One of the bug's symptoms is that after cloning a large chest, actions performed on the original chest can affect the clone. For instance, right-clicking renders the open animation against either the original or the clone (which could be far away) depending on which side you click. There's obviously an object pointer in use. – Auldrick (talk) 18:15, 16 January 2017 (UTC)
- Before anyone suggests adding this information to the article, let me point out that it already is, in the first paragraph of the section "Container". I'm not saying it's easy to find, but it is there. —munin ·
Untitled1[]
Maybe someone should update the information about ocelots locking chests. Do ocelots still do that or is this reserved for cats? 92.77.140.66 11:37, 27 August 2019 (UTC)
- Please add your new topic at the bottom of the page. -- Hatsuki kiri ( T⁄ C) 11:57, 27 August 2019 (UTC)
bee glitch[]
chests look wierd in the latest snapshot --173.180.201.172 16:28, 21 September 2019 (UTC)
locking chests[]
So you mention how to lock a chest by changing the /data merge 0,0,0 {lock:"key"} and you can only open it with an item named 'key' but how do you name it??? Clonemonkey (talk) 07:58, 24 February 2020 (UTC)
Inconsistency on catching fire[]
These two parts of the content are seemingly contradictory:
> Catches fire from lava: Yes
and
> Lava can create fire in air blocks next to chests as if the chests were flammable, but the chests do not actually catch fire (and can't be burned whatsoever)
Incorrect info[]
The bonus chest loot is incorrect. Minecraftexpert123 (talk) 17:20, 27 May 2020 (UTC)