However, it does seem to be triggered by the fact that GSX LVARs dont seem to have been initialized/advertised when GIT does its one and only scan after the aircraft is flyable after loading.
That's explains why that tool won't work with GSX: it assumes an L: variable must be something related or created only by an aircraft, so it connects its scanning routine to the airplane loaded event. This means it won't work if the variable is created at a different time, which is the case of GSX variables, that might be created at any time, usually when they are needed.
While we could probably create the variable when GSX starts, it still won't be a foolproof solution, because it might not be always certain if the airplane or GSX would start first, since GSX starts in parallel with the sim under an entirely separate thread and process ( the Couatl interpreter ) and, there are additional timing issues, because it's not even Couatl or the GSX python code that *actually* declare the variable, since this cannot be done by an out-of-process ( = .EXE ) program, but only by an in-process .DLL, which can be a gauge or a .dll module. In GSX's case, it's the Addon Manager .DLL that *actually* creates the L: variable, following a communication request from Couatl that is running the GSX code.
In addition to that, Couatl automatically restarts itself when the airplane is switched, and that takes a couple of seconds so, even if we just re-created the L: variable at each restart, an utility that scans for all used L: variables by IDs, should do it each time after the airplane has loaded, but should ALSO wait for GSX to finish its startup, which would make it needlessly complex.
So, the only way a tool that checks L: variables would work with every product that creates L: variables which is not necessarily an airplane gauge, or might simply be an airplane gauge that initialize its L: variables *later*, not during startup, would be this tool could allow to check L: variables at any time, or allowing to monitor variables that are supposed to be used in the near future, if you already know their names in advance.
I have no idea why that that GIT tool consider an "error" a variable that doesn't exists. The way the simulator works, an L: variable is created by the first one registering, then everybody else has access to it so, if the code is done correctly and it always checks variables before using them, it's surely possible to monitor a variable *before* its created, because in that case, the monitor utility becomes the creator, and while I cannot speak for others, GSX won't be confused by a monitor utility that has created a GSX own L: variable before GSX (as long it doesn't WRITE anything to it!!), only for the purpose of monitoring it. When GSX will try to create the variable itself, when the Pushback starts in this case, it will see the variable already exists, and will just use it.
