search

jdolan / quetoo

Quetoo ("Q2") is a free first person shooter based on id Tech2. GPL v2 license.
http://quetoo.org
204 stars 28 forks source link

Check for updates automatically #609

Closed jdolan closed 3 years ago

jdolan commented 3 years ago

Forcing users to run quetoo-update manually is bad UX and also causes a lot of support question churn. It's also more work to bundle two applications (game and update) separately on some platforms (e.g. macOS). Additionally, the quetoo-update executable is little more than a thin shim that automates executing the Java based installer. It's somewhat pointless in this regard.

A better solution would be to have the game check for updates using git commit hashes written out to S3, and launch the installer directly if any updates are available. This solves a number of problems.

  1. Only a single app bundle needed for all platforms. No more Update.app on macOS, no more quetoo-update[.exe] on Linux and Windows.
  2. Any complexity involved in launching the installer can be performed by the engine, which has already sorted out its filesystem and directory structure.
  3. Users will be automatically prompted to install updates, rather than wondering why they can't connect to servers, or why their map versions differ, and having to try updating manually as a form of troubleshooting.
jdolan commented 3 years ago

This is now merged into master, with continuous integration pumping out builds for macOS, Linux and MinGW (i686 and x86_64). I've done some preliminary testing, but we'll want to keep an eye on this for a few commits to ensure that updates are prompting users, pruning the distribution works, etc. And, of course, the Windows build scripts require a little adjustment for these changes, too.

jdolan commented 3 years ago

@Paril Can you please close this ticket out when you're happy with our Windows functionality here?

Paril commented 3 years ago

Yeah. I'm not sure what we'll do about this just yet. Even if we don't run the thread unless we're using it, if somebody closes the game while it's attempting to contact the site or whatever, it will get stuck spinning forever.

According to IBM's docs:

Any mutexes that are held by a thread that terminates, become `abandoned' and are no longer valid. Subsequent calls by other threads that attempt to acquire the abandoned mutex though pthread_mutex_lock() will deadlock. Subsequent calls by other threads that attempt to acquire the abandoned mutex through pthread_mutex_trylock() will return EBUSY.

I know you wanted to avoid having a specific cleanup function, but I think it's required if there is a "random" state involved, because atexit can lead to some pretty nasty behaviors if it needs to rely on random state. I think exposing teardown() and just calling it on graceful exits is the best solution, then we won't ever have to deal with this going forward and you can just note in Objectively docs that if you are using threads you should do this to avoid issues on exiting.