Hopperhocks not sorting correctly with quark's varient chests
Evo112358 opened this issue ยท 2 comments
Forge version: 14.23.1.2562
Botania version: r1.10-350
Quark version: r1.4-120
It was suggested on reddit i post here after noticing hopperhocks werent filtering correctly in the 1.12.2 version of Garden of glass by melanX.
I have modified the pack, however the below can be reproduced on a fresh install, on the latest forge and botania.
Steps to reproduce:
- Load into a new gog world.
- Place 3 quark chests, 2 of one wood type 1 of another side by side. (think normal, trapped, normal chest pattern)
- Add item frames to the face and add items. (i used each chest and the item frame as all 3 are already in inventory)
- Add either floating hopperhocks behind the chests.
- Toss the items associated to the item frames onto the middle chest or hopperhocks. (the range indicated by the monocle covers both areas)
What I expected to happen:
Items sorted into correct chest, indicated by the item frames.
What happened instead:
If hopperhock is used, all items are placed into the chests at random. 2 items in 1 chest, 1 in another.
If hopperhock petite is used, all items are placed into middle chest.
A guess: the hopperhock is probably assuming that the chests form a double chest, even though they do not.
Edit: Looking around a bit...
Custom chests from Quark extend TileEntityChest
. If getCapability
is called on a Quark chest, Quark returns an item handler capability that accurately reflects the double-ness of the Quark chest.
However, in Botania InventoryHelper#getInventory (line 43), Botania special cases TileEntityChest
s to go through a Forge-provided VanillaDoubleChestItemHandler
, which doesn't actually check whether a double chest is properly connected or not, it just looks for other TileEntityChests. And, if Botania doesn't find a TileEntityChest
, it falls back to asking the tile entity for its capabilities (which is what we want to happen because quark chests have that nice override)
Botania's special case seems to be unneeded anyways, because just calling getCapability on a vanilla chest will also go through VanillaDoubleChestItemHandler
. I tried ripping out the special case check and playing around with hopperhocks and corporea sparks, things seemed to work as normal. Making a PR...