Add update checker to launcher

[GeckoEidechse]

To prevent players from running into issues due to using older versions of the client, Northstar launcher should do an update check every time it is launched.

A possible setup would having a file called VERSION.txt inside the release zip that contains the current version. That value is then compared to and endpoint on master server (like /client-version) and a warning is displayed if the versions don't match up.
Warning should however be skippable.
A failed connection to master server should also display a warning but that too should be skippable (to prevent DoSing all clients by just taking down server).

Additionally by exposing the newest/desired client version via master server, 3rd party master servers could also request older clients if they themselves are not up to date (due to breaking changes).

[0neGal]

As I mentioned in the Northstar/#45 issue, I am working on a launcher/updater for Northstar, adding some way to know the versions of the zip would be very helpful on my end, currently I've no real way to determine the various versions compared to checking md5sums or similar.

Rather dumb, and not ideal...

[0neGal]

For reference, since the other issue had a screenshot of the other Northstar updater, here's one from mine, I of course named it Viper, I thought that was pretty clever.

[Alystrasz]

Looks sick!
Where can we contribute to your code?

[0neGal]

Currently nowhere, it's a private repo (soon to be public ofc), it'll be over on 0neGal/viper

Another thing I'd love to maybe do in the future, that being an easy to way VPK mod, auto backup of files, GUI for r1_english etc, the only thing missing for that to be truly easy to use is a CLI VPK extractor, I don't know of one for that, as for repacking there's RSPNVPK, which works on both Linux and Windows.

[pg9182]

I also threw together a quick Inno Setup 6 script when it was released: https://gist.github.com/pg9182/38180ce6064ebcec283b4b62b29b3cd7.

[0neGal]

As for the shell script, it's quite simple and I put the below together in literal minutes

#!/bin/sh

ZIPURI="$(curl --silent \
	"https://api.github.com/repos/R2Northstar/Northstar/releases/latest" |
	grep '"browser_download":' |
	sed -E 's/.*"([^"]+)".*/\1/')"

wget "$ZIPURI" -O "northstar.zip"
tar xfz "northstar.zip" "$GAMEPATH"
rm "northstar.zip"

I've not tested the script, but if I made it properly in the first try, running it with $GAMEPATH as an env variable equal to your games path it should download the latest zip and extract it, keep in mind this'd replace your ns_startup_args.txt as well. But you can just add --exclude="ns_startup_args.txt" to the tar command.

Of course this is only for Linux/Nix system unless you're running Bash/Bourne Shell on Windows, which isn't completely unlikely considering how niche this whole thing is to begin with...

[ghost]

I'd say that it should automatically check for updates every launch. Github API is just one GET request and it could just automatically download and install updates. I've already written one over at wozniak/ns-updater

[VITALISED]

A couple months back I had tinkered with this idea. The plan was to use a simple portrait form app to pull the latest files from the repo and add some URI stuff for one-click mod installs, whilst mod updates could feasibly still be done from the frontend vpk.

Here is what I drafted back around September/October

[BobTheBob9]

just getting to this issue, would love to do this

As I mentioned in the Northstar/#45 issue, I am working on a launcher/updater for Northstar, adding some way to know the versions of the zip would be very helpful on my end, currently I've no real way to determine the various versions compared to checking md5sums or similar.

Rather dumb, and not ideal...

specifically i'd be against taking md5s and stuff since it could limit modding, realistically just need to store version information with each release and only try to update if new version is available
i also think servers individually need to store version info so we can mark outdated ones as being outdated, and stuff like that too, overall really not sure how to handle servers updating especially since it'll really always require a restart, clients are much easier to handle

[nanovad]

If you could somehow build the applicable Git tag into the program, you could add a simple -version parameter to the launcher exe that just spits out the version and exits.
Run that in the updater app, compare to available GitHub releases, and you're all set.

[Alystrasz]

Could #10 help to get one's server version?

[GeckoEidechse]

[...] overall really not sure how to handle servers updating especially since it'll really always require a restart, clients are much easier to handle

I'd argue dedicated server updating should be obligation of the person hosting it. Expose some endpoint for them they can use to see current version. Then they could add their own scripts on top that polls Github for new releases, upon which it shuts down the current server and spins up new version with the update.

No need to overthink things :P

[BobTheBob9]

ok so, my current thoughts on this are that updating shouldn't be an entirely automated process, it'd likely be easier to have masterserver tell clients/servers on auth/heartbeat respectively that they're running an old version and possibly fail auth if they're down a non-patch version, and then give users the option to update through an updating program that'd be shipped alongside main files
this is mainly just because of the potential to overwrite modified files and stuff, it's hard to know what people are going to change so i think it'd be best to just let them choose when to update

the other thing is that any kind of updater will either need to be exclusively commandline, or have both gui and commandline versions, so headless servers can be supported

[0neGal]

this is mainly just because of the potential to overwrite modified files and stuff

I was considering this being an issue of an in-game updater...

the other thing is that any kind of updater will either need to be exclusively commandline, or have both gui and commandline versions

Viper would have both of course. Whether or not Northstar will have an official updater decides the fate of my program really, lol. I'm all for an official updater however...

[BobTheBob9]

this is mainly just because of the potential to overwrite modified files and stuff

