Giter Site home page Giter Site logo

unvanquished / updater Goto Github PK

View Code? Open in Web Editor NEW
16.0 12.0 7.0 6.03 MB

QML based updater to install, update and launch the Unvanquished game.

Home Page: https://unvanquished.net/download

QML 23.13% C++ 70.88% QMake 1.49% JavaScript 1.26% Dockerfile 2.81% Shell 0.43%
bittorrent bittorrent-client cpp downloader floss foss-game fps fps-game game installer

updater's Introduction

Unvanquished

Unvanquished is an arena game with RTS elements (you can build) in which two very different factions fight.

GitHub release Github updater release Flatpak release Github universal zip release Sourceforge files

IRC Matrix Discord

Windows macOS Linux
AppVeyor branch Azure branch Azure branch

ℹ️ We provide ready-to-use downloads for the Unvanquished game on the download page.

ℹ️ This repository contains the source code for the game logic of Unvanquished.

💡️ If you only want to play the game or run a server and want to rebuild, you only need to build the Dæmon engine and download the game's assets.

💡️ You need to build this repository if you want to contribute to the game logic or make a mod with custom game logic binaries.

See below for build and launch instructions.

Translating the game

Weblate

The Unvanquished game is translated on the Weblate platform, this is the easier way to contribute translations since it offers a central place were people can contribute and review translations while reducing risks of merge conflicts. Weblate preserves authorship and automatically produces commits that can be associated with your GitHub account.

Requirements to build the game binaries

To fetch and build Unvanquished, you'll need: git, cmake, python ≥ 2, python-yaml, python-jinja, and a C++14 compiler. The following are actively supported: gcc ≥ 9, clang ≥ 11, Visual Studio/MSVC (at least Visual Studio 2019).

Dependencies

Required: zlib, libgmp, libnettle, libcurl, SDL2, GLEW, libpng, libjpeg ≥ 8, libwebp ≥ 0.2.0, Freetype, Lua, OpenAL, libogg, libvorbis, libopus, libopusfile.

Optional: ncurses.

MSYS2

MSYS2 is the recommended way to build using MinGW on a Windows host.

Required packages for 64-bit: mingw-w64-x86_64-gcc, mingw-w64-x86_64-cmake, make
Required packages for 32-bit: mingw-w64-i686-gcc, mingw-w64-i686-cmake, make

See the wiki for more detailed instructions.

Downloading the sources for the game binaries

Unvanquished requires several sub-repositories to be fetched before compilation. If you have not yet cloned this repository:

git clone --recurse-submodules https://github.com/Unvanquished/Unvanquished.git

If you have already cloned:

cd Unvanquished/
git submodule update --init --recursive

ℹ️ If cmake complains about missing files in daemon/ folder or similar issue then you have skipped this step.

Downloading the game's assets

If you don't have the assets, you can download them first. You can download an universal zip from the download page, here is the link to the latest version. The pkg/ folder can be stored in the homepath.

Otherwise you can use the package downloader script. This script can use aria2c, curl or wget.aria2c is recommended.

You can do ./download-paks --help for more options.

./download-paks build/pkg

The above snippet places the pkg directory in the libpath of the Daemon engine that you are building, so it will only be automatically found from this build directory. If you prefer the paks to be found by from all installations/build directories, consider downloading to the pkg/ subdirectory of the homepath.

Building the game binaries

ℹ️ This will build both the game engine and the game logic. Building both makes things more convenient for testing and debugging.

💡️ Instead of -j4 you can use -jN where N is your number of CPU cores to distribute compilation on them. Linux systems usually provide a handy nproc tool that tells the number of CPU core so you can just do -j$(nproc) to use all available cores.

Enter the directory before anything else:

cd Unvanquished/

Visual Studio

  1. Run CMake.
  2. Choose your compiler.
  3. Open Unvanquished.sln and compile.

Linux, macOS

Produced files will be stored in a new directory named build.

mkdir build; cd build
cmake ..
make -j4

MSYS2

mkdir build; cd build
cmake .. -G "MSYS Makefiles"
make -j4

Linux cross-compile to Windows

💡️ For a 32-bit build use the cross-toolchain-mingw32.cmake toolchain file instead.

mkdir build-win64; cd build-win64
cmake .. -DCMAKE_TOOLCHAIN_FILE=../daemon/cmake/cross-toolchain-mingw64.cmake
make -j4

Running the game

