Consistent Constants

[wallE]

For the sake of simplicity and consistency i'd like to suggest the (possible) usage of a logistic network where ever the user can fill in a number (aka constant).

Example: Requester chest
Here you can request up to 10 different items with different counts you can fill in by hand. These numbers are not by any means known to your logic network.
To make things consistent we should use the same game mechanisms and guis as we do for inserters and let the target count come from your logic network OR fill in by hand like now.
A requester chest would use an input signal ( matched for the stuff it is requesting) as target count and outputs it's content like as it does now.

This way you could make calculations more easily: You KNOW what all kinds of chests and the like will WANT and you can compare this how much they HAVE.

And this solution will make the game more consistent: Any constant COULD be set in a constant combinator.

BTW:
A Smart Requester Chest would request only things the logic network will tell it to request. I feel sorry for the poor robots working for a requester chest changing it's needs every tick.

[ssilk]

Instead of this I would prefer, that the circuit network can change the requests in the request chests.

It's like in programming languages: Either something is constant (like now) or it can be changed at any time and for that case it shouldn't matter, if it is changed by some kind of user-defaults or some function, which calculates such defaults.

[wallE]

Sticking to your programming language: The way it's now, it's like having a constant defined, but the only way to know it's value is to look into the source code because you can't use it as value elsewhere as it's an undefined symbol outside it's scope / chest.

[daniel34]

Instead of this I would prefer, that the circuit network can change the requests in the request chests.

It's already implemented. Click on a requester chest that's connected to a circuit network and set the Mode of operation to Set requests. The chest will set its request slots to the items and amounts set by the signals (up to 10 items).

A requester chest would use an input signal ( matched for the stuff it is requesting) as target count and outputs it's content like as it does now.

Currently it's not possible to do both at the same time, setting the request slots and reading the contents of the chest.