So I decided to go for GSX Pro....

If I open FSDT Universal Installer the Update Button refering to GSX Pro is always clickable. Clicking it, launches something that seams to be doing some sort of an update that lasts about 2 min each time...

Since there is no info provided about the installed version, I can't realy tell if it's doing something or not.

It's a bit confusing....

1 hour ago, GEKtheReaper said:

So I decided to go for GSX Pro....

If I open FSDT Universal Installer the Update Button refering to GSX Pro is always clickable. Clicking it, launches something that seams to be doing some sort of an update that lasts about 2 min each time...

Since there is no info provided about the installed version, I can't realy tell if it's doing something or not.

It's a bit confusing....

If you click on the last side on "last release" (or something like that) you can see when the last update was released (and accordingly if you need to update). But I agree having the button always available is a bit counterintuitive...

@Fiorentoni you mean on the "left" side under "Release notes"?

 

Also to mention: GSX put 2 Icons on my desktop: FSDTLive Update and the FSDT Installer and both kind of do the same spooky "Update" procedure...

Edited November 29, 20223 yr by GEKtheReaper

2 hours ago, GEKtheReaper said:

It's a bit confusing....

To say the least. It gives no accurate indication if an update is needed nor does it give any feedback as to whether it updated successfully. A real mess and I wish they'd redo this 'thing' they call an installer.

I guess we have to accept it since GSX is a one-man show.

3 hours ago, GEKtheReaper said:

@Fiorentoni you mean on the "left" side under "Release notes"?

 

Also to mention: GSX put 2 Icons on my desktop: FSDTLive Update and the FSDT Installer and both kind of do the same spooky "Update" procedure...

Yes, that's what I meant. Yeah actually you only really need the FSDT Installer. The other app is basically like clicking the "update all" button in the Installer app. A bit redundant in my opinion and something that needs to be made more user-friendly (i.e. less confusing).

I agree that this is confusing. 
 

I don’t understand why it was designed this way. They could have chosen to check if there is an update when you load the installer program or grey out the button or even use a pop up notification. 
 

Let’s hope they can amend this process….with an update 😁

On 11/29/2022 at 9:40 PM, chickster25 said:

They could have chosen to check if there is an update when you load the installer program or grey out the button or even use a pop up notification. 

We explained so many times why it's not working like that, and why it's the most reliable update method, and I'm confident that, if you approach it with an open mind, you'll surely understand why it works like that. 

What "version checking" really mean ? What really matters for you: knowing you have some kind of version, or being sure the installation is complete, nothing is missing, down to the last file ?

Because, being happy to see a version number that checks for what is supposed to be the latest version, and sleep safe knowing you have "the latest version", and having a PROPER install, are two completely different things.

You say you would like to have the program "checking the version" while it starting, so it could "grey out" the update button. There are so many reason why, even this is the most common way to handle updates, it's not the best way.

- How do you make a version check ? You do it properly, and check each file one by one, or you just use some crucial files ( like the main .EXE of an app, for example ), so the version check can be made quickly ? And don't forget the FSDT Universal Installer must handle *all* FSDT products, 37 of them, in theory a dedicated user might have all of them installed.

So, the first problem would be, doing the "proper" check, the only reliable one that would ensure all your files are correct and are the latest version, if done at start as you suggested, would take a long time. The more products you have installer, to longer it would take to do just the initial check.

How long, exactly ? Do you think we haven't tested this ? Do you know what is the most time consuming part of the update process ? Is *exactly* the CHECK itself. Hashing thousands of files ( just GSX Pro is 30.000+ files) takes like 95% of the time of the whole update process, which means the updater would spend most of the time it takes to DO the update just *starting*, and that's just to disable the update buttons if an update wasn't needed. I'm not sure how much better the program would be, if it took 3 minutes in which you can't do anything else, only to show you with the right buttons greyed out. What if you didn't want to perform an Update to begin with, and started the installer JUST to read the manual, or JUST to Activate a product or JUST to Deactivate it ? That long startup would have been imposed to you, even when it wasn't required.

Now, of course, I assume you'll surely say "but I have this update made by XXXX, and it start immediately, and it check my version immediately!"

