Can't get Special K on NieR: Automata working

[awebeer256]

System Information

• SteamTinkerLaunch version: v12.12
• Distribution: Arch (in a distrobox-podman container)
• Installation Method: manual local

Issue Description

If I enable the "Use Special K" checkbox in STL, the game crashes instantly upon launch. The main reason I want to use Special K is to go above 60FPS.

Contrary to the Special K page on the STL wiki here, the message about missing api-ms-win-crt-string-l1-1-0.dll appears while using both GE-Proton and TKG. Adding vcrun2015 to Winetricks packages in STL makes that message go away, but the instant crash still happens.

Based mostly on this gist, my best attempt at making this work is the following STL config changes:

Winetricks packages: vcrun2015 dinput8 dxvk d3dcompiler_47
Wine DLL overrides: dinput8,dxgi,d3dcompiler_47=n,b

That's the configuration that produced the logs that I'll share here.

My game is fully up to date, although I've also tried FAR 0.7.14 with a downgraded game without success (this was before I installed STL). IIRC I got it to run, but selecting the option to disable the FPS cap didn't actually disable it. So now I want to see if that'll still be true with an updated game and Special K, but I can't even get Special K to not instantly crash the game.

Logs

steamtinkerlaunch.log

<game-install-dir>/logs/crash.log

I also made a backup of the entirety of /dev/shm/streamtinkerlaunch and ~/.config/steamtinkerlaunch/logs, if any of those files would help.

[sonic2kk]

I believe Special K is incompatible with NieR:Automata on Linux, to my knowledge anyway no one has gotten it to work. You're supposed to use the FAR mod which is a mixed bag on Linux to begin with.

As far as I'm aware this is expected behaviour. And for what it's worth even outside of STL, I have also experienced the exact same instant crash when trying to use Special K/FAR with NieR:Automata.

The Special K installation for STL is not really very well maintained, no one has stepped up to really help with it and it was written a long time ago. It is not something I use either. Aside from moving DLLs and setting overrides I don't think STL does anything else, and if that causes games to crash it doesn't do anything to work around those issues. I had success using Special K with NieR:Replicant a long while ago, but never with NieR:Automata. Those are the only two games that I have tested.

[sonic2kk]

I couldn't find it at first but I found this issue from a long time ago: #580

It details some improvements that could've been made to Special K support in STL but the previous maintainer was not receptive to this user (perhaps some history I'm not aware of? no idea). Maybe the details here could give you some pointers.

If the information here makes sense to you and you are able to use this to get NieR:Automata working, I would really appreciate either a PR or a feature proposal on how to best implement these improvements. I don't feel like it's very well laid out in that issue in terms of a feature proposal (it is confusing to me as someone who doesn't use Special K to be honest, I lack a lot of the context). But if you can get it working based on the information there I'd appreciate a more, shall we say "layman's terms" explanation of what STL would need to do. I'm willing to try and improve SpecialK support where I can, but given that I don't use it, I hope you can understand why it might be difficult :-)

[sonic2kk]

Re-opening for now in case there is actually a way to get this working based on the Special K improvements proposed. If you're able to get it working and can open a separate feature proposal issue with more details on how you did it and could outline the process in some more laymans terms I can try to implement it.

From inspecting the code and trying to fill in the blanks a little bit, it seems fetching an older Special K version is one part of the puzzle, and the second is to somehow look for the correct game name (perhaps a way to manually enter a game name, or to have a text file that can map game names in circumstances where there are no matches like with NieR:Automata). Finally, there may also need to be work done to how STL parses out the rendering API as there may be multiple, but STL needs to know to only pick one.

I can foresee issues with trying to install older versions of Special K, as I am not sure how compatible they are with STL's current installation code.

I am not sure if that is correct though, and if it doesn't actually fix NieR:Automata, then this would be for nothing, so I won't start any work until I know that this could be used to make the game run, and if it can then an explanation of the manual steps for someone who is less familiar with Special K would be useful to getting this implemented.

Also, as a heads up, I would try to follow those steps with a fresh game install and a fresh Proton prefix, just to wipe out any DLLs. Essentially try to do this without any Winetricks or DLL overrides, maybe except for dinput8.dll which may need an override if STL doesn't set it.

[sonic2kk]

Also, worst case scenario, I can attempt to follow those Special K steps from the linked issue, so if you don't have time or don't want to fiddle around it's alright. I just figured I'd ask since you probably know more about Special K than I do, since my knowledge is practically zero 😅

