Not sure if this is where I should send this, my gut instinct would’ve been to just shoot an e-mail to the developer, but the FAQ says to “not report issues by email” and the #lutris IRC channel cannot be joined, so I’ll try here. I mostly use Lutris to run games from old platforms, and in doing so I’ve noticed a few issues, so I made some patches for them (they’re made against version 0.5.5), which you can get from my cloud, I’ll briefly describe them below.
First, here’s an annoyance: Since the 0.5.5 release, I couldn’t use the Install buttons on the website to install games, I was told that the
lutris binary was not found. Upon noticing the binary was in an unusual location (
/usr/games. It’s in my
$PATH but I guess Chromium or xdg-open or whoever handle those links just hasn’t got it in theirs), I remembered the previous Debian package had more files in it. So, the solution was a quick one. Get the 0.5.5 source, create a file named
debian/lutris.links with the following content:
And rebuild the package with the usual
debuild -uc -us invocation. There you go (for those who are wondering: The culprit is commit
af070229db4936e4c9cd334b275a545b07882c45 from December 26)!
For everything else below, you can apply the patches to the Debian package quite easily by dropping the attached archive’s
patches directory into the Lutris source’s
debian directory, then doing a
echo "3.0 (quilt)" > debian/source/format, and rebuilding the package the normal way.
So, to begin with the litany of little issues, we have the runner’s platforms: They’re, huh, a bit wonky. For instance:
mednafenrunner returns platform names which do not match the corresponding icon names and mixes games for different machines under the same platform, e.g.,
Nintendo Game Boy (Color)should actually be two platforms to have the correct icons show
openmsxrunner also declares a platforn name which does not match the icon (maybe not a problem, I didn’t see this runner used on the site)
messrunner does not declare the
SNK Neo Geo Pocket Color, even though it’s used for the NGPC installation scripts
osmoserunner does not declare the
Sega Game Gearplatform
- The worst might be the
libretrorunner: It declares having cores for a plethora of platforms, but some of them are just missing from the runner repository (hxxp://lutris.net/files/runners/), for instance the
operacore (for 3DO) or the
kronoscore (for Sega Saturn). And yes, looking at games on the site, those cores are used by installation scripts, which tells me they won’t work upon install as the correponding core won’t be downloaded (also, some cores which are available on the repository are not declared, like DOSBox).
The first patch in the archive (
patches/0010-fix_runner_platforms.patch) fixes this, and standardizes all the platform names across runners. It also tries to return correct platforms for multiplatform runners/cores by applying a crude heuristic on the ROM filename (lousy, I know, but that was the easy option). For libretro, it also maps removed cores to ones that are still present (well, when there’s one, at least. To the guy who uploaded those J2ME mobile games: Sorry, you’re out of luck). Finally, it changes some platforms I think don’t really apply to the runners (I mean, come on, sure: ScummVM games might have been rereleased for Linux lately, but I’m sure most people would identify Monkey Island as an MS-DOS game!). You might also want to apply
patches/0050-show_old_platforms.patch (which merges the platforms from the runners with those from the SQLite DB) to ensure platforms don’t disappear from the sidebar after applying the previous patch.
Next, I noticed an issue with the default installation directory format: It’s just the game title, which is all well and good, until you have the same game for different platforms, as it will mix the game files, and (what I was most anxious about) probably delete all the files for both versions if I uninstalled one. The file
patches/0020-use_slug_for_install_dir.patch fixes this by using the full versioned slug. Also, the file
patches/0030-add_directory_field.patch provides a directory field which you can use to change the directory a game is installed in (you’ll still have to move the files yourself, though). Another annoyance was that, upon installing a game for a new platform, the platform wouldn’t show in the sidebar until restarting the app. The file
patches/0060-update_platforms_on_install.patch takes care of that.
Let’s go on with some more issues installing random games. Their scripts are, well, just broken. Take the Super Nintendo version of Final Fantasy III, for instance. The script says:
install: - dst: $GAMEDIR merge: null src: rom
Guess where the problem is? That will NOT install the game to
$GAMEDIR, instead the ROM will be left where it is, which can lead to some amount of head-scratching when that location is wiped (yes, I’d put the file under
/tmp for the install). The script should read:
installer: - merge: src: rom dst: $GAMEDIR
So, I made a patch (
patches/0040-handle_broken_scripts.patch), but I guess the correct solution would be for someone to fix the script on the website.
Another example: Looking at the available Z-Machine games, I tried to install Arthur Yahtzee: The Curse of Hell’s Cheesecake. The game installed, but then failed to run, the
frotz runner complained it couldn’t find the file, even though I could see it. So, what did happen? Well, the script just provides a naked filename, while the runner expects a full path. Applying
patches/0070-frotz_default_dir.patch fixed the issue for me.
I also had much more trouble than expected with some runners:
- Mednafen would run fine, but then freeze the KDE 5 Plasma shell upon exit, didn’t find any useful info about this problem, maybe some issue with powerdevil, I don’t know :+(
- DGen would go fullscreen even though fullscreen wasn’t enabled. I even managed to completely mess my screen resolution trying to troubleshoot it
- Osmose just would not run, instead failing with
libQtOpenGL.so.4: cannot open shared object file: No such file or directory(is that a KDE4 library?! Definitely out-of-date!)
In the end, I just had enough of this (not to mention, each time you use another runner, you’ve to redo your joystick setup, and so on) and decided that, since Retroarch was working quite well, I would simply use it for everything I could. If you too have trouble with some emulators and don’t want to tediously change every install script, you might find
patches/0090-replace_runners_with_libretro.patch useful: Assuming the runner platform patch above has been applied, it will run games for most emulators with Retroarch instead. Much better that way (at least for me)!
[edit: looking at the website now, it seems that most of the games have been switched to libretro, I can’t find any game run by either dgen or osmose, and pretty much none on Mednafen with the notable exception of Super Mario Bros., while I still have a lot of them, according to a
SELECT COUNT(*) FROM games WHERE runner IN ('dgen','mednafen','osmose'). I guess someone had enough just like me and changed the scripts, so I might just be able to drop the above patch if I can find how to fix the games config files]
There are a few more patches, but they aren’t really fixes per se, rather some experimental enhancements. The first (
patches/0080-frotz_alt_engine.patch) provides an option to enable a different engine for Z-Machine games, based on a patched version of jsZip. This is defintely hackish: In addition to applying the patch, it also requires dropping the
runners/jszip-master directory into
~/.local/share/lutris/runners. And it needs chromium-browser to be installed (or to edit jszip.sh to change that). But if you like playing IF comfortably, you might like the fact that you get an automap feature (yay!) and autocomplete to boot (try
<Tab> at the interpreter’s prompt).
Also, I found the installation process for most emulated games to be tedious: You have to navigate to your ROM directory for the console, which can be nested quite deep, and select the ROM file (which might have a completely different name, see below for my thoughts on the site’s game database), hoping you selected the right dump. So in
patches/0100-rom_auto_selector.patch, I try another approach: Just select a directory, and it will recurse into that directory, making CRC32s of each file and comparing them to a CRC in the script. Once the file is found, it’ll be automatically selected. For this to work, the installation script must have something like this:
files: - rom: S/C:61F9E7CD:Select the game's ROM file
Note the CRC value before the message to display.
Well, that’s enough monkeypatching for today, I hope someone finds one of those useful. That being said, a problem I cannot patch so easily is the lackluster quality of the Lutris games database. There are quite a few issues (wrong naming, duplicates, etc.), but the one that makes me go bonkers is the fact that the platforms a game is advertised for do not match the platform you can actually install the game for. You don’t have to search very far to encounter instances of this, for instance the MSX platform has a total of 49 games (which is far from being a complete listing, by the way). But looking at each game in turn, only three (3D Tennis, Penguin Adventure and Le Mans 2) have an install script for MSX. So that was three clicks out of forty-nine which yielded something useful. I’m aware this paragraph sounds really negative, and I’m sorry for that, but honestly, this kind of kinks does not provide for a good user experience; filtering out the platforms that cannot be installed would be a Really Good Thing™, and I’d really appreciate if someone could fix that (I would do it myself if I could but as I said, the issue is server-side)…
Also: On the Runners (hxxps://lutris.net/runners) page, there are links to see what games a specific runner (or a specific runner version) has got. That’s nice… except it’s broken: Following any version number link will just show a blank page. Following the “Browse games for all versions” will only show the first 25 games with no pagination. Again, not very useful :-/
So yeah, I definitely like Lutris, the idea of converging all your gaming-related things in a single place is appealing, the UI is nice, and some parts actually remove hassle from the user (I’m mainly thinking about WINE here), but there are other parts that bother me somewhat (like runner binaries not being integrated in my package manager) and some which are hugely annoying (like the database issues above). That being said, it’s still a huge improvement over the previous situation re: gaming on Linux. So thanks you all anyway!