elem_filters for type=signal choose-elem-button

[IsoSchiz]

choose-elem-button is awesome. But it doesn't quite allow easy re-creating of the conditions UI.

A quick addition would be the ability to add elem_filters for type=signal. The filters should support:

• Show/hide meta-signals (signal-everything, signal-anything, signal-each) - need control of each meta-signal independently as sometimes only each or every is appropriate, sometimes every and any are but each isn't, etc.
• Show/hide the "Or set a constant" sub-panel (e.g. from the RHS of the train-stop "Enabled Condition" UI)

[Rseding91]

Just FYI: the "or constant" is not a thing when it comes to signals so that's never going to happen with this CustomGuiElement type. A 'signal ID' is one of a special signal, a fluid, or an item.

[IsoSchiz]

Yup, understood.

Would it be possible to provide a composite custom GUI element that returns a CircuitCondition (and behaves the same as the various existing ones, with the "or constant" behaviour for the RHS)?

This is a relatively common use case, and while it's possible to replicate, it's difficult to get entirely right (especially with the same UX as vanilla UIs).

[Sharparam]

Are there any updates on any chance of getting support for hiding "everything", "anything", and "each"?

Currently I still have to have a workaround in my mod when a player selects one of those three, displaying an error message to the chat instead of just being able to not make those selectable.

[egladil]

+1 on the "or constant" part

Having an elem_type of "signal-or-constant" that shows the same interface as when selecting the rhs of an arithmetic or constant combinator input would be really useful. This could then be made available on the LuaGuiElement by a combination of the existing property signal and a new property constant. If signal is set then constant is nil, and vice versa. Instead of a new property constant, the existing value or number could also be used.