I was considering this being an issue of an in-game updater...

the other thing is that any kind of updater will either need to be exclusively commandline, or have both gui and commandline versions

Viper would have both of course. Whether or not Northstar will have an official updater decides the fate of my program really, lol. I'm all for an official updater however...

if it's no trouble could you give me access to the viper repo or make it public? would love to give it a look if it's something that's already somewhat functional

[0neGal]

if it's something that's already somewhat functional

It literally only has the UI and is able to extract the zip in the path of your game, since I've been busy lately... But then again I only really need to add an option of excluding files, and then everything else is smooth sailing... I'll keep you updated on the repo visibility, unless of course you wanna experiment with the few things it can do at the moment...

[nanovad]

If there's a manifest with version information, clients could have a graphical launcher that notifies them when there's an update available. The user could then skip the update and launch Northstar normally, or run the update, which would:

• Download the zip
• Extract the zip to AppData or something (non-destructive)
• Compare hashes of new files to existing ones
• Notify the user that they have a modified installation, or otherwise start the update
• Copy files from the update zip to the installation dir

If done this way you could also have an advanced mode where you can select granularly what files you want overwritten by the update zip.
Imo this will give clients the most flexibility in choosing how and when to update. I can try putting something together if anyone's interested in seeing this as a proof of concept.

For servers, you could just have an update CLI that, when run, warns server operators that it's about to nuke their install. I imagine most server ops would be able to write post-install scripts that restore their modded game if need be.

[0neGal]

Compare hashes of new files to existing ones

Version numbers would be far better... We wouldn't be able to easily tell if one version is outdated or not, just that it's not the same.

you could also have an advanced mode where you can select granularly what files you want overwritten

And by default client ns_args shouldn't be overwritten, in my opinion.

[nanovad]

Compare hashes of new files to existing ones

Version numbers would be far better... We wouldn't be able to easily tell if one version is outdated or not, just that it's not the same.

I agree, version numbers should be the primary method of comparing two versions. I was referring to using hashes to identify which files were modified since a clean install. You could ship an md5sums.txt with releases so that later update passes could compare what the hashes should be to what they actually are. If there are any mismatches, the user has modified files, and you show a warning in the interface.

[0neGal]

I was referring to using hashes to identify which files were modified since a clean install. You could ship an md5sums.txt

Actually not a bad idea... Layout of such could just be a space separated file,

MD_SUM_HERE FILE_NAME_HERE
ANOTHER_SUM ANOTHER_FILE_NAME

and so on, so it'd be something like:

e350f497f88705d4adf776dec695b538 NorthstarLauncher.exe
9c26d7ca3de888076e6025b23d300b4b Titanfall2-unpacked.exe
.....

that snippet isn't from the latest release but you get the gist...

[nanovad]

Exactly! I think that format is pretty standard among hashing tools, so it'd be preferable to home-rolling a format.

I guess the bigger question here is: what sort of launcher experience should end users get?

[0neGal]

I guess the bigger question here is: what sort of launcher experience should end users get?

In my opinion something that's similar to the screenshot of my WIP launcher would be easy enough to use, perhaps a few tiny easy to follow messages when some things aren't set right etc...

For reference, since the other issue had a screenshot of the other Northstar updater, here's one from mine, I of course named it Viper, I thought that was pretty clever.

As for dealing with overwriting files, I'm not sure much more than having a "Overwrite startup arguments on update" is needed, most users who need a GUI probably won't be having many things that could be overwritten.

However an advanced settings panel for ignoring specific files could also be considered... As for the CLI part of my launcher I'll just have --update, --setpath, --gamepath (for overwriting the saved path once), and --launch which could be followed up with --launch=vanilla/--launch=northstar but it would default to Northstar.

The point of --setpath is that it sets the path saved in your config folder (AppData on Windows, .config/XDG_CONFIG_HOME by default on Linux) within a file called viper.json so that you don't have to specify it each time your launch Viper or run the CLI, albeit for automating things you may still just want to use --gamepath

[zbot473]

I've written the code for checking updates from github. I think the best way is the version.txt file but we can also do it through the master server

[0neGal]

I've gotten to a point where I'm comfortable making Viper's repo public, and hence it is now as such, it's missing a few things, such as a nice looking icon, the ability to not overwrite certain files (i.e ns_args) and given I've only tested it on my system who knows what kind of jank might occur.

Which is all why I've yet to make release builds available, unless you want to build them yourself that is. Feel free to test it however.

It's also missing documentation/comments and I need to clean up some of the code as well, but besides that it's working quite well and looks quite neat if I do say so myself (definitely not biased...)

[pg9182]

If this is implemented, there needs to be a way to disable it for the headless servers (especially the containers).

[Alystrasz]

On Viper (with GUI and CLI), update process is not automatic and must be triggered manually.

[GeckoEidechse]

Between Viper and VTOL auto-updating Northstar and the planned integration with r2modman I think it makes more sense to put an auto-update feature into a 3rd or 1st party manager, rather than doing it directly from within Northstar.

Since the creation of this issue, Northstar now has version fields for core mods and launcher which those managers in turn can use to accurately determine the installed version and update it if necessary.

As such I'm closing this issue now.