CS2 crashes saying is not launched with Steam for Linux

ReeSilva commented 2 months ago

System Information

SteamTinkerLaunch version: v12.12
Distribution: Garuda Linux (Arch Linux)
Installation Method: Package Manager

Issue Description

Hey guys. So, I tried to search as much as I could because I thought I was just doing something stupid. But, I found nothing (which makes me more suspicious of being stupid hehe), so, I came here for ask for help haha. Basically, when I try to run CS2 using launch options (since it is a native game), it crashes. And crashes saying that CS2 was not launched using Steam for Linux runtime. I even tried a clean installation for both Steam and Steamtinkerlaunch. I'm attaching the logs and the screenshot that shows that CS2 is running through Sniper (Steam for Linux runtime). As I said, I'm using a fresh install, so default settings for STL.

From the things I read in STL docs, I think that this is because CS2 command is coming with --verb=waitforexitandrun. You guys can see in the logs as well.

Logs

steamtinkerlaunch.log 730.log 730.log

ReeSilva commented 2 months ago

I'll close because I notice the version from my package manager is really outdated compared to master. I'll test with master and reopen if needed.

ReeSilva commented 2 months ago

steamtinkerlaunch.log 730.log 730.log

Ok, reopening with logs from latest version in master.

sonic2kk commented 2 months ago

Thanks for realizing and testing from master, I appreciate it! I also appreciate the investigation work you did here, you put me on the right track by mentioning the SLR verb.

The issue might be that CS2 is using Steam Linux Runtime 3.0 Sniper, which this is the first time I have seen a Valve game selected to use it.

The final outgoing start command is missing the Steam Linux Runtime. I can't exactly tell from the logs, but this might be because Steam Linux Runtime 1.0 is not installed, so STL just foregoes it. See this snippet from the logs:

qui 18 abr 2024 19:56:43 CEST INFO - startGame - Full start command is '/home/reesilva/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=730 -- /home/reesilva/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- /home/reesilva/.local/share/Steam/steamapps/common/Counter-Strike Global Offensive/game/cs2.sh -steam'
qui 18 abr 2024 19:56:43 CEST WAIT - getGameWindowName - Waiting for the pfx '/home/reesilva/.local/share/Steam/steamapps/compatdata/730/pfx' to be full created
qui 18 abr 2024 19:56:43 CEST INFO - startGame - ## ORIGINAL INCOMING LAUNCH COMMAND: '/home/reesilva/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=730 -- /home/reesilva/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- /home/reesilva/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/_v2-entry-point --verb=waitforexitandrun -- /home/reesilva/.local/share/Steam/steamapps/common/Counter-Strike Global Offensive/game/cs2.sh -steam'
qui 18 abr 2024 19:56:43 CEST INFO - startGame - ## STL LAUNCH COMMAND: '/home/reesilva/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=730 -- /home/reesilva/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- /home/reesilva/.local/share/Steam/steamapps/common/Counter-Strike Global Offensive/game/cs2.sh -steam'
qui 18 abr 2024 19:56:44 CEST INFO - startGame - ## GAMESTART HERE ###

Can you check if Steam Linux Runtime 1.0 is installed? You can install this either from Steam or with the button on the Main Menu.

One other aside here, just as a warning: Using any tool like SteamTinkerLaunch is risky with online multiplayer games, as if detected it may lead to a ban. I have not heard of any such cases, but this is just a heads up out of courtesy just in case :-)

If this fixes it, great! But this highlights some changes needed for STL here. If the above doesn't fix it, or if CS2 is hardcoded to look for SLR 3.0, then the below may be less relevant.

So the overall solution here is likely going to be to guess when games are selected to use a Steam Linux Runtime and to try and nab this from the incoming start command. This is very uncommon on the Linux Desktop, even moreso uncommon for SLR 3.0.

I think we used to have code for this, but it was removed because it no longer got passed in the start command. I guess now if you or Valve select SLR 1.0 or 3.0 (2.0 is only for Proton) then it'll come in the launch command, but STL loses this. We need a way to restore the check of whether this comes from Steam.

CS2 may not work with SLR 1.0, it was likely selected with 3.0 for a reason, but installing 1.0 may at least fix the warning that a Steam Linux Runtime was not used.

I own CS2 so I will test when I have some more free time. I'll also need to consider what the solution should be. In the scenario where SLR 1.0 or 3.0 are forced as compatibility tools, STL should probably use whatever comes from the start command by default. But for games not using this when launched, we should probably give some option to select whether to use 1.0 or 3.0. That would cover the following scenarios, once implemented:

