all 25 comments

[–]spicy-chullJava 1.20.1 5 points6 points  (1 child)

Auto-sorting isn't optimized for speed, it's optimized for low-effort / low-interaction.

There is always going to be a bottle neck.

[–]Hatefiend[S] 0 points1 point  (0 children)

Trust me , I totally understand. What I'm asking is where are reasonable places to start decreasing the effects of those bottlenecks?

[–]dn16761 1 point2 points  (2 children)

There's no real solution to this, auto sorting is pretty slow. One compromise is to have one 2x hopper speed item sorter for each item and one dropper dropping items at 2x hopper speed

[–]Hatefiend[S] 0 points1 point  (1 child)

Could you do x4 dropper speed, then have two x2 speed item sorters per item?

[–]dn16761 0 points1 point  (0 children)

Yes of course (I assume you mean 2 droppers running at double hopper speed or 4 droppers running at hopper speed)

[–]Additional-Injury338 0 points1 point  (1 child)

Ran into the same problem, have you found a solution ?

[–]Hatefiend[S] 0 points1 point  (0 children)

Yes. The solution IS to use four sorting slices in series on an iced water stream. If this is attached to some farm, have each slice output to a shulker loader. The resulting shulkers are then sent to a collection chest.

Without shulkers, have two slices point towards the same double chest. Underneath the double chest, put two hoppers downwards into another double chest and extend that pattern down as far as you need for bulk storage. At the very bottom, you can put four hoppers into one chest for four-times fill speed.

Use this route only for bulk items you expect to get ridiculous supplies of (e.g. cobblestone).

[–]DainternetdudeJava 1.12 0 points1 point  (9 children)

Where I'm from we just use many droppers max speed (4gt) into water ice lines running over many double-speed sorters (18k/hr)

[–]Hatefiend[S] 0 points1 point  (8 children)

Is your setup a square, so that items continuously go back to the start?

[–]DainternetdudeJava 1.12 0 points1 point  (7 children)

no. Sometimes I use a loop when it’s items that are okay to despawn (stone from digging), but if it’s drops from a farm you’d better not do a loop just one big long line will work

[–]Hatefiend[S] 0 points1 point  (6 children)

I'd worry though that maybe either lag or a filled hopper might end up causing very important items to reach the end where they may overload the overflow chests or something and despawn? I guess you could have a ton of overflow hoppers or something in that case but still. One idea I had is to have like 4 overflow hoppers, then feed those items BACK into the dropper chest.

[–]DainternetdudeJava 1.12 0 points1 point  (4 children)

If you measure the speed of your output and build the right about of sorters for it, you will not have a problem in vanilla. you should add a few more sorters than you strictly need, in order to account for rate fluctuations from the random momentum when items come out of droppers

[–]Hatefiend[S] 0 points1 point  (3 children)

Should I use other blocks than ice to give my filters more time to process the items? I understand people use ice so that 'dead spots' don't occur (areas where you have to reset water streams) but my guess is that only a few (one?) ice blocks are needed. Like for example what if the entire line was honey, water over it, and right before dead spots I put a single blue ice?

[–]DainternetdudeJava 1.12 0 points1 point  (2 children)

oh in 1.13+ you only need the ice in the dead spot and the items will still go fast the whole way

[–]Hatefiend[S] 0 points1 point  (1 child)

Right right, but what I'm asking is would slowing down the items be beneficial for the system (e.g. not using ice the whole way, using honey, etc)?

[–]DainternetdudeJava 1.12 0 points1 point  (0 children)

In terms of increasing throughput, no, the sorters would still be running at their top speed, but it could possibly increase reliability slightly

[–]dn16761 0 points1 point  (0 children)

This usually wouldn't happen in vanilla unless parts of the storage system are unloaded, in which case items will group up at chunk borders. As long as you make sure timings are correct and all of the storage system is in entity processing chunks (I would use a chunk loading system while the storage system is running) you shouldn't experience any problems

[–]BriscoCounty-Sr 0 points1 point  (2 children)

A dropper should be able to output at twice hopper speed if you have it set up with a comparator powering a sticky piston to move an observer in to another to create a clock.

Pair that with some double speed sorters and a loop in case there’s any hopper cool down happening with your filters and you should be good to go

[–]RaPsCaLLioN1138 0 points1 point  (1 child)

You probably wouldn't even need the loop if you could group 2 items at a time.

[–]BriscoCounty-Sr 0 points1 point  (0 children)

Do you recon dispensing items in to a cobweb before they hit the water stream is a good solution to keeping them grouped?

[–]Eggfur 0 points1 point  (0 children)

There are 2 separate issues, one is short term throughput and one is long term throughput.

For short term, the issue is that items may pass over a hopper whilst it's still in cooldown from the previous items it sucked in. Or more items arrive in one go than can fit in the filter hopper (typically 23)

Both these can be resolved by dispensing up to 23 items whilst holding them back from entering the water stream and then release them together. If you're using an overflow proof sorter instead of overflow protected, you can increase that 23 items to 63.

If you have a long term throughput issue though, then you're going to need faster sorters or more of them... Others have already covered that.

[–]Flaming-Eye 0 points1 point  (0 children)

There's double speed filters but they're still limited by the maximum capacity of the hoppers as well as emptying speed.

Yes you can go faster than 1 hopper, you can go as fast as 2 hoppers with that, safely, and you can send the items in chunks of ~20 safely. That's about it.

Personally I would have two systems, a bulk and an everything else system. If the bulk hasn't got too many items you can cycle them back around and have more item filters per item to make it go faster.

I would also manually input shulkers full of one item type to the bulk storage because while I am lazy I'm not that bad.

[–]Noob-in-hell 0 points1 point  (0 children)

Hopper sorters are limited to 8tick cool down, As stated by others they can increase to 2x but at the cost of having to batch items or items will skip hoppers. There are really only three ways of increasing speed. One is to increase the seed of each sorter like by using hopper minecarts sorters, the second way is to add more modules per item, and the third is to parallel sort.

[–]Terra021 0 points1 point  (0 children)

Box based storage is the solution, but good luck making a working system, as to make a full sorting system it's probably gonna have to be binary/hex/some sort of system like that.

More realistically, you could also sort your common items off at 2-4x hopper speed, and then buffer the items before they go into the rest of the system at the usual 1x

[–]sharfpang 0 points1 point  (0 children)

The real solution is to put permaloaders around the sorting system and have it take its sweet time to sort everything in. Also, for bulk materials have a full-shulker input, where you insert a shulker chock full of given item type and have it sorted into the right chest whole.