When a hopper has one or more items in any of slots #2-5 while slot #1 is empty, and then it receives an item into slot #1 (pushed in by another hopper or a dropper, or moved in by a player), it will try to push out that same item from slot #1 instantly. This violates the 8 game tick transfer cooldown that hoppers are supposed to have.
Impact
Several impacts of this behavior can be seen in a horizontal line of hoppers pushing in the same direction (known as a "hopper pipe"):
Hopper pipes can be accelerated to transfer single items faster than 1 block/8 gameticks. This applies to both Java Edition and Bedrock Edition, as demonstrated by Ilmango and NavyNexus
Items moving through a hopper pipe can skip past item filters built under the pipe. This only happens in Bedrock edition because it depends also on random update order (MCPE-28890). Bedrock players have to expand their storage builds with transfer loops, extra filters, or rate limiting redstone contraptions to overcome this. However, even looping can fail: see MCPE-166794.
Items moving through a hopper pipe can skip past each other, rearranging their order. Again, this only happens in Bedrock edition because it depends also on random update order (MCPE-28890). Bedrock players have to expand their potion brewing builds, and will have to expand builds for the upcoming crafter block, by adding extra buffer space or redstone contraptions to control the sequence and/or limit the rate of item flow in hopper pipes.
Steps to reproduce
Load
. This world contains two item filter test setups and two pairs of long hopper pipes, with books that explain the builds. These builds demonstrate the first two impacts described above.
Read the book by the item filters and perform the tests described in it.
Read the book by the long hopper pipes and try each pair of hopper pipes by pressing the button.
Load
. This world contains a contraption designed for the upcoming crafter block, which is meant to loads items into a chest in a specific order.
Press the button on each version of the build.
Expected results
In the first test world, the zombie heads would never skip past the item filters and the wired and loaded hopper pipes would have the same transfer rate as the empty hopper pipes. In the second test world, the items would always enter the chest in the same order in each build.
Observed results
In the first test world, the zombie heads skip past the item filters in predictable ratios depending on the setup. The wired and loaded hopper pipes transfer individual items much faster than the empty hopper pipe. In the second test world, in the smaller build the stick sometimes enters the hopper before the redstone.
Linked issues
Attachments
Comments 2
Can confirm I have experienced this issue myself
The issue of items in hopper pipes rearranging their order was previously raised in MCPE-28890. My understanding is that that report was resolved WAI based on random update order being intended (MCPE-16371). That resolution does not address the fact that items rearranging also involves an exception to the 8 game tick cooldown that normally applies to hoppers transferring items. So, I made this report to raise the issue.
I think what I have reported here could be fixed by modifying the logic for triggering a transfer cooldown when an item is put into a hopper. The current logic is that putting an item into a hopper triggers a general transfer cooldown of 8 gameticks if the hopper is empty (that is, each slot is empty). A fix could be to add a secondary cooldown of 8 gameticks that would apply :info: only to pushing and (ii) only to the last empty slot that received an item (a "slot push lock", so to speak). This secondary cooldown should be activated only if (a) the general transfer cooldown timer is at <8 ticks, and (b) the slot that the item comes into and all lower slots are empty. Here is how that would play out:
Suppose a hopper is actively pushing items out from a stack in slot 3 while slots 1, 2, 4 and 5 are empty. It gets an item put in slot 2. This does not reset the general transfer cooldown because the hopper is not empty. It triggers a "slot push lock" on slot 2 for 8 ticks because (A) slot 2 receives an item AND (B) both slot 2 and slot 1 were empty. While the "slot push lock" is active, the general transfer cooldown expires, so the hopper pushes an item out of slot 3. Some time during the next general transfer cooldown the "slot push lock" expires, so the next time the general transfer cooldown expires the hopper pushes the item out of slot 2. This would fix the behavior reported here without adding any extra delay to overall hopper transfer rates.
Suppose a hopper is actively pushing items out from a stack in slot 3 while slots 1, 2, 4, and 5 are empty. It gets an item put in slot 4. This does not reset the general cooldown because the hopper is not empty. It does not trigger a "slot push lock" because a lower slot (slot 3) has items. The hopper continues pushing items out from slot 3 based on the general transfer cooldown without any added delay. This matches current behavior.