Uhm ... sure it would be. With C# and the FSUIPCClient it's basically 3 Lines to read/write an Lvar (and setting up the VS-Project is also much less complex).
You misunderstood. I said it wouldn't be too different shouldn't be too different for some that already coded something in Simconnect. Not compared to do something else entirely.
In any case, the problem with your approach is wanting to convert something that is inherently EVENT-BASED into POLLING, because it's "easier", without caring for the consequences.
To do what you are asking, GSX should ALSO revert to do POLLING the LVar you are setting, to see if has changed, when the rest of its behaviour, like any Simconnect app is, instead, listening to Simconnect EVENTS instead, not doing anything if they don't happen, which is the whole point of event-based programming.
Using LVar just to simulate a bi-directional communication protocol is really bad practice ( forces doing polling from *both* sides ), and it becomes complex and bugged very soon, so you'd better use the proper communication protocol, which Simconnect provides for and it's there precisely to cover these cases.
And please, don't turn this post into a programming debate. GSX is our program to design so, if it'll ever had a communication API, it will be done in the proper way, using the correct tools for the job, in a similar way as GSX communicates with SODE.
