Non-Steam Games cannot find files in game dir

[CartoonFan]

System Information

• SteamTinkerLaunch version: v14.0.20231019-1
• Distribution: Arch Linux
• Installation Method: AUR

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:

[jeremiah@arcadia Tokyo Xanadu eX+]$ pwd
/home/jeremiah/games/managed_games/gog/tokyo-xanadu-ex/drive_c/GOG Games/Tokyo Xanadu eX+
[jeremiah@arcadia Tokyo Xanadu eX+]$ ls -lv
total 5073892
-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     189241 Oct 17 17:25  ReShade.log
-rw-r--r-- 1 jeremiah jeremiah    3222240 Oct 17 16:03  ReShade32.dll
-rw-r--r-- 1 jeremiah jeremiah        526 Oct 17 18:06  ReShade32.json
drwxr-xr-x 3 jeremiah jeremiah       4096 Oct 17 17:11  Screenshots
-rw-r--r-- 1 jeremiah jeremiah         99 Oct 17 18:06  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       1755 Oct 17 17:13  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     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         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 17 18:06  dxgi.dll
-rw-r--r-- 1 jeremiah jeremiah       7197 Oct 17 18:06  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 17 18:06  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

I then tried a few more options:

• Giving the game dir to Steam kills the game process before Steam Tinker Launch even gets a chance to load:

• Launching the game through One time run produces a similar result to running the game through regular Wine:

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

[sonic2kk]

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:

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

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 chdir /path/to/game/exe-dir. So if you launched the Steam release of HoloCure (not the Itch.io release, as in you downloaded it from Steam), then Steam would actually run the command to start the game and then run a command like this: chdir /home/gaben/Games/steamapps/common/HoloCure

If you'd like to see this, start Steam from the terminal and you'll see the chdir command. When you launch a game with SteamTinkerLaunch (either as a launch option or a compatibility tool), the same thing happens. I assume Steam internally tracks the start directory for Steam games, although even when it may not make as much sense (such as when games have a launcher i.e. EA games), it still runs the command to the install folder. So if you had a game at /home/gaben/Games/steamapps/common/HatinTime, that would be the start directory, even if the EXE was at /home/gaben/Games/steamapps/common/HatinTime/Binaries/Win64/HatinTimeGame.exe

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 /home/gaben/FreeGames/Touhou Fumo Racing/TouhouFumoRacing.exe. This may not always be correct, but it's the Steam default behaviour, and is usually acceptable.

When you launch a Non-Steam game, it will also do the chdir like with Steam games, but it will use the StartDir to do this. So it would run chdir /home/gaben/FreeGames/Touhou Fumo Racing. If this is not set, chdir will error out saying it can't change into a null path, but the game will still start, it will just use the directory that the Steam process was started from as the working directory.

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 "", but it does do it properly when adding from the commandline. I figured out why this is and have a branch with the fix, and will open a PR after I reply to this issue :-)

---

So despite this background, the strange thing is the other parts of your issue.

Giving the game dir to Steam kills the game process before Steam Tinker Launch even gets a chance to load:

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 (Tokyo Xanadu eX+). I tried a few different thing to try and trip it up, too, including no quotes, a trailing slash, a mix of one missing quote and a trailing slash, and a path that doesn't exist. In all cases, the game would launch with and without SteamTinkerLaunch. When the path didn't exist, chdir would give chdir "/path/to/blah" failed, errno 2 which is expected, but the game would still start.

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 chdir call. This can be tricky, as there will be a lot of output spam, but you could try closing the game quick or logging the process output to a file (steam 2>&1 | tee terminal-steam-log.txt should do the trick) and then do a search for the chdir command.

Launching the game through One time run produces a similar result to running the game through regular Wine. Also, changing the working directory there does...nothing? No game, and the function doesn't even save the setting.

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:

• With StartDir set to the same folder as the EXE, launching with regular Proton works as expected
• With StartDir set to the same folder as the EXE, launching with SteamTinkerLaunch works as expected
• With StartDir not set, launching with regular Proton throws the error that the working directory must be same as the EXE directory
• With StartDir not set, launching with SteamTinkerLaunch throws the error that the working directory must be same as the EXE directory
• With StartDir set to a folder that is not the same as the EXE, the result above is the same for both regular Steam and SteamTinkerLaunch (it throws the error)
• With StartDir not set, launching with SteamTinkerLaunch and using the One-Time Run menu, selecting the option to use the EXE folder as the working folder, allows the EXE to work as expected
• With StartDir not set, launching with SteamTinkerLaunch and using the One-Time Run menu, not selecting that option will cause the EXE to throw the error

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.

