GSX Pro Update function in the Installer?

[peloto 213]

45 minutes ago, chickster25 said:

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! 

Yes, I am talking with Microsoft and Asobo for when we have an update, we better download all W11 files again and again and all the 128GB of FS2020 each time I start each day the PC or MSFS, and I redownload all again just in case, to be sure there is no an update forgotten, and without informing me they if there isn´t updates to update, and do not "waist" my time, perfect and normal. I am very happy pressing the update button to update the existing files with the same "update" already installed and downloaded all days, nothing I love more than download and wait during several hours and hours staring to the screen updating, my un-confessable hidden hobby.

[virtuali 4,421]

1 hour ago, chickster25 said:

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

They are not doing it "wrong", they are doing it less reliably that we do, in a less fault tolerant way. You are welcome to try the following, using any of these updaters:

- Go inside the install folder, and mess up intentionally with any files, like removing them or edit them.

- Run the updater, is still telling you have the latest version, and nothing there will make you suspect you have a problem.

And before you say "but I messed up the files myself, it's my fault!", this was an example to allow you to TRY this experiment. Files might be missing or wrong for multiple reasons, like file corruption, antivirus interference, network problems that caused a partial download, and you have no way of knowing that, that's way a reliable updater should be able to check that for you.

Yet, those updaters will all telling "you have the latest version", when you clearly haven't, because your "last version" is in fact crippled, with now way for you to know that.

- Now try the same with our updater, and all your missing/messed up files will be restored exactly as they are supposed to be, without even worrying *which* is the latest version. Does it matter, when you can be sure you *do* have the latest version, in all its integrity ?

 

1 hour ago, chickster25 said:

But as the end user, I prefer their solutions that tell me immediately if I need to run an update

You are now confusing the actual update PROCESS, with the update NOTIFICATION, which is a completely different thing, and it's the way to TELL you "there's an update".

As I've said already, we now have the "Release Notes" button, with dates, so you can use that for the time being, to know if there's a more recent update available. But as I've said in my last post THIS procedure can be improved, the way you are *notified*, not the way the update is *performed* , which works perfectly fine as it is now.

 

1 hour ago, chickster25 said:

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 think I have explained quite clearly, you can't have update check speed and full fault tolerance at the same time. We just decided to err on the side of reliability, and I also I think to have explained quite clearly, why a fast update check, for example made on the .EXE or some Gauges, wouldn't be very effective with GSX, where any of the 30k files that comes with it might potentially cause troubles, if they are not the right version.

Edited December 1, 2022 by virtuali

[AnkH 2,262]

Discussions on this topic is waste of time and effort, as Umberto stubbornly thinks that his approach is the way to go. It HAS indeed one big advantage he also never gets tired of pointing out: if you modify one single file of the GSX PRO installation, clicking on "update" will correct this. Preventing issues with user that modified files (purposely or by accident) and complaining that the product does not work as intended. 

BUT, what Umberto simply ignores, is the fact that this is not very often the case and in contrast, it even makes certain aspects even more a pain in the *, example given the default gsx config file for FSDT LSZH that is included but total rubbish. Each time you run the "update", this annoying file is redownloaded and added into the folder, no matter if you have a custom gsx config file for LSZH elsewhere. And if you do not think about deleting it, you have two config files active the next time you use LSZH. 

[virtuali 4,421]

7 minutes ago, AnkH said:

Each time you run the "update", this annoying file is redownloaded and added into the folder, no matter if you have a custom gsx config file for LSZH elsewhere. And if you do not think about deleting it, you have two config files active the next time you use LSZH. 

That's no longer a problem with the latest version, because as part of supporting the new SU10 Navdata, we also added the ability to have multiple .INI profiles for each airport, even of the same ICAO, and after you selected your preference once, your choice is SAVED in the Couatladdons.ini file, which is never touched by the updater, and will contain the names of your preferred profiles for each airport.

If you made a custom profile for an FSDT airport you'd rather use instead of the official one, it's enough it's named differently than the FSDT version ( which is clearly named LSZH-FSDT.INI for easy identification ). When you have two profiles that both matches the airport, the first time you open the GSX Airport configuration page, you'll be ASKED which one you want to use, and your choice will be SAVED as a GSX preference, so the file downloaded by the updater will not be used anymore.

