TL;DR
For the EventFilter class add a new child SignalChangedEventFilter that can be used to receive events when the signals of an entity change.What ?
Add a new EventFilter:filter SignalChangedEventFilter
filter :: string | The condition to filter on. "signal-changed"
mode :: string | How to combine this with the previous filter. Must be "or" or "and". Defaults to "or". When evaluating the filters, "and" has higher precedence than "or".
invert :: boolean | Inverts the condition. Default is false.
Other attributes may be specified depending on filter:
entity :: int | ID of entity to watch for signal changes
The entity must be one that wakes up when a signal connected to it changes. Like an arithmetic combinator. But it would be nice to have this for lamps too if not for any entity with a circuit connection. When the entity wakes up due to a change in circuit signals the event fires.
Additionally it might be nice to have a dedicated SignalFilter entity. This would be an extended decider combinator. Instead of having just one DeciderCombinatorParameters it should have a list. Each condition is evaluated and the outputs are summed. The SignalChangedEvent is triggered when the output changes. For example:
Iron Plate >= 1000 ===> 1x Iron Plate
Copper Plate >= 2000 ===> 1x Copper Plate
The SignalChangedEvent would fire whenever Iron Plates pass the 1000 units threshold or Copper Plates pass the 2000 units threshold going either way. The SignalChangedEvent could include the list of output signals of the conditons to make it even easier for LUA scripts. So the script would only see the Iron Plate and Copper Plate event and only if they are 1 in this case.
Note: the SignalChangedEvent would not fire when Iron Plates go from 1363 to 1364 since the output has copy_count_from_input=false. The Iron Plate output signal would remain at 1 so no change. This would allow to really reduce the number of SignalChangedEvents for most cases.
Why ?
There are many mods that want to react to circuit signals. Doing this efficiently is hard since signals must be scanned in on_tick and the script is flooded with all the signals on the circuit network. If more than a handful of entities are used that want to react to circuit signals then one has to add extra logic so only one or a few are scanned each tick. Examples for this are the LTN Train Stops that need to schedule trains when enough items collect in buffer chests or enough are used up. The SignalChangedEvent would make it possible for the LTN Train Stop to "wake up" when the input signals change and only scan the circuit networks for each stop when needed.Often the decision when to act comes down to a simple list of conditions like in the above example and any other signals can be ignored. The additional SignalFilter entity would make this exceptionally efficient causing SignalChangedEvents only when truly needed. Without it the user has to add additional combinators to reduce the noise of the signal input for the watched entities. The SignalFilter entity would be nice to have but isn't essential to this suggestion.
