Auto-Update Feature

Feedback on past, current, and future development.
Wolvman
Posts: 23
Joined: 30 Apr 2012, 15:57

Auto-Update Feature

Post by Wolvman »

Would there be any chance of an auto-updating feature being added to the launcher? As in when you load up the launcher it can be set to automatically look for, download, and install the latest OpenMW build (Perhaps with a "Nightly Build" option as well) over top of the current build if it is more recent. It would be nice to have a simple, streamlined way of staying up-to-date without having to involve a web browser.
Enetheru
Posts: 5
Joined: 29 May 2015, 05:41

Re: Auto-Update Feature

Post by Enetheru »

lol, windows problems.

You should have a look at package managers for windows, might improve your overall experience.
Loriel
Posts: 179
Joined: 28 May 2015, 00:44

Re: Auto-Update Feature

Post by Loriel »

I suspect the attempt to update would fail on Windows, because files would be in use for the launcher - at best you would probably be in a "reboot your computer to complete the update" situation.

Also I wouldn't recommend overwriting a "stable" version with a "nightly" version - I run both, switching between them as necessary because the nightlies do sometimes regress.

Possibly the launcher could include a version check, to notify the user if there's a newer version available. Though at present there's a lot of other things I would consider to be of higher priority.

Loriel
Naugrim
Posts: 172
Joined: 08 Jan 2016, 01:32
Location: Spain

Re: Auto-Update Feature

Post by Naugrim »

Maybe there's a middle-ground scenario.
If only the installed allowed to extract the files or there was a .zip distribution, it would be easy to build a script that:
1. Checks current version:
1.1 For Stable: using GitHub releases API
1.2 For nightly: browsing the http repo with HTTP calls.
2. Download, extract and replace the files in the installed folder

The launcher could have a button that closes itself and launches the script in a separated process to avoid problems with 'files being used'.

wtyt?
Loriel
Posts: 179
Joined: 28 May 2015, 00:44

Re: Auto-Update Feature

Post by Loriel »

I think that addresses my main concerns.

Just need to make it robust enough to recover from a failed update, rather than leaving a non-functional installation in place. Maybe install into new directory, then delete the old directory and rename the new one on successful completion (assuming that is possible without breaking shortcuts etc).

Loriel
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Auto-Update Feature

Post by psi29a »

If you code it, they will come. ;)
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Auto-Update Feature

Post by Chris »

Naugrim wrote: 31 Aug 2017, 15:08 2. Download, extract and replace the files in the installed folder
That could be a problem depending on where it's installed. On most systems, users don't have write access to program locations, it needs admin/root privileges, and the launcher shouldn't have admin/root privileges. Windows further complicates this by having "virtual folders" for apps in Program Files; the app will see that it can write to its otherwise write-protected folder, but it's actually writing to a different location and the app accesses the contents of the two locations (similar how openmw 'merges' the contents of multiple data paths). The original files are unchanged, and other apps don't see the changes.

Windows also doesn't allow modifying executables that are currently running, so the launcher can't directly update itself.
Naugrim
Posts: 172
Joined: 08 Jan 2016, 01:32
Location: Spain

Re: Auto-Update Feature

Post by Naugrim »

I have been doing some digging, by impression is that it's harder that it seems, but not for technical reasons,this is more of a "what features we want to provide".
Disclaimer: all I say here is for Windows, some things could be reused, but not much.

First, if you only want to use stable and some automatic self-update, that is, have the same experience as let's say a Ubuntu user. Chocolately get the job done (provided you can install in "Program Files" as Chris points out).
It makes the upgrade process really simple, but honestly, unless the self-update is provided by the launcher there's not much value for a normal user. Chocolately is not integrated in the launcher and requires you to run commands manually.

So, going back to how to integrate stable versions update in the launcher, I was thinking...
1. Invoke `GET https://api.github.com/repos/OpenMW/ope ... ses/latest` to get the last release and version number from the tag
2. Compare version to some config file or use the Windows registry keys. I've seen that CHANGELOG.txt begins with the file version but seems too dirty.
3. if (there's a newer versions)
get the download url for the correct "asset" attribute and run the silent installer (/S for windows)
display that there's a new version and enable an option to update
else
display that this is the "current" version
Outside file permissions, the only problem here is that GitHub's API anonymous usage has a limit of 60 calls, per hour, per IP. Don't think it should be a problem unless there are a bunch of users behind some proxy...but still I think it should be considered.

Now, dealing with file permissions. This is my thinking, taking into consideration I don't have much experience in this things.
The "update" option should copy a separate "updater.exe" to a temp dir, launch it passing as argument the download url and close the launcher.
Ideally, the "updater" should guide the user with some wizard with options like:
· New installation: in case the user wants to keep old version. In this case, just download the installer, run it as-is and close the updater. If the user chooses to install in the same directory as the current installation, it's HIS/HER problem!
· Replace: this the tricky part. To be 100% nice we should check if the user has more than one installation (can be done via windows registry) and if more than 1 is found, ask a nice "Are you sure you want to delete all?". If the user confirms or only 1 installation is found, just run the installer and then the uninstaller silently (/S).
I bet Thunderforge would explain this much better with some cool mock-ups :P

Now, for nightly builds, the url provided by ACE is always the same and I haven't seen any way to check the version. So, dead end here.
Maybe add a generated JSON with the version and tag number to replace the usage of GitHub API by a similar GET call?
However, important thing here. Nightly installer does not include the commit tag in the installation directory, so in this case there's no failsafe process. When selecting "Replace", it should run the uninstaller first.

In all scenarios, afaik, config files are not tocuhed.
densm27
Posts: 24
Joined: 02 Jun 2014, 18:34

Re: Auto-Update Feature

Post by densm27 »

Naugrim wrote: 31 Aug 2017, 18:42 Now, for nightly builds, the url provided by ACE is always the same and I haven't seen any way to check the version. So, dead end here.
Don't know if it's helpful or not, but you actually can get commit tag for nightly builds. Ace is providing not only a link to the installer, which is always "OpenMW-latest-winXX.exe", but also to an MD5 sum file, and inside it there is installer name with a tag, like "OpenMW-8c6a8ca-win32.exe". I made a program some time ago that was checking latest version against previously downloaded, and installing new version if there is one.
User avatar
Thunderforge
Posts: 503
Joined: 06 Jun 2017, 05:57

Re: Auto-Update Feature

Post by Thunderforge »

Instead of having the app replace the files, you could just have the launcher download the installer, verify the integrity, launch the installer, then quit the launcher. The user then lets the installer do its thing. I do that with one of my other apps and it works quite well.
Post Reply