mojira.dev
MC-6162

Unexpected behavior with stacked hoppers and chests

Perhaps not a bug. I'll let you be the judge. (Sorry for the wall of text.)

The attached screenshots tell a bit of a story. The first shows the front of a simple sorting system built with chests and hoppers (in the back). Items are put into the top hopper (perhaps by water stream). Shot #2 shows that inside each chest is at least one of each item (as labeled) so only that items gets put into that chest. Shot #3 shows the back, including a fourth hopper at the bottom to catch anything that doesn't fit into the chests.

Now, the behavior I would expect goes like this: Seeds, wheat, and eggs would get into the top hopper. After a time all of the seeds would be in the top chest, all of the wheat would be in the middle chest, etc. Anything not seeds, wheat, or eggs would end up in the bottom-most hopper.

What actually happens is the top hopper tries to put seeds into the top chest, and sometimes succeeds. But, the second hopper starts pulling items out of the top hopper, so they start competing to grab items. Some seeds get into the chest as intended, but some get passed down the system with nowhere to fit and end up at the bottom hopper. The same is true for the wheat and the eggs. Shot #4 shows the contents of the bottom hopper, containing items that should be in chests higher up.

Related issues

MC-6038 Hopper doesnt always put items into the container it is "Connected" to MC-7009 Behavior of hoppers is inconsistent MC-7071 Hopper block crash sucking blocks out of other hoppers MC-7081 Hopper underneath a hopper pointing to the left/right doesn't always pull item out when using as filter. MC-7136 I found a coupled bug whit hopper MC-7402 Hopper Prioritys MC-7416 Item flow from Hoppers not going the correct way MC-7741 Hoppers not taking items properly MC-7866 Hoppers fed from the side behave differently from hoppers fed from above. MC-8179 Hopper Issue MC-8398 Hopper Requires some optimization when relocating blocks MC-8687 Items won't get divided evenly among hoppers beneath a loop of hoppers MC-10141 Hopper "pipes" do not always transfer items to hoppers placed underneath them MC-10150 Hoppers not dirtibuting items fairly into droppers/dispensers depending of the configuration of non dropper/dispenser touching hoppers MC-10546 items passing through hoppers problem. MC-10586 Hopper problem 2 MC-10652 hoppers behave differently on servers MC-11828 Hoppers Act Different depending on how items are inserted. MC-12192 Hoppers bypass hoppers below that can accept items MC-13418 Horizontally connected hoppers act different than vertically connected hoppers MC-29293 automatic hopper route dedector cannot dedect route true MC-72009 Hopper taking/giving inconsistent amount of items MC-265091 Pistons reacting slower in certain chunks MC-273025 Hopper doesnt work properly

Attachments

Comments

migrated
[media][media][media][media][media][media][media][media][media]
kumasasa

... sorry, wrong ticket.
Nothing happened here 😉

Migsect

I just tested this, and I can confirm this behavior.

I think the hopper's top side's pull (topside) operation takes precedence over it's push (bottom and side) operation, which would cause this behavior.

Tanisha Angelia

Duplicate of MC-6038. It isn't a bug, the hopper retrieve items from the object above it automatically which is how they are supposed to work.

The best solution for achieving what you are trying to achieve would be to have a pipe system so you can avoid stacking the hoppers under each other; maybe Mojang will add this together with filter objects such as a filter hopper and a filter pipe (can hope), if not, then compact and complex hopper designs won't be possible, and sadly neither automatic item sorting.

Kevin Reid

This may not be a bug per se, but it is moderately inconsistent behavior — for example, I built a system like this but without intending to sort, merely three stacked chests — and the top and bottom chests got 50% split whereas the middle chest got nothing.

I think it would be worth improving the behavior so that it is less obviously "the effects of the precedence of a set of imperative rules".

For example, what if, when a hopper grabs an item from a hopper above, it doesn't grab the item if it is possible for the hopper above to place an item? Thus hoppers below hoppers never starve the hoppers above, and this sorting system would work as intended.

Corgano Wade

Hoppers need consistency - NEED it - if they will ever achieve their maximum usefulness. They should either always store the items before being able to be pulled form, or always have their items pulled to another hopper before being stored. Hell, even a switch between "store" and "pass along" mode. It just needs consistant

Kyle Egli