Game is not using any SLR compatibility tool, and has no SLR in its start command, so STL wraps it as normal
- STL will allow you to select SLR 1.0 or 3.0, defaulting to 1.0 - Each SLR has an AppID so we should be able to find 3.0 the same way we do with 1.0, and just pass a different AppID (although the start command may have different syntax, I'll need to check)
- If STL cannot find the selected SLR it will fall back to not using any and log a warning
Game is using SLR 1.0 or 3.0 as a compatibility tool, so the SLR comes in the launch options. In this case STL should, by default, use the one in the start command.
- I am unsure of the best way to handle cases where a user may be unable to change the SLR in use, but maybe we shouldn't allow changing the SLR if it is selected by Valve for a game?
- We could still allow them to disable the SLR I suppose if they really want, but I don't see a reason to let them change to a different version if one is selected by them or by Valve for a game, as this would more than likely break compatibility.

sonic2kk commented 2 months ago

Sorry, this is my bad, I just checked your 730.log (the AppID for CS2) and yes, it seems CS2 requires Sniper. See:

FATAL: It appears CS2 was not launched within the Steam for Linux sniper runtime environment. FATAL: Please consult documentation to ensure correct configuration, aborting.

it specifically requests Sniper.

sonic2kk commented 2 months ago

Got a fix locally, I will push a branch with an experimental fix. I haven't tested if this causes any regressions, but it allows CS2 to launch if the Steam Linux Runtime is enabled by default.

A long time ago, a change was made to disable all of the Steam Linux Runtime stuff, was it was broken due to a change in how Steam handled it (24de050). Previously, game launches would always pass the Steam Linux Runtime, but then it was changed to where Proton would build it.

The change I have locally disables a USESLR=0 default check on game startup, which basically tells STL to always ignore any incoming SLR from the commandline options (because it was thought to never happen). Disabling this, and making another minor change, allows STL to once again pick up the SLR from the incoming command launch from a compatibility tool. The logic to pick out the part of the Steam launch command that looks for the Steam Linux Runtime was still present, but seemingly disabled.

What this change does overall then, is looks at the start command from Steam, and if it contains an SLR start command, it picks that off and then appends that to the STL start command. Then, if the SLR is not in the start command (which 90% of the time, it isn't), we will append it ourselves, either based on what the Proton version requests or for native games, it defaults to 1.0.

I hope that makes sense :sweat_smile:

sonic2kk commented 2 months ago

The branch is up at https://github.com/sonic2kk/steamtinkerlaunch/tree/reenable-get-slr-from-compattool-launch-cmd -- Feel fre to test :smile:

If you installed by cloning STL from master, you can enter your clone, run git checkout reenable-get-slr-from-compattool-launch-cmd and then install again as normal. You can tell you're using the right version as the version string will be v14.0.20240419-1 (reenable-get-slr-from-compattool-launch-cmd).

I will do some more regression testing when I have time, but in my tests this at least fixes the issue with CS2 :-)

sonic2kk commented 2 months ago

Yes, but you can use compatibility tools with native games, such as Steam Linux Runtime 1.0 (Scout) and Steam Linux Runtime 3.0 (Sniper). Even though it's native, it gets compatibility tools from the launch command if these tools are used. In the case of CS2, the launch command looks like this:

/home/emma/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=730 -- /home/emma/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- /run/media/emma/500GB SSD/Games/steamapps/common/SteamLinuxRuntime_sniper/_v2-entry-point --verb=waitforexitandrun -- /run/media/emma/2B/Games/steamapps/common/Counter-Strike Global Offensive/game/cs2.sh -steam

Note specifically -- /run/media/emma/500GB SSD/Games/steamapps/common/SteamLinuxRuntime_sniper/_v2-entry-point --verb=waitforexitandrun --, which is the Sniper SLR which Steam wraps the start command in. STL was ignoring this entirely based on some code changes.

The PR fixes launching native games that get an SLR from their compatibility tool, which is a rare case and in those rare cases is almost always native games.

Valve Testing will often enforce the Steam Linux Runtime 1.0 on SteamOS only, to ensure game compatibility. So even if a game is native it will still be forced to use SLR 1.0 on SteamOS. This seems to now apply to some titles on Linux Desktop, where CS2 is forced to use the SLR 3.0 compatibility tool.

Outside of the Steam Linux Runtime, other compatibility tools you can use with native games that still use the Linux version are Steam-Play-None. Using a compatibility tool does not always mean the Windows version of a game has to be used; you specify this in the compatibilitytool.vdf file for a compat tool. However, a compat tool must either go Windows -> Linux, or Linux -> Linux, you can't do both with a single tool (which is why STL uses a compat tool for Proton, and a launch option for native).

sonic2kk commented 2 months ago

If this resolves the issue, I will open another Feature Request issue around choosing between Steam Linux Runtime 1.0 and Steam Linux Runtime 3.0. This will probably be a dropdown box on the Game Menu with the other SLR options. This option would have no effect if the SLR is coming from the start command, as the start command SLR should always be prioritised.

sonic2kk commented 2 months ago

~~In testing for regressions, I found that I could not get any Proton game to launch. Then, I testing master and still could not get any Proton game to launch.~~

They launch fine without STL but won't work with it, which is quite concerning... Even reverting back to a previously known consistently working commit (109c6f3e86db7fe324dc665e69788b07890bb46f was tested and worked, but bad7466cc9fe6c07a5a2518ba2314b1559b16181 was most extensively tested by me in gaming) now no longer works. This suggests either a system-specific issue, or Steam Client behaviour change.

~~I even rolled all the way back to v12.12, same issue.~~

The issue was a change I made in compatibilitytool.vdf to test out Manifest v2. This was my bad, STL still works as expected on master.

sonic2kk commented 2 months ago

Tested and the following scenarios work:

CS2 works out of the box, with Valve Testing's enforce SLR 3.0 (verified in log that the new code path is followed)
CS2 crashes as expected with Steam Linux Runtime disabled from Steam (this verifies the SLR is disabled as expected), and works again if the SLR is enabled (verified in code that SLR is seen as disabled)
- Start command was STL LAUNCH COMMAND: '/home/emma/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=730 -- /run/media/emma/2B/Games/steamapps/common/Counter-Strike Global Offensive/game/cs2.sh -steam'
Proton games work as expected and still follow the code path to pull the SLR from the compat tool toolmanifest.vdf (The so-called "Pressure Vessel Funtime 2nd Edition Ver. 2.31" code path is used)
- Tested PowerWash Simulator and Sonic Adventure 2
Proton games are hit-and-miss with the SLR disabled, sometimes crashing on launch, as expected, so no change in behaviour
Native games with NO COMPATIBILITY TOOL ENFORCED (none from Valve and none by the user) will still use the native Linux SLR 1.0, so no change in functionality
Native games with the SLR disabled will correctly ignore it, so no change in functionality
- This can be verified by checking the processes in system monitor: no additional srt-bwrap and pressure-vessel-adverb processes are spawned on game launch with the SLR disabled, but are spawned with the SLR enabled
Native games WITH SLR 1.0 FORCED FROM PROPERTIES -> COMPATIBILITY will use the SLR specified here using the new code path that pulls it from the launch command and not the toolmanifest.vdf (verified using log)
Native games WITH SLR 1.0 FORCED FROM PROPERTIES -> COMPATIBILITY but which have SLR disabled from SteamTinkerLaunch Game Menu will correctly ignore it
- This can once again be verified from the processes running
- The launch command still includes some reference to the Steam Linux Runtime, but as it is missing various arguments, it is likely harmless. We could probably grep and remove this, but I think we can just ignore it as it doesn't have any effect on whether the SLR is used or not. This also only happens in the case of a native game using SLR 1.0 with the SLR disabled from STL settings by the user.

Overall in my testing I am happy to merge #1086, but I will wait for OP to test and confirm on their end that it fixes CS2. If OP is unable to test for any reason, I will merge as-is :-)

ReeSilva commented 2 months ago

Hey, @sonic2kk . First of all, thanks for the heads-up regarding STL and online games. I've considered that before, there's no much news regarding that so I considered worth the risk. So, I'm aware of that, but, again, thanks for the heads-up (it will be even important for someone in the future, installing from Package Manager, if find this thread will be aware as well).

Besides that, thanks for the answer and the quick fix, and no need for thanking in the troubleshooting and investigation. A good effort from all parts (from users to developers) is what driven FOSS :)

