I recently wanted to make a multiple item system, where items with the same category (e.g. food, wood, etc.) would be sorted into the same chest. It bothered me, that I needed to make a lot of single item filters and combine them which costs a lot of iron, wood and time.
I now experimented a bit and came up with a 4x5 design, that filters up to 11 items into the same chest. It is basically a single item filter, where the checked item changes constantly. I explained the concept and how to build it in this video:
Probably needs a non-stackable filter upstream of the input chest [by eyeball, I've not built a testing rig] unless the input chest is manually loaded or otherwise guaranteed free of such.
Can 64-stack & 16-stack items be sorted in the same sorter cell?
Ignoring the issues with the rinse system (likely solvable – particularly if small losses/missorts of output are acceptable):
♦ this system will be slower than a standard sorter as the desired items circulate [N items means a 1/N chance of allowing an item from the input chest to pass on any given sort test.]
♦ the comparator clock adds lag [This issue may be mitigated if an output is taken from the input chest to automatically turn off the clock whenever this chest is empty.]
In combination the above would seem to place this device in the interesting but special purpose catagory. [I am unable to think of a circumstance in which I would use it; YMMV as compactness is something I have found to be subordinate to speed and lag-friendliness.]
Once again, the thought that went into the design is commendable, I simply don't see an application…
[At root this sorts an incoming item stream of stackables into Keep and Pass.
The system would seem to be best for an input stream with small quantities of a large number of [i]different[/i] Keep stackables and no large amount of Pass stackables.
Typically, one either extracts what one wants and disposes of the rest – or {my preference} removes the unwanted product for disposal (eg. cod from a guardian farm), sorts the desired product, and sends any residue to a 'junk' chest(s) for manual sorting.
Probably needs a non-stackable filter upstream of the input chest
I don't see, why this would be necessary. Non-stackable items just won't be sorted and will be collected as "junk" in the input hopper, where the rinsing mechanism will take over.
Can the system be extended to work with an imbedded 'Overflow protected' item sorter?
Do you mean, that one could add multiple (overflow protected) filter hoppers in the same design unit to maximise the filter rate? If so, then I don't think this would contribute to better filtering, since the input hopper has to be directly connected to the filter hopper. If you have multiple filters, you also need multiple hoppers, which would only spread out the available items and would not contribute to faster or more effective filtering (maybe just a little bit, but at the expense of, again, way more material and space).
Can 64-stack & 16-stack items be sorted in the same sorter cell?
Only if you do not mix them. The basic funcionality is like the 1-item filter design, so if you want to filter 16-stackable items, you just have to adjust the amount of filter blocks in the filter hopper. So you can only filter 16-stack OR 64-stack items with the same cell.
this system will be slower than a standard sorter as the desired items circulate [N items means a 1/N chance of allowing an item from the input chest to pass on any given sort test.]
That is true, however, this filter also filters items in a changing way. So, the possibility of sorting the same item 5 times after each possible cycle is (1/N)^5, but successfully sorting 5 items out of potentially 5 different items available (which this sorter can do) after 5 cycles has a probability of (5/N)^5, which is significantly larger. (Also see the "further thoughts" section below)
[At root this sorts an incoming item stream of stackables into Keep and Pass.
The system would seem to be best for an input stream with small quantities of a large number of different Keep stackables and no large amount of Pass stackables. [...] The main benefit of the MAP system is that several desired items can be sent into the same chest with minimal infrastructure: something to which Tango Tek's Minecraft Tutorial: Automated Storage System with Multi-Item Sorting Pub22Jun15 offers an alternative.]
I completely agree. I personally did this because the 1-item filters needs way more resources and the pre-assigned chest solution from Tango Tek needs a lot more height (or additional redstone contraptions to put the chests in a horizontal way). I also didn't like to idea of only pulling out 63 items instead of a full stack of items you need.
Further thoughts on this:
I also experimented with the possibility of connecting the clock with the inverted signal of the filter-circuit. This way, whenever and item is being filtered, it stops the clock and pulls out all the items of this type available in the input hopper at once. This is a lot faster when you have large quantities of the same type of item in the input, however, I couldn't get it to work properly in the first builds, since multiple items somehow came through and were collected in the dropper. Maybe this can be implemented in this version of the sorter, because I changed a lot of small details and also introduced the block on top of the input hopper which blocks it at the right time to ensure that it only tries to input an item when the filter is ready.
I could try to get this to work again since it would speed up the filter process by a lot!
A minor concern is the amount of time before the input hopper becomes clogged with non-Keep items (which would include non-stackables) as the design as depicted does not have a fully reliable auto 'rinse' feature.
My first concern is that if a non-stackable does get into the filter hopper it would break the system. Without building and testing, my thought is that this could occur as the Keep item in the filter hopper was changing. This concern is based on the idea that hoppers push before they pull and the orientation of the device might trigger directional or positional RS wonkiness.
Given the amount of time you've spent running/testing these rigs, it might well turn out to be a non-issue.
Overflow protection:
This can be ignored — my concern was based on what would happen to adjacent plys [which it does not appear can be added where they would be affected]. The 'logic' behind that concern is spoilered:
As shown, the device relies on the signal strength of the comparator that reads the filter hopper changing between 2 (hopper underneath locked) and 3 (unlocked).
If, however, the output chest is 'full' (totally or simply unable to store more of a particular item) additional examples of that item can build up in the filter chest raising the comparator output to 3 (1s +4i ) which can break things.
Time/space/resources concerns:
I think we write this down as differing styles: by the time I start building sorters, my major concerns are sorting speed and lag, thus different players leads to differing solutions.
Further thoughts section:
I, too, thought about stopping the item circulation clock to pull all of Item-A from the input at once, but couldn't see a clear way to achieve this.
As the clock serves only to cycle the Keep items through the filter hopper, changing the clock design might assist in this.
(I still think stopping the clock when the sorter is not sorting would be a good idea, but – at present – the input hopper is not likely to provide a convenient trigger by being empty at the end of sorting. This would make any auto-shutoff for the clock dependent on a reliable way of 'rinsing' the input hopper. )
I don't use Tango Tek's system myself (mainly because of lag issues), but neither do I tend to use large sorting systems in general.
I would be interested in seeing the actual application in game that led to your designing this… assuming it was not the result of a thought experiment.
[I suspect I don't properly understand what problem the device is intended to address.]
Looking at the basic mechanism of circulation items through the filter hopper, it occurs to me that this produces a random time delay before the item is sorted; this may have applications beyond sorters as I know of no convenient way to do this for user defined times at present.
Rollback Post to RevisionRollBack
"Why does everything have to be so stoopid?" Harvey Pekar (from American Splendor)
WARNING: I have an extemely "grindy" playstyle; YMMV — if this doesn't seem fun to you, mine what you can from it & bin the rest.
I recently wanted to make a multiple item system, where items with the same category (e.g. food, wood, etc.) would be sorted into the same chest. It bothered me, that I needed to make a lot of single item filters and combine them which costs a lot of iron, wood and time.
I now experimented a bit and came up with a 4x5 design, that filters up to 11 items into the same chest. It is basically a single item filter, where the checked item changes constantly. I explained the concept and how to build it in this video:
Kudos on the design work :>:
Probably needs a non-stackable filter upstream of the input chest [by eyeball, I've not built a testing rig] unless the input chest is manually loaded or otherwise guaranteed free of such.
Can 64-stack & 16-stack items be sorted in the same sorter cell?
Can the system be extended to work with an imbedded 'Overflow protected' item sorter? qv. https://minecraft.fandom.com/wiki/Tutorials/Hopper#Overflow_protection
Ignoring the issues with the rinse system (likely solvable – particularly if small losses/missorts of output are acceptable):
♦ this system will be slower than a standard sorter as the desired items circulate [N items means a 1/N chance of allowing an item from the input chest to pass on any given sort test.]
♦ the comparator clock adds lag [This issue may be mitigated if an output is taken from the input chest to automatically turn off the clock whenever this chest is empty.]
In combination the above would seem to place this device in the interesting but special purpose catagory. [I am unable to think of a circumstance in which I would use it; YMMV as compactness is something I have found to be subordinate to speed and lag-friendliness.]
Once again, the thought that went into the design is commendable, I simply don't see an application…
[At root this sorts an incoming item stream of stackables into Keep and Pass.
The system would seem to be best for an input stream with small quantities of a large number of [i]different[/i] Keep stackables and no large amount of Pass stackables.
Typically, one either extracts what one wants and disposes of the rest – or {my preference} removes the unwanted product for disposal (eg. cod from a guardian farm), sorts the desired product, and sends any residue to a 'junk' chest(s) for manual sorting.
The main benefit of the MAP system is that several desired items can be sent into the same chest with minimal infrastructure: something to which Tango Tek's Minecraft Tutorial: Automated Storage System with Multi-Item Sorting Pub22Jun15 offers an alternative.]
First of all, thank you for your comment on this.
I don't see, why this would be necessary. Non-stackable items just won't be sorted and will be collected as "junk" in the input hopper, where the rinsing mechanism will take over.
Do you mean, that one could add multiple (overflow protected) filter hoppers in the same design unit to maximise the filter rate? If so, then I don't think this would contribute to better filtering, since the input hopper has to be directly connected to the filter hopper. If you have multiple filters, you also need multiple hoppers, which would only spread out the available items and would not contribute to faster or more effective filtering (maybe just a little bit, but at the expense of, again, way more material and space).
Only if you do not mix them. The basic funcionality is like the 1-item filter design, so if you want to filter 16-stackable items, you just have to adjust the amount of filter blocks in the filter hopper. So you can only filter 16-stack OR 64-stack items with the same cell.
That is true, however, this filter also filters items in a changing way. So, the possibility of sorting the same item 5 times after each possible cycle is (1/N)^5, but successfully sorting 5 items out of potentially 5 different items available (which this sorter can do) after 5 cycles has a probability of (5/N)^5, which is significantly larger. (Also see the "further thoughts" section below)
I completely agree. I personally did this because the 1-item filters needs way more resources and the pre-assigned chest solution from Tango Tek needs a lot more height (or additional redstone contraptions to put the chests in a horizontal way). I also didn't like to idea of only pulling out 63 items instead of a full stack of items you need.
Further thoughts on this:
I also experimented with the possibility of connecting the clock with the inverted signal of the filter-circuit. This way, whenever and item is being filtered, it stops the clock and pulls out all the items of this type available in the input hopper at once. This is a lot faster when you have large quantities of the same type of item in the input, however, I couldn't get it to work properly in the first builds, since multiple items somehow came through and were collected in the dropper. Maybe this can be implemented in this version of the sorter, because I changed a lot of small details and also introduced the block on top of the input hopper which blocks it at the right time to ensure that it only tries to input an item when the filter is ready.
I could try to get this to work again since it would speed up the filter process by a lot!
Non-stackable pre filter:
A minor concern is the amount of time before the input hopper becomes clogged with non-Keep items (which would include non-stackables) as the design as depicted does not have a fully reliable auto 'rinse' feature.
My first concern is that if a non-stackable does get into the filter hopper it would break the system. Without building and testing, my thought is that this could occur as the Keep item in the filter hopper was changing. This concern is based on the idea that hoppers push before they pull and the orientation of the device might trigger directional or positional RS wonkiness.
Given the amount of time you've spent running/testing these rigs, it might well turn out to be a non-issue.
Overflow protection:
This can be ignored — my concern was based on what would happen to adjacent plys [which it does not appear can be added where they would be affected]. The 'logic' behind that concern is spoilered:
As shown, the device relies on the signal strength of the comparator that reads the filter hopper changing between 2 (hopper underneath locked) and 3 (unlocked).
If, however, the output chest is 'full' (totally or simply unable to store more of a particular item) additional examples of that item can build up in the filter chest raising the comparator output to 3 (1s +4i ) which can break things.
Time/space/resources concerns:
I think we write this down as differing styles: by the time I start building sorters, my major concerns are sorting speed and lag, thus different players leads to differing solutions.
Further thoughts section:
I, too, thought about stopping the item circulation clock to pull all of Item-A from the input at once, but couldn't see a clear way to achieve this.
As the clock serves only to cycle the Keep items through the filter hopper, changing the clock design might assist in this.
(I still think stopping the clock when the sorter is not sorting would be a good idea, but – at present – the input hopper is not likely to provide a convenient trigger by being empty at the end of sorting. This would make any auto-shutoff for the clock dependent on a reliable way of 'rinsing' the input hopper. )
I don't use Tango Tek's system myself (mainly because of lag issues), but neither do I tend to use large sorting systems in general.
I would be interested in seeing the actual application in game that led to your designing this… assuming it was not the result of a thought experiment.
[I suspect I don't properly understand what problem the device is intended to address.]
Looking at the basic mechanism of circulation items through the filter hopper, it occurs to me that this produces a random time delay before the item is sorted; this may have applications beyond sorters as I know of no convenient way to do this for user defined times at present.