Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Non-Steam Proton Games from Launching #560

Merged
merged 1 commit into from
Aug 29, 2022
Merged

Fix Non-Steam Proton Games from Launching #560

merged 1 commit into from
Aug 29, 2022

Conversation

sonic2kk
Copy link
Owner

Non-Steam Proton games wouldn't launch with SteamTinkerLaunch. It seems the cause was a missing "${GAMESTARTCMD[*]}" argument when setting PROTONSTARTCMD. I discovered this by inspecting the logs and noticing that GAMESTARTCMD[*] had the correct value, but PROTONSTARTCMD was missing it for some reason. I'm not totally sure how the setProtonCmd function works or what functions are called around it, so I'm not sure why this was only broken for Non-Steam Proton games, but this seems to fix Non-Steam Proton games in my tests and doesn't break regular Steam Proton games. In fact, games seem to launch significantly faster now? Could just be placebo but I did compare a build from this branch and a build from master... Who knows :-)

Non-Steam Proton games tested:

  • HoloCure
  • Sonic P-06

Steam Proton games tested to ensure this change didn't break anything:

  • Cookie Clicker (regular ol' Cookie Clicker with no tweaks)
  • Old School RuneScape (this has a custom command to launch a native Linux third-party launcher called RuneLite, and also has custom commands like GameMode enabled)
  • Fallout: New Vegas (modded to the hilt with MO2, and has a bunch of STL tweaks like DXVK Framerate Limiting, MangoHud and GameMode)

Steam Native games tested to be extra sure that this change didn't break anything:

  • Terraria (native Linux game with steamtinkerlaunch %command%, no tweaks)
  • Celeste (native Linux game with steamtinkerlaunch %command%, MangoHud enabled and a custom command line option set to force the game to use Vulkan instead of OpenGL)

I believe I covered as many basis as reasonably necessary to ensure this doesn't break anything, but I welcome all feedback and of course if there's something this change can potentially break let me know.

Thanks!

@frostworx
Copy link
Collaborator

thanks for the PR, mate.
Merging and concatenating the game launch command grew historically in multiple places in steamtinkerlaunch. It was mostly merged centrally later, but never went completely nice.
Although your PR apparently fixes your issue, I'm not 100% sure yet if this is the right place for the fix yet -
appending ${GAMESTARTCMD[*]} to PROTSTARTCMD feels incorrectly and might cause issues with other game launch options. It might be perfectly fine here though as well.
The PROTSTARTCMD array is finally appended to FINALSTARTCMD in the function launchSteamGame
(or FINALSTARTCMD is created from it if it does not exist yet)

Would be nice if you could check some STARTDEBUG logs (hehe, just noticed STARTDEBUG is still set to 1 by default)
of various random regular game starts to see if this PROTSTARTCMD is possibly misconfigured here.

@frostworx
Copy link
Collaborator

just added FINALSTARTCMD to the STARTDEBUG log

@sonic2kk
Copy link
Owner Author

Thanks for the review! I did some testing with your latest commit but I just wanted to point out something I forgot to in my PR. This is before testing with your latest commit :)

In the STARTDEBUG logs, FINAL LAUNCH RUNCMD is blank. This is true for both Steam Proton games and Non-Steam Proton games. This is part of what prompted my investigation :-)

Also wanted to mention that for one game (Cookie Clicker), I noticed the following line: HAVESCTP='1', but also HAVEREAP='0' - something went wrong - never seen this in the wild. Didn't want to open a separate issue for this and I didn't see this in other Proton games like Sonic Adventure 2, but since it says this was never seen in the wild I wanted to mention that too :)


Running Steam Proton Games sets FINALSTARTCMD in the debug log to

Sun Aug 28 15:39:16 BST 2022 - Cookie Clicker (1454400) - FINALSTARTCMD '/usr/bin/gamemoderun /run/media/username/BigSSD/Games/steamapps/common/Proton 7.0/proton waitforexitandrun /run/media/username/500GB SSD/Games/steamapps/common/Cookie Clicker/Cookie Clicker.exe --in-process-gpu --process-start-args -disable-features=HardwareMediaKeyHandling'

Running Non-Steam Proton Games sets it to:

Sun Aug 28 15:37:38 BST 2022 - HoloCure (2468522275) - FINALSTARTCMD '/home/username/.local/share/Steam/compatibilitytools.d/GE-Proton7-20/proton waitforexitandrun'

Though even for Non-Steam Proton games, ORGGCMD 'waitforexitandrun /run/media/username/500GB SSD/Non-Steam Games/HoloCure/HoloCure.exe' is seen correctly. So STL knows the path to the game executable but for some reason loses it by the time it gets to FINALSTARTCMD.

@frostworx
Copy link
Collaborator

thanks for testing.
"FINAL LAUNCH RUNCMD" being empty doesn't matter. the STARTDEBUG debug function is already is pretty old and initially was not even meant to stay in the code. I started it from different locations for debugging certain vars (mostly SLR stuff)
and therefore not every variable written has to be available everytime.
HAVESCTP, HAVEREAP and friends are similar unimportant leftovers as well. the SLR changed again since those vars had any use (as in: one day everything will break/ steamtinkerlaunch would require mostly a rewrite from scratch - see WIP analyze in your origin issue)

back OT:
your test results look fine for me. I'm still not sure if this is the perfect place to add it, but I don't find the time to look for a better place, so I'll merge your PR and we'll just wait if someone cries.

Good work, @sonic2kk! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants