Could you please add support for multiple inputs to the recipe combinator? As in the output should be the summation of each recipes' ingredients.

I have seen this suggestion brought up a few times but as of now it will require a major rewrite to the cache system to make this possible. I understand the appeal in having a single recipe combinator spit out all the ingredients for a bunch of recipes, but the problem with signals caching or scanning is real.

Both crafting combinators and recipe combinators are tightly coupled with the signals cache system (get_highest() function). If there is no signals cache the computational cost for every update will be horrendous, with the main UPS cost being the mod having to call the API to search through circuit networks in order to determine whether something has changed.

With multiple inputs, things get even trickier. I don't know of a proper way to cache multiple inputs as any single signal change means the cache has to be invalidated and the mod has to perform circuit scanning.

In short:
- Requires major signals cache rewrite
- UPS expensive due to caching becoming irrelevant - need to do API call whenever signal changes. Should be okay if the input signals can stay constant.
- Other problems like maximum slot for input and output signals

I will think about it as next feature if the problems above can be solved in a practical manner.

I think I can implement it as another entity, and users can choose to process only one recipe signal (highest) to uncapped number of recipes. The caveat being - the more recipes it has to keep track, the more often cache is invalidated and an API scan is required. So users should only tweak the cap with the associated workload in mind.

I can probably separate the update frequency for this entity too, for more options in spreading out the workload.

Would love to have this as a feature if it's still on your radar. I would also be happy to help contribute if you could provide a few pointers

You can use the decider combinator with "Anything != 0: Anything" to pick one signal from a wire. Then subtrack that from the wire and repeat for the next signal. This way you can split the signals into separate signals and feed each into a recipe combinator.

Problem I see is that you get the signal with lowest ID (or something) instead of the one with highest count. And each signal you want to extract adds 2 ticks delay. Also one recipe combinator per signal. You definetly want that capped to some value. There is no point in having 20 recipe combinators if the user only ever sends 2 or 3 recipes. The GUI for your own entity could ask for how many recipes to handle and then internally create hidden decider, arithmetic and recipe combinators and wires to produce the result.