Edited December 1, 2022 by virtuali

[AnkH 2,262]

9 minutes ago, virtuali said:

And before you say "but I messed up the files myself, it's my fault!", this was an example to allow you to TRY this experiment. Files might be missing or wrong for multiple reasons, like file corruption, antivirus interference, network problems that caused a partial download, and you have no way of knowing that, that's way a reliable updater should be able to check that for you.

Do a risk based approach and do the maths and you will realize that above explanation makes sense, but is so rare that annoying 90% of the customers with this process should be weighted more. 

In my 25+ years of simming with tons of addons I can not remember one single case where it was not entirely my fault that a manually modified file led to issues. And come on, even then, in the timeframe of one year (example), how many times will one of the reasons you stated corrupt the installation of an addon vs. how many times you get annoyed by this idiotic update procedure of yours? Since the release of MSFS NONE(!!) of my addons broke down due to modified files or any other reason you stated, but at least once a week I get annoyed by your updater. 

Do the maths, what could potentially be worse for us customers? Only one conclusion can be drawn here...

[GEKtheReaper 364]

@virtuali I apologize but while I do enjoy your work (thank you) I can't understand why you would need to implement other update methods than all others do!?

Some of your customers have slow or limited bandwidth and performing all those checks and downloads and stuff...is simply not the way to go (it might be the safest...but it's not the greatest).

There are SW out there that need incremental updates to get to the latest version (so you install the SW, then SP1 -> check -> SP2 -> check -> SP3....).

Your GUI does not inform you about the current state (version) of the product, no'r does it gray out the update button, nor does it say if it has done anything.

[virtuali 4,421]

1 minute ago, AnkH said:

Do a risk based approach and do the maths and you will realize that above explanation makes sense, but is so rare that annoying 90% of the customers with this process should be weighted more. 

It's far more common that you think.

Antivirus can mess up with files easily, firewalls can prevent their download, or  (even worse) let pass some files and block others, causing a mismatch of versions and, last but not least, it's even possible that Cloudflare caching might not be updated, which means we download a file, and we get an outdated version. In fact, most of the issues happen without the user even knowing or being in any way responsible, and that's precisely way a reliable updater should be able to deal with accidents.

 

5 minutes ago, AnkH said:

Since the release of MSFS NONE(!!) of my addons broke down due to modified files or any other reason you stated, but at least once a week I get annoyed by your updater. 

You are giving your own limited view, I speak with many years of supporting users, so my view is based on a way more ample sample of things that really happens to users, and the vast majority of them (the ones who contact support by email) are completely unaware of what kind of interference antivirus can pose, what a firewall really does, how ExFat/Fat32 filesystem so popular with external drives are so much less fault tolerant than NTFS to file corruption (for example when the PC crashes) because they are not journaled. All of this really happens in the real world, that's why we have an updater that is almost invariably capable of at least TELLING if anything's wrong with a file.

[virtuali 4,421]

13 minutes ago, GEKtheReaper said:

Some of your customers have slow or limited bandwidth and performing all those checks and downloads and stuff...is simply not the way to go (it might be the safest...but it's not the greatest).

The actual check, which is what takes the longest time, is NOT made by comparing each file with each file on the server, that would waste a considerable amount of bandwidth it we tried to do that.

Only a *small* LIST of files and hashes is being downloaded from the server, and over this "directory", the actual checks are made completely locally, with no data exchange over the internet. And it's not just that: even this "directory" file is cached locally and downloaded only when it has been updated so, even if it's small, we do not downloaded it needlessly.

If a file needs to be downloaded, it will just that file that will be downloaded, that's precisely what "checking all files individually" achieves.

That is, with the one and only exception of the jetway replacement files and the Airport service files, which are 30MB each, but here we are saving several minutes each time, so it IS faster this way.

 

Quote

Your GUI does not inform you about the current state (version) of the product, no'r does it gray out the update button, nor does it say if it has done anything.

I think I explained quite clearly why, in order to present you with the "current state" of the product, the updater would have to do the long check before it started, making it unusable for several minutes, even in case you didn't want to update everything, but doing other operations, like checking the manual, activating/deactivating, unlinking, get your keys, etc.

I also explained quite clearly, why preventing you to use the Update button, just because we "assumed" the last update when fine, and no files has been lost/altered in the mean time is wrong, and it can cause issues to a product that, compared to others, it NOT made with a single executable (or a bunch of executables) that changes with each update, so they can be checked very easily and very fast.

Edited December 1, 2022 by virtuali

[jarmstro 2,402]

6 minutes ago, virtuali said:

The actual check, which is what takes the longest time, is NOT made by comparing each file with each file on the server, that would waste a considerable amount of bandwidth it we tried to do that.

Only a *small* LIST of files and hashes is being downloaded from the server, and over this "directory", the actual checks are made completely locally, with no data exchange over the internet. And it's not just that: even this "directory" file is cached locally and downloaded only when it has been updated so, even if it's small, we do not downloaded it needlessly.

If a file needs to be downloaded, it will just that file that will be downloaded, that's precisely what "checking all files individually" achieves.

That is, with the one and only exception of the jetway replacement files and the Airport service files, which are 30MB each, but here we are saving several minutes each time, so it IS faster this way.

As I have said, a simple flag somewhere to say that an update has been released is all that is required. In use, if a file has been altered or corrupted this will be apparent to the user,  who can then run the very thorough updater to make the necessary repairs? What's the big deal?

[virtuali 4,421]

6 minutes ago, jarmstro said:

As I have said, a simple flag somewhere to say that an update has been released is all that is required.

One thing is the update PROCESS, another is the update NOTIFICATION, they are two completely unrelated things, and I said multiple times, we can probably improve this and automate the relationship with the update Release Notes and their dates, to compare against the latest time you ran the update. THIS can be done.

 

6 minutes ago, jarmstro said:

In use, if a file has been altered or corrupted this will be apparent to the user,  who can then run the very thorough updater to make the necessary repairs? What's the big deal?

That's what I'm trying to explain: most of the time users don't have any means to realize something's wrong, how they are supposed to, with over 30K files JUST for GSX Pro ? That's why the updater does: it ensures the product integrity, always.

Again, nothing to do with the way you are NOTIFIED if an update exists. That can be done better, but the actual update process is working fine as it is.

Edited December 1, 2022 by virtuali

[jarmstro 2,402]

6 minutes ago, virtuali said:

Again, nothing to do with the way you are NOTIFIED if an update exists. That can be done better, but the actual update process is working fine as it is.

Eureka! We are at one. It's the NOTIFICATION that we want.

[chickster25 153]

Here is an idea

How about one button that says "VERIFY" and that will do the same process that the update does now, that is check all the files.

Then have another button for update or just a simple notification to let the user know what version they are on and the current version

Simples!

I think the problems are because the button says UPDATE, but it is doing both an UPDATE & VERIFY or sometimes just a VERIFY if there is no update - so it is a bit misleading when you are clicking on an update button

Edited December 1, 2022 by chickster25

[AnkH 2,262]

32 minutes ago, virtuali said:

It's far more common that you think.

So, that is why all  those addon publishers have a constant flow of users running into issues because of their totally bad update process. No wonder forums are full with issues that turn out to be modified files of an installation, NOW I understand /sarcasm off.

Or in other words: bullsh*

[virtuali 4,421]

Just now, chickster25 said:

How about one button that says "VERIFY" and that will do the same process that the update does now, that is check all the files.

Then have another button for update or just a simple notification to let the user know what version they are on and the current version

As I've said already, the 2nd "quick" Update you are proposing, cannot possibly tell if you have the current version, without running the Verify check first so, no reason to have a reliable button and an unreliable one in the same page.

[chickster25 153]

3 minutes ago, virtuali said:

As I've said already, the 2nd "quick" Update you are proposing, cannot possibly tell if you have the current version, without running the Verify check first so, no reason to have a reliable button and an unreliable one in the same page.

But your reliable button doesn't tell me if I need to update or not- I have to run it just in case there is a button and I dont know if it did update or not because it takes just as long.

So in fact,your reliable button is quite unreliable in terms of providing information to the end user