Bug in DLC loading

[shironosho]

Emulator version
2025_04_20

Debug log
logs.zip

steam_settings file
steam_settings_files.zip

Requirement

• I am uploaded debug log.
• I am uploaded steam_setting file.
• I am sure the game not using 3rd party server (Photon, Playfab, GC, etc).
• I am sure can run the game offline.

Describe the bug

I'm not 100% sure this is a bug in the emulator, but it seems very likely to me.

To give a little backstory, in the game "NieR Replicant ver.1.22474487139..." (appid 1113560), the DLC files seem to not load properly. DLC "NieR Replicant 4 YoRHa" (appid 1408390) contains weapons and costumes. If a weapon from the DLC is equipped, the weapon model is invisible (everything else about the weapon seems to work). If a costume from the DLC is equipped, the game crashes while loading a save.

This bug seems to have been encountered with Steam as well (with no emulators), as it was reported in Steam Community. It was caused by a Steam client update and was later fixed in a newer version. In the discussion about the update, it was reported that it affected at least two other games as well (I don't have those to test them with the emulator).

All the info I listed above was what I found online (after I experienced the same problem). I could not find anything about what was actually fixed in the mentioned client update specifically, and the following is what I discovered after some testing (I couldn't find this mentioned anywhere else online).

Basically, it seems like this bug does not occur if the install path of the game (and the directory with the steam dll) is not "too long". Specifically, if the absolute install path is no longer than 51 characters, including the leading <driveletter>:\ and with no trailing backslash. I believe it's 51 bytes, more specifically, since replacing an ASCII character with a non-ASCII Unicode character causes the bug to appear again. Also, removing three ASCII characters after adding a character that would take three bytes in UTF-8 making it work again seems to hint that this path length is treated as UTF-8 (so 51 bytes in UTF-8 I guess?).

Here are the results of my testing. Of course, BAD means the bug was encountered and GOOD means no bug.

D:\123456789abcdef\NieR Replicant ver.1.22474487139         GOOD
D:\123456789abcdef\x\NieR Replicant ver.1.22474487139       BAD
D:\12345678\x\NieR Replicant ver.1.22474487139              GOOD
D:\123456789abcd\x\NieR Replicant ver.1.22474487139         GOOD
D:\123456789ab\x\y\NieR Replicant ver.1.22474487139         GOOD
D:\123456789ab\x\yz\NieR Replicant ver.1.22474487139        BAD
D:\1\2\3\4\5\6\x\yz\NieR Replicant ver.1.22474487139        BAD
D:\1\2\3\4\5\6\x\y\NieR Replicant ver.1.22474487139         GOOD
C:\Users\xxxxxxx\NieR Replicant ver.1.22474487139           GOOD
C:\Users\xxxxxxx\a\NieR Replicant ver.1.22474487139         GOOD
C:\Users\xxxxxxx\ab\NieR Replicant ver.1.22474487139        BAD
D:\1\2\3\4\5\6\x\yzwwwwwwwwwwwwwwwwwwwwwwwwwww\NieR         GOOD
D:\1\2\3\4\5\6\x\yzwwwwwwwwwwwwwwwwwwwwwwwwwwww\NieR        BAD
D:\1\2\3\4\5\6\x\yzwwwwwwwwwwwwwwwwwwwwwwwwwwあ\NieR        BAD
D:\1\2\3\4\5\6\x\yzwwwwwwwwwwwwwwwwwwwwwwwwwあ\NieR         GOOD

The same bug happens in the original Goldberg emulator. It was also present in the first emulator released with this game by CODEX, but was later fixed in a newer version (called "DLC Fix").

The log file with NOBUG_ prepended is from when the bug doesn't happen and the one with BUG_ is from when it does.

[universal963]

Please test #233 and see if it works. You need to add line "1408390=" in app::paths section of configs.app.ini.

[shironosho]

How do I build it? I tried following the README, but third-party\common\win is empty.

[GogoVang]

https://github.com/GogoVang/gbe_fork/actions/runs/15085462356
You can grab an artifact from my fork

[universal963]

This repo already has GitHub Actions set up so you can directly download artifacts here: https://github.com/Detanup01/gbe_fork/actions/runs/15085337222

[shironosho]

Oh, sorry I didn't see that.

I just tested your fix in NieR Replicant and now everything works, DLC gets loaded properly every time.

I did some more testing with different install paths in the meantime and I noticed that the game wouldn't even launch with the old dll if the install path was longer than 115 characters (which I didn't even know when I opened this issue). Your fix fixes that as well, the game launches now no matter the install path length.

I was looking at the files you modified to fix this and I was wondering, where did these two "magic" values (51 and 115) come from? Why does it work properly if the path length is short enough? Or is this something specific to the game's code and the dll always gives it the full path, regardless of its length? Still, it would seem weird to me that the game doesn't even start (when the path's longer than 115) when this fix only specifies the DLC app path in the ini file.

This is the log from when it crashes at launch (without your fix), before even trying to access DLC in game (with path longer than 115):

log.zip

[universal963]

I highly suspect that both "limits" are caused by game code itself, though I have currently only debugged the "115" limit. Actually, the limit should be 116. The path buffer of the game is 128 bytes, and after requesting DLC install path, the game appends another string "\dlc\dlc01" to the buffer, whose length is 11. And don't forget about null terminator itself takes 1 byte, so the remaining buffer available is 128-11-1=116 bytes. If anything longer, the game actively throws an exception called STATUS_STACK_BUFFER_OVERRUN and crashes because of this unhandled exception. Based on the result above, we can easily assume/guess the "51" limit can probably be 64-11-1=52 bytes limit somewhere else in the game code.

The real problems are the game does not unify the buffer length everywhere and the buffer length is too short. When requesting DLC install path, the game claims the buffer length is 512 bytes, much longer than even the 116 bytes limit. And Windows by default limits the path to 260 characters. So it becomes quite awkward that 512 is longer than 260, but 116/52 is shorter than 260.

Anyways, since it is calling Steam API, we should always focus on how real Steam behaves. And I have tested it, result showing the API does not fill the path buffer and returns 0. I think maybe the game itself somehow works around it and get the path by other means. So what is needed to be done is to just "copy" this behavior to the emu here, and that is all.

All in all, this problem is caused mostly by the poor game code, we just need to make emu more accurate to let the game itself resolve it.

[shironosho]

Thank you very much for the explanation.

What is then Steam's alternative to checking for app paths in configs.app.ini by this emulator? In other words, how does Steam know when it should just return 0 instead of filling the buffer?

[universal963]

I don't know too much about Steam backend for each game, so everything is based on my own tests. My tests currently indicate for many apps, if you request paths using appid that is for an individual app (e.g. 480), the API returns the path where this app is installed, or even where it will be installed by default if not already installed. But if using appid that is a DLC one or a depot one (e.g. 447130 and 481), it returns 0 and fills nothing. Maybe some rare games can change the behavior in Steam backend, and I have not encountered one yet.