Well, of course it does. Because it's cheating. Or because the application it's made in a way that, for each update, the developers are reasonably sure a certain file will ALWAYS change. The easiest ones are apps with a main .EXE that gets updated with each new version. EXE files have version numbers embedded which can be checked with a standard Windows API call, so checking for updates in this case is extremely easy and very fast. Same for other executables, like airplane gauges, where it's expected they would change at every update. In these cases, it would be enough checking the version of the main .EXE.

So yes, it's quick to do, and it's easy to understand but, it is RELIABLE ? Even normal apps are not made just by the main .EXE, they usually come with many extra files. However, again, extra files of normal apps are usually a bunch of .DLLs, which are also executable, which also supports version checking, so they are also easy and fast to check.

With something like an airplane add-on, things will get more complex. Sure, you got the last version of the .WASM gauge but, what about the other files. What if your aircraft.cfg/flight_model.cfg, etc. gets corrupted, or are removed for any reason, or you make a change to it to play with stuff, then you forgot about it.

A "quick updater", one that only checks a couple of crucial files that have embedded versions won't be able to deal with this situation, it just can't, because it would have to...check each and every file, hashing them one by one, against a known set of hashes, that's the only sure way that, you don't just have the latest version of the main .EXE or the main .WASM file but, instead, you have the latest and correct version of everything, down to the latest file.

And the worse thing is, with an updater that only checks for a few or a single file, showing a version number, without checking the whole set, you have no way to even *suspect* you might have a problem. Sure, your airplane might flight wrong, because you edited something and forget about it, but the updater won't even tell you, because it's not checking every single file.

Now, I'm sure ( as someone already said ) "but if I edited a file, it's my fault, and I would know that", that was just an example. A file might be altered or corrupted for any reason, from hardware failures to interference with other software (antivirus) or just logical filesystem corruption so it might be gone/corrupted the next time Windows will run a checkdisk. It doesn't really matter why a local file might be gone/corrupt, that's not really the point, the point is, a fault-tolerant updater should be able to handle this, and the only sure way is, again, hashing each and every file locally, and compare it with a list of the correct hashes stored on the server, and download anything that is not matching.

Now, I made an example of an airplane, but something like GSX or an Airport scenery, is almost *entirely* made by files that have no inherent version number, like models or textures, .cfg files, .ini files, and there are *thousands* of them in each product. GSX has one main executable, but it's not as if we always update it. Quite the opposite, most of the time other files are being updated, and they might even be more important to how it works than the main .EXE, because the main .EXE ( Couatl64_MSFS.exe ) it's JUST a Python interpreter that connects with the sim through Simconnect. None of the GSX logic is there, what makes GSX work ( or not ), and what usually requires a fix in the logic, is not in the .EXE, but in the many Python scripts that makes the whole program. And of course, we have thousands of textures, sounds, models, xml behaviors, support .BGLs, lots of things that don't have a standard version checking method, and each one of them is important. So, for a product like GSX ( but even airports ) where 99% of the files are not version-aware, the one and only way to be 100% sure your files are updated, is to hash them individually, and this takes time.

 

But all of this might be explained in a different way too:

- Just pretend the UPDATE button really means this:

"CHECK THE INTEGRITY OF MY INSTALLATION, AND GET THE LATEST VERSION OF EVERY FILE, IF NEEDED"

And it will be all clear to you, why it should be done under your command, and why the option to use it should always be available.

Edited December 1, 20223 yr by virtuali

6 hours ago, virtuali said:

We explained so many times why it's not working like that, and why it's the most reliable update method, and I'm confident that, if you approach it with an open mind, you'll surely understand why it works like that. 

What "version checking" really mean ? What really matters for you: knowing you have some kind of version, or being sure the installation is complete, nothing is missing, down to the last file ?

Because, being happy to see a version number that checks for what is supposed to be the latest version, and sleep safe knowing you have "the latest version", and having a PROPER install, are two completely different things.

You say you would like to have the program "checking the version" while it starting, so it could "grey out" the update button. There are so many reason why, even this is the most common way to handle updates, it's not the best way.

