Non-Steam Games cannot find files in game dir #941
Comments
sonic2kk
added
the
Non-Steam Game
|
Thank you for opening this issue! I realise it's work opening another and it might not always be obvious why (and tbh, it might just be my own preferences and tastes for keeping discussions """clean"""). Anyway:
So this is actually expected behaviiour afaik from Steam. If you don't specify the start directory, Steam will start it from the same directory as the Steam process is started from. When you launch a Steam native game from Steam, it runs If you'd like to see this, start Steam from the terminal and you'll see the So, for this reason, Steam lets you specify the start directory for Non-Steam Games, because these are not managed by Steam and may have other start directory requirements. If you add a Non-Steam Game to Steam yourself, it will use the EXE base directory by default. For example When you launch a Non-Steam game, it will also do the I tested with the STEINS;GATE Committee of Zero Improvement Patch installer, which needs to be executed from the same folder as the EXE. When adding it to Steam, it set the StartDir as expected and the game ran. When I removed the StartDir, it complained that it couldn't find the files needed to run the launcher, and closed. This exact message is actually what inspired the EXE dir option for One-Time Run (most of the rewrite there was because I wanted a better way to run those Committee of Zero patch installers 😄) So hopefully that background explains why the game is complaining that it can't find those files when StartDir is blank, and why it should be populated. I also noticed that SteamTinkerLaunch does not populate this field properly when adding games from the Add Non-Steam Game GUI (it always uses So despite this background, the strange thing is the other parts of your issue.
This is really odd, and I'm struggling to reproduce that behaviour. I even tried renaming directories to match the one I think your game is stored in ( One test I did do out of curiosity, was to set the "Target" path to a path that didn't exist at all. That caused the process to close. If the path existed but was not an EXE, I got a Wine file browser window asking me to select the EXE, but when the path was totally wrong, the process would close before SteamTinkerLaunch could open. It would be interesting if you launched Steam from the commandline and investigated the output of its
This part is particularly strange, because I actually use this fairly regularly. I suspected maybe this didn't work for Non-Steam Games for some reason, but I just tested with the Steins Gate patch installer added as a shortcut and I got expected behaviour:
The One-Time Run "Save" option also worked as expected for me. I used the save option because I wanted to keep the EXE selected without having to browse for it again.
Now this is probably the absolute strangest of all, but I was able to replicate this. When launching the patch installer from before with SteamTinkerLaunch (added as a Non-Steam Game), and having StartDir unset entirely:
I have absolutely no idea why this is happening. I'll need to dig into this as well. I wouldn't say this part specifically is a "bug" but it's certainly unexpected behaviour to me (it may have been set this way before I took over).
So launching with SteamTinkerLaunch normally (without using custom command), launching with One-Time Run, and launching directly from Steam using Proton, all result in the same error message about files not being found? And you can't set the start directory properly when using Steam because it just causes the process to close. This is certainly a strange one. The main problems here from what I can see are:
I'll need to do a little bit more investigation work here, but one adjacent issue will be fixed soon (Add Non-Steam Game GUI is not setting the StartDir properly). Thanks for the report, I shall investigate! |
|
The blank StartDir was fixed with #942, although in this case, I suppose this will cause a game crash... But that isn't necessarily specific to using STL as far as I understand it, and this is just following the default Steam behaviour. So while it's meant to be safe (and "it works on my machine") it isn't working for you and will warrant further investigation anyway! 😄 |
That's fine. Most of the ground work was done in the old issue's comment, and we always seem to find a lot of topics to cover 😆
I did not know all this 👀
This came up a few times in the Steam log. I guess that's what you meant? 🤔
I see 😁 I have quite a few older games on GOG, and some of those have separate config executables (like the Ys series, for example), so that's the use that I thought of. Would certainly be useful for patchers/launchers/etc as well, though 👍
Besides removing the start dir, the two directories I tried were:
Steam's file browser has been really unusable for me lately; it usually crashes right after selecting a file or folder.
Here you go!
shows up three times.
I haven't seen any of these errors 👀 I'm still getting this result:
Running the game through a standalone wine-tkg-staging (outside of Steam) gives the same error, along with this output:
The only change I'd like to make here is that the One-Time Run error message is different from the others.
Yes, although I experienced a particularly strange quirk while testing this particular route. After running the game with the correct StartDir, the game closed immediately (as before). However, when I went to change the StartDir to the directory just above the game dir, the game...started normally? I didn't even get a chance to actually change the directory, IIRC; the game just started up when I clicked over to VSCodium.
Aside from that hard-to-reproduce thing above, yeah 🫤
Thanks! 💜 🙏 Logs |
Sorry if I wasn't clear, those errors are specific to the program I was testing. That program will complain if the working directory is not the same as the game directory, which is why I'm using it for testing as if it works, it means the working directory / StartDir is set correctly :-)
Hmm, I can see it, and just to make sure, this message even shows up when you have the start directory set? If you set it to the one directory above like you mentioned later on in your reply, do you still see the chdir error message? This is delving into the territory of Steam doing the wrong thing, which is fascinating. Are you running the Steam Client Beta by any chance? I checked and didn't see any mention of a fix for this in any recent Client Beta, and it probably would've been noticed a long time ago and fixed in stable, but just wondering :-) Out of curiosity I also tested from Big Picture Mode, in case Steam was not launching games properly from Big Picture, but it still worked on my end.
And so it gets even stranger :-) Ok, this is some good information. I'll see what I can find out, what I'll look at next I think is what the heck custom command is doing to set the working directory, and what working directory it uses for various different launches to see when it does this and why. Very odd indeed! |
No to both? Did I do something wrong? The results are still the same as before: terminal_steam_log_game_dir.log - no chdir present
Surprisingly, no! I guess I haven't switched over since my big OS re-install adventure 😄
I'm also using Big Picture Mode 👍
Just wanted to point out that the "Tokyo Xanadu eX+ has stopped working" dialog has been there for years now. As I remember, the game uses Windows Media (possibly also Media Foundation) for its intro videos, and Wine just does not like to play them for some reason. I'm honestly really happy to even get one of the three of them working out of the box with Proton-GE 👍 |
Hmm, I'm seeing that now too, however yesterday and today I was seeing in my own logs the I don't think it's related here thankfully, I think this is either my own misunderstanding or a Steam client change, because it happens with Steam native games too. So likely nothing to worry about 👍
Ah yes, this is pretty common. Especially back in the early days of Proton this was a big pain point (some games that used to show this still don't work ootb, Catherine Classic comes to mind). So my testing didn't bring me anywhere, I couldn't re-create this problem. I also haven't yet tracked down why custom commands change the working directory (imo should be an option, maybe on by default, but toggle-able, though I did see a It's difficult to see in the Steam Big Picture because of what appears to be a bug with the Properties screen, but could you check even from the regular Desktop client if the StartDir is being set as expected and saved by Steam? This would essentially rule out any "corruption" with If Steam is saving the path correctly and it can read it properly when the window/even the whole client is closed and opened again, then I doubt it's any kind of corruption. Not to mention, Steam is pretty good at repairing its own files, including these VDF files. By the way, by "works", I mean it doesn't give that error and gets to the main menu, and I can change settings. Cutscenes are broken with Proton Experimental, but seem to work fine with GE-Proton (as you noted, so just making it clear what I mean by "works" 🙂) I didn't test the actual game, so no idea on further compatibility, but it boots up to the main menu. If you need me to test any further than this let me know :-) Here's what works (tested from regular client and in Big Picture):
Now onto when it doesn't work:
Something interesting I learned in my travels is that So there are a few things here now:
And for confirmation as well:
As a small aside, I also noticed that I broke Non-Steam show pics in STL again, so I've written that down and I'll investigate. |
And it wasn't even on sale...sorry for putting you through all this 🙏 I'm a big fan of the Ys series (also made by Falcom), and I managed to pick it up on sale, so my experience might not be representative of the average player's. However, it's a fun Action RPG that I enjoyed for the 4-5 chapters I've played (IIRC) so far. I've heard people say it overstays its welcome by the end, but...haven't gotten that far, yet 😅 Glad to hear it works for you without any extra steps, though 👍
Sure! Everything looks like it's as it should be 😄
Got the same error as before 👍
That's correct! I've only gotten the "Tokyo Xanadu eX+ has stopped working. Crash dump has been generated." error thus far.
Now this...was strange. Adding the game manually worked fine, with or without the enclosing quotation marks:
I don't remember the STL GUI showing up, though, even though Steam Tinker Launch is the default compatibility tool. Do you think that might make a difference? 🤔 Removing and re-adding the game through STL brought back the same behavior as before: terminal_steam_log_stl_ansg.log
Same behavior as with Big Picture, for better or worse 😄 Anyway, hope all this helps. Please don't hesitate to ask if you need more info 🙏 |
|
Thanks for the updates! I was working on some upgrades to Add Non-Steam Game's SteamGridDB functionality (#944), didn't have much more of a chance to dig into this today, but I'll look into it some more tomorrow most likely :-) It's very interesting that it works when added through Steam, but not SteamTinkerLaunch. This is a super generic thing to say but, does using the latest STL resolve things? In case #942 somehow fixes this, but I doubt it. It's not like you're using an outdated version, I've just been doing some changes lately and I'm wondering if that fix may have fixed this issue, though again I don't see how. The paths set by STL since #942 and the paths set by Steam should be identical, and #942 may even just cause the game to crash right away for you when added by STL since it sets the path... Switching gears, what if you add it through SteamTinkerLaunch, but give it a different name? For example, Something else to try is adding the game through Steam, and then purposefully breaking the StartDir. So if you make it blank, or a folder that doesn't exist, or a completely random folder, the game should give you the error box saying it can't find the game files, the same way it does when added through STL.
This might be if an entry for the game's AppID already exists in
I noticed this part of your log file: This is a very strange error, and it's coming directly from Steam. Do you know if this is """common""" with Steam and/or your install? Maybe it's a red herring and nothing to worry about. It may just be something that happens if you close Steam i.e. with Ctrl+C or closing the terminal, or something to do with running Steam from the commandline. I couldn't discern anything else from your log, the launch command looks fine and I didn't spot anything else out of place. |
|
I tried rolling back to I also tried using Steam's file browser option, just in case there was something weird going on there, but no difference. Still trying to figure out how to get this to fail... Tried adding the game from the commandline with the older version (which sets StartDir correctly, the issue with StartDir not being set was limited to only the GUI portion), and it launched fine. Changing the StartDir from Steam broke the game as expected, and it worked with STL when StartDir is the executable dir. Tried adding the game from the GUI with a different name so the AppID would be different, and StartDir was not set and the game complained as expected. But both using the Steam file browser and manually entering the game path seemed to fix the game launching, which is not what's happening in this issue, but is what would normally be expected since the paths are correct in both of our cases. I also tested with no SteamGridDB integration what-so-ever (just in case this is somehow a SteamGridDB related problem, yeah, I'm really grasping here 😅) and no change. For some reason Steam doesn't appear to be reading the Start Dir for the game properly for you. Would you be able to attach your You could do this by:
This way I can inspect the paths of both and see what's different. I could even inspect them with I actually just did this with my own tests, and in my case aside from casing differences between how STL writes out the column names versus how Steam does it (and the AppIDs), byte-for-byte the files are the same, including the StartDir (checked using Comparing them with Python also revealed them to be the same: import vdf
shortcuts_stl_tkx_path = '/path/to/vdf1'
shortcuts_steam_tkx_path = '/path/to/vdf2'
# Load VDF files as dicts
shortcuts_stl_tkx_vdf = vdf.binary_load(open(shortcuts_stl_tkx_path, 'rb'))
shortcuts_steam_tkx_vdf = vdf.binary_load(open(shortcuts_steam_tkx_path, 'rb'))
# Extract StartDir from both dicts
shortcuts_stl_tkx_startdir = shortcuts_stl_tkx_vdf['shortcuts']['0']['StartDir']
shortcuts_steam_tkx_startdir = shortcuts_steam_tkx_vdf['shortcuts']['0']['StartDir']
# Identical results
print(shortcuts_stl_tkx_startdir)
print(shortcuts_steam_tkx_startdir)
print(shortcuts_stl_tkx_startdir == shortcuts_steam_tkx_startdir) # True |
|
So...I'm kind of mid-testing right now, but apparently the crash seems to be limited to using Steam Tinker Launch as a compatibility tool. I tested with the Steam-added version and Proton-GE as a compat tool, and it got all the way to the main menu. Also, it doesn't seem like the Steam GUI selects Steam Tinker Launch as a default--which makes sense, since it's not able to know that it's a Windows EXE, right?
How should I proceed with this new development? Do you still want both shortcuts.vdf files, or should I provide something different? 👀 |
Hmm, I am a little confused right now, but to your last question, yes. When you add a compatibility tool, either with SteamTinkerLaunch or just Steam itself, no compatibility tool will be selected. That means when you press the "Play" button, it's the equivalent of double-clicking whatever Steam sets as the "Target" i.e. the exe. Sometimes this will get a game to launch with Wine, sometimes nothing will happen, sometimes I've had it open a crash in Wine notepad with one program! My question after this is now, what happens if:
My guess is going to be that the Steam added one works, but SteamTinkerLaunch added one does not, but I am not sure why that would be the case. If both work with GE-Proton, then you can try using STL as the compatibility tool. If it's only when using STL as a compatibility tool that the game crashes, then that is very odd indeed...
Both VDFs, it wouldn't hurt to have them to look through just in case there's something noticeably wrong :-) |
Here you go!
Yeah, this seems to happen whenever I close Steam. Somehow also happened when I ran Tokyo eX+ (Steam-added) with STL. That's the first time that's happened 😂
It works. terminal_steam_log_tkx_steam_ge_proton.log
Also works...for some reason. terminal_steam_log_tkx_stl_ge_proton.log
Neither one works...🫤 terminal_steam_log_tkx_steam_steamtinkerlaunch_compat.log I mean, it could just be that I didn't wait long enough for the game to launch, but Proton-GE loads reasonably quickly 🤷 |
|
So if I'm understanding correctly, the game now works for you, even if added as a Non-Steam Game by STL, and the only time it isn't working now is if you use STL as the compatibility tool? 😮 |
|
Seems like it. I just don't know what to make of all this at this point 😮💨 Just to clarify: both added...versions of the game (really having trouble articulating this 🤣 ) aren't launching with STL and the StartDir set to the game directory. STL probably still loads if the StartDir is blank or "" or...anything else, probably. |
Oh wow, that's a pretty interesting distinction. What in the heck is up with this. I just tested in case I messed something up and it still works with Non-Steam Games, and I'm actually using STL right now to play modded Oblivion (Steam native version, never tested the GOG version), so I don't think I broke STL this time. A couple of "classic" fixes:
So right now the way you can get the game to work with STL is by having a blank StartDir, and launching the game executable through STL as a custom command. Outside of this, with the StartDir correctly set, it will work with GE-Proton as the compat tool, but not with SteamTInkerLaunch. Odd for sure, does STL work with any other games or do they also just hang? |
No change.
No change.
No change. I felt like such a machine reading this though; like, "I need to reboot myself" 🤣 terminal_steam_log_tkx_steamtinkerlaunch_compat_reboot.log
Yeah. I mean, I'm glad I have a workaround, but usually we stumble upon a definitive solution 😆 3678379145.conf.zip
I don't think I've really gotten any Non-Steam Games to work well, yet. Tokyo+ is the only one I've added to Steam at the moment, but I can try some others if you'd like 👍 |
|
Damn, well it was worth a try to see if any of those fixed it 😄
A nice easy one to try might be the Itch,io release of HoloCure, just when you have some time, to see if this issue is isolated to Tokyo+ or if it's a general problem you're having with Non-Steam Games not showing the SteamTinkerLaunch wait requester at all. |
Holocure works--even picked up my Steam save 👀 terminal_steam_log_holocure_steamtinkerlaunch_compat.log
Steam Tinker Launch is my default for Steam Play, by the way 😁 Where else would I get this many cool options to work with? 😉 |
|
Hmmm, so right now it seems this is specific to Tokyo+. STL won't open with it for some reason, but only when StartDir is set to the same directory as the game EXE. I had a look through the logs you attached and sorry if I missed it, but could you attach a log of the following attempt:
Kinda a crazy idea, but for giggles, what if you make a directory somthing along these lines to put HoloCure in? Since HoloCure is working, and since the game is working from my side, I'm trying to gauge whether the path to the Tokyo+ StartDir is what's causing the problem with SteamTinkerLaunch launching. I'm not seeing anything in the code at a quick glance but a log may give some pointers (maybe there'll be a big red block yelling that there's something wrong heh). This is a bit of a stretch but are there any symlinks in that path to Tokyo+? Most file managers will have a little arrow on the file icon which is an easy indicator that something is a symlink. Not sure if that throws STL off or not, I'll probably investigate that too. EDIT: I did a couple of quick tests with file paths, with Tokyo+ added from the Steam file browser (not STL addnonsteamgame) and made a ridiculously long one that seems to break SteamTinkerLaunch: I'll have to test on my boot drive with no spaces to see what breaks it exactly with this path. I had to remove and re-add the game from Steam at the original path ( Maybe the file path is the culprit here, I noticed it's also significantly shorter with itch.io. I wonder if it's length, spaces, maybe some wording in the name (maybe it doesn't like |
Hopefully I did everything correctly 🤞 steamtinkerlaunch.log
Yep, it broke. Gave the segfault crash as well 🤔 There's also this weird log where STL tried to run a space as an EXE? Looks like the...Steam ID#0 process, so I'm not sure if that's relevant or not:
None that I could see 🤷
I got a good laugh out of the "500GB" name 😆
Nice 👍 I don't think I mentioned it before, but I installed Tokyo+ with Lutris, rather than simply copying the files in like I did with HoloCure. Maybe it really is the paths? 🤔 EDIT: Before I forget, there was this weird line from the steamtinkerlaunch.log with the comment's first experiment:
Could be something, maybe? |
|
I did a bit more testing and comparing my logs with the ones you provided, and it seems that if the Non-Steam Game paths don't have quotes around them, STL breaks entirely, using the wrong name and not launching the game (it can't find the EXE name, compatdata, and sets a whole bunch of stuff wrong). That would explain why in my path, it uses "500GB" when I change the exe. So the moving EXE causing games to break is a red herring to the main issue though sadly, because for me, adding quotes around the paths fixes my Non-Steam Games. This quotes rule does not apply to the StartDir, only the EXE. STL doesn't seem to read the StartDir, I assume Steam doesn't pass it from inspecting some logs, and that Steam is responsible for setting that. Based on the logs and our earlier discussion, I'm almost certain you tried with and without quotes, but for HoloCure and also Tokyo+, ensure the EXE path has quotes around it and see if that fixes the games not launching with STL. From one of the logs you gave in your last comment, it does look like the EXE path should have quotes around it: Note the Your HoloCure log also shows a similar log, where the path does have quotes. However on that note:
The logs you attached seem to show HoloCure in the same path as before, when it worked, that is: Could you confirm what the path for HoloCure is when it breaks, and if it has quotes? If putting into a path that's closer to the Tokyo+ path is what broke it (i.e.
If putting quotes around the long path doesn't fix the issue, but using the original shorter path does fix the issue, then how about this: what if you just put the game in a path like Since your original HoloCure path didn't have any spaces ( Basically this will help us work out if it's the spaces in the Tokyo+ and HoloCure paths causing the crashes for you. But the paths I'm using for Tokyo+ have spaces and they work fine with STL so long as they're wrapped with quotes, so I'm not sure that that's exactly the problem. I do think the path will play into this somehow though 😄 So in summary, the things I'd like you to test are:
On the subject of the paths without quotes being read incorrectly: EXE paths missing quotes seems to be something the Steam Client does now, when you change the path it seems it removes the quotes. When STL reads in the start command from Steam, it reads it like this: Having to quote paths is a pretty standard thing from the commandline, if you've ever tried to run Fixing this one might be tricky, and I am tempted to document that paths should have quotes around them if they have spaces as a bit of a copout 😅 This is a very odd issue but we've already uncovered a couple of tangible issues from this thread already. The first was that STL was not writing out StartDir properly from the GUI, and I was able to fix that with #942. The other issue is that STL breaks if the game path sent from Steam has spaces but doesn't have quotes. And the strangest part is that in the end, all of these may be distractions and the core issue you're having could be unrelated. The problem is your Tokyo+ game is not launching for some reason on that specific path. HoloCure works until you move it into another path, and now we have to figure out what exactly about the change you made to the HoloCure path is causing the breakage. |
|
I feel like Steam is gaslighting me at this point. Testing it today has HoloCure failing to launch with any non-blank StartDir set: terminal_steam_log_holocure_steamtinkerlaunch_compat_not_tkx_v2.log But successfully launching with a blank StartDir: terminal_steam_log_holocure_steamtinkerlaunch_compat_blank_dir_path.log Tokyo+ also fails to launch with any non-blank dir, even ones that do not have spaces: terminal_steam_log_tkx_steamtinkerlaunch_compat_gog_folder.log With a blank StartDir, however: It launches, but it can't find the files (as before): terminal_steam_log_tkx_steamtinkerlaunch_compat_gog_folder_renamed_blank_start_dir.log To emphasize, HoloCure works fine with a blank StartDir (and only with a blank StartDir), while Tokyo+ partially works with a blank StartDir (and crashes with one set). Unless it's the game itself--or perhaps those segfaults that kept showing up throughout today's testing--it simply does not make sense to me 😮💨 |
|
@sonic2kk Do you think it's worth trying the Steam beta and seeing if that makes any difference? |
|
I didn't test rolling back but it might be worth checking. The Steam beta is usually quite stable in my experience but it's safe enough to roll back if something else is buggy or if you just don't want to stay on the beta, which is totally fair, I won't ask you to stay on it :-) I can't re-create any crash behaviour with the StartDir being blank/set causing crashes... The only way I can get some failing behaviour is to remove quotes from the path, which seems to be a separate issue from the problems you're facing, since having with/without quotes has no impact for you. So I guess the Steam Beta is a good idea to try just to see! And if it doesn't work and you don't want to stay on the beta, feel free to roll back :-) I've been running the Steam beta for many years now so I haven't tested STL against the stable client for a long time, only in the interim when there is no beta |
Thanks 👍 I'm used to working with the beta, though, so I don't mind sticking with this for a while 😁
Well, the beta didn't really change anything for me 😅 With our nested Tokyo Xanadu eX+ directories--since those are the ones that are most likely to fail--these are the results so far: HoloCure
Tokyo Xanadu eX+ - Uses "Tokyo Xanadu eX+" as the file dir; sorry about the filenames 🙏
I usually stay on the beta myself, unless something breaks 😁 A few more miscellaneous observations that happen with both the stable and beta clients:
Hope this info helps 🤣 🙃 |
|
I saved those logs (no worries about filenames, I give them esoteric names when I save them that probably only make sense to me 😉), I'm gonna take a look into them now, but first:
This is really weird. So when you have a StartDir present for your Non-Steam Game (for both HoloCure and Tokyo+), the "PLAY" button will go to "STOP" and then right back to "PLAY"? But the game process still starts up when using GE-Proton, but not SteamTinkerLaunch. The behaviour of the button going "PLAY" -> "STOP" -> "PLAY" again so quickly is similar to what happens when a game crashes, however in this case the game it's actually crashing -- GE-Proton still runs, but STL does not. I'll check the logs, but your point that the segfault happens only when using STL, with StartDir set, and when you observe the button reversion behaviour (there's got to be a better way for me to phrase this, but it isn't coming to me right now, hopefully you know what I mean 😄) It's very strange to me that STL fails when StartDir is set. It at least follows that when StartDir isn't set, the game can't find the game files, but it's very strange that setting the StartDir breaks the launch entirely. Something is surely going wrong here, I will look into it. The segfault seems like a good place for me to begin this time! Thanks for always being thorough with logs, it is always good to glance through. |
Thanks 🙏
I checked just now, and it goes "PLAY" -> "CANCEL" -> "PLAY", all very quickly. Sorry for the mixup 🙏
That's what I'm seeing, yeah.
I know what you mean (I'm having a hard time articulating it myself), but there's a couple of cases where it happens occasionally:
You're welcome! 💜 You're the last person I'd want to confuse with all these strange happenings 😆 |
|
Do you have a file in the Tokyo Xandaru eX+ folder called I noticed in your STL logs, the launch with the StartDir set has this line, but the launch without StartDir set does not have this line: If I put a text file When I remove that file, the game works again, and the log line above doesn't appear in my log file anymore. |
Here's the terminal output from ls and cat: [jeremiah@arcadia Tokyo Xanadu eX+]$ ls -lv
total 5087756
-rw-r--r-- 1 jeremiah jeremiah 877325813 Oct 14 23:55 Asset1.bra
-rw-r--r-- 1 jeremiah jeremiah 499000182 Oct 14 23:54 Asset2.bra
-rw-r--r-- 1 jeremiah jeremiah 1653278165 Oct 14 23:56 Asset3.bra
-rw-r--r-- 1 jeremiah jeremiah 785690772 Oct 14 23:54 Asset4.bra
-rw-r--r-- 1 jeremiah jeremiah 716768383 Oct 14 23:55 Audio.bra
-rw-r--r-- 1 jeremiah jeremiah 51867 Oct 17 10:32 EULA.txt
-rw-r--r-- 1 jeremiah jeremiah 4730880 Oct 14 23:55 Galaxy.dll
-rw-r--r-- 1 jeremiah jeremiah 555182718 Oct 14 23:55 Japanese.bra
-rw-r--r-- 1 jeremiah jeremiah 633 Oct 14 23:58 'Launch Tokyo Xanadu eX+.lnk'
-rw-r--r-- 1 jeremiah jeremiah 277 Oct 15 00:15 ReShade.ini
-rw-r--r-- 1 jeremiah jeremiah 188547 Oct 19 16:35 ReShade.log
-rw-r--r-- 1 jeremiah jeremiah 3222240 Oct 17 16:03 ReShade32.dll
-rw-r--r-- 1 jeremiah jeremiah 526 Oct 20 19:26 ReShade32.json
drwxr-xr-x 3 jeremiah jeremiah 4096 Oct 17 17:11 Screenshots
-rw-r--r-- 1 jeremiah jeremiah 99 Oct 20 19:26 SpecialK_enabled.txt
-rw-r--r-- 1 jeremiah jeremiah 69753379 Oct 14 23:55 System.bra
-rwxr-xr-x 1 jeremiah jeremiah 7225344 Oct 14 23:55 TokyoXanadu.exe
-rw-r--r-- 1 jeremiah jeremiah 1789 Oct 19 15:34 TokyoXanadu.ini
-rw-r--r-- 1 jeremiah jeremiah 1574072 Oct 17 17:25 'TokyoXanadu 2023-10-17 17-25-05.png'
-rw-r--r-- 1 jeremiah jeremiah 94799 Oct 17 18:26 'TokyoXanadu 2023-10-17 18-26-57.png'
-rw-r--r-- 1 jeremiah jeremiah 164305 Oct 17 18:27 'TokyoXanadu 2023-10-17 18-27-00.png'
-rw-r--r-- 1 jeremiah jeremiah 30146 Oct 17 18:27 'TokyoXanadu 2023-10-17 18-27-10.png'
-rw-r--r-- 1 jeremiah jeremiah 2711776 Oct 17 18:27 'TokyoXanadu 2023-10-17 18-27-24.png'
-rw-r--r-- 1 jeremiah jeremiah 1571100 Oct 17 18:27 'TokyoXanadu 2023-10-17 18-27-31.png'
-rw-r--r-- 1 jeremiah jeremiah 2712349 Oct 18 11:31 'TokyoXanadu 2023-10-18 11-31-39.png'
-rw-r--r-- 1 jeremiah jeremiah 1611367 Oct 18 11:31 'TokyoXanadu 2023-10-18 11-31-45.png'
-rw-r--r-- 1 jeremiah jeremiah 98798 Oct 18 11:39 'TokyoXanadu 2023-10-18 11-39-32.png'
-rw-r--r-- 1 jeremiah jeremiah 2712751 Oct 18 11:39 'TokyoXanadu 2023-10-18 11-39-47.png'
-rw-r--r-- 1 jeremiah jeremiah 1573620 Oct 18 11:39 'TokyoXanadu 2023-10-18 11-39-55.png'
-rw-r--r-- 1 jeremiah jeremiah 121589 Oct 17 10:21 TokyoXanadu_20231017_172150.dmp
-rw-r--r-- 1 jeremiah jeremiah 119695 Oct 17 10:22 TokyoXanadu_20231017_172247.dmp
-rw-r--r-- 1 jeremiah jeremiah 46921 Oct 17 17:07 TokyoXanadu_20231018_000746.dmp
-rw-r--r-- 1 jeremiah jeremiah 46997 Oct 17 18:17 TokyoXanadu_20231018_011734.dmp
-rw-r--r-- 1 jeremiah jeremiah 120347 Oct 18 11:05 TokyoXanadu_20231018_180515.dmp
-rw-r--r-- 1 jeremiah jeremiah 126535 Oct 18 11:19 TokyoXanadu_20231018_181907.dmp
-rw-r--r-- 1 jeremiah jeremiah 41969 Oct 18 11:35 TokyoXanadu_20231018_183518.dmp
-rw-r--r-- 1 jeremiah jeremiah 121333 Oct 19 10:56 TokyoXanadu_20231019_175622.dmp
-rw-r--r-- 1 jeremiah jeremiah 121845 Oct 19 10:57 TokyoXanadu_20231019_175711.dmp
-rw-r--r-- 1 jeremiah jeremiah 121333 Oct 19 10:58 TokyoXanadu_20231019_175816.dmp
-rw-r--r-- 1 jeremiah jeremiah 47863 Oct 19 11:15 TokyoXanadu_20231019_181540.dmp
-rw-r--r-- 1 jeremiah jeremiah 122547 Oct 19 15:17 TokyoXanadu_20231019_221707.dmp
-rw-r--r-- 1 jeremiah jeremiah 12 Oct 15 00:15 check-steam_appid.txt
-rw-r--r-- 1 jeremiah jeremiah 3681600 Oct 17 16:03 d3dcompiler_47.dll
-rw-r--r-- 1 jeremiah jeremiah 10544128 Oct 20 19:26 dxgi.dll
-rw-r--r-- 1 jeremiah jeremiah 7197 Oct 20 18:41 dxgi.ini
-rw-r--r-- 1 jeremiah jeremiah 69248 Aug 9 2017 gog.ico
-rw-r--r-- 1 jeremiah jeremiah 157 Oct 17 10:32 goggame-1565811574.hashdb
-rw-r--r-- 1 jeremiah jeremiah 179429 Mar 30 2018 goggame-1565811574.ico
-rw-r--r-- 1 jeremiah jeremiah 336 Oct 17 10:32 goggame-1565811574.info
-rw-r--r-- 1 jeremiah jeremiah 157 Oct 14 23:56 goggame-1908505665.hashdb
-rw-r--r-- 1 jeremiah jeremiah 179429 Mar 30 2018 goggame-1908505665.ico
-rw-r--r-- 1 jeremiah jeremiah 603 Oct 14 23:56 goggame-1908505665.info
drwxr-xr-x 3 jeremiah jeremiah 4096 Oct 20 19:27 logs
drwxr-xr-x 2 jeremiah jeremiah 4096 Oct 14 23:55 movie
drwxr-xr-x 2 jeremiah jeremiah 4096 Oct 14 23:56 movieJP
drwxr-xr-x 5 jeremiah jeremiah 4096 Oct 15 00:14 reshade-shaders
-rw-r--r-- 1 jeremiah jeremiah 11 Oct 15 00:15 steam_appid.txt
-rw-r--r-- 1 jeremiah jeremiah 62895 Aug 9 2017 support.ico
-rw-r--r-- 1 jeremiah jeremiah 1862360 Oct 14 23:58 unins000.dat
-rwxr-xr-x 1 jeremiah jeremiah 1334880 Oct 14 23:58 unins000.exe
-rw-r--r-- 1 jeremiah jeremiah 41 Oct 14 23:58 unins000.ini
-rw-r--r-- 1 jeremiah jeremiah 23077 Oct 14 23:58 unins000.msg
-rw-r--r-- 1 jeremiah jeremiah 1634786 Oct 17 10:32 unins001.dat
-rwxr-xr-x 1 jeremiah jeremiah 1334880 Oct 17 10:32 unins001.exe
-rw-r--r-- 1 jeremiah jeremiah 41 Oct 17 10:32 unins001.ini
-rw-r--r-- 1 jeremiah jeremiah 23077 Oct 17 10:32 unins001.msg
-rw-r--r-- 1 jeremiah jeremiah 298538 Mar 30 2018 webcache.zip
[jeremiah@arcadia Tokyo Xanadu eX+]$ cat steam_appid.txt
3302090703
[jeremiah@arcadia Tokyo Xanadu eX+]$ I'll try renaming steam_appid.txt 👍 |
|
It works 😮 Game loads up to the menu, even: Since I have the STL option enabled for creating a steam_appid.txt in the game folder, a 2nd run returns the game to its old, crashing behavior (as expected?): Just have to remember to take that setting off of my defaults, I guess 😅 |
|
Woohoo! I'm glad that fixes it!
I haven't quite figured out why it causes a crash yet, but my guess is that STL is trying to do some Steam game specific setup when it gets this AppID. One fix I have in mind for this would be to simply ignore reading this file entirely when we have a Non-Steam Game (there are a couple ways to potentially tell). I'll have to look and see how this file is actually used, but having this option cause crashes for Non-Steam Games is no good. This isn't accusatory, I'm just wondering, what is this option enabled for? Is it just a handy way of getting the Steam AppID for a game for your own information? If so, it's probably safe to just tell STL not to read this for Non-Steam Games during a game launch. I'm guessing this value doesn't crash regular Steam games? 😅 I have never used this option before, and totally forgot about it. And I didn't even catch that log line until just now when I brought it up. This explains why the blank paths work, because it doesn't have this AppID file to try and read from, so it never tries to incorrectly set this. As far as I know, for a regular Steam launch, Phew, thanks for all the testing and patience here. We got to the bottom of this in the end, fixed a couple of issues along the way, and found a couple more. The main one here I want to fix is the crash with the I'll leave this issue opened until I can fix this text file problem. But in the meantime, I hope you get to sit down and enjoy your game in the end 😄 |
|
From looking at the wiki, it seems the Unfortunately since this is a Steam file, it seems like Steam loads this so soon that STL doesn't have a chance to unset this and make Steam happy. Therefore we cannot account for cases in STL where this file may already exist. Instead, the most we can do is prevent that option to create this file from running if we have a Non-Steam Game. That means anyone who already has this file in their Non-Steam Game EXE dir will have to do some manual intervention. The most we can do is prevent any future cases of this happening, by not writing out this value for Non-Steam Games. The overall fixes for this issue in order to close it will be the following:
I'll probably get this resolved tomorrow, I found a way to reliably determine if we have a Non-Steam Game. Steam passes Once those three points are resolved, I think we can close this issue. If there is something we discussed that I forgot about which also needs resolved, please let me know, but I think everything is working for you now? We just need to fix the option that caused this issue for you in the first place :-) Assuming everything is working now, I'm really glad we got it resolved. For a moment there I thought this was going to be an obscure Steam bug, but hopefully it's all working for you now with STL. And by the way, I forgot to mention before, but it's pretty cool that you use STL as your default compat tool 😄 |
Me too! 😁
It's occasionally used for allowing games to be run DRM-free (https://www.pcgamingwiki.com/wiki/The_big_list_of_DRM-free_games_on_Steam#SEGA) or for...non-Steam games? I vaguely remember something about...Fallout: New Vegas needing it for a mod or an installer or whatever. Honestly, I wouldn't have imagined it would cause problems--if anything, I thought it would help compatibility--so I figured leaving it enabled wouldn't hurt anything 😞 The only thing I can think of right now that might use it is Special K, but even that's a moonshot. I'm...OK with disabling it, I think 😅 But thanks for your gentle approach to the question 💜
Hasn't happened yet to my knowledge, but...I'll have to try some without it now 👀
Haha, that's...kind of funny 😅 Didn't expect all our digging to point...there, but it's good that we found a better workaround than the one at the beginning 👍
You're welcome 😩 👍 Somehow, it feels like these issues are progressively getting more complex, and I'm not sure if that's because we're fixing the easier stuff, or if I just happen to point out tricky issues, or...something else, I guess 🤷 After I regroup, my next big set of issues (either part of #894 or separate issues; please let me know whichever you prefer) will be dealing with the handful of weird cases I've found while testing ReShade + Special K compatibility. Briefly:
Hopefully, that'll be it for a while. As mentioned above, please let me know which of these deserve their own issues 💜 🙏
You too! It'll be great to finally enjoy the full experience of a game that I bought in...2019? 🤣 If you decide to keep the game, I hope you enjoy it as well. Paying full price for a game just to diagnose a bug is absolutely an amazing move 😆
Sounds good 👍
Thanks again 🙏 💜
You know, I originally used it because I wanted to have OBS Game Capture, MangoHud, and Gamescope all on at the same time without...a crazy looking launch command. At first, the number of options was overwhelming 😅 , but over time, I've come to appreciate the flexibility and convenience it offers. You're doing a great job 👍 |
I view it more as a lucky coincidence that you did. I mean, this has gone unnoticed for like 2 years or so, right? But now it's been found and it can be fixed :-) Do let me know if any games break without this text field, because if so, I'll probably report it upstream to Steam for Linux. It may be a client bug in that case if Non-Steam Games can use it but Steam breaks if you set it for Non-Steam Games. But if Non-Steam Games are never gonna use it, then it's probably best to just avoid giving this to Steam. Though I suppose in the latter case the fact that it loads it at all for Non-Steam Games could be a bug...
I think a lot of people just don't report issues, and don't have the same kinds of use cases that you do. A lot of what I observed online in the past was that people used STL as simply an installer for MO2/Vortex, and don't really use any other part of it. The way you use STL is a lot more like how I use it. It's my front-end to avoid having a freaking crazy launch command, and without having to remember the order of gamescope+gamemode+MangoHud. But the options we use are different, and there are lots of constellations that may not have been accounted for before, so the way we use STL just brings these issues to light. That isn't to say you or I should use STL differently, I view it wholly as a good thing. I get a ton more satisfaction out of fixing issues like this than doing anything on the mod tools to be frank.
Seems like that game isn't on the PCGamingWiki article (several games aren't), so when we can't find the game and renderer for SpecialK, we default to
There should be an optiom to choose an alternative EXE to check the architecture on somewhere around the ReShade options, which is in place for situations like this where you need DLLs matching the architecture of an EXE that is not the main game. Selecting the actual game EXE should get STL to check the architecture of that EXE instead of the launcher, and use the correct architecture. 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. Actually, I think there was a change made a while ago so if a custom command is selected, we check the architecture of that EXE instead. But it's late and I'm on my phone so I can't hunt for the PR right now, but I recall making a change around this in the past I think... Still, selecting the EXE you want to check the architecture of explicitly couldn't hurt :-)
Fix should be same as above, pick the EXE that the bat launches to check the architecture against. I own this game on Steam I think so I could test this one out tomorrow (around the time I got into Strive I got it cheap I think).
Vulkan isn't supported by ReShade on Linux, and I think there's very limited SpecialK support... Not too sure to be honest! I tested OpenGL games with ReShade and they worked (DOOM 3 was the main one I remember) but I'm not too sure about SpecialK. Does it support OpenGL? I haven't tested DX12 games I don't think but I own a few I could test with as well. As for which of these deserve their own issues, we can revisit it in one separate new issue to start off with if the above advice didn't resolve it for you 🙂
Curiosity gets the better of me sometimes, both in terms of diagnosing bugs, and seeing all the unique games people use with STL has definitely influenced more than a few purchases outside of bug hunting :-)
It's for sure overwhelming, and the moment Yad gets support for tabs on Wayland you can bet I'm overhauling the UI. It's also really refreshing to hear those features come up, gamescope in particular is an area I've spent quite a bit of time on. If the SpecialK+ReShade stuff is still giving you headaches, feel free to put it all in a new issue whenever you have time. There's no major hurry so just report whenever you have some time and I'll gladly take a look to try and figure things out. Glad to be able to track down another good issue 👍 |
|
It's going to take me a bit to process all this, but for now I just want to say:
Also,
Glad to help 👍 |
|
Got an experimental PR up that should fix the There is also some logging to note when STL thinks it has a Non-Steam Game with this new code to check for Non-Steam Games. It may not be foolproof so if you run into a situation where There are a couple more things related to Non-Steam Games on my radar still:
I think I will leave this issue opened until these are fixed :-) |
|
@sonic2kk I think we/I might've broken something 😅 [jeremiah@arcadia ~]$ steamtinkerlaunch version
steamtinkerlaunch-v14.0.20231022-3
[jeremiah@arcadia ~]$ steamtinkerlaunch update grid installed
/usr/bin/steamtinkerlaunch: line 1635: getInstalledGameIDs: command not found
Could not find artwork on SteamGridDB to save with filename '_hero' -- Check the log for details
Could not find artwork on SteamGridDB to save with filename '_logo' -- Check the log for details
Could not find artwork on SteamGridDB to save with filename 'p' -- Check the log for details
Could not find artwork on SteamGridDB to save with filename 'SEARCHID' -- Check the log for details
[jeremiah@arcadia ~]$ |
|
Good catch 😨 |
|
Dammit, I think there's a shortcut to close as completed and my silly fingers pressed it by accident... |
That's totally fine 🙏 😆 |
|
Ah, it's That option actually had significantly little testing, so:
|
|
I'll give it a try 👍 |
|
Still busted, although not in the same way as the earlier comment 🤔 |
|
That was a scary log... okay, it looks like it's just passing all the IDs to the endpoint as one big string, instead of as individual ideas. Should be fixable though, it's getting further than I kinda thought it would, so if we can send the IDs properly we may be onto something. |
Sorry about that 😅 . I figured it'd be better than just...putting it in a big code block.
Got it! |
|
Phew, today has been a busy development day 😅 Pushed up a fix with 08a6bc4 - I'll be interested to see how that goes. Now it should read the installed IDs one at a time and send them to |
|
The command's looking pretty good so far 😁 Thanks for all your hard work! 💜 |
|
I resolved most of the points from my previous comment about the remaining tasks before we can close this issue. The outstanding pieces now I think are:
Once I fix the EXE path issue for Non-Steam Games, this can probably be closed :-) |
Sounds good to me! |
|
Fixed game EXE name in 471f777, this can be closed 🥳
|
|
Thanks! |
System Information
Issue Description
As always, I like to clear issues with you before making new ones, to avoid unnecessary bug reports. After all, I could just be missing something obvious 😅
While doing the final tests of #906, using Tokyo Xanadu eX+ as the test game, I noticed something strange. When the game's start directory is empty, the actual game seemingly can't find the necessary files, despite them being present in the directory:
I then tried a few more options:
Also, changing the working directory there does...nothing? No game, and the function doesn't even save the setting:
The only way I was able to make it work was by running the game as a custom command:
Running the game with a Steam compatibility tool (Proton-GE, Proton-TkG, regular Proton, etc.) instead of Steam Tinker Launch, doesn't help the game find the files, either 🤷
I'm pretty sure this is a bug of some sort, but, as mentioned, I'm looking for a second opinion 🙏
Also, sorry for the cluttered issue. It didn't come out as good-looking as I'd have liked 😅
Logs
3678379145.log
steam-15798518130096996352.log
3678379145.log
The text was updated successfully, but these errors were encountered: