Gray Zone Warfare (2479810)

[A1RM4X]

Compatibility Report

• Name of the game with compatibility issues: Gray Zone Warfare
• Steam AppID of the game: 2479810

System Information

• GPU: Nvidia RTX 4090
• Video driver version: Nvidia 550.78
• Kernel version: 6.9.0-rc7
• Proton version: Proton Exp. Bleeding Edge

I confirm:

• that I haven't found an existing compatibility report for this game.
• that I have checked whether there are updates for my system available.

Symptoms:

• Game launches but get some random freezes ( like 10mn to boot to load screen).
• Really slow interface navigation
• Seems like EAC has been added game side, Linux enjoyers are not getting kicked.
• Can join a game but game crash depending on actions (like taking the helicopter will make the game freeze ie)

Reproduction

Install game and run it.

Thanks for your help!

[MattiasHansson]

Been messing around with it today aswell..
GPU: 7800 XT
Video driver version: amdgpu
Kernel version: Linux fedora 6.8.8-300.fc40.x86_64
Proton version: Proton Exp. Bleeding Edge and 9.0-1
Game launches fine using both proton9.0-1 and bleeding edge but I couldn't notice any differences
UI is terribly slow to use.
Helicopter rides are hit and miss and sometimes causes disconnects and maybe one frame every 5 seconds
This is a log from my last attempt using bleeding edge. I hit connect around line 6500 and ended with a helicopter disconnect

steam-2479810.log

[Weathelm]

GPU: 7900XTX
CPU: Ryzen 7700
Mesa drivers
Nobara 39
Proton version Experimental/9.0-1/Bleeding edge

In menu there are some lags, but nothing seriose. But loading into game almost always ended up with network connection issue for first time after launching the game and take ridiculously long time.
While in game, mostly I have around 150 fps on FHD EPic settings but UI env is laggy as hell. Interact with something like, Vendors or Inventory has so long response witch make it nearly unplayable due to inposibility to loot corpses mid combat. Also there are random freezes for about 10 seconds randomly, often ended with dead screen.
Freezes comes also when completing subtask or task, find new location etc.
Flying with heli is one big lag. Unlaging on ground in target location like 20 seconds after heli leaves.
Graphics ok, no issues or artefacts.

[marcjmiller]

To add my experience:
GPU: Radeon 6950XT
CPU Ryzen 9 5950X
Mesa: 24.0.3
Distro: PopOS 22.04LTS
Proton Version(s): HotFix/Experimental/9.0.1

From the logs:
Initially loading the game and after hitting deploy took 4 minutes (I timed it) and resulted in a Network Disconnect, but second try took 2 minutes but worked. Once in game, I got roughly the same framerate as I do running similar settings under Windows, however UI interactions cause freezes for 2-3 seconds and sometimes back-to-back. In this log I just messed around in the base camp, but typically helicopter rides start out well, then freeze for extended time and more often than not disconnects me.

Log running Proton Hotfix:
steam-2479810.log

[D2ans0]

GPU: Nvidia RTX 3060Ti
CPU: AMD Ryzen 5 3600
Drivers: Nvidia proprietary 550.78
Distro: NixOS 23.11
Proton Version: Experimental

UI freezes a lot, additionally after a freeze, the GPU utilization goes up to 95-100% and fps drops to 20 max. Helicopter rides drop down the fps to 1-2 with long freezes until I'm kicked off from the heli, after which the FPS goes back up to 20.

Log for Proton Experimental
steam-2479810.log

[jlmlr]

Game works fine with patch1 from devs!!!

First of all i hope that will help. And second sorry for my gibberish. I hope people can understand what i wrote down her.
System Info
GPU: 7800XT
CPU: Ryzen 5 5600x
Video driver version: amdgpu
Distro: Fedora 40 Workstation
Kernel: Linux 6.8.5-301.fc40.x86_64
RAM DDR4: 8GB(3200mhz) *4
window manger: x11
GNOME Version: 46
Monitor: 1080p

Proton versions:
run geProton9-1 / 11.05
ge-proton_9-1steam-2479810.log

Base works well. But ui freeze often. Helicopter flying was a big lag. And landing i fall from the map.

run geProton9-4 / 11.05
ge-proton_9-4steam-2479810.log

