Hoppers and hopper minecarts not picking from multiple item types when collecting

Can you reproduce this issue without breaking ice above the selection hopper? How about without breaking ice next to it, either?

There's a lot happening in the block above the hopper in your video. The breaking particle animation has to run, the flowing water has to be spawned to replace it, and then the redstone dust has to flow into and (when the timing is just right) out of that block. Breaking the ice is a world change event that happens asynchronously with the redstone tick clock, which could explain why it works as expected most of the time. When the timing is just right, the hopper's checks for an item might happen just outside the window of opportunity to find the item. In that case, this would be another example of MCPE-15793. But if the problem still occurs after the asynchronous activity is moved father away, this would more likely be a new issue.

Distance from user inputs added

Use of slabs and trapdoor hitbox (MCPE-13451) to limit the item's height whilst keeping most of it above the hopper

Attached test world for reproduction:

Shouldn't the top hopper be facing the comparator AND have the same items inside said hopper?

(Tested before reported - from 'Technical Bugs List' https://docs.google.com/document/d/1nziKYzCr4pBdCRj2gIMlfr9MVdWHd6HyafdiBHx9F0c/edit)

This issue happens in 1.14.30 hotfix and 1.15.0.51 also.

Hoppers only check the first item type in the block above them at any given time. That is, they read the chunk data entity list in FIFO order and stop reading when they find an item type listed within Y+1 of their own position. That is why this bug occurs. It has nothing to do with the timing of other events in the chunk as was speculated in previous comments.

The following video confirms this behavior in the test world provided by Mega_Spud. In it, you see

1. The hopper will not collect redstone dust when a slab is dropped on it prior.

2. When redstone dust is dropped elsewhere in the chunk before a slab is dropped on the hopper, the hopper will collect that redstone dust once it moves above the hopper location.

3. Once the hopper collects the "older" redstone dust, it is then able to collect the "newer." This is probably because the redstone dust aggregates into a single stack before collectionthat is, in the chunk data the "count" on the older dust listing gets +1 and the newer dust listing is deleted. This is because when the hopper collects the "older" dust, the game actually replaces the data from the "older" dust with the data of the "newer" dust in the chunk entity list, so the "newer" dust is then ahead of the slab in the list.

A recent duplicate report of this bug, MCPE-66618, contains very clear reproduction steps, and provides this video link: https://youtu.be/9HEZ6ioSKS8 as well as this automated test world:

So Will the Mojang  fix this bug?

@SakuraPuare on the bug tracker we generally do not receive updates from the developers unless and until a fix is announced in a changelog. All we can tell you is that this report has been forwarded to the developers. I will add that your report was helpful to me in understanding this issue, so thank you.

This bug could probably be fixed by a simple change to hoppers’ “stop reading” condition. If a hopper has something in each slot, then it should stop reading the chunk entity list at the first item above its location that also matches an item in its inventory, rather than the first item simpliciter.

This is the case with hopper minecarts as well. This would fix quick item sorters, which are awesome

I'm pretty sure these hoppers are working as intended, as they weren't designed by Mojang to be item sorters. That usage is a very clever adaptation of a hopper's basic function invented by ImpulseSV. However, Impulse realized there are a number of limitations on how his sorter could be used, and one of these limitations is that items must pass above the sorting hoppers one at a time. (Other limitations include that a sorter can only sort out one kind of item, that a certain number of that item must be preloaded into one of its slots, and that the rest of its slots must be full of some item that will never come through the input.)

In your screenshots it appears that you're dropping a whole bunch of items into a hopper which has an item filter directly below it, This violates the constraints of the standard item sorter and makes it unpredictable which item the lower hopper will "see" in its brief opportunity to pull the item down. (It only has one chance before the top hopper pushes an item along to the hopper beside it, so it can only "see" one item per cycle.) You can actually fix your problem easily by inserting one more hopper into the top line, after the input hopper and before the first item sorter. That will serialize the items flowing above the sorters so every sorter sees a predictable item and none get missed.

This bug report was passed by another mod to the developers for a fix. I'm not sure why, as like I said above I believe the hoppers are working as intended (at least with respect to the original bug report). However, we have firm criteria for closing a report as Working As Intended which requires us, more or less, to be able to point to somewhere that a Mojang development team member has stated that it is, in fact, intended to work that way. We often don't have such evidence, and in that case we forward the report to Mojang to leave it to them to make the WAI statement, or fix it if it's not the intended design. I don't know which resolution to expect in this case.

The problem with the hoppers is that ¨they read the chunk data entity list in FIFO order and stop reading when they find an item type listed within Y+1 of their own position,¨ as stated above. This is not a problem on java edition, as done by ilmango.  The fix is just to only look for items that match the items in their inventories. And the worst part is that it happens inconsistently.

I'm not sure where you're getting your facts from, but the Entity list for a chunk contains an entry for every entity in the chunk, in no predictable order. In particular, it includes mobs and other mobile things such as falling gravity blocks and minecarts. And it includes dropped items floating above the ground, but it does not contain items stored in inventories. Those are saved as data for the block or entity that the inventory belongs to. (This might be a difference between Java and Bedrock; I don't know how Java data is organized.)

Hoppers do something like what you describe only during their "suck" phase, which is when they collect items floating in the block space above them. There could be hundreds of stacks of items floating there, and processing them all on a single tick could cause serious lag, so the suck operation stops checking for matching items after it finds and processes the first one. If there are additional matching stacks, they will have to be sucked on subsequent cycles—or they might get burned up by lava above the hopper, which is why you can only get one kind of mob drop item in farms that use such a design.

When a hopper takes items from a block inventory above it, that is its "pull" operation and it works a bit differently. It goes through its own inventory, in slot order, and checks the inventory of the block above it for a matching item stack. (Or, if its own slot is empty, it considers any non-empty slot in the block above it to be matching.) Once it finds a stack it can move, it moves as many items as it can. But note that it might not be able to move all the items in the stack to the same slot in its own inventory, because its own slot already held a partial stack that didn't have enough room left for the entire stack in the other inventory. On top of that, the remainder of the source items need to get moved to another slot in the hopper, either another slot with a partial stack of the same item type (in which case there again might not be room for all of it) or an empty slot. It's actually pretty complicated, and as with the sucking logic trying to do everything in one tick might cause lag, even though there are only 9 slots to check. The problem is magnified much worse when you think about the fact that hoppers are very often used to make vertical hopper pipes with lots of stages, or lots of parallel item sorters, and all of those hoppers need to go through this same complicated logic for every tick. So when sucking or pulling, a hopper will only do a portion of what might be possible before it postpones doing more to the next tick.

And that, I believe, is what is causing this so-called bug. Because in an item sorter, the top row of hoppers forms a pipe that moves one item every tick, while the first row below that is trying to pull items from them. It's just bound to happen that when you allow the top hopper to have multiple items in it, sometimes the sorting hopper will only be able to move part of the matching stack and will wait to get the rest on the next tick. But by then, the hopper pipe may have moved some of those items into the next stage, so the chance to sort them out is lost and they go into the "unsortable" bin.

Yes, chucks have an entity list and yes, hopper inventory data are separate, the same as java edition. I didn't mean for it to seem like they were the same.

What you're saying about the hopper going through and processing all the items in one tick would cause lag, but that's why it should only be looking for the single type of item in the hopper item sorter. Right now, as you said, it is trying to process all the items in a single tick but fails. It works backward the way it should. The hopper should only look for the items it can pick up instead of trying to process them all at once, and hopefully, it doesn't look for entities such as gravity blocks, ignited TNT, etc.. If the hopper is looking for a maximum of 5 different items (5 slots), I could see this happening. In my case, if 20 items, comprised of 5 stone blocks, 5 dirt blocks, 5 grass blocks, and 5 cobblestone blocks all pass over a hopper looking for dirt blocks, the hopper should do a "Ctrl + F" (Find Search) through the list of entities, instead of checking each one (reading the whole list). In this scenario, the hopper has completed its "cool down" phase of 8 ticks, as you were getting at near the end.

What you said about lag is true, especially hopper chains, but if I'm getting 60fps, the items should be sorting fine. I do realize it has complicated logic as a developer myself, but I think it is possible without too much lag.

It's a hopper, not an item sorter. The only reason it sorts items is because of how you put it together with other components. So it has no way of knowing that you intend it to sort the item in the first slot versus some other slot, or even that you're trying to sort items at all. It does exactly what hoppers were designed to do. You want it to be an item sorter, but that's not what it's designed to be.

Mojang could, I'm sure, create a new type of redstone component that has sorting items as its purpose, but (1) that's a feature request, not a bug, and (2) they're never going to do that anyway, because the point is for you to figure out how to build stuff, not for them to figure it out for you. So yeah, some things you might want to do can't be done exactly the way you think of doing them at first. That's when your job becomes finding a different way to solve the problem.

Also, it's lovely that you've got a system that wouldn't get bogged down under a big load, but Bedrock was specifically designed to allow cross play. That means it has to have the same features running roughly equally well on mobile devices and less powerful computers as monster gaming systems. If it allowed you to do things on your system that someone you're cross playing with can't do, that would give you an unfair advantage and spoil, arguably, the most exciting design goal of the game.

Re: Entities such as gravity blocks and activated TNT. Since you're not talking about inventory here, it would only see these while doing its "suck" operation. All the entities are in the same list (if I'm not mistaken), but the hopper only considers what are called item entities for sucking so it sees, but ignores, gravity blocks and TNT (which are block entities) and the rest. Item entities are the entities that items become when they're dropped or blocks are broken. They collect into stacks and float above the floor, gently rising and falling. (They can also get trapped inside a block in certain circumstances, but hoppers below the block can still suck them out.)

This is the point, if the hopper is able to know what to look for rather than having to go through all the different item types. (i.e. It looks for the items that can be "sucked" in by using the items already in the hopper first, then if there's an empty slot(s) it can go through the list as normal)This is completely within the hopper's ability.

I do realize that bedrock is built for cross-platform compatibility, and I do not believe having about 40 item entities in a water stream is too much for any device that has Minecraft, as I have built this on my Xbox and phone. If this is fixed, it should reduce lag, because it is doing less processing per tick.

As you said, the point of the game is to be innovative. Hopper based item sorters are the by-product of this innovation. I also know that Mojang could create an item sorter block. I'm glad that they haven't because item sorters are one of the most used restone components it the game, and it's where I started my interest in restone. I think that it's important that hoppers work the way that they were intended. 

 I am not the reporter of this bug, but if I was, I would tag it as parity. Some redstone parity should be added to the Bedrock Edition. From what I've read in your previous statements, you don't seem to know that this isn't a problem on the Java Edition. Yes, I know that they're not the same, but this adding redstone parity in some form is important because it is probably the most underestimated feature in the game, with a lot of potential. 

Also, I know that all entities are on the same list, I was just pointing out that if the hopper was checking block entities, it would cause lag unnecessarily. 

@Auldrick

This report is only about the sucking function of hoppers. It is not about trying to turn hoppers by themselves into sorters, and it has nothing to do with hopper pipes or transfer rates. Moreover, it is the devlopers' intention that hoppers suck instantaneously (MCPE-64628), and lag would be far worse if they did not since item entities would be left sitting around for a long time.

The issue in this report is that sometimes a hopper with 5 non-full stacks of items in it does not suck in matching items. Specifically, if an item that does not match one of the item stacks in a hopper happens to be in sucking range, then the hopper sometimes will not suck in items that do match its contents, no matter how long the items sit there. In other words, the non-matching item permanently locks the hopper from sucking in matching items.

The statement quoted by Luke comes from a comment I made above to explain why this bug happens.

[hoppers, when sucking,] read the chunk data entity list in FIFO order and stop reading when they find an item type listed within Y+1 of their own position

I provided a video in that comment as evidence that the order in which items are added to a chunk is what determines when this bug occurs. I reached my conclusions based on a combination of testing and checking chunk data with MCCToolChest. By repeated checking I've found that the entity list for each chunk in MCCToolChest is chronological and not random (it shows entities in the order that they were added to the chunk). It seems reasonable to infer that the game stores the data this way too. My assertion about how hoppers read chunk data when sucking represents an inference to the best explanation that explains why, when, and how this bug occurs.

Here are two demonstrations of this bug as it applies to hopper minecarts.

So,  the problem is that is not reading through the list. This is a big problem then

Thanks for the videos

I think this may be related to MCPE-54244, which was fixed in 1.15.0.53 beta. My guess is that MCPE-54244 was due to the same part of the code as this bug, and to fix MCPE-54244 a special exception was made to the “stop reading” condition if the first entity found is a hopper minecart. This could be tested by dropping a non-matching item on a hopper, then placing a hopper minecart that’s already full of matching items above and letting it fall into the space above the hopper. Test was negative (in 1.14.60). An older, non-matching item does not block pulling of matching items from a newer hopper minecart. However, a hopper minecart with non-matching items in each slot does block collection of matching items into a hopper/hopper-minecart below.

With further testing I've determined why: hoppers and hopper minecarts run separate checks of the chunk entity list for blocks with inventory, hopper/chest minecarts, and collectible items, in that order. In 1.14.60 they stop checking at the first thing they find, and then they pull or collect/suck as the case may be. (Hopper minecarts make separate collectible item checks for their own Y-level, and for Y+1 to ~ Y+2.2, and they always check both when they check for collectible items.)

It appears from MCPE-80555 that the patch for MCPE-54244 in 1.15.0.53 was applied to checks for blocks with inventory as well as checks for hopper/chest minecarts, with the result that blocks with inventory no longer prevent hoppers/hopper-minecarts below them from pulling from hopper/chest-minecarts or sucking in free-floating items. This bug needs the same kind of fix. It does not makes sense that hoppers should be able to check multiple hopper/chest-minecarts for matching items to pull, but cannot check multiple items for a match.

Another impact of this bug, is what I call "hopper voodoo":

It can be cofirmed that in 1.16.0.64 this bug still exist. A long-life bug 2333

After some code analysis, this issue comes from HopperComponent::pullInItems.
The method fetch entities around the hopper, but only tries to take the first item of the list.
It should try all items of the list until addItem returns true.

Affects 1.16.100.53

Affects 1.16.100

Affects 1.16.200.56 Beta

Affects 1.16.100.59 Beta.

Affect 1.16.100.60 beta

Please note that the bug tracker is not a discussion board. Comments here are meant for providing additional information that might help the developers find and fix the bug. Other uses are subject to removal. To discuss the issue with each other, please use another service such as the Minecraft Discord.

affects 1.17.0.56

A further observation would be that this particular issue does not seem to be present in the java version of the game, which indicates that this is also a parity issue.

affects 1.17.10

I can confirm

Affects 1.17.0.50
Affects 1.16.221

Affects 1.16.221, I figured it out building an ice stream transportation system for my bartering farm, half of the items are not picked by hopper filters, making the whole work useless.
Consider fixing, this is really frustrating.

This definitely affects Java Edition. My report MC-155433  seems to be duplicate of this in case of hopper minecarts, reported JE 1.14.3, AFAIK still present.

Still having this issue in 1.17. Major issue when using water stream based item sorters.

Leon Wilk: based on your description in MC-155433, it sounds like the relationship of that Java issue to this bug is superficial. You report that in Java the problem is related to how many items are in one spot and how many mincarts you drive though it. By contrast, in Bedrock Edition the bug described on this ticket is reproducible with a single stationary hopper minecart and a single blocking item. Moreover, in your ticket you describe dropping all of the stone on the minecart track first, and then the other items. If you did that in Bedrock Edition all of the stone would eventually be picked up, because what matters is the order in which items are added to the chunk entity list.

My guess is that in the Java scenario your report describes, the problem is that the minecarts are moving through the space too fast to sort through the very large number of stacks you are dropping in one place. But that's just a guess.

It turns out that if the hopper minecart is inside a block, then this bug doesn't affect it. I've yet to find a work around for normal hoppers.

silentwisperer: what you're seeing with hopper minecarts is an artefact of your test setup or the design of whatever you're building. I'm glad it works for what you are trying to do, but the bug still technically affects hopper minecarts inside blocks in the exact same way as it affects hopper minecarts outside of blocks.

Let me explain. Hopper minecarts check 3 different areas around them for items to collect. The ranges are roughly as follows, relative to the center point of the hopper minecart

1. -0.5 to +0.5 vertical and -1 to +1 horizontal

2. 0 to +1 vertical and -0.5 to +0.5 horizontal

3. +1 to +2 vertical and -0.5 to +0.5 horizontal

Each of these check areas is affected by the bug, but they are affected separately. An item blocking one of the check ranges does not affect the other check ranges. That's because the blocking item is not found when the fetch function checks a different range.

My guess is that your test involved putting a minecart inside a block and then dropping items on it from above. When you do that, the non-matching item lands on the block and blocks search range (2), but items dropped from above can still be collected from search range (3). If instead of dropping items from above, you push items onto the block from the side, then you'll see the bug again. Or, if you put a slab on top of the block the minecart is in and repeat the dropping-from-above test, then you'll see the bug again, because the slab causes the non-matching item to rest in search range (3).

Can reliably replicate this bug with larger bartering setups in the nether. This world has multiple failing item sorters when the bartering drops pass over the ice on top.

@unknown: Your comments about this bug in 1.17.2 are not useful because that release is no longer current (the current release is 1.17.11). Also, comments should only be used to report new information; I didn't see anything new in what you reported. If there actually was something new there, you might want to re-test it in 1.17.11 and focus just on the new information.

Affects 1.17.40

1.18.0.22 beta

Affects 1.18.2. This bug continues to have major impact on technical play, specifically for trying to sort the output from a farm that outputs large amounts of numerous item types (like moss farms or piglin trading)

This behavior also affects 1.19.10.03 just like in the comments and examples above.

1.19.20 too...

As mentioned, still current in 1.19.20.  Ive made a contraption to simulate exactly whats going on. I put it all into a small .mcworld file. You can find that here https://www.mediafire.com/file/g1b69ggnefzpam1/Brokenhoppers.mcworld/file  If you need me to make a new bug report for this, Let me know and ill be happy too! Thank you! -Rs. 

Reply from @unknown: there is already a test world linked in the description at the top of this report.

Yes, Options are always good though! I know some bugs can be hard to replicate. 🙂 Thank you!