[MCPE-14075] Strange nondeterminism in horizontal hopper pipes and their cooldown counter Created: 10/Apr/16 Updated: 04/Nov/23 Resolved: 03/Feb/17 |
|
| Status: | Resolved |
| Project: | Minecraft (Bedrock codebase) |
| Component/s: | None |
| Affects Version/s: | 0.14.0, 0.14.1, 0.14.2, 0.14.3, 0.15.0, 0.15.2, 0.16.0, 0.16.2, 1.0.0.7, 1.0.0 |
| Fix Version/s: | 1.0.3 |
| Type: | Bug | ||
| Reporter: | PHO | ||
| Resolution: | Fixed | Votes: | 20 |
| Labels: | hopper, redstone | ||
| Attachments: |
|
||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||
| Platform: | Tablet - iOS - iPad 3 | ||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||
| ADO: | 23106 | ||||||||||||||||||||||||
| Description |
|
I'm not sure what is really going on but I have to report this anyway. In the screenshot below, when you put a stack of items into the topmost chest, everything should go to the bottommost chest and the middle one should not receive any items. But in 0.14.1 the middle chest does receive some of items, and the number of those items randomly changes every time you try. However, if you instead place the topmost chest directly on top of the second hopper (i.e. the one on the left side of the middle chest), all the items in the chest go to the bottommost chest as expected. So this has something to do with hoppers' cooldown counter. I mean, it is as if there were a relatively small chance that the second hopper didn't get suspended by the first hopper pushing items into it. It's like a nondeterminism of a multithreaded program. This relates to now-fixed |
| Comments |
| Comment by [Mojang] Tomas Alaeus [ 17/Jan/17 ] |
|
I finally found and fixed the issue. It will be available soon (tm). |
| Comment by Haydn V. Harach [ 28/Dec/16 ] |
|
Still a problem in Windows 10 edition 1.0.0. |
| Comment by [MCPE Mod] Auldrick [ 04/Nov/16 ] |
|
Confirmed still an issue in Windows 10 Edition 0.16.0. |
| Comment by Dax Faubus [ 28/Oct/16 ] |
|
Still an issue in 0.16 |
| Comment by Jeff Jewett [ 06/Oct/16 ] |
|
confirmed for 0.15.10- hopper item sorters are unreliable because sometimes they do not pull in items properly. Also with 2 hoppers facing each other, and multiple items, it should theoretically send 1 item back and forth however sometimes an extra one is pushed seemingly randomly |
| Comment by Michael Yohe [ 01/Jul/16 ] |
|
Confirmed this to still be an issue in 0.15.0. This breaks all manners of the way hoppers are supposed to deliver items based on the "tick". |
| Comment by Sam T [ 27/May/16 ] |
|
Confirmed: iPad v0.14.3 |
| Comment by PHO [ 13/Apr/16 ] |
|
Yes, it was a tiled set of item sorters that made me aware of this unreliability. I suspect that they changed the "push" action of hoppers so that source hoppers reset the cooldown counter of destination hoppers only when the latter is zero in order to work around
And it's very important to follow all of these steps atomically. If two hoppers were doing these in an interleaved way, they would end up in this nondeterminism, e.g. hoppers whose counter is reset to 8 may continue to push/pull items due to a race condition. Of course you cannot use pessimistic locking to synchronize hoppers because that would result in a dead lock when there is a hopper loop. (As a side note, some people believe that hoppers pull before push but I think that's incorrect. If in doubt, try placing a single hopper pointing sideways and use two chests as an input and output. If hoppers pull then push in the same game tick, you can't observe items passing through the hopper by measuring with a comparator or watching its inventory.) |
| Comment by jj [ 13/Apr/16 ] |
|
I confirm the hoppers don't perform reliable on the iOS 0.14.1 version. If you put items in a chain of hoppers, it seems some hoppers are skipped (if you keep monitoring them, no items seem to flow through. seemingly they jump to the end hopper immediately). I experimented with several item sorters, and of a full stack of items only the first item is sucked into the hopper below, the rest moves on. I build a loop of hoppers in an item sorting system and first I thought every loop it would suck one item in the hopper below, but doing several test runs, the results were everytime different and therefor could not be reproduced reliable. The more items are in the hoppers, the worse it gets. I also tried a huge sorting system, with the same item in every hopper below the main chain of hoppers, hoping that every hopper would suck 1 item of the stack, but again only the first hopper would suck 1 item and the rest would pass over all the other hoppers. Unable to reproduce reliable test results, gives me the feeling it is a multithreaded part of the code. Hope it helps. I believe several reported issues are related to this problem or are duplicates |
| Comment by PHO [ 13/Apr/16 ] |
|
While experimenting with the "item counter" shown below, I found another strange phenomenon which is very likely to be tied to the issue. I put 64 items into Ca and observed the pulses it emits. The result was very surprising. The first item stayed for 8 game ticks (4 redstone ticks) in Ha as expected. But things started to go mad after that. For the 2nd to the 64th items, they either
Both cases are glitchy because every time Hb pushes an item to Ha, it should reset the cooldown counter of both Hb and Ha to 8 so the items should always stay in Ha for 8 game ticks. The only difference between the first item and the rest is that whether the cooldown counter of Ha is 0 or 2 (not 4 due to |