Concept: Auto-update

[Omega]

Many programs these days (actually most of mine, probably) have an auto-update function, meaning they are capable of checking for updates and potentially downloading the update automatically. I feel that such a future feature could make updating MegaGlest easier. I realize that the chat can check the version, but to my knowledge, it can't automatically update.

Ideally, there'd be a setting to toggle between three options:

• Automatically update - The simplest option, would check for updates and if one is found, commence downloading and installing it automatically.
• Semi-automatic update - Checks for updates, and if one is found, asks the user if they want to update. If the user agrees, the game automatically updates. This would ideally be the default setting. If the player declines the update, it should not be shown again until the next version is available (storing a line in the configuration INI to remember that), but should have a button to download the update in the settings menu in-game, in case they decline at one point, but change their mind later.
• Manual only - The game does not check for updates nor alerts the user an update is available.

I don't claim to know how other programs perform their automatic updates, though I do realize that finding a way to overwrite the MegaGlest binary and files while they're in use could be problematic. The simplest solution would be to have the automatic updater be its own program, which would be run by MegaGlest for a moment at the start of the game, sending the version number and operating system to check for an update, and if up to date, would close immediately. The fact it's a separate program means that if there is an update, the main executable could be closed to allow the updater to overwrite files that would otherwise be in use (unless there is a better way to overwrite files in use? I wouldn't know).

When updates are available, ideally there would be three kinds of updates stored online. The data and binary would be in separate packages. For a normal user, this could save a lot of bandwidth, but would be too complex. For the automatic updater, it would eliminate the complexity of updating while allowing everyone to benefit from "differential updates". Firstly, there'd be an upgrade package from the last official release, which would only contain the files added/changed in the last release, which would be used only if the user is using the last version. Next would be an upgrade package from three releases back, which would contain the files added/changed in the past three releases, and would be used if the user missed a version, such as an infrequent MegaGlest player. Since only so much is changed in the releases, we can expect it would still be a massive improvement over downloading the full package again. But of course, for those running a MegaGlest older than three releases, the automatic updater would have to download the full package. Linux users have a console command for making folder diffs, while windows users could use WinMerge (WinMerge 3 will support Linux).

The binary would be distributed separately (DLLs would also be bundled with the windows binary), and would be updated every time.

Ideally, the updater would check if both the data and binary packs are available for the specific operating system before notifying the user a new download is available. If there is a missing package (eg, they're using an operating system that we don't make binaries for), they would simply be told there is a new version of MegaGlest available and a link from which they could download it. The option to automatically update would not be displayed.

I realize that many people might not want to use an automatic updater, and for those with technical experience, you could potentially get better performance by compiling the binary yourself, not to mention there's those who use unreleased revisions, and some may simply prefer the manual method. However, the feature would be fully opt-out, and would not replace the chat message stating your version is outdated. Rather, the feature is largely aimed at the (often overlooked) majority of users, many who struggle to even install a mod. MegaGlest is pretty easy to install, but for "not computer people", the bloated installer is often the only reasonable way to update. This would open the ability to have differential downloads -- just the files that have been changed -- for users, while still maintaining support for those which we cannot offer binaries for (for them, there would be pretty much no change).

Admittedly, this feature wouldn't help the devs at all, nor most of the large members of the community, who are more than capable of doing the manual work, but could be a big difference in helping the unspoken majority. Keeping MegaGlest up to date is necessary for online play, so ensuring that keeping it up to date is as easy and manageable as possible should be an objective.

[tomreyn]

I think the idea of providing some kind of 'automatic update' is a good one for platforms which have no native, open and user friendly means to handle this themselves, i.e. Windows and, to my knowledge, OS X. So it could be nice to default to On for an automatic upgrade option on these platforms.

The way I'd suggest to implement it in the first step is much simpler than the one you describe, though. When starting up, if online update checks are enabled, the game spawns a background thread which communicates with a (yet to be developed) interface on the master server or website. The game checks with it for availability of an upgrade, providing information on the currently installed version and platform, which is then responded to by a machine interpretable representation of either 'no update available' or 'update available, download location is ...'.

Example request (transmitted via HTTP POST):

Code: [Select]

interfaceversion=1
gameversion=3.5.3-beta2
ostype=2
osarchitecture=2
osversion=5.1

InterfaceVersion refers to the version of this web query interface, and allows for later upgrades to it. GameVersion is self-explanatory, it's important here to work with a version scheme which allows error prone comparisons of version numbers, i.e. it must be detected that 3.5.3-beta2 is older than 3.5.3 but newer than 3.5.3-dev, and that 3.6.0.4 is newer than 3.6. Alternatively, we could switch to a different version naming scheme as needed. The problem of correctly interpreting version schemes has been solved before by e.g. Debian GNU/Linux and we could and should just copy existing solutions.
OSType 2 would mean Windows (1=Linux, 2=Windows, 3=OS X, 0=Other).
OSArchitecture 2 would mean x86_64 (1=i386, 2=amd64, 3=armel, ...) See http://popcon.debian.org/ for some hints. Alternatively, this information could be used to create more specific OSType's which would then make OSArchitecture superfluous.
OSVersion obviously refers to the operating system version.

The online interface should then respond with something along the lines of this:

Code: [Select]

updateavailable=1
gameversion=3.7.1
download=http://example.org/download?ostype=2&osarchitecture=2&osversion=5.1&gameversion=latest
info=http://example.org/downloads.html

UpdateAvailable states, as a boolean, whether an update is available for this platform based on the currently installed version (1=an update is available, 0=an update is not available). If updateavailable is false (0) then all other response values may empty.
GameVersion is the latest game version available for this platform.
Download points to the download location of the latest update; HTTP 301 and 302 Location redirects are be allowed (and need to be followed by the client), the latest keyword points to the latest available version available for this platform (and basically causes the version check to be repeated on the server), alternatively, the gameversion could be provided as a specific version number such as "3.7.1" here.
Info is a human friendly representation of available downloads, changelogs etc. Currently, this would probably point to http://megaglest.org/download.html

If updateavailable=1, the game thread would create a lock file which contains the information returned by interface discussed above. A hook would be added to every game menu which would check whether this lock file exists. If found, a prompt would display, informing the user that an upgrade is available, offering to download it, get more information on it, or to 'remind me later'. If the user chooses to download it, the game will shut down, spawning an OS handled request for the given download location as it exits (this should result in the users' default web browser starting up, offering to download the file the download location points to). If the user chooses to get more information, the game will shut down, spawning an OS handled request for the given info location as it exits (this should result in the web page at the info location to be rendered in the users' default web browser). If the user chooses to be reminded later, the prompt closes and another lock file is created, which will prevent further update prompts during the runtime of this game. This lockfile is removed whenever the game starts up, causing prompts to appear again unless disabled generally.

The process described above does not support bindiff / delta style upgrades (I assume that's what WinMerge does), but I think offering this for all supported platforms would mean too much overhead at this time. Producing releases already involves a lot of work now, and we don't want to make it even more by having to provide binary diff information for every upgrade on any platform. If our minds change on this, an updated version of this interface could allow for bindiff style updates.

This process does also not depend on an external application (other than the users' web browser) for updating MegaGlest. If there was such an updater application then it would be unclear how this application would be updated itself, it would also make the process more complex and thus error prone, so I do not recommend it at this time.