If we don't document a variable, there's a reason for that. Add-on developers shouldn't use that variable, and there's no reason why they would want to.
An add-on always needs to interact with one of the GSX services, so there's no reason why it should be concerned with the Couatl status directly and using to know if GSX is available, because there a lot of situations (especially in P3D), where Couatl might have started, but GSX is not available, or not available yet, for example:
- All FSDT sceneries use Couatl even without GSX so, Couatl might have started, but not GSX.
- XPOI uses Couatl and it's not an airport.
- Even if GSX is used, Couatl might have started, but GSX might not be available for many reasons: it might have been disabled by the user, the airport cache might not be ready (either is rebuilding right now, or it failed to rebuild), the airport might have not been recognized, or GSX might still be finishing starting up.
So, using that variable to know if GSX is available is quite unreliable, and that's why we haven't documented it, because it's only useful internally.
Instead, since add-ons always need to interact with GSX services like boarding, deboarding, pushback, etc. the reliable documented way to know not "just" Couatl started, but GSX itself it's ready to use on that airport, is to check the various _STATE variables, like FSDT_GSX_DEBOARDING_STATE for example.
If GSX is available, any of these variables will have a value which ranges from 1 to 6. This means, if they are 0 (default value of any variable), GSX is not usable, for some reason, with Couatl not started being just one, so it's a way more reliable way to check if GSX can be used and works in the same with FSX/P3D and MSFS.
