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.