I have an app that requires certain support files to run. I can get the program to run properly from the terminal if I change the current directory (“cd /mnt/555…/games/Binaries/”) first before running the exe using Wine.
But if I try to run it using Lutris, I get an error. I have the executable path & working directory path set in Game Options, but it doesn’t help.
When I run Lutris (from the GUI or CLI), it keeps prompting me to download “Wine-mono”, but when I click “Install”, nothing happens. It just sits there.
When I run Lutris from the CLI/Terminal, I first see a message:
…then crash. And underneath, the dialog that’s still trying to install “wine-mono” (whatever that is.)
Note that everything runs fine if I DON’T use Lutris, using the Terminal, setting the current directory to the path of the exe, and then launching the exe using “wine”. If I don’t set the current directory, crash.
Hm. Multiple things going on here it seems. First let us identify the things Lutris wants to download and/or install.
WINE-mono is the open source implementation of Microsoft’s dotNet framework. If your app is built in dotNet then you’ll be needing this. This popup can come up when its missing.
DXVK is a library which translates Direct3D calls to Vulkan so Linux knows what to do.
The URL points to a JSON file which contains all DXVK releases which are available for Lutris. This URL works in my browser. When I get these kind of error messages I usually test these links in my browser to check if there are any connection issues.
The log calls are feedback from the app on what api calls are made.
Questions
Are the prefixes in which the app runs the same for both the command line route, which works, and the Lutris route? IE: the same directory?
Is the behavior the same if you omit the step of changing the directory from the command line? If so then maybe you can run a pre-launch script? Some thing like this:
I can open the link in my browser, so that part should be okay.
When I went thru the process to install DotNet471 (the Winetricks method kept failing, so it took some work.) I had to create a second wine prefix called “.dotnet471”, and when I use that instead of “.wine”, while the “wine-mono download” prompt goes away, it’s probably only because the game doesn’t appear to attempt to load any DirectX libraries (in the same folder as my game exe.)
Yes, when I try to run my program from the terminal w/o changing the current directory (simply inserting the full path before the exe), the result is the same as if I run the program from Lutris. (I have “Working directory” set in the Lutris config, so I don’t know why it’s ignored.)
When the same happens when you run it from the terminal without entering that directory then, from a problem solving perspective, its a good thing because you can focus on that issue. The other issues don’t seem a factor in this. So I guess that is good.
I don’t use the default wine prefix as I prefer to keep it clean. Windows programs often need specific winetricks etc to work so I prefer to create specific prefixes for them.
I’m not sure how Lutris does the working directory thing. I have to analyze the source code for this. Safe to say it does things different. It looks like your app’s case is a different one from the usual scenarios.
Did you try the pre-launch script option under the system tab in the game’s configuration? There is also a switch which tells Lutris to wait for this script to complete. You then create a text file something.sh and add the following:
Using the “pre-launch script option”, I can run the program properly via Lutris, but all I’m doing is running my desktop shortcut (which sets the path before launching the program using Wine), and if I’m going to do that, why do I need Lutris?
I don’t understand the way Lutris works well enough to figure out why the “Working Directory” option doesn’t work. I’d assume it basically executes a “CD {path}” command prior to execution, but either it does something else, or I’ve uncovered a bug.
Funny thing is, about two years and 3 HDD crashes ago, I had everything working just fine, and I don’t recall ever having to set the path. I think the problem is more likely that it’s not finding the necessary DotNet libraries in the default path.