Latest comment: 30 January 20245 comments4 people in discussion
Based on the discussion above here on the Talk page, it seems that a hopper will push and pull in one action, and then wait for the cooldown. The info box "Hoppers push before they pull" seems to suggest that only one of these actions can take place: "Next time, the hopper is empty, so it pulls." Unless I'm pretty mistaken, this is wrong. The text in the article says "Item pushes and pulls are processed in the same game tick, but pushes are processed before pulls (see schematic, right)." This sentence could be more clear about whether the pushes and pulls happen at the same time for each hopper, or just globally (again, I'm pretty sure it's each hopper). The schematic referenced contradicts the point being made, though. If corrected, the schematic/info box will not have any unique or helpful information, so I'd recommend just deleting it. krs013 (talk) 08:21, 8 April 2020 (UTC)
Agreed. The diagram text is incorrect if more than one item was in the chest, because it would both push and pull following the 1st cooldown. The idea behind the diagram might be helpful if it went through the process starting with 2 items in the chest. Then at least you could see how the process of pull / push + pull / push. GreenBeing (talk) 13:57, 1 May 2020 (UTC)
Fixed, hoppers do prefer to pull over push. As of 1.20 you can test this out in-game by throwing an item into a chain of hoppers. Have a hopper line to go in a direction horizontally and a hopper underneath that pulls from the line downwards. The horizontal line never points downwards, meaning the only way the item can transport vertically is if hoppers pull before pushing. Throw an item into the first hopper in the chain and it will always go downwards before trying horizontal. The only times where the item ends up moving horizontally is when the descending hopper is full. I see where confusion can happen, if you are rapidly throwing in items or the hopper is transferring many items in quick succession, the hopper pulling itmes down is on cooldown, thus letting items slip by horizontally. NPhlames (talk) 09:46, 7 October 2023 (UTC)
Latest comment: 8 December 20201 comment1 person in discussion
It appears that, in the list of items hoppers interact with, that Furnace, Blast Furnace, and Smokers are all covered by the paragraph under Smoker. Should the three items be combined, perhaps with commas or a header?
Latest comment: 27 November 20243 comments2 people in discussion
I tried dropping an item into the start of a water stream that led to a locked hopper, and another item directly onto the hopper. The item that was dropped first was sucked in first after the hopper was unlocked, instead of the item that contacted the hopper first. This seems to indicate either the order is arbitrary (as in Bedrock) or is based on the entity ID or creation time.
Implementing functionality to keep track of which entity _landed_ first would probably be really messy, you'd have to involve the physics sim, and have the hopper store a list of entities or something. They probably just implemented sucking items using the equivalent of a direct GetEntitiesInBoundingBox call, and the order goes by whatever ordering that method returns. 51.6.173.10411:59, 11 April 2021 (UTC)
I decided to do some testing to see if I could figure out how it worked. After extensive testing and many wrong leads, I think I found three distinct levels of priority. They are listed and explained from lowest to highest priority.
Testing Environment:
- All tests were done on a new singleplayer superflat world created in Java Edition 1.21.3.
- Certain gamerules were disabled (weather & daylight cycle, mob spawning, and possibly mob loot or 1–2 other gamerules).
- No mods, resource packs, datapacks, plugins, or experimental packs were enabled.
- Initial tests were done with just throwing items onto locked hoppers. Refinements were made to get the full parameters and specifics with the use of commands — /tick, mostly, and the occasional command block.
The following are the levels of priority I found, from lowest to highest priority. Most tests were refined until I could replicate it consistently using locked hoppers to be unlocked when ready, and often usage of the /tick command.
The item that has been in the same chunk as the hopper's chunk for the longest will be prioritized. This includes 16-block vertical chunks as well (subchunks), which is what I'm referring to when I say "chunk" past here..
Results of various tests and circumstances:
- Two items thrown within the chunk: First thrown is first.
- One item thrown within the chunk, one from outside: Item thrown from inside the chunk is first.
- Two items thrown within the chunk, but one is ferried out and back in: Item that doesn't leave the chunk is first.
- Item One, Item Two, then Item Three (I3 should be stackable with I1) are thrown: If Item One moves to Three to stack, then Item Two is picked up first. If it's the other way around, then Item One is first.
- Two items thrown within the chunk during the same tick: Item thrown first is usually first. I had a couple times where that wasn't the case, but it may have been caused by Priority 2.
I have not tested what happens when two items created at the same time are moved into the hopper's chunk in the same tick. I also haven't tested which item is prioritized when created from two dispensers or command blocks at the same time. I'd guess it might check things like age, position, motion, item ID, item name, or just be random.
An item that is both moving and is at least partially inside the hopper's physical hole/drop, will have priority over an older but non-moving item.
For a better explanation:
- Hopper is locked and at Y5. Standing on top of the hopper would put you at Y6.
- Item One is thrown somewhere the hopper will be able to grab it.
- Item Two is thrown at the hopper.
- Once Item Two has gone inside the hopper's hole — so its Y position is less than 6.0 and equal to or greater than 5.6785 — the hopper can be unlocked.
- If Item Two is moving, and Item One is not, then Item Two will be prioritized. It can be falling, sliding on the ground, anything; any movement on any positive or negative axis is fine. I believe the item must change its position on the tick that the hopper tries to pick up an item. This movement does not have to be a lot, but its position does need to change. Keep in mind that items can have very small amounts of motion that won't actually cause them to move for several ticks. This was the cause of many of my problems before and even after I discovered it, as an item could look stopped only to move a tiny bit when I unlocked the hopper, ruining the experiment.
Priority 2 is easiest tested with /tick freeze, /tick step, and either summoning items that have momentum using a command block (summon item <x> <y.6785 or -y.3125> <z> {Item:{id:"diamond"}, Motion:[-0.1,0.0,0.0]}), or timing unlocking the hopper when a thrown item is falling/sliding into the hopper hole.
I haven't tested which item gets priority if both are moving. My guess would be checking Priority 1, age, position, or highest velocity.
I have not tested if there's any change when the item's position is below 5.6785 (the floor of the hopper). I also actually did most of my tests at Y=-60, but changed the numbers to positive versions to hopefully make it easier to follow.
Obviously, an item that a hopper can actually pick up is prioritized over an item that's currently too far away.
What the wiki says
Now let's move onto what the wiki currently states for the order that a hopper picks up items from a broken armor stand:
The only accurate part of this is the order, as far as I can tell. Especially with /tick step, you can see that the armor pieces usually land within a couple of ticks of each other but not always in that order. I've had a run where the boots landed last by one or two ticks, and was still picked up first. Rather, it seems that the items are following a form of my Priority 1. While the items aren't being dropped by a player, they're all still being created on the same tick; so the first one created is picked up first. Just in this case, the item first created depends on the slot — first is the stand itself, then the boots slot, leggings slot, chestplate, and helmet.
You can see this with other containers as well. I did a small amount of testing with a full barrel, and the hopper always picked up the top first left slot first, then top second left, until reaching the item that was in the bottom right slot. The barrel itself gets picked up last.
Interestingly, going back to the armor stand, it seems that if left to free-fall a decent distance, so that it would pass a vertical chunk border, the order is still retained. Perhaps they were all entering the chunk within the same tick, or it allows for a few ticks of buffer.
However, if the items land on another block before reaching the hopper chunk's border, then the order usually gets messed up. I could also delay the boots from falling with the command /data modify entity @n[name="Diamond Boots"] Motion set value [0.0,0.0,0.0], which successfully takes the boots out of the pre-defined order.
If needed, I could probably make a video showcasing everything I've explained here, but I have nothing prepared at the moment.
Slight update to what I said. In addition to Priority 2 (Momentum inside hopper), it seems that items in the hopper hole can sometimes gain priority for no reason that I've been yet able to identify, even if they don't seem to be moving. They can get priority over other items in the hole or items on top, even if their Motion has been set completely to zero (though they do retain some very small vertical motion, but don't actually appear to move).
After setting up a system to ensure each test was the same, I realized I was getting repeating seemingly random results.
- 4T First hopper depowered, allowing items to be collected
- Each subsequent hopper (starting left → right) delay increased by 1T, except #13 which did not get an increase by accident
TL;DR: Hoppers and items automatically get reset, spawned, set to zero motion, and picked up by the hoppers with 1 redstone tick of delay between each one.
I ran the test 10 times, and marked which hoppers picked up the second item first. The following format is HOPPER#. <list of tests in which the hopper picked up the newer item first>
None
2, 6
3, 7
None
None
2, 6, 10
3, 7
4, 8
2, 6, 10
2, 6, 10
1, 5, 9
4, 8
1, 5, 9
2, 6, 10
1, 5, 9
None
Note how not every repeater ran into issues, and the ones that did repeating every fourth test. I'm not sure what's causing this. There was no standard delay in between each test.
Hopper #2 is an outlier, but I may have missed marking it down.
I decided to run the test again another 15 times, but after removing the incremental delay. Here are the results:
13
14
11, 15
None
None
14
11, 15
12
14
14
13
12
11, 15
12
11, 15
None
While there were less tests to go off of, it seems they still following the "repeat every four tests" pattern. Many (but not all) of the tests lined up with or continued from the previous tests. The ones that did not continue where the previous tests left off are #1 (None→13), #2 (6→14; may have missed a count round 1), #13 (9→11), #14 (10→12), #15 (9→11). Hoppers 13–15 give us valuable data, though — they started only 2 tests after the previous set rather than 4. (Probably not) coincidentally, on the first set, hoppers 13+ deactivated 1 redstone tick (2 game ticks) faster than I had intended.
As of when I did those tests, not all of the Item 1s are spawned/modified at the same time. I won't re-list all the results results a third time, but after making the item spawns identical, I ran 8 more tests. I confirmed it still repeated after four. Here are which hoppers had it happen for each run:
Test#: Hoppers Affected
Never: 4, 5, 16
One, Five: 2, 6, 9, 10
Two, Six: 3, 7, 13, 15
Three, Seven: 8, 12, 14
Four, Eight: 1, 11
Anyway, that's all from me for now. Oh, a couple more small things I wanted to say about moving items in hoppers getting priority: I have not properly tested whether this is the case if: there's many items waiting for the hopper; the hopper's already unlocked and taking items; or for the strangeness in this post.
Latest comment: 14 October 20242 comments2 people in discussion
A hopper can push items downwards and in the direction it faces. The logic behind it eludes me. It seems that a filled hopper pushes half its items downwards and half sideways. But with a chest on top, it pushes everything downwards.
Is anyone familiar with this functionality and can add information? LowerDecks (talk) 23:35, 14 October 2024 (UTC)
Latest comment: 4 November 20241 comment1 person in discussion
With two hoppers underneath a large chest, one will always take precedence if a single item appears in that chest. I have not been able to determine through experimentation of building order which hopper takes precedence, however, so I assume this is related to compass direction. If anyone knows how this is determined, it would be good to include that information in the "Chest" / "Trapped Chest" bullet of the "Container Interactions" section. Foxprimegames (talk) 21:02, 4 November 2024 (UTC)
If you don't understand feedback you should leave it unresolved. Not just resolve it without doing anything. Other editors may understand what you don't. Mudscape👁 Image talk15:55, 17 March 2025 (UTC)
Here's a reply with more details that was left as feedback.. appending it with this issue.
"there's "Item Hopper" string with translation key "container.hopper" in Crowdin"
Seems they expected to find “container.hopper” in the data values section because they don't know what it's refering to in CrowdIn, but container.hopper is missing in the article. -BrianGLHF (talk) 03:14, 31 March 2025 (UTC)
Latest comment: 11 November 20253 comments2 people in discussion
Resolved
In the History section under Version 1.5 snapshot 13w02a, it states, "Hoppers now output 1 signal strengh per 1/3 of a stack (21 items) when interacting with a redstone comparator." Is this true, that the signal strength used to increase once every 21 items? If so, at what point did it change to the modern iteration of every 23 items? Because there is no other mention of this in the article.
Side note: there is a typo in the article in the part I quoted: "strengh"
I checked and yes, it was like that in 13w02a but it was changed again in 13w02b to the current system.
Since the thing that changed is the algorithm that's used to determine the signal strength depending on the amount of items, all containers are affected. Because of this I'm currently contemplating the idea of removing that history line entirely (I've already added the 13w02b change to the comparator's history). Either that or it should be added to all containers' history section, but I think it makes more sense to only have this change mentioned in the comparator's page, since it's related to the comparator's output signal. SworderExert (talk) 17:28, 26 October 2025 (UTC)
Latest comment: 24 October 20251 comment1 person in discussion
Unresolved
Still no mention of that (see #Feedback (Sun, 16 Mar 2025 11:03:01 UTC)). Should be mentioned somewhere in article. (likely data values) We could also make an article that lists translation key formats for different things and where are the strings used.
Latest comment: 10 January3 comments2 people in discussion
The text before my edit stated that items inside the hopper block are always collected, regardless of the block above.
In Java Edition, this is definitely not true, I've verified this in the code. I assume that that sentence only described Bedrock Edition and have changed the text thusly. I do not have access to Bedrock Edition though, so I'd be glad if someone verified this. Siphalor (talk) 13:35, 10 January 2026 (UTC)
It seems to be the opposite: the item is collected in JE but not in BE. Here's the test I used to verify this:
1) Place down a hopper and power it
2) Throw an item inside of the hopper (make sure it lands inside, not on the outer rim)
3) Place a container on top of the hopper and then depower the hopper
Apparently the game has two different methods that both collect items inside the block.
While the "normal" method that also collects item from above gets blocked by blocks above, the other one that only collects items from inside for some reason doesn't get blocked.