Well, there are two somewhat simple solutions to the issue really, adding a Pipe item, which would also keep the Hopper 'simple', or giving Minecarts more love. Though I'm sure Dinnerbone will have his own ideas on the matter, and sure, you could currently use dispensers and water and a space consuming setup as a filter to get a similar effect to pipes, but that doesn't work for projectiles or unstackable items, I figure I'd put in my 2 cents on the matter.

Pipes could have 2-6 slots (or however many one thinks would be needed), 1-5 to transfer items with, and the other to act as a filter (which if empty would let all items through), then the problem is solved. Though to solve the issue of pipes not knowing which way to go, you'd want to make the face the pipe is placed against an input-only face, which would allow for the other 5 directions to either input items or receive items. Then you'd just prioritize items going into filtered pipes first, and unfiltered pipes last.

Of course, the pipes wouldn't be able to transfer items upwards, only sideways and down, as is logical and how hoppers already are, and thus still requiring minecarts or the like to move items upwards. Crafting recipe could probably be how rails are done but turned on their side, with a nether quartz replacing the stick, and could give 4-8 pipes per.

More importantly, adding pipes would give a nice bit of aesthetics to moving items around, rather than the clunky mess that a chain of hoppers currently is.

Alternatively, more functionality to minecarts, rails, and etc to make it possible to do something along the lines of the suggested pipes. Haven't really thought on it that too much though, so couldn't give any ideas on how one would do that.

Travis Goettl

I have had a similar issue with this except I know my issue is a bug. I set up a pipe like system running horizontally about a dozen hoppers into them selves eventually leading to a chest. then below this row of hoppers I set up another row of hoppers pointing in various directions (left, right, and down). inside the lower hoppers I placed one item of various natures in each of the slots (one hoppers all oak saplings, one hopper all red stone dust, etc.) at the beginning of the top row of hoppers I placed a chest and proceed to place stacks of the items that were in the lower row of hoppers. about half the items went where I expected into the lower hoppers with their respective items inside and half continued onto the chest at the end of the top row of hoppers (all items of a specific type acted the same, ex. All birch saplings pasted their hopper and went to final chest, all oak leaves went to their hopper.) I looked for a pattern as to why they wouldn't go into the right hoppers but it appeared to be random. Replacing the hoppers fixed one of the infected hoppers but most of them continued to refuse their items. (playing in creative)

William Rust

Since any issue relating to item transferring through hoppers is considered a duplicate with this, despite the specific nature of this Bug post... I will just like to point out a SIMILAR but definably different issue I am having with hoppers... That is a problem with their priorities, and that they don't seem to be consistent, and seem to change depending on if blocks are placed/removed around them (an updating issue?). This is especially the case when you have a hopper pushing items to a chest by its side, and another hopper under this first hopper. If this is built, initially the hopper below will take priority and will pull items from the above hopper before it gets the chance to push them into the chest. However after some block refreshing and/or restarting the game, the priority changes and the hopper now always pushes items into the chest. This issue seems to be more present, when a third hopper is feeding items into the inconsistent hopper - if this is the case items more often are pushed into the chest. However if items are placed STRAIGHT into the inconsistent hopper, then they will be pulled by the hopper below.

Anyone get something similar? I'm fairly sure this is subtly unique to this Bug report, yet its implications mean different things.

Jesper the End

Yup, I'm having a same issue here, just a bit different I think.
I used this (take a look at attachment) for a sorting system and I want it to go down in to the bottom chest, but instead it goes to the chest on the right hand side.
Currently It is only sometimes going to the bottom chest, I don't know which way it is supposed to take (I prefer the bottom one) but the way it is now (random) is definitely wrong.

William Rust

Issue still present in snapshot 12w03a 😞

William Rust

I'm confident that I have isolated a bug... (see screenshot above with words scribbled on it)... If a hopper pulls an item from a chest it is pulled by hoppers underneath... if it is placed (or pushed into by another hopper) into a hopper, it will take a different priority... that certainly seems like a bug to me!!

William Rust

Items put into slot 1 a hopper will be pulled by hoppers underneath (as a priority over being pushed by the above hopper to the side). Items placed into slot 2 of a hopper will be pushed sideways (as a priority over being pulled by any hopper underneath)

Mike B

