I have a Windows application that I can run with lutris lutris:rungame/adobe-digital-editions (or lutris lutris:rungameid/1 ) from the command line. I know that I can pass arguments to the exe / application by setting “Game options” > “Arguments” in the Game preferences. How can I do this on the command line?
That is, I would like to pass file names as command line options to the application like
I tried this but it did not work. Might it be that this is really not possible with lutris?
With bare wine you can do this with wine .wine32/drive_c/Program Files/Adobe/Adobe Digital Editions 2.0/DigitalEditions.exe file1.acsm file2.acsm file3.acsm (but I cannot use wine as the application does not properly install with just wine, it is too complicated to setup, but Lutris works without problems)
You seem to be misunderstanding the purpose of Lutris.
Lutris is an interface for managing videogames. It’s designed to run videogames, it has multiple features that exist specifically for that purpose, and it has a large database of easy-to-use install scripts for them.
Videogames aren’t utility appilcations. They aren’t supposed to operate external files; they’re supposed to be set up and run the exact same way every time you start them up. There’s no reason to run a game with a custom one-time argument (and thus, Lutris doesn’t have such a feature).
If you want to manage utility/multimedia applications (particularly those run with Wine), don’t use a videogame manager to run them. Personally, I’d suggest using Q4Wine for that; that’s what I use whenever I need to work directly with Wine. The whole “create prefix → setup drive → work with Wine” process is very smooth in it, and it has a CLI-runner if you need it (though I normally just make a desktop icon with drag-and-drop). Of course, it doesn’t have Wine versions hosted for download, but you can just add ones you download in Lutris.
Except when they do. For example, World of Warships expects you to pass the replay file to the executable to be able to view a replay made in the game. This is a function of the game. This is how that company (stupidly) expects their players to perform that task. Well, they actually expect them to double-click the replay and have Windows pass the replay file to the registered EXE as a command-line parameter.
Having this feature be missing from Lutris on the faulty presumption of “games don’t do that” ignores that games can, and often do, perform just that task.
Games are not utility applications. They aren’t supposed to operate external files.
If developers of some game do not bother to keep to the convention, and implement their game to do weird things, that doesn’t change the convention, that’s just them being lazy.
And, if you really need to have access to that particular odd functionality, there’s literally nothing stopping you from using an actual Wine utility applications manager for the purpose of running your game in a way that games aren’t normally supposed to be run.
Except when they do. And they can. For example, save files, replay files, mod files. Games are programs like any other and the developers will avail themselves to those features like any developer.
Except this isn’t weird? And honestly, this isn’t a convention I’ve heard of until you brought it up as a lazy defense on not implementing a basic feature.
Aside from the fact that it was installed with Lutris, using Lutris scripts, launched by Lutris.
Here’s what I had to do to this weekend get around this lazy thinking of yours. I needed to run a program in the same bottle as the game launcher, so it would recognize the launcher as running. This is because the program would run the launcher and exit if it wasn’t already running. To do this I needed to Run EXE in this… whatever that option is. Except I can’t pass a command line parameter to the EXE that I want to run in that bottle.
Fine, check the debug window. Oh, the debug window is only for the “play” button and does not include any launch options for other EXEs. Cobble together a passable command line based on the one that was for the game launcher. Try that on the command line. It fails. This is where we get to “Just use another WINE launcher!”
It failed because Lutris sets environment variables which are part of getting the game to run properly. To get those environment variables I had to run Lutris -d in its own window. Why they aren’t a part of the debug logs, who knows! How another WINE manager is supposed to divine what Lutris sets, who know!?
Ultimately I was able to cobble together enough to have a shell script that sets the proper variables, calls the correct version of WINE, in the correct prefix, while having Lutris run the game launcher so that program recognizes the game launcher as running so it could do it’s thing and pass the command line variable it needed. 2 hours of effort because Lutris not only won’t implement a basic feature of computing since it was a thing, but because it seems openly hostile to anyone knowing what it does.
There are several reasons why people would want to have control of the command line. Not only of the main game, but of the “Run EXE…” option as well. It has come up several times in the forums. I think it has been in the bug tracker several times. And the reason it’s not implemented is an allusion to a convention that, in my 40+ years of computing, I have literally never heard of until now?
Sigh. Look up the word “supposed” in a dictionary before arguing about it.
Then again, you can’t seem to tell the difference between a videogame and an utility app, so it might be that it simply eludes you.
Again, a properly made game isn’t an application that should be used to operate external files; that’s exactly what is not their purpose. Any command-line arguments provided by game executables are normally for fine-tuning its launcher command in case default settings aren’t working for you. A game that expects you to run it with an external file as an argument, and apparently registers its own file extension for that purpose? That’s very much not normal at best. And if you somehow managed to miss it in no matter how many years of experience you claim to have, it can only mean this experience of yours hadn’t had much to do with videogames.
As for your 2 hours of troubles, it appears you have neither tried using Wine console (which is I believe is the to-go thing when doing something that apparently would be done in the command terminal when doing it on Windows) nor did you think to run that program of yours externally with the game being run from Lutris (running in the same bottle should be as easy as using the same Wine server binary and same prefix… or at least that’s how it been for as long as I can recall). And if it’s a one-time thing you could likely have just duplicated the game config with a different executable/arguments list instead of going through all of that trouble.
Also, last time I checked, Lutris didn’t actually hide its game config but rather kept the game settings in the config dialog, with most settings being a fairly transparent wrapper over commonly used CLI parameters, whereas the not-so-common environment variables are outright listed in dedicated table. Haven’t had much trouble running any game installed in Lutris externally, and I certainly never needed to look at debug output just to figure out how the game is configured to run.
As for why they haven’t implemented every single feature that ever ended up being mentioned on their forums? I’d imagine it’s because for the most part these are either obscure things not needed by the vast majority of users, stuff that should be easy enough for anyone actually capable of doing it in the first place (as for the most part Lutris is a rather thin frontend to the process of installing/launching videogames), or possibly both.
Funny, it has nothing to do with what I was arguing. Just because you presume how games should work and use a weasel word doesn’t change that fact that you’re wrong. The sky is supposed to be chartreuse and lime green! The word “supposed” in that argument doesn’t make it any more true.
Again, by who’s definition? Yours? I consider that highly suspect since you seem to be wholey unaware of what games actually do. After I replied I thought of about a dozen reasons why someone would want access to the command line. I was actually hard pressed to come up with games that don’t have command lines. The more I thought about it, the more examples I came up with.
Ultimately I just did the following in a terminal. Man Wesnoth. Sure, not a Windows game but Lutris isn’t confined to Windows. 2004, popular game on Linux, 3+ pages of command line options.
Any command-line arguments provided by game executables are normally for fine-tuning its launcher command in case default settings aren’t working for you.
Or as a shortcut way to pass variables for often used cases. Like what configuration file to run for a game server. Or a modlist. Or any other number of files which might be used.
Yes. Because you haven’t heard of it doesn’t mean it doesn’t exist. In this case, World of Warships replays. On windows it registers the .replay file to the WorldofWarships.exe as a command line. Pass a replay, it bypasses the login process, loads the replay and plays out the match that was recorded. Wargaming has done that since they released World of Tanks in 2010. Pretty simple way for them to get their community to view the replays. Register the game as a player to a file and leverage the standard Windows “double-click file to open” mentality. You may not like it, you may not think it is what a game is “supposed” to do. It doesn’t change the fact that it has been done.
To replicate that functionality we need a way to easily to pass the replay to the executable.
Mod files, different configuration profiles, as you mentioned command-line parameters to adjust how the program runs, replay files, game servers running different settings for different people, custom levels. These are not uncommon. Are you a console player or something? These was standard fair back in the '90s and '00s. This is part and parcel of gaming on a PC. You are literally the only person I have ever met in PC gaming that things passing a command line to program is somehow a foreign concept.
Or, it includes trying to do that. Fun fact, cmd in Wine doesn’t have tab completion. Let me tell you how fun it is to try to manually type out “20201011_231439_PZSD107-Gadjah-Mada_17_NA_fault_line.wowsreplay” by hand. Might be why I want to be able to pass it as a command line to the executable?
It’s like you didn’t even read what I wrote. I was running the program in Lutris. Wargaming Game Center, the launcher, needs to be running. If it isn’t, the game executable will launch it and exit. They need to be in the same bottle to be recognized. So, my first thought was there must be some trivial way to pass a command-line via “Run EXE inside wine prefix”. When I found no method to do that I then searched here which lead me to this 9 month old thread with a very poor excuse on what it isn’t present.
Except without the environment variables the game’s display was completely borked. As I said, and you ignored, I did get to that step by looking at what the debug window showed for the launcher and replaced it with the executable for the game.
You’re also knee deep in this and familiar with what you’re looking for. Just imagine someone who is using Lutris to not have to be knee deep in that minutia. You also have the knowledge of knowing what the dials on Lutris translate to. Incidentally, you’re trivializing or lying here. My entire runner and system options for the environment has this listed in the config:
Here’s the environment that is passed to WINE for this game:
Running /home/grey/.local/share/lutris/runners/wine/lutris-5.7-9-x86_64/bin/wine /home/grey/games/lutris/wargaming-game-center/drive_c/Program Files (x86)/Wargaming.net/GameCenter/wgc.exe
Initial process has started with pid 6000
Game is considered started.
And here’s lutris -d:
DEBUG 2020-10-13 21:54:29,194 [command.start:133]:Running /usr/share/lutris/bi
n/lutris-wrapper Wargaming Game Center 0 0 /home/grey/.local/share/lutris/runners
drive_c/Program Files (x86)/Wargaming.net/GameCenter/wgc.exe
DEBUG 2020-10-13 21:54:29,194 [command.start:135]:ENV: SDL_VIDEO_FULLSCREEN_DI
DEBUG 2020-10-13 21:54:29,194 [command.start:135]:ENV: PULSE_LATENCY_MSEC="60"
DEBUG 2020-10-13 21:54:29,194 [command.start:135]:ENV: DXVK_HUD="0"
DEBUG 2020-10-13 21:54:29,194 [command.start:135]:ENV: WINEDEBUG=""
DEBUG 2020-10-13 21:54:29,194 [command.start:135]:ENV: WINEARCH="win64"
DEBUG 2020-10-13 21:54:29,194 [command.start:135]:ENV: WINE="/home/grey/.local
DEBUG 2020-10-13 21:54:29,194 [command.start:135]:ENV: WINEPREFIX="/home/grey/
DEBUG 2020-10-13 21:54:29,194 [command.start:135]:ENV: WINEESYNC="0"
DEBUG 2020-10-13 21:54:29,194 [command.start:135]:ENV: WINEDLLOVERRIDES="d3d10
DEBUG 2020-10-13 21:54:29,194 [command.start:135]:ENV: WINE_LARGE_ADDRESS_AWAR
DEBUG 2020-10-13 21:54:29,194 [command.start:135]:ENV: game_name="Wargaming Ga
DEBUG 2020-10-13 21:54:29,194 [command.start:135]:ENV: PYTHONPATH="/usr/lib/lu
/home/grey/games/lutris/wargaming-game-center/drive_c/Program Files (x86)/Wargami
Initial process has started with pid 6000
Game is considered started.
Now why in god’s green earth would I want to have all of those ENV statements? Wait, I know, because it tells me EXACTLY what Lutris is passing which is EXACTLY what works and I want to match EXACTLY. Not have to look through a couple pages of configuration dialogs and guessing what might be passed. Oddly enough once I saw that I knew prepend export to each line, ignore the Pythonpath as I don’t need that, and I’m done. Guess what happened? The game run perfectly fine.
What boggles my mind is why, on the debug log for the game you don’t think the exact environment passed that the game is running under is important.
Because in your perspective, which is the worst perspective you have, you feel that it doesn’t matter? Except, unlike you, most people aren’t coming to this problem with a deep understanding of WINE, the tools surrounding it, nor a mental map of the Lutris code.
In case you missed it, do you know how Lutris is most mentioned? To people new to Linux. Not Linux gaming, Linux in general. Someone wonders how the gaming is because they want off Windows. And people tell them if a game is on Steam, Proton probably has it covered. If not, give Lutris a go. This tool is recommended to neophytes to WINE as a way to not have to worry about WINE.
Do people recommend that Lutris do everything in the exact same way as Windows? Hell no. But does it come with a certain expectation that if there is a use case in Windows (or any other runner, for that matter) that the approximate same thing can be done in Lutris?
I hate to break it to you, but you are completely wrong when it comes to the command-line. Especially when it comes to PC gaming with its culture of modding, tweaking and customizing. You may not engage in that on the regular basis. But that does not mean the userbase at large doesn’t have a need for this fundamental feature of PCs. And saying it is trvial for you to noodle out how to get around that shortcoming is of absolutely no help to someone who is running a game with Lutris and has 0 experience with WINE outside Steam or Lutris.
I have another use case that may add to the merit of allowing command line arguments to applications installed via lutris.
Recently, it was possible to run Roblox again on linux via wine 6.11 and later. Roblox uses a browser to browse games and launches the game using a url protocol.
I made a custom .desktop file that launches RobloxPlayerLauncher.exe along with the token that comes when you click on a game.
Exec=wine RobloxPlayerLauncher.exe %u
This works and launches the game successfully.
This doesn’t work however:
Exec=lutris lutris:rungameid/001 %u
It would be nice if instead of launching wine directly, I could launch it via lutris simply because of the ease of configuration it provides, should I choose to change a few settings here and there.
I worked around this by editing the game.yml file directly before launching lutris.
The .desktop file passes the token to a script which then uses sed to replace the arguments in the args: field.