- How do you make a version check ? You do it properly, and check each file one by one, or you just use some crucial files ( like the main .EXE of an app, for example ), so the version check can be made quickly ? And don't forget the FSDT Universal Installer must handle *all* FSDT products, 37 of them, in theory a dedicated user might have all of them installed.

So, the first problem would be, doing the "proper" check, the only reliable one that would ensure all your files are correct and are the latest version, if done at start as you suggested, would take a long time. The more products you have installer, to longer it would take to do just the initial check.

How long, exactly ? Do you think we haven't tested this ? Do you know what is the most time consuming part of the update process ? Is *exactly* the CHECK itself. Hashing thousands of files ( just GSX Pro is 30.000+ files) takes like 95% of the time of the whole update process, which means the updater would spend most of the time it takes to DO the update just *starting*, and that's just to disable the update buttons if an update wasn't needed. I'm not sure how much better the program would be, if it took 3 minutes in which you can't do anything else, only to show you with the right buttons greyed out. What if you didn't want to perform an Update to begin with, and started the installer JUST to read the manual, or JUST to Activate a product or JUST to Deactivate it ? That long startup would have been imposed to you, even when it wasn't required.

Now, of course, I assume you'll surely say "but I have this update made by XXXX, and it start immediately, and it check my version immediately!"

Well, of course it does. Because it's cheating. Or because the application it's made in a way that, for each update, the developers are reasonably sure a certain file will ALWAYS change. The easiest ones are apps with a main .EXE that gets updated with each new version. EXE files have version numbers embedded which can be checked with a standard Windows API call, so checking for updates in this case is extremely easy and very fast. Same for other executables, like airplane gauges, where it's expected they would change at every update. In these cases, it would be enough checking the version of the main .EXE.

So yes, it's quick to do, and it's easy to understand but, it is RELIABLE ? Even normal apps are not made just by the main .EXE, they usually come with many extra files. However, again, extra files of normal apps are usually a bunch of .DLLs, which are also executable, which also supports version checking, so they are also easy and fast to check.

With something like an airplane add-on, things will get more complex. Sure, you got the last version of the .WASM gauge but, what about the other files. What if your aircraft.cfg/flight_model.cfg, etc. gets corrupted, or are removed for any reason, or you make a change to it to play with stuff, then you forgot about it.

A "quick updater", one that only checks a couple of crucial files that have embedded versions won't be able to deal with this situation, it just can't, because it would have to...check each and every file, hashing them one by one, against a known set of hashes, that's the only sure way that, you don't just have the latest version of the main .EXE or the main .WASM file but, instead, you have the latest and correct version of everything, down to the latest file.

And the worse thing is, with an updater that only checks for a few or a single file, showing a version number, without checking the whole set, you have no way to even *suspect* you might have a problem. Sure, your airplane might flight wrong, because you edited something and forget about it, but the updater won't even tell you, because it's not checking every single file.

Now, I'm sure ( as someone already said ) "but if I edited a file, it's my fault, and I would know that", that was just an example. A file might be altered or corrupted for any reason, from hardware failures to interference with other software (antivirus) or just logical filesystem corruption so it might be gone/corrupted the next time Windows will run a checkdisk. It doesn't really matter why a local file might be gone/corrupt, that's not really the point, the point is, a fault-tolerant updater should be able to handle this, and the only sure way is, again, hashing each and every file locally, and compare it with a list of the correct hashes stored on the server, and download anything that is not matching.

Now, I made an example of an airplane, but something like GSX or an Airport scenery, is almost *entirely* made by files that have no inherent version number, like models or textures, .cfg files, .ini files, and there are *thousands* of them in each product. GSX has one main executable, but it's not as if we always update it. Quite the opposite, most of the time other files are being updated, and they might even be more important to how it works than the main .EXE, because the main .EXE ( Couatl64_MSFS.exe ) it's JUST a Python interpreter that connects with the sim through Simconnect. None of the GSX logic is there, what makes GSX work ( or not ), and what usually requires a fix in the logic, is not in the .EXE, but in the many Python scripts that makes the whole program. And of course, we have thousands of textures, sounds, models, xml behaviors, support .BGLs, lots of things that don't have a standard version checking method, and each one of them is important. So, for a product like GSX ( but even airports ) where 99% of the files are not version-aware, the one and only way to be 100% sure your files are updated, is to hash them individually, and this takes time.

 

