[MC-6162] Unexpected behavior with stacked hoppers and chests Created: 05/Jan/13 Updated: 08/Jun/24 Resolved: 21/Oct/13 |
|
| Status: | Resolved |
| Project: | Minecraft: Java Edition |
| Component/s: | None |
| Affects Version/s: | Snapshot 13w01b, Snapshot 13w02a, Snapshot 13w02b, Snapshot 13w03a, Snapshot 13w04a, Snapshot 13w05a, Snapshot 13w05b, Snapshot 13w06a, Snapshot 13w07a, Snapshot 13w09a, Snapshot 13w09b, Snapshot 13w09c, Snapshot 13w10a, Minecraft 1.5 |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Rocket Turtle | Assignee: | Unassigned |
| Resolution: | Works As Intended | Votes: | 37 |
| Labels: | chest, hopper | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Community Consensus | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
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. |
| Comments |
| Comment by Spex [ 18/Aug/14 ] |
|
@Phil71994 Please don't make duplicate reports. Having done more thinking on this issue, here is what I propose: |
| Comment by Spex [ 31/Mar/14 ] |
|
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. |
| Comment by Michael Turner [ 23/Mar/13 ] |
|
May be related to MC-8457. |
| Comment by Jesper the End [ 05/Mar/13 ] |
|
horizontal works as expected now, hoppers got waaayy slower though, but I can live with that. |
| Comment by Steve Blanding [ 04/Mar/13 ] |
|
@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. |
| Comment by Zipron Brendt [ 04/Mar/13 ] |
|
http://youtu.be/gROZ6Ip2ZhE proof that this works |
| Comment by Kumasasa [ 04/Mar/13 ] |
|
Ok, thanks for the feedback. |
| Comment by Rocket Turtle [ 04/Mar/13 ] |
|
@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. |
| Comment by Zipron Brendt [ 04/Mar/13 ] |
|
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. |
| Comment by Jonathan S [ 04/Mar/13 ] |
|
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 |
| Comment by Kumasasa [ 04/Mar/13 ] |
|
@Zipron Brendt, Rocket Turtle: Is this bug fixed in 13w10a or still persisting in 13w10a ? |
| Comment by Rocket Turtle [ 04/Mar/13 ] |
|
Confirmed in 13w10a. |
| Comment by Zipron Brendt [ 04/Mar/13 ] |
|
This bug is fixed in 13w01a! |
| Comment by Jesper the End [ 01/Mar/13 ] |
|
OK, I was wrong, it's still there, but at least it's better. |
| Comment by Zipron Brendt [ 01/Mar/13 ] |
|
Confirmed for 19w09c |
| Comment by Samuel Bliss [ 01/Mar/13 ] |
|
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) |
| Comment by Steve Blanding [ 01/Mar/13 ] |
|
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. |
| Comment by Jesper the End [ 01/Mar/13 ] |
|
I think it's kind of fixed in 13w09c, your system still doesn't work though, but a sideways stacking system works perfectly now. |
| Comment by Zipron Brendt [ 27/Feb/13 ] |
|
confirmed for 13w09b |
| Comment by Zipron Brendt [ 26/Feb/13 ] |
|
confirmed for 13w09a |
| Comment by Zipron Brendt [ 14/Feb/13 ] |
|
confirmed for 13w07a |
| Comment by Jesper the End [ 07/Feb/13 ] |
|
Confirmed for 16w06a |
| Comment by Zipron Brendt [ 07/Feb/13 ] |
|
Still bugged in 13w06a. |
| Comment by Jesper the End [ 02/Feb/13 ] |
|
that video (http://youtu.be/jMszbxiBqKQ) really showed the problem, go watch that mojang! |
| Comment by WolfieMario [ 02/Feb/13 ] |
|
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). 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. |
| Comment by WolfieMario [ 02/Feb/13 ] |
|
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). |
| Comment by Zipron Brendt [ 01/Feb/13 ] |
|
Made a quick video to illustrate the issue: http://youtu.be/jMszbxiBqKQ |
| Comment by Justin Bourassa [ 23/Jan/13 ] |
|
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. |
| Comment by Jesper the End [ 23/Jan/13 ] |
|
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. |
| Comment by Jesper the End [ 22/Jan/13 ] |
|
I think this explains very well what is the way it should work: http://youtu.be/h80qAGuJxkw?t=5m37s |
| Comment by William Rust [ 22/Jan/13 ] |
|
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... |
| Comment by Thomas Overbeeke [ 22/Jan/13 ] |
|
I confirm this bug and its REAALY ANNOYING |
| Comment by Jesper the End [ 21/Jan/13 ] |
|
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. |
| Comment by Mike B [ 21/Jan/13 ] |
|
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. |
| Comment by William Rust [ 17/Jan/13 ] |
|
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) |
| Comment by William Rust [ 17/Jan/13 ] |
|
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!! |
| Comment by William Rust [ 17/Jan/13 ] |
|
Issue still present in snapshot 12w03a |
| Comment by Jesper the End [ 16/Jan/13 ] |
|
Yup, I'm having a same issue here, just a bit different I think. |
| Comment by William Rust [ 16/Jan/13 ] |
|
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. |
| Comment by Travis Goettl [ 16/Jan/13 ] |
|
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) |
| Comment by Kyle Egli [ 14/Jan/13 ] |
|
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. |
| Comment by Corgano Wade [ 08/Jan/13 ] |
|
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 |
| Comment by Kevin Reid [ 05/Jan/13 ] |
|
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. |
| Comment by Tanisha Angelia [ 05/Jan/13 ] |
|
Duplicate of 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. |
| Comment by Migsect [ 05/Jan/13 ] |
|
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. |
| Comment by Kumasasa [ 05/Jan/13 ] |
|
... sorry, wrong ticket. |