New "total ingredients" mode for selector combinator

[Tinyboss]

TL;DR

A new mode for the selector combinator to output all the ingredients for the recipes on its input.

What?

A new "total ingredients" mode for the selector combinator. It outputs the total ingredients needed to craft the items on its input, in quantities given by the signal values. For example, if the input is 10 red science and 1 red belt, then the output is:

(10 iron gears + 10 copper plates) + (1 yellow belt + 5 iron gears) = (15 iron gears + 10 copper plates + 1 yellow belt).

Items with no ingredients would output themselves, e.g. 100 iron ore would be output as 100 iron ore.

An item signal and its recipe signal would give the same output. Items with multiple recipes would use a default, and different recipe(s) could be sent specifically if needed.

Technologies would output the total science needed.

Recipes that produce multiples of their product would round up to the nearest multiple of the recipe inputs. For example, 3 yellow belt would output 2 iron plate + 2 iron gear.

A productivity bonus could be provided on the P signal and would be taken into account, making the assumption that the productivity bar is initially empty.

Why?

It's not just duplicative with the "read recipe" function on crafting entities, because it can work without the appropriate entity to read from. One great use would be to get the total materials needed for a logistic group, set on a constant combinator. Because items without ingredients return themselves, this function could be used repeatedly to calculate raw material requirements if desired.

This idea came to me while considering another suggestion for reading the current research and doing something different depending on whether Agricultural Science is used, and would enable half of that ability. (The other half being reading the research queue from labs.)

[mr_abomination]

+1 to this. I think it could be very useful for fancy circuit automation and compacting down without having to use the assembler as an intermediate

[hitzu]

I was just about to suggest the same thing! It’s frustrating that to create an automated setup based on available ingredients, we have to add dummy machines which work is only to list out the ingredients for each possible recipe first. Only then can we compare it with storage to decide what to craft. Using constant combinators and manually inputting every ingredient list is quite a tedious workaround for a game focused on automation!

[SyrusVir]

Wholehearted +1. That information is already available in the parametrized blueprint interface so it shouldn't be too hard to expose that information to the selector combinator.

[Bazhosh1]

+1

[boskid]

No. This would create a lot of problems around items that can be produced by more than one recipe, which is extra fragile when one recipe can be crafted by one machine while other recipe can be crafted by other machine. This suggestion is under-specified and as such is not going to happen. It is also not specified here if its about direct ingredients of the provided signals, or if it should be decomposed all the way to the raw ingredients, and then question would be what should be considered a raw ingredient. If there would be some attempt to compute ingredients using only recipes of a specific machine, then should the specific machine be given as a parameter of the selector combinator, or should it be also provided as a signal on the circuit network? Having it provided by a circuit network would cause problems if you would want to provide both recipe and entity through a circuit network since it could considfer entity restriction as item to be decomposed.

Information from SyrusVir is not applicable here since blueprint parametrization's "ingredient of" is given a specific recipe without any ambiguity, while circuit network may be given item signals that have multiple recipes available.

[Koub]

[Koub] Moving this to won't implement then.