I just tested this graphical example (https://mojang.atlassian.net/secure/attachment/18903/2013-01-17_18.36.44.png) from the attachments above. All four cardinal directions work fine, and both blue and red wool go to the correct chest.

Jesper the End

Sometimes it works fine, but because of some sort of update the hopper get's 'broken' and then it doesn't work the way it did anymore.

Thomas Overbeeke

I confirm this bug and its REAALY ANNOYING

William Rust

As a temporary fix, introduce a chest into the hopper system (i.e. somewhere are the top just before the hoppers start pushing different directions - I found this fixes the issue (temporarily - the big is still there). I believe it is to do with the hoppers placing items in either slot 1 or slot 2 of the hoppers' inventory - this for some reason also dictates where the items end up further along the chain...

Jesper the End

I think this explains very well what is the way it should work: http://youtu.be/h80qAGuJxkw?t=5m37s

Jesper the End

I added a world file (test) with two item sorters. If you want both item sorters to work, the item sorter has to look which hopper has the most amount of items of the item the hopper wants to move and go into the chest/furnance/hopper with the most items.

Justin Bourassa

I thought my sorting system was fool proof until I tested it. The hopper priorities do not work as I expected or as the wiki stated so I am rather confused. I can CONFIRM this does happen.

Zipron Brendt

Made a quick video to illustrate the issue: http://youtu.be/jMszbxiBqKQ
I can confirm this is just very random, and it will change when chunks are reloaded.

WolfieMario

Confirmed for 13w05b.

Added a schematic of vertical and horizontal hopper sorters. Both are effected by this bug, and the behavior is very inconsistent. This is problematic, as I wanted to make a multi-item detector with hoppers to replace my old ice-based one - hoppers would have allowed for faster rates (important for the system I'm working on), but this would entirely fail to detect items at random - and worse, depending on unknown chunk loading factors, some items will be impossible to detect until the chunk is reloaded. Thus, the behavior is very inconsistent to say the least.

A possible fix would be to give higher precedence to sucking items from a container than pushing items to the next one: in this way, a horizontal sorter would function as intended, because all items would have a chance to be sucked out before they are pushed on to the next hopper.

EDIT: A workaround for sorting items is to use Droppers, which work like the Allocator: when powered, they stick their contents into the next container. Chain droppers above a line of hoppers, and activate the dropper after a little delay if it has any contents (use a comparator, and feed the wire back to the dropper).

The downside to this is that it fails if more than one item travels through at a time, so it'd be slow at sorting, but still faster than an ice-based system for item detection (I believe forcing the dropper to dispense into the next dropper in the chain after a delay allows this to be faster than an ordinary hopper pipe: two ticks of redstone delay is less than the natural 3.5 ticks offered by hoppers. Thus, if an item is not the target, it will move along quicker than normal. I think you'll be forced to only have every other block a dropper, and the rest hoppers which feed into the next dropper, in order to avoid crossing wires when activating the dropper. Regardless, a width of two is faster than a width of five for an ice detection scheme: the ice scheme transports items at twice the rate of a hopper pipe (a normal ice pipe will transport items at four times the rate), but the distance is more than halved and the delay is reduced even more by each dropper, thus improving performance overall).

Regardless, this workaround is very expensive for a survival setup, and far less compact (as I said above, to avoid crossing wires, you'll need a line of droppers/hoppers twice as long as normal).

WolfieMario

I found a more elegant and compact workaround to this bug: you can manually control priority by powering hoppers you want to be lower priority, and depowering them with a comparator output from the hopper: This gives the "higher priority" hopper a better chance of grabbing the item if it can. Note, however, that this inconsistent timing bug is still present: you can make it less likely by increasing the delay before depowering the hopper, but it still can rarely happen (this really shouldn't be possible once more than 3.5 redstone ticks of delay have passed).
Here's a screenshot: http://i.imgur.com/cBDxnCI.png

I've also added a schematic above.

EDIT: Oh, and this version also has the issue of only being able to handle one item at a time.

Jesper the End

that video (http://youtu.be/jMszbxiBqKQ) really showed the problem, go watch that mojang!

Zipron Brendt

Still bugged in 13w06a.

Jesper the End

Confirmed for 16w06a

Zipron Brendt

confirmed for 13w07a

Zipron Brendt

confirmed for 13w09a

Zipron Brendt

confirmed for 13w09b

Jesper the End

I think it's kind of fixed in 13w09c, your system still doesn't work though, but a sideways stacking system works perfectly now.

Steve Blanding

No. It's NOT fixed in 13w09c. And a sideways stacking system does NOT work perfectly. It works a little better than it used to but I have verified that it is still quite broken.

Samuel Bliss

Ya, I checked if it was fixed and got really excited but turns out it's still broken... No easy Item sorting :'( (unless you use minecarts)

Zipron Brendt

Confirmed for 19w09c

Jesper the End

OK, I was wrong, it's still there, but at least it's better.

Zipron Brendt

This bug is fixed in 13w01a!

rocketturtle

Confirmed in 13w10a.

kumasasa

@Zipron Brendt, Rocket Turtle: Is this bug fixed in 13w10a or still persisting in 13w10a ?

Jonathan S

Looking at how things were affected in this update I would say that we have been seeing two different bugs/game mechanics actually occurring.

The first bug/mechanic is when when hoppers are stacked vertically. Hoppers constantly try to pull things out of the hopper above them. Prior to 13w10a, when hoppers did their pulling was rather unpredictable. To demonstrate this unpredictably build a tower of 4 hoppers when a chest at the top and bottom and comparators + repeaters reading the levels of every hopper. If you put a stack of items in the top chest in 13w09a/b/c some of the repeaters with light, some will blink and some will just stay off. It appears as if there is no ryhme or reason behind the pattern as it will change if you rebuild the test in a different location or re-log. In 13w10a, the test stack becomes more predictable, but it still does not match up with what is expected as only the bottom repeater will light up for me, no matter the stack size or if I point the hoppers down or to the side. Watching the slots in the hopper tower it seems that hoppers are sucking items before the comparitors have had a chance to update, and since the bottom hopper doesn't have anything sucking items from it, one item appears to get stuck until the bottom is not able to suck stuff from above.

The second bug/mechanic was visible prior to 13w10a, and it occured when items were moving sideways through hoppers. Items would seemingly skip hoppers and not get sucked down by hoppers below. This seems to be related to MC-10679, as it now works correctly in 13w010a.

Zipron Brendt

It is definitly fixed the way I used to encounter it. I'll upload a video about it in an hour to confirm. Tested it in creative and survival now, the same setup I had since 13w05a, and it works like a charm with 500+ hoppers.

rocketturtle

@Kumasasa The original behavior that I reported to start this ticket does persist into 13w10a (I reran my original tests in a new map). However, even then I suspected what I saw wasn't the result of a bug per se, but unfortunate behavior in stacked hoppers.

tl;dr Yes, still going in 13w10a.

kumasasa

Ok, thanks for the feedback.

Zipron Brendt

http://youtu.be/gROZ6Ip2ZhE proof that this works

Steve Blanding

@Kumasasa: I can confirm Rocket Turtle's observations. Horizontal hopper behavior now appears to work correctly. Vertical behavior still seems to be a little less correct.

This is a great improvement and I could live with this just it is now but it doesn't appear to be 100% correct just yet.

Jesper the End

horizontal works as expected now, hoppers got waaayy slower though, but I can live with that.

Michael Turner

May be related to MC-8457.

neurospex

This seems to be broken again. I if I make a vertical stack of chests and point hoppers into them, items which go into the top hopper will either all end up in the bottom chest, or half in the top and half in the bottom. Any middle chests will be skipped for some reason.

It should be desired that if a hopper is pointing in to a chest or another hopper, that should take priority. Items should be fed from the hopper into the desired destination with a higher priority than another hopper trying to pull from that hopper by being below it.

A player shows intention with a hopper by directing it at a destination. This should be higher priority than placing a hopper below another, with the upper hopper /not/ pointing directly at the lower hopper.

neurospex

@Phil71994 Please don't make duplicate reports.

Having done more thinking on this issue, here is what I propose:
If a hopper points into anything other than a hopper, then if the object it points in to can accept items, that should take priority over a hopper below that hopper. If a hopper points into another hopper, than the hopper below the original hopper should take priority over the direction the original hopper is pointing. This allows all old contraptions to still work while making new contraptions allow for storage item sorting.

rocketturtle

(Unassigned)

Community Consensus

chest, hopper

Snapshot 13w01b, Snapshot 13w02a, Snapshot 13w02b, Snapshot 13w03a, Snapshot 13w04a, ..., Snapshot 13w09a, Snapshot 13w09b, Snapshot 13w09c, Snapshot 13w10a, Minecraft 1.5

Retrieved