Open CartoonFan opened 10 months ago
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:
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.
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.
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:
PE32
and Intel 80386
is 32bitPE32+
and x86-64
is 64bitA 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:
d3d9.dll
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.
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:
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
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:
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.
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.
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:
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:
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:
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:
d3dcompiler_47.dll
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
Launcher.exe
as your custom command and seeing if you get the D3D error message
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.
AOT2_EU.exe
is launched from Steam with a launcher renaming trick, it's using the Steam Linux RuntimeSo 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:
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).
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:
Disabling Gamemode allowed MangoHud to work again:
With strace enabled: Gamemode, MangoHud, and the Discord IPC work together without conflicts :confused:
- 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
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:
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:
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:
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:
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-bwrap
and pressure-vessel-wrap
are 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-0
is 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:
wine-preloader
or wine64-preloader
are Wine executables, they're a standard part of Wine and for Proton, can be found under ProtonName/files/lib/wine-preloader
, or ProtonName/files/lib64/wine64-preloader
(where the 64 denotes 64bit). Valve Proton often uses dist
instead of files
, but it varies (Proton Hotfix, for example, uses files
), and community Proton flavours usually use files
.wineserver
is 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 understandproton
is 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 usually waitforexitandrun
, but others exist, like simply run
). This script does quite a lot, like checking to ensure a prefix isn't corrupted, attempting to repair prefixes, and tracking the prefix version.linux-gnu-inspect/capture-library
processes are, other than one is for 32bit and one is for 64bit :sweat_smile: A google search even came up empty. If you're running strace
, 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?)
ffxii_before_proton_ge_file_list.log
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:
nightly
option for SpecialK that downloads builds from the latest GitHub Actions workflow, which corresponds with the latest commit at that time.default
(GitHub) and latest
(website) is being replaced with stable
(website) release.custom
option 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
nightly
option 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)
custom
option 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 grid
seems to be breaking again by putting all the filenames...together? Lots of this:steamtinkerlaunch update grid installed
works properly.
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
.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 :-)
Latest master should have fixed the steamtinkerlaunch update grid
command, just be sure you wanted to use this for all owned games :wink:
Some games may fail, either as expected if they have no AppID, but also we can't tell which AppIDs are internal Steam things, DLCs, etc, so it might also return no art found in those cases as well. But, it should be able to set artwork for all owned games.
I have well over 1,400 games at this point, so I'm not brave enough to test the command too in a real-world scenario apart from fudging the AppID list for testing :-)
Latest master should have fixed the
steamtinkerlaunch update grid
command, just be sure you wanted to use this for all owned games πSome games may fail, either as expected if they have no AppID, but also we can't tell which AppIDs are internal Steam things, DLCs, etc, so it might also return no art found in those cases as well. But, it should be able to set artwork for all owned games.
I have well over 1,400 games at this point, so I'm not brave enough to test the command too in a real-world scenario apart from fudging the AppID list for testing :-)
Thanks :+1:
I have 989 games (looked it up :laughing: ), so you're definitely ahead of me. I'll give it a try shortly.
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 :-)
Got it :+1:
I managed to get the "trimmed" list working before, but I forgot what I did :disappointed:
As I understand it, they're just symlinks (and ReShade won't be able to really do anything without them), but I can see how some might want to pick and choose which repos they want for each game.
I remembered a couple more things (don't be mad, please :pray:)
steamtinkerlaunch update allgamedata
is broken for me:grep: warning: stray \ before -
, sort: write failed: 'standard output': Broken pipe sort: write error
, cp: -r not specified; omitting directory '/home/jeremiah/.config/steamtinkerlaunch/proton/Public/global'
and a bunch of others. Are these harmful? Are there logs that I can provide to help debug them? I haven't noticed anything harmful, but since you're the one maintaining the software, I thought I'd let you know :grin: Hopefully, this time, that's really it for actual bugs. I'll still probably have those "can STL do this" kind of questions in the future :laughing:
steamtinkerlaunch update allgamedata is broken for me:
Looks like a blank value is getting passed to jq
. A quick fix would be to check if -z $1
but I'm not sure what kind of impact this would have.
allgamedata
is for things like game appinfo binary data and is mostly for internal use, so it's probably not a big deal. I'm cautious of touching it too much as this is 3+ year old code and is widely used, but I think a blank check should be safe. I'll do it in a branch and test it to be safe though :-)
The context of this error is trying to get the game name from the Steam API using a given AppID. jq
is used to parse the Steam API response, and the error you've shown with the unexpected ')'
is because it expects a value for .appid==
, but since it gets no value, it isn't happy.
# in getGameName:
# ...
if [ -f "$APIDL" ]; then
if [ ! -x "$(command -v "$JQ")" ]; then
writelog "WARN" "${FUNCNAME[0]} - Can't get data from '$APIDL' because '$JQ' is not installed"
else
writelog "INFO" "${FUNCNAME[0]} - Searching Game Name for '$1' in $APIDL"
# Here is where the error comes from, '$1' is empty
GNRAW="$("$JQ" ".applist.apps[] | select (.appid==$1) | .name" "$APIDL")"
if [ -n "$GNRAW" ]; then
writelog "INFO" "${FUNCNAME[0]} - Found Game Name '$GNRAW' in $APIDL"
fi
fi
else
writelog "SKIP" "${FUNCNAME[0]} - file '$APIDL' not found"
fi
# ...
STL has occasional warnings like
Yeah, these are safe. The grep one especially is just grep being grumpy about some escape characters. It's happened in some other test projects I've written, and I've seen the warnings in STL for a while now too.
The sort
one is probably some kind of blank value being piped , and cp -r
, if it's not causing any visible breakages, it's probably fine. Something is probably being passed to a copy command and being ignored, but since it's likely been this way for a while, I think it's ok :+1:
Good catches all around though, just no "burning" fires I don't think.
Created a branch that experimentally skips the jq
if there is no AppID set. There is also a little more logging in cases where this happens, and when game name is still not set (since fetching from the Steam API is the final fallback).
I will be doing a lot more testing on this before I merge it though, as I'm still cautious of impacts this change could have (maybe too overly cautious).
Good catches all around though, just no "burning" fires I don't think.
Thanks again :+1:
I've noticed that some project maintainers are noticeably more strict than others at keeping their issues on-topic, so that's why I was kind of nervous there :sweat_smile:
Glad to hear that it was semi-useful to you :pray: :purple_heart:
Created a branch that experimentally skips the jq if there is no AppID set. There is also a little more logging in cases where this happens, and when game name is still not set (since fetching from the Steam API is the final fallback).
I will be doing a lot more testing on this before I merge it though, as I'm still cautious of impacts this change could have (maybe too overly cautious).
I'll give it a try once you think it's ready :grin:
P.S. I've been looking at Steins;Gate as my next big "when I have money" purchase, but I'm kinda...I mean, the reviews are glowing, but there's a Horror tag, and people talking about tear-jerkers...I'm just not really sure what I'm getting myself into :sweat_smile:
I've noticed that some project maintainers are noticeably more strict than others at keeping their issues on-topic, so that's why I was kind of nervous there
Sometimes I can be, but you bring up issues in a very thorough manner which I appreciate, instead of just throwing in "this doesn't work, fix it now" :smile:
I'll give it a try once you think it's ready
Hopefully I can get it into master and with enough testing it should be safe enough. When testing things, one thing I do is I usually try to run that branch as my default one and use STL as I normally would. It can be a very useful way to catch some bugs. There are others but it's probably how I catch the most issues :-)
but there's a Horror tag, and people talking about tear-jerkers
It's been almost a year and I still tear up, so I'd say brace for that. For horror, it's definitely a minor aspect, though there is some "cosmic horror"; fear of the unknown, and fear of your own choices! But mystery and sci-fi are the main elements. And whether you decide to get it or not, the reviews are entertaining, especially without context :-)
Sometimes I can be, but you bring up issues in a very thorough manner which I appreciate, instead of just throwing in "this doesn't work, fix it now" π
Thanks. That's something I value as well, although arguably some of my issues are "this doesn't work, and I don't know how to proceed" :shrug: I guess that's somewhat...better?
Hopefully I can get it into master and with enough testing it should be safe enough. When testing things, one thing I do is I usually try to run that branch as my default one and use STL as I normally would. It can be a very useful way to catch some bugs. There are others but it's probably how I catch the most issues :-)
I feel like...I do the same? Maybe? I don't really have a...method, I guess. Just kind of try it and see if anything seems strange.
It's been almost a year and I still tear up, so I'd say brace for that.
Oh my goodness.
So, there are a lot of games that made me sad, but things that made me tear up...my mom got terminal cancer around 3 years ago, so that's...pretty much all I can think of.
I have no idea why I'm writing all this on a bug report, but:
To the Moon made me sad.
Narcissu made me sad (somehow I have 6.5 hours on that game without even finishing it :eyes:)
The Danganronpa games made me sad.
But this sounds like a completely different animal. I'm kind of...intrigued. Apprehensive, but intrigued.
For horror, it's definitely a minor aspect, though there is some "cosmic horror"; fear of the unknown, and fear of your own choices!
Gotta love staring at the screen, mulling over choices :slightly_smiling_face:
But mystery and sci-fi are the main elements.
Sounds like it's up my alley :+1:
And whether you decide to get it or not, the reviews are entertaining, especially without context :-)
Yeah, I got that vibe, too :smile:
Anyway, that was a bit of a sidetrack, but since you said you were a big fan of the game (the series?), I figured I'd get your input.
I usually tend towards:
The visual novels I've played so far (Zero Escape, Danganronpa, Ace Attorney, etc.) have been pretty good, but it's a bit more of a jump from my usual, so...I wanted to ask you directly, you know? :sweat_smile:
Anyway, thanks for being accommodating! :pray: :purple_heart:
Haha, so...I encountered an issue with Steins;Gate, perhaps similar to the one with Attack on Titan 2: ReShade and Special K don't seem to work with this game. However, unlike that game, Steins;Gate won't let me run the game by itself; it requires the launcher, from what I can tell, so simply renaming the game doesn't work this time around.
Also, it's not related to STL, but I'm using the Committee of Zero patch, and I'm not seeing any subtitles on the opening (the one at the end of the prologue). Is an override needed? I used the Windows patcher, but there's a Linux patcher, too; should I use that instead?
I've only completed the prologue--mainly because I didn't want to go too far without getting the whole experience--but the game seems kinda...unusual? I assume stuff's going to be explained later--because there's a lot of weird stuff happening already--but there's this...bizarre, detached feel to the writing, as if everything feels...distant (yet exaggerated). It's really hard to describe :sweat_smile:
Anyway, that's the latest from me :+1:
EDIT: No offense intended with any of this. Just sharing my first impressions :pray:
it requires the launcher, from what I can tell, so simply renaming the game doesn't work this time around.
Yes, Steins Gate requires the launcher :-) Both the main launcher and the Committee of Zero launcher get grumpy if you try to skip it, which is annoying.
ReShade and Special K don't seem to work with this game.
Yes, there is no way for ReShade and SpecialK DLLs to load for this game on Linux unfortunately. For SpecialK, there's some kind of global injection that can be used on Windows to get it to work I think, but as far as I know I don't think this is possible on Linux.
I tested this myself a while back when testing probably the initial SpecialK issue we were going through, and couldn't get it to work. My guess is that the launcher tries to load the DLLs and can't/doesn't pass them to the game. Zero Escape was able to do it but this is probably a case-by-case thing rather than anything else.
Also, it's not related to STL, but I'm using the Committee of Zero patch, and I'm not seeing any subtitles on the opening (the one at the end of the prologue). Is an override needed? I used the Windows patcher, but there's a Linux patcher, too; should I use that instead?
The "Linux patcher" just runs the Windows patcher and attempts to guess a Proton version to use, so either should work. Subtitles should work, however, there is a step required where you need to manually rename the launcher. This used to work, but broke on Windows and Linux, you need to rename the original game's launcher to something else, and rename the Committee of Zero launcher (forget what its actual name is, sorry :sweat_smile:) Launcher.exe
.
You'll know you've done it right if, when you run the game, you get this launcher only.
The original launcher is pretty different, it looks kinda how you'd expect, so there's no chance of mixing this one up with the original launcher.
If all that is correct, then note the "Song Subtitles" dropdown on the launcher. It's possible it may have defaulted to Off
, so I'd double-check this as well.
If that fails and you want to be sure the patch installed correctly, outside of the CoZ launcher showing up (the one in the screenshot), the font will be different. The patch page has a couple of comparison screenshots :-)
If this still didn't work, you can try re-installing the patch, or uninstalling the game, removing any lingering files from the patch, and re-installing the game and then the patch. Uninstalling the patch in my experience breaks all games that have a Committee of Zero patch, for some reason it never works properly.
But I don't think that should be necessary. If only the Committee of Zero launcher appears, and the font looks like the one in the patch page screenshots, maybe the Song subtitles were just turned off.
Feel free to ask if you need any more help.
For what it's worth, I don't think the "vanilla" Steam release has subtitles. I believe the subtitles were taken from the PC release long before it was put on Steam, but that they weren't included in the Steam release, as a "selling" point of the CoZ patch is the subtitles. That's why I bring up that the patch may not have installed correctly for some reason, maybe the game isn't picking up or doesn't have the mod files. Or, it could be nothing that deep :-)
I should also mention that there is a way to install the mod files manually. I don't recommend it but if you're curious, the installer basically finds the game install folder, copies the files from the patch folder into the game files (everything in the DIST
folder), and on Linux, sets a DLL override for dinput8=n,b
(WINEDLLOVERRIDES="dinput8.dll=n,b" %command%
if you install manually, or set dinput8=n,b
in the STL Wine DLL overrides). The CoZ launcher even knows when you're using Wine, under "Troubleshooting" in the CoZ launcher, it has a section where it gives some Wine information, so the installer knows as well, and can apply that DLL override in the registry (when you set a DLL override using Winecfg, or even any setting in Winecfg, it writes it out to the prefix registry, more info at WineHQ).
For the Prologue, I had basically the same thoughts. I gave up at least once and then made a new save and read it again. There's a lot of weird things going on, but there's a part in the very beginning that says something along the lines of "The average person perceives only 1% of their surroundings, even if our brains notice something, they forget it a moment later". I tried to put myself in the shoes of the MC as much as I could, and since they were confused, I figured it was okay to go along for the ride.
Also, after a first playthrough, I'd recommend a guide to get the true ending.
EDIT: No offense intended with any of this. Just sharing my first impressions π
Of course! You might not like it and that's fine too, I wouldn't hold that against someone :slightly_smiling_face:
More specific to this issue, when I've had time I've been trying to figure out the issue with FFXII. No progress to report yet though.
Thanks for thoroughly answering my questions and concerns :smile:
So, after a fresh installation and patching of the game, everything seems like it's working properly. Do you know if the "Steins;Gate Steam - HQ FMV Project" is still...a good idea to patch the game with?
https://www.pcgamingwiki.com/wiki/Steins%3BGate#Uncompressed_FMV_videos
After all the trouble it took to get working song subtitles, I'd hate to lose them and have to do the whole process all over again :sweat_smile:
A strange side point was that, with this installation, I had to install the d3dcompiler DLLs through Winetricks to prevent the game from throwing an error. The game worked out of the box last time :thinking:
Also wanted to say that I did read your response, but sometimes the energy to respond to each of these points (as I like to do) just isn't there, unfortunately.
Thank you for your help and...guidance, I guess? Not sure what to call it, but I appreciate your insight :+1: :pray: :purple_heart:
Hmm, I never had to install any Winetricks. I tested a fresh install and it worked fine as well without any Winetricks needed. Maybe the issue is related to the d3dcompiler
in the game files, used by SpecialK/ReShade? Using Winetricks would override that, as it would update the DLL in the prefix, and then tell Wine to use that.
Do you know if the "Steins;Gate Steam - HQ FMV Project" is still...a good idea to patch the game with?
Yeah, I would recommend using this if you're playing at 1080p. If you're playing at 720p (i.e. on a Steam Deck) it's much less noticeable imo.
It has to be installed after the CoZ patch though. It's just dragging and dropping some files into a folder in the game filesa thankfully so no installer here, I think the languagebarrier
folder but I'm not too sure. The HQ FMV Project only works with the CoZ patch because it allows for replacing these.
And no problem, happy to help however I can :+1:
Yeah, I would recommend using this if you're playing at 1080p. If you're playing at 720p (i.e. on a Steam Deck) it's much less noticeable imo.
My monitor's native resolution is 1680x1050, so I guess that's closer to 1080p than 720p :thinking:
It has to be installed after the CoZ patch though. It's just dragging and dropping some files into a folder in the game filesa thankfully so no installer here, I think the languagebarrier folder but I'm not too sure. The HQ FMV Project only works with the CoZ patch because it allows for replacing these.
It's the languagebarrier folder, from what I understand. However, I'm pretty sure--well, it seems like it interferes with the karaoke subtitles (for me), but I'll give it another try. I usually have to do a clean re-install of the game and the CoZ patch to get working subtitles in the opening, so...well, I'll give it a try. Won't know unless I try, right? :grin:
And no problem, happy to help however I can π
Thanks. I know this isn't a Steins;Gate support forum or anything, but I appreciate it :laughing:
And...back to no subtitles. The rest of the CoZ changes seem to be there, though :shrug:
There's no hurry on this, but just wondering if you could check something for me in the Proton logs for FFXII for me, when running with and without STL. The Proton logs are the ones that have all of the Wine spew.
Bad file descriptor
?I was going through some logs and spotted that message, but it might be entirely unrelated. My current working theory is that for some reason when using STL, there might be some problems with how FFXII is reading the prefix. Perhaps symlinks are still being used somewhere along the trail and FFXII can't resolve them.
One way you could check this is by doing the following with the game closed, and then running the game without STL once these steps are complete.
/path/to/pfx/drive_c/users/steamuser/Documents/My Games/FINAL FANTASY XII THE ZODIAC AGE
-- Copy and paste the saves folder somewhere else.saves
, now that folder would be a symlink pointing to wherever you copied them. The command to do this is ln -s /path/to/realfolder/ /path/to/where_you_want_the_symlink
.
/home/gaben/path/to/original_folder
/home/gaben/path/to/folder_that_will_be_symlink
.ln -s /home/username/Documents/ffxii_saves /home/username/.local/share/Steam/steamapps/compatdata/<appid>/pfx/drive_c/users/steamuser/Documents/My Games/FINAL FANTASY THE ZODIAC AGE/saves
-- Nothing that the name at the end of the last path is the name that will be given to the symlink.I hope the explanation of how to create the symlink made sense. They can be tricky, and there may be other ways (your file manager may allow you to drag and drop folders to make symlinks, for example), but the general thing I want to test here is if FFXII can write into a path where the saves folder is symlinked.
It would be strange if the game could read from, but not write to, the symlink path, but you never know.
Once again, no hurry, there's a bit here so just try it out when you have some time :-)
Hope I did this right :sweat_smile:
Save folder
Symlink folder
The game saved properly, although that quick-closing popup showed up at the end. I actually managed to get it this time :grin:
Without STL, the game retrieved my previous set of saves. Didn't see anything about a file descriptor, though :confused:
steam-595520_without_stl_symlinked_save_dir_works.log
With STL, the game loaded my most recent set of saves. Saving didn't even work once this time.
595520_gamelaunch.log 595520_steamtinkerlaunch.log steam-595520_with_stl_symlinked_save_dir_doesnt_work.log 595520.conf.zip
Thank you for testing, and yup it looks like you did the symlinking correctly.
I think my suspicion that FFXII doesn't like symlinks might be on the right track. First, even though the game saved correctly, it showed some error when saving, and this doesn't happen under normal circumstances. Second, saving didn't even work once.
My suspicion is then, that with STL, some symlinking is going on somewhere along the trail. On first load with a new Proton version this isn't happening, but it is on the second load. That's why, at least from what I recall here, juggling the Proton versions causes saving to work once but not on the next try.
If you can try disabling any kind of compatdata redirect, Steam user symlinking, etc, anything that might be causing the game to try and load data not from the direct prefix path, that could be a good troubleshooting step. It might take a while to try and unwind all of that though. It might be an idea to go through the STL per-game config file and manually edit some elements too and/or confirm their values. If you aren't using any of these options as default, then maybe a fresh game config file would solve the problem. By default, the options under, well, "Default" are used as a template for game files. It's probably not worth editing these just to test one game, instead modifying or at least inspecting a fresh game config file might be the way to go.
Feel free to back up your config first, too. Just rename it with an underscore or copy it somewhere, in case you want to restore / reference any other options such as DLL names.
The default config file template is stored at ~/.config/steamtinkerlaunch/default.conf
if memory serves, and per-game configs are stored at ~/.config/steamtinkerlaunch/gamecfgs
. They real files are stored in the id
folder I believe is the name, and there are symlinks with human-readable game names in the title
folder I believe is what it is called. Not at my PC to double check that right now π
You don't have to but if you get extra curious it might be interesting to manually create a symlinked prefix for FFXII. Since we get save errors here with just the save file symlinked I suspect the 100kb error message comes from the game being unable to read the prefix and determine the availabile space, if that makes sense. It tries to save and goes "wait where the heck am I, what is this" and falls back to being unable to save because it can't properly understand the prefix. Since the entire prefix or perhaps just the Steamuser folder is symlinked/redirected, the game is just unable to determine any information about how to read the size of the prefix, which to the game, is the Windows installation.
I guess the Wine log message was a red herring, but the symlinking could be confusing the game. I guess we just need to try testing with nothing is being symlinked/redirected using STL and hopefully that allows us to test as close to how the game would run without STL as possible :-)
If you can try disabling any kind of compatdata redirect, Steam user symlinking, etc, anything that might be causing the game to try and load data not from the direct prefix path, that could be a good troubleshooting step. It might take a while to try and unwind all of that though. It might be an idea to go through the STL per-game config file and manually edit some elements too and/or confirm their values. If you aren't using any of these options as default, then maybe a fresh game config file would solve the problem. By default, the options under, well, "Default" are used as a template for game files. It's probably not worth editing these just to test one game, instead modifying or at least inspecting a fresh game config file might be the way to go.
Does this look OK? Or am I still missing an option somewhere? Saving is still following the same pattern of not working on the second load.
You don't have to but if you get extra curious it might be interesting to manually create a symlinked prefix for FFXII. Since we get save errors here with just the save file symlinked I suspect the 100kb error message comes from the game being unable to read the prefix and determine the availabile space, if that makes sense. It tries to save and goes "wait where the heck am I, what is this" and falls back to being unable to save because it can't properly understand the prefix. Since the entire prefix or perhaps just the Steamuser folder is symlinked/redirected, the game is just unable to determine any information about how to read the size of the prefix, which to the game, is the Windows installation.
I got extra curious :grin:
Still the same results as above, though :shrug:
595520_gamelaunch_symlinked_prefix.log 595520_steamtinkerlaunch_symlinked_prefix.log 595520_symlinked_prefix.conf.zip steam-595520_symlinked_prefix.log
Thank you a lot for investigating, I'm sorry it didn't lead anywhere :frowning_face: It isn't because you did any of the steps wrong, this is just an obscure problem.
I made an issue documenting the things I would like to see implemented/fixed/resolved before v14.0, and I put this issue in under the nice-to-have bugs I would like to see resolved. That isn't to devalue your issue at all, the only crucial things I want resolved before v14.0 are fixing up in-development features (i.e. finishing up SGDB support, and finishing up the Non-Steam Game stuff, basically anything in-flight I want wrapped up). Tying up loose ends for initiatives that I have spent a lot of time researching and implementing. I don't mean any offense by putting it in that category.
I mention this at all though because I am hoping that could draw more eyes on it. Maybe that's too optimistic but I am hoping that since so many people keep asking for v14.0, at least one person could take a look and help figure out the problem, as I am stumped. This is definitely the highest up on nice-to-have issues that I want to get resolved before the next release, and if a new release comes without this being resolved it's not like it will be abandoned.
If I think of anything or discover anything I will still of course help however I can, and I hope I am able to bring more eyes onto this issue and get the attention of someone who might be able to discover the cause of the issue :-)
Thank you a lot for investigating, I'm sorry it didn't lead anywhere βΉοΈ It isn't because you did any of the steps wrong, this is just an obscure problem.
That's a relief :face_exhaling:
I made an issue documenting the things I would like to see implemented/fixed/resolved before v14.0, and I put this issue in under the nice-to-have bugs I would like to see resolved. That isn't to devalue your issue at all, the only crucial things I want resolved before v14.0 are fixing up in-development features (i.e. finishing up SGDB support, and finishing up the Non-Steam Game stuff, basically anything in-flight I want wrapped up). I don't mean any offense by putting it in that category.
No problem at all! If this was the only game I owned, I might be a bit more disappointed, but I've already got a huge backlog as it is, so I can wait :+1:
I mention this at all though because I am hoping that could draw more eyes on it. Maybe that's too optimistic but I am hoping that since so many people keep asking for v14.0, at least one person could take a look and help figure out the problem, as I am stumped. This is definitely the highest up on nice-to-have issues that I want to get resolved before the next release, and if a new release comes without this being resolved it's not like it will be abandoned.
If I think of anything or discover anything I will still of course help however I can, and I hope I am able to bring more eyes onto this issue and get the attention of someone who might be able to discover the cause of the issue :-)
Thanks :pray: :purple_heart:. Maybe someone will come up with a good suggestion :eyes:
Along the line of suggestions: can you think of anything else I can try with Steins;Gate?
Sorry, no idea for Steins Gate. It stills works on my end :frowning:
I also just realised I should put the help wanted label on here. I'll do that now :-)
System Information
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:
The game runs properly when run from the launcher.
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