mpaperno
commented
2 years ago Serious limitation with Events is that the value which triggers the event has to be selected from a static list of choices. Which pretty much rules out anything with a dynamic value.... like pretty much all the data for a flight sim. Some simple things with set values would work, like switches (anything on/off) and maybe flaps detent or magneto.... but those are all easily done with the "when plugin state changes" already.
So I think the question boils down to if it's worth having some dedicated Events in the UI for these "simple" states which only have, say, 1-4 values anyway, or is that just extra clutter in the UI?
For generating event json entries, at minimum we'd need a way to flag which states should be events. But I think we'll also want dedicated name and format values to use for the events, since the language used is fairly different ("this happened" vs "here is this"). I'm also not sure how it would deduce the available event choices w/out those being specified in an attribute. So really I think we'd want a new attribute, but perhaps some of the data can be re-used from the related TouchPortalStateAttribute (and certainly the association of the event to the state could be maintained that way).
Is your feature request related to a problem? Please describe. Touch Portal allows specifying specific "Events" when custom plug-in data changes. Investigate the pros/cons of using those. Current flow requires the use of "Dynamic Text Updater" or "When Custom Plugin State Changes" logic. Investigate adding state change events for all the states into the corresponding MSFS subsections.
Describe the solution you'd like If enough advantages, will need to update the auto generator to be able to create the events into the Entry.tp automatically. Hopefully this will not require additional attributes, instead it would be ideal if it could use the existing state attributes.