Circuit network dualism

[leadraven]

Hello, factorians.

Recently I intuitively tried to do the following : sent content of Requester Chest into red network, do some math, set request filter to this Chest from green network. It took me a few seconds to realize why chest allows me to choose only 1 network behavior.
My question is : why entities cannot behave differently in 2 connected networks? Is there some fundamental problem?

Thanks.

[mrvn]

And why is that? (chest allows me to choose only 1 network behavior)

It would be perfectly fine for the chest to publish it's content and read network signals. Even with just one colored wire. Look at train stops for an example. Ignoring the signals you add to the circuit network yourself isn't that hard for an entity.

[leadraven]

Ignoring the signals you add to the circuit network yourself isn't that hard for an entity.

I believe it's actually very hard in terms of circuit network implementation. And counterintuitive.
But choose different behaviors in different networks - why not?

[astroshak]

The color of wire is just there for player distinction. It has no bearing upon the circuit network.

Connecting two wires to an entity has that entity sharing all signals across both wires. It does not matter if they are two red wires, two green wires, or one red and one green.

I am not sure it is possible, but I’d suggest combining the two networks. Have a Roboport output logistic contents to the circuit network. Have that go through the usual Constant Combinator showing what you want, but then go through a Decider Combinator taking each signal and multiplying it by -1. Send that output to a requestor Chest OUTSIDE the logistics network by a square or two. Have an Inserter move the requested stuffs to an Active Provider just inside the logistics network.

The only real use case I can think of for this would be to request something from a different logistics network.
If you are trying to set things up within the same logistics network ... just use a Buffer Chest and set it by hand? I don’t know.

[leadraven]

The color of wire is just there for player distinction. It has no bearing upon the circuit network.

Connecting two wires to an entity has that entity sharing all signals across both wires. It does not matter if they are two red wires, two green wires, or one red and one green.

It's incorrect. Each network has ID, and network is a set of connected wires of the same color. Two red wires will connect with each other into single network, but red and green will not. Red and green networks are not mixed when connected to the same entity. Entity mixes signals from both networks locally, and that behavior is really counterintuitive and, I think, should be optional (default).

EDIT. Actually, summing signals from two networks is something that shoud be done in combinator. I don't know why all entities do this.

[mrvn]

Ignoring the signals you add to the circuit network yourself isn't that hard for an entity.

I believe it's actually very hard in terms of circuit network implementation. And counterintuitive.
But choose different behaviors in different networks - why not?

It's `signals on network - my own signals`. That's really trivial for the entity. Might be hard or confusing for you because a connected power pole will show different signals than the request chest uses as requests. But trivial for the entity.

[mrvn]

The color of wire is just there for player distinction. It has no bearing upon the circuit network.

Connecting two wires to an entity has that entity sharing all signals across both wires. It does not matter if they are two red wires, two green wires, or one red and one green.

It's incorrect. Each network has ID, and network is a set of connected wires of the same color. Two red wires will connect with each other into single network, but red and green will not. Red and green networks are not mixed when connected to the same entity. Entity mixes signals from both networks locally, and that behavior is really counterintuitive and, I think, should be optional (default).

EDIT. Actually, summing signals from two networks is something that shoud be done in combinator. I don't know why all entities do this.

The LUA interface can see the separate red and green signals as do power poles. Using them added is a choice. I guess in most cases it is what you want and, despite us asking for it, there is no "each green" and "each red" virtual signal that could be used to add red and green wires.

[SLB]

If you want a stream like this

item from red to blue:
Red box >>> Green box (buffer) >>> Blue box

The Green box "Set requests" and "Read contents" at same time are very useful

I don't know why it can't do this but I have an alternative

Red box >>> Green box(Read the signal from the red box circuit) >> Inserter >> Green box (Send inventory signal to downstream blue box) >>> Blue box

[Nemo4809]

Hello, factorians.

Recently I intuitively tried to do the following : sent content of Requester Chest into red network, do some math, set request filter to this Chest from green network. It took me a few seconds to realize why chest allows me to choose only 1 network behavior.
My question is : why entities cannot behave differently in 2 connected networks? Is there some fundamental problem?

Thanks.

