mmmPI wrote: Thu Apr 24, 2025 4:11 am
I have something that "works" , it is a modified version of what Tertius made on the bug report topic, it's 99% Tertius' design, the problem is that i don't exactly understand why it works and any slight modification breaks it.
The combinator performs a map from a set of conditions to a set of
signals. In our case, it maps to a set of recipes. All possible recipes are defined in the constant combinator, each with its own value to differ between them.
As conditions, there are blocks of conditions. The blocks are combined with OR, so whatever inside one of these blocks is being determined, will influence the output. In each block, there is an EACH that walks over the recipe
signals and gives exactly one match for one recipe signal. There are 4 blocks, one for each recipe. The 1st block contains the conditions for the 1st recipe, the 2nd block the conditions for the 2nd recipe, and so on.
The EACH is used, because it "saves" internally matching
signals that can be output with an EACH at the output. The EACH at the output collects the matching
signals from all the EACH of the input, but only those whose other conditions (combined with AND) also match. So the 1st EACH outputs the 1st recipe signal if the conditions from the 1st block match, the 2nd EACH outputs the 2nd recipe signal if the conditions from the 2nd block match and so on.
This works similar to a select ... case statement, with just 1 combinator.
The flickering isn't due to that general combinator design. It's because of fluid flushing on recipe change. If some fluid level goes below 1000, the corresponding fluid recipe gets selected to create more of that fluid. If the previous recipe consumes that fluid, and that fluid is flushed back from the foundry fluid buffer due to the recipe change, the level is again back over 1000, and the previous recipe is selected again. If it works or flickers depends on the question if the level goes above the threshold on flushing or not. It cannot go permanently below the threshold in my example (posted in that other thread), because the fluid input and output are on opposite sides and I connected just one side, so the fluid can go out, but it cannot go in, or vice versa, without manually rotating the foundry.
You added these missing pipes, but now there isn't any flushing for the case there is a casting recipe active and you want to change away from that recipe: it will not change until the input fluid is empty, which needs one more set of valves/pumps. Because of these kind of edge cases, I gave up that general design.
Count the tiles: you already need as much footprint for pipes and tanks as a 2nd foundry needs. And currently, we just throw away any trashed solid material. On a real factory, we need to feed this back into some loop, which needs more space, so we don't save even the 3rd foundry footprint. May be even more, if you count unusable single tiles within. So there goes any space footprint advantage over 4 separate foundries.