Any chance of implementing combination of Network Signal ID? It'd be nice if we can combine network Signal IDs having different bitmask schemes, so that one can easily uncouple different Network Signals by removing a Signal ID instead of having to rework the bitmask scheme for all stations.

Hey Xeraph,

I saw this in the Information tab, and I wonder if this usage meets your needs already:

In addition, if the combinator receives as input a signal of the same Id as its network signal Id, then the value of this signal will be interpreted as a bitmask to give 32 "sub-networks" to choose from. Each station can belong to any set of sub-networks based on its mask. A delivery will only be made between two stations if any two bits match between the two masks, i.e. if mask1 & mask2 > 0.

Thanks for the information, I am aware of the current implementation. What I suggest is the ability to union more than one group of Signal IDs. Say A has a bit mask of 1100 and B has a bit mask of 0001, I was hoping for a way to make a station serve the union of both groups (A's two groups, and B's one group), without having to modify the bitmasks on both groups. That way when I want to uncouple B from the scheme I just need to remove signal B instead of having to modify the bitmasks of both groups (again).

I've thought a bit about something like this, I can't really think of a good UX design for such a system without doing a massive overhaul of the mod to add a gui system for configuring groups of stations. That would be a version 2.0 change if I ever get around to implementing it.
Right now to bridge two separate networks you either have to change each one manually or build a transfer station to move goods between them.

I was thinking of removing the use of item-signal as network signal ID. Currently when a station has selected an item-signal as network ID, it cannot provide and request that item type - seems to work against the principle of a logistic system?

Instead, a station control can interpret any virtual signal supplied to the station control as a union of network signal IDs. while default network ID can be set in the mod settings.

Users will have to careful in supplying extra virtual signals to station control to prevent unwanted behaviours.

So by default I don't want to confuse new users who will often put virtual signals onto their station circuit networks as control signals. Unless they read the docs they would not intuit why their fancy circuited station is broken. However I can make that functionality a non-default option. Currently the cybernetic combinators allow for the "each", "any" and "every" signals to be chosen as network Signal IDs. This was not by my choice but as a result of factorio api spaghetti, and if you choose these nothing will happen. What I can do is now give one of those functionality, where if you choose it, the combinator will then behave exactly as you describe.

Say if I choose "any" for the station control, I can send multiple virtual signals to ask the station to serve the union of the networks? Sounds good to me.

Version 1.2.0 now allows you to set the network of a station and a fuel loader to "each". This allows you to union as many network Ids and network masks together as you want.

hi, thanks for implementing! Looking forward to implementing my space elevator schemes using this new feature - my plan is to have an entirely new network for trains that are allowed to cross the elevator, while maintaining the same scheme for each surface. With that, I just need to union the elevator network to networks of stations that are allowed to cross surface.

hi, I noticed that this doesn't work for depot currently (1.2.1), when I select Each the choose-element-button just empties itself.

Edit: adding or param.operation == MODE_DEPOT in gui.lua makes it work, I think

Edit 2: it only allows me to keep the each symbol in the depot combinator, cybersyn still does not recognise it as a valid multi-network depot

If I add this feature to depots it creates a many-to-many network mapping problem where previously it was just one-to-many. Algorithmically this would be difficult to implement in a way that is efficient. I'll put it back on my todo list, but I can't make any promises it will come until I find an algorithm to solve the many-to-many problem.

Actually I'm silly, the algorithm is absurdly simple. It will be in the next update.

If I add this feature to depots it creates a many-to-many network mapping problem where previously it was just one-to-many. Algorithmically this would be difficult to implement in a way that is efficient. I'll put it back on my todo list, but I can't make any promises it will come until I find an algorithm to solve the many-to-many problem.

Noted, but I wish to continue the discussion, just for the sake of understanding the problem.

I didn't study the algorithm in-depth, forgive me if it sounds naive. Referring to this part, I observed this possibility:

What if a Cybersyn train is allowed to appear more than once in the global.available_trains table under different network_name? What problems can such redundancy lead to? My impression is that the housekeeping code just need to make sure the (multiple) entries of a multi-network train are inserted and removed together in that table.

Edit: Just saw your new reply, took too long to post this XD