But all of this might be explained in a different way too:

- Just pretend the UPDATE button really means this:

"CHECK THE INTEGRITY OF MY INSTALLATION, AND GET THE LATEST VERSION OF EVERY FILE, IF NEEDED"

And it will be all clear to you, why it should be done under your command, and why the option to use it should always be available.

The time it took you to write this you could probably have coded a second button called „verify integrity“ which does exactly that and then use the update button instead with a simple check of a single version history file that gets updated with every GSX update, as does *anyone* else in the software business. As of now it‘s just counterintuitive because it works differently from anything a customer is used to. Also please save yourself the „we‘ve explained this *so* many times“-line, what do you think „support“ is if not explaining the same things many times to different people?
To end on a positive note I‘m happy about the constant development of GSX, it‘s working really well now for MSFS and I‘d recommend it to anyone who uses airliners in MSFS.
 

6 hours ago, virtuali said:

We explained so many times why it's not working like that, and why it's the most reliable update method, and I'm confident that, if you approach it with an open mind, you'll surely understand why it works like that. 

What "version checking" really mean ? What really matters for you: knowing you have some kind of version, or being sure the installation is complete, nothing is missing, down to the last file ?

Because, being happy to see a version number that checks for what is supposed to be the latest version, and sleep safe knowing you have "the latest version", and having a PROPER install, are two completely different things.

You say you would like to have the program "checking the version" while it starting, so it could "grey out" the update button. There are so many reason why, even this is the most common way to handle updates, it's not the best way.

- How do you make a version check ? You do it properly, and check each file one by one, or you just use some crucial files ( like the main .EXE of an app, for example ), so the version check can be made quickly ? And don't forget the FSDT Universal Installer must handle *all* FSDT products, 37 of them, in theory a dedicated user might have all of them installed.

So, the first problem would be, doing the "proper" check, the only reliable one that would ensure all your files are correct and are the latest version, if done at start as you suggested, would take a long time. The more products you have installer, to longer it would take to do just the initial check.

How long, exactly ? Do you think we haven't tested this ? Do you know what is the most time consuming part of the update process ? Is *exactly* the CHECK itself. Hashing thousands of files ( just GSX Pro is 30.000+ files) takes like 95% of the time of the whole update process, which means the updater would spend most of the time it takes to DO the update just *starting*, and that's just to disable the update buttons if an update wasn't needed. I'm not sure how much better the program would be, if it took 3 minutes in which you can't do anything else, only to show you with the right buttons greyed out. What if you didn't want to perform an Update to begin with, and started the installer JUST to read the manual, or JUST to Activate a product or JUST to Deactivate it ? That long startup would have been imposed to you, even when it wasn't required.

Now, of course, I assume you'll surely say "but I have this update made by XXXX, and it start immediately, and it check my version immediately!"

Well, of course it does. Because it's cheating. Or because the application it's made in a way that, for each update, the developers are reasonably sure a certain file will ALWAYS change. The easiest ones are apps with a main .EXE that gets updated with each new version. EXE files have version numbers embedded which can be checked with a standard Windows API call, so checking for updates in this case is extremely easy and very fast. Same for other executables, like airplane gauges, where it's expected they would change at every update. In these cases, it would be enough checking the version of the main .EXE.

So yes, it's quick to do, and it's easy to understand but, it is RELIABLE ? Even normal apps are not made just by the main .EXE, they usually come with many extra files. However, again, extra files of normal apps are usually a bunch of .DLLs, which are also executable, which also supports version checking, so they are also easy and fast to check.

With something like an airplane add-on, things will get more complex. Sure, you got the last version of the .WASM gauge but, what about the other files. What if your aircraft.cfg/flight_model.cfg, etc. gets corrupted, or are removed for any reason, or you make a change to it to play with stuff, then you forgot about it.