The only way I was able to make it work was by running the game as a custom command

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:

• Launching as a regular game fails, with the expected error about having the wrong working directory
• Launching as a custom command works, and the installer launches, so it's being launched from the correct working directory.

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).

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

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:

• Starting this game with SteamTinkerLaunch normally, with SteamTinkerLaunch One-Time Run (including setting the One-Time Run exe dir option) or with a regular Proton version, will result in the game complaining that it can't find its game files.
• You can't enter the game's StartDir in Steam, as this results in the game process closing before anything can start.
• The only way you can get the game to launch is to start it as a custom command, which I confirmed does actually seem to start the game in the same folder as the EXE, which means it makes sense why the game can find the files, but it doesn't make sense why it can't find it any other time.

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!

[sonic2kk]

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! 😄

[CartoonFan]

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:

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 😆

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

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 chdir /path/to/game/exe-dir. So if you launched the Steam release of HoloCure (not the Itch.io release, as in you downloaded it from Steam), then Steam would actually run the command to start the game and then run a command like this: chdir /home/gaben/Games/steamapps/common/HoloCure

If you'd like to see this, start Steam from the terminal and you'll see the chdir command. When you launch a game with SteamTinkerLaunch (either as a launch option or a compatibility tool), the same thing happens. I assume Steam internally tracks the start directory for Steam games, although even when it may not make as much sense (such as when games have a launcher i.e. EA games), it still runs the command to the install folder. So if you had a game at /home/gaben/Games/steamapps/common/HatinTime, that would be the start directory, even if the EXE was at /home/gaben/Games/steamapps/common/HatinTime/Binaries/Win64/HatinTimeGame.exe

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 /home/gaben/FreeGames/Touhou Fumo Racing/TouhouFumoRacing.exe. This may not always be correct, but it's the Steam default behaviour, and is usually acceptable.

I did not know all this 👀

When you launch a Non-Steam game, it will also do the chdir like with Steam games, but it will use the StartDir to do this. So it would run chdir /home/gaben/FreeGames/Touhou Fumo Racing. If this is not set, chdir will error out saying it can't change into a null path, but the game will still start, it will just use the directory that the Steam process was started from as the working directory.

This came up a few times in the Steam log.

chdir "(null)" failed, errno 14

I guess that's what you meant? 🤔

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 😄)

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 👍

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 "", but it does do it properly when adding from the commandline. I figured out why this is and have a branch with the fix, and will open a PR after I reply to this issue :-)

So despite this background, the strange thing is the other parts of your issue.

Giving the game dir to Steam kills the game process before Steam Tinker Launch even gets a chance to load:

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 (Tokyo Xanadu eX+). I tried a few different thing to try and trip it up, too, including no quotes, a trailing slash, a mix of one missing quote and a trailing slash, and a path that doesn't exist. In all cases, the game would launch with and without SteamTinkerLaunch. When the path didn't exist, chdir would give chdir "/path/to/blah" failed, errno 2 which is expected, but the game would still start.

Besides removing the start dir, the two directories I tried were:

• "/home/jeremiah/games/managed_games/gog/tokyo-xanadu-ex/drive_c/GOG Games/Tokyo Xanadu eX+" (game dir)
• "/home/jeremiah/games/managed_games/gog/tokyo-xanadu-ex/drive_c/GOG Games" (one dir up)

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.

Steam's file browser has been really unusable for me lately; it usually crashes right after selecting a file or folder.

It would be interesting if you launched Steam from the commandline and investigated the output of its chdir call. This can be tricky, as there will be a lot of output spam, but you could try closing the game quick or logging the process output to a file (steam 2>&1 | tee terminal-steam-log.txt should do the trick) and then do a search for the chdir command.

Here you go!

terminal_steam_log.log

chdir "(null)" failed, errno 14

shows up three times.

Launching the game through One time run produces a similar result to running the game through regular Wine. Also, changing the working directory there does...nothing? No game, and the function doesn't even save the setting.

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:

* With StartDir set to the same folder as the EXE, launching with regular Proton works as expected

* With StartDir set to the same folder as the EXE, launching with SteamTinkerLaunch works as expected

* With StartDir not set, launching with regular Proton throws the error that the working directory must be same as the EXE directory