It's indeed quite a strange limitation. It's possible to have Requester Chests have both behaviors simultaneously - just include the chest content in the total. Will need a more sophisticated UI for the request amount though. (edit: On second thought, the complexity probably isn't worth it.)

The color of wire is just there for player distinction. It has no bearing upon the circuit network.

Connecting two wires to an entity has that entity sharing all signals across both wires. It does not matter if they are two red wires, two green wires, or one red and one green.

It's incorrect. Each network has ID, and network is a set of connected wires of the same color. Two red wires will connect with each other into single network, but red and green will not. Red and green networks are not mixed when connected to the same entity. Entity mixes signals from both networks locally, and that behavior is really counterintuitive and, I think, should be optional (default).

EDIT. Actually, summing signals from two networks is something that shoud be done in combinator. I don't know why all entities do this.

Well ... how else should they reconcile 2 signals from 2 different networks? e.g. Red says 10 copper ore and green says 5 copper ore. So what's the value of copper ore at the entity connected to both networks?

[Xeorm]

Hello, factorians.

Recently I intuitively tried to do the following : sent content of Requester Chest into red network, do some math, set request filter to this Chest from green network. It took me a few seconds to realize why chest allows me to choose only 1 network behavior.
My question is : why entities cannot behave differently in 2 connected networks? Is there some fundamental problem?

Thanks.

My guess is that order would matter, and that might lead to annoyances with how the system works. Seems smart to me to keep edge cases minimal. Easier in this case for the player to use two different chests. Might also be just general design where keeping things a little limited promotes more problems solving. Might also not have thought of adding it.

[mrvn]

Hello, factorians.

Recently I intuitively tried to do the following : sent content of Requester Chest into red network, do some math, set request filter to this Chest from green network. It took me a few seconds to realize why chest allows me to choose only 1 network behavior.
My question is : why entities cannot behave differently in 2 connected networks? Is there some fundamental problem?

Thanks.

It's indeed quite a strange limitation. It's possible to have Requester Chests have both behaviors simultaneously - just include the chest content in the total. Will need a more sophisticated UI for the request amount though. (edit: On second thought, the complexity probably isn't worth it.)

The color of wire is just there for player distinction. It has no bearing upon the circuit network.

Connecting two wires to an entity has that entity sharing all signals across both wires. It does not matter if they are two red wires, two green wires, or one red and one green.

It's incorrect. Each network has ID, and network is a set of connected wires of the same color. Two red wires will connect with each other into single network, but red and green will not. Red and green networks are not mixed when connected to the same entity. Entity mixes signals from both networks locally, and that behavior is really counterintuitive and, I think, should be optional (default).

EDIT. Actually, summing signals from two networks is something that shoud be done in combinator. I don't know why all entities do this.

Well ... how else should they reconcile 2 signals from 2 different networks? e.g. Red says 10 copper ore and green says 5 copper ore. So what's the value of copper ore at the entity connected to both networks?

IF the game handled the wire colors separately then the GUI would say: Set Filter: [ ] No, [ ] from red, [ ] from green, [ ] sum of both.

But normal entities simply summing up both wires is usually fine. What hinders is that combinators have no way to NOT do this.

As for "Will need a more sophisticated UI for the request amount though": That's not needed. If a chest has both set request and report content then set request simply has to subtract it's own content from the total. For example you connect a constant combinator (10 iron plate) with a green wire to the chest. And a red wire to a LED (enable: iron plate > 10). Then the chest would request 10 iron plate. The green wire would have 10 + amount present and the red wire would have amount present. Works out just fine.

[Nemo4809]

IF the game handled the wire colors separately then the GUI would say: Set Filter: [ ] No, [ ] from red, [ ] from green, [ ] sum of both.

But normal entities simply summing up both wires is usually fine. What hinders is that combinators have no way to NOT do this.

As for "Will need a more sophisticated UI for the request amount though": That's not needed. If a chest has both set request and report content then set request simply has to subtract it's own content from the total. For example you connect a constant combinator (10 iron plate) with a green wire to the chest. And a red wire to a LED (enable: iron plate > 10). Then the chest would request 10 iron plate. The green wire would have 10 + amount present and the red wire would have amount present. Works out just fine.

Having entities not be colorblind would fix it but it would increase the complexity of the UI though - think of it as a newcomer, the “which network switch” would make circuit networks even scarier; most players are avoiding the circuit network if possible already (although the clutter it causes and having to check settings of each entity involved one by one probably plays a big part).

As for the more complex UI comment, I was thinking of having combinator like input/output for requester chest but that would mean its impossible to request more than one type of item without adding a expandable list to the requester chest circuit UI.