Set Recipe + Read ingredients

[okuraku]

Ever since FFF #394 and #405 I've been daydreaming about a sushibelt setup with "generic" assemblers. In the forum thread for the FFF, I read others wondering how these two settings would interact, and now that 2.0 has hit I have spent all night tinkering in creative mode trying to figure out myself.

I have a row of assemblers, one set to Read ingredients only, with its recipe set to red circuits. Then 5 other assemblers all set to both Read Ingredients and Set Recipe. Since my goal was to combine this with the whole belt reader, I circled the whole thing in a conveyor belt and hooked that up to the same network to begin tinkering.

At first, basically nothing happened, because of an important functionality understanding I gained of "Set Recipe": When multiple item signals are present that it could try and build, it always tries to build the one that is "lowest" on the tech tree, which in the case of red circuits, is copper wire. All the rest of my assemblers got set to copper wire and nothing else.

I spent several hours tinkering with it and the closest I got to success was:

Whole belt reader sends belt contents to an accumulator to be inverted (Each * -1), which are then sent to the generic assemblers on the red wire. The green wire connects them all together, and is successfully "added" to the red wire inside each assembler, which means that the only things they will set their recipe to will be the things not already on the belt. It almost works beautifully, but quickly it gets into a state of flipping every tick, I think because the assemblers basically get into a fight over who will make the green circuits and who will make the copper wire. I spent another couple hours trying to incorporate the read recipe finished / read working signals to try and fix this but without success yet.

Looking at FFF #394, obviously I can tell a massive amount of combinators may be required to achieve what I want - basically, a true sushi conveyor belt, only items that enter the belt are things directly requested as ingredients by assemblers that can swap their recipes on the fly as needed by their peers, who are also generic. But I can't get past the issue of assemblers not "holding" their chosen recipes long enough.. they swap to a "lower" recipe, and then empty themselves out...

I wanted to discuss with others, possibly to get the answer, but also possibly to get a clue I may be missing. I know my own experience/understanding of combinators is severely lacking, I feel like the solution or at least the next step is right there if I could just see it.. I assume that everything needed is there in the game already, but if more could be added, perhaps if assemblers could be told to "Set Recipe" only to the value on a certain signal, instead of always the lowest tech item on all the networks attached to them, it would help a lot. But maybe I'm just not seeing why that's not really necessary..

blueprint.txt

Blueprint showing the flipping

(1.76 KiB) Downloaded 354 times

[okuraku]

With the help of reading reddit user u/doot_toob's example I think I figured out a good solution for me. The flipping I am seeing in my very simple setup I think is caused by "feedback" of "later" assemblers talking back to "earlier" ones and getting into fights about who will build what. If I use a simple arithmetic combinator between assemblers to establish a directional chain of their shared circuit network (instead of direct connection, connect to combinator with Each + 0 -> Each) they don't seem to compete anymore.

This gives more ideas about how to structure a sushibelt + generic assembler configuration! Excited to explore more designs.

[FGenious]

The main problem is, an Assembler gives back "Read ingridients" signal to both red and green wire without checkers. Or which signals it inputs and outputs. Or better both, with control over input/output in red/green wire, like Decider.

I'm checking your trick with Arifmetic combinator and "each + 0 => each". Somehow it works better, thanks a lot for this one.

[edipost]

I got your mixing problem, a similar issue happens when you want to set a request and read contents from a requester chest.
Devs could add the checker for green and red circuits for those options.
Anyway, there is a workaround.
let's break down, the signal outputted by the assembler mixes with the signal input by you, since you know this signal, you can create a inverted version of the input signal using a combinator set to "all * -1", using the other color, also get a copy of the dirt signal using "each + 0 => each" or "all * -0" and connect both exist together and you get a clean signal