It was not made clear to me in the linked issue that this would definitively solve the problems with using Special K and NieR:Automata (or any "older game" as they were referred to), so I'm hesitant to start anything without knowing 1) that this fixes the problem, 2) that this won't break compatibility with existing Special K functionality, and 3) that this can generically apply to all older Special K games

[awebeer256]

I'm afraid my Special K knowledge is also practically zero, along with my winetricks knowledge. I was hoping that by posting here, it might be seen by someone with relevant experience, who could make sense of the logs and say, "Oh, it's reporting X error so you need to set Y option and it'll work."

I've been at this for days and I feel like I'm trying to hike through a forest while blindfolded and one-handed.

[sonic2kk]

The consensus that I have seen is that Special K and NieR:Automata just don't work on Linux. That was afaik a big part of the appeal to playing on Linux, was that aside from modding, you didn't need the original FAR mod because the resolution fix and performance optimisations were baked into DXVK.

The logs sadly aren't all that useful as the STL log details the STL execution, and the Special K log is probably only useful to someone working directly on Special K.

I will probably close this issue then and investigate these improvements in my own time, but for now, I think the answer is just that Special K and NieR:Automata don't work on Linux. I have not seen anything positive, though the last time I actually delved deep into this was about 2 years ago.

I've been at this for days and I feel like I'm trying to hike through a forest while blindfolded and one-handed.

I have a bit of experience modding on Windows and that's pretty much how the experience is. And if you're doing advanced tinkering like this STL can be an aid for accomplishing some of the steps, but when there is a fundamental incompatibility and/or uncharted territory, there isn't much that can be done without someone stepping up to fix the problems.

I'll try my best to look into how to get NieR:Automata to work with the older Special K version as it is incompatible with newer releases to my knowledge. I'll try to follow what was suggested in the linked issue but I don't have hope.

If I can actually get this fixed, I'll update this issue, but I don't have an ETA or even a promise of fixing this. Sorry, this appears to my knowledge to be a limitation of Special K on Linux with this game and I may not be able to fix it 😦

[awebeer256]

Oh I don't blame you, don't worry ❤️.

Since my last comment, I relatively easily got FAR 0.7.0.14 running on an updated (2021) game, though sadly the frame-rate uncapping still doesn't work:

1. Download FAR_0_7_0_14.7z from here.
2. Extract the contents into the game's installation directory, and rename dinput8.dll and dinput8.pdb to dxgi.dll and dxgi.pdb respectively.
3. Make sure protontricks is installed, and run protontricks 524220 vcrun2015. Click to complete the two installers that pop up.

