[1.12.1] First item in ItemStack being lost when pulling from drawer
Hjaldar opened this issue ยท 5 comments
Forge: 14.21.1.2428 (latest) and 14.21.1.2387 (recommended) (and presumably everything in between)
Storage Drawers: 1.12-5.2.9
Chameleon: 1.12-4.1.3
No other mods present for testing. Drawer setup as seen below:
This is a typical mob farm drawer setup where the empty drawer is to allow deletion of unwanted items.
Tests:
If a non-stackable item is placed in the input hopper, it reaches the empty drawer (confirmed by removing the output hopper) but does not reach the output hopper.
If a stack of n items not in the drawer system is placed in the input hopper, it all reaches the empty drawer, one item at a time, but no items reach the output hopper.
If a non-stackable item is placed in the empty drawer, it does not reach the output hopper.
If a stack of n items is placed in the empty drawer, only n-1 of the items reach the output hopper.
It seems like every time the hopper pulls from the drawer above it the first item is being deleted.
I'm having the same or a very similar problem on StorageDrawers-1.11.2-4.2.10 (forge 13.20.1.2429). My test was connecting two drawers with XNet and setting up a channel to move items from one to the other. With a full destination drawer, when I remove one item by hand, two items are removed from the source drawer, and one item gets added to the destination drawer. The other item is lost.
Just in case it's related: it also seems like Storage Drawers incorrectly reports the amount of empty space in a drawer's inventory. For example, with a full drawer, when I remove one item, a Thermal Dynamics servo will send 2 items to the drawer. One item goes in, and the other gets backstuffed.
On 1.12.1 with Thermal Dynamics pulling/pushing with resonant servo/retriever set at 64 items, they vanish completely. Dropping down to 63 items, the first item disappears and the other 63 make it fine.
Confirmed bug/unusual behaviour still present with:
Minecraft 1.12.1
Forge 14.22.0.2462
Storage Drawers 1.12.1-5.3.0
Chameleon 1.12-4.1.3
All are the latest versions available at the time of writing.
To help you track down/fix it.
The issue starts in DrawerItemHandler.java#L127-L129.
The call of drawer.adjustStoredItemCount(-amount) goes down to StandardDrawerGroup.java#L278
Which then leads to StandardDrawerGroup.java#L387-L395. This sets the prototype to AIR.
The final call of DrawerItemHandler.java#L131 then uses AIR as new prototyp to return the stack.
A fix might be to cache the original prototype before calling drawer.adjustStoredItemCount(-amount)
Locking a drawer seems to prevent it from happening.
