Compatibility Report

Tried to play this morning and found the same problem, seems they've added some kind of anti-cheat as of yesterday's update.

@AWBuchanan7
Yes indeed started with the update, I thought I was able to bypass using GE's fork, but then I get the API error.

Using Proton 5.0-7-alyx from here, I am able to get past the Unity crash window and into the game, but immediately get hit with this Steam API init error:

I think this is because the err:steamclient:create_win_interface Don't recognize interface name: SteamUser021 problem is addressed here but not the err:steamclient:create_win_interface Don't recognize interface name: STEAMUSERSTATS_INTERFACE_VERSION012 problem?

Edit:

• Added log. steam-1217060.log
• Looks like Torchlight III is in the exact same boat.
• Missed the GE release yesterday, only tested GE-5 previously and it would crash, but GE-6 seems to get to the same point as Proton 5.0-7-alyx.

@AWBuchanan7 My test with GE was with the latest release as of today and did get the exact same as your screenshot.

so is it an anticheat issue or a missing implementation in proton ?

@sigzegv Seems to just be a missing implementation, but since it was not an issue prior to the addition of anti-cheat in yesterday's update, I don't know whether there is or isn't an anti-cheat issue as well.

Game is working again after 9/25/2020 Major Update
From the patch notes:

Fix the issue that players using Linux could not launch the game with Proton

Game seems to be running smoothly with latest proton, have not played a full run, but no game issue popped up so far.

If any of you encounter mouse issue such as dual-wielding skill get cancelled when pressing both left and right mouse button at the same time. Disable middle mouse button emulation in your system settings to fix the problem.

Fedora 33 cinnamon have this emulation enabled by default for unknown reason.

Hello,
I have been playing Gunfire Reborn for 36+ hours, all in multiplayer, it works great.
I noticed a problem and I'm not sure if it's related only to this game: if I launch the game from the system tray, it runs fine but in game I have heavy random fps drops, they are big spikes.
If I, instead, launch the game through the main Steam window the Vulkan Shader pre-caching seems to always popup and those fps drops disappears. It is 100% reproducible and the difference is immense: I vary from a min/max of 20~60+ to an almost stable 60+fps (I cap at 60 but, uncapped, is definitely more).

The only reason I can think it's the game recompiling shaders when launched from the system tray. Sound like a bug but I'm not sure if it's unique for this game or it can be a generic Proton problem.

I tested on Fedora 33 KDE with Proton 5.13 and 6.3.2.

I am not able to start the game ....
steam-1217060.log

I am also unable to start the game, it seems that the game is not recognising my GPU. I tried updating my mesa, downgrading and also used different Proton versions. All of these, other than 5.13-6, crash on the start screen; 5.13-6 goes to the banner and then crashes.

steam-1217060.log

Game is completely stuck when it's fullscreen. On GNOME, if I open the window overview mode, I see the game working and animating, but as soon as it goes full screen, it's completely frozen.

Using wayland, Fedora 35 on a RX 6800 XT, Proton 6.3-8 or Experimental.

Hello @1player, that sounds like a compositor or Xwayland issue. Can you check if the same happens with an X-based session?

Works fine with GNOME loaded in Xorg mode. Any way I can force the game to run in Xorg mode while Wayland is active?

Actually, I've managed to find the root cause: I'm using MangoHud with vsync and fps limiter enabled. Starting the game (in Wayland) with env MANGOHUD=0 %command% works fine. So either MangoHud's vsync=3 or fps_limit=57 settings I'm using is causing the issue. Note that MangoHud doesn't cause any issue on any other game.

EDIT: in fact the issue presents with MangoHud settings vsync=0 or vsync=3. Removing this option fixes it. I'll open a bug report on their repo.

Game is not launching on Steam Deck, OS version 3.4. Game launches fine in Desktop mode, but not in gaming mode.

I added the command and the game launched fine with it. Here is the log file you requested. Apologies if I made or make any mistakes sending this and commenting on this thread. This is my first time using Linux and Proton, just wanted to help out haha. Also I heard the game was launching fine on 3.3.3, but I can't confirm that. I just picked up the game last night on the Steam Winter Sale.
steam-1217060.log

+1 crashes on startup right after loading splash. Thank you!

Can't play this on steam os 3.4 on my steam deck. Tried adding the launch command proton logging, which did launch the game but I have no inputs other than touchscreen and just the steam button. All other inputs don't work. Same issue when launching from desktop mode: can launch, no buttons work.

Checking on here, the steam deck reddit, and on the Gunfire reborn community hub, believe the steamos 3.4 update broke the game unless running on desktop or with the log command. Believe it was working before 3.4 because it got marked as deck verified back in February this year as well as others playing it on deck on youtube, should be looked into along with Forza 5.

I can also manually confirm it happens on my end too, highly recommend bumping it down to unsupported

I can also confirm the game boots fine with the proton_log command, also seeing similar issues from others mentioning Stalker Clear Skies too (I know it's marked as unsupported already, but apparently it's now crashing on startup like Gunfire Reborn)
steam-1217060.log

Just wanted to confirm that adding the PROTON_LOG=1 %command% command also works for me on Steam Deck. Thank you @kisak-valve!

I have the same behavior, it started after SteamOS 3.4 update. Seems like proton is indirectly affected by this since it's only happening in game mode and only after system update, not proton itself. I see people have similar issues in unsupported stuff (link), though I'm not sure if it's gamescope related or not.

PROTON_LOG=1 %command% works for me as well on Steam Deck; but I find it curious that enabling the logging causes the game to launch correctly as a side effect. I guess one of the environment variables set here must be responsible?

It would be great to have a proper solution to this, especially in case the performance impact of enabling the logging is non-negligible (the game runs flawlessly on the Deck still, but less power draw is always nice).

Anyway, this game is currently still Deck Verified, even though it won't launch (except in Desktop Mode) without this workaround, which is likely confusing to people when it's advertised as "Great on Deck".

Yeah, it would be nice if a fix could be looked into for steamos 3.5, or at the very least telling the ones in charge to bump it down to unsupported, least until this gets fixed.

Apparently proton Experimental got an update that should fix it.

Update: Can confirm, game no longer needs the "PROTON_LOG=1 %command%" command to avoid crashing on startup.

Using [Ubuntu 22.04.03 LTS] Some kind of error is still happening, Routing through all the Steam-Protons, and still gets the; “Error at Hooking API”-when launching the game.

My Proton Experimental version upgraded there now, and now my Gunfire Reborn games get keys stuck when holding down either W A S D, it's hard to repeat on purpose and is seemingly random.

The issue has appeared again in one of the newer versions of Proton Experimental.

As of recently, with Proton 11 the mouse cursor is no longer locked anymore, but on Proton 10 it locks perfectly fine. Does anyone else have this?
Using Wayland KDE on CachyOS.

@Yi3d hmm, I'm checking with plasma wayland too, and I don't see a difference in behavior between proton 10, 11 and experimental. I'm running the game windowed, and during a run the cursor will remain locked as far as I've tried, it only allows you to leave the window when menus are available. What do you see in your end?

@Yi3d hmm, I'm checking with plasma wayland too, and I don't see a difference in behavior between proton 10, 11 and experimental. I'm running the game windowed, and during a run the cursor will remain locked as far as I've tried, it only allows you to leave the window when menus are available. What do you see in your end?

Hm, I did a bit of testing regarding the windowing (video settings in-game). It looks like Fullscreen with Proton 11 causes the cursor to not lock for me, but Borderless Fullscreen does lock the cursor just fine.
Possible regression maybe? Sometimes it doesn't lock right away for Proton 10, but if I click on the game (or alt-tab works) then it will lock.

Fullscreen Proton 10.0-4

https://github.com/user-attachments/assets/85de25b3-4562-45dc-9d36-47043fff20d1

Fullscreen Proton 11:

https://github.com/user-attachments/assets/5a158a70-469c-42c7-b72a-5d8123e6cee1

Borderless Fullscreen Proton 11:

https://github.com/user-attachments/assets/5ad56693-0958-4140-aa61-269d22186595