A "quick updater", one that only checks a couple of crucial files that have embedded versions won't be able to deal with this situation, it just can't, because it would have to...check each and every file, hashing them one by one, against a known set of hashes, that's the only sure way that, you don't just have the latest version of the main .EXE or the main .WASM file but, instead, you have the latest and correct version of everything, down to the latest file.

And the worse thing is, with an updater that only checks for a few or a single file, showing a version number, without checking the whole set, you have no way to even *suspect* you might have a problem. Sure, your airplane might flight wrong, because you edited something and forget about it, but the updater won't even tell you, because it's not checking every single file.

Now, I'm sure ( as someone already said ) "but if I edited a file, it's my fault, and I would know that", that was just an example. A file might be altered or corrupted for any reason, from hardware failures to interference with other software (antivirus) or just logical filesystem corruption so it might be gone/corrupted the next time Windows will run a checkdisk. It doesn't really matter why a local file might be gone/corrupt, that's not really the point, the point is, a fault-tolerant updater should be able to handle this, and the only sure way is, again, hashing each and every file locally, and compare it with a list of the correct hashes stored on the server, and download anything that is not matching.

Now, I made an example of an airplane, but something like GSX or an Airport scenery, is almost *entirely* made by files that have no inherent version number, like models or textures, .cfg files, .ini files, and there are *thousands* of them in each product. GSX has one main executable, but it's not as if we always update it. Quite the opposite, most of the time other files are being updated, and they might even be more important to how it works than the main .EXE, because the main .EXE ( Couatl64_MSFS.exe ) it's JUST a Python interpreter that connects with the sim through Simconnect. None of the GSX logic is there, what makes GSX work ( or not ), and what usually requires a fix in the logic, is not in the .EXE, but in the many Python scripts that makes the whole program. And of course, we have thousands of textures, sounds, models, xml behaviors, support .BGLs, lots of things that don't have a standard version checking method, and each one of them is important. So, for a product like GSX ( but even airports ) where 99% of the files are not version-aware, the one and only way to be 100% sure your files are updated, is to hash them individually, and this takes time.

 

But all of this might be explained in a different way too:

- Just pretend the UPDATE button really means this:

"CHECK THE INTEGRITY OF MY INSTALLATION, AND GET THE LATEST VERSION OF EVERY FILE, IF NEEDED"

And it will be all clear to you, why it should be done under your command, and why the option to use it should always be available.

OK but would it not be possible just to flag up that an update has been released since the user last ran the updater  somehow? So that if no update has been released, and everything was working fine, we wouldn't need to run the updater to find out?

Edited December 1, 20223 yr by jarmstro

Bloody ridiculous reply that…bonkers

2 hours ago, Fiorentoni said:

The time it took you to write this you could probably have coded a second button called „verify integrity“ which does exactly that and then use the update button instead with a simple check of a single version history file that gets updated with every GSX update, as does *anyone* else in the software business.

That's was whole point of that long explanation: why such "simple check" is not at all reliable for an product like GSX. Because the only thing it would really tell you, is when you *tried* to run the update the last time, with no indication whatsoever if it completed successfully, or if some files were missing/corrupted after the update.

What you are proposing, would just be adding an "unreliable update" button alongside the reliable one.  How, exactly, makes that more easier or less confusing than having just one button, the reliable one, which is exactly like it is now ?

Doing something "just because the others do", it's just wrong, each software is different, and I think I explained quite clearly why, different kind of applications, can have various degrees of reliability when doing "simple" updates checks based on few files and saving the last version somewhere, with GSX being a clear example of something that can't be reliably updated this way, because most of the updates relates to files that are not versioned ( =executables ).

Edited December 1, 20223 yr by virtuali

2 hours ago, jarmstro said:

OK but would it not be possible just to flag up that an update has been released since the user last ran the updater  somehow? So that if no update has been released, and everything was working fine, we wouldn't need to run the updater to find out?

I happy to see you see the value of a reliable update and understood my explanation why this method is better.

Here, you are raising a completely different issue, which is not how the update should be performed but, instead, how users could be NOTIFIED an update exists.

In FSX and P3D, we have an update notification inside the sim, but this wasn't always working, for example if the program didn't start in the sim (perhaps an update might fix that), you wouldn't get any notification. 

