Hello everyone,
I had an idea that could make buffer chests much more flexible by giving them a feature similar to the logistic filter available on storage chests.
The idea is to allow a buffer chest to filter which item requests it accepts, either by manually setting filters or, even better, by allowing circuits to set those filters (similar to how inserters can have their filters controlled by the circuit network).
Example:
Imagine a buffer chest whose logistic requests are driven by circuit signals. If the request contains multiple item types, the chest currently requests all of them unless you build additional combinator logic to separate the signals.
If buffer chests had a logistic filter, you could simply whitelist the items you want the chest to request. This would:
* Reduce the amount of combinator logic needed.
* Save space in circuit designs.
* Make buffer chests much more versatile while still fitting their intended role.
* Allow localized stockpiles that construction bots and logistic bots can both use, without unnecessary item movement.
For example, if I only want a particular item stored in a specific buffer chest, I wouldn't need to rely on trash filters or enable "Trash unrequested", which can be difficult to configure correctly and often causes unnecessary bot traffic.
I think this would position buffer chests nicely between requester and storage chests, making them a more powerful general-purpose logistics tool without replacing the existing chest types.
One possible concern is the circuit interface. Buffer chests already have limited circuit I/O (setting requests and reading contents), so adding a "Set Filter" mode could create interface or wiring conflicts. I haven't worked out the best implementation yet—perhaps manual filters only, or revisiting this feature deeply to see if there's any useful needs to having all I/Os simultaneously (set filter+read contents+set requests), I'm assuming it'll mostly be for example (R)set requests + (G)set logistic filter, without reading. It's also worth considering whether filters should only care about item type or whether signal values should have meaning.
Overall this is kind of cool extension to the current logistic system and I would love to hear your feedback or thoughts about whether this should or not be implemented
Buffer chest + Storage chest filter
Moderator: ickputzdirwech
Re: Buffer chest + Storage chest filter
As an additional example, I think this would be especially useful on Fulgora.
Imagine building your production lines on the larger islands while keeping all recycling on a separate island. A single circuit signal could connect a roboport in the recycling network to request items selected by quality using a selector combinator.
From there, you could have a group of buffer chests dedicated to each production line. Each buffer chest would have filters for only the items that production line needs. My expectation is that one buffer chest with set filter to be holding 1–5 different item types would be enough for many factories. If there are balance or implementation concerns, even limiting each chest to a single filtered item would still solve the problem—you would simply use multiple chests.
The buffer chests would all receive the same quality-request signals from the selector combinator, but each chest would only request the items that match its configured filters. Additional arithmetic and decider combinators could then control when requests are enabled or how many items should be requested.
In addition, you will be able to set the 'read ingredients' from assemblers, and set them to a requester chest, with those buffer chests providing much cleaner approach to holding only the items that they need for production, this also optimizes logistic's bot pathing the way I see it.
This is also why I think the filter should behave similarly to storage chest filters. Ideally, the filter would only care about the item type and ignore the signal value, while the request amount would continue to come from the Set Requests circuit input. If necessary, those could even be separate circuit modes (or separate wire channels) so that filtering and request amounts remain independent.
In addition, I thought about the blacklist/whitelist option for the filter, but as for now it sounds way overpowered. also this kind of makes trash unrequested redundant, but may still be used in cases such as gleba where stuff get spoiled and needs to be out of the system for example.
Imagine building your production lines on the larger islands while keeping all recycling on a separate island. A single circuit signal could connect a roboport in the recycling network to request items selected by quality using a selector combinator.
From there, you could have a group of buffer chests dedicated to each production line. Each buffer chest would have filters for only the items that production line needs. My expectation is that one buffer chest with set filter to be holding 1–5 different item types would be enough for many factories. If there are balance or implementation concerns, even limiting each chest to a single filtered item would still solve the problem—you would simply use multiple chests.
The buffer chests would all receive the same quality-request signals from the selector combinator, but each chest would only request the items that match its configured filters. Additional arithmetic and decider combinators could then control when requests are enabled or how many items should be requested.
In addition, you will be able to set the 'read ingredients' from assemblers, and set them to a requester chest, with those buffer chests providing much cleaner approach to holding only the items that they need for production, this also optimizes logistic's bot pathing the way I see it.
This is also why I think the filter should behave similarly to storage chest filters. Ideally, the filter would only care about the item type and ignore the signal value, while the request amount would continue to come from the Set Requests circuit input. If necessary, those could even be separate circuit modes (or separate wire channels) so that filtering and request amounts remain independent.
In addition, I thought about the blacklist/whitelist option for the filter, but as for now it sounds way overpowered. also this kind of makes trash unrequested redundant, but may still be used in cases such as gleba where stuff get spoiled and needs to be out of the system for example.