Factorio Forums

1: What did you do: Attempted to use the read logistics requests condition on a roboport to set agricultural farms to only work when a buffer chest with a request for their output exists on the network. Then reproduced in a simple setting with simply inserters and chests (and bots of course).
2: What happened: The roboport request circuit condition output is consistently incorrect. With a low amount of provider chests (of any kind) the request condition is considered complete before it is - IE, if you had one buffer chest requesting 2000 jellynut and one active provider being filled with jellynut with the inserter being activated while the request exists on the logistic network, the inserter would be consistently getting disabled before the request condition is completed. You can also observe the actual circuit network itself to see that the request on the circuit network goes down faster than it should. Meanwhile, with too many chests, it would instead stop too late - at somewhere around 40 chests, my tests began to have the inserters only getting shut off after an extra hundred or so had been moved. The logistic request itself still worked fine, however it was being incorrectly reported by the roboport to the circuit network
3: What did you expect to happen instead: I would've expected the logistics request being reported by the roboport onto the circuit network to only be considered complete when it is actually complete.
4: Reproducible 100% of the time. Although I did originally discover this in a modded file, I have tested it in vanilla and it occurs the same way - after 1k jelly has been moved it shuts off. This only occurs with buffer chests, leading me to believe the issue is caused by the roboport read logisitics network requests to be incorrectly subtracting items in a buffer chest actively requesting an item from that very same request - which is to say, I think maybe the circuit condition being ouput is considering the items in a requester chest as being a valid option for fulfilling logsitics requests no matter what the origin on that request is - this doesn't impact the actual request, as placing down a chest with more jellynut in it or simply filling the provider chest manually will have the bots fullfill the request.
Steps to reproduce:
Place down a provider chest of any kind, feed it from an infinite chest via inserter.
Place down a roboport. Connect the roboport to the inserter with the "Read logistic network requests" condition
Set the inserter to only be enabled when the signal for the item you are requesting is greater than 0 (for my tests, I used Jellynut, but I believe in any item that stacks to at least 50 should work)
Place down buffer chest, request any sufficiently large amount of an item (potentially this could occur at small amounts too but I'm not certain. For my tests, I requested 2k. I also did another test where I requested 1000 - similar results, although instead of a perfect 500 I ended up with 530 or something like that)
Watch either the circuit network itself through a power pole or the resultant amount of items in the chest once the bots are done. The result will be (for 2k) perfectly half of the request amount (for 1k it was not but it was near enough).
Log I don't think a save file is needed for this but can provide one if requested

To put it more simply, the roboport "Reads logistic network requests" as seen on the pole. Should be 900, is 800. If the items are in the passive provider the value is correct. If the items are in the buffer and the request is on a requester chest the value is correct as well.

I see. I don't have a solution for this that won't be terrible for performance. Buffer chests completely screw this logic because they both want and provide items and from the logistics side of it. They both are unsatisfied but also can provide items to other requester chests.

The logistic network does not make this distinction in its count of "item available in providers" - it just sees a total number and says "this many are available for requesters".

It really feels like this feature of reading "unsatisfied requests" was not thought out with buffer chests in mind (because it clearly wasn't).

My unsolicited 2 cents: Buffer chests should not count towards the logistic network contents, anyway. Because their contents are unreachable by default requester chests or themselves, that is, if you are using the logistic network to set requests of chests you are usually counting on the items on the network being requestable by whatever you're setting the requests to. This means that if you use buffer chests anywhere in your network you must use requesters with the option ticked for any circuit-controlled chests, since otherwise they might request items that they have no way of getting.

Rseding91 wrote: Thu May 22, 2025 3:15 pm I see. I don't have a solution for this that won't be terrible for performance. Buffer chests completely screw this logic because they both want and provide items and from the logistics side of it. They both are unsatisfied but also can provide items to other requester chests.

The logistic network does not make this distinction in its count of "item available in providers" - it just sees a total number and says "this many are available for requesters".

It really feels like this feature of reading "unsatisfied requests" was not thought out with buffer chests in mind (because it clearly wasn't).

I think this should be a regression bug instead of an old design problem, as my base relying on this stopped working after updating the game to 2.0.55.

After bisecting the versions, the issue appeared firstly in 2.0.48 (maybe related to some logistic request fixes?). And of course, I think this regression should be fixed.

Screenshots from 2.0.47 (correct) and 2.0.48 (incorrect)

According to the patch notes this was fixed in 2.0.56. I have updated to 2.0.58 and I am still getting issues with requests from Buffer Chests.

If I have 2 buffer chests requesting the same item ( eg first chest requests 10 red belts and second chest request 50 red belts) then put 10 belts into the first chest and 25 belts into the second chest. The system thinks it can take the 10 belts from the first chest to fill up the second chest. This results in the "Read Logistics Network Requests" saying that it needs 15 red belts but actually it needs 25.
If I then remove 1 belt from the first chest so that it has 9 belts instead of 10 and its request if not fulfilled. The "Read Logistics Network Requests" updates as it does not think it can use the belts in the first chest to fill the second chest and becomes the expected value of 26.
This is the blueprint I was using for testing.

Tranzalore describes a very specific bug with a simple fix. The bug is that buffer chests whose requests are fulfilled are dropped from the list of active requests, which then lets their contents count toward fulfilling other requests, even though the buffer chest request can only remain fulfilled if those items are not removed.

The solution to this behavior, at least, is simple: buffer chest requests should always count as "active" even when they are fulfilled. There are still some edge cases of inaccessible items, but this change will make the unfulfilled request number mostly accurate and predictable enough to be usedul.

Tranzalore wrote: Tue Jun 24, 2025 2:58 am According to the patch notes this was fixed in 2.0.56. I have updated to 2.0.58 and I am still getting issues with requests from Buffer Chests.

I already have a setup that should show if there is still an issue but does not, so I placed your bp and inserted the items and it shows 25 requests in the first and 26 in the second case.

Are both of you sure you can produce this in 2.0.58? If yes post a simple save please.

My apologies, I wrote my post without testing it myself.

I tested Tranzalore' blueprint in 2.0.55 first and observed the original very strange behavior. I then loaded the save in 2.0.58 and observed it operating correctly as Loewchen said. I don't know how to reproduce what Tranzalore put in their most recent post.