Factorio Forums

Having access to ingredients via parametrized blueprints is nifty, but would it be possible to have a selector combinator mode which outputs the ingredients of a given signal sequentially? Ingredients would be requested like the existing 'select input' mode.

Most items only have one non-recycling crafting recipe, but not all. An incomplete solution would be to ignore alternative recipes and only index the ingredients for the first-unlocked recipe.

To get around this, I suggest all ingredients of each item are listed. e.g. plastic's 'ingredient index' mode would output signals as follows:
0: coal
1: petroleum
2: bioflux
3: yumako mash

Players could then filter ingredients to ignore materials that either don't appear in Gleba recipes, or only appear in Gleba recipes, as required using a further decider combinator, meaning that this solution would be useful on all planets and potentially for modded scenarios.

This mode could also output the quantity per craft, i.e.:
0: coal 1
1: petroleum 20
2: bioflux 1
3: yumako mash 4

An alternative would be to also add a 'recipe index' e.g. 'recipe index' for plastic would output signals as follows:
0: plastic bar (i.e. the item itself, associated with the standard recipe)
1: bioplastic (i.e. the first non-standard recipe)

The 'ingredient index' could then be set up to accept item signals (for the standard recipe) and alternative recipe signals (for non-standard recipes).

This can be done even now by sending that signal to a machine with Set recipe and Read ingredients.
Copy blueprint

Muche wrote: Thu Jan 09, 2025 10:40 pm This can be done even now by sending that signal to a machine with Set recipe and Read ingredients.

Except this causes problems with the need for the machine to output other signals, and would seem to cause weird circular issues when you both want to set the recipe AND read the ingredients (for any kind of generic machine). You seem to indicate that it works, but I don't understand how, and think there is some weird blackmagic in the code to cause the machine to not read its own output as an input.

It may be fixable by having the ability to select the wire of the signal (so set the recipe on red and read the ingredients on green), but it would seem even easier to do what shapezio has done and implement something like this suggestion.

If you send to the selector combinator two signals (an item to craft, and a machine to craft it in) then set the mode to "recipe" you can get the recipe entirely within the circuit network and independent of the wiring up the actual machine. Now it is all very clear how things work because circuit elements have clearly defined input and output sides. We know that what we are outputting from the combinator is an output and can only be an output. Nothing circular can happen.

Except it does work. Have you even tried it?

Yes, there is "blackmagic" - 123753 Asteroid Collector not counting own contents for "Set Filters".

Yes, having ability to specify reading and writing wire would be more user friendly, has been proposed, and might come in 2.1 - 117481 Please, PLEASE make circuit connection behavior configurable per wire.

Muche wrote: Fri Jan 10, 2025 12:25 am Yes, there is "blackmagic"

And I would say that is a problem/symptom of a bad design.

Muche wrote: Thu Jan 09, 2025 10:40 pm This can be done even now by sending that signal to a machine with Set recipe and Read ingredients.

0eNrdV9tuozAQ/ZXKz06FuQWQut+w71WEDLiNJTCsMdlGEf++YxNImjgreEklxMvJeDw+59jxwAllZccayYVCyQnxvBYtSt5PqOWfgpY6JmjFUILyPat4TstNU1JI7jHiomBfKCE9tqRnvM73tMqYvEp1raktK1muarnJ6yrjggK8muNZ5xS8BR7HTUMFK6+y/X6HEROKK84GIebHMRWd4ZIQPAkCqQqkXC+LUVO3MLcWei2oF78GGB1hmvMawCoFl0DVDEdYV1CyLtOM7emBw3SY0w7j7XcMPEa3MPrgpWLyNnpmBapaxfNNRjWbPx0tgT3ERS0rcEAvWjVUGrYJejOBTm8e6Xfw9NqtG8kufrCHd2q3o1rPqLXrUyl4wBuop2THMJKMFikXn5IVHFZuh3ivB4a0G01DOL2TZmHuYctxumNNyHfaczZpuQhgcNaxTIOP/3fOH2/BdpaSumFwFkzGuT6UHEBa0a9Rnjlm6Xji9WGxMA2WMQ2fwtSxMQ2XMY2ewtS1Md0uY3o5ys/f/mghVefn9j9eSNX9uQNAHGzvWY//+dHDy1df/BWbmgekFFOFDy5blV4apTqaa+vApepM4xgdMxkbKo5qDxceGpYa3b7pL79Ma82HFWZX1H3I4gSZ60S4difcuU5Ea3fCm+vE5WZcqxX+bCuctVsRzLbCXZUV8O3yF7qTJvpOMMEeJjsMyNUPIBdigYl5EIlMzJ9iGoVnBNgxw4GGxMBQw6HQdpquUXxGMOwZGGnoGxhrGAAEblyxSr8JT1+MGJU0g31J0O/h1fjl6hX6pWBVDSkHcN7YHYRu7MdxEHguiULolv8AzXnr1w==

