Requester chest driven by constant combinator(s)

[nosports]

It seems that a requester chest which requests were set by constant combinator(s) is limited to the first 30 request of constant combinator(s)
-> albeit this is much, but chaining some combinators together will get one easily over 30 requests.
(To some extend this seems to is also the case for filter-inserters, but for this i had not gotten a grasp on the problem for now; maybe it will be solved when the adjenct requester-combinators will work.)

Solutions :

Expand the possible request-slots for such cases
Or give an overload if set request-number is greater than workable requests (like in alarm light or like 'no path' for trains) on the struggeling inserters or combinators

It took me a while to figure this out because my train delivery station were not working correctly.
I set up the request /delivery with constant combinators wich will fill provider stations and take out the desired items at the requester stations but it would not work in full.

i hope this is enough description, but in case i can provide more informations

[Loewchen]

This is not a bug.

[nosports]

Just to be clear to work around this

so this is a limitation ?

[boskid]

As Loewchen said: this is Not a bug. It is not a limitation, it is part of the mechanic. If entity can have at most 30 requests, providing more requests will cut some of them. Similar behavior happens for stack filter inserter with set filters: if you provide more than 1 signal for a filter, it will choose signals up to the limit. The limit for requester chests will increase a little for the next release but do not expect too much.

[nosports]

thanks a lot....

Its ok thats a limitation or mechanik - i just wanted to point this out.....
I did not know this is a border.

If i know its intended i can think a work around - a more grainy albeit simpler system.....

It was just so nice just chain a additional combinator and everything would work (not)

[mrvn]

What you can do is request only items that are missing. That way when you want 200 iron plates and the chest has 200 iron plates the signal would be dropped and open up a slot for the next item. You would only request 30 items at a time but unless you constantly remove items eventually all items will arrive.

Another workaround is to simply use multiple requester chest, one per 30 items.

[nosports]

its no problem, i now use one combinator with one requester chest, use this combination mutliple times (with max 30 items each) and fill in a filtered train wagon.

On the request station i am not sure, currently it works because the station is filled from earlier, so it needs only request depleted items,but a mass depletion with more as 30 items is to be seen....
But as a newly build station is empty i don't know if it will work, but thats also solveable with one filter-inserter and one combinator for each filter-inserter.

Its somewhat simpler and granier, but will work

[SoShootMe]

This is not a bug.

I think a bit of expansion on that would have been appreciated. As I understand it: the limitation is that a requester chest can only request 30 different items, as you can see when you open the chest.

If requests are set by the circuit network, a requester chest will ignore signals with negative values or for things that cannot be requested (eg fluids or letters). If more than 30 signals remain, an unspecified subset of them will be used. (I think it's the first 30 in a particular order, but the order isn't specified, so best not to rely on it.)

Similar applies to filter inserters (five signals) and stack filter inserters (one signal).

What you can do is request only items that are missing. That way when you want 200 iron plates and the chest has 200 iron plates the signal would be dropped and open up a slot for the next item. You would only request 30 items at a time but unless you constantly remove items eventually all items will arrive.

You can only either set or read requests, not both. A workaround for this is to use inserter(s) to move items from the requester chest to other chest(s), and reduce the requests as items are removed from the chest. You can do this by setting each inserter to read hand and hold, connecting all the inserters and chests to the input of an arithmetic combinator set to "each * -1 -> each", and connecting the output of that combinator and the constant combinators to the requester chest.

Note this can result in slightly more ending up in the chests than requested due to Worker robot cargo size bonus. This can cause a problem if you end up with additional (partial) stacks of items. You can solve this by removing the excess using a couple more combinators and filter inserters set to stack size 1. (At least, I cannot see a better solution that isn't much more complex.)

Another workaround is to simply use multiple requester chest, one per 30 items.

That's a lot simpler, of course .

[mrvn]

Sorry, should have mentioned the workaround for not being able to read content and set filter at the same time.

Which makes the multiple chest option even more appealing, no need to move items.