* With StartDir not set, launching with SteamTinkerLaunch throws the error that the working directory must be same as the EXE directory

* With StartDir set to a folder that is not the same as the EXE, the result above is the same for both regular Steam and SteamTinkerLaunch (it throws the error)

* With StartDir not set, launching with SteamTinkerLaunch and using the One-Time Run menu, selecting the option to use the EXE folder as the working folder, allows the EXE to work as expected

* With StartDir not set, launching with SteamTinkerLaunch and using the One-Time Run menu, not selecting that option will cause the EXE to throw the error

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:

terminal_wine_log.log

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.

The only way I was able to make it work was by running the game as a custom command

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:

* Launching as a regular game fails, with the expected error about having the wrong working directory

* Launching as a custom command works, and the installer launches, so it's being launched from the correct working directory.

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).

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

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.

The only change I'd like to make here is that the One-Time Run error message is different from the others.

• One-Time Run and wine-tkg-staging

• Everything else

This is certainly a strange one. The main problems here from what I can see are:

* Starting this game with SteamTinkerLaunch normally, with SteamTinkerLaunch One-Time Run (including setting the One-Time Run exe dir option) or with a regular Proton version, will result in the game complaining that it can't find its game files.

* You can't enter the game's StartDir in Steam, as this results in the game process closing before anything can start.

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.

* The only way you can get the game to launch is to start it as a custom command, which I confirmed does actually seem to start the game in the same folder as the EXE, which means it makes sense why the game can find the files, but it doesn't make sense why it can't find it any other time.

Aside from that hard-to-reproduce thing above, yeah 🫤

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!

Thanks! 💜 🙏

Logs

terminal_steam_log.log
terminal_wine_log.log

[sonic2kk]

I haven't seen any of these errors

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 :-)

[chdir message] shows up three times.

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.

The only change I'd like to make here is that the One-Time Run error message is different from the others.

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!

[CartoonFan]

[chdir message] shows up three times.

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?

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
terminal_steam_log_one_above_game_dir.log - no chdir present

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 :-)

Surprisingly, no! I guess I haven't switched over since my big OS re-install adventure 😄

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.

I'm also using Big Picture Mode 👍

The only change I'd like to make here is that the One-Time Run error message is different from the others.

And so it gets even stranger :-)

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 👍

[sonic2kk]

No to both? Did I do something wrong? The results are still the same as before

Hmm, I'm seeing that now too, however yesterday and today I was seeing in my own logs the chdir. Now it seems to only show up if the StartDir is invalid, and it only shows up when the path given to the command is invalid. Very strange, I know this used to come back as well because I used it to try debug an issue with Origin games. I have no idea what changed 🤔

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 👍

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.

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 Changed pwd into the custom directory log that I never noticed before, a bit of a lead), so I was kinda out of options and ended up buying this game on GOG. And... it works on my end.

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 shortcuts.vdf. If you want to back up your shortcuts.vdf (you can quickly find it with steamtinkerlaunch ogf and then go one directory up) and then re-add your Non-Steam Game (either manually or with STL). I'll also do some tests around this to see if maybe some corruption is happening, though I doubt it.

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):

• When launching the game with GE-Proton8-16 and Proton Experimental, with the StartDir set to the game folder, it works fine.
• When launching the game with SteamTinkerLaunch normally (no custom command or one-time run), it works fine.
• When launching the game with SteamTinkerLaunch as a custom command, it works fine.

Now onto when it doesn't work:

• When launching the game with GE-Proton8-16 or Proton Experimental with StartDir set incorrectly (blank/invalid path), it will display the prFileSystem error meaning it can't find the game files
• When launching the game with SteamTinkerLaunch and StartDir is set incorrectly (blank/invalid path), it will display the prFileSystem error meaning it can't find the game files
• When launching the game with SteamTinkerLaunch One-Time Run, it shows the error message you described: "Tokyo Xanadu eX+ has stopped working. Crash dump has been generated." I believe this matches your experience.
  • Even when enabling the EXE working dir option or even manually selecting the EXE dir as the working dir, the game still shows this error message 🤔