ℹ️ On Windows you'll have to use daemon.exe and daemonded.exe instead of ./daemon and ./daemonded, everything else will be the same.

First, enter the build/ folder:

cd build

Running the client

Assuming the pkg/ folder is stored next to the daemon binary:

./daemon

You can also use -pakpath to load assets from a pkg/ folder stored somewhere else, <PATH> stands for the path to the pkg/ folder.

./daemon -pakpath <PATH>

Running the server

If you want to run a server, you may prefer to use the non-graphical daemonded server binary instead of daemon and start the first map (here, plat23 is used as an example) from the command line.

Assuming the pkg/ folder is stored next to the daemonded binary:

./daemonded +map plat23

You can use -pakpath to load assets from a pkg/ folder stored somewhere else (see above).

Configuring the server

You may want to copy and extend some configuration samples, they must be stored in your user home directory, for details see the game locations wiki page and the page about running a server.

Running a modified game as a developer

ℹ️ This is not a tutorial to distribute a modified game usable by players. See the wiki for mod building and hosting tutorials.

ℹ️ This is not needed to run the released game or a server.

As a developer, you may want to run the game logic as a shared library and load modified assets from the pkg/unvanquished_src.dpkdir submodule.

Assuming you already have a release pkg/ folder, you can do it this way:

./daemon -pakpath ../pkg -set vm.sgame.type 3 -set vm.cgame.type 3

Note that only the basic unvanquished_src.dpkdir asset package is provided that way, and running Unvanquished only with that package will bring you some warnings about other missing packages and you will miss soundtrack and stuff like that.

ℹ️ If you are looking for the sources of the whole assets, have a look at the UnvanquishedAssets repository. Beware that unlike the unvanquished_src.dpkdir package most of them can't be loaded correctly by the engine without being built first.

Dealing with submodules

Please don't commit submodules in pull requests, as the submodule references may not exist after the pull requests are rebased and merged.

When a feature is split across more than one repository, submodules are expected to be committed after each pull requests has been merged.

ℹ️ More details can be found in the wiki: wiki:Dealing with submodules.

updater's People

Contributors

dolcetriade avatar edg-l avatar freeslave avatar illwieckz avatar necessarily-equal avatar slipher avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

updater's Issues

[Windows 10] Updater loading forever

The (assumed news) widget in the center never loads.

image

Also, the area at the bottom contains no content - only if you press the download icon (which is in the screenshot replaced by the play icon) then that area contains information.

Not sure whether these are technological or usability issues.

EDIT: here's a video https://www.youtube.com/watch?v=_0HEZzBGZbg

updater fails to load the blog post if it fails to load the thumbnail

updater fails to load the blog post if it fails to load the thumbnail, it must at least load the text without thumbnail

there is a way to test for this issue: run updater and click right arrow button to load previous blog post, it will fail because it will not find thumbnail because of #39.

Option to not phone home at startup (add “do not check for updates” as an opt out)

When the desktop file did not launched the updater but the game, people not wanting to phone home just had to click the Unvanquished icon and not run the updater. Now that that Unvanquished icon runs the updater (something I vote for), we need an option to skip the check at startup and just run the game straight. Players would just have to click the gear button to re-enable the update check if needed.

