Add "Connect To Logistic Network" To Requester Chests

[CheeseMcBurger]

TL;DR

Requester chests should be connectable to the logistics network in the same way inserters are, enabling the requests on certain conditions.

What?

Inserters can be connected to the logistics network, allowing for conditions that are based on the amount of items within the logistic network. That is, the amount of items in all chests, except requester chests. Requester chests would greatly benefit from this functionality as well by setting up conditions on which the requester chest is active and enabling the configured logistic requests.

Why?

This could be especially useful in large bot networks e.g., on Fulgora.

At the moment, you can achieve a similar functionality with a combination of a logistics-connected inserter and a chest, and setting up a condition on which the inserter takes items out of the chest. However, that leaves the problem that the chest is still taking items out of the logistics network, even if the inserter would be disabled by the control behaviour. Especially with expensive items that should be prioritised elsewhere, I would prefer that they would not be requested into the chest in the first place. If a requester chest could be connected, I could say: Request X amount of item Y only if there are more than Z available in the network.

As items in requester chests do not add to logistic network item count, such a functionality could be added easily without causing any request recursion or loops.

[AileTheAlien]

You can already wire requester chests to circuits, to change their requests. That's what you want, right? You can see here, I've set this chest to request asteroid chunks, from a constant combinator.

[CheeseMcBurger]

I am talking about the connection to the logistics network, not the connection to the circuit network.

https://www.reddit.com/media?url=https% ... c77b020735

[IanLee1521]

I agree this would be useful to have for sure. Probably buffer chests too, while we're at it.

A good use case is for overflows. E.g. if I want to activate a requestor "sink" when a count in a network gets over a certain value. This can be done with circuit networks, but then you have to connect to a roboport to get the contents of the logistics networks.

[neoChaos12]

+1 Was just about to make a post on this myself. I wanted to use this functionality to setup logistic network based quality upscalers that don't send lower quality items to the trash unless an overflow on a minimum storage threshold is met. I can still do this by connecting a nearby roboport to the circuit network, but it seems like such an unnecessary step considering literally everything but the logistic storage entities can directly access the logistic network.

[tappi]

I'd really enjoy this feature as well. One useful usecase for this would be disabling Gleba requester chests so they don't cause unnecessary pull for materials which will spoil in the chest. It's obviously possible to do this by reading the logistics content from a roboport but you'd either need roboports everywhere or a giant circuit network on all the chests. Assemblers and inserters get this functionality for free while the logistics driven / themed chests don't? It doesn't make sense.

[Tesse11ation]

You can run a wire from the nearest roboport to your chest and set the roboport to "read logistic network contents" to achieve the same effect.

I could see a niche case though where you want to enable/disable via circuit network, and also enable/disable via logi network and have separate conditions. But even then you can just use a decider combinator. You can even use a second combinator to isolate for the signal you want (itemyouwant > 0, output itemyouwant input count).

That being said, I'm not opposed to this suggestion.

[tappi]

You can run a wire from the nearest roboport to your chest and set the roboport to "read logistic network contents" to achieve the same effect.

The same argument applies to all "Connect To Logistic Network" entities, you could do the same thing with a roboport connection and a circuit but it's much nicer to have the option to just connect to the logistic network without any additional fuss. Thematically how does it make sense an inserter is more capable of connecting to the logistic network than a (circuit board powered) chest that is inherently a part of it?

[Muche]

The issue is consistency.
Should requester chests be controlled by logistic network contents, a consistent thing would be to allow similar behaviour for other logistic chests.
Now you could have a passive provider/storage/active provider/buffer chest that is set to be a part of the network when the amount of items it carries falls below a threshold, a tick later the amount it higher, so it's set to not be a part of the network.
So you've got an infinite loop of a chest + contents flickering.
Sure, the similar could happen with circuit controlled chest as well, but there you have options of implementing latches, etc.

[vinnief]

Allowing connection to the logistics network obviates the need for a wire to a roboport. This is a superior solution, because it lets you make a self-contained functional unit. Currently if you make a blueprint for a small machine you may have to put in the description "remember to connect a red wire to a roboport with read contents turned on." It is much nicer to allow the connection without the wire.