sonic2kk
Compatibility issues with bypassing launchers via custom command
System Information
- SteamTinkerLaunch version: steamtinkerlaunch-v14.0.20231105-3
- Distribution: Arch Linux
- Installation Method: AUR
Issue Description
I seem to be attracted to games with strange issues :sweat_smile:
I've noticed two to three quirks which may warrant a closer look:
- When running Nine Hours, Nine Persons, Nine Doors (https://www.pcgamingwiki.com/wiki/Zero_Escape:_The_Nonary_Games) directly as a custom command, the game crashes with an error message:
The game runs properly when run from the launcher.
- With the same game, running the game as a custom command and with the Special K DLL name set to 'auto' creates a DXGI DLL, even though PCGaming Wiki lists the game as a D3D9 game.
- When run without the launcher, Attack on Titan 2 (https://www.pcgamingwiki.com/wiki/Attack_on_Titan_2) has a significant amount of audio crackling with Pulseaudio latency set to 60 ms.
With 120+ ms, there is a variable--but usually lesser--amount of crackling. I've gotten it to work properly once so far :laughing: . This happens with or without Special K and ReShade enabled. Running the game through the launcher has no discernible audio crackling.
Running the game as a custom command doesn't give me gamelaunch logs--which may be by design--so hopefully it's not a problem if some of them are missing from the list :pray:
As always: I'm not sure which--if any--of these things STL can fix, but I figured I'd toss them out there all the same.
Thanks!
Logs
477740_no_launcher_specialk_auto.conf.zip 477740_steamtinkerlaunch_no_launcher_specialk_auto.log steam-477740_no_launcher_specialk_auto.log
477740_gamelaunch_launcher_specialk_auto.log 477740_launcher_specialk_auto.conf.zip 477740_steamtinkerlaunch_launcher_specialk_auto.log steam-477740_launcher_specialk_auto.log
601050_no_launcher_60msec.conf.zip 601050_steamtinkerlaunch_60msec.log steam-601050_60msec.log
601050_no_launcher_120msec.conf.zip 601050_steamtinkerlaunch_120msec.log steam-601050_120msec.log
601050_gamelaunch_launcher.log 601050_launcher.conf.zip 601050_steamtinkerlaunch_launcher.log steam-601050_launcher.log
I think in general, trying to bypass a game launcher by using it as a custom command is a bad idea. Games expect to be launched via the launcher, and when running via Proton especially, sometimes workarounds are applied directly to the launcher process (DXVK, for example, with Sonic Adventure 2 applies some workarounds when it detects the actual launcher process). I couldn't find the list of workarounds in Valve's Wine fork again, but I did find part of the DXVK one again: https://github.com/doitsujin/dxvk/blob/master/src/util/config/config.cpp
DXVK is not exactly relevant in itself but I use it as an example to show how Proton can apply workarounds at a process level.
When it comes to Steam native games, the Proton script also tries to apply workarounds per-app-id, but also sometimes per-EXE. I think as well, GE-Proton also tries to apply Protonfixes, but I am not sure if these are compatible on a first run with STL, I remember hearing that Protonfixes didn't work with wrapper scripts or if a different EXE than the vanilla one was launched.
I am not sure if STL can do anything here really. However, I'll leave a few comments all the same!
With the same game [Zero Escape: The Nonary Games], running the game as a custom command and with the Special K DLL name set to 'auto' creates a DXGI DLL, even though PCGaming Wiki lists the game as a D3D9 game.
I don't see the game on the PCGamingWiki article of SpecialK games. Indeed, it may be compatible, as this list is massively incomplete, but as noted on the SpecialK wiki, STL uses this wiki page to determine the renderer for games.
Download/update the SpecialK Compatibility List to know which rendering API to use
The only related game I can see on this list is "Zero Escape: Zero Time Dilemma", at the very bottom of the page at the time of writing.
If a game is not on this list, auto will not work correctly, as SteamTinkerLaunch downloads and parses this page. I'm not sure how viable it would be to try and search for the game page on PCGamingWiki itself and attempt to parse information on the renderer that way, as I am not sure how consistent the page structure is (structure as in the actual markup, which is different from perhaps just looking similar, maybe an obvious distinction but one I wanted to make).
With 120+ ms, there is a variable--but usually lesser--amount of crackling. I've gotten it to work properly once so far 😆 . This happens with or without Special K and ReShade enabled. Running the game through the launcher has no discernible audio crackling.
I think this is just an oddity of running without the launcher and with using STL. Sometimes games fail with and without STL if you bypass the launcher (i.e. with Fallout 3 I often ran into an issue where Steam didn't set the registry keys correctly), sometimes there is weirdness specific to STL (I think maybe when a game can't initiate DRM properly I think, as it thinks the game is being ran by just double-clicking the EXE with Steam closed).
It seems like the PulseAudio latency change is being applied but STL doesn't do anything directly to PulseAudio, all it does is set an environment variable. It's not doing anything deeper than that or making any strange tweaks, so if it isn't working, I don't think STL can fix it much :frowning_face:
Bypassing launchers can be a real mixed bag sometimes, I'm not sure that these issues are necessarily specific to STL itself and I don't see how STL could fix them. All it does is run EXEs with whatever options are selected. Sometimes running as a custom command is problematic, it may be best to rename the launcher and launch that way. For example, with a game that uses the name Launcher.exe, rename Launcher.exe -> OrgLauncher.exe, and rename the game executable to Launcher.exe. Then Steam will run that, and subsequently pass that to SteamTinkerLaunch.
Those steps are different than simply using custom command with SteamTinkerLaunch, since the game process is launched directly from Steam, and not as a separate SteamTinkerLaunch process piggybacking off of the Steam process. When launching as a custom command STL builds a separate launch command, basically launching the game separately with Proton, instead of using the regular Steam launch process. The steps are very similar, but some games don't like this and do indeed fail.
When launching as a custom command as well, I don't think the AppID is passed to Steam (since the custom command is not guaranteed to be a Steam game, it could be any executable), and so the Proton script isn't getting the AppID unless it can somehow pull it from the environment, but I don't think that's the case. I don't think the Proton script has access to those variables stored and set by STL, and I highly doubt it would have access to the ones from Steam itself. This is significant as the Proton script is probably unable to apply workarounds when a game itself is launched as a custom command, as the Proton script does track and apply fixes by AppID. If you're handy with Python, you can take a peak at one example of where Steam stores and checks for specific AppIDs here (there are others, this is just one I remembered off the top of my head)
Hope that makes sense :-)
Haha, I feel dumb once again :sweat_smile:
So, to explain myself somewhat, I tried to take your comment from https://github.com/sonic2kk/steamtinkerlaunch/issues/941#issuecomment-1773676882 and run with it:
As for loading the DLLs, you may have to skip the launcher. I'm not sure how this is meant to work, but you should be able to skip the launcher by setting the game EXE as the custom command, which should bypass the launcher. You can use"only custom command" so that the launcher won't start afterwards as well.
However, based on what you wrote here, it seems like some games do not like doing it that way (for the reasons you outlined). I'm somewhat used to renaming launchers, though, so that's fine. Just thought it'd be easier to do it directly through STL :sweat_smile:
With the same game [Zero Escape: The Nonary Games], running the game as a custom command and with the Special K DLL name set to 'auto' creates a DXGI DLL, even though PCGaming Wiki lists the game as a D3D9 game.
I don't see the game on the PCGamingWiki article of SpecialK games. Indeed, it may be compatible, as this list is massively incomplete, but as noted on the SpecialK wiki, STL uses this wiki page to determine the renderer for games.
Download/update the SpecialK Compatibility List to know which rendering API to use
The only related game I can see on this list is "Zero Escape: Zero Time Dilemma", at the very bottom of the page at the time of writing.
If a game is not on this list, auto will not work correctly, as SteamTinkerLaunch downloads and parses this page. I'm not sure how viable it would be to try and search for the game page on PCGamingWiki itself and attempt to parse information on the renderer that way, as I am not sure how consistent the page structure is (structure as in the actual markup, which is different from perhaps just looking similar, maybe an obvious distinction but one I wanted to make).
So, I thought...that STL just took the API from the game page (https://www.pcgamingwiki.com/wiki/Zero_Escape:_The_Nonary_Games#API). I guess I imagined, also...some sort of database, where the game will just be "tagged" with the API across the PCGW wiki. Reading the above, though; it seems like each page has its own value for renderer APIs and such (is this the case?). It looks like ReShade has its own compatibility list, as well, so I guess I know what I have to do now :grin:
On a side note: is it common for open-source tools to grab information from the PCGamingWiki? Ludusavi (https://github.com/mtkennerly/ludusavi) also pulls game save location from there, so I'm wondering if it's like...a central place where I can help multiple projects, if that makes sense :thinking:
If you're handy with Python, you can take a peak at one example of where Steam stores and checks for specific AppIDs here (there are others, this is just one I remembered off the top of my head)
I am a Python novice, but I'll accept your suggestion for when I feel adventurous :grin:
Hope that makes sense :-)
It does...for better or worse. It seems like I'm always fighting against something, though :weary:
Thanks for your erudite replies :pray: :purple_heart:
I'm somewhat used to renaming launchers, though, so that's fine. Just thought it'd be easier to do it directly through STL
It can work sometimes, for example some visual novel patches that install their own launcher but that don't rename original game launcher correctly on Linux, can correctly have their launcher used as a custom command. Other times, iirc for the game "Elite Dangerous", the game will crash if you try to bypass the launcher. I think Sonic Adventure DX also worked, but it's been a long time since I tried that game with STL.
I actually own "both" games you mentioned here (I understand Nonary Games is actually a 2-game collection and not a "single" game really) so if needed I could try it out. I've also seen Attack on Titan up to the end of Season 3 Part 2 so I don't mind trying AoT 2 if there is something specific to be investigated, but I guess probably tomorrow at this point I'll try to re-create the behaviour you described to at least see if it's consistent. And I didn't buy the games just for this issue this time, I've had them in my library for a while :-)
So, I thought...that STL just took the API from the game page (https://www.pcgamingwiki.com/wiki/Zero_Escape:_The_Nonary_Games#API). I guess I imagined, also...some sort of database, where the game will just be "tagged" with the API across the PCGW wiki. Reading the above, though; it seems like each page has its own value for renderer APIs and such (is this the case?). It looks like ReShade has its own compatibility list, as well, so I guess I know what I have to do now 😁
It doesn't take information directly from the game page, it takes it directly from the table on the SpecialK compatibility page. If there is some kind of central database though I'd definitely take a look at that!
I'm not sure how flexible PCGamingWiki is with edits and such but if you were to edit that page to include any missing games, when STL re-downloads the table of games, it should pick up the renderer for the game (it does this automatically after a few days I think, but removing it will also force a redownload).
If each page has its own entry for renderer and this is reasonably consistent (like if anecdotally more pages have it than not, I'm not looking for exact stats here :smile:) then I think STL could use this as a fallback if there's a good way we could fetch the page for the given game. If there's a way to do it by Steam AppID that could work. We could prioritise the table since it has a defined structure, then fall back to trying to find the page by Steam AppID, and if that doesn't work we could try to search by game name to choose the API. The name might be flimsy, but if a user wants the value to always be correct, they can always select the DLL themselves.
On a side note: is it common for open-source tools to grab information from the PCGamingWiki? Ludusavi (https://github.com/mtkennerly/ludusavi) also pulls game save location from there, so I'm wondering if it's like...a central place where I can help multiple projects, if that makes sense 🤔
I'm actually not sure but I have seen it being used a bit! I think a program called Heroic Games Launcher might pull some description information from PCGamingWiki, and I recall seeing some other tools reference it though I forget what they were and how they did it. I didn't write the code to fetch from PCGamingWiki, that actually precedes me by quite a while, so I'm not sure how Frostworx knew the information could be gotten from here. Maybe it is a widely used source, I am not too sure :-)
It looks like ReShade has its own compatibility list, as well, so I guess I know what I have to do now
I wonder if in future there could be a way for STL to use this. I think right now we just default to DXGI, but I guess in future if there's a need, someone could always come along and implement some kind of "auto" option for ReShade as well. I don't think it's that much of a priority though. Good to know though!
A takeaway here might be to down the line investigate some ways to pull information about which SpecialK renderer to use from the PCGamingWiki game page. Though if the SpecialK compatibility list is kept up-to-date, this may be unnecessary, and would benefit more than just STL if it was kept updated. That's easier said than done though, and having a fallback such as for a very new game where the renderer may only be on the wiki page and SpecialK compatibility is unknown, may be worthwhile.
I'll keep it in mind, I have no idea if it's feasible yet or how to implement it, but it's something I could look at in the hopefully near-ish future. It'll be a good break from all the VDF parsing stuff I've spent the last 3 weeks implementing for SteamGridDB and Non-Steam Game work :-)
For the game issues, I don't expect anything to be fixable on the STL side, as I don't think STL is doing anything here that could be causing this behaviour, and I don't think it can do anything to necessarily fix it either -- Though if someone reading this in future knows the issue and a fix, I'd gladly accept a PR :-) I'm pretty sure though, it's kind of just how using a custom command works, it's launched as a separate program which works great for executables you simply want to run in the prefix. Someone used a speedrunning tool with Hades a while ago, some people use "trainer" programs, I personally use custom commands for times when I want the game process to replace the Steam process, such as using the RuneLite AppImage to run a game called Old School RuneScape natively with a separate program.
I also think that when running games and such as custom commands, things like achievements don't work? And that's for similar reasons that weirdness would be happening, the process it's directly attached as the "Steam" process. It's been a long time since I tested and I only remember this with one game, but basically, custom commands are like if you ran an executable with Proton yourself. Sometimes it might get attached to Steam correctly, other times it won't.
The Attack on Titan 2 issue where the PulseAudio delay worked correctly once is weird, but I think perhaps something is set/configured correctly when running via the launcher that just isn't when running the executable directly. I suppose I'll find out soon! We can keep this issue open at least until I test to see what's up with this behaviour.
I actually own "both" games you mentioned here
I had a hunch that this might be the case :grin:
I feel like I have quite a few niche/anime/anime-adjacent titles myself. Unfortunately, those tend to have not-so-great Wine support, so...yeah. Might not be the last game-specific issue, I'm afraid :sweat_smile:
I get that software issues are an interconnected affair, though, so I don't mind you simply pointing me in the right direction :+1:
(I understand Nonary Games is actually a 2-game collection and not a "single" game really) so if needed I could try it out.
This is correct :grin:
I've also seen Attack on Titan up to the end of Season 3 Part 2 so I don't mind trying AoT 2 if there is something specific to be investigated, but I guess probably tomorrow at this point I'll try to re-create the behaviour you described to at least see if it's consistent.
Well, you're leagues ahead of me, then. Like with Sword Art Online: Fatal Bullet, this game was essentially my introduction to the source material, so I'm just taking it in as I go. IIRC, I noticed it way back while looking for another good Musou-type game--basically large-scale beat-em-ups, with most of them made by the same developers--but the price was just crazy at the time. Somewhere around last week, I was looking for a new Action RPG with SteamPeek (https://steampeek.hu/) and it came up in the results. Happened to be about 50% off, so...I took the plunge :sweat_smile:
It's...quite a bit different--and more challenging--than similar titles, though :sweat_smile:
And I didn't buy the games just for this issue this time, I've had them in my library for a while :-)
Well, that's a relief :face_exhaling:
Speaking of purchases, though; for my next issue, Final Fantasy XII: The Zodiac Age (https://www.pcgamingwiki.com/wiki/Final_Fantasy_XII:_The_Zodiac_Age) has some serious issues with saving. With anything besides a clean compatdata prefix, the game complains about "insufficient drive space", even though there's plenty available:
Happens even with "Delete compatdata" set through STL. I basically have to get lucky--since the steamuser backup usually doesn't take effect until after the first run--and then it's the same issue all over again on the next session. I have to hop between Proton versions to get it to work consistently, and sometimes the prefixes seemingly don't get created, so it's...tough going :sweat_smile: A similar issue happens on Windows 10, but the solution there is to tweak Windows Defender, and that's not something that's even installed 🫤
Also, it's been a long time since I last checked, but I think that the "Enable network monitoring" and the "Enable Discord Rich Presence" options both prevent games from closing normally after quitting a game (e.g. the process needs to be killed outside of the game itself).
Do any of these seem like issues that STL can solve?
It doesn't take information directly from the game page, it takes it directly from the table on the SpecialK compatibility page. If there is some kind of central database though I'd definitely take a look at that!
If each page has its own entry for renderer and this is reasonably consistent (like if anecdotally more pages have it than not, I'm not looking for exact stats here 😄) then I think STL could use this as a fallback if there's a good way we could fetch the page for the given game.
Man, what a tricky situation :laughing:
Spreading out to cover more pages is definitely more useful, but if the information's defined in more than one place, there's a risk of update anomalies (when the info in one place is changed, but the others aren't). I'd think it'd work well as a backup, though. I mean, if the game's not in the "master list", the next best thing is the game page, right? :thinking:
If there's a way to do it by Steam AppID that could work. We could prioritise the table since it has a defined structure, then fall back to trying to find the page by Steam AppID, and if that doesn't work we could try to search by game name to choose the API. The name might be flimsy, but if a user wants the value to always be correct, they can always select the DLL themselves.
It looks like the Steam AppID's part of the page (here's the AoT2 page, for example: https://www.pcgamingwiki.com/w/index.php?title=Attack_on_Titan_2&action=edit), so it might be possible to grab it for Steam games. I could very well be mistaken though; I don't have any experience grabbing info from an API or anything like that :smile:
How is it being currently done? Is STL just searching for the title?
I'm actually not sure but I have seen it being used a bit! I think a program called Heroic Games Launcher might pull some description information from PCGamingWiki, and I recall seeing some other tools reference it though I forget what they were and how they did it. I didn't write the code to fetch from PCGamingWiki, that actually precedes me by quite a while, so I'm not sure how Frostworx knew the information could be gotten from here. Maybe it is a widely used source, I am not too sure :-)
Got it :+1:
I wonder if in future there could be a way for STL to use this. I think right now we just default to DXGI, but I guess in future if there's a need, someone could always come along and implement some kind of "auto" option for ReShade as well. I don't think it's that much of a priority though. Good to know though!
A takeaway here might be to down the line investigate some ways to pull information about which SpecialK renderer to use from the PCGamingWiki game page. Though if the SpecialK compatibility list is kept up-to-date, this may be unnecessary, and would benefit more than just STL if it was kept updated. That's easier said than done though, and having a fallback such as for a very new game where the renderer may only be on the wiki page and SpecialK compatibility is unknown, may be worthwhile.
I'll keep it in mind, I have no idea if it's feasible yet or how to implement it, but it's something I could look at in the hopefully near-ish future. It'll be a good break from all the VDF parsing stuff I've spent the last 3 weeks implementing for SteamGridDB and Non-Steam Game work :-)
Glad to help--even though I'm half-responsible for those, too :rofl:
I also think that when running games and such as custom commands, things like achievements don't work?
With AoT2, at least, achievements seem to work. Special K took a screenshot of one, but there's quite a bit of, uh..."tomato spray" in the background, so it might not be worksafe. I'm fine with posting it if you think it's safe, though :+1:
It's good to know, though! Just one more mystery to my weird fluke of a run :rofl:
The Attack on Titan 2 issue where the PulseAudio delay worked correctly once is weird, but I think perhaps something is set/configured correctly when running via the launcher that just isn't when running the executable directly. I suppose I'll find out soon! We can keep this issue open at least until I test to see what's up with this behaviour.
Sounds good! You've given me quite a bit of help already :grin:
It's a bit off-topic, but what's the best way to...find out all that game info on the wiki? Not so much the publishers, developers, etc.; but the renderer, architecture, and those sorts of things. I think MangoHud or the DXVK overlay would work well for finding the renderer, but...the 32/64 bit thing seems difficult to determine :thinking:
So first off, I tested both games mentioned here:
Zero Escape: The Nonary Games
The issue here is that you were seeing an error message around a failure to create a D3D device, basically the renderer couldn't start up. Strangely I didn't have this issue, though I didn't have this issue out of the box. And actually, I think this issue is related to SpecialK, with a fix which is to use d3d9.dll as the SpecialK DLL name, as this is a D3D9 name. This got both games to launch with SpecialK for me, but in my tests, I couldn't re-create any Direct3D errors.
After this, if you didn't already, you can run the game normally with the launcher first, do some configuration, then launch both games. After this, try running as custom commands, with d3d9.dll selected. Some other Direct3D 9 games give similar errors if you launch them without running the launcher first. This step might be necessary for Zero Escape to generate launcher configuration files "properly" with compatdata redirect, due to some potential weirdness with how launchers track settings by some internal GPU ID, if the launcher config files are stored in the prefix. I didn't see them in the game files, so I suspect they might be stored in the prefix.
More Info
For me, a first launch showed the launcher and I configured it to make sure I was using Direct3D 9 and not OpenGL. But trying to start a game resulting in a crash at first with and without STL. Starting the game with a clean prefix using GE-Proton8-22 worked though, then I was able to launch the game vanilla with SteamTinkerLaunch. I was also able to select `ze1.exe` and `ze2.exe`, I assume these are the game EXEs. The started up no problem.Once the game worked with and without STL, I tested with SpecialK, because it totally went over me last night that you were using SpecialK. I tried using d3d9.dll first, I didn't even think to check the DLL you were using at this point, and tried both ze1.exe and ze2.exe, both as custom commands, with only custom command enabled, and they launched as expected with SpecialK.
That was a bit strange, so I re-read the issue and noticed you were using dxgi.dll. I thought "bingo!" and then tried a fresh SpecialK install with dxgi.dll, but the games still launched as custom commands, just without SpecialK. Which I guess is expected, but it's just notable that the games didn't crash for me.
Perhaps you need to launch the game with the launcher if you haven't already and configure it first, then launch with SteamTinkerLaunch, though I'm not sure how this might play with compatdata redirect and launcher configuration, if the launcher configuration stuff is stored per-prefix. Maybe launch with STL and the launcher first, go into settings and configure, and see if that has an impact. Perhaps this is a case of a config file being missing, as launchers will often try to get GPU information and associate some GPU ID with settings. Sonic Generations, which is also D3D9, does this and it is very annoying, and gives similar Direct3D device errors if you launch on one PC and then launch on another without deleting your config and running the launcher again.
I should also point out that while I got SpecialK to "work", I mean I got it to show up, and I didn't test any compatibility beyond that. It might not work properly under Wine with this game, I am not sure, but I got the menu up at least :sweat_smile:
Attack on Titan 2 - A.O.T.2
With this one, I'm honestly not sure. I didn't get any audio crackling, so I can't offer too much more. I tried with 2ch and 5.1ch settings in the launcher, with/without SpecialK, with/without custom command, and by manually setting PULSE_LATENCY_MSEC=60 or PULSE_LATENCY_MSEC=120 when running without STL. I also tried another pair of headphones and didn't experience any crackling.
One potential factor is that on my system I'm using PipeWire, perhaps that is masking an issue? I'm not sure, or sure how relevant it is, and I know PipeWire is reasonably controversial so I'm not telling you to try it and see if it fixes it, because from how I understand the implementation, it shouldn't have an impact. Still, it was something I thought to mention.
More info
I couldn't get the crackling to happen with Proton 8.0-4 or GE-Proton8-22, with and without STL, with and without using the game as a custom command, with and without SpecialK. I tested with PulseAudio latency selected at 60ms, and exported PULSE_LATENCY_MSEC=60 %command% and PULSE_LATENCY_MSEC=120 %command% as the launch options when running without STL. I also tried some combinations with and without the 5.1ch option selected on the launcher, though truth be told I forget which times I used it and which times I didn't, I kind of lost track... But I don't know if this is causing the crackling anyway.
I didn't start up a game save, I just stayed on the main menu and turned the sound up, but if I should start up a game let me know and I'll try see if I can hear any crackling. Someone on ProtonDB mentioned that cutscenes have crackling sometimes, but I think for you this issue is specific to using SteamTinkerLaunch, so that may not be totally relevant.
I have a few pairs of headphones, so I broke those out and tested. My main pair is some AudioTechnica m50xBT2's, but I also have a pair of Grado sr60x's which I tested with. Neither are super high end but I wanted to make sure the problem wasn't being potentially masked. I didn't test over Bluetooth because quite honestly I forgot until I was typing this paragraph :sweat_smile:
Basically I tried a whole bunch of combinations and couldn't re-create the problem. I also tried the launcher juggling trick and didn't have any problems with audio crackling.
I'm just wondering out of interest, what's the use-case for selecting the PulseAudio latency? Does it fix a different issue you're having with the game? I'm just wondering if there's a specific need for it. Usually, it's used to fix audio crackling. For example, DOOM Eternal and I think one Final Fantasy game had crackling audio at launch with Proton, and benefited from tinkering with this option. Maybe the game has audio crackling and you wanted to try using the PulseAudio option to fix it, but no option you chose (including the default 60ms) fixed it?
Something I should note here is that I'm using PipeWire on my system, and not every system uses PipeWire. If unsure, you can check if you're using PipeWire by checking if you have any relevant packages installed with pacman -Q | grep "pipewire", and seeing if you have pipewire, libpipewire, and pipewire-pulse (pacman -Q just lists all packages, and grep "pipewire" picks all items output that have pipewire` in the name).
I'm not looking to start a war over PipeWire or anything, and I'm certainly not saying the problem is caused/fixed by using PipeWire, it's moreso that this is a potential difference in setup that could be a factor. But, I'm far from an expert here!
That's not all good news sadly, but maybe it can point you in the right direction for these titles? I'm hoping at least for Zero Escape it's a little helpful. For AoT, I'm not too sure...
Final Fantasy XII: The Zodiac Age (https://www.pcgamingwiki.com/wiki/Final_Fantasy_XII:_The_Zodiac_Age) has some serious issues with saving. With anything besides a clean compatdata prefix, the game complains about "insufficient drive space", even though there's plenty available. Happens even with "Delete compatdata" set through STL. I basically have to get lucky--since the steamuser backup usually doesn't take effect until after the first run--and then it's the same issue all over again on the next session. I have to hop between Proton versions to get it to work consistently, and sometimes the prefixes seemingly don't get created, so it's...tough going
That is really odd. Does redirect compatdata play a role here, and does this happen without STL? If it happens without STL, I'm not sure if much can be done. I don't own this one so I can't really investigate much. I didn't find anything beyond a couple of Steam Forums post where one person solved it by making another Windows account, and others said what you said about disabling Windows Defender.
This one has stumped me to be honest. It could be an issue perhaps with the Proton prefix being re-created or redirected, but I'm not too sure. If you can, some testing without STL to see if there's a way to re-create the problem on Linux without STL would be helpful. I didn't find anything about this online though so I have a feeling it'll be exclusive to STL. It's also Steam Deck Verified.
Just wondering since it's the "topic" of this issue, are you using STL to bypass a launcher here as well? And if so, if you don't do this, do you run into any issues?
Also, it's been a long time since I last checked, but I think that the "Enable network monitoring" and the "Enable Discord Rich Presence" options both prevent games from closing normally after quitting a game (e.g. the process needs to be killed outside of the game itself).
This one is strange. For security reasons I use Discord on the web instead of the app and never used Rich Presence, so I'm not sure about that, but I guess I could see why this might be happening. The process may not get caught by Steam as a process it needs to close down, but it thinks the game is still running since the processes are attached to the game. I'm not sure if this is recent behaviour or anything as I haven't used these options, but this behaviour is something I could investigate at least for network monitoring. Discord Rich Presence may work as well, even though Discord isn't installed I'm sure the process would still run, it just wouldn't do anything.
I'd think it'd work well as a backup, though. I mean, if the game's not in the "master list", the next best thing is the game page, right
Right, that's my thinking as well :-)
It looks like the Steam AppID's part of the page
I'll have to check to see how the page looks when downloaded, but good find! It could be a good fallback.
The main thing with these two options is actually finding the page to begin with. It may not be as simple as creating a "sanitised" URL based on the game name, but there may be a way to do it. I think it could be a useful fallback.
It's a bit off-topic, but what's the best way to...find out all that game info on the wiki? Not so much the publishers, developers, etc.; but the renderer, architecture, and those sorts of things
Checking whether a game is 32/64bit is a bit (heh) tricky. SteamTinkerLaunch determines this automatically based on either the game EXE or a custom selected EXE, and it stores this in a meta file (~/.config/steamtinkerlaunch/meta/title/general/<game_name>.conf). One crucial thing here though, is that launchers can be 32bit, but games may be 64bit. STL stores the architecture of the default game EXE as set by the developer and stored by Steam in appinfo.vdf, which is a binary file. But as a quick general rule, for games launched with SteamTinkerLaunch, you can check this meta file and look for GAMEARCH.
Without SteamTinkerLaunch, there are various ways, but the way SteamTinkerLaunch does it internally is by using the file command to parse information about the file.
If you want to get the architecture of an EXE, you can run file /path/to/prog.exe and then from the output:
PE32andIntel 80386is 32bitPE32+andx86-64is 64bit
A quick-and-dirty command with prettier output might be echo "$(file Launcher.exe | grep -o 'PE\S*' | sed 's/PE//g;s/.*+/64/g')bit", replacing Launcher.exe with the path to your EXE (takes output from file, grabs only the part standing with "PE" and ending in a space, removes "PE", replaces anything remaining ending with a + with 64 so you get 64bit instead of 32+bit). Only tested this on a handful of executables but it might be an easy way to tell :-)
Well, this was interesting to test. I guess the main things to try here are:
- Try Zero Escape with using the launcher once, then using SpecialK with
d3d9.dll - Try Attack on Titan without the PulseAudio setting, and/or with a different audio channel setting from the launcher, and checking if you're using PipeWire
- Try FFXII without SteamTinkerLaunch
Hope something promising comes out of this! :smile:
Well, this was interesting to test. I guess the main things to try here are:
- Try Zero Escape with using the launcher once, then using SpecialK with d3d9.dll
- Try Attack on Titan without the PulseAudio setting, and/or with a different audio channel setting from the launcher, and checking if you're using PipeWire
- Try FFXII without SteamTinkerLaunch
Hope something promising comes out of this! 😄
Can't say it turned out to be promising, but FFXII brought some unexpected twists nonetheless.
Zero Escape
Tried with the launcher first, then Special K (d3d9.dll) along with the first game as a custom command. Still the same behavior, though :shrug:
Thankfully, ReShade + SpecialK works with the first game when it's run from the launcher (haven't tried the second one yet), so it's not a huge deal if the launcher has to be run every time :+1:
Attack on Titan
So I haven't tried super recently yet, but when I tried with both different audio channels with the launcher, I didn't notice any changes; the custom command still had the audio issues, and the launcher-run version had nice-sounding audio. I don't think I've tried turning the Pulseaudio latency option off with the launcher version, so that's something I can try.
I'm using Pipewire, BTW.
[jeremiah@arcadia ~]$ paru -Q | grep "pipewire"
gst-plugin-pipewire 1:0.3.84-1
lib32-libpipewire 1:0.3.84-1
lib32-pipewire 1:0.3.84-1
lib32-pipewire-jack 1:0.3.84-1
libpipewire 1:0.3.84-1
pipewire 1:0.3.84-1
pipewire-alsa 1:0.3.84-1
pipewire-audio 1:0.3.84-1
pipewire-jack 1:0.3.84-1
pipewire-pulse 1:0.3.84-1
FFXII
So...this one was a bit weird, but I'm glad you asked me to test it.
Tried with Proton-GE 8-22 (through Steam Tinker Launch), and the saves didn't work:
Tried a couple more times with no change.
After, I tried with the game run as a custom command, and I still couldn't save. However, there was a noticeable amount of audio crackling, although not as severe as with AoT2. Tried a few more times with no changes.
Then, I tried with Proton-GE 8-22 directly. Saving worked, but the same amount of audio crackling was also present here. Tried four times--all four saved properly, and the crackling was present in 3 out of the 4 trials.
After that, I switched back to using Proton-GE 8-22 through Steam Tinker Launch. Saving worked the first time--which was expected, since I switched Proton versions--but stopped working after that. Audio crackling was not present when running the game normally, but returned when I ran the game as a custom command. Saving did not work with the custom command, either.
All this seems to suggest that Steam Tinker Launch is fixing the crackling (perhaps due to that one setting--I'll have to test that). While it very well could be my speakers--they've been crackling when I move the volume dial, or when the dial is at certain positions--I can't think of any other native applications that suddenly introduce crackling into an otherwise fine audio stream. I guess I could try braving it with my headphones if you think the speakers might be an issue--I have a pair of Sennheiser HD 280 Pro's that have served me well over the years, and I don't expect them to have the same hardware issues.
Sorry if my comment seems a bit rushed--I'm kind of tired at the moment, but I can probably upload whatever logs you like; just let me know which ones you think would be most helpful :+1:
Tried with the launcher first, then Special K (d3d9.dll) along with the first game as a custom command. Still the same behavior, though 🤷
Hmm, I wonder why it's not working. Maybe if you can find where the launcher stores config files, you could try removing those? Or maybe with a clean prefix? I'm not too sure what would be causing such an error.
If all else fails, maybe using OpenGL will work?
I'm using Pipewire, BTW.
That rules PipeWire out :-)
FFXII
So with this game:
- Without STL, saving works
- With STL, saving doesn't work
- With STL using a custom command, saving still doesn't work, and there is audio crackling
I don't have this game so I can't really test, but it is strange that these issues only happen with STL.
A totally random thought that may be related, the Steam Linux Runtime is not passed to custom commands, and may be a factor here. So it may be worth doing some tests to see if the SLR makes a difference here.
For Zero Escape, I believe the game works if launched normally through STL. What happens if you disable the Steam Linux Runtime and run the game, do you get the D3D error? Feel free to test other constellations and with AOT2.
Then, what happens if you try any of these games using One-Time Run, with the same Proton version selected, and the Steam Linux Runtime enabled? You can do this from the GUI, I recommend doing it while the game is running. So use STL as the compatibility tool, then select One-Time Run. From here, make sure the Proton version selected is correct, then select your game EXE (ze1.exe, ze2.exe, or AOT2_EU.exe), use EXE directory as working directory, and then most importantly, select the "Use Steam Linux Runtime" option. Then you can check to see if you have any issues.
SpecialK+ReShade may work since they may be picked up automatically by having the DLLs in the EXE dir, but if they don't work, we can chalk that up as "expected", since this test is mainly to see if using the Steam Linux Runtime resolves issues with these games.
This may fix the Direct3D issue with Zero Escape, and the crackling issue with AoT2, but I'm not sure about the FFXII issue.
In my tests, there was no change in behaviour. SpecialK was also picked up by ze1.exe, ze2.exe, and AOT2_EU.exe. But since I wasn't having the issues, perhaps the lack of SLR Is the culprit.
I don't remember if I had a reason for not passing the Steam Linux Runtime to custom commands yet or if I just forgot, but there has been gradual progress this year of implementing support for using the Steam Linux Runtime again in STL. Maybe I didn't do it because the SLR is really only intended for Steam games, and I figured for Non-Steam titles a user could just add the executable as a custom command, but I don't think I took bypassing a launcher into consideration.
Boring Technical Explanation
Let me tell you a bit about my good frenemy, the Steam Linux Runtime.
Basically, the Steam Linux Runtime is a container or prebuilt environment that Proton expects game to be ran inside of. It contains a common set of libraries that Proton is built against and expected to work with. As a random example, let's say there's some system audio library. Different distros may have X or Y versions of this library, but Proton (or more specifically, the Wine component) might be built with Z version in mind. The SLR resolves this by having a set of common libraries, so no matter what versions of libraries a distro is using or might be missing, Proton should run the same.
You may have even experienced this with some native Linux titles. The SLR started for native games to give developers a common set of libraries to build their games against, eliminating the need to target specific distros or hardcode for specific library versions. If you've ever tried to play Half-Liife native and gotten errors about it requiring an ancient version of libpng, or Borderlands 2 native missing some openssl-1.0.0 package or not recognizing a cURL version, the SLR was made to resolve those kinds of issues. On SteamOS, all verified native titles run using the SLR.
Even with two Arch distros, there can be any number of changes that might affect things. Newer Arch installs (like yours iirc) may have an ever so slightly different library name, or may be missing a library symlink, than an ancient Arch installs (like the one on my PC, well over 5 years old).
The SLR does often account for weirdness and has resolved a number of issues in the past, including an issue I was unable to reproduce when running a Non-Steam Game, where a Direct3D 11 initialization issue would appear (#772, fixed by #773). The fix was to pass the SLR to Non-Steam Games, which is why perhaps it may fix the issue here.
The SLR has been the cause of headaches before, and I think I will look into passing it to custom commands somewhat soon if it doesn't break things horribly in testing. If using the SLR with One-Time Run fixes even one of the issues here, that would probably make it more of a priority, but since I'm still unsure if it's the cause I'll leave it be for now.
If you have issues with One-Time Run unrelated to these games (iirc in the past there were some problems), I could look into making a testing branch with a change thrown together to use the SLR for custom commands towards the weekend for testing.
Attack on Titan 2
Well, at first I was going to say that the SLR didn't do anything, but it seems to significantly reduce the crackling issue when used with One Time Run. Maybe it's worth including after all? :thinking:
Renaming the AoT2 exe to Launcher.exe still works--no real crackling that I could hear, although it seems like it causes issues with Special K and Steam DRM:
11/09/2023 23:52:45.748: > SteamAPI DLL File Verification: Size Mismatch ( File: Z:\home\********\.local\share\Steam\steamapps\common\AoT2\Launcher.exe,
Expected SHA1: dab45b18df9c377a38e9,
Expected Size: 3962304 bytes,
Actual Size: 33726912 bytes )
11/09/2023 23:52:45.778: > SteamAPI Application File Verification: Match ( File: Z:\home\********\.local\share\Steam\steamapps\common\AoT2\steam_api64.dll,
SHA1: cfff57cafee87aaf527f,
Size: 242976 bytes )
Selecting "Okay" doesn't cause any issues, but the game crashes if the Special K GUI is brought up. It's something I can live with if I have to, though :shrug:
Zero Escape
Still seeing the D3D error, but I've found a bit more info :mag_right:
The Proton log had this important-looking section:
269230.986:01b4:01b8:fixme:xinput:XInputGetBatteryInformation index 0, type 0, battery 0A1EFE0A.
269230.987:01b4:01b8:warn:debugstr:OutputDebugStringA "D3DXCreateEffect : D3DERR_INVALIDCALL.\n"
269230.987:01b4:01b8:trace:seh:dispatch_exception code=40010006 flags=0 addr=7B04F467 ip=7b04f467
269230.987:01b4:01b8:trace:seh:dispatch_exception info[0]=00000028
269230.987:01b4:01b8:trace:seh:dispatch_exception info[1]=0a1efc44
269230.987:01b4:01b8:warn:seh:dispatch_exception "D3DXCreateEffect : D3DERR_INVALIDCALL.\n"
269230.987:01b4:01b8:trace:seh:call_vectored_handlers calling handler at 6F41CFB0 code=40010006 flags=0
269230.987:01b4:01b8:trace:seh:call_vectored_handlers handler at 6F41CFB0 returned 0
269230.987:01b4:01b8:trace:seh:call_vectored_handlers calling handler at 04CED310 code=40010006 flags=0
269230.987:01b4:01b8:trace:seh:call_vectored_handlers handler at 04CED310 returned 0
269230.987:01b4:01b8:trace:seh:call_stack_handlers calling handler at 7B627BD0 code=40010006 flags=0
269230.987:01b4:01b8:trace:seh:__regs_RtlUnwind code=40010006 flags=2
269230.987:01b4:01b8:trace:seh:__regs_RtlUnwind eax=00000000 ebx=00000000 ecx=40010006 edx=0a1ef83c esi=0a1ef770 edi=0a1ef83c
269230.987:01b4:01b8:trace:seh:__regs_RtlUnwind ebp=0a1ef1a8 esp=0a1ef1a0 eip=7b60ee16 cs=0023 ds=002b fs=0063 gs=006b flags=00200206
269230.987:01b4:01b8:trace:seh:__regs_RtlUnwind calling handler at 7BC5FCE0 code=40010006 flags=2
269230.987:01b4:01b8:trace:seh:__regs_RtlUnwind handler at 7BC5FCE0 returned 1
269230.987:01b4:01b8:warn:debugstr:OutputDebugStringA "Compile error in fragment shader.\n"
269230.987:01b4:01b8:trace:seh:dispatch_exception code=40010006 flags=0 addr=7B04F467 ip=7b04f467
269230.987:01b4:01b8:trace:seh:dispatch_exception info[0]=00000023
269230.987:01b4:01b8:trace:seh:dispatch_exception info[1]=0a1efc80
269230.987:01b4:01b8:warn:seh:dispatch_exception "Compile error in fragment shader.\n"
269230.987:01b4:01b8:trace:seh:call_vectored_handlers calling handler at 6F41CFB0 code=40010006 flags=0
269230.987:01b4:01b8:trace:seh:call_vectored_handlers handler at 6F41CFB0 returned 0
269230.987:01b4:01b8:trace:seh:call_vectored_handlers calling handler at 04CED310 code=40010006 flags=0
269230.987:01b4:01b8:trace:seh:call_vectored_handlers handler at 04CED310 returned 0
269230.987:01b4:01b8:trace:seh:call_stack_handlers calling handler at 7B627BD0 code=40010006 flags=0
269230.987:01b4:01b8:trace:seh:__regs_RtlUnwind code=40010006 flags=2
269230.987:01b4:01b8:trace:seh:__regs_RtlUnwind eax=00000000 ebx=00000000 ecx=40010006 edx=0a1ef87c esi=0a1ef7b0 edi=0a1ef87c
269230.987:01b4:01b8:trace:seh:__regs_RtlUnwind ebp=0a1ef1e8 esp=0a1ef1e0 eip=7b60ee16 cs=0023 ds=002b fs=0063 gs=006b flags=00200202
269230.987:01b4:01b8:trace:seh:__regs_RtlUnwind calling handler at 7BC5FCE0 code=40010006 flags=2
269230.987:01b4:01b8:trace:seh:__regs_RtlUnwind handler at 7BC5FCE0 returned 1
Default
Default
LOCALE_ICOUNTRY : 1
LOCALE_ILANGUAGE : 409
CreateDevice : D3DERR_NOTAVAILABLE
SDL_WINDOWEVENT_RESIZED
SDL_WINDOWEVENT_SIZE_CHANGED
D3DXCreateEffect : D3DERR_INVALIDCALL.
Compile error in fragment shader.
269231.012:01b4:0228:trace:seh:NtGetContextThread 0xfffffffe: eax=000010c7 ebx=00000001 ecx=00000000 edx=00000000 esi=09457500 edi=00000002
269231.012:01b4:0228:trace:seh:NtGetContextThread 0xfffffffe: ebp=0a82ff28 esp=0a82fdfc eip=64a8c1ac cs=0023 ss=002b flags=00000246
269231.012:01b4:0228:trace:seh:NtGetContextThread 0xfffffffe: ds=002b es=002b fs=0063 gs=006b
269231.015:01b4:0280:warn:threadname:NtSetInformationThread Thread handle 0x50c renamed to L"wine_xinput_hid_update"
269231.015:01b4:0280:warn:threadname:NtSetInformationThread Thread renamed to L"wine_xinput_hid_update"
steam-477740_fragment_shader_compile_error.log
Also, the OpenGL renderer seems to hang with both games; the first game before the game window opens, and the second game after it opens.
Also, it's a side question, but how does Re-create Wineprefix work with global Proton symlinks? It seems like it finishes very quickly (compared to installing packages through Winetricks), it doesn't seem like it removes the main Proton compatdata directory (Proton-GE-8, etc.), and I still had to install OpenAL through Winetricks to get working audio, despite having it selected in the Steam first run setup:
Final Fantasy XII
No real changes, but running the game through One-Time Run hung the game before the Square Enix logo, then eventually crashed.
Still no working saves :sweat_smile:
Sorry if this isn't that helpful :pray: I've kinda run out of ideas :sweat_smile:
That Zero Escape fragment shader error is really odd. I guess first off, if you're using ReShade, try turning it off in case it breaks this game on Linux and/or without running the launcher first. Otherwise, if you weren't using ReShade to begin with, this is probably some Wine issue. SteamTinkerLaunch doesn't touch anything to do with game rendering, getting into Proton logs for issues is well after a game starts.
If you didn't ready, try running the game without any SpecialK/etc DLLs.
If those Steam first run vars are the defaults then that's fine, but if you selected any extras, I'd reset things to default.
[Zero Escape] Also, the OpenGL renderer seems to hang with both games; the first game before the game window opens, and the second game after it opens.
Does this happen only with SteamTinkerLaunch? I didn't get this behaviour... This worked on my desktop and my Steam Deck (running SteamOS 3.5), but if I remember, you're using mesa-git, right? Maybe there's some issue there with initialising the game outside of the launcher? That seems like a major stretch to me though, I can't re-create any of these problems...
Also, it's a side question, but how does Re-create Wineprefix work with global Proton symlinks? It seems like it finishes very quickly (compared to installing packages through Winetricks), it doesn't seem like it removes the main Proton compatdata directory (Proton-GE-8, etc.), and I still had to install OpenAL through Winetricks to get working audio, despite having it selected in the Steam first run setup
I'll have to get back to you on this one, I don't know actually :-) I don't really know how any of the compatdata redirect stuff works very much, or any of the constellations around it. I think I tested something with it once for another issue and reviewed a PR around it a long time ago, but I haven't used the feature before in a real sense.
However based on what you described it doesn't sound like it installed OpenAL into the prefix properly.
Well, at first I was going to say that the SLR didn't do anything, but it seems to significantly reduce the crackling issue when used with One Time Run. Maybe it's worth including after all?
I think I can include it then, though I'll weigh up whether it should be the default. I'm leaning towards yes because Proton should always use the SLR, but I'll have to think it over a bit.
Renaming the AoT2 exe to Launcher.exe still works--no real crackling that I could hear, although it seems like it causes issues with Special K and Steam DRM
That does look like a DRM error. I don't remember running into this issue but I'll re-test tomorrow. I'm not sure if SteamTinkerLaunch can fix that though. I guess the launcher also acts as a form of DRM? I could see it I guess, if the Steam API DLL is only loaded by the launcher, but then I would figure if the Steam Overlay can get injected that the Steam DRM is initialising properly...
The Final Fantasy XII crash is really odd, but maybe something to do with the working directory. Perhaps the game expects something else, though most just use the game dir.
These issues are very strange, I'll do some more tinkering tomorrow to see if I can re-create issues. Going forward it should be feasible to pass the Steam Linux Runtime to custom commands but whether it resolves any issues remains to be seen.
For Zero Escape, I am suspecting the fragment shader issue is unrelated to STL, and OpenGL hanging could be a driver issue. I dunno if ReShade/SpecialK/other DLLs could break it but on my PC I don't think SpecialK caused an issue when using OpenGL.
For Attack on Titan, the crackling could maybe be related to not using the SLR then, though I can't re-create that problem.
I can't be sure exactly what's causing it but I don't think it's entirely out of the question that it could be an STL issue. I'm not sure what would be causing it, though. It's a real long-shot but disabling the Steam Linux Runtime might help? This is a crazy 2am thought but if there is any compatdata symlinking or any really strange cross-linking going on, the SLR may be unable to allow the game access to wherever it wants to make saves. I am assuming it makes saves in the prefix and not the game files since juggling Proton versions (which modifies the prefix libraries) fixes the issue temporarily. There is a checkbox on the Game Menu to disable the Steam Linux Runtime, you could give it a shot :-)
These issues are very strange, I'll do some more tinkering tomorrow to see if I can re-create issues.
Haha, sorry. You know how me and strange issues are :smile:
Going forward it should be feasible to pass the Steam Linux Runtime to custom commands but whether it resolves any issues remains to be seen.
Got it. I'm just hoping it doesn't cause any new issues :worried:
For Zero Escape, I am suspecting the fragment shader issue is unrelated to STL, and OpenGL hanging could be a driver issue. I dunno if ReShade/SpecialK/other DLLs could break it but on my PC I don't think SpecialK caused an issue when using OpenGL.
SpecialK/ReShade work fine with the launcher, but I'll try disabling them and seeing if that helps :+1:
EDIT: It didn't--at least not with the custom command :disappointed:
With the launcher, the OpenGL renderer works with/without ReShade, but not with SpecialK. SLR didn't seem to make a difference either way. Curiously, after trying with Zink enabled, turning Zink off, and trying again; the game still thought Zink was enabled :confused:
Had to restart STL to get it to recognize the change.
As a custom command, even with OpenGL selected, it still gave me the D3D error box. Maybe the game defaults to D3D9, rather than OpenGL?
I can't be sure exactly what's causing it but I don't think it's entirely out of the question that it could be an STL issue. I'm not sure what would be causing it, though. It's a real long-shot but disabling the Steam Linux Runtime might help? This is a crazy 2am thought but if there is any compatdata symlinking or any really strange cross-linking going on, the SLR may be unable to allow the game access to wherever it wants to make saves. I am assuming it makes saves in the prefix and not the game files since juggling Proton versions (which modifies the prefix libraries) fixes the issue temporarily. There is a checkbox on the Game Menu to disable the Steam Linux Runtime, you could give it a shot :-)
For FFXII, right? I'll give it a try.
Those 2 AM thoughts can really come through sometimes, so I don't mind at all :grin:
As always: thanks for your diligent help in these issues. I know that you're doing this because you want to, and that you use the software yourself, but it's still your time and effort, all the same :pray: :purple_heart:
Also, I made a repo for some shell scripts--mostly the ones you've helped me with so far. It's super super rough, but I figured I'd tell you about it since you helped me out with them :grin:
https://codeberg.org/CartoonFan/misc_helper_scripts
As a custom command, even with OpenGL selected, it still gave me the D3D error box. Maybe the game defaults to D3D9, rather than OpenGL?
Ah, that was a good catch! I didn't expect that. It was also a good hint.
Just confirmed with MangoHud and SpecialK that yes, without the launcher, the game always uses DXVK (and so I assume Direct3D 9, SpecialK says D3D9 anyway). That's unusual and unfortunate :frowning_face: Games in my experience usually handle rendering backends either with a separate executable, or the games can read the launcher preference to know which DLLs to load.
Seems like you're right on the money, the game defaults to D3D9 and ignores the launcher when not launched from it! Other settings are ignored too. The main visible one I could check was windowed mode. From the launcher if I select OpenGL and Windowed mode, ZE1 respects it. But if I do the launcher renaming trick, or use a custom command from STL, the game will launch with D3D9 in fullscreen. Very strange!
I wonder if this is the cause of some issues, maybe there's some weirdness here. I guess a good test would be to try the launcher renaming trick without STL, which I described a bit further down.
EDIT: [disabling ReShade/SpecialK didn't fix the issue]--at least not with the custom command 😞
Maybe the version is causing the issue, but I think it's a stretch.
You could try uninstalling SpecialK for the game, then removing the STL SpecialK files at ~/.config/steamtinkerlaunch/downloads/specialk (all of them is fine, latest, default if you have it, and the HTML file). This will force a SpecialK update. Just in case it's causing the issue, but I doubt it.
Something else which I just noticed for Zero Escape is the d3dcompiler_47.dll. If you remember that whole saga, that caused a whole bunch of crashing issues for me. You could try removing it from the game files to be sure, and then disabling the option to use d3dcompiler_47 with the game. I'm not sure if you already removed this from your testing before but it might be worth checking just to make sure this DLL was completely gone.
Since the launcher seems to influence what renderer is used, I assume the renderer then controls which DLLs are loaded. It might be that when running with the launcher, it overrides d3dcompiler_47 so that the one in the game files is ignored. But when not using the launcher, it respects the DLL override export to use d3dcompiler_47. In other issues, we had the issue the other way around: d3dcompiler_47 caused headaches for me but things worked fine for your tests, now perhaps it's the other way around? :sweat_smile:
Failing all of this, and very sorry if I asked you this before so you don't have to test if you already did: If you run the game with the launcher renaming trick, with or without SteamTinkerLaunch, with the same Proton version, do you also see this issue? In other words, is this issue isolated to SteamTinkerLaunch?
Another little bit that might be interesting to check is if you use the Launcher as a custom command, do you see this issue?
As an aside, maybe you can try verify integrity of game files and/or delete and re-create the prefix for the game? In case something got messed up somewhere, but I don't know if that would be the case since things work as expected when running from the launcher...
So to summarise:
- Try verifying integrity of game files
- Try re-creating the prefix
- Try completely uninstalling SpecialK from the game files, then remove the STL downloaded files so STL will download fresh SpecialK files the next time it installs SpecialK
- Try running without
d3dcompiler_47.dll - Try renaming
ze1.exetoLauncher.exe(renaming the original executable first) and running from Steam without SteamTinkerLaunch, such as with GE-Proton8-22, and seeing if it still gives you the D3D error message- You can test this with/without SpecialK, that should probably not make a difference, but if you wanted to be extra safe, running the game "vanilla" might yield different results, but again I really doubt it
- If you still get this error when running from Steam, the issue may not be on the STL side
- If I already asked you to test this, just reply with the result from before, you don't have to retest :-)
- Try running
Launcher.exeas your custom command and seeing if you get the D3D error message- You'll probably want to rename the EXEs back from the above test, just so the launcher can find them, though these tests don't need to be done in any particular order
Okay, and one final thing to test might be simply running the game executable directly with the same command and variables SteamTinkerLaunch uses.
For Attack on Titan, I'll try work on an option to pass the Steam Linux Runtime to custom commands. I'll drop a ping once it's in master.
It seems like for Attack on Titan, the audio crackling is reduced when using the launcher, or when using the Steam Linux Runtime. Maybe try running with the Launcher as the custom command for STL, which means the SLR won't be used, and see if that causes audio crackling. That should help diagnose whether the issue is related to the SLR a bit better.
- If the Launcher is used from Steam or STL, it's using the Steam Linux Runtime
- If
AOT2_EU.exeis launched from Steam with a launcher renaming trick, it's using the Steam Linux Runtime - If either the Launcher or game is launched from SteamTinkerLaunch using One-Time Run, it should be using the Steam Linux Runtime if the option is set
- If either the launcher or the game is launched from SteamTinkerLaunch as a custom command, it is currently not using the Steam Linux Runtime
So if you experience crackling when the launcher is used as a custom command, my guess is that the SLR is the "fix". Even though it wasn't perfect in your tests. Though, I wonder if the PulseAudio latency is passed to custom commands?
Now for some better news!
I took a quick look at the code and it seems like the PulseAudio latency is not actually set for custom commands. A lot of checks in prepareLaunch happen, but then we run checkCustomLaunch which will launch the game and when using Only Custom Command, everything below that won't get called (because shortly below, launchSteamGame is called). Interestingly,
Now the good news: you know what's very interesting? Our friends Network Monitor and Discord IPC Bridge are also called after the custom command launch, meaning they're ignored when only custom command is in use (and even if only custom command wasn't, they wouldn't start). Most likely for these two, they are being started and the process is getting forked into the background after the game closes, meaning their process is started after game close, which means it makes sense why Steam still lists the game as running!
So three trivial fixes should be possible here: Move PulseAudio, Discord IPC, and Network Monitor checks to run before custom command. I will probably just push that directly to master, they are just exporting/starting processes conditionally and should not break anything.
For FFXII, right? I'll give it a try.
Fingers crossed :-)
As a last note, verifying integrity of game files and/or re-creating a game prefix (or not redirecting compatdata, if you're doing that in any tests), is just to help narrow down where the problem might lay and with as few moving parts as possible. The more "vanilla" a test we can perform the better, it isn't about "you shouldn't use XYZ" feature but more to see where the problem might be coming from. It might seem that way or might seem arbitrary but stripping back the layers and then putting them back on is one method of testing to find out where problems are coming from. My advice on how to help mostly comes from looking at the code to try and understand the problem, and if it's not obvious, I give advice based on the steps that I would take to troubleshoot an issue.
As always: thanks for your diligent help in these issues. I know that you're doing this because you want to, and that you use the software yourself, but it's still your time and effort, all the same 🙏 💜
And thank you for your patience! STL is software that I use myself, but also, that means in a large sense I'm just a user that happens to maintain the project now. I mean that's basically how it went, after months of active contributions I was a likely candidate to take over, and so here I am! I had virtually no experience with Bash and hadn't touched that much of the codebase when I took over, but I did it because I was and still am passionate about this project. Helping users comes under that :-)
Also, I made a repo for some shell scripts--mostly the ones you've helped me with so far. It's super super rough, but I figured I'd tell you about it since you helped me out with them 😁
This is pretty dang cool :smile: It's not that rough to be honest (but I'm not a Bash expert) but keep going and improving anything you can! Building things that you find useful is the best motivator.
The export order for PulseAudio latency and friends (strace, Discord IPC, netrun) has been addressed in 6e72d17ece660713267231263ee0ea34493a78f8 :-)
Guess it's finally time for me give you a big update! :grin:
Some good, thankfully; but a fair amount of weird, negative quirks and things that remain unchanged :confused:
Attack on Titan 2
The Pulseaudio latency commit fixed the audio crackling issue! :partying_face: :tada:
Running the game as a custom command also fixes that Steam DRM-based error with Special K, letting everything work as intended after making the plugin load "Early" in the plugin order.
Some runs will have an audio delay, but that happens with the launcher as well, so nothing weird here.
With that success, I decided to try the rest of the options in the new commit (strace, Network Monitoring, and the Discord IPC).
- Network monitoring still keeps the process from closing properly. Also, does it need a separate program to work properly? I didn't see one on your wiki page, so...not really sure which to download if that's the case :eyes:
- Strace massively lags the game when it's in focus--but not when it's out of focus:
Strace enabled, window in-focus:
Strace enabled, window out-of-focus (The picture didn't come out well, sorry :pray:):
Strace disabled:
But the winner for weird in this set is the Discord IPC:
- I still had to add the running process through Discord to get it to show up. Is this intended? Seems like it kind of defeats the purpose of the Discord IPC process.
- When the game exits, Discord shows the "Last Played" time seemingly as the time the game started, not when it ended.
- With the Discord IPC, MangoHud, and Gamemode enabled (but NOT strace), Gamemode and MangoHud seem to conflict with each other. The MangoHud GUI wouldn't appear when I pressed the keyboard shortcut, and after enabling MangoHud variable (MANGOHUD=1), I got an error like this when the game crashed:
Disabling Gamemode allowed MangoHud to work again:
With strace enabled: Gamemode, MangoHud, and the Discord IPC work together without conflicts :confused:
- To be honest, I'm not sure what strace and network monitoring are actually supposed to do :sweat_smile:
- In the Game menu, "Enable Discord Rich Presence" is located between a bunch of debugging options. Is this intentional? Not a huge thing either way, but I'm curious.
Zero Escape
- Try verifying integrity of game files
- Try re-creating the prefix
- Try completely uninstalling SpecialK from the game files, then remove the STL downloaded files so STL will download fresh SpecialK files the next time it installs SpecialK
- Try running without d3dcompiler_47.dll
None of these fixed the issue, unfortunately :disappointed: . Game still hangs with OpenGL.
Try renaming ze1.exe to Launcher.exe (renaming the original executable first) and running from Steam without SteamTinkerLaunch, such as with GE-Proton8-22, and seeing if it still gives you the D3D error message
- You can test this with/without SpecialK, that should probably not make a difference, but if you wanted to be extra safe, running the game "vanilla" might yield different results, but again I really doubt it
- If you still get this error when running from Steam, the issue may not be on the STL side
- If I already asked you to test this, just reply with the result from before, you don't have to retest :-)
This actually gave the D3D error :laughing:
Try running Launcher.exe as your custom command and seeing if you get the D3D error message
- You'll probably want to rename the EXEs back from the above test, just so the launcher can find them, though these tests don't need to be done in any particular order
I don't remember this one working, but I only saved that one image, so maybe it just hung before anything showed up :thinking:
Okay, and one final thing to test might be simply running the game executable directly with the same command and variables SteamTinkerLaunch uses.
I wasn't really sure how to use the same command and variables as STL, but after running the process with Wine and selecting the game through the launcher, the launcher crashed without showing anything, IIRC.
zero_escape_launcher_wine_log.log
Final Fantasy XII
No change with disabling Steam Linux Runtime, unfortunately.
One thing I noticed (not just this game, but in general) is that Proton-GE seems to have trouble creating its global prefix in some situations. The most consistent way I've gotten it to trigger is to first run the game with another Proton version (Proton experimental, for example); then, on the next run, switch over to whatever Proton-GE version I'm using.
Other than that, it's still the same experience: saving works the first time, per-version, then...doesn't :confused:
Even though I'm still in favor of "Snow halation" as the next release name, the actual experience tends to feel more like "Despair Searching"--or perhaps "Hope Searching", when the finish is in sight :sweat_smile:
Every one of our shared investigations just seems to turn up a bunch of questions and issues until we finally reach the point where it feels like it's been "resolved". It's like a roller coaster ride, each and every time :rofl:
On something that's not STL-related at all: if I press Tab while typing in the comment field, the selecting moves to "Close with comment". Maybe that's how you accidentally closed those other issues before? :thinking:
Anyway, that's it! Was planning to write this up earlier, but couldn't find the energy/motivation. At least one of the games got fixed, right? :grin:
That's some good news about AoT 2!
Network monitoring still keeps the process from closing properly. Also, does it need a separate program to work properly? I didn't see one on your wiki page, so...not really sure which to download if that's the case
I am fairly sure it is, most programs like strace and so on are third-party programs. However, it runs the netrun command, and I can't find a package that this corresponds to. I checked the netmon package and netrunner-bin package, but I can't find what this is for... It was added three years ago, and was not touched since. I also couldn't find anything useful for a network-monitor package.
So... yes, it's supposed to be a third-party package, but I'm not sure which one it's supposed to be! This one long predates me as well.
Strace massively lags the game when it's in focus--but not when it's out of focus:
Makes sense, it's a debugger tool after all :-) It's probably running and dumping a whole bunch of stuff about the application process, which is going to slow the game down. When building software too, running with a debugger is always slower and more resource intensive than running regularly, because a lot of information about variables and processes is being monitored and tracked.
When running with a debugger, I think this is expected. But thank you for testing nonetheless!
Gamemode and MangoHud seem to conflict with each other. The MangoHud GUI wouldn't appear when I pressed the keyboard shortcut, and after enabling MangoHud variable (MANGOHUD=1), I got an error like this when the game crashed:
Hmm, sounds like the launch command gets messed up somewhere along the way. I wonder if the Discord IPC stuff needs to go earlier... I can't test unfortunately. The Discord client is a huge security risk I don't feel like having on my system, and I also don't feel like broadcasting the games I'm playing to the people on my Discord friends list, so I don't know that I can do too much to verify how to fix certain behaviours, though I should be able to investigate the launch order and at least try to prevent a conflict / game crash.
My guess is that somewhere along the way, one of these commands is changing the way the launch command is built. STL basically tracks a whole bunch of variables to know which commands are enabled, and then builds a launch string based on all these conditions (i.e. enable GameScope and MangoHud, but disable MangoHud if MangoApp is used with GameScope, and put OBS Game Capture before/after GameScope, things like that). It's very possible that the order of how some of these things in the launch command are built needs to be adjusted for this constellation.
To be honest, I'm not sure what strace and network monitoring are actually supposed to do
Strace is a debugger, and, well, network monitor is supposed to give information on network activity for a given process from what I can see (or rather, it runs with the game, and all network activity including that tied to a game, is recorded and sent to log file at a specified location). But, I'm not sure what package it is for. The code just runs netrun.
In the Game menu, "Enable Discord Rich Presence" is located between a bunch of debugging options. Is this intentional? Not a huge thing either way, but I'm curious.
It's likely "intentional" so to speak in that it wasn't accidentally put there, but perhaps it was put there without much thought. It could be moved though, if there is somewhere that would fit better in your opinion, let me know :-)
I still had to add the running process through Discord to get it to show up. Is this intended? Seems like it kind of defeats the purpose of the Discord IPC process.
Discord IPC bridge is for Discord Rich Presence, Discord is responsible for picking up the game process, and no program can fix that as far as I'm aware.
This actually gave the D3D error 😆
If Zero Escape still gives the D3D error without STL, I don't think I can fix this one. Sorry about that :frowning_face: I hope that makes sense at least though, because if this is """regular""" behaviour without SteamTinkerLaunch, and isn't caused by SteamTinkerLaunch, I can't really fix it. It seems like Zero Escape just isn't working without the launcher on your setup for some reason, and the issue is not isolated to STL.
Sadly, you might have to use the launcher for this one. Maybe you could re-install the game if you're particularly interested, but if a fresh install fails, you might be out of luck. If you do uninstall, make sure the game folder is completely removed, as Steam won't remove the folder if non-game files i.e. SpecialK DLLs are still in the game files when you uninstall, and the install folder could end up getting re-used -- A protip I learned from headaches in the past :slightly_smiling_face:
You could also try a different Proton version, or a Proton-tkg version, in case this is some specific regression/bug with DXVK (the layer that handles rendering the game). It could also be a GPU driver bug, maybe something on Mesa-git (I'm using Mesa 23.2.1, Mesa-git broke too many of my games last time I tried it a few weeks ago).
I don't remember this one working, but I only saved that one image, so maybe it just hung before anything showed up
Ah, I would say it probably just won't work, unless it took an unreasonable amount of time to start up.
One thing I noticed (not just this game, but in general) is that Proton-GE seems to have trouble creating its global prefix in some situations. The most consistent way I've gotten it to trigger is to first run the game with another Proton version (Proton experimental, for example); then, on the next run, switch over to whatever Proton-GE version I'm using.
Yeah, switching Proton versions is risky business and causes prefixes to get messed up sometimes. It is not uncommon to end up with a file in a compatdata folder steamapps/compatdata/<appid> called pfx-corrupted-somethingorother, where Proton basically gave up trying to repair a prefix, renamed the old one, re-created a new one fresh, and attempted to copy over any relevant data (i.e. My Documents, AppData, etc) into the new prefix to minimise disturbance. This could be just what's happening here.
If you're using any kind of global compatdata for FFXII, I would recommend turning it all off. Try using the game prefix and launching it normally, as the game may not like using a compatdata that isn't the exact one the game should be running in. You can check if the regular prefix is in use by going to ~/.local/share/Steam/steamapps/compatdata/595520 (I assume the AppID is 595520 and that it's on your home drive, adjust the path if it's wrong :-)) and checking to see if it's modified when you launch the game. This will rule out any redirected/global compatdata causing the saving issue.
So it looks like Attack on Titan 2 is fixed, glad we got the crackling all resolved! But less happily, it seems like for some reason, Zero Escape isn't working for you. But it happens without SteamTinkerLaunch as well, so I don't think it's something I can fix.
The Discord IPC issue is something I can try and investigate a little bit, to see if I can resolve anything there.
The Final Fantasy issue is something I'm definitely willing to investigate further, on one hand I am somewhat interested in seeing a Proton log from a game run when this occurs, but on the other hand that is just me being curious, and I am by no means a Wine developer so it would probably mean nothing to me and I could end up going on a totally unrelated path. It seems like it's got something to do with the prefix though, and if you're doing any kind of prefix redirecting / global prefix / etc, that could be causing issues. So try running the game without any of those settings if you're using them, and let the game run as "normal" as possible.
The Final Fantasy issue is something I'm definitely willing to investigate further, on one hand I am somewhat interested in seeing a Proton log from a game run when this occurs, but on the other hand that is just me being curious, and I am by no means a Wine developer so it would probably mean nothing to me and I could end up going on a totally unrelated path. It seems like it's got something to do with the prefix though, and if you're doing any kind of prefix redirecting / global prefix / etc, that could be causing issues. So try running the game without any of those settings if you're using them, and let the game run as "normal" as possible.
If you're using any kind of global compatdata for FFXII, I would recommend turning it all off. Try using the game prefix and launching it normally, as the game may not like using a compatdata that isn't the exact one the game should be running in. You can check if the regular prefix is in use by going to ~/.local/share/Steam/steamapps/compatdata/595520 (I assume the AppID is 595520 and that it's on your home drive, adjust the path if it's wrong :-)) and checking to see if it's modified when you launch the game. This will rule out any redirected/global compatdata causing the saving issue.
Done! :grin:
Same results; although there's yet more new oddities, as usual.
Despite having both redirects disabled, the STL GUI still has the global steamuser symlink:
After re-creating the Wine prefix, the folder structure appears to be correct. However, after starting the game, the steamuser dir gets symlinked to the global one before the game window even shows up:
Saving still only works the first time. My saves and settings get brought over from the Steam cloud, but is that really what's causing the symlink?
There's also an error box that occasionally shows up after the game closes, but it disappears very quickly; I haven't been able to get a screen capture yet. It says something like "Saving requires register"--again, I haven't been able to read the whole message yet, so...can't give you more info, unfortunately :frowning:
595520_gamelaunch.log steam-595520.log 595520_steamtinkerlaunch.log 595520.conf.zip
But less happily, it seems like for some reason, Zero Escape isn't working for you. But it happens without SteamTinkerLaunch as well, so I don't think it's something I can fix.
Really, the launcher (with D3D9) picks up both ReShade and Special K, so it's not too big of a deal. I just wanted to know if I could shave a little off of the startup time :grin:
I am fairly sure it is, most programs like strace and so on are third-party programs. However, it runs the netrun command, and I can't find a package that this corresponds to. I checked the netmon package and netrunner-bin package, but I can't find what this is for... It was added three years ago, and was not touched since. I also couldn't find anything useful for a network-monitor package.
So... yes, it's supposed to be a third-party package, but I'm not sure which one it's supposed to be! This one long predates me as well.
Makes sense, it's a debugger tool after all :-) It's probably running and dumping a whole bunch of stuff about the application process, which is going to slow the game down. When building software too, running with a debugger is always slower and more resource intensive than running regularly, because a lot of information about variables and processes is being monitored and tracked.
When running with a debugger, I think this is expected. But thank you for testing nonetheless!
Strace is a debugger, and, well, network monitor is supposed to give information on network activity for a given process from what I can see (or rather, it runs with the game, and all network activity including that tied to a game, is recorded and sent to log file at a specified location). But, I'm not sure what package it is for. The code just runs netrun.
Thanks for the info :+1:
Discord IPC bridge is for Discord Rich Presence, Discord is responsible for picking up the game process, and no program can fix that as far as I'm aware.
Got it. I'll keep that in mind when I need to broadcast what I'm doing :+1:
Just in case I didn't mention: manually locating the game through Discord works fine (with the window title and everything). I just wasn't aware that that extra step was needed :sweat_smile:
It's likely "intentional" so to speak in that it wasn't accidentally put there, but perhaps it was put there without much thought. It could be moved though, if there is somewhere that would fit better in your opinion, let me know :-)
Hmm... :thinking:
- Underneath obs-gamecapture
- After Luxtorpeda
- Switching places with Strace (since strace is for debugging, rather than network monitoring)
Those are my best suggestions at the moment.
Hope this helps, and let me know if I forgot anything (or if there's something you wanted me to add)!
Despite having both redirects disabled, the STL GUI still has the global steamuser symlink
After re-creating the Wine prefix, the folder structure appears to be correct. However, after starting the game, the steamuser dir gets symlinked to the global one before the game window even shows up
This could be a bug, actually it sounds likely that it is on the surface, but I'll take a look at the logs and see if I can figure it out in case there might be some setting somewhere controlling this unintentionally. Your screenshot of the settings look correct, though. I appreciate attaching the logs and configs, it'll make this more straightforward to investigate! :-)
Saving still only works the first time. My saves and settings get brought over from the Steam cloud, but is that really what's causing the symlink?
I don't think so, but I think perhaps the game / Proton is doing some specific things that might not play nice with symlinking. It's hard to say right now but I could see perhaps the game reading a symlink incorrectly, or perhaps it's reading the real prefix once but not again, and so that's why it works each time you change the Proton version.
It would suck if you couldn't use this feature with this game, but maybe this has uncovered an issue with the symlink options, since it seems like STL isn't reverting back to using the game prefix, and is still using the redirect.
Unless STL needed a restart to pick up this change? I'm not sure, I'll need to check. I don't own this game but I doubt this symlink issue is specific to this game :-)
Really, the launcher (with D3D9) picks up both ReShade and Special K, so it's not too big of a deal. I just wanted to know if I could shave a little off of the startup time
Yeah, sorry about this :sweat_smile: I really hope it doesn't come across as brushing an issue off, but generally speaking, if an issue happens with and without STL, I usually chalk it up to weirdness that I can't do much about. Of course there are cases where an STL feature is supposed to resolve an issue (i.e. a DLL override), and if that feature isn't working then I investigate that on a case-by-case basis, but when a feature isn't working from a game launch scenario, it might just be some setup weirdness.
Just in case I didn't mention: manually locating the game through Discord works fine (with the window title and everything). I just wasn't aware that that extra step was needed
Sometimes Discord doesn't pick things up properly, the Steam Linux Runtime likes to get in the way afaik, I used to see people on Discord playing pv-bwrap a lot heh, but really the way DIscord picks processes up isn't always the best from what I recall.
I'll still need to look into the issue of Discord IPC not working when some other options are enabled though.
Those are my best suggestions at the moment.
I like it going underneath OBS Game Capture, I'll look into that!
I think that about covers it. Main things left in this issue:
- FFXII save issue
- Symlink setting may not be getting properly disabled
- Discord IPC conflicts with other custom programs i.e. MangoHud and GameScope. I wonder if this is caused by passing external programs to Discord IPC? Though they shouldn't get passed afaik...
- Move Discord IPC setting
For the Discord IPC checkbox change: Changed my mind, I like the Discord IPC setting after Luxtorpeda better :-) Gonna push that in a bit!
For the Symlink issue: I took a look at your config for 595520.conf, it looks like the USESUSYM (Steamuser symlink) and USEGLOBSUSYM (Global Steamuser symlink) are both enabled still. These are checkboxes further down, at pretty much the bottom of the "Proton options" menu. You can also just set those variables to 0 in the config file.
This is probably why the symlink is still happening.
I also checked the code, and leaving ONLYPROTMAJORREDIRECT (only redirect for major Proton versions) enabled should be fine. It seems like this code will actually store the directory name, but it isn't used unless REDIRCOMPDATA is not disabled.
For the FFXII save issue: We should investigate without any symlinking first, in case the game has problems reading a symlink.
Apart from that, no change yet!
For the IPC conflicts: Nothing yet, no testing has been done just yet :-)
Well I tested with the Discord Rich Presence thing, and at first, the game would just crash when using it with MangoHud (with/without GameScope). Now, it "works" in that it doesn't crash, but looking at the extProtonRun log it seems like it crashed (it seemed like it crashed even when the game process didn't start). I can't get it to "not work" again, in that I can't get it to
For what it's worth, I don't think Attack on Titan 2 actually has any Discord Rich Presence? RPC is the thing where games can transmit extra information, such as what level you might be on, what enemy you might be fighting, send a request to join their party, that sort of thing.
From looking at the repo, it seems like the way it works with the SLR has changed now. It looks like there's a script that it uses now. Probably a change can be made here to symlink the winediscordipcbridge.exe file to the game folder, copy the script into the game folder, and run the script (which should manage running the EXE). Though no idea how this would play with STL.
I don't use Discord RPC or anything, so I can't really fix this, this fix will have to come from a community member that wants to fix it.
For the FFXII save issue: We should investigate without any symlinking first, in case the game has problems reading a symlink.
Done!
Weirdly enough, Steam brought back my previous set of game saves this time. Didn't really affect the outcome either way (saving still fails on a 2nd run), but it was rather unexpected :sweat_smile:
595520.conf.zip 595520_gamelaunch.log steam-595520.log 595520_steamtinkerlaunch.log
For the Symlink issue: I took a look at your config for 595520.conf, it looks like the USESUSYM (Steamuser symlink) and USEGLOBSUSYM (Global Steamuser symlink) are both enabled still. These are checkboxes further down, at pretty much the bottom of the "Proton options" menu. You can also just set those variables to 0 in the config file.
Since we've been recently talking about making changes to the GUI:
- How do the two checkboxes differ from the drop-down menus above?
- Would it be all right to move the steamuser/compatdata stuff at the bottom to where the other redirect options are? Seems like it'd make sense to have everything in one place :eyes:
For what it's worth, I don't think Attack on Titan 2 actually has any Discord Rich Presence? RPC is the thing where games can transmit extra information, such as what level you might be on, what enemy you might be fighting, send a request to join their party, that sort of thing.
I didn't know this :open_mouth:
I don't think so, but I'll try to check. It's not a feature I'm probably going to use often, but it seems useful for online co-op or letting my friends know what game I'm playing.
Really, the launcher (with D3D9) picks up both ReShade and Special K, so it's not too big of a deal. I just wanted to know if I could shave a little off of the startup time
Yeah, sorry about this 😅 I really hope it doesn't come across as brushing an issue off, but generally speaking, if an issue happens with and without STL, I usually chalk it up to weirdness that I can't do much about. Of course there are cases where an STL feature is supposed to resolve an issue (i.e. a DLL override), and if that feature isn't working then I investigate that on a case-by-case basis, but when a feature isn't working from a game launch scenario, it might just be some setup weirdness.
Not at all! You've been seriously considering...pretty much everything I put out here, so I don't feel like you're brushing my concerns off at all. STL (and you) can only do so much, so I understand where you're coming from :purple_heart:
Well I tested with the Discord Rich Presence thing, and at first, the game would just crash when using it with MangoHud (with/without GameScope). Now, it "works" in that it doesn't crash, but looking at the extProtonRun log it seems like it crashed (it seemed like it crashed even when the game process didn't start). I can't get it to "not work" again
Ah, I see. Seems pretty similar to what I experienced :thinking:
Sometimes Discord doesn't pick things up properly, the Steam Linux Runtime likes to get in the way afaik, I used to see people on Discord playing pv-bwrap a lot heh, but really the way DIscord picks processes up isn't always the best from what I recall.
I've got:
- pv-bwrap
- wine-preloader/wine64-preloader
- x86_64-linux-gnu-inspect-library/i386-linux-gnu-inspect-library
- x86_64-linux-gnu-capsule-capture-libs/i386-linux-gnu-capsule-capture-libs
- pressure-vessel-wrap
- proton
- wineserver
- steam-runtime-launcher-interface-0
I have no idea what any of these games are. It'd be great to one day have an open rich presence protocol, so I don't have to be concerned about where my data's going or what it's used for. Which isn't me saying that STL needs to do that--just that it would be nice to have available in the software ecosystem.
Thanks again! :pray: :purple_heart:
Done!
Weirdly enough, Steam brought back my previous set of game saves this time. Didn't really affect the outcome either way (saving still fails on a 2nd run), but it was rather unexpected 😅
If the saves changed, the compatdata is definitely suspicious here. Do you know if the same compatdata is being used with and without SteamTinkerLaunch? You could check if the prefix files are updated with/without STL, so if the files update when launched without STL, you know Steam is using them. But if they don't update with STL, then STL isn't using them.
Something is afoot with however this game is interacting with the prefix, is my best guess. On the first launch, it might be using the right path, but on a second launch, it isn't for some reason.
How do the two checkboxes differ from the drop-down menus above?
I'm not sure why there's a difference. Usually STL has a pattern of having a checkbox to enable a feature, and then you can pass additional info. But in this case I'm not sure why we couldn't infer that disabled would mean the same as the checkbox being turned off. I'd have to check to see more about how this was implemented to understand that, but I'm curious now too.
Normally, this pattern of a checkbox is when there's no straightforward way to infer when an option should be disabled. For example, with custom commands, there is a checkbox because it's convenient to toggle this, but also there is no easy way to remove the selected custom command without editing the config file (Yad doesn't have an option to clear these boxes with something like backspace or a middle-click).
Would it be all right to move the steamuser/compatdata stuff at the bottom to where the other redirect options are? Seems like it'd make sense to have everything in one place 👀
I think that's fine, normally the checkboxes are close by. I'm not sure why they're so far apart. Normally the pattern would be toggle checkbox -> related widget (in this case, the checkbox and then the dropdown). I only had a feeling there was an extra checkbox and had to check to confirm it earlier, it did strike me as weird that they were so far apart... Maybe options just pushed them further apart as time went on.
Should be feasible to move them close together but I'll investigate later this week. In 99.9% of cases though, moving UI elements has zero impact.
Ah, I see. Seems pretty similar to what I experienced 🤔
Yeah, my guess is something just isn't working right with how Rich Presence is implemented. It was implemented a long time ago now, in #511 I think. I haven't seen a single person try it, and only vaguely remember seeing the commits where it was added. Looking into adjusting it would be a bit tricky, and someone out there might be using it somehow, so I'd rather not strip it out entirely. Hopefully someone with an understanding of how it all hangs together can come forward to improve it though.
It seems to me to be some kind of weirdness where the process causes the game process to fall over. I couldn't tell you why though, and it seems intermittent. The steps on the Discord IPC Readme might work but I don't know how running this with STL would go. It might be fine, since it runs before %command% when launching without STL, I assume we could just run it before game start, but I don't know what Unforeseen Consequences it may bring. But then I think the script may have a delay to wait for the game, since I think it waits for the game process to start up (or more specifically, the Steam Linux Runtime) and tries to attach itself to that.
Couldn't say for sure though, I'd have to spend some time looking into it, maybe if no one contributes it I'll take a peak whenever the dust settles with some of the ongoing work.
I've got:
Most of those are processes are related to Wine/Proton, I'll try explain my understanding of them if you're curious :-)
pv-bwrapandpressure-vessel-wrapare the Steam Linux Runtime. If you've ever used Flatpaks, the Flatpak Team developed a container solution called "bubblewrap". Valve's open-source Steam Linux Runtime containers are called "Pressure Vessel", because they're "Steam in a container". Basically, a set of common libraries that can be used to run games in a containerized environment.steam-runtime-launcher-interface-0is a new one to me, but I imagine it's some kind of mount to allow applications to talk to the Steam Linux Runtime. I am no container expert though :sweat_smile:- I'm not too familiar with anything when it comes to containers and sandboxing, so don't take it all as hard fact, but hopefully it helps give a little bit of insight as to what these processes are (and I never miss an opportunity to point out fun naming schemes).
wine-preloaderorwine64-preloaderare Wine executables, they're a standard part of Wine and for Proton, can be found underProtonName/files/lib/wine-preloader, orProtonName/files/lib64/wine64-preloader(where the 64 denotes 64bit). Valve Proton often usesdistinstead offiles, but it varies (Proton Hotfix, for example, usesfiles), and community Proton flavours usually usefiles.wineserveris some process that acts as the "host" Wine process for the given application and manages translating all of the API calls as far as I understandprotonis the Proton Python script that is used to run a game with Wine. When you start a process from Steam using Proton, it actually calls this script, with the game executable as one of the argument (the first argument is usuallywaitforexitandrun, but others exist, like simplyrun). This script does quite a lot, like checking to ensure a prefix isn't corrupted, attempting to repair prefixes, and tracking the prefix version.- I have no idea what the
linux-gnu-inspect/capture-libraryprocesses are, other than one is for 32bit and one is for 64bit :sweat_smile: A google search even came up empty. If you're runningstrace, maybe it's something to do with that, otherwise I have nothing on these so far... Couldn't get these ones to appear so I couldn't track where they're coming from. If you can find them in a system monitor program though, it might be able to tell you which process they belong to, or at least give a hint. But just to emphasise, I don't think they're anything malicious, and are probably related to Proton in some form or another.
It'd be great to one day have an open rich presence protocol, so I don't have to be concerned about where my data's going or what it's used for.
This would be great, I'd love to see this one day. Free Software and open standards make computing better.
I just want to emphasize that I did read your comment above, but I wanted to get the FFXII results out there as soon as I could, so I hope you're fine with me not (yet) commenting on every interesting point above.
I tested it with Proton-GE 8-23, and saving worked both times (as expected?)
Before
ffxii_before_proton_ge_file_list.log
After 2nd Proton-GE run (forgot to enable logging the first time)
ffxii_after_proton_ge_file_list.log
steam-595520_proton_ge.log
Hope this helps you identify the cause :pray:
I'll check the logs when I'm back at my PC, but do you mean the game worked with SteamTinkerLaunch and Proton-GE-8-23? That would be pretty nice!
Either way I'll investigate the logs and see if I can discern anything. The main thing that sticks out to me is that the file er, permissions "look" different after each run I think? Usually the icon in the 2nd screenshot is when a file is executable. That definitely has my curiosity piqued :-)
I'll check the logs when I'm back at my PC, but do you mean the game worked with SteamTinkerLaunch and Proton-GE-8-23? That would be pretty nice!
Ah, sorry, sorry! I meant that I ran the game twice with Proton-GE (by itself, without SteamTinkerLaunch), and saving worked both of those times. Saving still works once per Proton version with STL :sweat_smile:
Either way I'll investigate the logs and see if I can discern anything. The main thing that sticks out to me is that the file er, permissions "look" different after each run I think? Usually the icon in the 2nd screenshot is when a file is executable. That definitely has my curiosity piqued :-)
Yeah, I'm not really sure why that happened, though I don't think that's unique to this game. Just one more thing for me to observe, I guess.
As for the saves themselves: FFXII_002 was the slot I saved in, so only that file and the Steam cloud should be the ones with updated timestamps.
Sorry for all the confusion :pray:
Thanks for clearing that up, no issues at all. I'll take a look as soon as I can :-)
Possibly relevant / interesting, since the games in this issue were using SpecialK and also because I know you've played a big role in improving the SpecialK support thus far, just a heads up that some changes to SpecialK are coming as a result of #975. The tl;dr is:
- We have a
nightlyoption for SpecialK that downloads builds from the latest GitHub Actions workflow, which corresponds with the latest commit at that time. - (not released yet)
default(GitHub) andlatest(website) is being replaced withstable(website) release. - (not released yet)
customoption is being added, which can take either two SpecialK32/64 DLLs that you manually place, or extract them from a SpecialK installer EXE that is manually placed in that directory (i.e. one from Discord such as the SpecialK Discord Beta or a custom build).
In case you spot these changes, now you know what they are/what's coming and what issue is tracking them :-)
Possibly relevant / interesting, since the games in this issue were using SpecialK and also because I know you've played a big role in improving the SpecialK support thus far, just a heads up that some changes to SpecialK are coming as a result of #975. The tl;dr is:
We have a
nightlyoption for SpecialK that downloads builds from the latest GitHub Actions workflow, which corresponds with the latest commit at that time.(not released yet)
default(GitHub) andlatest(website) is being replaced withstable(website) release.(not released yet)
customoption is being added, which can take either two SpecialK32/64 DLLs that you manually place, or extract them from a SpecialK installer EXE that is manually placed in that directory (i.e. one from Discord such as the SpecialK Discord Beta or a custom build).In case you spot these changes, now you know what they are/what's coming and what issue is tracking them :-)
That sounds pretty cool! :grin:
I've been trying out the nightly option recently; it seems fine for normal use, but I haven't tried it yet with the handful of games that have had problems with the "latest" version, so it'll be interesting to see if it fixes those :+1:
If it's between stable and nightly, then I'll probably stick with nightly (unless some issue pops up) :thinking:
Custom DLLs...could be useful for testing, maybe? :thinking:
SpecialK's kinda worked its way into my default lineup of tools, so any improvements are certainly welcome. Just wondering about some of the use cases for the not-yet-released stuff. I'm not trying to sound ungrateful or anything :sweat_smile:
@sonic2kk It's not related to this issue (unless some older games need their launcher bypassed), but it looks like Proton-GE finally implemented D8VK in their 8-24 release! :tada:
https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton8-24
Honestly, something like a nightly GitHub Actions download for Proton GE/TkG would be really great. I mean, that's not something ProtonUp can do, right? :thinking:
Might be tricky to settle on which TkG branches you'd want to provide downloads for, though.
Still, can't complain too much: we now have a way to try ReShade+SpecialK with a ton of new (old?) games :laughing:
GE-Proton has Actions builds now, but from what I can see, they're not built from Git or anything, and the only one there is GE-Proton8-24, which matches the latest release. STL can already download GE-Proton, from a GUI and from the commandline with steamtinkerlaunch dlp lge for latest GE-Proton, or with a URL. Not sure how the commandline usage fully works but I know this logic is used to download GE-Proton for MO2 installation.
We can also download Proton-tkg, but not from GitHub Actions, because it only points to the GitHub Releases section. It think it's possible to re-use the same kind of logic we use for SpecialK Nightly, though, I remember briefly looking into this around the time of #783 and thinking it was more difficult than I initially thought.
Plus, since ProtonUp-Qt can do it and it hadn't been requested here, I didn't revisit the idea. Also in part because:
I mean, that's not something ProtonUp can do, right? 🤔
Yes, I implemented a lot of that :wink:
Might be tricky to settle on which TkG branches you'd want to provide downloads for, though.
I want to refactor the GUI for downloading GE-Proton/Proton-tkg/Wine builds, but for the commandline, I'd be happy to support all the same ones I added for ProtonUp-Qt :-)
So I don't think GE-Proton needs any kind of nightly download, since it matches the releases section. Proton-tkg would need a nightly download, and by extension, Wine-tkg, since they're both the same repo, with Wine-tkg actually being the main repo and Proton-tkg being a sub build script.
And, fwiw, upstream DXVK is going to get D8VK in the semi-near future I believe, it's pending some refactor and in-depth review the last time I checked. I'm not sure how GE-Proton implemented it but since it's behind a flag I would imagine they're using the D8VK repo and not some patched DXVK containing the PR.
Plus, since ProtonUp-Qt can do it and it hadn't been requested here, I didn't revisit the idea. Also in part because:
I mean, that's not something ProtonUp can do, right? 🤔
Yes, I implemented a lot of that 😉
Nice, didn't even realize that was what was going on behind the scenes. You've done a lot of hard work, it seems :grin:
So I don't think GE-Proton needs any kind of nightly download, since it matches the releases section. Proton-tkg would need a nightly download, and by extension, Wine-tkg, since they're both the same repo, with Wine-tkg actually being the main repo and Proton-tkg being a sub build script.
And, fwiw, upstream DXVK is going to get D8VK in the semi-near future I believe, it's pending some refactor and in-depth review the last time I checked. I'm not sure how GE-Proton implemented it but since it's behind a flag I would imagine they're using the D8VK repo and not some patched DXVK containing the PR.
Man, I'm 0 for 2 this time around :sweat_smile:
The only other two things I've been wondering about with STL (might need separate issues; please let me know):
steamtinkerlaunch update gridseems to be breaking again by putting all the filenames...together? Lots of this:
Console excerpt
[jeremiah@arcadia ~]$ steamtinkerlaunch update grid
Downloading '/home/jeremiah/.local/share/Steam/userdata/103041470/config/grid/5
10
20
30
40
50
60
70
130
211
215
570
730
2200
2630
3020
3480
3590
3830
4000
6550
7940
8080
8190
8870
8930
8980
9480
10090
10150
10180
12100
12110
12120
12130
12140
12150
12200
12210
12900
15320
17450
17460
20500
21670
21690
21980
22200
22330
24010
24960
24963
24980
25000
26800
26803
31170
32330
32440
32450
33905
33930
33934
34190
34270
34330
35080
35110
35140
39140
39150
40400
40700
40990
41070
41074
42680
42700
43110
43160
44350
45760
45798
46500
46510
47760
47780
47880
47890
47892
47893
47894
47895
47896
47897
47898
47899
47930
47931
47932_hero.png'
/home/jeremiah/local/share/Steam/userdata/103041470/config/grid/5
10
20
30
40
50
60
70
130
211
215
570
730
2200
2630
3020
3480
3590
3830
4000
6550
7940
8080
8190
8870
8930
8980
9480
10090
10150
10180
12100
12110
12120
12130
12140
12150
12200
12210
12900
15320
17450
17460
20500
21670
21690
21980
22200
22330
24010
24960
24963
24980
25000
26800
26803
31170
32330
32440
32450
33905
33930
33934
34190
34270
34330
35080
35110
35140
39140
39150
40400
40700
40990
41070
41074
42680
42700
43110
43160
44350
45760
45798
46500
46510
47760
47780
47880
47890
47892
47893
47894
47895
47896
47897
47898
47899
47930
47931
47932_heropng: File name too long
steamtinkerlaunch update grid installed works properly.
- Is there a way to have the
Game Shaderslist default to theShader reposlist? I have to enable each entry for every new game, and theGame Shaderslist shows repos that are disabled in theShader reposlist, which causes an extra step of disabling each globally-disabled shader if I enable all of them inGame Shaders.
Other than that (and the FFXII issue), I am a very satisfied STL user :smile:
steamtinkerlaunch update grid seems to be breaking again by putting all the filenames...together? Lots of this:
Nice catch! For steamtinkerlaunch update grid, we default to all owned games if no argument is provided, but I guess it has the same issue that all installed games had before 08a6bc4. You can also explicitly define owned, though it is the default (I think this explicit option helps with some internal use as well). For Non-Steam Games, you can specify nonsteam.
Should be a quick fix, will push a fix up soon.
Is there a way to have the Game Shaders list default to the Shader repos list? I have to enable each entry for every new game, and the Game Shaders list shows repos that are disabled in the Shader repos list, which causes an extra step of disabling each globally-disabled shader if I enable all of them in Game Shaders.
Honestly, I am not sure. I'm not close to this code and don't use this feature. But enabling some shader stuff by default could be problematic... It may have to get fetched for each game by default then, for example, and I'm not sure if that's a good idea. It might be, and if I have some time I can look into it, but no idea when that'll be.
Feel free to open a separate issue if you have time, maybe someone else can step forward and look at it as well :-)