Back to the main site

Lutris is a terrible Wine front-end

I outlined my issues here: Taking forever to install World of Tanks Blitz

May I ask which features from PoL (e.g.) you’re missing?

Because managing WINE bottles with Lutris is pretty achieveably IMHO. You might right-click a game and go into settings to check “run from terminal”, so you get an output with errors and shit.

Changing wine versions is very easy, winetricks are built in (but only work for me when Lutris runtime is disabled) and so on

Not all functions might be easily accessible for tech-nonsavvy users, but that’s the same in PoL. So what features from PoL are missing?

The only problem is, that often Lutris installer scripts are a little outdated (like in PoL heehee), but that’s part of the community to fiddle around. I for myself would like something like “right-click WINE -> paste own installer script” so that I don’t have to create an installer script on the website and can fiddle around with it

1 Like

He isn’t wrong. Most scripts are broken, in my experience.

If you find a script that is broken, you can fix it, and submit the working version. If you don’t do that, it will stay broken.

Keeping the scripts up to date is community work. Last time I checked the database has over 18000 games in it. Thats too much for a few people to check and keep up to date. But if from all users that we have, everyone keeps 1 or 2 up to date, it is no effort at all.

1 Like

This thread is interesting as I haven’t found any scripts in the last few months that needed any fixes at all from me.

1 Like

That’s why I pledge to get an offline “insert custom script” install method. I don’t want to do some clicks on a website, write in that browser textfield, save it, open unpublished scripts, click install and see what I did wrong again

I just want to press the “+” in Lutris and then be able to click a button to insert a custom script :slight_smile:

2 Likes

lutris -d -i localscript.yaml

You need to put your script under script: and fields for name, slug, version, runner etc. See https://github.com/lutris/lutris/blob/master/docs/installers.rst#trying-the-installer-locally

Ah thanks for that!

This needs to be made much more easy so that normal people could test/create installiers, too

1 Like

dont’ forget to install wine-staging in add to lutris:
I had to reinstall complety my machine, so I could test lutris with a clean system, and I get issues with some games ( mass effect, world of tank, borderlands )

this Suggest on installing lutris has solved all of my problems.

Mate, I kinda agree with you!

My solution was to use Q4Wine together with Lutris. It was a bit tedious to mix 'em together, but it’s possible. Some Wine games I install using a prefix created with Q4Wine, then add the prefix + wine version to lutris and then the game (or was it the other way around?).

So… yeah, my suggestion is that for some games (where the lutris script doesn’t work), use Q4Wine instead. And then manually add it to Lutris.

Cheers!

FWIW, I think Lutris is actually an incredible WINE front-end, and a far superior experience to POL where I have had endless issues, and I donate money to Lutris monthly to help support it, because of just how amazing it is.

I’m not sure why people feel compelled to come and shit on projects in this way. If you don’t like it, don’t use it.

3 Likes

The only time in a year and a half that I could make a game work with Wine was with Lutris so, no, it’s not terrible.
I find it very easy to use. It even manages DXVK which is a pain to compile and keep up to date.

Some really updated and “hard” to work games really didn’t work 1st time on Lutris in my case. Path of Exile and Warframe didn’t work with a simple install button.

Nevertheless, I was impressed by how easy it installed Diablo 3 and Heroes of the Storm, both that required the extra DRM from BattleNet/BlizzardApp.

It does feel like Lutris could work better by separating wine bottles (prefixes) and installing Steam on each of those prefixes and treating games separately, like scripts do for BattleNet games.

Later I tried installing Winesteam games using default scripts and they worked (age of empires III, titan quest), but I do feel like this will break sometime because of the different winetricks dependencies of games.

One thing I will agree that “lutris is a terrible wine front-end” is that there’s no clear mention of how to setup your system BEFORE trying wine/winesteam on Lutris. Which is basically installing Wine on your system beforehand.

So far nothing has “just worked” for me, I’ve been working on getting Fallout 4 to work for weeks now and even after getting the game to work I find out the controller isn’t working correctly.

Not to say that lutris is “bad” but it simply needs to be accessible for anyone new to update or be able to report their working versions with their specs, all of these things being archived is important if we want a healthy and growing community.

I had tons of issues getting Lutris to work on my laptop,but on my desktop, it was too easy, I dont think its lutris itself but other factors as well. I would start all over and maybe watch some youtube videos during the setup to make sure you have everything set up properly.

I don’t think I’ve ever gotten a game to work properly when installing from lutris. Have no idea why.

And you reported issues with the specific games etc? :slight_smile:

Maybe I can add some perspective to this. I came to Lutris after several days of trying in vain to install Tropico 3 or 4 (GOG versions) on Linux. More precisely on my daughter’s 64-bit Dell Latitude running Ubuntu 18.04 LTS (bionic). Until recently, using 64-bit Linux was asking for trouble in the form of library installation hell. This is why I installed the 32-bit version, which is still running. (Unfortunately, within a very short period of time the situation has been reversed. The computer cannot even be upgraded normally to 19.04.)

As I normally use Windows 10 for running Windows software, and recently even Microsoft’s Ubuntu integration for most of my Linux needs, I have next to no experience with Wine. I quickly realised that manually installing Tropico under Wine would be a very tedious process involving a lot of learning of technical details in which I am not interested. (I’m a mathematician and a professional software developer, so I could no doubt do it. But in this case I just want to get the job done quickly.)