This would not only please privacy-caring people but also those who may play on disconnected networks (see #35).

updater looks for medium thumbnail but it's not guaranteed to exist

this is probably a bug in wordpress, but we must support this way to do things.

in json produced by wordpress, current blog post has this content:

"comment_count": 0,
"comment_status": "open",
"thumbnail": "https://unvanquished.net/wp-content/uploads/2019/05/vega_monitor.display_text.1024-filtered-672x372.png",
"custom_fields": { },
"thumbnail_size": "post-thumbnail",
"thumbnail_images": {
    "full": {
        "url": "https://unvanquished.net/wp-content/uploads/2019/05/vega_monitor.display_text.1024-filtered.png",
        "width": 1024,
        "height": 1024
    },
    "thumbnail": {
        "url": "https://unvanquished.net/wp-content/uploads/2019/05/vega_monitor.display_text.1024-filtered-150x150.png",
        "width": 150,
        "height": 150
    },
    "medium": {
        "url": "https://unvanquished.net/wp-content/uploads/2019/05/vega_monitor.display_text.1024-filtered-300x300.png",
        "width": 300,
        "height": 300
    },
    "post-thumbnail": {
        "url": "https://unvanquished.net/wp-content/uploads/2019/05/vega_monitor.display_text.1024-filtered-672x372.png",
        "width": 672,
        "height": 372
    },
    "twentyfourteen-full-width": {
        "url": "https://unvanquished.net/wp-content/uploads/2019/05/vega_monitor.display_text.1024-filtered-1024x576.png",
        "width": 1024,
        "height": 576
    },
    "rpwe-thumbnail": {
        "url": "https://unvanquished.net/wp-content/uploads/2019/05/vega_monitor.display_text.1024-filtered-45x45.png",
        "width": 45,
        "height": 45
    },
    "sow-carousel-default": {
        "url": "https://unvanquished.net/wp-content/uploads/2019/05/vega_monitor.display_text.1024-filtered-272x182.png",
        "width": 272,
        "height": 182
    }
}

but previous blog post has this content:

"comment_count": 0,
"comment_status": "closed",
"thumbnail": null,
"custom_fields": { },
"thumbnail_size": "post-thumbnail",
"thumbnail_images": {
    "full": {
        "url": "https://unvanquished.net/wp-content/uploads/2019/05/20181210-055235-000.unvanquished-updater.png",
        "width": 1024,
        "height": 805
    }
}

As you see the thumbnail key is empty, but there is a thumbnail available somewhere else.

This is reproducible by clicking the right arrow button to try to display this blog post.

Hangs at near-completion: Error extracting update.

For me, the updater got stuck showing a progress of 740.3 / 740.7 MiB, 00:00:00 left, still showing DL: 4.9 MiB/s UL: 0.0 Byte/s while there is no more progress.

The console shows:

QFontDatabase: Cannot find font directory /usr/local/lib/fonts.
Note that Qt no longer ships fonts. Deploy some (from http://dejavu-fonts.org for exampl
qml: conn.updaterUpdate=false
qml: Installing to […]
qml: Download started
qml: Torrent downloaded
qml: Download started
qml: Error extracting update
qml: Error extracting update

add a checkbox to start the game right after being downloaded

Right under the download bar in main ui we may add a checkbox to tell the updater to automatically run the game once download finishes.

In options, we may put another checkbox to automatically download updates once available. With the updater displaying the main ui with the news excerpt during max(download time, arbitrary time) when both autodownload and autostart is activated.

warning: unused parameter ‘flags’ in unix.cpp: RelaunchElevated

I got this:

unix.cpp: In function ‘Sys::ElevationResult Sys::RelaunchElevated(const QString&)’:
unix.cpp:260:49: warning: unused parameter ‘flags’ [-Wunused-parameter]
  260 | ElevationResult RelaunchElevated(const QString& flags)

All other warnings I get are from dependencies, not our code.

Self-update does not work when updater is launched from the zip file (windows allows to browse zip files like directories)

The updater's self-update functionality (replacing its own binary) does not work when it is launched from a zip file, as the binary path is some temp location.

We currently distribute the updater in a zip file, presumably due to the binary obesity (like 40M IIRC). One option would be try to find some compile flags to reduce the binary size, and then distribute the bare executable.

Another way would be to have the updater properly install itself - copy to the installation directory, create shortcuts etc. This would be a good idea in general since, assuming most users put the updater in the default "Downloads" folder or whatever, it is sketchy to have a non-single-use program located there.

Unvanquished does not load properly if updater runs in a terminal on Linux

Hi, it's probably related to some stdio stuff, but Unvanquished hangs at startup when launched by from the updater if the updater runs in a terminal.

If I start the updater from my desktop launcher using [Alt+F2] key combination or if y run the updater without attaching it to my terminal stdios using nohup (doing nohup ./updater), I'm able to successfully start Unvanquished from the updater. Otherwise don't.

You can see these logs:
http://pastebin.com/T4qFZjda

You get more logs if you try to restart unvanquished from updater after crashing it before (started from updater too).

Warn: Error writing to the terminal: Resource temporarily unavailable
Warn: Error writing to the terminal: Resource temporarily unavailable
Warn: Error writing to the terminal: Resource temporarily unavailable
Warn: Error writing to the terminal: Resource temporarily unavailable
Loading pak '/data/unvanquished/pkg/unvanquished_0.39.0.pk3'...
 Error: Crashed with signal 11: Segmentation fault

Unsupported image format (.gif)

When starting the updater/launcher, the image of the latest blog post loads endlessly.

launcher_gif_not_loading

The following error is displayed in the terminal:

qrc:/NewsCard.qml:15:5: QML Image: Error decoding: http://www.unvanquished.net/wp-content/uploads/2020/09/20200908.unvanquished-freedom-granger-celebration.gif: Unsupported image format

It seems that .gif images aren't supported.

System: Debian GNU/Linux bullseye

idea for the future: built-in console

I truely believe the updater's vocation is to become the Unvanquished launcher, while the Dæmon engine would be an updatable component like cgame or a map.

I would like to be able to tick a checkbox in that launcher and get the game started with a console, a bit like classic FPS did.

Maybe Qt has a ready-to-use console component we can leverage ?

In that schema, even Linux distributions would be able to ship the launcher, we would still announce news to players even if a distro throws away the update code at build time.

idea: command line switch for headless update

For server owners, would be cool to be able to do:

./updater --no-gui --install-path=/some/where

I don't know yet if --no-gui would just check for update and download things or must it run the game at the end too. In the later case, perhaps add a --no-run option, to let server owners having one install for multiple servers being sure they keep full control of what they do.

The --install-path would be optional. Once the config file is written, the install path would be reused like in gui mode. Wa can also add a --no-conf switch to not write the config file, it would be useful for benchmarking software, allowing them to install unvanquished for benchmarking purpose without having to mess with user data path (Let's make phoronix benchmarking us again).

Edit: the --install-path would be optionally usable by game managers like lutris or things like that, so it would be cool to have it doing things on gui mode too.

Self-compressed binaries?

@slipher proposed we may ship bare binaries instead of shipping them within .zip files. What if we use a self-compressed format like UPX?

I made some tests:

11M	updater2.7z
12M	updater2-upx
14M	updater2.zip
32M	updater2
136M	updater2-nonstripped

non-blocking warning messages about fonts

On Linux:

$ ./updater2
QFontDatabase: Cannot find font directory /opt/Qt5.8-static-release/lib/fonts.
Note that Qt no longer ships fonts. Deploy some (from http://dejavu-fonts.org for example) or switch to fontconfig.

Make cmake build libaria2.

Also it should print a human readable warning when the git submodule isn't initialized or maybe even perform the initialization.

Can't build on Debian Jessie

First try to do autoreconf -i aborts with this error:

configure.ac:24: warning: macro 'AM_PATH_CPPUNIT' not found in librar
configure.ac:24: error: possibly undefined macro: AM_PATH_CPPUNIT

If I run autoreconf again, it proceeds without errors, but still outputs warning:

configure.ac:24: warning: macro 'AM_PATH_CPPUNIT' not found in library

If then I run ./configure it gives another error:

./configure: line 12572: syntax error near unexpected token `1.10.2'
./configure: line 12572: `AM_PATH_CPPUNIT(1.10.2)'

Make installer only, dropping launcher/self-updater concepts?

The idea would be to drop the updater update implementation since it is too half-baked currently (for example the exe may be a temp file if the updater is run from the zip). Probably keep the ability to launch the game since that's a normal convenience feature of an installer, but we would not encourage anyone to use it as a launcher. So we could remove the daemon command line arguments feature.

Some relevant conversation:

<perturbed``> hmm it is not good to distribute the windows updater as a zip
<perturbed``> the updater update would not work later
<perturbed``> well it's fine for now since the game is downloaded all right
<illwieckz> do you talk about the updater updating the updater?
<perturbed``> yes
<perturbed``> the idea of the updater as a launcher is still not really fleshed out though so it probably doesn't matter
<perturbed``> since it will probably be used as a single-use installer
<perturbed``> and we can just change the version url in the next release in case anyone is using it :P
<perturbed``> for the next release we should either make it really work as a launcher or pare it down to a basic installer
<illwieckz> would be better to make it a real launcher
<illwieckz> taking url arguments and passing it to engine
<illwieckz> hmm
<illwieckz> no
<illwieckz> it means we have to write the .desktop (or regedit stuff) with updater path…
<illwieckz> so it's better the current way
<perturbed``> if it is to be a real launcher then the updater should install itself to the chosen installation path (instead of in "downloads" folder or whatever) and shortcuts should point to it

<`Ishq> fwiw, I would prefer it to be an installer
<`Ishq> The launcher part is meh
<perturbed``> i think there is only one set of quotes, but qt is printing it like a c++ string literal?
<`Ishq> And honestly
<`Ishq> I don't think we need to follow all the other companies
<`Ishq> we can just ask people to launch the installer, or launch it automatically from the game if required.
<illwieckz> to launch it from the game you need to do it in engine
<perturbed``> new concept: instead of having updater, the master server fills the server list with UPDATE YOUR CLIENT messages
<illwieckz> we can do it in client
<`Ishq> perturbed``: lol, but ya
<`Ishq> while that particular implementation is pretty shitty, launching it from the engine is doable.
<illwieckz> I'm not sure the client tells the master server its own version
<`Ishq> It doesn't have to
<`Ishq> Master server sends the latest version and client does the comparison client side.
<illwieckz> the client can fill its own server browser
<illwieckz> yes, that's whay I4m saying
<`Ishq> ah
<illwieckz> at least, no need for master server
<illwieckz> each "greater than current" server will have its name replaced
<illwieckz> well, this one may be abused by mods
<illwieckz> so master server is better

Unfortunately we can't do PIE executables for Linux yet

Because of a bug in mimetype database, PIE executables were recognized as shared libraries by mistake and then Linux file managers (whatever the desktop) were not able to run them. When user clicked on them, they got a message saying the system does not know how to open shared libraries. 😱

See freedesktop.org/xdg/shared-mime-info#11 for the related issue. 👀

This issue was only fixed this year (see freedesktop.org/xdg/shared-mime-info!81).

So we have to wait current stable releases of major distros shipping that mime fix before shipping PIE binaries, either by waiting for the next LTS, either by them backporting it.

So, for example, the day an Ubuntu LTS and a Debian stable ships the fix, we can think about starting distributing PIE executables. Before that day, it's better if we can ship non-PIE binaries if that's possible. 😢

Otherwise Linux users would have to open a terminal, go to the download dir, run the updater by hand… If we are worrying about the executable bit enough to ship the binary in a zip to avoid asking users to flip the bit in the file properties after download, we can't really expect the user to run a console and so on… 🙄

Feedback on 40f36ca.

General layout/size/proportions are looking good!

This feedback is mainly based on "what other launchers do":

  • There are two empty toolbars in the launcher window.
  • You don't need to display anything above the download bar as the bar has enough space for all relevant data. It could read "Updating 200/564 MiB (3.2 MiB/s ↓ 0 MiB/s ↑ 5:23 left)" for example. Think of the bar as the only way to communicate with the user and you will automatically strip your output down to just the currently relevant info.
  • In particular, don't display the install location on the launcher window. You can have a popup window asking for an install location at first start, after that the choice would just be remembered.
  • The launcher errors out with "Install dir does not exist. Please select another". Of course a folder named unvanquished doesn't exist when you want to install Unvanquished, this doesn't mean the installation should fail… 😛
  • In case there is an actual error with the selected download directory, it would be most convenient to re-open the install location selection dialogue. Make sure the status/progress bar is visible and shows the reason for the failure (alternatively display the reason in the dialogue).
  • Except for when the popup window is open on first launch, the launcher should always automatically start to download/update. The play button is the only button that the user should ever press on any subsequent launch. (And this is only true because users could want to read the news!)

The updater never closes the splash screen if url to download new updater is faulty

If url to download new updater is faulty, the updater never closes the splash screen.

Here, while using 0.0.5 version instead of expected v0.0.5 one (so the url returns a 404 error):

Updater update to version "0.0.5" required
aria2::addUri returned 0
onDownloadCallback event DOWNLOAD_START
onDownloadCallback event DOWNLOAD_ERROR

Then the updater is stuck on splash screen.

usability: give status and instructions in progress bar

I split the #36 issue by @GamesOpenSource in two, this one to track the usability issue:

Also, the area at the bottom contains no content - only if you press the download icon (which is in the screenshot replaced by the play icon) then that area contains information.

Not sure whether these are technological or usability issues.

I agree it would be good to give instructions, like displaying "click the download button to start the download →" in the progress bar until the user clicks it.

We may do the same to tell the download is complete and to tell people to play the game within that bar instead of a text that quickly disappear in the bottom…

Unsupported image format (.gif)

When starting the updater/launcher, the image of the latest blog post loads endlessly.

launcher_gif_not_loading

The following error is displayed in the terminal:

qrc:/NewsCard.qml:15:5: QML Image: Error decoding: http://www.unvanquished.net/wp-content/uploads/2020/09/20200908.unvanquished-freedom-granger-celebration.gif: Unsupported image format

It seems that .gif images aren't supported.

System: Debian GNU/Linux bullseye

QSslSocket: cannot resolve SSLv2_client_method

I built the updater to have a look, and I got some ssl-related errors, and nothing is downloaded, neither blog entries neither the game itself, I guess the following json error occurs on an empty file due to a timeout or something like that.

qt.network.ssl: QSslSocket: cannot resolve SSLv2_client_method
qt.network.ssl: QSslSocket: cannot resolve SSLv2_server_method
file:///…/Qt5.9.1/5.9.1/gcc_64/qml/QtQuick/Dialogs/DefaultFileDialog.qml:210:25: QML ListView: Binding loop detected for property "model"
qrc:/News.qml:30: SyntaxError: JSON.parse: Parse error

only hardcode one url in updater

Currently, those url are hardcoded in updater:

Once the updater is built and ship, we loose all control on those url, and we are vulnerable to any change or redirect (some parts in updater does not support redirects for sure), for example github may redirects the http url to https and may breaks the updater update.

The idea would be to only hardcode one url in updater (basically a json file like version.json one) and put the other ones in that json file.

Note that our web server already knows the full path to the latest updater, so we may store the full updater url in that json file instead of a prefix url. That would also allow us to quit github, change the zip name, or do strong things like that.

I suggest to extend the versions.json file (perhaps under another name).

Windows: game is launched as administrator

When the updater is running as administrator, the game is started with administrator permissions too. We can try to run as administrator only when required (instead of always), but it is still required if Unvanquished is being installed to Program Files (as is the default).

To start as a non-administrator, hopefully this code will work: https://github.com/microsoft/Windows-classic-samples/blob/master/Samples/Win7Samples/winui/shell/appplatform/ExecInExplorer/ExecInExplorer.cpp

timeout is very long when website is down, no way to start the game

When the website is down…

  • the updater is waiting a very long time before timing out;
  • the game is not automatically started even if already there;
  • the download page is displayed even if we know the download can't work;
  • there is no button to start the game.

If download is manually started:

  • waiting for timeout is very long;
  • the download attempt do not abort when the timeout is reached (only a notice is displayed);
  • the timeout notice does not last enough and may not be noticed;
  • there is still no button to start the game.

Feedback on 982b53b.

  • There needs to be a guaranteed-to-be-writable default install location for every OS. For Linux (and maybe also Mac) it should be somewhere in ~ (check the Posix/XDG/etc. standards, maybe ~/.local/share is the correct location but I'm not sure), for Windows use whatever steam uses for downloaded games, etc. That default needs to be displayed in the first-start install-selection textbox.
  • Changing the install location in the menu doesn't trigger any direct reaction, only after restarting the updater there is a reaction.
  • The reaction to changing the install location via the menu currently is that the old install location is abandoned and the game is re-downloaded to the new location. The desired behaviour for changing an installation directory should definitely include asking the user whether they want to move the old installation over. If the option can be changed during a running/paused update this means that the updater has to behave accordingly.
  • There currently is no error for when the selected download directory is not writable. For windows, installing to the system's location for programs may be desired by users, which requires admin privileges. Only allow/implement this if the launcher can maintain these privileges over multiple executions and reboots, so that it doesn't re-request privileges every startup (I'd say it's still fine for actual updates only).
  • You could actually circumvent all the points above by just dictating the install location, which is what some other launchers do iirc. It would be sufficient as an option if you could change the install directory via a command line parameter only (which is stored to configuration just like now though). In that case it's fine if it's also the user's obligation to move any content before re-executing the launcher with a new install location.
  • The launcher should have an uninstall option, in case the isntallation isn't properly registered with the OS which would handle the de-installation instead (which it isn't, atleast not for Linux). This is probably as easy as deleting all downloaded data after asking for confirmation.
  • The launcher doesn't need a Quit button. What it does need is a Play button which also replaces the Update button. To be precise, the Update button as such isn't needed either as launching the launcher means that you want to (update and) play the game in as few clicks as possible. Thus, all that is needed is a Play button that is greyed out while an update is being downloaded or looked for.
  • If you insist on a pause button, integrate it into the Play button, too. It would have three states: Play (greyed out), Pause/Resume (during update), Play (launches game). Looking at other launchers, I don't see many pause buttons for the same reason as above: Either you want to update and launch the game or you don't.
  • When the updater fails to look for a new update (e.g. no internet connection), the Play button should become available anyway after a few seconds. This should print a warning as the text of the download bar ("Failed to update").
  • Use the download bar to print the subset of the log messages that is interesting to the user: "Looking for update" (while downloading the .torrent and then doing a fast-verification), "Verifying installation" (in case of a necessary or requested non-fast-verification), "Downloading (n%)", "Up to date", "Failed to update". The log should be printed to the console only, if at all (maybe add a --debug switch). We can use the space you currently print the log to later for news and changelogs.
  • The menu should offer the in-depth verification (re-checksuming) of the installation, similiar to how it's done in torrent clients.
  • The menu could offer a download and upload speed limit setting. A drop down menu with "unlimited" and a few options (a range/selection of powers of two) is sufficient.
  • The launcher should create desktop icons on all operating systems for both the launcher (see next point) and Unvanquished itself. Atleast do the latter for now.
  • The latest version of the launcher needs to be shipped inside the binary packages of the torrent (prefered) or the launcher needs to copy itself to the installation directory for the last point to be possible (not prefered, as the launcher is never updated that way but maybe worth an intermediate solution). Some launchers would even re-launch themselves after replacing their own binary. We need a self-updatig launcher in the long run for stability, so it's best to figure out a good strategy now.
  • If the launcher is shipped as part of the torrent as explained above, the (default) install location should be the directory it is launched from. Detect this, for example by looking for the binaries or at a prioritized config file that would be part of the torrent, too. This allows users who downlaoded the torrent or zip once (or got it on a flashdrive) to update it, which is an extremely cool feature for very little effort!

prevent people "accidentally" run updater as root

I've seen on IRC that some people run the updater as root, and then chmod foo:bar $GAMEDIR. Running stuff as root can be handful, but also reserved to people which know what and why they're doing it, so, on linux and bsd systems, I would check against geteuid() == 0 (or getuid, in case someone gave the updater the setuid bit, unlikely, but code is the same and this feels safer to me?)

[Debian buster] Launcher not working

First of all, I would like to thank all of you for working on the new Unvanquished version and the launcher!

I immediately downloaded the new launcher from the official website and tried to execute it.


My system and qt version:

uname -a
Linux debian-dell 4.18.0-3-amd64 #1 SMP Debian 4.18.20-2 (2018-11-23) x86_64 GNU/Linux

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux buster/sid
Release: testing
Codename: buster

qmake --version
QMake version 3.1
Using Qt version 5.11.2 in /usr/lib/x86_64-linux-gnu

The result is as follows:

launcher

With output from the terminal:

./updater
QSslSocket: cannot resolve CRYPTO_num_locks
QSslSocket: cannot resolve CRYPTO_set_id_callback
QSslSocket: cannot resolve CRYPTO_set_locking_callback
QSslSocket: cannot resolve ERR_free_strings
QSslSocket: cannot resolve sk_new_null
QSslSocket: cannot resolve sk_push
QSslSocket: cannot resolve sk_free
QSslSocket: cannot resolve sk_num
QSslSocket: cannot resolve sk_pop_free
QSslSocket: cannot resolve sk_value
QSslSocket: cannot resolve SSL_library_init
QSslSocket: cannot resolve SSL_load_error_strings
QSslSocket: cannot resolve SSLv3_client_method
QSslSocket: cannot resolve SSLv23_client_method
QSslSocket: cannot resolve SSLv3_server_method
QSslSocket: cannot resolve SSLv23_server_method
QSslSocket: cannot resolve X509_STORE_CTX_get_chain
QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf
QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf
QSslSocket: cannot resolve SSLeay
QSslSocket: cannot resolve SSLeay_version
QSslSocket: cannot call unresolved function CRYPTO_num_locks
QSslSocket: cannot call unresolved function CRYPTO_set_id_callback
QSslSocket: cannot call unresolved function CRYPTO_set_locking_callback
QSslSocket: cannot call unresolved function SSL_library_init
QSslSocket: cannot call unresolved function SSLv23_client_method
QSslSocket: cannot call unresolved function sk_num
QMutex: destroying locked mutex
QSslSocket: cannot call unresolved function CRYPTO_num_locks
QSslSocket: cannot call unresolved function CRYPTO_set_id_callback
QSslSocket: cannot call unresolved function CRYPTO_set_locking_callback
QSslSocket: cannot call unresolved function ERR_free_strings

Digging into it, it seems Debian has dropped these symbols completely from the packages:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797926

Installing libssl1.0-dev should resolve those issues:

sudo apt install libssl1.0-dev

The output is now as follows:

./updater
QSslSocket: cannot resolve SSLv3_client_method
QSslSocket: cannot resolve SSLv3_server_method

This seems to be the same issue as #17, which shouldn't be a blocking issue.

Starting the launcher, it still looks the same.

Disregarding the look of the launcher I downloaded the game, but after finishing the download a new error shows up, saying that it can't extract the update:

launcher_extract

After manually extracting linux-amd64.zip under /home/leo/.local/share/unvanquished I was able to start the game by executing the daemon engine.


Do I need any additional packages to make the launcher work in Debian?

If any specific log files etc. are necessary, just tell me.

Store the updatable updater as any asset, the downloaded one just being a chainloader

Original comment from #49 (comment)

For the next sentences I'll assume Linux (we would adapt for other OS):

Basically what I think is that the updater would install itself as ~/.local/share/unvanquished/base/updater at first launch and then run it and close the parent, and of course that path would be the updater to update in priority, and every time the original updater is started, whatever it is stored, it would start the one in ~/.local/share/unvanquished/base before doing anything else. Autogenerated shortcuts would point to the updater in that path, not the randomly downloaded one.

We may also try to replace the binary that is stored in the wild, but even if we fail to, that would not be a problem, starting an old updater will load the newer one even before trying to update.

That would fix the started-from-zip issue (#49) at the same time.

aria2 TLS broken on Linux

The updater-update is broken on Linux in the v0.0.5 release, and with Docker builds. This is because github.com redirects http to https, and then the certificate verification fails.

I think the problem is that the ca-certificates option supplied in ariadownloader.cpp is misspelled. Hopefully changing it ca-certificate will fix that.

Splash screen sticks at top of z-order during self-update

The splash screen can't be moved or minimized and is drawn on top of any other windows. The splash screen is also displayed during the entire updater update process. Since a download potentially takes a long time, it should be possible to minimize the application during an updater update.

Apple Silicon: The application cannot be opened for an unexpected reason

Hi,

I tried to open and launch the macOS build available on the website (Alpha 51 release), on macOS Big Sur (arm64, Apple Silicon).

Unfortunately, running the app failed with the following error: The application cannot be opened for an unexpected reason.

The error logged is Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)".

Full error:

The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSFunction=_LSLaunchWithRunningboard, _LSLine=2508, NSUnderlyingError=0x130f215b0 {Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x130f1ccc0 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed with error: 111}}}}}

