Hopper with container above is able to collect dropped items
Hopper with container above, eg. chest, furnace, etc. is able to collect dropped items.
Steps to reproduce:
- Place a chest on a hopper
- Add a water-stream at the level of the chest to direct items towards the chest
- When items are dropped into the water-stream, they will be collected by the hopper as they are pushed near the chest's hitbox.
Expected result
A hopper with container above should not collect, or detect, dropped items. From the wiki,
A hopper with a container above it, such as a furnace, chest, or another hopper, cannot collect dropped items; for run-time efficiency, the hopper's code doesn't check for floating items.
Actual result
The hopper is able to collect items due to items entering the smaller hitbox of the chest.
This bug can negatively affect item sorters, item pipes, etc., that rely on "capping" a hopper with a container to prevent dropped items from going where they're not supposed to.
Linked Issues
discovered while testing1
relates to3
MC-8864Hopper can't pick up items which sit on top of the stand of a brewing standWorks As Intended
MCPE-109449Hopper/hopper-minecart with container block above pulls from hopper/chest-minecartsConfirmedMCPE-94293Hoppers can push into hopper/chest minecarts on curved tracks diagonally below themWon't Fix
![[Mod] GoldenHelmet](../../../data/avatars/users/18951.svg){kind=small}
Created Issue:
Hopper with container above is able to collect dropped items
Hopper with container above, eg. chest, furnace, etc. is able to collect dropped items.
Steps to reproduce:
- Place a chest on a hopper
- Add a water-stream at the level of the chest to direct items towards the chest
- When items are dropped into the water-stream, they will be collected by the hopper as they are pushed near the chest's hitbox.
The hopper is able to collect items due to items entering the smaller hitbox of the chest, however, a hopper with container above should not collect, or detect, dropped items. From the wiki, "A hopper with a container above it, such as a furnace, chest, or another hopper, cannot collect dropped items; for run-time efficiency, the hopper's code doesn't check for floating items."
This bug can negatively affect item sorters, item pipes, etc., that rely on "capping" a hopper with a container to prevent dropped items from going where they're not supposed to.
Hopper with container above, eg. chest, furnace, etc. is able to collect dropped items.
Steps to reproduce:
- Place a chest on a hopper
- Add a water-stream at the level of the chest to direct items towards the chest
- When items are dropped into the water-stream, they will be collected by the hopper as they are pushed near the chest's hitbox.
The hopper is able to collect items due to items entering the smaller hitbox of the chest, however, a hopper with container above should not collect, or detect, dropped items. From the wiki, "A hopper with a container above it, such as a furnace, chest, or another hopper, cannot collect dropped items; for run-time efficiency, the hopper's code doesn't check for floating items."
This bug can negatively affect item sorters, item pipes, etc., that rely on "capping" a hopper with a container to prevent dropped items from going where they're not supposed to.
Hopper with container above, eg. chest, furnace, etc. is able to collect dropped items.
Steps to reproduce:
- Place a chest on a hopper
- Add a water-stream at the level of the chest to direct items towards the chest
- When items are dropped into the water-stream, they will be collected by the hopper as they are pushed near the chest's hitbox.
Expected result
A hopper with container above should not collect, or detect, dropped items. From the wiki,
A hopper with a container above it, such as a furnace, chest, or another hopper, cannot collect dropped items; for run-time efficiency, the hopper's code doesn't check for floating items.
Actual result
The hopper is able to collect items due to items entering the smaller hitbox of the chest.
This bug can negatively affect item sorters, item pipes, etc., that rely on "capping" a hopper with a container to prevent dropped items from going where they're not supposed to.
![[Mod] OcelotOnesie](../../../data/avatars/users/43220.png){kind=small}
discovered while testing
Affects 1.16.0.64
relates to
![[MCPE Mod] Auldrick](../../../data/avatars/users/10122.svg){kind=small}
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
Affects 1.16.20.54 Beta
relates to
relates to
relates to
relates to
Does the fix to minecart hitboxes in 1.16.0.57 (MCPE-59302) not impact this bug?
Nope, it's unrelated. This bug is in the the hopper-minecart search function.
Now, the fix for MCPE-54244 in 1.15.0.53 does impact this bug, because that fix allows hoppers and hopper-minecarts to ignore blocks with inventory above them and continue searching through hopper/chest-minecarts above and/or to the S or E side of those blocks. So now this bug is worse. (See MCPE-80555.)
I think this may be related to MCPE-54244, which was fixed in 1.15.0.53 beta. My guess is that 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.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.
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.
@GoldenHelmet, just letting you know I created a separate ticket here: MCPE-80555 regarding the hopper/container bug
This report has been changed since it was originally created.
The original issue reported (May 2019) was that shulker boxes broken by pistons would sometimes get stuck in-between vertically stacked hoppers. The shulker was placed next to a hopper that had another hopper below it, and the piston would push the shulker toward the hoppers. The reason the shulker would get stuck is that when it was pushed against the motion-blocking side of the upper hopper, it would look in random directions for an open space to move to, and sometimes it would find the open space of the lower hopper's funnel and rest there. Based solely on this information, I would say this was working as intended based on MCPE-38628, since it is intended that hoppers have a non-full hitbox that items can get stuck in.
However, the expected behavior was later (August 2019) explained to be that items pushed against a vertical hopper stack by a piston should fall out to the side. So the issue was clarified to be about how items pushed by a piston should behave when pushed into a full side collision box.
More recently, the summary and description was changed again (May 2020) to report that items pushed by pistons into a vertical hopper stack can get collected by the hoppers. Now on the surface, based just on the summary, "items get sucked instantly by hoppers," this issue is working as intended per MCPE-64628. However, part of the expected behavior described is that a container on top of a hopper should prevent it from collecting. That used to be the case, but it was changed as a side effect of the fix to MCPE-54244. We are tracking that issue separately at MCPE-80555.
From my survey of the history of this ticket, I believe it should be revised again to focus on the behavior of items pushed by pistons, and not on hopper behavior. The various hopper behaviors are tracked elsewhere.
Right. I changed the summary and the tite. And are you sure the bug I describe is MCPE-80555? If so, update the status of this bug to resolved, I trust you this is the specific issue that causing this bug.
@Tal Melamed the hoppers collecting when they have a container on top is MCPE-80555, but that is not what you originally reported on this ticket.
The piston pushing items through the side of hoppers is similar to MCPE-46746. However, I've done some more testing and I think MCPE-46746 is actually fixed.
In testing that one I also figured out why pistons can push items through the side of hoppers: hoppers do not have a full side collision box. Instead, the collision box of hoppers actually matches their appearance. I do not know if it was always this way, or if this was changed in 1.16 when the hitbox was changed to fix MCPE-47541. However, I think it is probably working as intended.
There is still a bug though with the wireframe around the hopper when outline selection is turned on, which is tracked at MCPE-59928.
I can think of no other mechanic that serializes item paths when multiple paths are present.
Actually this is how hoppers and hopper-minecarts work when checking for items to pull or collect as well. While testing MCPE-38963 I found that hoppers and hopper minecarts run 3 separate checks of the chunk data in series, always in the same order. They look in turn for
- blocks with inventory
- hopper/chest-minecarts
- collectible items
Prior to 1.16 they would stop checking at the first thing they found in range. This had a few notable consequences:
- A block with inventory above a hopper/hopper-MC would "lock" it from sucking in free-floating items or items in a hopper/chest-MC. For example, items pushed up against the side of a chest by a water stream could not be collected into a hopper below the chest.
- If there were multiple hopper/chest-minecarts above a hopper, then the hopper would only be able to pull from the first of those hopper/chest-minecarts in the chunk entity list, even if that one was empty and others in the space contained items. This was reported as a bug in
MCPE-54244. - If there were multiple free-floating items above a hopper/hopper-MC (or in the same block as a hopper-MC), then the hopper/hopper-MC would only be able to collect the first of those items in the chunk entity list, even if it already contained partial stacks of the other items. In other words, an item that did not match any of the partial stacks in a hopper/hopper-MC would "lock" the hopper/hopper-MC from collecting matching items. This was reported as a bug in
MCPE-38963.
In 1.16 MCPE-54244 was fixed, but the fix eliminated both (1) and (2). The elimination of (1) is reported as a bug in MCPE-80555, and it was discovered in connection with MCPE-68912. The behavior reported in the present ticket is analogous, the difference being that it concerns the pushing function of hoppers rather than pulling.
In other words, just like
- hoppers pulling from an hopper/chest-MC that crosses the block above them on a slanted track (
MCPE-68912) is a behavior that always existed but was not discovered and did not have much impact until the fix toMCPE-54244reversed (1) and created the behavior reported inMCPE-80555,
so
- hoppers pushing into a hopper/chest-MC that crosses the block under them on a curved track is a behavior always existed but was not discovered and did not have much impact until the fix to
MCPE-54244enabled the hopper to push into the hopper/chest-MC even if there was a block with inventory below the hopper.
Both the errant pulling reported in MCPE-68912 and the errant pushing reported in the present ticket are blocked when the hopper is actively transferring to/from the block with inventory.
Neither of these issues actually relates to MCPE-57637 at all, since the issue there is the incorrect spatial range of the hopper-minecart's search for entities. Here and in MCPE-68912 the issue is how hoppers handle hopper/chest-minecart collision boxes that partially cross their correct search range (something that was unnoticed until (1) above was reversed).
(For the record, (3) was not impacted by the fix to MCPE-54244, so it still occurs.)
I have re-thought this report and the companion report on hopper pushing (MCPE-94293) and want to recommend that they be closed Works As Intended or Won't Fix. Both behaviors have always been in the game and both are actually important for advanced storage tech. The only reason they were reported as bugs is because MCPE-80555 / MCPE-109449 caused existing builds to behave differently. Assuming that MCPE-109449 will be fixed, given that MCPE-80555 was fixed 1.16.100, the behavior of hoppers toward hopper/chest-minecarts will once again controllable in traditional ways.
The underlying cause of the issue reported here is that hoppers pull from hopper/chest-minecarts based on the hitbox of the hopper/chest-minecart overlapping the hopper's pulling range. Far from being a problem, this behavior is the basis for builds that overlap hopper/chest-minecarts over 2 or 4 hoppers in order to empty them quickly. If this behavior were removed from the game it would break a lot of advance item transport and storage builds. See the picture below.
I have re-thought this report and the companion report on hopper pulling (MCPE-68912) and want to recommend that they be closed Works As Intended or Won't Fix. Both behaviors have always been in the game and both are actually important for advanced storage tech. The only reason they were reported as bugs is because MCPE-80555 caused existing builds to behave differently. Now that MCPE-80555 has been fixed in beta 1.16.100.51 the behavior of hoppers toward hopper/chest-minecarts should once again be controllable in traditional ways. (I cannot test the present report in the beta but I expect that the fix to MCPE-80555 affects both pushing and pulling.)
The underlying cause of the issue reported here is that hoppers push into hopper/chest-minecarts based on the hitbox of the hopper/chest-minecart overlapping the hopper's pushing range. This behavior is the basis for builds that position hopper/chest-minecarts under 2 or 4 hoppers in order to fill the hopper/chest-minecarts quickly. If this behavior were removed from the game it could break advance item transport and storage builds. See the picture below.
Thank you for your report!
We're tracking this issue in MCPE-80555, so this ticket is being resolved and linked as a duplicate.
This bug has already bee been fix in the current beta version. The fix will arrive in the next release version. You can check the Fix Version/s field in that ticket to learn more.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Mojang Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
However, this issue is Working as Intended.
The report you have submitted is working as intended: Previously there was a bug, tracked as MCPE-80555, where a hopper could pick up items with a chest above, but that was fixed in 1.16.100.
Please note, that mechanics of the game may change between updates.
Things such as graphics, sounds, world creation, biomes, redstone, villagers, and animals may not work the same in current versions.
Full Version History – Snapshot Version History – Feature Requests and Suggestions
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Hello,
I think we’re all familiar with hopper-minecarts pulling from other minecarts with inventory diagonally on X+1, Y+2, Z+1 going back years now MCPE-57637 and recently hopper-carts began going even more crazy with the fix for MCPE-54244 where new items in “infected” hopper-mc MUST be drained first.
I had done some reading and I believe the main reason behind this bug existing for so long is the lack of details on previous tickets to explain how serious this issue is and its connection and history of fixes I believe are related all together:
MCPE-57637, MCPE-54244, MCPE-80555, MCPE-94293, MCPE-59302, MCPE-68912
Lets start building:
1. Place chest and attach hopper to top side and then add 1 upside down slab to side of hopper and 4 more slabs to the other side to make flat surface for 3 activator rails.
2. Then place full block on top of slab furthest way from hopper and add redstone torch and repeater towards activator rails and place activator rails on 3 remaining blocks, on the full block, place lever on top and then place observer facing out and place lever on its face as well.
3. Add 2x2 inverted slabs on top of activator rail and place 4 detector rails on top of slabs, parallel to rails bellow.
4. Block each of detector rail exits with full blocks.
5. Add frames with items for orientation for example:
White – X=X, Y=Y+2, Z=Z; - Correct pull
Red – X=X+1, Y=Y+2, Z=Z; - 1 off to Right
Green – X=X+1, Y=Y+2, Z=Z+1; 1 off to Right and Bottom
Blue – X=X, Y=Y, Z=Z+1; 1 off to Bottom
6. Place hopper-cart on activator rail and use lever on observer to send a test pulse.
7. Place 4 remaining hopper-carts on top for each colour code in order: Blue, Green, Red, White.
8. Fill containers with matching colours
9. Use either of levers.
Experiment
Expected Results:
- On Pulse - Chest contain white wool
- On Switch – Hopper-mc pulls white wool from hopper-mc directly above it.
Actual Results:
- On Pulse – Chest contain blue wool
- On Switch – Hopper-mc pulled from each container above in the same order I placed them it. Blue, Green, Red, White
Additional Observation:
- For hopper-mc to pull white wool, red wool container must be empty; to pull red wool, green container must be empty; to pull green wool, blue container must be empty.
- This order is fixed. While white wool is pulled, if any other containers receive more wool, it will force pulling from that container instead. I assume
MCPE-54244is related to this. - Pull order is based on order in which hopper-minecarts were placed.
- If 2x2 square of hopper-minecarts cross chunk border the pulling hopper-mc would only remember order of those within its own chunk.
- Hopper-mc pushed towards brick wall pole is still able to pull diagonally. Tile-able designs require each hopper-mc to be placed individually and be equally pushed to the brick wall to prevent cross-contamination (very time consuming).
- Most effective way to keep hopper-carts pulling from Y+2 only was by having content in that container only when bottom hopper-cart is placed.
In summary:
Hopper-carts pull diagonally if given a chance to
Hopper-cart bellow can pull from chest-minecarts
Must pull in the same order minecart-containers above were placed – has the ability to prioritize pulling
Pushing towards brick wall did not affect pulling range
Also suggest that the source of the bug is a result of upper minecarts having their “collision box?” overlaying each other at the edge of scan from minecart bellow
Diagonal pulling only pulls from minecarts towards positive X Y Z and since I could not find any information as to how does hopper-minecart actually scans for target (mathematical formula), I can only assume this is caused by the lack of off-set for the calculation resulting in either bottom hopper-cart scanning extra area towards positive or hopper-cart invading scanned area of a hopper bellow with extra size towards negative. It could be both actually although I guess it is the second one.
I am aware that this could be considered a “duplicate” ticket and I really hope Moderators won’t close it so that players can find it and learn how to manage this diagonal pulling effect until developers can deal with it. I should probably point out that his is a new behaviour that I assume is the result of fix to MCPE-54244 and unresolved issue MCPE-57637 which exists for about 2 years now with label “won’t fix” or “work-as-intended” and now not only “can” pull diagonally but now hopper “must” stop pulling from hopper-cart directly above to pull from “infected” hopper-carts first if they have items inside.
This bug affects builds such as: Storage/item-transportation systems, Super-smelters which are the most complicated and time-consuming builds with practical application in survival worlds. It took me two days of experimenting in creative world with different combinations until I found a behaviour pattern that I want to share with you…
2 Clips attached and world in creative mode with example ready, one shows the “new” bug, the other solution – Make sure to focus on the order of hopper-carts being placed. (I am facing East on clips (X=X++))
That’s all I can do for now, I gathered the all information I could, so don’t hesitate to ask me any questions, I will answer as soon as I can.
Thank you very much for reading,
P.S. Ticket MCPE-46706 describes a behaviours which have very similar "angle" of operation - perhaps it is worth reading through as well.
The bug
Hoppers are able to pick up item entities inside them, even when they have a container above (see also MCPE-80555).
However, when there are currently items flowing through the hopper from a container above, the item entities won't be picked up causing them to despawn eventually.
Reproduction steps
See Minecraft1.16.4-Singleplayer2020-11-2917-51-57.mp4
.
- Build two hoppers above each other
- Let item entities slide on ice into the lower hopper
The item entities are picked up - Now put items into the top hopper and repeat step 2
The item entities are not picked up, the hopper prefers transferring items from above
Dear Mod's and Dev's,
I hope you will read this as I did a number of experiments which collectively answer the question "why does it happend?".
So, we all know that this applies only to the container-carts.
Only towards X+1, Y+2, Z+1.
Issue 1: do hopper-carts scan larger area towards positive coordinates?
Answer: No, based on seen contraption made to deal with random droppers drop and uneven acceleration from water, also with hopper-cart placed on different Y levels observation confirms that scan range is not the case of an issue.
Issue 2: hitboxes of container chest overlapping?
Answer: Also no, different configurations also evidence that this bug does not care for the respective rail placement (e.g. bottom rail facing N-S and upper W-E)
Issue 3: What makes a hopper - hopper?
Answer: A short line of code "minecraft:item_hopper" - not really helpful but name itself doesn't specify if thats a hopper-cart or hopper block.
Note: Hopper to hopper-cart is in its essense a trade-off of ability to push items for the mobility and additional pulling range. Although, using shared "components_groups" theoretically, suggest that any changes targetted to hopper behaviour will result in same behaviour change to hopper-cart, right?
Issue 4: Did recent changes to hoppers had an impact on hopper-carts?
Part_A: Fix from ticket MCPE-80555 denies hoppers the ability to pull through blocks.
Part_A - Anwer: Fix intended to prevent hoppers from collecting free-floating items above blocks with inventory applied to Hopper-carts!
Part_B: Fix from ticket MCPE-54244 give hoppers bellow ability to scan entities above when they're stacked.
Part_B - Answer: The fix intended for Hoppers alone applied to Hopper-cart!
Issue 5: Will container-carts slammed into honey block be within pulling range of hopper underneath?
Note: If both container-carts have equal "reactive" range to "active" pulling by a hopper bellow would further suggest that:
Behaviour to manage distance form entities towards X+ and X- must've been mathematically corrected and then hard-coded into the game.
Since hopper-carts are basically a "buff" for hoppers range of pulling indicates these two are being treated same by the behaviour control code that controls things like hopper serializing (detailed description found in comments section of tickets MCPE-94293 and MCPE-68912) 
Finally, with full confidence in my findings, I say that the reason this happens in game is because hopper-carts inherit behaviour controls that were intented only for hoppers.
The fix for MCPE-80555 in 1.16.100 (which attempted to correct the fix for MCPE-54244 in 1.16.0) applies only to hoppers/hopper-minecarts collecting items. It should be applied to hoppers/hopper-minecarts pulling from hopper/chest-minecarts as well. Indeed, that was the original context in which the issue was discovered (namely, inventory blocks no longer capping hoppers from pulling from hopper minecarts due to the way MCPE-54244 was fixed--see MCPE-68912).
Steps to reproduce
- Build either of the setups shown:
- Put items in the chest minecarts.
Expected result
The chest and barrel (and any other inventory block such as a furnace) prevent the hopper and hopper-minecart from pulling items from the chest minecarts.
Actual result
The hopper and hopper-minecart pull items from the chest minecarts despite the presence of an inventory block.
Probably intended, see MCPE-80555, which describes the opposite and was fixed.
This issue was discovered while investigating
MCPE-68912. It appears to be a direct consequence of the fix forMCPE-54244. It appears that since hoppers and hopper-minecarts no longer stop searching for inventories and items at the first hopper/chest-minecart they find, they also no longer stop searching for inventories and items when they find a block with inventory to pull from.This new logic in conjunction with the ability of hopper-minecarts to pull from hopper/chest-minecarts 2 blocks above (see MCPE-57637) allows for pulling to bypass blocks with inventory, including hoppers, in a column. Here are examples:
