Unexpected behavior with stacked hoppers and chests

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.

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)

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.

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.

Issue still present in snapshot 12w03a 😞

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!!

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)

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.

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.

I confirm this bug and its REAALY ANNOYING

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...

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

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.

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.

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.

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).

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.

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

Still bugged in 13w06a.

Confirmed for 16w06a

confirmed for 13w07a

confirmed for 13w09a

confirmed for 13w09b

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

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.

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)

Confirmed for 19w09c

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

This bug is fixed in 13w01a!

Confirmed in 13w10a.

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

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.

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.

@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.

Ok, thanks for the feedback.

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