I've tested and the game is opening well now, and I'm being able to join Valve's Public Servers.

Once again, thanks for that (now I'll be able to play during the weekend without my ADHD remembering me that something is not right hahaha)

ReeSilva commented 2 months ago

btw, just out of curiosity I've tried with Scout (SLR 1.0) and it fails, so CS2 is indeed asking for Sniper even if I have another SLR installed (which I, indeed, didn't have before)

sonic2kk commented 2 months ago

I've considered that before, there's no much news regarding that so I considered worth the risk.

Yup, that's totally fair! I haven't heard any case of any issues, it was just a warning because I'd hate to see anyone get banned for using STL.

Besides that, thanks for the answer and the quick fix, and no need for thanking in the troubleshooting and investigation. A good effort from all parts

I wholeheartedly agree :-) And it is genuinely how I was able to investigate a fix so quickly.

I've tested and the game is opening well now, and I'm being able to join Valve's Public Servers.

Awesome, I am really glad to hear it! I have tested a couple native games at this point and they still work, and a couple of Proton games too. So I think the PR will be good to merge later today. At that point it'll be in master and you won't have to use the branch anymore.

btw, just out of curiosity I've tried with Scout (SLR 1.0) and it fails, so CS2 is indeed asking for Sniper even if I have another SLR installed (which I, indeed, didn't have before)