Base works well. But ui freeze often. Helicopter flying was a big lag. And landing i cant move my body. After this run my missions was closed and i must restart the mission don't know why. That i found out under windows.

---

Yesterday i played a bit under windows and kill the 10 scavs in sawmill see screenshot. The quest is now reset again.

Quest screenshot befor Part1 | 12.05

Quest screenshot aferward Part1 | 12.05

run proton experimental with lunch options | 12.05
gamemoderun mangohud VKD3D_CONFIG=dxr VKD3D_FEATURE_LEVEL=12_2 VKD3D_SHADER_MODEL=6_6 %command% --launcher-skip --intro-skip --skipStartScreen

Base works well. But ui freeze often. Fly was one big lag. Landing also as well freezing over maybe 20 seconds than a fall from map again. Server kicked me. I restarted my game.

part1:
proton experimental_part1_steam-2479810.log

part2:
proton experimental_part2steam-2479810.log

Game was restarted. Second join kicked me again. See screenshot.

Than i choose a other server. So my mission are reset see screenshot. Than i run a bit to the next village near by base. I killed 2 or 3 scavs not sure. Than i go to town and killed more scavs. The game freeze often but i think the shader is learning slow its. I was killed by scav. I clicked respwan and respawn in base. I exit the game to menu. I clicked close the game but there was blackscreen from game and proton sad sorry for crash.

[RaidTheWeb]

System Info
GPU: RX 6600
CPU: Ryzen 5 5600X
Mesa: 24.0.6-2
Distro: Arch Linux
Kernel: Linux 6.8.9-arch1-2
Proton version: Proton 9.0-1 and Proton Experimental (latest as of this comment).

Complete failure to launch. It exits before even getting to the splash screen without any notification.

Both versions using the launch options VKD3D_VULKAN_DEVICE=0 VKD3D_CONFIG=dxr VKD3D_FEATURE_LEVEL=12_2 VKD3D_SHADER_MODEL=6_6 %command% (as per numerous recommendations)

Proton Experimental:
experimental-steam-2479810.log

Proton 9.0-1:
9.0-1-steam-2479810.log

[kisak-valve]

Hello @RaidTheWeb, can you check if https://gitlab.freedesktop.org/drm/amd/-/issues/3343 is relevant to your system? A quick test would be to reboot into an older kernel and see how the game behaves.

[qjack666]

Proton: GE Proton 9.5 / Proton Experimental
flags: PROTON_LOG=1 %command%
GPU: AMD Radeon RX 6800XT
CPU: AMD Ryzen 7 5700x
RAM: 16GB
Video: kisak-mesa 24.0.7
Distro: Linux Mint 21.3
Kernel: Linux 6.5.0-28-generic / Linux 5.15.0-106-generic

Getting the same errors than most people. First connect gets a 0x00030004 network error (maybe server related?)
Getting long loading times, heavy stutters in inventory. Also getting some stutters from time to time. Heli is freezing but gets through

GE Proton 9.5 (Kernel 6.5.0-28)
steam-2479810.log

Proton Experimental (Kernel 5.15.0-106-generic)
steam-2479810.log

With the latest Patch (Patch 1) problem is non existant. We just get long Game start time (a few minutes)!

[benjmarshall]

OS: Manjaro Linux
KERNEL: 6.6.30-2-MANJARO
CPU: AMD Ryzen 7 5800H with Radeon Graphics
GPU: NVIDIA GeForce RTX 3070 Laptop GPU
GPU DRIVER: 550.78
Proton: GE Proton 9.5
Launch Options: VKD3D_VULKAN_DEVICE=1 mangohud gamemoderun %command%

I am now running the game fine after the developers added EAC support for linux but I see the same ~10min initial load time to the main menu. Steam Log attached in case it is useful.

steam-2479810.log

I am running GE Proton 9.5, but have also confirmed Proton Experimental and Experimental (bleeding-edge) as working.

[Exist2Resist]

OS: Fedora 40
KERNEL: 6.8.10-300.fc40.x86_64
CPU intel 14900ks
GPU: NVIDIA RTX 4090
GPU DRIVER: 550.78
Proton: Experimental-9.0-20240522
Launch Options: gamemoderun mangohud %command%

No issues with loads, I load almost instantly into the game. Actually faster than I do on Windows.
I do enable DLSS quality in game otherwise the frame rate is too low for my liking.
steam-2479810.log

