Would be useful to eithier allow irq to be set to an array of signals or have a 2nd variable 'irqs'. The list of signals is summed and code is run if total > zero.

Looks like it would be straight forward for-each on irqs; new to Lua, but will share my code if I get it working.

Could be done with several standard combinators, but I just don't have fun "coding" with a sprawl of combinators.

"irq" signal was added when someone needed a way to lower performance impact when using many of these combinators, I think.
I.e. so that they won't run too much Lua code on every game tick, and only lookup/compare one signal/variable.

• Adding a loop over more signals seem to be a bit in conflict with this goal, especially if you're also using this for performance reasons.

• If not using this for game performance optimization, then maybe just put such check into a combinator code? Should work the same from the gameplay perspective.

• If game-UPS is the issue, one decider combinator with "Any Signal" ">" "0" = "<irq-signal>" "1" will beat anything in lua ofc, but if that won't do, and you really need sum, feel like it's still a bit too oddball special-case to add in the mod tbh, but you totally can add it yourself.

For implementing this in control.lua, you're looking for on_tick(ev) function - this is the whole check:

if mlc.irq and (mlc.irq_tick or 0) < tick - (mlc.irq_delay or 0)
    and mlc.e.get_merged_signal(mlc.irq, defines.circuit_connector_id.combinator_input) ~= 0
  then mlc.irq_tick, mlc.next_tick = tick end

What you might want to do there is to run mlc.e.get_merged_signals() instead to get whole signals-table.
Then lookup some special table-value that you'll be using in mlc.vars, e.g. mlc.vars.irqs and compare signals above to that in a loop.
Accumulate the sum in some local var, or do any other math there, check result, and either do same mlc.irq_tick, mlc.next_tick = tick operation if combinator code needs to run out-of-order, or just do nothing otherwise.

This mod is updated very infrequently and haven't really gotten any major bug reports or new features for years iirc, so don't think you'll need to bother rebasing such changes on top of a new version anytime soon, so I'd suggest doing it this way, if - again - UPS is the problem, and single in-game combinator won't work.

Thanks. Yes, started down the path, then realized I'll be running Lua code in Lua code, so not really any advantage. Could just do the check at the begining of each tick and end for the same effect.

Used to other engines where the mod would be compiled in fast C++ or such to run Lua instead of this cool bit of Lua inception. ;).

Thanks for the great mod. Perfect for automating my oil products without a sea of wires that would ruin my type of fun.

One thing that I remembered later as an option is actually using factorio's C++ code to do the signal-filtering in a somewhat sneaky way.

Currently this combinator is actually not just a 2-tile factorio combinator entity that you see, but that arithmetic combinator entity, which has wires to two separate invisible/untouchable constant combinators placed underneath it, connected to its outputs. Inputs are read from arithmetic one, outputs are set on constant ones (mlc.out_red + mlc.out_green, separate because signals on these can be set to different values).

So what if we want to somehow process signals in a super-efficient way on every tick instead of Lua and only do bare-minimum "compare signal X to 0" operation in the latter?
Well, if they can run Wolfenstein 3D, then obviously this can be coded in invisible arithmetic/decider combinator gates/logic, piled underneath actual visible combinator and connected to its input wires, with final output in their processing chain read for e.g. wakeup "irq" signal.

Bit more work, but tbh not actually that much - code for placing/removing these invisible mlc.out_red/green constant combinators is already there, any amount of extra entities can be added/removed in these two places, and then irq signal just read from e.g. mlc.irq_chain_end in on_tick, instead of visible combinator inputs, like it is now.

Don't think this kind of "compile logic to invisible gates" approach will scale well enough to "implementing Lua in a chain of stock combinators", but pretty sure it should be very efficient for trivial arithmetics and/or filtering, same as it is in the game with vanilla combinators.