Fix autoupdater

[etlegacy]

Fix autoupdater

[ETLegacyTeam]

From: @TheDushan (TheDushan)
Date: 2012-05-07T15:09:26Z

---

To share,
this is about ~98 of code what I am using currently inside my OpenWolf.

[ETLegacyTeam]

From: @IR4T4 (IR4T4)
Date: 2012-11-05T09:14:31Z

---

Update server URL changed to 'updates.etlegacy.com' - we no longer touch zerowing.idsoftware.com at that point

[ETLegacyTeam]

From: @JanSimek (Radegast)
Date: 2012-11-19T22:53:13Z

---

IR4T4 wrote:

Update server URL changed to 'updates.etlegacy.com' - we no longer touch zerowing.idsoftware.com at that point

It was actually changed to aupdates.etlegacy.com :-), but it doesn't matter since there is no updates.etlegacy.com yet. Waste of a commit to fix that typo - just mentioning it here so we remember to fix it when we implement our update server.

[ETLegacyTeam]

From: @IR4T4 (IR4T4)
Date: 2012-11-20T08:52:51Z

---

typo award: IR4T4 :o ... well while checking my typo I've noticed Sys_Chmod isn't available for APPLE. It's a good reason to touch that file ;)

[ETLegacyTeam]

From: @JanSimek (Radegast)
Date: 2012-11-20T10:54:05Z

---

IR4T4 wrote:

I've noticed Sys_Chmod isn't available for APPLE. It's a good reason to touch that file ;)

It is available. Sys_Chmod uses @chmod@ function from stat.h which is on Mac. Or am I missing something?

[ETLegacyTeam]

From: @IR4T4 (IR4T4)
Date: 2012-11-20T11:07:53Z

---

See source:src/qcommon/qcommon.h

<code class="C">
#ifdef __linux__
// TTimo only on linux .. maybe on Mac too?
// will OR with the existing mode (chmod ..+..)
void Sys_Chmod(char *file, int mode);
#endif
</code>

[ETLegacyTeam]

From: @JanSimek (Radegast)
Date: 2012-11-20T14:18:53Z

---

lol, I see. But why does compilation on Mac not fail? It builds fine..

[ETLegacyTeam]

From: @JanSimek (Radegast)
Date: 2012-11-22T16:02:32Z

---

OK, it prints just a warning:

etlegacy/src/client/cl_main.c:1868:4: warning: implicit declaration of function 'Sys_Chmod' is invalid in C99 [-Wimplicit-function-declaration]

[ETLegacyTeam]

From: @JanSimek (Radegast)
Date: 2012-12-31T16:32:44Z

---

I finally managed to figure out how to decode Huffman. Now that it works it doesn't look that complicated (to port), but it took me countless hours and I tried out every single available Huffman decoding library written in C or C++ on github.com.

Anyway, update server now responds with a "print" packet which means we can use the old autoupdate popup box and ET:L doesn't strictly depend on pak3.pk3 anymore (connection to update.etlegacy.com doesn't hang indefinitely).

!etl_updateavailable_not_implemented.png!

All messages sent from ET:L update, master and motd servers are stored in a xml file and will be editable using a web interface by the dev team.

[ETLegacyTeam]

From: @IR4T4 (IR4T4)
Date: 2013-01-02T13:49:59Z

---

I'm still thinking about the auto update feature in combination with *nix distribution packages. I'm pretty sure it'll fail for installs where files have to be written into system pathes (usr/lib & co). We'll fall back into a 2.55/2.60 conflict just with new version numbers ...

[ETLegacyTeam]

From: @JanSimek (Radegast)
Date: 2013-01-02T15:41:00Z

---

If you want to discuss this specific issue further, I created a "forum topic":http://www.etlegacy.com/boards/3/topics/178

[ETLegacyTeam]

From: @IR4T4 (IR4T4)
Date: 2013-01-02T15:54:04Z

---

Signed. I've created a wiki page to unique all info about distribution packages. Let's fill it up ...

http://www.etlegacy.com/projects/etlegacy/wiki/All_about_*nix_Distribution_Packages

[ETLegacyTeam]

