Adapting generic circuit signals to a standard format (not even sure if this is possible)

[kiwi]

For context:
I have a series of train stations, reading train IDs into unique signals (unique per station). This is then fed into a 1hz clock which compares the incoming signals with a list of 30 known signals, then outputs a single "clock" signal matching that train ID. So essentially:
-- Input to the clock would be signals [1: 123, 3:512, 7:99] (signal:value)
-- and a constant combinator with the signals [0-9, A-T] in sequence [1-30] (0=1, 1=2, .., T=30)
-- Output of the clock over the 30 ticks would be: [-, 123, -, 512, -, -, -, 99, -...] (signal C)
I then use these clock signals to get a list of item filters from a list of constant combinators containing the items and the train ID.

So this system does work, but I'm looking for neat solutions to speed it up.
My main two ideas currently are
1. we could adapt the incoming signals to a different format and increase the clock speed to match the highest signal. So the input in the example above would be [0:123, 1:512, 2:99] instead. The clock could then be 10hz and just check each signal up to [2]
the challenge: how do we generically turn any given signal into the "next one available"?

2. or we could adapt the signals the clock could check so instead of being a fixed list where 7 always =8, could be 7=3. Then we could speed the clock up and just have it check those signals.
the challenge: how do we get the clock to know what signal to check next?

Apologies if this is confusing, first forum post so not too sure on all the etiquette or what exact information I need yet. Been really trying to get my head around this for a while but couldn't think of a working solution so maybe we'll get some good ideas from here? Other posts have helped in the past.
)

[astroshak]

I’m not following what you are doing here. Train comes in, ID gets read, and what are you trying to do, exactly? Not “what are you doing with circuitry” but “what are you trying to use circuitry to accomplish “?

[Tertius]

Could you describe the overall purpose of the whole setup on a high level? Without even mentioning the circuit network? You explained your implementation, however I'm not sure what it is all about as a whole.

From what you wrote, I guess you want this:
You have a series of train stations and a number of trains. Whenever a train stops at some station, you want to look up a list of items to load into (or to unload from) the train. There is a central dictionary that defines which train should get which items.

The dictionary is a bunch of constant combinators, each combinator dedicated for one train, where one signal contains a train id and the rest is the signals for the items to send for that train id.
---
As implementation for this, you send train id's from each station to a central location. To keep the id's distinct, every station uses a different virtual signal to transmit the train id. You use the 1..9A..T signals. These are 30 signals.

In the central location, you have a counter that counts from 1..30 that corresponds to these 30 station signals. In a constant combinator, you store the tick (1..30) for each of the 1..9A..T signals the logic is supposed to process the given station signal. If the tick matches for some signal, the train id from that signal is looked up in the dictionary, and the associated content is sent out to the station (supposed to be used as filter for the train).

For this to work it's required to save and store the filter values at the station in a memory cell (you didn't mention that), because it will be gone the next tick.

That's what I got from your description.
---
How to speed up? To skip signals where no train id is currently being transmitted seems not possible. The only way I see is you need to get rid of the counter that visits each signal. You can create 30 duplicated lookup circuits that process each of the 30 signals in parallel.

As alternative, you can use a bitmap for the stations. You want to process 30 stations, so instead of assigning 30 distinct signals, you can assign one bit for each station and handle stations in the same signal. Bit 0 = value 1, bit 1=value 2, bit 2=value 4 and so on. Use bit shift and AND operations to iterate over the stations. This way all station signals are collapsed into one signal, which enables us to process each station at the same time and not in 30 distinct ticks.
However, you need to send the train id over a different signal (the same signal for every station to make it unified), and must ensure no 2 stations transmit their train id at the same time. I don't know if this concept opens faster processing. It's more generic, because it doesn't use distinct signals for each station, however it's not clear if an implementation can be more simple than the current solution.

[kiwi]

Thanks for the replies )
Tertius you are 100% correct in that implementation, there's no memory cell because I'm not advanced enough to know how to make them yet (kinda wanna work it out tho). So yeah, we only have one tick of signals per station so it does end up kinda slow.

Bit masks sounds like a good idea, tried to get it to work first time I set it up but I'll try your suggestions too.

At a high level, the idea is to have a sorta "hub" station where trains deposit all their items into a very large set of storage chests, then the factories connected to them via the train network can send trains there and get the ingredients they need. So you might have a train hand in iron / copper plates, then the train going to the circuit factory can get those delivered via requester chests and filters sent out along the circuit network.

[Tertius]

Since you will have a somewhat arbitrary number of trains in an advanced factory, I don't feel it's a good idea to configure each train by using its train id. If you add a new train, you have to manually get its train id, then add a new constant combinator + configuration for it. Seems somewhat tedious.

A memory cell tailored to your needs is somewhat big, you need 3 or 4 combinators per cell, i. e. per station. That's in addition to other combinators that are required to actually control what is filled into or extracted from the station chests.

It seems you want to use multi purpose train stations to fill and unfill the storage chests of your hub station. The chests to directly supply the trains probably handled by robots, not by inserters.

An interesting and innovative idea. How it is feasible depends on the size and scale of your factory as a whole. The common factory has fixed item flows: mines get ore, ore goes to smelter, smelted material goes go to assembling machines. That's usually always the same, so you can directly feed the smelters from the mines, and directly feed the assembling machines from the smelters, without the need to have a global storage in between. Usually, the buffers of the corresponding loading and unloading stations are sufficient as buffer, additionally to the trains themselves. Usually, players use more trains than required, and multiple trains are buffered in stackers in front of their unloading station. The latency between demand and delivery is very low this way. If you need the next train full of ore, the next full ore train already waiting is released from the stacker and drives to the unloading station just a few tiles away.

Your concept is probably good for a factory that uses small amounts from a huge number of different material, more material than the vanilla game has. Instead of using trains for buffering, you use storage chests. The price is one additional loading+unloading step. This additional step increases the train traffic (just mentioning this, because train congestion is mean).

In my opinion, such a hub system is complex too do with the basic combinators of the vanilla game. May be you could look into the several mods that aid with flexible train logistics. These could greatly simplify dynamically loaded trains.

[kiwi]

Thanks again for the replies ))
Really the purpose of this was to see if I could, more than to improve a factory. It was my first experiment using more complex circuit logic so I was more interested in the logic side of things than the efficiency
Maybe on my next world I'll add more circuit things )

[Tertius]

How about designing a supply train station for building outposts and supplying outposts with ammo and replacement items for destroyed walls/turrets. It's an interesting challenge to design a loading station that will load 10-20 different materials to each waggon, configured with constant combinators. And a corresponding unloading station that will request and unload material according to a different constant combinator setup, so the outpost can build itself with bots as soon as the basic unload circuit itself is built from your portable roboport+player inventory.

This is something I did and it was a very satisfying experience.

In the end, I'm able to place a blueprint over a resource patch, connect it with belt ghosts to a blueprinted train station. From my inventory, only the tracks, station, and circuits are actually built. The vast amount of belts, inserters, miners, walls and turrets stay ghosts. As soon as my own bots finish the station core from my portable roboport, my supply train comes in and fills the chests with belts, inservers, miners, walls and turrets, as well as construction bots, and the rest of the outpost will be built from that without me present.

Or do something different, something totally useless: in case you have multiple rocket silos in operation, design a circuit that synchronizes the silos, so they launch the rockets always simultaneously, or always one after another, or with some other pattern. I have a goal for the far future: I will build 12 rocket silos arranged in a circle which will start their rockets like the hands in a clock.