Requester Chest / Circuit Network Interactions

[rwx]

Suppose I am connecting two logistics zones with a requester/inserter/provider chain. If I want a certain (or possibly calculated) number of an item to be in the provider, the best way (because it supports multiple item types) is to multiply the contents of the provider by -1 and adding that to the request amount.

Problem: Even if you include the inserter contents (hold mode), there is a one tick delay in which the item is removed but the subtraction isn't updated yet. A single extra request will be made each time the target amount is reached.

Proposal: A different "set request" mode where a one-tick-pulse adds a logistics request, regardless of the number of items in the requester chest. It would not be affected by item removal by the inserter.

Problem: When requests are picked up, but not yet delivered, they "disappear" from the logistic network storage statistics. This makes it very hard to implement certain kinds of balancing without oscillation.

Proposal: An option to credit to-be-delivered (and to-be-picked-up) items when reading the statistics. Although it makes more sense to do this on the requester chest, you can't both set the request and read the contents at the same time, and I don't have a good proposal to work around that.

Problem: Suppose I have a variable number of these chains (eg. imagine the direction being controlled by a circuit network), and I want to split the requests across all the enabled chests. I now need to divide the request amount by the number of enabled chests for that specific item type. This is hard with the available circuit elements.

Proposal: An ALU circuit network node. It would have two inputs (that is, 2x red and 2x green inputs total) and one output, and could compute MIN, MAX, PRODUCT, QUOTIENT. Basically an element-wise vector operation node.

[DaveMcW]

Problem: Even if you include the inserter contents (hold mode), there is a one tick delay in which the item is removed but the subtraction isn't updated yet. A single extra request will be made each time the target amount is reached.

Solution: Use red and green wires on the inserter (hold mode). Both wires connect to the *-1 combinator, but the green one passes through an extra combinator first. This provides the extra 1 tick delay you need.

[rwx]

Solution: Use red and green wires on the inserter (hold mode). Both wires connect to the *-1 combinator, but the green one passes through an extra combinator first. This provides the extra 1 tick delay you need.

There is no Factorio circuit that can solve this problem, because what is needed is a zero-tick latency. The fundamental problem is that the request is already active when the item is removed, and the request will be dispatched immediately once the inserter picks an item up out of the chest. The closest you can get is to guess what the inserter will pick up and deduct that from the request in advance, and restore the requests again once you know for sure.

The problem is similar with the second (I do realize that how the logistic networks computes values has been discussed before, but I think the problem is large enough to bring up repeatedly). There is no precise way to use circuits to distinguish a robot pickup from a player pickup from a provider chest. You can at best guess based on the number of active robots at the time the inventory changes.

The good news is that I believe the third problem can be solved with just a mod, so it's the least important in this list.

I'd be happy if logistic networks just exposed detailed request/pickup/fulfillment data via the Lua API, then I could implement everything as a mod. One-tick-pulse logistic requests would still be a big improvement in precision though, even with all the data available.

[Yoyobuae]

One-tick-pulse logistic requests would still be a big improvement in precision though, even with all the data available.

One tick pulsing a 100k request into a logistic requester chest results in one bot delivering to that chest (if logistic bot is available, that is).

Pulsing it every 6 ticks results in almost a blue belt throughput (assuming bot capacity of 4), but not quite. Pulsing every 5 ticks will result in a blue belt but requester chest will start to fill faster than blue belt can take away. This remains true regardless of the delivery path length (until the capacity of requester chest is filled by in-flight requests, that is).

So the bot throughput is proportional to the pulse rate on the requester chest. Only need a control system which can dynamically adjust the request pulse rate according to some desired target.

[rwx]

One tick pulsing a 100k request into a logistic requester chest results in one bot delivering to that chest (if logistic bot is available, that is).

I really like this approach, it's actually a relatively clean solution to the requester chest request size problem in general. Are there any situations in which more than one worker could be dispatched?

[Yoyobuae]

One tick pulsing a 100k request into a logistic requester chest results in one bot delivering to that chest (if logistic bot is available, that is).

I really like this approach, it's actually a relatively clean solution to the requester chest request size problem in general. Are there any situations in which more than one worker could be dispatched?

I think the only danger is a worker NOT being dispatched. In my tests to get more than one worker dispatched per tick required multiple chests (one worker dispatched per chest per tick). I have only tested in lab conditions though.

[rwx]

I was able to reproduce your result (exactly one dispatch per tick, even with many requesters/providers/roboports), but as it turns out there is a flaw: with this technique, requests are no longer balanced between requester chests. It's possible to build circuitry to rotate which chest is making requests, but I think it's too cumbersome in practice for me