Forgot to mention that split_lock_detect is set to off on my system...

To do this edit /etc/default/grub add the highlighted line and run grub2-mkconfig then reboot.

[Swivelgames]

Proton: GE Proton 9.6-1
GPU: AMD Radeon RX 6850XT
CPU: AMD Ryzen 7 5800X3D
RAM: 64GB
Video: Mesa 24.1.0-arch1.1
Distro: Arch Linux
Kernel: Linux 6.9.3-zen1-1-zen

36 Hours, No Crashes or Long Load Times

I have about 36 hours on this game and haven't experienced any crashes or long loading times.

Until Latest Update

However, after the latest update, I was getting kicked because of EAC. I found that this was due to an old workaround that Star Citizen lug-helper left over in my /etc/hosts. Commenting out or removing this line out in my /etc/hosts fixed that issue:

127.0.0.1	modules-cdn.eac-prod.on.epicgames.com #Star Citizen EAC workaround

EAC To Blame?

I can now join games again, but it takes about 10 minutes to get to the Main Menu, like others are experiencing.

This leads me to believe that the 10 minute load time in the beginning has to do with EAC; potentially with EAC initializing?

May try split_lock_detect

I haven't tried split_lock_detect=off in my kernel options yet, but running lscpu | grep split_lock_detect doesn't return anything, suggesting that it isn't supported by my CPU. I'll give it a try anyway and report back.

[Swivelgames]

Game Version: GZW 5.3.2-70657-Shipping-Heroic Production Cloud

In terms of the 10 minute startup time, it seems like I keep getting this in my proton logs when I first start the game up:

59433.230:00cc:00d0:warn:seh:dispatch_exception RPC_S_SERVER_UNAVAILABLE exception (code=6ba) raised

Here's my proton logs:

steam-2479810.log

After that, it continues to repeat this over and over again until the Main Menu finally loads:

59765.788:0190:0294:fixme:mfplat:bytestream_file_Close 0000000021147110
59765.794:0190:05f0:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
0:04:18.522416199 406349 0x7ba750097760 ERROR             audio-info audio-info.c:302:gst_audio_info_from_caps: no rate property given
0:04:18.596719710 406349 0x7ba7b8073190 ERROR             video-info video-info.c:546:gst_video_info_from_caps: no format given
0:04:18.601615121 406349 0x7ba7b8073190 ERROR             audio-info audio-info.c:302:gst_audio_info_from_caps: no rate property given
59765.881:0190:02d0:fixme:mfplat:topology_loader_Load iface 000000002114E020, input_topology 00000000492B2D00, ret_topology 000000006B1DFCE8, current_topology 0000000000000000 stub!
59765.903:0190:02d0:fixme:mfplat:audio_renderer_get_service_GetService Unsupported service {866fa297-b802-4bf8-9dc9-5e3b6a9f53c9}, interface {0a9ccdbc-d797-4563-9667-94ec5d79292d}.
59765.903:0190:02d0:fixme:mfplat:media_source_QueryInterface {6ef2a662-47c0-4666-b13d-cbb717f2fa2c}, 000000006B1DFBC8.
wine: setpriority -10 for pid -1 failed: 3
59765.905:0190:05f8:warn:threadname:NtSetInformationThread Thread renamed to L"audio_client_timer"
59766.004:0190:02d0:fixme:mfplat:stream_queue_sample Dropping sample 0000000049313D10, time 853333, clocktime 1137338, systime 597660179618.
59766.020:0190:02d0:fixme:mfplat:stream_queue_sample Dropping sample 0000000049313DC0, time 1066666, clocktime 1238979, systime 597660281259.

Right before this begins repeating, the logs show:

59504.402:0190:02e4:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
59507.275:0190:02e4:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\msdmo.dll" at 00006FFFFAFD0000: builtin
59507.279:0190:02e4:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\winegstreamer.dll" at 00006FFFFB000000: builtin
59507.280:0190:02e8:warn:threadname:NtSetInformationThread Thread renamed to L"wine_mmdevapi_notification"
59507.296:0190:02ec:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
59507.298:0190:02f0:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
0:00:00.093227314 406349 0x7ba750001a90 ERROR             video-info video-info.c:546:gst_video_info_from_caps: no format given
59507.383:0190:02d0:fixme:mfplat:topology_loader_Load iface 000000002113A5F0, input_topology 000000002111FD30, ret_topology 000000006B1DFCE8, current_topology 0000000000000000 stub!
59507.384:0190:02f8:warn:threadname:NtSetInformationThread Thread renamed to L"SlateLoadingThread1"
59507.384:0190:02f8:trace:seh:dispatch_exception code=406d1388 flags=0 addr=00006FFFFFC1CE87 ip=6fffffc1ce87
59507.384:0190:02f8:trace:seh:dispatch_exception  info[0]=0000000000001000
59507.384:0190:02f8:trace:seh:dispatch_exception  info[1]=00000000730efe80
59507.384:0190:02f8:trace:seh:dispatch_exception  info[2]=00000000000002f8
59507.384:0190:02f8:warn:threadname:dispatch_exception Thread renamed to "SlateLoadingThread1"
59507.385:0190:02f8:trace:seh:call_vectored_handlers calling handler at 00006FFFFB85BA70 code=406d1388 flags=0
59507.385:0190:02f8:trace:seh:call_vectored_handlers handler at 00006FFFFB85BA70 returned ffffffff
59507.388:0190:02d0:fixme:mfplat:media_source_QueryInterface {6ef2a662-47c0-4666-b13d-cbb717f2fa2c}, 000000006B1DFBC8.
59507.407:0190:028c:warn:vkd3d-proton:d3d12_command_list_QueryInterface: {09e0bf36-54ac-484f-8847-4baeeab6053f} not implemented, returning E_NOINTERFACE.
59507.423:0190:02b0:info:vkd3d-proton:dxgi_vk_swap_chain_recreate_swapchain_in_present_task: Got 3 swapchain images.
59507.458:0190:02fc:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
59507.458:0190:0300:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_timerqueue"
59507.462:0190:0304:warn:threadname:NtSetInformationThread Thread renamed to L"FAsyncLoadingThread"
59507.462:0190:0304:trace:seh:dispatch_exception code=406d1388 flags=0 addr=00006FFFFFC1CE87 ip=6fffffc1ce87
59507.462:0190:0304:trace:seh:dispatch_exception  info[0]=0000000000001000
59507.462:0190:0304:trace:seh:dispatch_exception  info[1]=000000007808fe80
59507.462:0190:0304:trace:seh:dispatch_exception  info[2]=0000000000000304
59507.462:0190:0304:warn:threadname:dispatch_exception Thread renamed to "FAsyncLoadingThread"
59507.462:0190:0304:trace:seh:call_vectored_handlers calling handler at 00006FFFFB85BA70 code=406d1388 flags=0
59507.462:0190:0304:trace:seh:call_vectored_handlers handler at 00006FFFFB85BA70 returned ffffffff
59507.471:0190:0308:warn:threadname:NtSetInformationThread Thread renamed to L"ScreenSaverInhibitor"
59507.471:0190:0308:trace:seh:dispatch_exception code=406d1388 flags=0 addr=00006FFFFFC1CE87 ip=6fffffc1ce87
59507.471:0190:0308:trace:seh:dispatch_exception  info[0]=0000000000001000
59507.471:0190:0308:trace:seh:dispatch_exception  info[1]=000000006a24fe80
59507.471:0190:0308:trace:seh:dispatch_exception  info[2]=0000000000000308
59507.471:0190:0308:warn:threadname:dispatch_exception Thread renamed to "ScreenSaverInhibitor"
59507.471:0190:0308:trace:seh:call_vectored_handlers calling handler at 00006FFFFB85BA70 code=406d1388 flags=0
59507.471:0190:0308:trace:seh:call_vectored_handlers handler at 00006FFFFB85BA70 returned ffffffff

For context, my audio setup is as follows:

lib32-libpipewire 1:1.0.7-1
lib32-pipewire 1:1.0.7-1
lib32-pipewire-jack 1:1.0.7-1
libpipewire 1:1.0.7-2
libwireplumber 0.5.3-1
pipewire 1:1.0.7-2
pipewire-alsa 1:1.0.7-2
pipewire-audio 1:1.0.7-2
pipewire-jack 1:1.0.7-2
pipewire-pulse 1:1.0.7-2
qemu-audio-pipewire 9.0.0-1
wireplumber 0.5.3-1

[benjmarshall]

Replying to #7721 (comment)