• When manually running the same command that One-Time Run uses, I get the same error as One-Time Run, which is the crash dump error
  • Here's the command, tweaked so you should be able to paste it directly into terminal based on the paths from this issue but double-check the paths (it'll use GE-Proton8-20): cd "/home/jeremiah/games/managed_games/gog/tokyo-xanadu-ex/drive_c/GOG Games/Tokyo Xanadu eX+" && STEAM_COMPAT_CLIENT_INSTALL_PATH="/home/jeremiah/.local/share/Steam/" STEAM_COMPAT_DATA_PATH="/home/jeremiah/.local/share/Steam/steamapps/compatdata/3678379145" "/home/jeremiah/.local/share/Steam/compatibilitytools.d/GE-Proton8-20/proton" run "/home/jeremiah/games/managed_games/gog/tokyo-xanadu-ex/drive_c/GOG Games/Tokyo Xanadu eX+/TokyoXanadu.exe" ""

Something interesting I learned in my travels is that chdir errno 2 is for a path that doesn't exist, but errno 14 is for when the path is null, or blank in this case. In the logs you provided much earlier on that did have chdir, it was errno 14, which means even though the path is set in Steam, Steam isn't passing it to chdir.

---

So there are a few things here now:

• The game works for me without any extra tweaks with both GE-Proton and Proton Experimental, but not for you.
• The game works for me without any extra tweaks with SteamTinkerLaunch, but not for you .
• One-Time Run fails for both of us, with the same error, regardless of whether the working directory is set properly or not
  • One-Time Run and running the same command One-Time Run generates manually, both result in the crash dump error. However, custom command does not.
• Custom command works for both of us, and actually does change the working directory. I'll investigate that if custom command doesn't do this, will it still work. It's strange that this would work for custom command but not for One-Time Run, however I think One-Time Run might be failing before it reaches the point of being able to say it can't find certain files
  • To make sure we're both on the same page, One-Time Run hasn't shown the prFileSystem error message, right? That's the error message which indicates that it can't read the game files, which means the working directory is wrong. But if OTR isn't showing this then I suspect the failure is happening sooner.

And for confirmation as well:

• do you get any errors if you add the game to Steam yourself manually, using the "Add Non-Steam Game" option?
  
• do you get any errors if you try this from outside of Big Picture?

---

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.

[CartoonFan]

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 Changed pwd into the custom directory log that I never noticed before, a bit of a lead), so I was kinda out of options and ended up buying this game on GOG. And... it works on my end.

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 👍

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 shortcuts.vdf. If you want to back up your shortcuts.vdf (you can quickly find it with steamtinkerlaunch ogf and then go one directory up) and then re-add your Non-Steam Game (either manually or with STL). I'll also do some tests around this to see if maybe some corruption is happening, though I doubt it.

Sure! Everything looks like it's as it should be 😄

• When manually running the same command that One-Time Run uses, I get the same error as One-Time Run, which is the crash dump error

  • Here's the command, tweaked so you should be able to paste it directly into terminal based on the paths from this issue but double-check the paths (it'll use GE-Proton8-20): cd "/home/jeremiah/games/managed_games/gog/tokyo-xanadu-ex/drive_c/GOG Games/Tokyo Xanadu eX+" && STEAM_COMPAT_CLIENT_INSTALL_PATH="/home/jeremiah/.local/share/Steam/" STEAM_COMPAT_DATA_PATH="/home/jeremiah/.local/share/Steam/steamapps/compatdata/3678379145" "/home/jeremiah/.local/share/Steam/compatibilitytools.d/GE-Proton8-20/proton" run "/home/jeremiah/games/managed_games/gog/tokyo-xanadu-ex/drive_c/GOG Games/Tokyo Xanadu eX+/TokyoXanadu.exe" ""

Got the same error as before 👍

• To make sure we're both on the same page, One-Time Run hasn't shown the prFileSystem error message, right? That's the error message which indicates that it can't read the game files, which means the working directory is wrong. But if OTR isn't showing this then I suspect the failure is happening sooner.

That's correct! I've only gotten the "Tokyo Xanadu eX+ has stopped working. Crash dump has been generated." error thus far.

And for confirmation as well:

• do you get any errors if you add the game to Steam yourself manually, using the "Add Non-Steam Game" option?
  

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

• do you get any errors if you try this from outside of Big Picture?

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 🙏

[sonic2kk]

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, Tokyo Xanadu eX+ (GOG) or something. The reason I say this is in case somehow it's to do with the AppID (don't see how it would be, just grasping at straws a little). The name and path of the Non-Steam Game are used by SteamTinkerLaunch to generate the AppID, but Steam generates a seemingly random AppID each time. Using a different name if you add the game through STL would mean a different ID should be generated, and there should be no potential interference.

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.

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? 🤔

