FWIW, I get the same results on an Intel NUC (with Kaby Lake GT3e graphics) and this same install (it's on a Samsung SSD that I am using to test this on various machines). I also get the same results on two other Linux machines (not using this SSD, but installed on the internal drive(s)) but neither of those can actually run Vulkan (laptop 720m and desktop nVidia 460), so that's somewhat expected (not sure if Proton will fall back to OpenGL if it can't initialize Vulkan).

FYI: disabling Vk and forcing Proton to use OpenGL does not help.

It turns out that it is possible, but very intermittent, to run the game. Proton 3.7-6 did actually let me run the game, and drop into a match, but crashed coming back to mechlab. Most of the time, I get the "unexpected error" popup during the splash screens though.

I have experienced the same issues (crash on splash screen, every time for me) with both Proton 3.7-8 and 3.16-6 Beta. I decided to try the instructions found here to compile a modified version of wine from source: https://mwomercs.com/forums/topic/268847-running-the-game-on-ubuntu-steam-play/page__st__20

I used the wine stable branch (commit 6b42eae19f3bd9a4f4412fcb21c2f46a4c95bbfd), and modified dlls/ntdll/path.c per the instructions:

$ git diff dlls/ntdll/path.c
diff --git a/dlls/ntdll/path.c b/dlls/ntdll/path.c
index 11483fabba..44a99a1fd9 100644
--- a/dlls/ntdll/path.c
+++ b/dlls/ntdll/path.c
@@ -648,10 +648,8 @@ static ULONG get_full_path_helper(LPCWSTR name, LPWSTR buffer, ULONG size)
 
     RtlAcquirePebLock();
 
-    if (NtCurrentTeb()->Tib.SubSystemTib)  /* FIXME: hack */
-        cd = &((WIN16_SUBSYSTEM_TIB *)NtCurrentTeb()->Tib.SubSystemTib)->curdir.DosPath;
-    else
-        cd = &NtCurrentTeb()->Peb->ProcessParameters->CurrentDirectory.DosPath;
+    //modified by tempestfarer 2/9/19 per https://mwomercs.com/forums/topic/268847-running-the-game-on-ubuntu-steam-play/page__st__20 
+    cd = &NtCurrentTeb()->Peb->ProcessParameters->CurrentDirectory.DosPath;
 
     switch (RtlDetermineDosPathNameType_U(name))
     {

I made sure I had the openal, pulse and vulkan development libraries installed on my system (Debian 9, i7-5930K, Nvidia 980 (396.18)) and after compiling wine the game works just fine (though I do get, and ignore, the "video card not supported warning"). My main gripe is that I don't have access to DLC purchased through Steam, since I am having to launch the game through an external script.

Just hunted down the wine bug for this: https://bugs.winehq.org/show_bug.cgi?id=46022

Been playing semi-regularly for a little over a week now, and after switching the VOIP audio to use Direct Sound to address an audio quality issue the game works perfectly using the above mentioned patched version of wine, though it does sometimes crash on shutdown leaving a dead window to kill manually.

With Proton 6.5-GE-2 everything but voice chat works for me. Voice chat -used- to work, but quit when I installed a new microphone.

@DonKatsu I've been unable to reproduce this with Proton Experimental 20230801 or with a Bleeding Edge build.

Please add PROTON_LOG=1 %command% to the game's launch options and attach the generated $HOME/steam-$APPID.log to this issue report as a file. Also, please copy your system information from Steam (Steam -> Help -> System Information) and the contents of Steam Runtime Diagnostics from Steam (Steam -> Help -> Steam Runtime Diagnostics) and put them in a gist, then include a link to the gist in this issue report.

System info, Experimental 20230801 log from a live match.
Launch options were PROTON_LOG=1 mangohud WINE_CPU_TOPOLOGY=6:0,1,2,3,4,5 %command%.

If it helps narrow it down, GE-Proton 8-9 does not give me this problem, but GE-Proton 8-11 does.

@DonKatsu Thank you for the info! I tried to reproduce this and match your video, but I'm still not seeing it which makes it harder to investigate. I was getting into a quick match, opening that menu with "e" and then moving my cursor to the edge of the area that it is captured within for the talk menu, and then letting go of "e" to close the menu. I did not see the kind of camera movement to the bottom right that is in your video.

Could you try without mangohud? Also - I was testing with Arch instead of Fedora, but the same kernel and using KDE Plasma + X11 which seems to match your system. Can you think of anything else about your desktop environment or cursor that is unique?

Also - I'm uploading a couple of builds with the lock code "mech" here: https://www.codeweavers.com/xfer/alasky/Proton_testing/ - could you try both of these builds and see if you see the cursor regression or not with each? Instructions to test:

1. Create ~/.steam/steam/compatibilitytools.d folder if not already present.
2. Drop builds in compatibilitytools.d folder and untar
3. Reboot Steam. Builds should now show up in list of Proton versions available to select via dropdown menu.

@alasky17 I'm using wayland. I don't believe I have any applications that could be interfering with the mouse.
The scoreboard closing causes the camera to snap as well on affected versions.

Experimental updated to 20230809, still had the issue with or without mangohud.
Your experimental-8.0-20230705b: issue not present
Your experimental-8.0-20230706: issue not present
Logs: steam-342200 custom1.log steam-342200 custom2.log

@DonKatsu Thank you! I somehow managed to miss that you were on Wayland when looking at the system info, whoops! That was the key - this issue is not present on X11, only on Wayland because Wayland is doing something funky.

Interestingly, what you perceived to be a regression is actually an improvement in behavior in my testing. Before the change, the cursor was not captured correctly - it is supposed to be stuck in that small central area where the radial menu is. After the change, the cursor is correctly captured in the central area, but Wayland has added a fun quirk with the bottom-right camera movement.

We will still look into this issue -- if this is truly a Wine bug and not a Wayland bug, it will be interesting to fix. It is likely that the entire patchset related to this change will be in experimental for a while, so in the meantime you can either use Proton-stable or X11 in order to avoid this issue.

Oh yeah, I did notice that for a while the cursor wasn't resetting to the center of the screen after using the command wheel.
But I had noticed that behavior was fixed with whatever version GE-Proton 8-7 was based from. (Released July 21st)
So then after that was when Experimental 20230801/GE-Proton 8-10/11 started that camera snap behavior.

@DonKatsu I'm a bit confused - are you saying that there was a build where the cursor was correctly locked to the central part of the screen and there was no camera snap behavior? In my testing, the commit that caused the cursor to correctly stay in the middle of the screen is also the commit that introduced the camera snap behavior, so there was never a point on KDE+Wayland where this was functioning 100% correctly -- for me it was either broken in one way or the other.

Edit: please note - in my testing, the camera snap is specific to KDE+Wayland. If you were using a different WM at any point, you would not have seen the camera snap.

@alasky17 there was a build where the cursor was correctly locked to the central part of the screen and there was no camera snap behavior

Yes, but now I'm not entirely sure what's up after trying GE-Proton versions from before the 8-7 release, which was when I noticed that cursor re-centering started working again. I've been using KDE with Wayland since Fedora 36, no changes there.

Like I said, I noticed cursor re-centering was working again for me when I got GE-Proton 8-7. (Jul 21st)
Then the camera snap thing started after August 1st's Experimental/GE-Proton 11.
But I tried GE-Proton 8-6 again, and cursor re-centering still works. Same with 8-1 and even 7-55. Fresh prefixes each time.

The only thing I can think of is that I got the KDE Framework 5.108.0 update on July 20th, the day before GE-Proton 8-7 released. But that changelog doesn't mention anything for Wayland.

One other thing I didn't notice. On versions with the commit that causes the camera snap, when using the command wheel there's a bounding rectangle that surrounds the options which the cursor can't move past. I don't remember that being a thing before this. But if that's how it's supposed to behave normally on Windows I wouldn't know as I've only played this through Proton. Any other Proton version allows me to move the cursor to all corners of the screen with the wheel open.

@DonKatsu I guess I'm not sure what you mean by cursor recentering - I had thought you meant the "bounding rectangle" as you called it, but clearly you meant something different :D But it seems like the cursor recentering is generally working even with current experimental, I'm not going to worry about it unless you say it is broken now :)

I checked on Windows and the bounding rectangle is Windows behavior. It was this improvement that also caused the camera snap. The change was introduced to fix another wayland regression and appears generally correct since it also improved the bounding rectangle behavior and captures the cursor properly now. Since the camera snap only happens very specifically on KDE+Wayland, it is possibly a bug somewhere other than Wine. We will still look into it though and hopefully can improve the behavior so that we have both the bounding rectangle and no camera snap :D

@DonKatsu I have some good news - Experimental bleeding-edge has a fix for the camera down+right drift that is working in my testing. This will be included in the next experimental release, but currently is only available if you select the "bleeding-edge" beta option for Experimental. Please let me know if this fix works for you and if you see any other regressive behavior :)

@alasky17 Yep, seems to be working perfectly. Mouse bound to the command wheel, cursor recentering, no camera issues.

Since I last posted in this issue I moved to CachyOS (Arch based). I played a bit of MWO with no problems while it was still on Plasma 5.27, but ran into mouse snapping again on Plasma 6.0.2. Not sure if it's a leftover of the old problem as I didn't really use the following technique previously, or if it's something new with Plasma 6 Wayland. But I've seen new reports on other games with similar behavior again.

I ran into it while playing a mech with gauss rifles. I was holding a charge with mouse 1 and tapped the command wheel to cancel it. After the wheel closed, I let go of mouse 1 and the snap happened.
Experimenting in the testing grounds, I found that clicking and holding after the wheel is open, then releasing after it's closed also does it. It also seems to happen more frequently if you open the command wheel, then mouse click after it closes. It's guaranteed the first time of a map load if that's done immediately.

Also found that the command wheel is unbound again in Proton 8.0-5? It's still working in Experimental (which Cachy's is based on) and 9.0 Beta.

