Today, 9/19, is the 6th Anniversary of Gamepedia's launch. Join us for an all-day Mega Stream on the Gamepedia Twitch channel! In addition, all users who log in during the anniversary week will receive a special achievement.
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
/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)
(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
- 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 the
net.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)
- 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)