From: @JanSimek (Radegast)
Date: 2013-02-08T23:02:55Z

---

Update server is complete. Update process is separated into two stages:

1. "intraversion" updates of Legacy mod and pak3 assets
2. "interversion" updates of client/server binary to a higher one, e.g. 2.70rc1 to 2.71 (afterwards intraversion updates commence)

[ETLegacyTeam]

From: @JanSimek (Radegast)
Date: 2013-12-08T01:01:52Z

---

Separate auto-update code

Client bits of autoupdate code should be shared with server to enable server updates. More importantly, these functions should not depend on the current server connection, so that update downloading can be started from the main menu or even before ET:L is initialized.

Currently, it is only possible to update files located inside @fs_homepath@. There are two ways to update executables:

1. There is an incomplete code which is supposed to download and execute an updater installer. This is a clean way of doing updates on Windows, but it would realistically work only on Windows and Mac. Additionally, we would have to create update installer for each minor release.
2. We could hotswap the ET:L executable if it is user-writeable (http://stackoverflow.com/questions/9162969/how-can-a-c-binary-replace-itself). However, there are several problems with this approach. First, users usually install ET:L in @program Files@ on Windows or in @/Applications@ on Mac OS X, which are not user-writeable, so this would not work. Second, ET:L version would not be updated in the Windows registry or in the App bundle.

[ETLegacyTeam]

From: @jackeri (Jacker)
Date: 2013-12-08T14:18:17Z

---

We could fork the urban terrors updater and create our own updater based on that..

[ETLegacyTeam]

From: @JanSimek (Radegast)
Date: 2013-12-08T14:37:52Z

---

UrT updater depends on Qt Framework and it is a standalone program. I suggested some time ago to create an ET:L launcher in Qt with inbuilt updater, but people didn't like the Qt dependency.

[ETLegacyTeam]

From: @jackeri (Jacker)
Date: 2013-12-08T15:33:43Z

---

Then we will need to roll our own updater. IMHO there is no point in doing a stable release before we have a viable updating system or we will get stuck with the same situation the current vanilla is (people using old versions just to troll around). Linux ofc is it's own little honney pot but we could just do it the Blizzard way -> Launcher that checks for updates & updates files and then launched the game.

[ETLegacyTeam]

From: @rmarquis (Spyhawk)
Date: 2013-12-08T16:17:02Z

---

I'd agree with Jacker here.

As a temporary "cheap" workaround, you can force people to download the latest version manually. In the error message windows above, replace the "Back" and "Reconnect" buttons by a single "Quit" button, which would quit the program and automatically open the website download page.

[ETLegacyTeam]

From: @JanSimek (Radegast)
Date: 2013-12-08T18:34:03Z

---

Jacker wrote:

IMHO there is no point in doing a stable release before we have a viable updating system or we will get stuck with the same situation the current vanilla is (people using old versions just to troll around).

I will have a look if solution number 1 that I proposed above can be implemented quickly just for the version:2.71 stable release. If not, we can do what Spyhawk suggested and we won't even have to touch client code, because the autoupdate server can just send a download with @DL_FLAG_URL@.

Finally, if someone installs ET:L once, he will be able to do it again. If someone doesn't want to update, then we will not be able to make him do it.

Linux ofc is it's own little honney pot but we could just do it the Blizzard way -> Launcher that checks for updates & updates files and then launched the game.
That's what I intended to do with the Qt-based launcher, but it wouldn't solve anything on linux if ET:L was installed through a package manager. Autoupdate will only ever work on linux if ET:L is installed in the user's home directory.

[ETLegacyTeam]

From: @JanSimek (Radegast)
Date: 2013-12-15T00:03:02Z

---

user:Jacker found a solution to our problem on Github and it's called "Mendeley Update Installer":https://github.com/Mendeley/Update-Installer

Checking for updates and downloading them can be handled by ET:L. Installation and permission checks can be taken care of by the updater.

[ETLegacyTeam]

From: @jackeri (Jacker)
Date: 2014-12-15T11:56:19Z

---

The update system works now, it should be tested this week by the devs extensively before we can build the final release versions.

[ETLegacyTeam]

From: @rmarquis (Spyhawk)
Date: 2014-12-19T08:35:59Z

---

Since http://update.etlegacy.com/updater/ has been populated with Linux files, here is some feedback:

When launching etl, the popup windows -can't be closed with "No", it will reopen instantly. You have to select "Yes"- can be closed only when clicking "No" twice. (which isn't necessarily a bug :P)

