Autoupdater using ioquake3's approach

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Autoupdater using ioquake3's approach

Re: Autoupdater using ioquake3's approach

by leileilol » Mon May 29, 2017 5:49 am

In OA's case FWIW, i'm not even going to take that autoupdate commit either (as it's upstream). Back in my day, people scorned autoupdates as "taking away rights from the end user", especially when Steam does it *shakes cane at cloud*

It would also cause inconsistencies with repositories downstream.

(also the really scary security bug is already averted by defaulting autodownload off, defaulting openal off and the released version not using renderer DLL modules anyway)

Re: Autoupdater using ioquake3's approach

by wildweasel » Sun May 28, 2017 10:47 am

I'd also consider adding a notice to any script error that reads, "Please ensure that you are running the latest available version from ZDoom.org" or similar. No need for an automatic checker.

Re: Autoupdater using ioquake3's approach

by Rachael » Sun May 28, 2017 10:43 am

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:
zscript-too-new.png

Re: Autoupdater using ioquake3's approach

by Zhs2 » Sun May 28, 2017 9:52 am

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?)

Re: Autoupdater using ioquake3's approach

by Rachael » Sat May 27, 2017 7:53 am

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.

Re: Autoupdater using ioquake3's approach

by Enjay » Sat May 27, 2017 7:48 am

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.

Re: Autoupdater using ioquake3's approach

by Edward-san » Sat May 27, 2017 7:39 am

... 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.

Re: Autoupdater using ioquake3's approach

by Gez » Sat May 27, 2017 5:29 am

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.

Re: Autoupdater using ioquake3's approach

by Trusty McLegit » Fri May 26, 2017 9:03 pm

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.

Re: Autoupdater using ioquake3's approach

by Xaser » Fri May 26, 2017 2:22 pm

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

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

Re: Autoupdater using ioquake3's approach

by Rachael » Fri May 26, 2017 2:21 pm

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.

Re: Autoupdater using ioquake3's approach

by Caligari87 » Fri May 26, 2017 2:03 pm

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.

8-)

Re: Autoupdater using ioquake3's approach

by Enjay » Fri May 26, 2017 12:57 pm

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.

Re: Autoupdater using ioquake3's approach

by JPL » Fri May 26, 2017 11:28 am

Kinsie wrote: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.

Re: Autoupdater using ioquake3's approach

by Rachael » Fri May 26, 2017 1:35 am

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.

Top