I installed the GSX v1.6.0.0
But maybe there were more then one issue which prevented couatl to start:
As i took the chance to renew all yours installers you have made in may/june i had both old version and new version beside installed according
to the control panel/software menu and i had 3 different instances of addonmanager.
None of this matters, I've spoke with the developer and, he told me the fix was made, and it prevented Couatl to CRASH when such problem was encountered. The fix prevented it to crash, but it made it quitting gracefully so, you wouldn't get a crash, but still the program ended, so the end result for you would have been the same: no buildings and no GSX working.
The log file would indicate the reason for the quit was because there was an error in the disable_on_airports line, but you had to enable logging to verify this.
The issue is not so simple: we use a standard library to parse .INI files, and empty space after an = sign it's not legal, but this library generates an exception in a way that can't be stopped. So, we are going to modify the standard library itself, in order to catch these situations.
We'll have a new Couatl.exe online very soon, which will not quit even if the .INI contains such errors.
if i ever try to exclude airports again, should the format look like:
disable_on_airports = EDDF EDDM EGLL
or
disable_on_airports = (EDDF EDDM EGLL)
as far as i remember i used brackets.
Page 19 of the GSX manual, where disable_on_airports is discussed, have a sample line with Icao codes separated with spaces, no brackets.
Is it possible to make a routine and button to (de)activate all installed sceneries at once in future?
I've already thought about this and, also making the "Backup RegKey" button saving multiple .REG file for ALL the activated products.
i flashed my bios some months ago, without deactivating all my FSDT/Flightbeam, Cloud9 sceneries. (hope this will never happen again 
)
There's no need to deactivate sceneries before flashing the bios. The only time when you need to deactivate sceneries, is when you plan major hardware components, because this will consume an activation, and the deactivation prevents that.
But, even if you see the "machine mismatch" message after flashing the bios, it doesn't mean this is going to consume an activation, the system is able to figure it out is the same computer, so it will ask confirmation for the activation, but it's not going to consume an activation.
This activation-error forced 4time window click interaction for each scenery .
I'm sure that flashing the bios was a way more cumbersome operation in itself, than having to click to confirm each scenery activation, and you surely don't keep flashing the bios so often.
I think there should be a smarter way to face this event.
The smarter way should be the bios of your mainboard shouldn't change its hardware id just because it has been flashed, because it's not that every bios flashing results in a request for reactivation, it only happens with some mainboard and bios releases, the activation system is NOT "designed" to check your bios release.
