Autoupdater using ioquake3's approach

[JPL]

Ryan Gordon just posted some info about a proof-of-concept auto-updater for ioQuake3:

https://github.com/ioquake/ioq3/pull/290

This was especially relevant for that project because they had a scary unfixed security issue for a while, and realized they needed an autoupdater to get the fix properly rolled out. The code he's using for the auto updater is public domain. I haven't looked at it yet to see how suitable it is for other codebases.

GZDoom isn't as multiplayer-centric, but an autoupdater might still be pretty nice to have. It would ensure non-dev users who don't specifically take pains to disable auto-updates always have the latest. It might also make the consequences of people distributing stock EXEs with their mods slightly less painful.

[Kinsie]

I don't think forcing automatic updates, like in this example, is a good idea, for a number of reasons. For example, bouncing back and forth between old and new builds to check for regressions in a mod.

I think automatic checking for updates ala GZDoom Builder is a good idea, but given that the game startup window is implemented in different, separate ways on different operating systems I'm not sure how viable adding it would be.

[Rachael]

I'm really inclined to disagree with this suggestion. The devbuilds in their current form are extremely accessible, and there are cases where experimental code is committed to the master branch and a person may want to revert to an older build (this happens quite frequently after major releases and during refactors).

Even if a person's interest is in release builds (as far as I am aware, most forum users use devbuilds while most people who just lurk stick to releases), GZDoom is extremely mod-designer-centric and Kinsie is absolutely right about bouncing back and forth between releases.

[JPL]

I don't think forcing automatic updates, like in this example, is a good idea, for a number of reasons. For example, bouncing back and forth between old and new builds to check for regressions in a mod.

I should have clarified in my original post: the use case for this is non-dev users (dev builds wouldn't do this ofc), this would only be for official release versions, and there should be an obvious (GUI) way to turn off auto updates.

[Enjay]

I don"t mind the idea of checking and GZDoom telling me that there is an update. But auto updates? No no no no no no thank you. For all the reasons given and more.

Even update messages give me some concern. The last thing I want when all that is on my mind is the need to kill some demon scum is a friendly little pop-up telling me that there is an update.

Frankly, I just don't see the need with a program like GZDoom and i can see it causing more problems for than it would solve. Seems like an idea to fix a problem that doesn't exist to me.

[Caligari87]

This may sound harsh, but it's essentially useless for all but the most casual, can't-be-assed-to-give-a-shit users. I mean, developers work with bleeding-edge code already, Linux users should be using their package manager, users who compiled their own versions are used to pulling code, modders are usually watching for the latest-greatest features and bugfixes, creators who ship standalone games/mods should be managing updates per their project needs, and the average do-nothing-else player is probably already watching the forums for new things to play, so they'll see update crosschatter.

IMO an auto-updater is only good for the users who got some old engine version bundled with Kotaku Reviewed This Mod's Mouthbreathing Moron Starter Pack. As a cranky old bastard, I'd rather not see the engine start catering to that crowd.

[Rachael]

At most, we can put in a button on the startup dialog that says "check for updates" - and that does nothing more than execute the following C++ statement:

Code: Select all

system("https://zdoom.org/Download");

which opens a web browser to ZDoom's download page.

For this reason I will not close this outright, but I don't see a need to do much more beyond that.

[Xaser]

I don't mind such an addition, so long as I can shut it off.

[EDIT] Responding to the suggestion in general -- doesn't make much sense in response to Rachael's post above.

[Trusty McLegit]

There have been talks lately about the possibility of merging GZDoom and Zandronum (see this thread https://zandronum.com/forum/viewtopic.php?f=26&t=8242) but one of the concerns was that zandro users don't want to be constantly updating, so an auto updater could help resolve that issue. Torr is down for it too :

If anybody volunteers to write an auto updater that works on Windows, Linux and OS X, and can handle clients and severs, please go ahead. It would be wonderful to have such a thing, but implementing it is a lot of work and I'd personally rather spend the necessary time and effort on Zandronum itself.

[Gez]

A check for update could make sense in the start window (the one with the IWAD selection box). It would check the net for whether a more recent version exist and show a message in that case. It definitely shouldn't run once the game is actually launched.

[Edward-san]

... and to go forward with the above idea, make it as a button 'Check for updates' in the iwad selection window, then the automatic check on launch could be done only with a CVAR enabled.

[Enjay]

Personally, the more I think about this, the less I like it.

However, if it did become thing, it should be something easily disabled/removed code-side for those indie games that come with a modified engine - particularly those that are little more than superficial modifications like icon changes and so on. Presumably the authors of such games won't want their engines auto-updating to the latest GZDoom.

[Rachael]

I feel the reactions from this are way too mixed. Even if such a thing is beneficial I don't feel that we as a community are ready for it yet. You got GZDoom once from the download page - you know where to find it again later. That's enough.

I want to see how Graf feels about a simple link in the launch dialog that goes to the downloads page (or devbuilds site for the devbuilds) where you can get the latest version - but other than that, I feel like this is way too much for what we use GZDoom for.

[Zhs2]

Automatic updating is distilled overkill for this already stable and completely-founded engine that should theoretically run plain old Doom and derivatives out of the box with absolutely no trouble. It's running mods with this engine that are the main issue here - the most common reason that the engine might freeze, crash, or otherwise quit unexpectedly; it may just be prudent to inform users, when the game exits with an error message (not a crash) while any external game files with modification lumps are loaded (e.g. DECORATE, ZSCRIPT), to check if a newer update of the engine might properly load the game and where to find such updates, after the list of script errors. (GZDoom already informs of where to report a crash when it crashes, right? Kinda?)

[Rachael]

ZScript already requires specifying the engine version if you use newer features. If you attempt to run a newer mod than the current engine's ZScript supports, I see absolutely no harm in alerting the user that their current GZDoom cannot run this file, and may require a recent dev build and/or newer release if one is available.

Currently, all we get is this fancy little message: