OpenMW Launcher issues

[dreamer]

Summary:

• Launcher requires Qt to run - and Steam Runtime does not include it, so we can't depend on users having it installed.
• Qt build takes more than 1h, timeouting our builds
• It's possible to launch OpenMW without it but we need to work around few details
• It is very useful for selecting mods, which is important for this game

[d10sfan]

For this, at least the following steps are needed:

• Change openmw build to use qt4 source only for headers, and not compile to help speed build up.
• Create shell script that is used as the launcher wrapper that checks for the existence of the openmw config file. If it does not exist, create it and point the "data" variable to the Morrowind steam installation.
• Test this with and without qt4 installed. The launcher should load and already be pointed to the right location. And the game should be able to be run without the launcher in the mix.
• Amend the shell script to show a warning to the user if qt4 is not installed. This would allow them to stop so that they can install qt4 with their package manager, or continue to load the game directly. This would use Zenity for the user interface of this dialog.

[d10sfan]

Was looking into the built without qt4 in the mix. One option I was considering that I wanted to get your thoughts on was to replicate what the openmw gitlab ci tool does for that package, which is grab it from apt-get. If we did that, not sure if we'd want to use some of the other packages that way as well.

[dreamer]

Sure, it might be the fastest path towards solving this problem and we don't lose anything by experimenting :) Just install it using before-script in .gitlab-ci.yml - preferably only for build stage; I don't want run-build.sh ran locally to install qt4 into my local Docker image and introduce unintended dependency for other packages.

If we did that, not sure if we'd want to use some of the other packages that way as well.

We can do it only in two cases:

• library offers only .a object to be statically linked <- I am fine with adding these to the Docker image
• we plan to introduce launcher script to bypass GUI launcher to work around libraries potentially missing on users' machines <- OpenMW situation

But! Maybe we should indeed install missing dependencies during CI run and copy the .so files to game-specific lib directory; or even bypass installation and just download and unpack .deb files during build stage. It would be neat and potentially save us a lot of effort - we need to investigate it more :) I doubt this approach will work for GUI libraries though - they tend to have dependencies outside of binary ABI (paths to resource files, default themes, etc).

[d10sfan]

Ok, I'll probably give this a shot in a few weeks, about to go on a trip. But it sounds doable.

[dreamer]

For the record: new Docker image is now available: luxtorpeda/steam-runtime-amd64-beta:lux-190808-1; details here.

[d10sfan]

Made some good progress on this front. Now the qt4 dep is handled by the libqt4-dev package, instead of compiling it. The last piece for now I believe is some issues with getting gitlab-ci to work with the apt-get install part.

The launcher wrapper script will now check to see if the launcher is successful in loading, due to the qt4 dep installed on their system. If it is, it'll let the install wizard (does not change any data, just points to the right place) and then launcher take care of the settings process. If not, it'll create the openmw configuration file and launch the game directly. I copied the latest example file for the config into the repo, as the one in the source repo had none of the fallback data. I ran a test locally and was able to load into the game and do a bit of the starting bit, without needing qt4 or the launcher.

It won't prompt the user about the qt4 currently, just launch the game directly. I'll probably need help in showing a dialog, as haven't done that before with bash.

I could also use some more people testing this one, both with qt4 installed and without. It checks for the existence of the ~/.config/openmw directory to decide whether or not to install its own config file, if the launcher is not available.

I'm running into issues with the apt-get install step on gitlab ci. When attempting to install the packages, it gets the following error. I based the command off of https://github.com/OpenMW/openmw/blob/master/.gitlab-ci.yml

debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin: 
Fetched 27.5 MB in 1s (16.0 MB/s)
dpkg: error processing archive /builds/luxtorpeda/packages/openmw/apt-cache/libaudio2_1.9.3-4ubuntu0.1_amd64.deb (--unpack):
 cannot open security status notification channel
E: Sub-process /usr/bin/dpkg received a segmentation fault.

[d10sfan]

I added the zenity GUI to ask if we should continue launching the game.

[dreamer]

The package is now buildable :) and just got deployed to GitLab pages: https://luxtorpeda.gitlab.io/packages/openmw/ but I haven't updated launcher scripts to reflect slightly modified file structure. As for Zenity: please remember to:

• use ShellCheck on shell scripts to prevent certain categories of bugs
• in context of Steam Runtime, use the binary pointed by env variable STEAM_ZENITY (this variable was added to recent Steam Beta to fix some Zenity-related problems); if it is not defined, then use binary /usr/bin/zenity.