16.15 Logistic Storage and buffer chests

[Ishimuro]

Not sure if a bug or there's a other way to work this out or i just doing it wrong

Ok, we got buffer chests, so now it is possible to build a kind of outpost to shorten paths for bots.
These chest behave like requesters, but could be used by construction drones or requests the player made (or if you select it, also requester chests).

But how could i work around the fact, the stuff stored at a buffer chest also count towards the logistic network?
My problem: the main base got the output inserter limited within amounts of items at the logistic network connection, so i could be sure to just have e.g. 100 Pumps at the whole network (cause the output inserter just move if the logistic storage drop below). But if i now want to shorten ways and setup a bufferchest supply far out cause i want to expand even further and don't want to wait for resupply for years.
Ok, pumps are limited to 100, 25 of em at storage chests, 75 at passives.
I may say i want 50 pumps in a buffer chest at this outpost. These 50 will be delivered, fine. Now i setup 3 other supply ports with also 50 pumps... the second one will get also 50, but the 3rd and 4th will get nothing, cause the logistic storage still count 100, so the inserter didn't move at the production. Even if i say i now request 50 with requester chest that won't work cause he can't request out of these 2 buffer chest filled with 50 each unless i set the option. But if the network noticed, i request 50 with requester and it can't reach the 100 at buffer chest (cause i didn't set the option) it should get a -50 amount to the network to force the inserter to add another 50 to the network.

The only workaround is to not limit the inserter via logistic network, but rather limit the chest to some slots or use the circuit connection. That lead to unnecessary productionamounts.

Did i miss sth i could setup that buffer chest?

[nuhll]

I would just limit it in the boxes then, or maybe add a "dont count towards logistic network" option in the puffer chest. (but i dont know if thats usefull)

[Rseding91]

Thanks for the report however this isn't a bug.

If you don't want the contents to be counted towards the logistic contents then you can't use buffer chests. That's the entire purpose of them: they request but still provide to the network.

[golfmiketango]

Thanks for the report however this isn't a bug.

If you don't want the contents to be counted towards the logistic contents then you can't use buffer chests. That's the entire purpose of them: they request but still provide to the network.

For the record, I have encountered certain situations involving reading the logistic network contents from roboports into circuit networks where this arrangement "does what I said" but not what I meant. But I admit it's hard to make any technical argument against the idea that those items are in the network. I can think of two. A bad one, and a not-great one:

• The bad one: Since buffer chests take from providers and give to requestors, they should be treated like robots and the items they are "holding" should be treated as "on the way."' This is really a stretch since the items they contain are not in fact reserved yet for any particular destination requestor and the analogy simply doesn't hold up to scrutiny.
• The not great one: Since buffer chests both request and passively provide they should simply perform those roles separately in terms of network statistics. The amount requested should be subtracted from the available amount in the network; then the amount they contain at each given moment should be added back in. I am pretty sure there is a problem with this argument as well, in that, even though it seems like the logistic network works this way, I suspect it's somehow not how it actually works. Otherwise, I believe I would see much larger negative numbers in the logistic network in general; the negative logistic network numbers seem fudged somehow. Perhaps this is undocumented? Or perhaps I'm just confused. Anyhow I haven't taken the time to really understand this, since it just magically does what I mean most of the time. But since I'm not clear about how it really works, it's hard to opine intelligently about it.

Regardless, if buffer chests worked this way, the result would be that huge amounts of resources would "disappear" into buffer chests. This could become its own source of great confusion causing huge unintended overproduction. It kinda seems like a damned if you do but more or less OK if you don't sort of thing. Especially since we can always read the contents of the chest into the circuit network and account for this manually. So, to be clear, I think they way this works now should not be changed (unless, maybe this keeps coming up over and over and it eventually becomes obvious that it would be better. But that will take time to figure out; I'm definitely not convinced).

[Ishimuro]

As this is intended, it feels like a downgrade of logistic handling cause i always thought using the logistic network for limitation is the most advanced one.
But another question, how are requests done now? If i have active and buffer (enabled for requests), what would be used first, if a request is done?
Cause one of the 2 Options i using buffer now is requesting ore next to the smelting if the mines are a bit off of them. Cause it feels like sometimes the smelting requester got delivered from those active provider at the mining (not from the storage chest near them).
(2nd Option is a supply train station at a splitted network).
I hoped for a more handy bufferchest solution but with the already figuered out workarounds it looks like there is not that hugh demand for the current bufferchest without sacrificing my cleaned up logistics
But i really like the storage chest filters, cause that was my intended use for bufferchest (to get dedicated storagelocations).

[Serenity]

The amount requested should be subtracted from the available amount in the network; then the amount they contain at each given moment should be added back in.

That doesn't work for all use cases. For example I use buffer chests for recycling. I sometimes have them as normal output chests and request the maximum amount of materials. Or with with piercing magazines I have them request everything too, but I also have them pull from a belt with an inserter while returning the excess to the belt.

[nuhll]

Its wayne actually, at the point u build robots and buffer chests u have resources on mass, so it really doesnt matter if u produce 50 items more then needed... just only limit the space in the provider chest and you should be fine.

[golfmiketango]

The amount requested should be subtracted from the available amount in the network; then the amount they contain at each given moment should be added back in.

That doesn't work for all use cases. For example I use buffer chests for recycling. I sometimes have them as normal output chests and request the maximum amount of materials. Or with with piercing magazines I have them request everything too, but I also have them pull from a belt with an inserter while returning the excess to the belt.

We're actually in agreement about that; above I'm just playing devil's advocate so I can shoot down my own argument (which I eventually do but probably using too many words )

[smcpeak]

I ran into this problem myself and found a workaround suitable for some situations:

1. Wire all of the buffer chests together to get their combined contents.
2. Put that through an arithmetic combinator set to multiply the "each" (asterisk, "*") signal by -1, and output "each" as well. That gives the negative of the buffer chest total.
3. Wire that signal into wherever you are also reading the logistic network contents, for example from a roboport. The two signals get implicitly summed, so now you have the logistic contents minus whatever is in buffer chests.

If you are currently testing logistic contents directly from the "wireless" signal (of an inserter, for example), you'll have to change to using a wired signal in order to use this technique. Beware: If you wire a signal into an existing inserter that is already connected wirelessly, the inserter will still remember the wireless condition, even though the UI does not show it! You have to explicitly disconnect the wireless signal before connecting the wire.