Back to minecraft.net

What is parity? This category is designed just for features that exist but work one way on one platform, and another way on a different platform. Bugs are not parity! Items in snapshots and betas are subject to change so please be sure to only post about things that are currently released in Minecraft. Please read the intro post before you post!

← Parity
328
Follow

Hoppers should transfer items in the correct order

Hoppers when transferring items, randomize the order at which the items get moved along. Aka, the hoppers are not reliably in which items they will send when.

This has been a massive issue for every kind of sorting system for as long as bedrock has existed, and it makes things needlessly complicated! It affect pretty much every type of redstone system that uses hoppers, from sorters, logic, timers, auto brewers, and way way more.

This is also a parity issue, not just a redstone issue. Java edition has proper hopper mechanics, and no such issues like the ones we have on bedrock edition.

I made a bug report for this issue, but apparently its "not a bug" :/

https://bugs.mojang.com/browse/MCPE-51087

You can see a demonstration on this bug in action here
https://youtu.be/1ei2sEELbxY?t=169

Avatar
Registered User shared this idea

9 Comments

Please sign in to leave a comment.

Date Votes
Sorted by oldest
  • Official comment
    Avatar
    Registered User commented
    Comment actions Permalink

    Moved to parity category - love that the bug number is included here! THANK you!

  • 8
    Registered User commented
    Comment actions Permalink

    In Bedrock Edition redstone is more logic than the Java Edition. But I have the same issue. This issue is not logic at all.

  • 6
    Registered User commented
    Comment actions Permalink

    This has been talked about in the bug tracker. The order gets messed up because of hoppers earlier in a hopper chain pushing items before hoppers later in the chain, leaving earlier items in later slots, effectively lowering their priority.

    https://bugs.mojang.com/browse/MCPE-28890?focusedCommentId=449680&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-449680

    Idk how the JE does it (maybe ask that team how they did it?), but I'm thinking maybe a buffer could work? Hoppers should remember for a tick if they've sent something, so a newly received item can be put into the previous item's slot. Alternatively, incoming item(s) could be held in a buffer until the hopper sends out item(s), to ensure proper slot placement.

    Edit: Thinking a bit more about it, the buffer would also need to be implemented for all types of storage containers (chests, barrels, etc). Don't want a chest between 2 hoppers getting the order messed up.

  • 1
    Registered User commented
    Comment actions Permalink

    Silent please take it back, I have made 3 different board games in survival and 2 of them utilize this bug. 

  • 3
    Registered User commented
    Comment actions Permalink

    I was about to post and say "This is a known bug, my friend!", and then link Silentwisperers bug report. lol Funny coincidence. Seriously tho, how is this working as intended? Maybe Mojang INTENDED to be lazy when they coded bedrock hoppers?

  • 6
    Registered User commented
    Comment actions Permalink

    Bedrock need this.

    Regarding the comment by TakingItCasual - one way to fix this could be;

    When an item enters a hopper, it enters an 'array' in C++. That array is built using 0-indexed keys and when the hopper wants to push an item, it systematically works its way down the array, remembering the last key it pushed, and then pushes the next highest key number, returning back to key 0 when there are no keys higher than the current one.

    For example:
    Hopper #1 - pushes key 0, then on the next push, key 1, then key 2.

    As each hopper receives an item (Hopper #2), it is entered in to an 'array' for that hopper (#2), using the next available key. If hopper #2 already has an item in slot 5, then the item from Hopper #1, enters the Hopper #2 array as key 0. When hopper #2 pushes its item, it will push key 4 (slot 5) first, then key 0 (slot 1), because hopper #2 recorded that it last pushed an item from key 3 (slot 4). This way of using arrays within C++, tied to each hopper, ensures all hoppers within a chain move items in the same order they receive an item. This ensures items do not flow out of sequence when moving through hopper chains and will enable parity between the Java version and Bedrock version. If each hopper in a chain, is also triggered beginning with the last hopper, working backwards to the very first hopper, this will also ensure that several items moving through a hopper chain, continue to run in the order than they were first pushed from Hopper #1 to Hopper #2.

  • 1
    Registered User commented
    Comment actions Permalink

    They do transfer things in order don’t they? Or item sorters wouldn’t work

  • 1
    Registered User commented
    Comment actions Permalink

    However... you can make a randomiser with hoppers because of this

  • 1
    Registered User commented
    Comment actions Permalink

    For a hopper chain:
    A->B->C->D->Chest

    If the hoppers are processed in the inverse order in the chain
    D, C, B, A then there will not be any issue.

    In a general case, if a directed graph is created based on how the hoppers are connected to each other, as long as there is no hopper cycle in the connections, the sequence in which the hoppers need to be updated can be easily calculated.

    For cycles it might not seem trivial

    A->B->C->A

    but also logically there is no need for a predeterministic order in a cycle, as long as the hoppers in each cycle are processed in a fixed order of the cycle starting from any point it is fine.

    The code can keep the directed graph in the memory when the corresponding chunks are loaded so the order could be preserved.

    -----------------

    Even if the hoppers are processed in a random order, as long as the order does not change every tick, again there will not be an issue in most cases. I imagine the code is not literarily using a random function to determine the order and most likely is using a data structure like a set that does not preserve orders when new items are added or removed, so if the data structure holding the hoppers change to something that keeps the orders stable, then this issue will not persist.