This might be if an entry for the game's AppID already exists in config.vdf. Unless STL is your default tool for all Steam games, which would be very flattering 😄 It would be strange indeed though.

terminal_steam_log_stl_ansg.log

I noticed this part of your log file:

/home/jeremiah/.local/share/Steam/steam.sh: line 798: 1769244 Segmentation fault      (core dumped) "$STEAMROOT/$STEAMEXEPATH" "$@"
crash_20231019110506_34.dmp[1772892]: Finished uploading minidump (out-of-process): success = yes
crash_20231019110506_34.dmp[1772892]: response: CrashID=bp-58a2bb07-5c48-46b1-b793-9dd562231019
crash_20231019110506_34.dmp[1772892]: file ''/tmp/dumps/crash_20231019110506_34.dmp'', upload yes: ''CrashID=bp-58a2bb07-5c48-46b1-b793-9dd562231019''

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.

[sonic2kk]

I tried rolling back to 20231019-1 (commit b0ef25c), before #942 was merged, and it didn't set the Start Dir as expected so the game gave the error about not being able to find game files. However I manually entered the correct path and it worked... I'll keep tinkering!

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 shortcuts.vdf file? You can zip it if you want. I'll try inspect it with a Python script.

You could do this by:

1. Renaming your existing shortcuts.vdf so it gets backed up
2. adding Tokyo Xanadu using STL, launch Steam, and confirm that it doesn't launch properly.
3. Modify the StartDir so that it's the EXE dir, i.e. /home/blah/blah/GOG Games/Tokyo Xanadu eX+ (either with or without quotes, whichever Steam uses, iirc when adding via Steam it will use quotes around the start path (but not when using the file browser for some reason))
4. Then close Steam, rename that file to something like shortcuts_stl_tkx.vdf
5. Re-open Steam, add Tokyo Xanadu using Steam, and confirm that it does launch properly.
6. Close Steam, rename that file something like shortcuts_steam_tkx.vdf
7. Zip them and attach them

This way I can inspect the paths of both and see what's different. I could even inspect them with xxd and see if there's something particularly strange with them. That's a lot to ask so there's no hurry, hopefully the ask makes sense too. Basically then we can inspect to see what the differences in the files are between the two shortcuts, and really they should be more or less identical (Steam may add more fields, but that's about it -- paths should be the same, and I suspect they won't quite match).

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 diff and xxd -ps shortcut_filename.vdf).

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

[CartoonFan]

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? 👀

[sonic2kk]

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?

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:

• You add the game via Steam and launch with GE-Proton as the compat tool (your preferred version)?
• You add the game via SteamTinkerLaunch and use the same GE-Proton as a compatibility tool?

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...

How should I proceed with this new development? Do you still want both shortcuts.vdf files, or should I provide something different?

Both VDFs, it wouldn't hurt to have them to look through just in case there's something noticeably wrong :-)

[CartoonFan]

Both VDFs, it wouldn't hurt to have them to look through just in case there's something noticeably wrong :-)

Here you go!
shortcuts_steam_tkx.vdf.zip

shortcuts_stl_tkx.vdf.zip

I noticed this part of your log file:

/home/jeremiah/.local/share/Steam/steam.sh: line 798: 1769244 Segmentation fault (core dumped) "$STEAMROOT/$STEAMEXEPATH" "$@"
crash_20231019110506_34.dmp[1772892]: Finished uploading minidump (out-of-process): success = yes
crash_20231019110506_34.dmp[1772892]: response: CrashID=bp-58a2bb07-5c48-46b1-b793-9dd562231019
crash_20231019110506_34.dmp[1772892]: file ''/tmp/dumps/crash_20231019110506_34.dmp'', upload yes: ''CrashID=bp-58a2bb07-5c48-46b1-b793-9dd562231019''

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.

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 😂

My question after this is now, what happens if:

• You add the game via Steam and launch with GE-Proton as the compat tool (your preferred version)?

It works.

terminal_steam_log_tkx_steam_ge_proton.log

• You add the game via SteamTinkerLaunch and use the same GE-Proton as a compatibility tool?

Also works...for some reason.

terminal_steam_log_tkx_stl_ge_proton.log

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...

Neither one works...🫤

terminal_steam_log_tkx_steam_steamtinkerlaunch_compat.log
terminal_steam_log_tkx_stl_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 🤷