Crazy Idea: Remove restriction on L-Vars so external apps can also use them

Originally, L-Vars were introduced to allow Gauge developers to introduce
state in their gauges and even exchange data between gauges. However, in that
context, it was not envisioned that their value needed to be made available
outside of the simulator. For many addon developers, these L-Vars also opened
extension points to the simulator’s model, allowing the introduction of
variables that simply fill in gaps in the predefined model. As soon as this
happened, other addon developers started searching for ways to allow external
applications to query these L-vars, or even move custom functionality into the
simulator for that explicit purpose. Integration-oriented add-ons, like
FSUIPC, which added programmable layers to expose other functionality within
the simulator, immediately started to think up new and inventive ways to
expose L-Vars. They also try to smoothen out the differences caused by yet
other approaches to integration, such as using Client Data blocks. The
restriction as it is now, puts a major block on integrating with complex
aircraft that explicitly publish L-Vars for that purpose. Developers wanting
to integrate with them are now forced to write their own custom layer,
resulting in more complex deployment and mixed integration strategies.
(SimConnect SimVars for everything except L-Vars) Removing the restriction,
even if initially read-only, would be a powerful change, and IMHO should not
be that expensive, as the simulator already allows for integration with
L-Vars, just not towards external clients. [unless there is some very old code
that nobody dares to touch of course, but that would be a huge piece of legacy
debt that should be very profitable to clean up…] Cheers, Bert

It’s not a crazy idea at all. In fact, it’s a very much needed feature to
solve the issue of having many WASM modules all doing the same thing ( using
Simconnect client areas and custom events to allow access to the Gauges API to
external .EXEs ), which is further complicated by the issue that stand-alone
WASM modules all run on the Main Thread. If it was possible to use these
features through Simconnect, lots of modules out there wouldn’t be required
anymore (or might be simplified a lot), with an obvious
performance/reliability benefits. A thread asking about this has already been
opened, and it’s currently flagged as “Schedule Evaluation”