Reminder: in the game, press Ctrl-Shift-Backspace to open the FAR menu, and Ctrl-Shift-O (that's a capital letter "o", not a zero) to toggle the FAR statistics display in the top-left (I think these are the same as with Special K).

[CartoonFan]

Oh I don't blame you, don't worry ❤️.

Since my last comment, I relatively easily got FAR 0.7.0.14 running on an updated (2021) game, though sadly the frame-rate uncapping still doesn't work:

1. Download `FAR_0_7_0_14.7z` from [here](https://github.com/Kaldaien/FAR/releases/tag/far_070).

2. Extract the contents into the game's installation directory, and rename `dinput8.dll` and `dinput8.pdb` to `dxgi.dll` and `dxgi.pdb` respectively.

3. Make sure `protontricks` is installed, and run `protontricks 524220 vcrun2015`. Click to complete the two installers that pop up.

Reminder: in the game, press Ctrl-Shift-Backspace to open the FAR menu, and Ctrl-Shift-O (that's a capital letter "o", not a zero) to toggle the FAR statistics display in the top-left (I think these are the same as with Special K).

Hey there! I ran into this same problem a few days ago, myself, so hopefully what I found might be of use to you. I'm super new to all this, too, and I don't know exactly what you've tried, but this worked for me.

• FAR 0.7.x seems to be deprecated now, but thankfully the updated plugin is included in the latest SpecialK, so there's no need to hunt around for outside downloads or anything like that. They recommend uninstalling the 0.7* versions from the game directory (https://wiki.special-k.info/SpecialK/Custom/FAR#installation)

• I installed vcrun2015 (adding the latest vcrun might help with futureproofing, though) and d3dcompiler_47 from the Winetricks button in the STL GUI; SpecialK needs vcrun2015 to be installed before it runs, while d3dcompiler_47 is needed for the game to not white screen/crash immediately (ReShade might need it, too?)

• If you're using LodMod (https://wiki.special-k.info/SpecialK/Custom/FAR#update-faq), you'll want to include xinput1_4=n,b in the Wine DLL Overrides area of the Game Menu (STL settings)

• If you haven't tried it recently, I'd also suggest validating the game's files through Steam, as it downloaded some new files that weren't there previously.

That's pretty much it! I have the config file below if you want to try and use that instead. Hope this helps 👍 💜

524220.conf.zip

[sonic2kk]

Thanks a bunch @CartoonFan !

ReShade might need it, too?

Indeed it does, and when installing SpecialK via STL, d3dcompiler_47 should be installed with it and the override should be set afaik. If it isn't, that sounds like a bug :-)

Since SpecialK needs vcrun2015, maybe it would be an idea for STL to install this too. Is this needed for every game?

[CartoonFan]

Thanks a bunch @CartoonFan !

You're quite welcome 😁
I always worry that my efforts won't hold up to scrutiny, but I'm really glad they helped y'all.

ReShade might need it, too?

Indeed it does, and when installing SpecialK via STL, d3dcompiler_47 should be installed with it and the override should be set afaik. If it isn't, that sounds like a bug :-)

Since SpecialK needs vcrun2015, maybe it would be an idea for STL to install this too. Is this needed for every game?

It seems like it. Without explicitly installing vcrun2015 through winetricks, SpecialK complains about the missing dll, and the rest of its setup doesn't trigger. I've only gotten consistent results with the 2015 version, but, theoretically, later versions should work too. I've been trying to test vcrun2022, but...it's been hit or miss, and I don't feel confident giving advice if it's not reproducible. There's just so many variables, and if something's not the way it should be, the whole thing comes crashing down. So...no luck yet 😅

[CartoonFan]

I hate to bug you again, @sonic2kk; but during my testing, the tracked_files file doesn't seem to be copied over once the compatdata is symlinked, which causes a crash. Am I just doing something dumb, or is this a bug? If it's a bug, should I make a separate bug for it? It also happens after deleting the compatdata through the GUI. Thanks!

524220.log
524220_V2.conf.zip

[sonic2kk]

Is this referring to the tracked_files in the game prefix (i.e. /home/gaben/Games/steamapps/compatdata/524220/pfx, which would be symlinked to something like /home/gaben/.config/steamtinkerlaunch/proton/compatdata/compatdata-proton-8.0)?

If so, I can't reproduce the problem with a symlinked compatdata, the tracked_files text file is appearing as expected.

It would be best to create a separate bug report, with as much detail as you can provide about the steps to re-create the problem. I'm not sure if this is related to SpecialK directly anyway.

---

It would be important as well to confirm if this affects general Winetricks in a game prefix (I assume the crash is happening because tracked_files is missing information about vcrun2015), as well as whether or not copying this file into the symlinked prefix resolves the problem (in this case, it resolves the problem of NieR:Automata crashing).

When deleting a compatdata it makes sense to me that this file would be removed, since you're removing the entire compatdata, and that's where things like vcrun2015 would get installed to, essentially undoing the actual installation of vcrun2015. But when symlinking the compatdata, unless it removes the existing one and creates a new one, I don't see why this would be happening (I can't find any indication in the code from skimming that this is what happens).

A separate bug report for this would be appreciated.

[CartoonFan]

Is this referring to the tracked_files in the game prefix (i.e. /home/gaben/Games/steamapps/compatdata/524220/pfx, which would be symlinked to something like /home/gaben/.config/steamtinkerlaunch/proton/compatdata/compatdata-proton-8.0)?

If so, I can't reproduce the problem with a symlinked compatdata, the tracked_files text file is appearing as expected.

It would be best to create a separate bug report, with as much detail as you can provide about the steps to re-create the problem. I'm not sure if this is related to SpecialK directly anyway.

Is this referring to the tracked_files in the game prefix (i.e. /home/gaben/Games/steamapps/compatdata/524220/pfx, which would be symlinked to something like /home/gaben/.config/steamtinkerlaunch/proton/compatdata/compatdata-proton-8.0)?

If so, I can't reproduce the problem with a symlinked compatdata, the tracked_files text file is appearing as expected.

It would be best to create a separate bug report, with as much detail as you can provide about the steps to re-create the problem. I'm not sure if this is related to SpecialK directly anyway.

Sure thing. Just to confirm--since I don't want to clog up your issues list, either--this is what the directory looks like:

It would be important as well to confirm if this affects general Winetricks in a game prefix (I assume the crash is happening because tracked_files is missing information about vcrun2015), as well as whether or not copying this file into the symlinked prefix resolves the problem (in this case, it resolves the problem of NieR:Automata crashing).

When deleting a compatdata it makes sense to me that this file would be removed, since you're removing the entire compatdata, and that's where things like vcrun2015 would get installed to, essentially undoing the actual installation of vcrun2015. But when symlinking the compatdata, unless it removes the existing one and creates a new one, I don't see why this would be happening (I can't find any indication in the code from skimming that this is what happens).

For the general Winetricks part, you want to know if it affects things other than vcrun2015, right? I can try that and see what happens.

For the copying solution, I think it worked when I tried it before, but I should be able to confirm it without too much difficulty.

Let me know if there's anything else I can provide you with 😆

[sonic2kk]

Ah, thanks for the screenshot. This is different than what I was looking at. Perhaps here SteamTinkerLaunch is creating separate folders. I did not work on this functionality and this is my first interaction with it, so I will take a look and see what this functionality actually is and how it works in the code (probably sometime this week, not tonight, almost 3am 😴).

Just by doing a very preliminary look, it seems like STL is the one that creates those used_by-{appid} files as well as the stl-version file (no surprise with the last one 😉). The pfx.lock file is created by Proton afaik. It is possible that STL is creating a brand new prefix and then moving/creating files inside of it. Perhaps there is a folder in your compatdata directory (one dir up from the screenshot you showed) named 524220_steamtinkerlaunch or something to this effect, basically a folder with that AppID but with some kind of name change that you didn't create.

If this is the case, then some fixups would be required for this logic. First off, the prefix version file is missing, as well as some configuration information that Proton expects. If other files were created here in future by Proton, STL would miss those as well. I'll have to look more closely into how this logic works, and what exactly is inside the {appid}_SAC folders (as well as how they're created by STL, they're symlinks of some description at least).

If you can find out if this affects more than just vcrun2015, as well as if copying a "valid" tracked_files into that prefix fixes the issue, then that would be helpful. Actually, the copying of tracked_files fixing the issue would be the most interesting to know.

But feel free either way to open an issue, this is something that at the very least warrants more discussion that may be better in its own dedicated issue. No ETA as always on investigating this stuff and so likewise, there is no rush or pressure on you either. Just whenever you have some time if you can open an issue with more information, and I will do my best to try and figure out what's going on :-)

[CartoonFan]

Right on. I'll gather up the info and do what I can. Thanks for your help 👍

[sonic2kk]

I just checked the log you attached (missed until now, sorry...) and the error relating to tracked_files is actually related to Proton. When a game is launched via Proton, it is intended that the game executable is passed to a Python script in each Proton version called proton.

I wonder if creating a blank tracked_files in the prefix that is missing it would fix your issue as well. I am not sure if Proton tries to populate it somehow, it may end up resolving Proton throwing that file not found error, but it may not fix any crashing (since vcrun2015 may still be "unseen" by Proton, depending on how tracked_files is actually used).

[CartoonFan]

I just checked the log you attached (missed until now, sorry...) and the error relating to tracked_files is actually related to Proton. When a game is launched via Proton, it is intended that the game executable is passed to a Python script in each Proton version called proton.

I wonder if creating a blank tracked_files in the prefix that is missing it would fix your issue as well. I am not sure if Proton tries to populate it somehow, it may end up resolving Proton throwing that file not found error, but it may not fix any crashing (since vcrun2015 may still be "unseen" by Proton, depending on how tracked_files is actually used).

I get you. I'll give it a try 😁

[sonic2kk]

This is not a feature I have used so this has completely slipped under my radar :-) So thank you!

[CartoonFan]

You are very welcome 🙏 💜

I'll hopefully have results for the new bug report soon 🫡

[sonic2kk]

Hey @awebeer256, it turns out I was off the mark entirely and once #898 is merged, NieR:Automata and SpecialK should work via SteamTinkerLaunch. Sorry for the misunderstanding.

However I wanted to mention that I did test the tweak in SpecialK to remove the FPS cap and that didn't seem to work, even trying to run it on my 165Hz monitor and disabling vsync. I'm not sure if I have any extra configuration set inadvertently (maybe a DXVK FPS cap set unintentionally), but just a note that even though SpecialK loads, the FPS cap removal doesn't appear to work in my testing, and I know that was your use-case for SpecialK. It may be worth trying to report upstream that it isn't working, in case this is explicitly disabled when running via Wine. It's also possible that this setting has to be configured from the FAR.ini in the game files (From Steam: right click on game -> Properties -> Browse local files, it can also be done from the STL game files menu).

I haven't looked too deeply into it, I just thought to check this for you when testing the improvements to SpecialK and STL.

[awebeer256]

Great to hear. I will indeed look into reporting the FPS issue to Special K.