Having Trouble Getting Native Games to Run

[Nano-Ocelot]

The only native game I've managed to get working is Valheim where I could set 'proton version' to 'none'. However in other games I don't have that option therefore they can't be launched because they're forcibly trying to run with proton. How do I force games to run without a proton version? I have attached a screenshot showing the issue where 'none' isn't an option.

[frostworx]

You missed the wiki part below the picture here:
https://github.com/frostworx/steamtinkerlaunch/wiki/Steam-Launch-Option

(the Proton version used can never be set to none, and I also cannot reproduce this happening with Valheim)

Edit: Of course I belive you that you set the option to none, that's not what I meant.
Anyway it should not be possible, so you might have triggered a bug or used a stray/old tempfile in /dev/shm/stl

[Nano-Ocelot]

I actually am using the steam launch option and it still forces me to launch the game using a proton version so it obviously just crashes because it's native. This is very strange. I must've hit a weird bug then. I'll attach a screenshot later for proof. Hopefully I can get this figured out because it's really the best all in one tool for configuring and enabling other tools on Linux and I've been really bummed that I can't get it to work with my native games.

[frostworx]

Ok, good to know you're using the steam launch option already. I'll try to reproduce this, maybe Valve changed something and this doesn't work anymore or I added a regression somewhere
Edit: No need to proof - I believe you! :)

[frostworx]

I used Braid for testing, because it is small which makes switching between linux and windows version pretty fast.
Good news - the linux version still works with stl %command% so nothing seems to have changed.

When the game is installed and not using any compatibility tool please make sure the linux version is actually installed.
stl determines if a linux or windows game is launched by an env variable provided by Steam on game launch (STEAM_COMPAT_DATA_PATH). When it is set we have a proton version, if not it is a linux game.
Only when this variable is set, choosing any proton version is actually used in stl, else proton is completely skipped and the game is treted as native game (ISGAME=2).
If this doesn't work for you please attach the log file of the game launch, to find out if stl went a wrong way somewhere.

[Nano-Ocelot]

This is the log file for Splitgate, which crashes on launch when using stl %command%
677620.log

[frostworx]

There is nothing in the log which crashes.
In fact the game launch function was not even started, so the game also wasn't started using proton.
Instead "Exit" was selected in the settings menu.
Also you might want to check your custom user stop script.

[Nano-Ocelot]

That's bizarre. I wonder why it won't launch then. My user scripts are just commands to stop and start the compositor because games launched with STL don't automatically suspend and resume the compositor for some reason. But also the scripts don't work in STL anyway for some reason but that's two different bug reports that I'll make later.

[frostworx]

user start/stop scripts are simply executed. If they do not work this is no stl bug, so no need to open a different bug.
feel free to write a good generic PR for compositor suspend/resume, I'm not interested in writing it myself, as I simply use gamemoderun start/stopscripts.
feel free to reopen here if you have useful logs with the game launch not working

[Nano-Ocelot]

Well the thing is they work fine when launched from the command line. They just don't work when run in STL.

[frostworx]

check function saveOrgVars and saveOrgVars emptyVars

[Nano-Ocelot]

Does this help? I might've accidentally opened STL and exited the game manually before sending the log last time.
677620.log

[frostworx]

As you can see in the new log is no attempt to launch the game as well, so it must be something else crashing on your system.
I've just seen that Splitgate is free, so I'll try to reproduce it here - maybe I find something out (RL stuff like dentist before...)_

[frostworx]

Download finished earlier than expected.
It just works!
What I did:

• rename my ~/.config/stl/ to start with a clean default setup
• set stl %command%
• start the game
• let the stl requester timeout or enter the settings and start from there - both work
• the game starts correctly

Please try to reproduce, maybe one of your stl configs messed up somewhere (would be interesting to see where then)

[Nano-Ocelot]

I just renamed the whole config folder like you said and it still doesn't launch. Hopefully this log will be different and maybe give you more insight. What's confusing is that this is only an issue with native games (except one native game) and the native games work fine if I don't use stl. Every other game works fine.
677620.log

[frostworx]

Cool, this time the log is complete, and it is indeed visible that the game was detected as Windows game.
reopening as now it is clearly a bug
I'll see if I can find anything before time is running out.

Which OS are you running and are you using Steam stable or beta client (I'm on Arch with Steam Client Beta where it works)

Please also check if STEAM_COMPAT_DATA_PATH is set when you start the game (just add something like env > "/tmp/stl-env" before main "$@" at the end of stl) (no need to paste your whole env, just check if it is set - it usually should when a Linux game was started, maybe something changed (in SLR?))
It would also help if you would test if stl reaches the # win game part in function setCustomGameVars
(a simple echo "setCustomGameVars set ISGAME to 2 " > "/tmp/stl-bug" will do)

[frostworx]

Your ORIGINAL INCOMING LAUNCH COMMAND
contains two SLR calls, have never seen that before.
(I have none, but expected one)
Pretty sure this is the core problem (or at least triggers it) and might be part of what I wrote here
#324
(which might point to the Steam command line option already being shut down)

Can't tell yet if this specific issue is fixable.

[frostworx]

HAH!
Any change you have "Steam Linux Runtime" set as compatibility tool?
I can reproduce the issue when it is set, but it works correctly when setting it to "Steam Tinker Launch" (which basically does nothing, but is a valid option to not switch to the windows build)

[Nano-Ocelot]

HAH! Any change you have "Steam Linux Runtime" set as compatibility tool? I can reproduce the issue when it is set, but it works correctly when setting it to "Steam Tinker Launch" (which basically does nothing, but is a valid option to not switch to the windows build)

Omg that was it! I must've forgot about testing the steam linux runtime a long time ago so they were still set as the compat tool for my native games. It works perfectly fine now.

[frostworx]

Relying on the initial existence of the variable STEAM_COMPAT_DATA_PATH is no longer a valid option to check if a Linux or Windows game was started in this combination.
Might be simply an upstream glitch, but could as well be part of the container strategy
The double SLR appearance can be controlled, the "game OS detection" needs to be rewritten...

[frostworx]

Should be properly fixed with dd3b804

[frostworx]

ping

[frostworx]

So just give no feedback anymore, because the workaround works for you, @Nano-Ocelot?

[Nano-Ocelot]

Oh, sorry. I haven't tried the fix. I was just rolling with the workaround. I can test it though and report back.

[frostworx]

Would be nice, thanks! It should work, but two people testing something is always better than one.

[Nano-Ocelot]

Yep, works perfectly fine now. I just had to remove the old config files after updating and now it launches even when 'steam linux runtime' is set in compatibility options.

[frostworx]

Thanks for confirmation, glad this is fixed properly :)
closing here