
transhumanist trans humanist
Published
gamemoderun %command% --skip-launcher
Game failed to open (steam says "running" but no window actually ever appeared) out-of-the-box. Disabling the launcher and manually switching to Experimental fixed it.
I was able to play just fine, no weird performance issues, and was able to host a multiplayer session with friends playing on Windows without any issues whatsoever.
gamemoderun %command% --skip-launcher
UPDATE: Patch #4 broke Linux compatibility for the Vulkan executable for the game for some reason, and hasn't been fixed as of Hotfix 12 - when you're most of the way through loading the game, WINE will throw an error, something about Vulkan pipelines. The marginally annoying solution is to open the game files through Steam by going to Library > Baldur's Gate 3 > Manage > Browse local files, and go into the /bin/ folder. Remove the default "bg3.exe" (which is the Vulkan exe), by either deleting or moving it somewhere for safekeeping (I just threw mine to ~/Desktop/). Then rename the "bg3_dx11.exe" (DirectX exe) to simply "bg3.exe". Hopefully they fix this, or a WINE update fixes it... It hurts my brain that the Vulkan version, out of all of them, is broken on Linux. In any case, it works as it did before when I wrote the below review. I had switched to ProtonGE to try to fix the above problem, but it didn't help.
Game failed to open (steam says "running" but no window actually ever appeared) out-of-the-box. Disabling the launcher and manually switching to Experimental fixed it.
I was able to play just fine, no weird performance issues, and was able to host a multiplayer session with friends playing on Windows without any issues whatsoever.
Worked, but updates have broken some stuff and necessitated more tweaking (luckily just launch options). Hopefully fixed back up in future.
eval $( echo gamemoderun "%command%" | sed "s/Launcher\/LariLauncher.exe'.*/bin\/bg3_dx11.exe'/" )
ANOTHER UPDATE: At some point starting a few weeks ago, updating my system caused only this game to fail to launch, with the launcher complaining that I don't have .NET6 on my system (even though I didn't update dotnet!). This was fixed by stealing the below launch option. All it does is enable FeralGamemode, and literally replace the PLAY button's call to LariLauncher.exe to one directly calling bg3_dx11.exe. Doing this also achieves the effect of the update below in terms of directly launching the DX11 version through steam, so I don't need to move around or rename any files anymore. Just set the launch option.
.
UPDATE: Patch #4 broke Linux compatibility for the Vulkan executable for the game for some reason, and hasn't been fixed as of Hotfix 12 - when you're most of the way through loading the game, WINE will throw an error, something about Vulkan pipelines. The marginally annoying solution is to open the game files through Steam by going to Library > Baldur's Gate 3 > Manage > Browse local files, and go into the /bin/ folder. Remove the default "bg3.exe" (which is the Vulkan exe), by either deleting or moving it somewhere for safekeeping (I just threw mine to ~/Desktop/). Then rename the "bg3_dx11.exe" (DirectX exe) to simply "bg3.exe". Hopefully they fix this, or a WINE update fixes it... It hurts my brain that the Vulkan version, out of all of them, is broken on Linux. In any case, it works as it did before when I wrote the below review. I had switched to ProtonGE to try to fix the above problem, but it didn't help.
.
Game failed to open (steam says "running" but no window actually ever appeared) out-of-the-box. Disabling the launcher and manually switching to Experimental fixed it. I have been able to play just fine, no weird performance issues, and have been able to host multiplayer sessions with friends playing on Windows without any issues whatsoever. Have all of my playtime on Linux, almost all multiplayer, and it has worked very well after getting past these issues.
gamemoderun %command% --skip-launcher
There used to be issues related to the following:
- The Vulkan executable would crash 50% through launch on my machine
- The game would fail to launch with the C# Dotnet Runtime (dotnet-runtime) updated to 8.0.1
- The launcher did not work, forcing the use of verbose and complicated launch options that directly replaced the call to LariLauncher.exe with a call to bg3_dx11.exe (
--skip-launcher
used to not work on this game, but now it does!)
As of my testing on 29 Feb 2024 (Had to rip off a bandaid with glibc on Insurgency: Sandstorm, figured I'd rip off the Dotnet bandaid too) these issues are no longer present. Vulkan exe works completely fine, the Larian launcher opens properly and is able to launch the game, and all that on top of updating my Dotnet runtime to the latest version. Cannot overstate how happy I am to see a game graduate from issues like these to working good enough for an average joe out-of-the-box. I still recommend these launch options, as Feral Gamemode is helpful for performance in general, and the Larian launcher just adds extra clicks before actually getting into the game where it pesters you to make an account for cloud saves (which is probably worthwhile for some people, but AFAIK this game also has steam cloud saves, so really only necessary if you're playing on multiple platforms).
Worked out-of-the-box on my system.
No problems whatsoever. I assume EAC runtime needs to be installed - I have it already from playing other games
Didn't modify any of the launch options, although I might mess around with enabling Gamemode.
Worked perfectly with no tweaks.
Did not try to play co-op yet. Internet-connected singleplayer functionality e.g. daily challenges, race events, and cloud synchronization with Ninjakiwi account work as designed.
Worked flawlessly
I just picked up this game for the first time during the winter sale, since I had heard much better things about version 2.0 & the expansion compared to what I heard when it first came out. I've been able to play it without having to think about or tinker with anything, and I haven't had any issues with stability, graphical bugs, or anything else for the 50+ hours I've played at the time of writing. It has never crashed and I don't think I've seen any kind of graphical artefacts whatsoever. A+
Switched to experimental out of habit for demanding 3D games. Worked without any significant messing-with.
Works out-of-the-box, haven't tried multiplayer
I just downloaded the game and clicked Play. No launch options, no forcing a specific Proton version. Works like Windows. Haven't tried multiplayer (I'll be honest I don't even really know how DiRT Rally MP works, I've played both games singleplayer). Other online features such as syncing of your profile, daily/monthly/etc. Challenges, Time Trials, and so on work as intended.
Works out-of-the-box, haven't tried multiplayer
I just downloaded the game and clicked Play. No launch options, no forcing a specific Proton version. Works like Windows. Haven't tried multiplayer (I'll be honest I don't even really know how DiRT Rally MP works, I've played both games singleplayer). Other online features such as syncing of your profile, daily/monthly/etc. Challenges, Time Trials, and so on work as intended.
gamemoderun %command%
Running in windowed mode had very poor FPS
Runs fine with no changes to steam settings or launch options, maybe a slight (i.e. 5-10%) performance hit vs Windows at most. Seemed to run better still after I forced Proton Experimental and enabled Feral Gamemode.
Worked out of the box - played the same as windows
gamemoderun %command% --use-d3d11
I don't recall how I fared with the default Proton recommendation, which is why I didn't include a non-tinkered rating. I haven't had crashes or disconnects that fared differently from any of my friends on Windows. The obscure kernel-level anticheat (🤮) doesn't seem to cause any problems, not sure if it's because it intentionally allows Proton or because it isn't well-designed enough to tell when it's not running natively on a Windows system.
gamemoderun mangohud %command%
Works pretty much perfectly. No issues whatsoever with audio, resolution & framerate, windowing, or inputs including the use of my Xbox One S controller via Bluetooth (Although Steam probably lends a hand with that).
gamemoderun %command%
No problems whatsoever. Seems like there may be intermittent issues after game updates and/or EAC updates, but I haven't run into this thus far.
Three essentials: (1) Force Proton Experimental. (2) Use Feral Gamemode (gamemoderun %command%). (3) Make sure you have Proton EAC Runtime installed. There might be a 5-10% performance hit at worst in my experience so far.
gamemoderun %command%
Last major update (1.14) temporarily broke the anticheat; I kept getting kicked due to a NullClient error. This was fixed by deleting some files (I believe, but don't quote me, it was the /common/sandstorm/EasyAntiCheat directory) and verifying the game through Steam to redownload the files.
Worthwhile experience and I'm very glad that recent light-speed breakthroughs with Proton have made it possible to play on Linux. Devs aren't officially working with Linux support in mind which leads to occasional issues, although Update 1.14 was apparently buggy as hell in general so it isn't just the Linux users.
Proton Experimental and Proton EAC Runtime are the bare essentials.
gamemoderun %command%
UPDATE: Have had problems with anticheat in 1.15 and subsequent patches, this time getting an Anticheat Integrity Violation. While the below fix is worth trying, I had to uninstall and reinstall the game after patches to fix it. Very annoying; I'm just lucky I have decently fast internet.
Major update (1.14) temporarily broke the anticheat; I kept getting kicked due to a NullClient error. This was fixed by deleting some files (I believe, but don't quote me, it was the /common/sandstorm/EasyAntiCheat directory) and verifying the game through Steam to redownload the files.
Game hitches at some point shortly after joining first match of the session for a few seconds, but is fine afterwards.
Proton Experimental and Proton EAC Runtime are the bare essentials.
DXVK_ASYNC=1 PROTON_NO_ESYNC=1 gamemoderun %command%
The game works well but has a tendency to have issues with anti-cheat for a week or two after major updates. Additionally, as of Feb 2024, there is a nuisance issue described below. Hopefully it gets fixed - Game runs great, but it's annoying to have to install an AUR package just to play this game.
The GNU C Runtime (glibc) update to 2.39 in Feb 2024 completely removed a hash function DT_HASH, which was used in older versions of EAC. To get the game to work properly, I had to install glibc-eac from the Arch User Repository, which is a version of glibc with the hash function patched back in. If the devs update the EAC version they are using, this would not be necessary; modern EAC versions have removed usage of DT_HASH about a year ago AFAIK specifically because it has been deprecated for a while and the glibc maintainers publicly stated their intention to remove it entirely.
Runs with slight performance loss 5-15% with Feral Gamemode enabled & 15-25% without. No other noticeable differences.
gamemoderun %command%
I am happy to say that this game runs with very minimal tweaking and a barely-noticeable performance loss. Forcing Proton 7.0-6 made the launcher pop up but it disappeared after a moment. Forcing Proton Experimental, the launcher opened and functioned as designed and the game launched and played the same as Windows. I didn't notice any gameplay problems; there was a slight performance hit, but this game is horrifically optimized to begin with (and the devs know that). I'm just lucky that I have a souped up PC at the moment.
Worked out of the box
No issues whatsoever playing with a friend over the internet.
DXVK_FRAME_RATE=144 WINEDLLOVERRIDES=libglesv2=d gamemoderun mangohud %command%
No Linux-specific multiplayer problems. Still lags because of high CPU demand in large fights. Hit cap of 144 fps most of the time, dipping down to 60-70 on my hardware in fights of 100+ people.
The game runs probably a bit slower than windows, but not by much. Game is very demanding in general, so hard to tell what Win10 vs Linux performance would be (also haven't played on Win10 on this PC). Needs launch option WINEDLLOVERRIDES=libglesv2=d
for the game's launcher to open properly. Thoroughly enjoyed and didn't have any issues that made me disappointed to be playing on Linux.
Worked perfectly out-of-the-box
No tweaks required on my system, worked as well as it would on Windows. Not a super demanding game in general, but glad to see it work so easily.
WINEDLLOVERRIDES=EasyHook,EasyHook64,EasyLoad64,NativeInterop,version,dinput8,ScriptHookRDR2,ModManager.Core,ModManager.NativeInterop,NLog=n,b gamemoderun %command% -USEALLAVAILABLECORES -cpuLoadRebalancing -ignorepipelinecache
Had an artifact where an object would appear as a stretched-out polygon, only maybe twice its real size, with very undefined edges, almost like more of a shadow artifact than a texture artifact? I've only noticed it once in several hours of playing.
Game launches out-of-the-box in windowed mode, which defaulted to 1280x720 on my system for whatever reason. However, after closing the game following my first session (where I changed a bunch of graphics settings!) I kept getting a problem where the game would hang at a black screen during launch before the shotgun loading splash animation.
This was frustrating to fix, but I eventually settled on the following:
- Switch to Proton-GE
StealBorrow launch options from another user here- VSYNC had to be disabled
If you need to get back into the game after getting this error, graphics settings can be restored to defaults by editing, or more simply deleting, the settings file; it will be replaced by defaults the next time the game is launched. It should be in the compatability data (fake C:\ drive to fool the game) folder, and on my system was located at:
/home/myusername/.steam/steam/steamapps/compatdata/1174180/pfx/drive_c/users/steamuser/Documents/Rockstar Games/Red Dead Redemption 2/Settings/system.xml
This didn't seem to affect my other settings e.g. mouse sensitivity, but YMMV.
After these tweaks I can just press play without any more finnicking and it works very well, no crashes, save issues, or etc.
gamemoderun %command%
Repeatedly booted from any servers due to EAC failure to initialize
You can play on the few servers that don't use EAC, but any that do will boot you out after about a minute or so. EAC is the only thing that breaks this game which is a shame since development ceased before the official Proton-compatible EAC implementations. Updating the anti-cheat may well be the only thing that would be needed to let this game work in a perfect world.
Borked
Tried default, experimental, and GE proton to no avail. Copied launch options from the other user here with a successful report, but it didn't help me. Game flickers open for a split second before crash to desktop.
gamemoderun %command%
Works with a bare minimum amount of "tinkering". I enabled Feral Gamemode, forced the use of Proton Experimental, and made sure I had the Proton EAC Runtime installed. There are only two minor speedbumps I encountered; one, running in windowed mode had very poor FPS in the main menu, which I've encountered on a number of games and is fixed by playing in Fullscreen which I do anyway. Second, upon changing the resolution of fullscreen to 1080p, the game became unresponsive and I had to close it and re-open it again. After that, I've had two or three play sessions with no issues.
Performance not out-of-this-world (pun intended) but I haven't played on Windows to compare; I think the graphics are just very modern, which is to say demanding. Sustained >80 fps in crowded areas/cities, easily hit 144 in empty areas / indoor dungeons, GPU maxxed out almost full time. Game looks great running on Medium with FSR. Didn't try with default Proton. Haven't had any bugs relating to controls, windowing, or stability; have only run into graphical bugs maybe twice with an NPC's face not loading in completely (which seems to be a well known bug in Bethesda's engine... People have been making memes about it for years).
Performance not out-of-this-world (pun intended) but I haven't played on Windows to compare; I think the graphics are just very modern, which is to say demanding. Sustained >80 fps in crowded areas/cities, easily hit 144 in empty areas / indoor dungeons, GPU maxxed out almost full time. Game looks great running on Medium with FSR. Didn't try with default Proton. Haven't had any bugs relating to controls, windowing, or stability; have only run into graphical bugs maybe twice with an NPC's face not loading in completely (which seems to be a well known bug in Bethesda's engine... People have been making memes about it for years).
bash -c 'exec "${@/Starfield.exe/sfse_loader.exe}"' -- %command%
I don't honestly remember where I found these launch options, but they open the SFSE executable through Steam, which is necessary for modding. If you only add the SFSE executable as a non-steam game to your library, Steam will try to make a whole new compatdata folder for it, thus "forgetting" your save games and the like. Adding these options makes the Steam "play" button run the SFSE loader, thus "bridging the gap" by telling Steam to use the original compatibility data folder.
Achievements didn't work for me on native Linux version. That was the only issue with native. No issues with Windows version on Proton.
If you don't care about Steam achievements, just click play. If you do, switch to any recent Proton version in the compatibility options and the achievements will work..
DXVK_FRAME_RATE=144 %command%
Works very well OOTB. Only issue I've encountered I'm not sure is necessarily even a Linux issue, but it could be: I can't Vsync higher than 60FPS. Even in fullscreen set to 1080p 144FPS in settings, Vsync would limit frames to 60FPS, and leaving Vsync off would leave framerate un-capped (meaning I would spike between 200-400, generating unecessary heat and noise, as well as coil whine on my RX 6000 series GPU). My workaround was to add the above launch option, which acts as a built-in frame limiter in DXVK. There's probably another launch option to force adaptive sync with DXVK that I haven't bothered to look up.