This is, at least from what I've experienced, quite a rare case but you are indeed correct. CS2 will specifically check for and refuse to launch if not ran with SLR 3.0. With the change in the branch, STL will now always use the SLR coming from the selected compatibility tool, if one comes through at all.

Thank you again for reporting, investigating, and testing. I'll close this issue once the PR is merged and open a separate issue myself for a related feature request to select the SLR for native games . And a drop-down+tooltip+wiki update to note that this won't impact the SLR coming from the compatibility tool -- in general the SLR wiki page needs a big update

Happy gaming!

sonic2kk commented 2 months ago

@StellarHarbour That's not even related to this issue, and I have no idea why it isn't working for you as it works fine for me and other users. One user fixed NXM links for themselves and submitted a PR (#1082).

I'm not sure why you would even suggest this on this issue, and the way you have phrased this implies you think I have intentionally broken MO2 or something. It works for me when I use it, it works for some users and not others. If you're trying to use MO2 2.5 or if you tried to install MO2 2.5 and then roll back without removing all references to the borked 2.5 (for example if you didn't read the docs and tried to use v12.12 to install MO2 after MO2 2.5 was released, and you then later updated to using master without doing a complete fresh MO2 install setup, and if you're on SteamOS if you didn't make sure to cleardeckdeps to make sure an up-to-date innoextract was used -- all information that is already on the ModOrganizer 2 wiki page), then that might be why. But I can't help you based on that alone, and the way you have phrased your reply suggests bad faith (not to mention doing it on an unrelated issue).

If MO2 isn't working for you, feel free to figure out why and submit a PR on how to fix it. FOSS thrives when the community works together, I have poured more than my fair share of time into trying to figure out why things aren't working for some users, and most of the time when I have been able to get someone to work with me, it's ended up being an issue on their end.

@ReeSilva The fix for this issue is in master now, let me know if you find any regressions with regular games overtime but in my testing it works fine!!

ReeSilva commented 2 months ago

@sonic2kk Amazing. I'll checkout master again. I'll test with other games later. I was figuring out if I would be able to make STL works before setup my rig. If I face anything else I'll open a new issue.

Thanks for your amazing work not only with the fix but with STL at all. ^^

billbeans commented 3 weeks ago

This is happening to me on the Steam Flatpak and I'm using the stable branch, which appears to be from February. Do I need to switch to the beta branch for this to work? Same problem as the OP, CS2 closes immediately and in the console I found the message: FATAL: It appears CS2 was not launched within the Steam for Linux sniper runtime environment

billbeans commented 3 weeks ago

Actually it looks like the beta branch hasn't been updated in a year, making it older than the stable branch. This should probably be noted in the Wiki

sonic2kk commented 3 weeks ago

Flatpak SteamTinkerLaunch isn't on the version with this patch, so it doesn't have the fixes. It's packaged separately at https://github.com/flathub/com.valvesoftware.Steam.Utility.steamtinkerlaunch

There is currently no automatic way to get these changes. There is probably a way to custom build the Flatpak / update the SteamTinkerLaunch files with a clone from master, but on not familiar with Flatpaks so I'm not sure how to do that. It's probably installed to ~/.var/app/com.valvesoftware.blah.blah/ and from there you should be able to dig around and find the data files, and then replace them with the one from master.

That isn't guaranteed to work nor endorsed by the Flatpak maintainer, but if you're desperate then that may work.

This should probably be noted in the Wik

The Beta branch is not intended to be used how you've described, and this is described on the wiki.

[...] This should contain Flatpak-specific fixes only available in git releases, but may (or may not) also contain newer features only available in SteamTinkerLaunch git. [...] The Flatpak is not intended to be a git release of SteamTinkerLaunch in Flatpak form [...]

This note at the end of the quote was specifically given by the SteamTinkerLaunch Flatpak maintainer to be added to the wiki a while back. So the information has been on the wiki for a while I believe, it shouldn't be a recent addition if memory serves.

sonic2kk / steamtinkerlaunch