I have the same log output during the 10 minute load.

Audio Setup:

lib32-libpipewire                 1:1.0.7-1                        multilib  630.4 kB
lib32-pipewire                    1:1.0.7-1                        multilib  3.9 MB
lib32-pipewire-jack               1:1.0.7-1                        multilib  419.4 kB
libpipewire                       1:1.0.7-2                        extra     1.5 MB
libwireplumber                    0.5.2-2                          extra     1.6 MB
pipewire                          1:1.0.7-2                        extra     2.9 MB
pipewire-audio                    1:1.0.7-2                        extra     4.3 MB
pipewire-jack                     1:1.0.7-2                        extra     634.5 kB
pipewire-session-manager          1:1.0.7-2                        extra     
wireplumber                       0.5.2-2                          extra     984.4 kB

[benjmarshall]

Replying to #7721 (comment)

This is very interesting! If I add that same line to my hosts file then I get an instant load - quicker than on my Windows install. I can find and initiate connection to server, but then before I load in I get the 0x00020008 error (client failed to load the anti-cheat module).

Proton log for that run here:
steam-2479810.log

I have tried loading the game with that hosts entry, but then removing it before trying to connect to the server but unfortunately I still get the same error. Proton log for that run added here as well for completeness.
steam-2479810.log

So it looks like the EAC module is loaded during that startup period and doesn't load if that URL is blocked. I am not sure if it is the EAC module load itself that causes the delay or if the failure to load this actually skips some other processes which speeds up the launch. I will try and compare the logs to see if they give any clue.

UPDATE:
Comparing logs doesn't give anything really obvious away. The logs where EAC module fails to load (quick start time) has a lot less of the audio related output mentioned above and highlighted by @Swivelgames.
Those logs also have much fewer of these statements:
20218.379:018c:0294:warn:vkd3d-proton:d3d12_low_latency_device_SetLatencyMarker: PRESENT_START_NV is non-monotonic 70380000 <= 70380000.
I get hundreds of these in my original log with the long startup but very few in the log that doesn't load EAC module and starts quickly. Does anyone know what this warning indicates?

[benjmarshall]

Further information to the previous post. It looks like GZW is using an Epic Online Services version of EAC which loads the library required at launch time. Below is a log from the EAC process when starting the game normally.
anticheatlauncher.log

Compared to a log of starting the game with the URL blocked via hosts entry.
anticheatlauncher.log

The game is launched in both cases, but in the second case the game exe is laucnhed directly rather thanb through the EAC library. This can be confirmed by comparing process trees for the two scenarios. First with EAC enabled, and then disabled:

Edit:
Looks to me like in the process tree for EAC enabled we can see the game binary being launched with an explicit call to the GEProton wine binary, whereas with EAC disabled this isnt the case and game binary launched directly.

Could the EAC process be trying to launch wine inside wine? Or is the non-EAC launch not using GEProton as I selected and is instead running in a wine env within the steam runner rruntime?

[Exist2Resist]

Replying to #7721 (comment)

The thing is that host file entry worked previously and allowed people to play. Myself included. With a caveat though, if I logged into a distant server, let's say South Africa I would get kicked due to EAC.

[Swivelgames]

@Exist2Resist It did indeed. The problem is that it didn't enable EAC for Linux, it intentionally allowed the circumvention of it. Anti-cheat works on Linux, and it should.

Don't get me started on client-side Anti-Cheat and how utterly flawed the logic is there (as a Software Engineer of 20 years, that's like sanitizing your inputs on a web frontend, and just assuming that it's clean on the backend; it's just stupid 😒 -- And also kernel-level anti-cheat is a massive privacy concern and potential attack vector for bad actors. But I digress).

At the end of the day, though, the reason Linux support is lacking in the game development community is the false assumption that you either have to (1) disable anti-cheat entirely, or (2) you have to somehow have access to the kernel.

Disabling anti-cheat entirely, rather than improving support for it, doesn't improve our odds of gaining Linux support. If anything, it enables Linux support for early development, only to be locked out of the game entirely once the game launches (something that many Linux gamers have experienced; and something I fear we'll see once Star Citizen gets closer to launch).

---

tl;dr: Host file entry was only ever going to be a temporary solution, never a permanent one. It only prolonged the inevitable. We need proper improvements implemented into Proton.
🙂 👍