@gardotd426 Is there the issue with the base game without mods? (and what version is it - gog, steam)
Also please explain in more detail what graphics settings were used and how/which "dx11 mode" you need to use (as far as I remember, it is included as a non-standard option related to lighting or something like that) in order to get the problem.

@Iglu47 it's a standalone mod and doesn't need any of the official games. It uses a custom version of the original X-ray afaik. I think the common way to download it is moddb https://www.moddb.com/mods/stalker-anomaly

Edit: The legality of some of the standalone mods have been a bit ambiguous afaik since most don't check for ownership of the main games, but i don't know the details.

@Iglu47, @Blisto91 is right. There is no base game. It's standalone. And yeah that's the correct launcher.

I have a script that the Lutris installer uses to grab the 7z archive for you. This is all the script is:

#!/bin/bash
url="$(wget -q -O -  https:// www.moddb.com/downloads/start/207799 | grep /downloads/mirror/207799 | cut -d= -f2 | cut -d">" -f1 | cut -d";" -f1 | grep https | jq -r)"

wget -q $url -O Anomaly-1.5.1.2.7z --show-progress

Put that in a script and run it and you'll have the archive. Extract that into a wineprefix inside /path/to/wineprefix/drive_c/Program\ Files/Anomaly and then run AnomalyLauncher.exe

If you want to skip the launcher and go straight to the crash, bin/AnomalyDX11.exe or bin/AnomalyDX11AVX.exe is the direct executable(s).

Also please explain in more detail what graphics settings were used and how/which "dx11 mode" you need to use (as far as I remember, it is included as a non-standard option related to lighting or something like that) in order to get the problem.

When you launch the launcher, it literally just asks you your resolution and DirectX API. That's it. Select 11. That's it.

The game won't ever launch after that (unless you revert the bad commit).

Stalker Anomaly 1.5.2 works fine for me (nvidia pascal, 525.116.04) on curent master.

StalkerAnomaly_dxvk.log

I will test with 535.54.03 driver.

I manually updated DXVK files for current Proton experimental_8.0 - and got this crash with the initially described error.
steam-stalker-anomaly.log (it's still on 525.116.04)
probably my local build of Wine just has a very old winevulkan.

I manually updated DXVK files for current Proton experimental_8.0 - and got this crash with the initially described error.
steam-stalker-anomaly.log (it's still on 525.116.04)
probably my local build of Wine just has a very old winevulkan.

Yeah that makes sense, it would make zero sense for me to have been able to completely bisect this bug to a specific commit and then it somehow be a 535 thing, when reverting the commit fixes it. I'm sure that's possible but it just wouldn't make sense to my admittedly less-knowledgeable brain.

@Iglu47 If you rebuild DXVK with the bad commit reverted and replace the dlls in Proton, does the crash go away?

So, I cloned a fresh git, created a patch from the bad commit then reverted it, and removed the following section from the patch:

@@ -804,9 +833,27 @@ namespace dxvk {
   HRESULT DxgiSwapChain::AcquireMonitorData(
           HMONITOR                hMonitor,
           DXGI_VK_MONITOR_DATA**  ppData) {
-    return m_monitorInfo != nullptr
-      ? m_monitorInfo->AcquireMonitorData(hMonitor, ppData)
-      : E_NOINTERFACE;
+    if (m_monitorInfo == nullptr || !hMonitor)
+      return E_NOINTERFACE;
+
+    HRESULT hr = m_monitorInfo->AcquireMonitorData(hMonitor, ppData);
+
+    if (FAILED(hr)) {
+      // We may need to initialize a DXGI output to populate monitor data.
+      // If acquiring monitor data has failed previously, do not try again.
+      if (hMonitor == m_monitor && !m_monitorHasOutput)
+        return E_NOINTERFACE;
+
+      Com<IDXGIOutput1> output;
+
+      if (SUCCEEDED(GetOutputFromMonitor(hMonitor, &output)))
+        hr = m_monitorInfo->AcquireMonitorData(hMonitor, ppData);
+    }
+
+    if (hMonitor == m_monitor)
+      m_monitorHasOutput = SUCCEEDED(hr);
+
+    return hr;
   }

Then I ran the patch, built DXVK, and tried to run the game with that build. And it launched.

Then I reverted the patch, re-applied the whole commit and tried again, and got the original crash.

So that code above is the bad code, seemingly. Obviously it might just make OTHER parts of the commit non-functional, but removing that bit does fix it.