Description
When logistic robots reserve their cargo size worth of items, whether the number of reserved items is subtracted from the number of unsatisfied logistic requests (as read via circuit signal from a roboport) depends on the type of chest the reserved items are stored in. For items in storage chests, the value does not change. For any other type of chest, the cargo size is subtracted from the number of unsatisfied requests until the logistic robot picks up the items, at which point the value changes again, subtracting only the number of items that have been actually picked up.This leads to rather unexpected behavior. For example, when requesting two items spread over two separate active provider chests, robot A may reserve 4 items in the first chest, temporarily pseudo-satisfying the entire request, so that when robot B reserves the item from the second active provider chest, it is bound to be delivered to a storage chest first, instead of directly to the requester chest.
Possibly related to viewtopic.php?t=126787
Steps to reproduce
Create requester chest, set it to request 100 iron plates. Create a roboport, put a logistic robot inside. Pause time in map editor [numpad 0]. Put 1 iron plate into any logistic chest that is not a storage chest. Move forward in time tick by tick [numpad .], monitoring logistic network request circuit signals at the roboport. The value changes from 100 (see also bug report linked above) to 96, and then to 99 when the item gets picked up. Repeat for storage chest. It remains at 99 during all three phases. See attached image for illustration.Possible solution
Depends on when you consider a request satisfied. My expectation would be for requests to remain unsatisfied until the requested items have arrived at the requester, and for that to be reflected in the number of unsatisfied requests reported via roboport circuit signals. However, I would be happy if the number of unsatisfied requests would simply not ever go up unless more items are actually being requested, so changing the other chest types to function similarly to the storage chest in that regard would be a quick fix. Ideally, requests, contents, reservations, and in-transit values would be reported separately rather than in aggregate, but that would be more of a feature request than a bug report.- chests2.png (1.04 MiB) Viewed 287 times
