Buffer chest + Storage chest filter
Posted: Thu Jul 02, 2026 12:07 pm
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
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