Here, the update/motd check is done twice:

MOTD: resolving motd.etlegacy.com... resolved to 5.135.27.11:27951
Updater: resolving update.etlegacy.com... resolved to 5.135.27.11:27951
MOTD: resolving motd.etlegacy.com... resolved to 5.135.27.11:27951
Updater: resolving update.etlegacy.com... resolved to 5.135.27.11:27951
execing etlegacy.cfg
execing etlegacy.cfg

And then, nothing happens. In Linux console:

INFO  (6027) Update install completed
INFO  (6027) Starting main application /home/remy/dev/etlegacy-build/mod/etl
INFO  (6027) Started child process 6031
ERROR (6031) error starting child: No such file or directory
INFO  (6027) Updater files removed

It seems the updater looks for the etl binaries in INSTALL_DEFAULT_MODDIR instead of INSTALL_DEFAULT_BINDIR.
Note that etl build is split between etlegacy/mod/ and etlegacy/bin/ (default install paths after using easybuild.sh), but shouldn't be a problem for official binaries that have everything in a single folder.

EDIT: After installing all the files in a single folder, the updater indeed succeeds (both the expected northpole.pk3 and test.txt are downloaded in legacy folder).
The files seem to be downloaded in the background, I've not seen any GTK interface at all.

Also, the /tmp/update-progress file (interface backup) contains some gibberish:

Legacy Updater (ASCII-art edition)                                                                              
====================================
 
We have a nice graphical interface for the <83>Ä^P1ÀëPRRhóK^G^HPè^Q<83>ÿÿ<89>^\$£p]^H^H誧ÿÿ<83>Ä^Pÿ^Up]^H^Hë+ë^F
we can't show it to you :(
 
You can fix this by installing the GTK 2 libraries.
 
Installing Updates...
Update Progress: 50%
Update Progress: 100%
 
Update Finished.  You can now restart ET:Legacy.

[ETLegacyTeam]

From: @jackeri (Jacker)
Date: 2014-12-19T09:50:32Z

---

The updater now works with windows and on linux (tested) and before a release the last thing to decide is that should the update checking be mandatory? At the moment the cvar cl_autoupdate can disable the update checking all together. In my mind this is bad and the cvar should be disabled/removed at least on the client side.

What do other people think about this? People can still press NO to not update but at the least there is a pop up about it every time they launch the game..

[ETLegacyTeam]

From: @adanski (Dragonji)
Date: 2014-12-19T13:16:44Z

---

Jacker wrote:

the last thing to decide is that should the update checking be mandatory?
Yes, please. We don't want to experience 2.55/2.6b situation again, right? :)

[ETLegacyTeam]

From: @rmarquis (Spyhawk)
Date: 2014-12-21T18:47:28Z

---

For the records, both IR4 and myself are in favour of removal. Developers can still disable the update feature at compile time anyway.

[ETLegacyTeam]

From: Mateos (Mateos)
Date: 2014-12-21T18:52:07Z

---

Reason(s)? Because you're just throwing opinion here ^^'

If removal means total removal of the auto-update feature?

[ETLegacyTeam]

From: @rmarquis (Spyhawk)
Date: 2014-12-21T19:13:00Z

---

Mateos wrote:

If removal means total removal of the auto-update feature?

No, removal of the client's ability to disable the auto-update feature with a cvar. The windows popup will be mandatory (update can still be delayed by the client, until he updates).

[ETLegacyTeam]

From: Mateos (Mateos)
Date: 2014-12-21T19:16:51Z

---

Ah alright then :)

[ETLegacyTeam]

From: @jackeri (Jacker)
Date: 2014-12-31T09:05:24Z

---

The update system is now done, works on both client and on server binaries.