Here's a clip of it in action. I used Proton Experimental, but it happens on 8.0-5 and 9.0 Beta. First was experiencing it with proton-8-cachyos. Still using Wayland, and the game is in "full window" like before.
Gauss is used for illustrative effect, it still happens if no weapons in a group bound a mouse button.

I don't know if the bit at the end is relevant or if it happens on Windows too, but I noticed it while testing.
If you have a weapon group assigned to a keyboard key and hold it, gauss rifles will charge again after the command wheel closes. With a held mouse click you have to release and click again, and there's a second delay after the wheel closes before clicks register.

EDIT: This also happens occasionally. When it does, it persists between map loads and game restarts (so definitely Plasma?).
The mouse look gets stuck in an up and left direction. Hitting arm lock brings it back in but moving the mouse shoots it back. Same with center torso.
It's possible to break out of it, and afterwards it goes back to just doing the above things for the rest of that session.
EDIT 2: Since about yesterday (27th), it seems to be back to normal? I had set "Touch Mode" in General Behavior to "Never enabled" which was suggested in a thread for similar behavior, which didn't seem to help. But since there doesn't appear to have been any relevant Plasma updates I can't imagine why?

Hi @kisak-valve I'm unable to launch the game. It worked before, but now it doesn't. Launcher pops up in a black screen, then disappears and nothing happens: proton experimental

