Requester Chests: Read Contents & Set Requests at the same time

[Hares]

TL;DR

Allow requester chests to read contents & set requests at the same time, like belts or inserters can.

What?

Suggestion 1, minimal:
Allow requester chests to work in both modes at the same time


Suggestion 2, extended:
Change "Read contents" on all chest-like entities from the radio-box to check-box so it can be disabled

Suggestion 3, wow-solution:
Add "None" mode of operation to all entities (pumps, I see you!) without it, either by turning radio-buttons to checkboxes (like with most entities), or adding "None" radio button (like on inserters).

Why?

Part 1. Requester chests
When requester chests are used in combination with the circuit network, they are often used as one-time requestors. When this is the case, you don't want too many items to be requested, and you want:

1. Unload items from the requester as soon as they appear to remove the bufferization time
2. View the delivered but not yet loaded items count, so you know when to cancel the request
3. Alternatively, if you want the exact items to be loaded, you can wait until the buffer is full, and there's no way this is possible in vanilla

Why do you need to do so?

1. Automated supply trains with no redundant items
2. Space Exploration supply rockets
3. Other delivery requests

Part 2. "None" mode of operation
Well, if you accidentally connect pump to a circuit network, you basically cannot tell it to ignore it (unless setting the "✱ ≠ 0" condition).
And the chests & storage tanks are unconditionally putting their contents to the network.

From what I know, these are the only entities in the game which can't be set to ignore the connected network.

[Illiander42]

This has been requested over a hundred times before, and someone always has to explain why it would lead to infinite requests.

Think for a moment about a requestor chest that is requesting its own contents, plus 1 belt, and how many belts would end up in it.

You can do all the things you want this for by wiring a stack inserter and a steel chest next to the requestor.

[FuryoftheStars]

it would lead to infinite requests.

Think for a moment about a requestor chest that is requesting its own contents, plus 1 belt, and how many belts would end up in it.

Hmm, shouldn't this only end up with a full chest? I mean, once it's full, the feedback loop can't continue/get worse (a signal of current contents is no different than a constant combinator).

I think the real issue here might be separating the request signal from the set contents signal. Chests only have 1 hookup point, and a signal on a wire has neither an identifier of the entity that created it nor a "direction" on a wire, so a requester chest outputting its contents would immediately see this as a set request signal, too, even if that wasn't desired.

The only way to separate them would be to have separate in & out hookup points like combinators, however, the sides that they are on would be fixed as chests do not support direction and thus cannot be rotated, which the devs are appearing very weary about doing.

[Hares]

This has been requested over a hundred times before, and someone always has to explain why it would lead to infinite requests.

I searched for the similar questions before asking.
Found none, but search over Factorio Forums isn't quite a thing providing accurate search results.

Think for a moment about a requestor chest that is requesting its own contents, plus 1 belt, and how many belts would end up in it.
You can do all the things you want this for by wiring a stack inserter and a steel chest next to the requestor.

I have thought about that. That's why you should use different wires for that, like you do with inserters.
The thing you can't do currently is to request 500 belts and get a notification when these 500 belts are delivered.

[Hares]

I think the real issue here might be separating the request signal from the set contents signal. Chests only have 1 hookup point, and a signal on a wire has neither an identifier of the entity that created it nor a "direction" on a wire, so a requester chest outputting its contents would immediately see this as a set request signal, too, even if that wasn't desired.

You hook up isolated green wire with the request signal.
Then you hook up red wire to isolating combinator (one which does nothing to the signal), and it's your contents output.

[Illiander42]

Yes, this stops being an infinite request if the set and request are on different wire colours.

But as long as we can't do that, this would cause a chest full of items if you set the request to one of that item. They would just arrive one at a time.

[FuryoftheStars]

I think the real issue here might be separating the request signal from the set contents signal. Chests only have 1 hookup point, and a signal on a wire has neither an identifier of the entity that created it nor a "direction" on a wire, so a requester chest outputting its contents would immediately see this as a set request signal, too, even if that wasn't desired.

You hook up isolated green wire with the request signal.
Then you hook up red wire to isolating combinator (one which does nothing to the signal), and it's your contents output.

That's not what I was talking about.

[Tertius]

I think the real issue here might be separating the request signal from the set contents signal. Chests only have 1 hookup point, and a signal on a wire has neither an identifier of the entity that created it nor a "direction" on a wire, so a requester chest outputting its contents would immediately see this as a set request signal, too, even if that wasn't desired.

You hook up isolated green wire with the request signal.
Then you hook up red wire to isolating combinator (one which does nothing to the signal), and it's your contents output.

This doesn't prevent direct feedback. If the chest contains 10 copper and the chest is set to read content, you will observe 10 copper at its circuit connection. If you connect both red and green, these 10 copper will appear on red and on green. You can observe this with regular chests.
If you were able to read content and set filter at the same time, these 10 copper are read back as requests, because they are on the wire. If you connect both red as well as green, you will even read 20 and set the filter to 20 copper. Just on its own, without extra signal from outside.

This direct feedback can be observed with the electric mining drill. Put one down over some tiny resource that contains < 500 ore, for example 123. Should be < 500, so numbers are not shortened to 1k, 2k, and precision lost.
Connect a red and a green wire from the miner to some power pole not yet part of the circuit network and set the miner to read resources as well as to activate/deactivate. You will see 123 on the red wire and 123 on the green wire. Now set an activation condition in the miner: ore > 150. You will see the miner will be activated and running, although it's just reading its own data, and although it has even less than 150 ore. It's activated nonetheless, because it's reading red+green = 123+123=246, which is > 150.

