search

sonic2kk / steamtinkerlaunch

Linux wrapper tool for use with the Steam client for custom launch options and 3rd party programs
GNU General Public License v3.0
2.04k stars 70 forks source link

Steamtinkerlaunch fails to start the game after launching itself #1078

Closed ngraham20 closed 3 months ago

ngraham20 commented 3 months ago

System Information

Issue Description

When I try to play games through steamtinkerlaunch, the menu typically disappears as soon as it shows up. I have gotten it to show up once, and I was able to mess around with settings; however, the moment I clicked "play", it quit out. I have tried this most recently on Celeste Native, with the properties steamtinkerlaunch %command%.

I saw that a similar issue was opened a couple weeks ago, and I'm fairly certain that this is not the flatpak version of Steam, and the issue template doesn't seem to indicate that I shouldn't be using v12.12 right now. I apologize if this is incorrect.

Logs

steamtinkerlaunch.log

madscientist16 commented 3 months ago

It's recommended to be using the latest git master, so try and see if using it fixes the issue.

sonic2kk commented 3 months ago

Like @madscientist16 said, checking latest master is a good idea. You should also attach a log for the latest master run (please keep your old log attached too in case I need to compare).

You should also try running from the command line once you install latest master, and see if you get a segfault when opening various menus (see #1070). Perhaps there is some issue with Yad on various systems?

Outside of that I'll test with Celeste when I am home, and check the log file as well.

I was using SteamTinkerLaunch with the native game The Talos Principle and didn't encounter issues, so I don't think this is a general issue.

You might already know this from the Readme but as an FYI, SteamTinkerLaunch can be used with Proton games using the compatibility tool, and with native games using just the launch option (meaning no compatibility tool is selected).

sonic2kk commented 3 months ago

It looks like your system is missing the Steam Linux Runtime.

Mon Mar 25 11:59:09 PM MDT 2024 ERROR - getGameDir - Could not find game directory for '1070560' - Maybe it is not installed
Mon Mar 25 11:59:09 PM MDT 2024 WARN - setSLRReap - Could not find Steam Linux Runtime with AppID '1070560' for native Linux game - This will need to be installed manually!
Mon Mar 25 11:59:09 PM MDT 2024 WARN - setSLRReap - Could not get path to Steam Linux Runtime - This will need to be installed manually!
Mon Mar 25 11:59:09 PM MDT 2024 WARN - setSLRReap - Ignoring USESLR option since valid Steam Linux Runtime could not be found

This being missing was causing a crash for native games, which was fixed in #999.

Updating from v12.12 should fix your issue, or manually installing the Steam Linux Runtime 1.0 should also fix it. You can do this from Steam by searching for it, and SteamTinkerLaunch on master has a button you can click that will open a prompt on Steam to install the Steam Linux Runtime (as it is not possible to silently initiate a download from Steam from the commandline afaik).

It is usually a good idea to run native games with the Steam Linux Runtime for compatibility anyway, SteamTinkerLaunch will try to use it by default for native and Proton games, and on SteamOS, Valve will run Verified/Playable games using the Steam Linux Runtime 1.0 by default. However, a missing SLR should not prevent games from running, this was a bug on the STL side that was fixed a while back.

If you are unfamiliar with the Steam Linux Runtime, I am no expert but the high level overview is that it is a container that games can run inside of. Native games will then look in the container for the libraries they need instead of your system; for example, Half-Life used to rely on a very old version of libpng, some native titles rely on an old version of SSL, and so on. Each point release of the Steam Linux Runtime is named after classes from Team Fortress 2 (Currently 1.0 Scout, 2.0 Soldier, 3.0 Sniper) and the containers are built using steampipe. You can check if a game is using the Steam Linux Runtime or not by checking if there is a new pressure-vessel/pv-bwrap/pressure-vessel-adverb process running once you start your game.

The Steam Linux Runtime avoids these by having a bunch of tested library versions as well as symlinks for library names that may have been specific to certain distributions (i.e. Ubuntu) which are not shared on others (i.e. Arch). Proton is also built against and runs inside of the Steam Linux Runtime, although it uses 2.0 and 3.0. Native games use 1.0, and there is ongoing work to allow native titles to run with 3.0. Although currently you have to manually edit the config.vdf to use 3.0 with native games, as the GUI to force a compatibility tool will only list Steam Linux Runtime 1.0.

If you want to play a native game without SteamTinkerLaunch and want to use the Steam Linux Runtime, you can force it from the Steam Per-Game Properties Menu -> Compatibility -> Force the use of a Steam Play Compatibility Tool -> Steam Linux Runtime 1.0 (Scout). Note that unlike with Proton, doing this will not force a download of the Windows release, so you are safe to do it :-)

sonic2kk commented 3 months ago

I am going to close this issue as I am fairly sure this is the cause of the problem. I tested Celeste with master (bad7466cc9fe6c07a5a2518ba2314b1559b16181) and it works fine.

It's also worth nothing that the issue template asked you to test master, as well as to check the changelog to see if this issue was fixed (following is copy and pasted from the issue template comment in text of your OP):

If at all possible, try testing the latest version of SteamTinkerLaunch from the master branch to see if the issue has already been fixed. You can also check the changelog on the wiki to see if its been fixed since the latest release: https://github.com/sonic2kk/steamtinkerlaunch/wiki/Changelog

It's always good to use the latest master; there is never a reason to not use master. Release happen infrequently (v12.12 is over a year old!) and are just development checkpoints; they are not supported, and if I had my way, I'd get rid of them in favour of just having people build from master.