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 have to say, I really appreciate that Aikar listened to the players and tried to find a compromise for everybody instead of relying on the poll. I hope this works out!
    Pab10S likes this.
  2. Well "Listening to the players" would be more so to go with the poll lol, But we will always try to give options to keep things working where possible.

    Were still going with the poll "eventually" but itll be able to opt-out of it.

    This will not be done with res flags, but renaming the block could be an option.
    Maybe "Single Move Hopper" will activate it.
    _Stads_, jkjkjk182 and ob1bob69 like this.
  3. Are the current hoppers vanilla or not?
  4. Yes. Should still be vanilla. I undid timing changes, and all I did was push out the performance improvements.
    cadgamer101 likes this.
  5. Well Aikar, I'm not sure what you did, but my head farm is fixed, for now at least :)
  6. Until we break it... we'll try even harder, to drop more heads :) ( j/k )
  7. Well, you don't have to try harder, you get plenty :p
    NoahMarcusWhite likes this.
  8. So since moving 64 at a time would break sorters, couldn't changing it to 8 or 16 per tick still improve overall server performance while not break sorter and clocks completely? Clocks would be easy since you would just multiply the number of items by 8 or 16 to get the same duration. For sorters it would just require a different distribution of items in the filter hopper and the hopper would act as an accumulator. Would suck for sorts of a small number of items. My guess tough is that people using sorters aren't sorting small quantities of items.
  9. Sorry to bump this, but is this now definitely going to be implemented, and if so, when?
  10. the full stack is intended to be implemented "some time in the future, but not any time soon", but it will be able to be disabled.

    The timings wont happen unless something drastic comes up.
    cadgamer101 likes this.
  11. So basically, it will come out right after the dragon tombs.
  12. Besides item 'sorters', the behavior of a hopper, in a sort system can be applied for many other purposes as well, having a hopper dump an entire stack per tick would destroy every opportunity for any system that depends on a hopper sort function. As someone that uses a lot of redstone to optimize mundane tasks, this type of hopper modification would be destructive at best. I am wondering how the vanilla hopper function compares to buildcraft pipes. Before hoppers, a diamond pipe in buildcraft was great for sorting items. Obviously since buildcraft is not supported on EMC, it doesn't seem relevant to discuss the difference between vanilla hoppers and pipes, but what if there is some code in the diamond pipe sort mechanism that could be applied toward vanilla minecraft hopper behavior to reduce lag? One major difference is you don't see the item being moved, so it's simply a matter of bytes being shifted.

    What about taking some of the server side 'processing' and sliding it over to client side processing, (this may be outside of possibility, I concede I don't know a lot about how minecraft 'works') Instead of all processing happening server side, slide some of it to the client or clients that have loaded that area, and let the client side handle more of the processing than the server (where possible).

    I know that unless I am present on my res, my item sorter does not sort. but it works rather quickly when I'm there.

    An alternative would be to have a new 'hopper interface' mod installed server side, where the hopper exhibits basic vanilla behavior, unless interacted in such a way to tell it to move stacks at a time. I see that there was a suggestion in place to use tokens, and to use those tokens to modify the behavior TO vanilla, but what about using tokens to modify it to NOT vanilla behavior. I can certainly see applications where moving a stack at a time through a hopper would greatly expedite things, but I would want that to be a selectable behavior, and I wouldn't mind spending tokens to get that behavior, even if it was a 10-15 token charge for each hopper modified. (It would also be beneficial if you could tint expedited hoppers red to indicate as such, to give you a visual clue that you spent tokens to modify that hopper.)

    You've already got a harry potter trick with a stick, so maybe right clicking a hopper with a stick will pop open an interface in chat that would allow you to spend a few tokens to modify that specific hopper. I would also suggest that any hopper modified this way is completely immune to redstone signals.

    Just my 2 cents as a heavy redstone user.
  13. you guys just bumped an almost two year-old thread
    ElfinPineapple0 likes this.
  14. I am fairly certain this would break my item elevator.


    It uses the comparator to see when there are items in the hopper feeding into the dispenser, so while there are it fires it. If it transfers a whole stack at once, it would empty the hopper while the bottom dispenser would remain full with items, therefore breaking it.

    I may be wrong, didn't put a ton of thought into it.

    EDIT: Oh dang! I didn't realize that someone had bumped a 2-year old thread. I thought this was fresh hahaha
  15. Well, I like the idea, just would hurt item sorters but you said you would find a way to fix it, so a +1 from me.
  16. Although still 'relevant', I am closing the thread as this thread has served its purpose.
    607, cadgamer101 and AwesomeBuilder33 like this.
Thread Status:
Not open for further replies.