Hi Bert,
That’s a nice rundown, thank you. Do you have the original post’s URL? Just curious if there was discussion around it there.
The upshot of course is that yes one still needs some kind of “insider” access to read L vars, which at the moment seems most “practical” via WASM module. Mind you I"m not saying this is an ideal solution by any means.
But lots of good stuff right now is controlled or read via L vars (partially because lots of the SimConnect events and SimVars are broken). And users want that data/control (I maintain a plugin for a popular touch-based controller and the L vars were on top of the requested feature list even though they can already request any SimVar and fire any Key Event which SimConnect supports).
The custom “ClientData” struct option is good and maybe “proper” but from an “access tool” author perspective it presents some challenges. Namely that one needs to know, in the code, how to decode the data struct(s) (the tool users can barely handle what’s already available… so setting up custom data structs it out of the question 
).
In contrast, when dealing with individual value types (PODs or known simple structs like XYZ), these are much simpler to define/access “on the fly” using generic code. A somewhat-savvy tool user can set these up pretty easily as needed, which is IMHO essential because there’s no way any tool is going to know about every possible data value on every possible aircraft.
Of course the “ClientData” approach could also use individual fields instead of structs, just like, essentially, SimConnect allows now to individual SimVars (except the few structs of course, but those are essentially just another known type).
Personally this seems like the most flexible solution to me.In fact if aircraft devs could simply “add SimVar” the whole issue would be solved AFAICT. Am I wrong? Not only would they be instantly accessible externally, but it would also delineate that “Local” vars are private and SimVars are public (which I do agree is the point of local vars, as you point out).
Why SimVars have to come from some rigid pre-defined list here in the 21st century escapes me.
I’m not even clear on if using fewer, larger “blocks” of “ClientData” with SimConnect, is actually more efficient than using more smaller ones… my experiments so far show no difference and with my WASimCommander I chose to implement each variable request being returned to the client as separate SimConnect “ClientData” bins (sized appropriately for each data type expected). This makes them much easier to manage too.
Anyway, not sure you wanted to get into a discussion of it or not, but those are my thoughts… with apologies to @Phil7789 for the “hijack!”
Cheers,
-Max
PS. Oh and the custom event “you must choose an ID in this small range and hope no one else happened to have chosen it,” w/out any way to verify, is pretty ridiculous. Anyway it doesn’t do anything for data access at all, just triggering things.
