advanced circuitry: separating signals

[jagholin]

Lets say we have a wire that carries a lot of signals(connected to logistic network for example, but it doesn't really matter). We want to separate the signals to form groups of 4, the last group allowed to be <4. One signal can go to at most 1 group.
How it should look like: one wire input, multiple wires output(1 wire = 1 group).

I have some ideas how to do this, but they all will have to be quite huge. I'm interested to see if this task can be done with few combinators, so I'm looking for any new ideas.

[Fel]

If you wanted to separate them based on conditions it would be easier but there isn't really a way to do what you want without a lot of combinators (one per signal is the best I could come up with).

I'm curious as to what you plan on using that for because I can't come up with a good answer.
If it was much larger groups I could understand linking it to a power pole to read it more easily since the network info goes off the sceen but by groups of 4 I have no clue.

[jagholin]

it's filter inserters, they only have 4 slots for filters

[knighttemplar1960]

Go to the 37:00 mark
https://www.youtube.com/watch?v=AtN3ewXfZHM&t=2157s

[AlexMBrennan]

Decider combinator if anything > 0 then output anything will pass through at most one signal. Multiplying this by -1 allows you to remove the signal from the input so you can repeat this to split N signals on one wire into N separate wires, which you can then recombine to form groups of 4.

Unfortunately that blueprint is going to be big and slow if you want it to be universal (Factorio has a couple hundred signals) but I doubt that this will be necessary (just start loading with the first group of signals instead of waiting to calculate the 423rd group of signals)

[RiO]

The sheer number of layers of combinators you would need to make this work in a way that it can be sanely automated, would mean the actual result of the computation would lag behind by more game ticks than an inserter swing.

I.e. if you were planning on using this to distribute 'up to X of each item' into a certain amount of containers, then I'm sorry to say: you will find that your idea is intractable to solve with combinators. You will never get it to work right, because the timing will always be off and too much of an item will always randomly slip through.

If this is the scenario you are attempting to solve, then I would urge you to investigate an alternative instead. For instance: distribute items into inventory slots according to reserved item slots, by going through a railway wagon as an intermediary. Railway wagons can be configured with reserved slots just like the player inventory can: by using middle-mouse click over an empty slot to pick an item, or by middle mouse click with an item in hand to dedicate the slot to that item type (and drop what you have in hand into it).

You could wire up a simple SR/RS latch which enables inbound inserters and disables outbound inserters when the wagon reaches the fully empty state; and vice versa when it reaches the fully filled state.

That way you're guaranteed you'll always get one exact wagon load of items passed on in-ratio. And if you don't need all the slots; block some of them off with an arbitary non-item like a deconstruction planner.

Also: train wagons can, afaik, be part of blue prints - but I'm not sure if it also stores their reserved inventory slots. You may have to set those individually, which would still kind of suck -- but it's better than nothing.

[bluemonkey]

My current procedure for controlling filter inserters fed from a roboport. Works for my purposes, might not for yours:

Step one: Put only the contents of the roboport onto a separate network as a negative number:
Roboport -> Decider [each >0; output each] -> Arithmetic [each * -1; output each] ->Red wire

Step two: A different constant combinator for each filter inserter. The constant combinator has 4 items I want it to handle input with amounts I want it to move attach to filter inserter with green wire. Filter inserter will run in "Set filters" mode.

Summary: Red wire runs to every filter inserter tells you what's there (when to stop). Green wire just connects the inserter to its combinator and tells it what to move (when to go).

[Leeux]

Originally posted by RiO:

<snip>

Also: train wagons can, afaik, be part of blue prints - but I'm not sure if it also stores their reserved inventory slots. You may have to set those individually, which would still kind of suck -- but it's better than nothing.

Yes! They can and the filtered/masked slots are saved too and reconstructed when you stamp the plugin... I know this because I have a new outpost expansion blueprint that also includes the service train for it and all its slots are reserved for specific items, and when I built it in my game, the train came back with all its inventory already filtered (thankfully!)

[RiO]

Originally posted by Leeux:

Originally posted by RiO:

<snip>

Also: train wagons can, afaik, be part of blue prints - but I'm not sure if it also stores their reserved inventory slots. You may have to set those individually, which would still kind of suck -- but it's better than nothing.

Yes! They can and the filtered/masked slots are saved too and reconstructed when you stamp the plugin...

Nice! I wasn't certain, because I never actually tried it myself.
So it's good to have some confirmation. :)

[RiO]

Originally posted by bluemonkey:

My current procedure for controlling filter inserters fed from a roboport. Works for my purposes, might not for yours:

Step one: Put only the contents of the roboport onto a separate network as a negative number:
Roboport -> Decider [each >0; output each] -> Arithmetic [each * -1; output each] ->Red wire

Step two: A different constant combinator for each filter inserter. The constant combinator has 4 items I want it to handle input with amounts I want it to move attach to filter inserter with green wire. Filter inserter will run in "Set filters" mode.

Summary: Red wire runs to every filter inserter tells you what's there (when to stop). Green wire just connects the inserter to its combinator and tells it what to move (when to go).

This could work. But it has two issues.

Firstly, it only works for a set-up where each filter inserter handles a single, fixed, dedicated set of 4 items and no more (though potentially less). Secondly: inserter stack size.
If the application of the filter inserters requires a truly exact count (e.g. stock exactly X of item A into a chest; train wagon; Space Exploration cargo rocket; etc. so that it doesn't eat into the required space Y for item B) then you'll need to limit stack size or the inserter can and will 'over-fetch' and mess it up. That means either forcing stack size to 1 - which makes everything suuu---per slow; or trying to use circuitry to compute the max allowed stack size.

Getting the max allowed size for the exact item the inserter will pick up is impossible. So, what you have to actually do is either put the four items on a timer and iterate through the 4 items one by one in a continuous loop, where only one is set to the filter to allow pick up and you've set the proper stack size for it; or you need some other metric. E.g. set the filter (and stack size) for the item that still needs the highest amount transferred. This requires implementing a min/max function in combinators, which is also not trivial.

All in all, as soon as you need count-exact transfers that fit into storage together, your best option really is to redirect through a limited item inventory like a train wagon.
And if that's not your use-case, then you're going to probably have to accept (and be able to handle!) randomly over-fetched items.

[AlexMBrennan]

This requires implementing a min/max function in combinators, which is also not trivial.

Is that really necessary? What do you hope to gain by filling the largest/smallest request first compared to filling the requests in random order?

[knighttemplar1960]

Originally posted by RiO:

If the application of the filter inserters requires a truly exact count (e.g. stock exactly X of item A into a chest; train wagon; Space Exploration cargo rocket; etc. so that it doesn't eat into the required space Y for item B) then you'll need to limit stack size or the inserter can and will 'over-fetch' and mess it up. That means either forcing stack size to 1 - which makes everything suuu---per slow; or trying to use circuitry to compute the max allowed stack size.

You can work around it by using a common factor of the stack sizes of all 4 items that it might pass through. As an example if the possible stack sizes are 50(bots), 100(repair packs), and 200(ammo) you can set the inserter hand size to 2, 5, or 10 and it won't over fetch.

Originally posted by RiO:

So, what you have to actually do is either put the four items on a timer and iterate through the 4 items one by one in a continuous loop

and you don't have to do this either. You can use the sort order that the game uses (its the same one that reorders the contents of your inventory when you add something that isn't currently in there.)

The person that made the video that I linked is quite clever and he addresses all of these things in that video.

Its definitely worth the time it takes to watch it if you want to make use of combinator quirks. Its all ready saved me a few steps and headaches.

[RiO]

Originally posted by AlexMBrennan:

This requires implementing a min/max function in combinators, which is also not trivial.

Is that really necessary? What do you hope to gain by filling the largest/smallest request first compared to filling the requests in random order?

Keeping the allowed stack size as high as possible for as long as possible. If you can get the filters to be set to the item with the greatest amount remaining, then you can derive the stack size from that item as well.

Originally posted by knighttemplar1960:

You can work around it by using a common factor of the stack sizes of all 4 items that it might pass through. As an example if the possible stack sizes are 50(bots), 100(repair packs), and 200(ammo) you can set the inserter hand size to 2, 5, or 10 and it won't over fetch.

No; it'll definitely still over-fetch if you can't provide constant compressed belts.
Remember; inserters 'time out' if they have to wait too long to collect a full stack and will then swing with what they have.
So: for an item stack capacity of 50, a stack size of 10 and an item stack that's already at 30 items:
Compressed belt fully availabe: +10 -> 40
Lapse in production: +3 -> 43
Belt fully available: +10 -> 53 (busted!)

Originally posted by knighttemplar1960:

The person that made the video that I linked is quite clever and he addresses all of these things in that video.

I'll have a look. I added it to my watch list.

[knighttemplar1960]

Late game I rarely move stuff from belts, and where I am still using belts, I'm using spltters to mechanically sort disparate items. For bulk items that need a stack inserter Its usually from a chest to a machine or from a rail car to a chest. Moving from a chest solves the over fetching problem and you can use a chest to buffer the inserter and still solve the problem, which is why I mentioned stack sizes. Stack sizes of items don't apply to belts.

[AlexMBrennan]

Keeping the allowed stack size as high as possible for as long as possible.

Yes, but what does that achieve?

Let's say you want to load 100 copper plates and 10 iron plates - you will need the exact same number of inserter swings regardless of whether you load the iron plates or copper plates first.

[bluemonkey]

Originally posted by RiO:

This could work. But it has two issues.

Firstly, it only works for a set-up where each filter inserter handles a single, fixed, dedicated set of 4 items and no more (though potentially less).

Actually, you are only partly correct. I routinely use the described setup for larger collections of items and it works fine as long as I can guarantee that almost all of the items are present (up to 3 can be missing before it risks premature failure). I agree that It is neither dynamic nor is it count perfect. But the OP was rather vague about what they were doing aside from dividing up network signals to accommodate filter inserters.

Which brings up another possible avenue, maybe the OP could use a request chest with "set requests" controlled by a circuit network to use a regular inserter and get around the limit of 4 item types. (Also not count perfect)