[FuryoftheStars]

I think the real issue here might be separating the request signal from the set contents signal. Chests only have 1 hookup point, and a signal on a wire has neither an identifier of the entity that created it nor a "direction" on a wire, so a requester chest outputting its contents would immediately see this as a set request signal, too, even if that wasn't desired.

You hook up isolated green wire with the request signal.
Then you hook up red wire to isolating combinator (one which does nothing to the signal), and it's your contents output.

This doesn't prevent direct feedback. If the chest contains 10 copper and the chest is set to read content, you will observe 10 copper at its circuit connection. If you connect both red and green, these 10 copper will appear on red and on green. You can observe this with regular chests.
If you were able to read content and set filter at the same time, these 10 copper are read back as requests, because they are on the wire. If you connect both red as well as green, you will even read 20 and set the filter to 20 copper. Just on its own, without extra signal from outside.

This direct feedback can be observed with the electric mining drill. Put one down over some tiny resource that contains < 500 ore, for example 123. Should be < 500, so numbers are not shortened to 1k, 2k, and precision lost.
Connect a red and a green wire from the miner to some power pole not yet part of the circuit network and set the miner to read resources as well as to activate/deactivate. You will see 123 on the red wire and 123 on the green wire. Now set an activation condition in the miner: ore > 150. You will see the miner will be activated and running, although it's just reading its own data, and although it has even less than 150 ore. It's activated nonetheless, because it's reading red+green = 123+123=246, which is > 150.

This is what I was talking about. ^^

[Hares]

Okay, you're right.
I was sure machines are ignoring signals they provide, but they actually do not.

However, with 2.0 and its wire-specific operations this could be possible.

[Tertius]

As far as I remember the past fff, it's just the decider combinator that will have a wire selector for input and output. I don't remember any fff screenshot from other devices with that functionality. Not even the new selector combinator.

[Hares]

As far as I remember the past fff, it's just the decider combinator that will have a wire selector for input and output. I don't remember any fff screenshot from other devices with that functionality. Not even the new selector combinator.

Even though I can't argue that, there were too many requests in the same discussion topic to extend the mentioned functionality.

[Mck6]

I'll be resurrecting this.

As far as I can see, this should be a solved problem. Assemblers can already have both reading contents and setting recipes on at the same time, along with 3 extra read operations, and none of the read operations change the assembler recipe.

assembler.jpg (215.66 KiB) Viewed 1418 times

Just attach the same logic that disregards self-produced signals of assemblers to chests. You could also just subtract the 'read contents' signal from the overall signal when both 'read contents' and 'set requests' are turned on on the 'set requests' method (so it wouldn't affect the overall signal).

If it's impossible, for whatever reason, to do any of the above, you could instead re-work signals slightly. Logistic networks already separate requests and contents. Why not separate requests and contents entirely, have all negative values be treated as requests and all positive values as contents? Requester/buffer chests could have 'set requests' and 'read content' independently (requests = negative, content = positive). Sure, it would require people to change their existing setups by adding an extra arithmetic combinator when requesting (or switching existing ones from positive to negative values), but it would greatly expand the usefulness of chests overall.

I've been trying to make a universal assembler array (1 assembler for each quality, set through a single constant combinator) together with accompanying buffer storage and recycling, but the more I try the harder I find it to be. Setting the storage chest filter through signals is impossible, and while it is possible to set buffer/requester chests through signals, it's impossible to read whether they are full or not at the same time (so it's impossible to turn off production or turn on recycling at certain storage count). I guess I could use the 'read logistic network contents' option on roboports, but that would unnecessarily complicate things (extra step of connecting the logistic network to the assembler blueprint, unreliable if the item is stored anywhere else).

Buffer chests are necessary, because lower quality recipes can produce higher quality products, so I need to syphon them out somehow. Before quality, products could just be stored in a passive provider chest, but doing so now can stop lower quality production if it fills with higher quality products, especially for products you don't need a lot of and limit the output chest to just a couple slots. I didn't miss this functionality before, but with quality it became more important.

[Hares]

BTW, parts 2 & 3 of my suggestion were implemented.

[Henour]

It would be nice if requester chests worked like assemblers in this regard.

[mooklepticon]

+1 for this idea. I went to turn this on, assuming it existed because assemblers have it.

Basically, I have a buffer chest requesting 1 stack and then an inserter turning on if it's >=1 stack. So it'll turn on and feed into a recycler, but maintains a buffer amount. Example: I want 50ish modules. The buffer request is set by a combinator to be 1 stack, 50 modules, and the inserter is set to active if >=1 stack, or 50 modules. The inserter turns on, feeds into the recycler, and then turns off bc the buffer chest has <50 modules. This lets me keep 50ish (or whatever) modules as a buffer and then direct inserts anything above that.

Edit - I solved it by using more combinators. The selector combo is wired to the chest and requests one stack of the item. The inserter is connected to the logistics network via combinators and turns on if there's more than the set point. The chest and the inserter are not connected via wires.

[Hares]

See also: 117481: Please, PLEASE make circuit connection behavior configurable per wire