This appears to be a duplicate of #526.

No its not, Final Fantasy IV and Final Fantasy IV The After Years, are different games, have seperate app ids

My mistake. Sorry about that.

No problem, easy mistake to make.

This game works perfectly for me too

https://gist.github.com/Utopanic/106a4807d0c0079057a9b85c06634e06#file-utopanic-s-system

Whitelist Request

• Name of the game to be whitelisted: FINAL FANTASY IV
• Steam AppID of the game: https://steamdb.info/app/312750/

System Information

• GPU: GTX 760
• Driver/LLVM version: NVIDIA 440.59
• Distro version: Arch
• https://github.com/shoober420/linux-scripts/blob/main/home/shoober420/sysinfonvidia
• Proton version: 4.11-12

Works great out of the box.

With 5.13 and 5.0-10 the game does not have audio. The intro video has audio, but when you get to the title screen or into the gameplay, there is no longer any audio.

Reverting to 4.11-13 has everything work properly.

Here is the log file with 5.13-2:
steam-312750.log

I'm experiencing the same issue that @ugly95 described but for me this issue occurs in every version of Proton from 3.7 to Experimental. Distro is Fedora 33.

Game has no issue playing the audio from the opening video which appears to be vorbis audio contained within an .mkv file but cannot play any in-game audio which all appear to be vorbis audio contained within .akb files.

Replying to https://github.com/ValveSoftware/Proton/issues/565#issuecomment-3020620298

It looks like the the mod you have linked needs an override for version.dll (I'm assuming due to the existence of that in the archive)
I've attempted to override that with WINEDLLOVERRIDES="version=n" %command% but that just seems to cause an immediate crash.

Do you know if it is possible for this mod to hijack a different DLL?

Here’s what I was able to gather from one of the mod creators.

Replying to https://github.com/ValveSoftware/Proton/issues/565#issuecomment-3025312920

If they could offer a version that tries to hijack one of those other DLLs you are more likely to have success. I did generate a log from a layman's skimming perspective it looked like that DLL caused an issue with WINE loading its own version of msi.dll

WINE in general tries to load its own version of libraries (builtin) instead of loading things the windows way of loading DLLs in the executable directory. (Native)
Regardless of what they offer, something to note is that mods that rely on DLL hijacking will require config to not load the builtin DLL for that which is what WINEDLLOVERRIDES="version=n" will do. Basically you would replace version in that part of the command with the name of whatever DLL they choose to hijack. The =n part of it just tells it to try to load the native Windows version only. Whereas the default for most libraries is =b,n meaning try to load the builtin first and the native if that fails.

Edit: I think dinput would be a good idea because I do recall having success getting a mod using that to not cause an issue with other WINE DLLs.

I reran the test and generated some logs. Vanilla is unmodified and modified is with the mod installed and the DLL override specified. I've also included the end of the modded log as a code snippet.

19909.018:0020:0024:err:module:import_dll Library version.dll (which is needed by L"C:\\windows\\system32\\msi.dll") not found
19909.018:0020:0024:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\wintrust.dll" at 00006FFFFDFE0000: builtin
19909.018:0020:0024:err:module:import_dll Library msi.dll (which is needed by L"C:\\windows\\system32\\steam.exe") not found
19909.018:0020:0024:err:module:loader_init Importing dlls for L"C:\\windows\\system32\\steam.exe" failed, status c0000135
19909.035:0030:00d8:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
19909.035:0030:00d4:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
19909.035:0030:00dc:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
pid 7273 != 7272, skipping destruction (fork without exec?)

steam-312750-vanilla.log

steam-312750-modded.log

Finally found this thread. Putting this here for context and future reference - I didn't create the DLL hijack, only forked and compiled from ysc3839/FontMod because the build pipeline had failed on the version I needed.

Since it loads hooks for multiple DLLs, you can just rename version.dll to one of the supported hooks and it may work in that scenario.

Judging by the vanilla logs - it looks like both winmm and dinput8 are loaded, so there might be the highest chance of success with one of those two, but if memory serves, the font gets loaded very early on, so likely winmm because it is loaded before SDL2_ttf

Unfortunately, after a lot of trial and error, and even attempting to rebuild parts myself, it seems the issue is proton specific.

Attached is the log from my most recent test.

steam-312750.log