Additionally would like to also mention that people found out multiplayer doesn't work as starting a multiplayer sortie gets you kicked out with error code ST-3200003, although the multiplayer hub itself works. The assumption as of now is that this is pretty much anticheat issue though (EAC).

Reproduced on an RTX 3090 with the closed driver (NVIDIA 615.71.9) running GE-Proton11-7, so I started digging for a fix.

Original findings

I dumped all shaders the in-game warmer could generate with 'VKD3D_SHADER_DUMP_PATH'. Driver-side, the hardware subgroup size is fixed at 32 (minSubgroupSize = maxSubgroupSize = 32).

Correction to my earlier claim: I originally said the entire shader library assumes 64-wide waves. That was overstated! Of the 8.1k compute shaders in the dump, 4,602 have "LocalSize 64", but that's workgroup size, not wave size. Only 1,086 use wave ops, and 456 use ballot ops. Those are the ones where the hardware wave width could actually matter.

Update: testing a wave-size fallback

The log shows 28 compute pipelines failing with Required WaveSize range [N, N], but supported range is [32, 32] (hr 0x80070057), for N = 4, 8, 16, 64 and 128. Each of the 28 is a different shader hash with a single fixed size, and none asks for 32.

To test whether those rejections cause the missing clouds, I patched vkd3d-proton (d3d12_device_validate_shader_meta in device.c, and the subgroup-size selection in vkd3d_setup_shader_stage in state.c) so that an unsatisfiable WaveSize request is ignored, with a warning, and the driver picks its native size instead of failing pipeline creation.

Result, confirmed with the patched DLLs loaded (And only running the first game mission!):

• 28 "Ignoring unsatisfiable WaveSize" warnings
• 0 "Required WaveSize range" errors, 0 failed compute pipelines
• Didn't crash
• clouds still missing, no visible change on earlier cutscenes from the intro portion either.

So the WaveSize rejection of these 28 pipelines is not, by itself, what breaks the clouds. Either the cloud pass isn't among them, or those shaders run at wave32 but produce wrong output because they assume more lanes. I can't distinguish the two yet. For what it's worth, an Intel Arc reporter above also lacks wave64 and renders the clouds, which points the same way.

Next

• Map the 28 hashes to the dumped .dxil/.spv and see what they do.
• RenderDoc capture of a frame with the clouds missing, to find the pass where the horizontal cut first appears.
• Cross-reference that against the ballot/wave-op shaders.

Happy to share the patch or any logs/dumps that would help. If anyone (@HansKristian-Work?) knows whether D3D12 on Windows rejects or clamps fixed WaveSize requests on NVIDIA, that would help me narrow this down. I'm also considering vibe coding my way out of this one lmao.

WaveSize 4:    6f2f52846716bf22 dffa883987ef26eb
WaveSize 8:    27ad2127b028b6b3 4a759e3ea0a23cee
WaveSize 16:   099336d8dd5b8a97 0e168a852cedefbc 28da48ab25891370 6665dfb0a2723da6
               87b221357c8ec2d9 8cd68471d54a75c0 a1db84d1f0c9e700 a31e7bbeabf5d245
               a34099de668ff7b0 b748e3fd4bbdf09a df945678402547a3
WaveSize 64:   13b48314821f8e28 1d0a6c7003601c7d 27591fcfef2d52ce 41c698c83f8285c8
               5e3aaef8ea12d041 60277b0b38298815 b46c15ec0f923f0e c31cc10042568960
               da2607306b9ea2a8 e2c908af44581bcd e6706734cc90c248
WaveSize 128:  37ff68e29f673cfc e96468baa58d4f75

Additionally would like to also mention that people found out multiplayer doesn't work as starting a multiplayer sortie gets you kicked out with error code ST-3200003, although the multiplayer hub itself works. The assumption as of now is that this is pretty much anticheat issue though (EAC).

The same, old issue of devs doesn't want to activate EAC for linux with a click of the mouse?

Using NVIDIA Nsight, with help from GPT-6-Astra in Codex, I traced this to a cloud ray-march stall in SkyTraceCS and have a targeted workaround. I'm looking into a way to make some sort of script that maybe someone else could run to do the same shader patches until a proper fix is sorted.

The shader initializes invalid cloud/cirrus ranges to (-1, -1), then packs them into half precision after dividing by 131072. The generated SPIR-V applies OpQuantizeToF16 to -1/131072, a half-precision subnormal, which becomes negative zero. The invalid cirrus range consequently becomes (-0, -0): a ray at distance zero passes the inclusive range check, gets a zero-length step, and exhausts its 128-iteration budget without rendering clouds.

// Invalid cirrus-range sentinel:
Pack(ret1.packing_cirrus_range, float2(-1, -1));

// Range packing:
void Pack(inout Packing_float2_TO_uint_Remap1e5 pack, float2 first)
{
    pack.first_packed = Pack_16_16(first * (1.0f / 131072.f));
}

// Inclusive range test:
bool IsInsideRange(float2 range, float t)
{
    return (range.x <= t) && (t <= range.y);
}

