Factorio Forums

i wanted to set on a requester chest the request by circuit network and read at the same time the content of the chest. could not find any workable setup with just one chest or an open suggestion topic to this. basically the suggestion are tick boxes and not radio buttons for the mode of operation (i understand a "mode of operation" and some limitations for some entities even i don't get the point when you use tick boxes vs radio buttons, but i think a chest should always be "readble")
in the screen shot my robots are still delivering because I can't "net" the chests content with the request

so why or what i'm trying to do: i'm playing around with "just in time" delivery from a central train warehouse where my robots are operating. on the "delivery" train stations i have placed requester chest filled by demand out of my factory/outposts and the robots are bravely filling the chests. if there is no train or the train is full and just not departing, the items in the chest are not netted with the requested amount from the "request" network. so this leads to an overdelivery which i can't accept in my "just in time" and minimal storage base to reduce my warehouse value only setup i could figure out is with 2 chests, one receiving based on circuit request, an inserter inbetween moving items to the next chest where i really read the content (can be a normal chest then). of course workable but not nice at all (ok, complained on really high level and perhaps my fault because i don't see the "solution" ).

would really love to see a better setup for my chests or the possibilty to read contents and set requests on 1 single chest if this is technically possible. in each case, great work from the whole DEV-Team that absorbs on a lot of evenings after work my time in optimizing logistics

EDIT: i have to correct slightly, so the mentioned work around is not really possible. as soon the target chest is clogging up and the demand is still high enough, the problem starts again. so i think the only real workaround is then with deciders and combinators but then a "simple" task of a Requster Chest becomes kind of overdesigned

I don't think this would work even if they weren't radio buttons: both numbers are positive, so you'd just end up *adding* the contents of the chest to what you were requesting, causing it to request things forever.

ah right, have not tought about that, thanks. if it should work, it must have something like a "Reader Input side" and a "set Input side" and this kind of not fits in the current "style". so this should go into a mod i think in this case

by the way i just experimented around in the last hours while running the whole system and the error quote on over delivery is quite small even on a low tech level reagrding robo speed and so on. and if you limit on top the requester chest just to one slot the maximal error count is still very small compared to the total over due amount so the whole need of it gets kind of obsolete besides the smaller layout but this is ok with me and not worth the effort for this sole use of it.

so i guess this can be moved by an admin to "wierd mod ideas" or so or closed

I want to second this request.

I noticed that in 0.15, it is possible to both configure a filter inserter and read its hand contents at the same time. As long as you use separate wire colors, it works reliably. I take this as a sign that the devs are okay with this kind of feature!

(A component also knows its own contribution to a total, so it should be possible to work reliably over one color as well.)

I believe this feature would be a better solution than my previous attempt to solve my automatic delivery system via feature requests, on the grounds that it's simpler and easier to understand.

It works for filter inserters because the two things are taken into consideration at different points in time: the filter is only relevant when the hand is empty and it's deciding whether to pick up an item, so the "read hand contents" data doesn't interfere with the filter setting. It's not that the game is doing something special to make this work; it's not taking its own contribution into account.

This isn't the case for a requester, unfortunately.

That would be a case for separating red and green wire. But that is so unlikely to all the other wire-behavior...

I think this needs a completely different solution than yet.

How about a "Set request of X to signal Y"? Then you can request green's value of copper - allowing a disconnect from the read and write?