Copy blueprint

Yes, and this use case breaks down immediately if you ever want to connect a couple of machines together with the same wire. In one factory I had a dedicated assembler that didn't actually assemble anything just so I could read the ingredient list from it.

If an item or fluid has multiple recipes, the additional recipes already get extra signals. So for selecting the correct recipe, the item's or fluid's signal itself can correspond to the default recipe, which is the recipe the item or fluid is merged with on Factoriopedia. The additional recipe signals would serve to identify their individual recipes.

When given Bioplastic recipe, it should output 4 Yumako mash and 1 Bioflux.
When given Plastic item as input, it should interpret it as the Plastic recipe and should output 1 Coal and 20 Petroleum gas.

Why?

The assembling machines are not really well-equipped for this sort of computation. First, you must use the entire machine. Second, the different kinds of assembling machines (Foundry, Electromagnetic Plant) ignore recipes they cannot craft. Third, furnaces do not support setting the recipe, so good luck figuring out what stone bricks are made from. Finally all of these machines take 2 ticks to compute the result.

There are additional considerations for such a feature:

What should happen when there are multiple input signals?
Say, the combinator could evaluate them individually and sum the results like the following example:

Input: 5 iron gear wheel, 10 Electronic Circuit
Output (Option A): 25 Iron Plate, 15 Copper Cable (for each signal, compute ingredients, multiply by signal)
Output (Option B): 3 Iron Plate, 3 Copper Cable (for each signal, compute ingredients, do not multiply)
Output (Option C): 1 Iron Plate, 3 Copper Cable (pick highest signal, compute ingredients, do not multiply)
Output (Option D): 2 Iron Plate (pick what assembling machine would, compute ingredients, do not multiply)

I can come up with use cases for all options. Option A is better suited for supply-demand computation scenarios, option C is better suited for priority-based systems. Option B is somewhere in between. I personally think option A is the most versatile, as you can get all the other behaviors from it. Want highest signal only? Select using selector combinator first. Want to compute ingredients for only one execution? Use decider combinator and output 1 of Each.

What should happen when a recipe produces multiple results?
If option A is picked, the question for multi-output recipes comes up:

Input: 10 Copper Cable
Output (Option E): 10 Copper Plate (Compute what is required to execute the "Copper Cable" recipe 10 times)
Output (Option F): 5 Copper Plate (Compute what is required to produce at least 10 Copper Cables)

Here I strongly lean towards option E. The reason is that the input signals are really to be interpreted as recipes, not items.

Additionally, I propose adding another mode, which computes the expected output of running the input recipes (rounded down) which could work like in the following examples:

• Input: 1 Transport belt => Output: 2 Transport belt
• Input: 1 Molten iron => Output: 250 Molten Iron, 10 Stone
• Input: 1000 Uranium processing => Output: 7 Uranium-235, 993 Uranium-238

Such a mode would really help in disentangling automatic recipe selection logic.

I would keep it simple:

- Combinator mode has one fixed parameter, the machine used to produce a recipe, together with the surface the machine is placed on.

- It would then work as the current "Read ingredients" option on the given machine. Input signal is like set recipe, output are the ingredients. It has an option: it either outputs the ingredients for one craft, or the total needed for the input signal count. You can also set a signal to output the number of products produced per craft.

- If you provide multiple signals as input you are on your own. It would use the same recipe selection logic as the machine to select the signal to be processed.

In addition, I would add a recipe filter function: it takes multiple set recipe signals, and only forwards those that can be made in the configured machine. That would it make easier to figure out which machines can produce requested items.