// Cirrus membership uses that test:
Pack_Bitmask(
    trace_state.bitmask,
    IsInsideRange(Unpack(ret1.packing_cirrus_range), trace_state.t),
    2
);

// Later, the cirrus range limits the step:
if (IsInsideCirrus(trace_state))
{
    const float cirrus_trace_range_length =
        Unpack_Y(ret1.packing_cirrus_range) -
        Unpack_X(ret1.packing_cirrus_range);

    step_length = min(step_length, cirrus_trace_range_length / (3 + 1));
}
float next_stop = trace_state.t + step_length;

For shader e2ace7e3e8dbf87b, my patch is:

-%498 = OpQuantizeToF16 %float %float_n7_62939453en06
+%498 = OpCopyObject   %float %float_n7_62939453en06

The patch keeps the half-precision packing. It removes a separate OpQuantizeToF16 immediately before it, which turns the small negative sentinel into negative zero. With OpCopyObject, the original value reaches the packing instruction unchanged; in the Nvidia Nsight replay, it survives packing and unpacks back to -1.
The original HLSL packing helper already expresses a direct f32tof16(v) conversion. This workaround changes the generated SPIR-V; I haven’t established which part of the shader compilation path should receive the upstream fix.

The patch changes one byte in the 249,084-byte SPIR-V file, at offset 24096 (0x5E20):

74 00 04 00 → 53 00 04 00

Original SHA-256 of the shader:
6b6eda17573f21c74c2fe6466cb784d64c1c9b6227e7bd39fe5c64ddbce5c469

I apply it using VKD3D_SHADER_OVERRIDE, placing the replacement at <override directory>/e2ace7e3e8dbf87b.spv. vkd3d-proton substitutes the hash-matched shader when creating the pipeline. No modified Proton build or game file edits are required.

On an RTX 4090 with Proton Experimental, this restored clouds below the horizon in both the same Nsight replay and live gameplay. Instrumented replay confirmed that the sentinel remained -1 and the ray advanced normally. Depth tests, iteration limits, density evaluation, and compositing remain intact; the workaround does not disable ray tracing.

After another mission showed the symptom, I found 16 SkyTraceCS variants with identical cloud-range setup source and extended the same one-byte correction to each. All original and patched modules pass spirv-val --target-env vulkan1.3. I verified the original variant in replay and gameplay; the additional variants still need gameplay verification.

These are the 16 SkyTraceCS shader hashes found with the faulty sentinel conversion:

22fdcb556e490841
38f591d7629df2b6
43b1f2ca42fb23c0
59582be9428f0c60
713ad0f307870d6c
76d3b0fd2325587f
80f225e283cc4d72
87b42e91ceafed10
88ad084f83cf8ef9
aaf93c80eebd46d5
aff49440c4c76f41
c652fabba323d136
e2ace7e3e8dbf87b
e6afff4a21f36ae7
f00552bae8b97a19
fcef06642b47c3cd

Instruction IDs and byte offsets for the patch differ between variants.
This covers the variants of this shader I've found.

This establishes the failure mechanism in the captured shader, and a workaround, but not a real upstream fix. I am at least able to play the game with the clouds working correctly though! I haven't tested this for every single mission yet but I think this should cover most/all(?) of them now that the patch is applied to those 16 shaders. That is still pending testing as I replay the game for the second time.

AI use disclosure:
I used GPT-6-Astra in Codex to debug this with Nvidia Nsight frame captures. Getting Nvidia Nsight to capture a frame without incompatibility issues and then have it actually replayable on the GPU required a lot of iterating. I also do computer things for a living :3

Would you mind posting the offsets you used for the other variants?

Heeey guyss!! I've built a small script that automates the SkyTraceCS fix described by @empty-quiver !!

It scans the shader dump for the sentinel pattern, patches the 16 affected shaders via spirv-dis -> spirv-as, validates the output with spirv-val, and drops the results in an override directory ready for VKD3D_SHADER_OVERRIDE.

Repo: https://github.com/ac1dn0ise/ace8-cloudfix-linux/

Tested on RTX 3090 with GE-Proton11-7. Full run end to end: 16 discovered, 16 patched, 16 validated. Clouds render correctly in Mission 1. No game files or Proton builds were modified.

Thank you very much @empty-quiver for the original analysis and manual fix. This is was just the automation!

@IsaacVaughn Sure, but keep in mind that these are from the shaders I dumped from my game, so if your proton version is different they might not be the same, I haven't checked different versions:

@ac1dn0ise Nice you beat me to it lol, I have a script here that people can also use and compare :)
https://github.com/empty-quiver/ac8-cloud-patcher

Now I want to use yours XD.

I also reproduced the GPU hangs on RTX 5070 with 615.71.09. It seems to be an Nvidia compiler bug, as I could work around it with the following Pyroveil config:

{
	"version": 2,
	"type": "pyroveil",
	"matches": [
		{ "opStringSearch": "87b42e91ceafed10", "action": { "glsl-roundtrip": true } }
	],
	"disabledExtensions": [ "VK_NV_raw_access_chains" ]
}

Replying to https://github.com/ValveSoftware/Proton/issues/10198#issuecomment-5924274607