In addition to that, we listened to many users that didn't want to have the software that runs inside the simulator to include any "maintenance" options that are not strictly related to flight, like update notifications, activation/deactivation, so all of them have been moved to a separate application.

So, right now, the "Release Notes" button, which show all the update history and their release dates, can be used to know if there's an update. I agree THIS can be automated, by saving the last date you ran the update and compare it with the last update release date, so it might be more obvious an update is required.

 

So it is a wrong fake confuse named button because it don´t perform updates almost, but reinstall, check integrity most the time. The problem so, is that you can be mis-updated cause you do not know that you have an update, so add two button, one redownload-check integrity like the "update" button of now, and other greyed if there isn´t new updates or new files to download, or name correctly the actual “update” button. If you call a button update, and you press 5 times in a row, and 5 times it performs redownloads and checks, it is confusing customers, because it is not doing and telling customers what it is doing, it isn´t updating, you don´t have an update and you are not updating despite you press the update button haha.

 

Good software, hope the continuous improvement and development, with a option in GSX displaying an airport map to select the route in various points for the followme car, or to select clicking too a gate or parking position, and to solve the minor glitches in VR, regards.

1 hour ago, peloto said:

If you call a button update, and you press 5 times in a row, and 5 times it performs redownload

This has been explained as well:

https://www.fsdreamteam.com/forum/index.php/topic,26826.0.html

Quote

IMPORTANT NOTE: The Airport Services and Jetways sceneries ZIP files are supposed to be always downloaded, this is normal. Those kind of files are thousands of very small files that compress very well, so we found it was faster to always redownload them as single ZIP files, then check thousands of individual files if they are in need of an update.

Unencrypted versions of FSDT airport files for FSDT sceneries bought on the MS Marketplace will also be downloaded every time, this is also normal.

Always downloading these 3 kind of files resulted in a way faster update than individually check for each one, because of this very specific case of having many thousands of files that are highly compressible, so we just always redownload their ZIP, because it's faster.

We'll add EXTRA text in the Log window, to make it more clear that "always downloading" these specific files is normal, for those that missed the Sticky thread on the forum.

12 hours ago, virtuali said:

We explained so many times why it's not working like that, and why it's the most reliable update method, and I'm confident that, if you approach it with an open mind, you'll surely understand why it works like that. 

What "version checking" really mean ? What really matters for you: knowing you have some kind of version, or being sure the installation is complete, nothing is missing, down to the last file ?

Because, being happy to see a version number that checks for what is supposed to be the latest version, and sleep safe knowing you have "the latest version", and having a PROPER install, are two completely different things.

You say you would like to have the program "checking the version" while it starting, so it could "grey out" the update button. There are so many reason why, even this is the most common way to handle updates, it's not the best way.

- How do you make a version check ? You do it properly, and check each file one by one, or you just use some crucial files ( like the main .EXE of an app, for example ), so the version check can be made quickly ? And don't forget the FSDT Universal Installer must handle *all* FSDT products, 37 of them, in theory a dedicated user might have all of them installed.

So, the first problem would be, doing the "proper" check, the only reliable one that would ensure all your files are correct and are the latest version, if done at start as you suggested, would take a long time. The more products you have installer, to longer it would take to do just the initial check.

How long, exactly ? Do you think we haven't tested this ? Do you know what is the most time consuming part of the update process ? Is *exactly* the CHECK itself. Hashing thousands of files ( just GSX Pro is 30.000+ files) takes like 95% of the time of the whole update process, which means the updater would spend most of the time it takes to DO the update just *starting*, and that's just to disable the update buttons if an update wasn't needed. I'm not sure how much better the program would be, if it took 3 minutes in which you can't do anything else, only to show you with the right buttons greyed out. What if you didn't want to perform an Update to begin with, and started the installer JUST to read the manual, or JUST to Activate a product or JUST to Deactivate it ? That long startup would have been imposed to you, even when it wasn't required.

Now, of course, I assume you'll surely say "but I have this update made by XXXX, and it start immediately, and it check my version immediately!"