Google told me that PlayOnLinux is the right way to do it. So that’s what I tried. Only to run into the problem that almost everyone seems to be having these days: Some weird font issues leading to zero-size windows. Sometimes they can be enlarged and used in the normal way. But some modal and non-resizable ones turned out to be totally empty even when I found a window manager (i3) that I could coax into resizing (more precisely tiling) them. As these windows were crucial for the installation process, PlayOnLinux is currently unusable. It also appears to be completely unsupported. The old development team for Python-based version 4 is no longer active and has taken down the bug tracker, which appears to have contained some crucial information about workarounds.

A new team is working on a Java-based version 5 of PlayOnLinux, but that doesn’t seem to have matured yet. I didn’t even try it.

I looked at manual installation in Wine once more, but got totally confused with the chaos of things having to be installed in Linux, within a Wine, or sometimes(?) within only part of Wine, and most people not saying clearly which method they have in mind. Things that are supposed to help add more layers of complexity.

So I googled again and found a comment saying that nowadays Lutris should be used instead of PlayOnLinux. I am sure I am not the only user on this trajectory, so it seems clear why Lutris is seen by many as primarily a Wine front-end. To make things worse, Lutris attracts users who have already been frustrated by PlayOnLinux and possibly other infrastructure around Wine.

My first impression of Lutris was excellent. I already had the Tropico 3 Gold Edition installer on the target computer, and I immediately found that there was a script for it on the Lutris website.

Unfortunately, the Tropico 3 script is obviously for a different game: “exe: drive_c/GOG Games/The Witcher 3 - Wild Hunt/bin/x64/witcher3.exe”. The problem was pointed out in a comment 9 months ago, shortly after the script was uploaded. But never addressed. No wonder, as documentation on how to debug scripts seems to be very hard to find.

So I tried Tropico 4 instead. Anticipating more problems, I nearly downloaded the 4 GB installer before starting Lutris. But I double-checked and found that, weirdly enough, there is no way to supply your own installer. Apparently it MUST be downloaded from GOG again for every installation. OK… So I did that. Over a slow connection. (It took well over an hour.)

At the end of the Tropico 4 (GOG version) installation, I found two problems:

  1. Another broken script. This was the second Lutris script I tried, and the second obviously broken on. For no obvious reason (at least to me) the script says “arch: win64” in several places. I am not an expert, but it seems obvious to me that for a Win32 game intended to run in Wine on a 32-bit Linux machine this is inappropriate and very unlikely to work. There was in fact an error message to that effect. AFTER the huge download.
  2. Another general bug similar to the one I had encountered in PlayOnLinux. The installation ends with a window that claims to be copying application data, though this doesn’t actually happen. As the window thinks the installation is not finished, the only option is “Cancel”, which undoes the installation.

I started the Tropico 4 installation process once more. This confirmed my suspicion that the installer was not cached. Lutris again asked me for my GOG password, repeated an earlier 1 GB download and then started the same 4 GB main download again

I tried one more thing: Installation of SimCity 2000 in DOSBox. This time there was no problem with the script, but I encounted problem 2 above again, in exactly the same form. Thus, the supposedly stable Lutris version I got by following the recommended installation process is not just a terrible Wine frontend, it is also a terrible DOSBox frontend.

Here are some suggestions for making Lutris more tolerant to both user errors and its own, inevitable, bugs:

  • At the start of a game installation, offer to display the installation script . (I would not have used the Tropico 4 script if I had seen that it obviously requires the wrong architecture.)
  • Offer or document an easy way to edit an installation script before use, and to upload it after it has proven sucessful.
  • Provide some form of infrastructure for keeping different architectures apart, and do not download installers without prompting if the script doesn’t pass a basic sanity check. (Requiring win64 on 32-bit Linux probably shouldn’t pass such a sanity check.)
  • Cache all downloaded installers in the user’s Downloads folder, and allow the user to supply them there if already present.
  • On the website, the comment function is a good thing but evidently not sufficient. It should be possible to report “This script is broken” in a structured way, so that the information isn’t completely missed just because nobody from the team looks at the game’s page.

All of this said, I am very glad that Lutris exists. I just wish it already were as good as it is likely to become in the next few years. And I hope it will soon be able to fill the gap left by PlayOnLinux.

Lutris is a powerfull Frontend and it is normally limited to runners compatibility, but also by script contributors. So if Wine if not compatible with your game, Lutris will not help you. If a script is obsolete, broken or…Lutris will not help you. But you can help: report an issue on Github, ask help for a broken script on the forum. All others actions will be lost time for you and for the Lutris community.

I would not approve “terrible”. I’m glad Lutris exists because Playonlinux went the way of the dodo. @johaquila has some valid points though.

  • Show install script before installation would be a good security measure.

  • Sanity checks are always a good idea.

  • Comment section could use some structure because it’s never clear which script or script version the comment refers to.

  • I’ve seen that working installers were removed in the past and replaced with strange (malicious?) ones. No way to get the old one back. Maybe a public git for installers? Or is there one already I just couldn’t find?

  • I have reported wrong (malicious?) installers in the past and nothing happened.

So yeah, there is room for improvement.