Thank you for analysis, with Gpt-6-Astra i write fix yesterday which fixes all 16 traces. Currently 0 problem with clouds to mission 16.
Rtx3070 laptop
Arch Linux
Proton experimental

Replying to https://github.com/ValveSoftware/Proton/issues/10198#issuecomment-5931454287

It worked for me, thanks. My shader hashes were the same as yours, so I figured our proton versions were close enough.

Replying to https://github.com/ValveSoftware/Proton/issues/10198#issuecomment-5932516896

This has worked for me, many thanks.

Appears to me that today's update to the game fixed the issues

Replying to https://github.com/ValveSoftware/Proton/issues/10198#issuecomment-5931797204

I'm experiencing a similar issue. RTX 4060, 16 gigs ram, on Fedora 44, latest driver, latest kernel. I either crash on the loading screen after selecting the difficulty, or the loading screen after skipping the first cutscene. RAM usage also spikes during the crash.

The GPU hangs and the cloud glitch turned out to be symptoms of the same issue. It should work fine now on its default Proton (hotfix 20261001) and on Proton Experimental bleeding-edge.

HDR support remains permanently grayed-out on Nvidia. Tried:

PROTON_ENABLE_WAYLAND=1 PROTON_ENABLE_HDR=1 ENABLE_HDR_WSI=1 %command%

and

PROTON_ENABLE_WAYLAND=1 PROTON_ENABLE_HDR=1 %command%

Tried Proton Experimental and GE-Proton 11-7.

Switching to proton experimental bleeding edge fixed the clouds and driver hangs however now the mission briefings just show a black screen while the audio plays.

Hello @enishiexia, please add PROTON_LOG=1 %command% to the game's launch options, reproduce the black screen, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.)

I got it working, thanks. Had to use steam://unlockh264/

This was the main error in the logs avdec_h264 Subclass refused caps

Hi, everyone seems to be talking about this issue on Nvidia cards, and that's what the tools to fix it have been made for, but I've got an AMD card - a 6600 XT - and the same issue. Ran one of the tools anyway, hoping against hope, and it found 8 of 16 shaders it expected, but the result was not what I was hoped. Just thought I'd raise the fact that it happens on (at least some) AMD cards, too.

Hey @BrotherTharnak can you please give us more insight on your settings? Which version of proton where you using to run the game? Also, if you used my script can you please open an issue and attach the "ace8-work/patch.log" file so we can take a look on what's happening?

Replying to [#10198 (comment)](https://github.com/ValveSoftware/Proton/issues/10198#issuecomment-5931797204)

I'm experiencing a similar issue. RTX 4060, 16 gigs ram, on Fedora 44, latest driver, latest kernel. I either crash on the loading screen after selecting the difficulty, or the loading screen after skipping the first cutscene. RAM usage also spikes during the crash.

I fixed my problem by creating a 16 gig swapfile. I've been able to play the entire campaign.

Is anyone else seeing dense black dots around the fringe of certain objects? The most noticeable is the space elevator in mission 15, but I noticed it in some places in mission 14, and around professor's helmet (but not tasha's) in mission 15's opening cutscene.

EDIT: I am also having issues with the game only detecting a single resolution, which is not the full resolution of my monitor.

@IsaacVaughn Could you provide save files with those missions if you still have one? They should be in steamapps/compatdata/2288340/pfx/drive_c/users/steamuser/AppData/Local/BANDAI NAMCO Entertainment/ACE COMBAT 8/Saved/SaveGames/

@IsaacVaughn Could you provide save files with those missions if you still have one? They should be in steamapps/compatdata/2288340/pfx/drive_c/users/steamuser/AppData/Local/BANDAI NAMCO Entertainment/ACE COMBAT 8/Saved/SaveGames/

I was able to resolve the issue by updating the nvidia drivers from 590.xx to 615.xx, so probably not a proton issue. The game's resolution detection in fullscreen mode is still broken, but that isn't tied to any particular mission.

Odd issue on RTX 50 series on driver 595.91.07 with Proton Experimental bleeding-edge (experimental-bleeding-edge-11.0-451000-20261012-pb94341-w981e2f-d649c4b-v223075-x86_64 as of this post). The cloud fix is mostly working, but occasionally there will be issues with banding or pixelation that crop up. Changing the camera to cockpit view resolves this, and this issue doesn't happen if you stay only in full cockpit view.

https://github.com/user-attachments/assets/caa48880-e7fb-4062-bc92-1aa627c877e5

I can also confirm that the pyroveil config from runar-work resolves the crash at the end of Mission 4 but it is also causing a crash at the very start of Mission 6 (at least for me) so I've had to only enable it for the affected mission and run without it normally. I suspect something about the shaders for the unmanned aerial refueling drone are to blame as it appears in both the end cutscene of mission 4 that triggers the first crash and the start of mission 6 that triggers the second. I can do some more testing on this as it also shows up again at the start and end of Mission 13.

New to debugging shaders so while I plan to see what I can resolve myself, if there's logs or dumps I can provide that may help if someone else intends to take a look just let me know.