Well, of course it does. Because it's cheating. Or because the application it's made in a way that, for each update, the developers are reasonably sure a certain file will ALWAYS change. The easiest ones are apps with a main .EXE that gets updated with each new version. EXE files have version numbers embedded which can be checked with a standard Windows API call, so checking for updates in this case is extremely easy and very fast. Same for other executables, like airplane gauges, where it's expected they would change at every update. In these cases, it would be enough checking the version of the main .EXE.

So yes, it's quick to do, and it's easy to understand but, it is RELIABLE ? Even normal apps are not made just by the main .EXE, they usually come with many extra files. However, again, extra files of normal apps are usually a bunch of .DLLs, which are also executable, which also supports version checking, so they are also easy and fast to check.

With something like an airplane add-on, things will get more complex. Sure, you got the last version of the .WASM gauge but, what about the other files. What if your aircraft.cfg/flight_model.cfg, etc. gets corrupted, or are removed for any reason, or you make a change to it to play with stuff, then you forgot about it.

A "quick updater", one that only checks a couple of crucial files that have embedded versions won't be able to deal with this situation, it just can't, because it would have to...check each and every file, hashing them one by one, against a known set of hashes, that's the only sure way that, you don't just have the latest version of the main .EXE or the main .WASM file but, instead, you have the latest and correct version of everything, down to the latest file.

And the worse thing is, with an updater that only checks for a few or a single file, showing a version number, without checking the whole set, you have no way to even *suspect* you might have a problem. Sure, your airplane might flight wrong, because you edited something and forget about it, but the updater won't even tell you, because it's not checking every single file.

Now, I'm sure ( as someone already said ) "but if I edited a file, it's my fault, and I would know that", that was just an example. A file might be altered or corrupted for any reason, from hardware failures to interference with other software (antivirus) or just logical filesystem corruption so it might be gone/corrupted the next time Windows will run a checkdisk. It doesn't really matter why a local file might be gone/corrupt, that's not really the point, the point is, a fault-tolerant updater should be able to handle this, and the only sure way is, again, hashing each and every file locally, and compare it with a list of the correct hashes stored on the server, and download anything that is not matching.

Now, I made an example of an airplane, but something like GSX or an Airport scenery, is almost *entirely* made by files that have no inherent version number, like models or textures, .cfg files, .ini files, and there are *thousands* of them in each product. GSX has one main executable, but it's not as if we always update it. Quite the opposite, most of the time other files are being updated, and they might even be more important to how it works than the main .EXE, because the main .EXE ( Couatl64_MSFS.exe ) it's JUST a Python interpreter that connects with the sim through Simconnect. None of the GSX logic is there, what makes GSX work ( or not ), and what usually requires a fix in the logic, is not in the .EXE, but in the many Python scripts that makes the whole program. And of course, we have thousands of textures, sounds, models, xml behaviors, support .BGLs, lots of things that don't have a standard version checking method, and each one of them is important. So, for a product like GSX ( but even airports ) where 99% of the files are not version-aware, the one and only way to be 100% sure your files are updated, is to hash them individually, and this takes time.

 

But all of this might be explained in a different way too:

- Just pretend the UPDATE button really means this:

"CHECK THE INTEGRITY OF MY INSTALLATION, AND GET THE LATEST VERSION OF EVERY FILE, IF NEEDED"

And it will be all clear to you, why it should be done under your command, and why the option to use it should always be available.

I apologise in advance but I did not really read your answer in detail, because as the end customer - I don't really care!

You are correct that I am used to using other software that may work in a different way , or perhaps 'cheats'.

I open the Aerosoft updater - it tells me if there are updates

I open the FS2Crew updater - it tells me if there are updates

I open the FBW updater - it tells me if there are updates

I open the PMDG updater - it tells me if there are updates

I think you can see the pattern.

 

Now you are welcome to tell all of the suppliers above that they are doing it wrong.

But as the end user, I prefer their solutions that tell me immediately if I need to run an update. Plus, so far, these all seem to have worked very well and are a lot quicker to check than running the 'update routine' via your platform. I like your products, I'm just not a fan of your updater service.

Sorry!