Hopper usage poll

Discussion in 'Community Discussion' started by Aikar, Sep 9, 2013.

?

Making hoppers move entire stack instead of 1 by 1

Love the idea, helps me 136 vote(s) 59.6%
This would hurt my creations (please explain in thread) 40 vote(s) 17.5%
Doesn't affect me (or I don't use hoppers) 52 vote(s) 22.8%
Thread Status:
Not open for further replies.
  1. I was quite disappointed when I first used hoppers and found them moving one item at a time. So actually, once I kicked the harvest off, I would go to the hopper and manually empty it into the chests.

    For me, if you made hoppers transfer a stack per tick, it would make them do what I expected them to do in the first place. This change would fix the broken hoppers we currently have!
    PandasEatRamen likes this.
  2. is it possible to make a setting so we can choose to make them move by stacks or by item? Sort of like the export/import buses in FTB. (Correct me if i am wrong on that.)
  3. Don't Slow It Down To Much
  4. Great Idea! Helps me in every way possible. Why hasn't this been fixed already or at least when the hoppers were added to mc. With it changed to 1 stack in every slot, my wheat plantation will successfully be picked automatically without me having to stay there and empty the hoppers manually. :cool:
  5. i think even if you made it pull 32 at a time, im sure there is a configuration that would work for sorters, and for brewerys, it shouldnt be affected, current config for sorters is 17 and 1 with a 1-1-1 filler, but if you just kept it all at 1, the item sorted would fill the first slot to 33 and only pull 32 without breaking anything.
    Cinnamonyoshi likes this.
  6. i accidentally voted for not doing it, but after i read some of the comments i see that it would do no harm but still what would happen with the brewing, like what i mean is that would i simotaniously brew the portion or in normal cases with the akwerd potions would not brew twice say there was a potion that would take an akward potion and then a nether wart, would it brew twice? (im realy bad at spelling and sentences.)
  7. This would completely ruin my auto-smelter design, because of the fact it distributes items evenly to each of the 15 furnaces. However, I think a single hopper event flag would be useful if this was to get implemented.
  8. Res flag would be good.This would completely mess up most of my hopper stuff.
  9. I don't think a res flag is the way to go. Do all of you non supporters that only have one res want to have to choose between if you want a potion maker, some sort of sorting device big or small, hopper timer, OR a faster auto farm on your property. You shouldn't have to. There needs to be away to separate the two hopper types completely.

    I give you the following example. Lets say I have half my 60x60 res with an auto harvesting sugar cane farm. It is constantly self harvesting so there are thousands of events per hour. Having the per stack drain would be fantastic for that and help to reduce workload on the servers BUT if I decide I want to add in just one teeny tiny double hopper clock for a stone generator, or a small item sorter to help with filter donations then I am forced to set a flag that slows down every hopper on my entire res.

    Example 2: I have a hopper in the wild, what flag do I set......

    Again, if we decide to make a stack draining hopper, it needs to be a separate item completely. Flags don't work 100% nor does placing signs. You either need two separate blocks or a way to set a mode per hopper, kind of like subtraction mode on a comparator, and it needs to be visually detectable to help with quicker classification for building and investigative purposes.
    NetherWorld666 and cddm95ace like this.
  10. Signs AND res flag then.And a separate item.
  11. There are a couple things that worry me about this. I mentioned them yesterday but I don't see any responses to them yet.

    Aikar said yesterday that 30% of the event overhead he is seeing is from Hoppers. Most Hoppers that are being used for collection are going to nearly always be empty and only move a few items at a time. I think that is the application where the most Hoppers are being used, so I would think that most of what the server is doing is checking empty Hoppers to see if they need to be updated. It seems to me that no amount of flags, signs, or smart internal block shuffling is going to help much because most of our Hoppers are in an active state only part of the time.

    But the report Aikar linked to seems to contradict what I would expect. I'm not sure what the labels in it mean exactly, but they seem to suggest as he has stated that the overhead is being caused by items moving through Hoppers. The percentages don't make much sense because the total in the section it is from is over 100%, and it is unclear to me whether the "-" in "tickTileEntity - TileEntityHopper" means minus or is for clarification, but I think this line is the one he referred to as representing 10 million events in less than 3 minutes:
    50.55% 0.02% 83.738 s 0.0085 ms 9,870.61k ** tickTileEntity - TileEntityHopper

    Can anyone explain this? Are just a few people really routinely running the equivalent of nearly three thousand double Chests of items through Hoppers in three minutes of time? What in the world are they doing? Farms, Sorters, Timers, all of the above?

    I keep my auto Furnace full of fuel from a Chest. Is it possible that all the items that are stuck in Hoppers that are being used in Sorters, Timers, and auto Furnaces are causing updates even though no items are effectively being moved? Or possibly, are all these dormant Hopper items themselves causing overhead because they could move under the right circumstances? Is it possible that these events include both item events and empty Hopper checks? Rather than trying to move more stuff faster, and perhaps this is already addressed in the Hopper code, we should consider first whether we need to move anything at all. Also, are there simply so many Hoppers placed, empty or not, that the server is being overwhelmed by updating them all? If so, it may be that we will eventually need to limit Redstone just like we have a limit on animals.

    The other thing was this:
    Aikar - The order would be the same, just basically when a hopper takes action, it waits 8 ticks to do another round, and that would be increased (likely to 16, I think its 20 atm on SMP1).

    I asked Aikar to clarify this but he has not posted again other than to update his original post and say that he is aware that his original idea could break Sorters. I am pretty sure that what the statement above means is that he is considering making it so that a Hopper will check for items above it half as often as it currently does before pulling them into its slots.

    So far most of the discussion here has been about whether moving stacks internally is a good idea rather than how those items get there in the first place. Not pulling items into a Hopper fast enough can break a Sorter as easily as shuffling items around internally. I was at a mob farm that has a sorter last Friday night and it was not working right. Items I wanted to save were bypassing my sorter Hopper and getting thrown into the trash can. If the duty cycle of Hoppers are reduced to half as fast as they are now I can only expect this problem to get worse.

    This may or may not have been caused by the Spigot update Aikar mentioned yesterday. If it was and unless Aikar rolled it back or made some other patch, everyone's Sorters may already be somewhat broken. Also, I don't use Lava in any of my mob farms just for this reason, but anyone using that kill method may be losing a lot of drops right now.

    Although I fear changing the duty cycle on Hoppers could break things, I think it is something Aikar may have to do if he can't figure out a way to make Hoppers work smarter through code or if we simply are using too many Hoppers. I expect(hope) there is some halfway setting where things will still work and/or where we can make adjustments to our machines.

    I trust that whatever Aikar does, he will try to be fair to as many of us as possible while still keeping things running well. Hopefully we can get a chance to try out any changes and see what they do before they are made permanent.
    cddm95ace likes this.
  12. I am a redstone user, and from this perspective this can mess up alot of redstone machines including a few of mine
    cowland123 likes this.
  13. i like the idea but i have a redstone contraption relying on a hopper timer...
    cowland123 likes this.
  14. Guys a fix for both auto furnaces and auto sorters is by forcing it to only insert 1 item in at a time. To do this, all you need is a dropper to put in items 1 by 1
  15. But droppers require a redstone signal to send the item, which would be difficult in really compact sorters.
  16. You only need 1 dropper at the beginning of the sorter.
    jkjkjk182 likes this.
  17. I don't know much about sorters, but this sound like a good idea.
  18. i just rolled out some fixes, speed and stack sizes are untouched. Will see how things go from here.

    That specific number is all hoppers, even inactive. the - just is a seperator for the text as all TE's are prefixed TileEntity -.

    But however, Empire's ItemMove event using 30% means 30% of the 50% is from actual moving items...

    I've switched our events to be more effecient and it should be better now.

    going to try to not mess with the timings

    s o far looking ok but not as many players on
    http://aikar.co/timings.php?url=6090755
  19. Oh, thats actually really clever. I still prefer some sort of on-an-off switch for these things though.
  20. I am all for a stack at a time. I thought that's what they were going to do when first put in, I was all excited when I made my smelter only to realize that I would have to either A.) Afk for hours on my res having to wait on it all to smelt as well. or B.) It take days to smelt the whole DC I gathered or I smelt it a little at a time over several days because it was "slow as molasses in January" as my grandma liked to say.
Thread Status:
Not open for further replies.