The app is 64 bits version so, normally, it could works using Rosetta 2:

file Unvanquished\ Updater.app/Contents/MacOS/updater2
Unvanquished Updater.app/Contents/MacOS/updater2: Mach-O 64-bit executable x86_64

I tried to resign the app locally, or to repackage using upx (not not packed by UPX btw), but none of those solutions are working...

I expect maybe a package issue, but I am not sure about that...
Are you aware about that issue please?
Is a solution "available" for this?

Thanks in advance

Pass unv:// protocol args to unvanquished

Hi, it could be awesome to be able to do that:

updater unv://server:port

So the updater launchs the game with that arg. With that functionality, it could be possible to use the updater binary path in an unvanquished.desktop file, so the unvanquished icon on player's desktop menu launches the updater instead of dæmon directly (so the player get news and updates before launching the game), and the protocol handler will works too.

With that, you only need one desktop file, the one who starts the updater. What do you think about it?

Linux docker build: AX_CXX_COMPILE_STDCXX(11, noext, mandatory)

I tried the docker Linux build and got this:

./configure: line 13883: syntax error near unexpected token `11,'
./configure: line 13883: `AX_CXX_COMPILE_STDCXX(11, noext, mandatory)'
The command '/bin/sh -c autoreconf -i && PKG_CONFIG_PATH=/openssl/lib/pkgconfig ./configure --without-libxml2 --without-libexpat --without-sqlite3 --enable-libaria2 --without-zlib --without-libcares --enable-static=yes ARIA2_STATIC=yes --without-libssh2 --disable-websocket --disable-nls --with-openssl && make -j`nproc`' returned a non-zero code: 2

Assertion failure on Debian Jessie

updater from UnvUpdaterLinux64_0.46.0.tar.xz runs, but it gets aborted if I push continue button (the one with arrow).

updater: SimpleRandomizer.cc:93: void aria2::SimpleRandomizer::getRandomBytes(unsigned char*, size_t): Assertion `rv >= 0 && (size_t)rv == len' failed.
Aborted

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.