https://github.com/user-attachments/assets/7af1c774-2292-4699-b864-182aa32f6f8a

Operating System: Garuda Linux
KDE Plasma Version: 6.6.4
KDE Frameworks Version: 6.24.0
Qt Version: 6.11.0
Kernel Version: 6.19.11-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-6500 CPU @ 3.20GHz
Memory: 16 GiB of RAM (15.6 GiB usable)
Graphics Processor: NVIDIA GeForce GTX 1050 Ti
Manufacturer: MSI
Product Name: MS-7972
System Version: 2.0

Hello @kisak-valve

log: steam-342200.log
SRD: https://gist.github.com/krixkrax1/248dafb5138573902ed59d1832eb8508

edit for plus info:
The game previously worked on openSUSE Tumbleweed as recently as early March, but since switching to Garuda (Arch-based), it fails to launch. I am using NVIDIA driver 580.142, the max supported version for my Pascal GPU, which is the same driver I used on openSUSE. I’ve tested multiple Proton versions (GE, Cachy, 9.0, 10.0, and Experimental) with no luck.

The only way I can get it to launch is by using PROTON_USE_WINED3D=1, but this forces OpenGL and kills performance compared to Vulkan. Grok AI suggested this is a known CryEngine issue and recommended the WINEDLLOVERRIDES="d3d9=n,b" parameter, but that didn't help. It’s frustrating because the game ran perfectly on openSUSE without any launch parameters, and since there are no recent reports of this on ProtonDB, it feels like an isolated issue.