Executable Arguments Are Not Passed to Custom Commands

[SentaiBrad]

System Information

• SteamTinkerLaunch version: 11.12.20221021
• Distribution: SteamOS
• Installation Method: ProtonUp-Qt

Issue Description

I have read the GameScope Wiki page several times to make sure I got it configured properly, and the page on it for the Steam Deck. However, despite it being enabled, "GameScope" is passing over no arguments to New Vegas in this case. And yes, MO2 is installed, but I am clicking on the "No MO2" option each time. I am also configuring this in desktop mode, and not the SteamOS GameMode.

I know STL is passing over any commands because I also enabled DXVK HUD, and turned on all of the settings. The Deck is plugged into an External Display, running at 120Hz (max of 165Hz), and I am attempting to Frame Limit the game to 60fps (also tested 30fps). In-game, however, it is running at 120FPS, and I thought something was wrong, to begin with because the game plays too fast.

I looked at every menu I could, and in the conf manually. "GameScope" is enabled and doing nothing as far as I can tell. The behavior happens regardless of the game's built-in VSync. I wanted to go this route, as it is a native Linux Limiter instead of using SpecialK even though it has one of, if not the, best frame limiters out there (at least on Windows).

Side question: I can enable SpecialK in a hidden menu or conf file, but where is the main SpecialK menu? I read somewhere it might be removed. Did that go through?

Logs

Game Launch Log Fallout New Vegas.log

SteamTinkerLaunch Log Fallout New Vegas.log

/dev/shm/steamtinkerlaunch/ Log steamtinkerlaunch.log

[SentaiBrad]

I was able to get a Frame Limiter going by enabling a 60fps lock in DXVK.

Still unsure why GameScope was not enabled.

[sonic2kk]

First of all, I highly discourage playing games in Desktop Mode on Steam Deck. Just using GameScope with composing disabled won't give you the same kind of performance you get in Game Mode, if you're just testing it's fine but this is really just a "courtesy" warning that you shouldn't be doing this if you plan to play seriously.

"GameScope" is enabled and doing nothing as far as I can tell

This definitely sounds like a bug, it worked in my tests previously in Desktop Mode with Terraria. Can you try running without MO2? Set it to disabled in the Main Menu and launch the game. You can tell if GameScope is enabled by pressing Meta+W to bring up all windows and if there is no window icon, you are probably using GameScope. You could also check in system monitor by searching for gamescope, or also by setting the GameScope resolution to something absurd and seeing if there is any visible change.

Using the "No MO2" option may be the problem here, you could also try running with MO2 GUI and seeing if GameScope launches that way. It should - It worked for me before when I modded Skyrim. MO2 would run in a GameScope window and the game would launch on top of it. But perhaps choosing thee "No GUI" option or whatever it's called, happens to break passing GameScope.

Side question: I can enable SpecialK in a hidden menu or conf file, but where is the main SpecialK menu? I read somewhere it might be removed. Did that go through?

SpecialK has not been removed. You can enable it in the Main Menu. I am not so sure that it works better as a framerate limiter on Linux, your mileage may vary on that front. Whether you use MangoHud, GameScope or DXVK to limit the framerate, they should all work the same. Please remember that SpecialK is a Windows tool and the developer only offers minimal support and tolerance for the Linux community.

[SentaiBrad]

First of all, I highly discourage playing games in Desktop Mode on Steam Deck. Just using GameScope with composing disabled won't give you the same kind of performance you get in Game Mode, if you're just testing it's fine but this is really just a "courtesy" warning that you shouldn't be doing this if you plan to play seriously.

100%. It's just easier for testing purposes. I know performance is not nearly the same. But, it is a lot easier to mod, tinker, edit configs like this, or test to make sure a frame limiter is working.

Side question: I can enable SpecialK in a hidden menu or conf file, but where is the main SpecialK menu? I read somewhere it might be removed. Did that go through?

SpecialK has not been removed. You can enable it in the Main Menu. I am not so sure that it works better as a framerate limiter on Linux, your mileage may vary on that front. Whether you use MangoHud, GameScope or DXVK to limit the framerate, they should all work the same. Please remember that SpecialK is a Windows tool and the developer only offers minimal support and tolerance for the Linux community.

That's what I presumed. Totally different environment, but curiosity.

"GameScope" is enabled and doing nothing as far as I can tell

This definitely sounds like a bug, it worked in my tests previously in Desktop Mode with Terraria. Can you try running without MO2? Set it to disabled in the Main Menu and launch the game. You can tell if GameScope is enabled by pressing Meta+W to bring up all windows and if there is no window icon, you are probably using GameScope. You could also check in system monitor by searching for gamescope, or also by setting the GameScope resolution to something absurd and seeing if there is any visible change.

Using the "No MO2" option may be the problem here, you could also try running with MO2 GUI and seeing if GameScope launches that way. It should - It worked for me before when I modded Skyrim. MO2 would run in a GameScope window and the game would launch on top of it. But perhaps choosing thee "No GUI" option or whatever it's called, happens to break passing GameScope.

Disabled MO2 in the Game Menu, disabled the DXKV 60fps limit I had set and re-enabled GameScope in this menu as well. Went back to the main menu, and into the GameScope-specific menu here, and am using these settings for a test:

DXVK Hud is reporting 120fps once again, no frame limiting. I ran KFind under the STL .config folder and searched inside all documents for references to GameScope, and then I narrowed them down to the testing I am doing just for this with New Vegas. Unsure if these are helpful, but here they are.

22380.log This log is from - /home/deck/.config/steamtinkerlaunch/logs/steamtinkerlaunch/id

22380.txt This config (changed to a .txt as GitHub wouldn't allow me to upload a .conf) is from - /home/deck/.config/steamtinkerlaunch/gamecfgs/id/

Worth noting that the default_template.conf has GameScope disabled, but I assume that game-specific changes override the default setting.

[sonic2kk]

100%. It's just easier for testing purposes

Absolutely fine :-) Basically, I wanted to avoid a scenario where you pour time into getting something working only to realise it won't work how you expect. I also foresee situations where users on Steam Deck see GameScope and think "oh, that's the thing that gives the Steam Deck good performance!" - I am not trying to imply that this is how you would have seen it, but this is the kind of situation I want to avoid.

and into the GameScope-specific menu here, and am using these settings for a test:

The bottom checkbox has to be enabled in that screenshot, the one simply called "gamescope". Although in your earlier screenshot from the main menu, the GameScope checkbox was checked. It might be worth making sure this option is definitely kept toggled on - Try enabling that checkbox, then pressing "Done" and then going back into the GameScope menu to see if it stays enabled.

Until fairly recently, GameScope was disabled entirely on Steam Deck. But there was a change made to include a variable to differentiate between running in Game Mode and Desktop Mode on Steam Deck, and I made the change to enable GameScope. I had tested with Terraria and Cookie Clicker and it seemed to work, however I did no testing with ModOrganizer 2 - It didn't occur to me that there could be problems.

GameScope is still disabled in Game Mode (along with a couple of other settings) because there is no reason to allow a user to enable it in Game Mode.

[log files]

Looking at your log, it looks like GameScope is still being disabled.

Mon Oct 24 08:36:19 AM PDT 2022 SKIP - steamdeckBeforeGame - Disabling own gamescope on SteamDeck

The outgoing start command is not passing GameScope either, as would be expected from the above message:

Mon Oct 24 08:36:19 AM PDT 2022 INFO - launchSteamGame - Final outgoing start command: '/home/deck/.local/share/Steam/compatibilitytools.d/GE-Proton7-37/proton waitforexitandrun /home/deck/.local/share/Steam/steamapps/common/Fallout New Vegas/FalloutNVLauncher.exe /home/deck/.local/share/Steam/compatibilitytools.d/GE-Proton7-37/proton waitforexitandrun /home/deck/.local/share/Steam/steamapps/common/Fallout New Vegas/FalloutNVLauncher.exe /home/deck/.local/share/Steam/compatibilitytools.d/GE-Proton7-37/proton waitforexitandrun /home/deck/.local/share/Steam/steamapps/common/Fallout New Vegas/FalloutNVLauncher.exe'

Just to absolutely confirm, you are running SteamTinkerLaunch from Desktop Mode with this log file, yes? Does the timestamp also look correct to you?

I also notice that you are trying to launch a custom command for Fallout New Vegas? Is this a mistake, or perhaps an attempt to skip the launcher? I am not sure if custom commands use GameScope or how that works, so I would try disabling using a custom command just in case.

However, the "disabling own gamescope on SteamDeck" message might be the real problem here.

Worth noting that the default_template.conf has GameScope disabled, but I assume that game-specific changes override the default setting.

Correct, GameScope is disabled by default for all games and it has to be enabled on a per-game basis - SteamTInkerLaunch almost always won't touch per-game settings by default. So if you just enabled STL for a game and launched it, it should launch virtually identically to a regular game launch. It's up to users to enable the tweaks, which are really just passing environment variables.

[SentaiBrad]

100%. It's just easier for testing purposes

Absolutely fine :-) Basically, I wanted to avoid a scenario where you pour time into getting something working only to realise it won't work how you expect. I also foresee situations where users on Steam Deck see GameScope and think "oh, that's the thing that gives the Steam Deck good performance!" - I am not trying to imply that this is how you would have seen it, but this is the kind of situation I want to avoid.

and into the GameScope-specific menu here, and am using these settings for a test:

The bottom checkbox has to be enabled in that screenshot, the one simply called "gamescope". Although in your earlier screenshot from the main menu, the GameScope checkbox was checked. It might be worth making sure this option is definitely kept toggled on - Try enabling that checkbox, then pressing "Done" and then going back into the GameScope menu to see if it stays enabled.

I realized after the screenshot and did enable it.

Until fairly recently, GameScope was disabled entirely on Steam Deck. But there was a change made to include a variable to differentiate between running in Game Mode and Desktop Mode on Steam Deck, and I made the change to enable GameScope. I had tested with Terraria and Cookie Clicker and it seemed to work, however I did no testing with ModOrganizer 2 - It didn't occur to me that there could be problems.

On this most recent test, I disabled MO2 in the settings and we're still at no changes.

GameScope is still disabled in Game Mode (along with a couple of other settings) because there is no reason to allow a user to enable it in Game Mode.

Which is totally fair. In the end, the DKXV implementation worked perfectly in GameMode. The DXKV Hud was still even visible in GameMode, and overlapped with the Valve MangoHud implementation. I can make a Bug Report on this too if you'd like.

[log files]

Looking at your log, it looks like GameScope is still being disabled.

Mon Oct 24 08:36:19 AM PDT 2022 SKIP - steamdeckBeforeGame - Disabling own gamescope on SteamDeck

The outgoing start command is not passing GameScope either, as would be expected from the above message:

Mon Oct 24 08:36:19 AM PDT 2022 INFO - launchSteamGame - Final outgoing start command: '/home/deck/.local/share/Steam/compatibilitytools.d/GE-Proton7-37/proton waitforexitandrun /home/deck/.local/share/Steam/steamapps/common/Fallout New Vegas/FalloutNVLauncher.exe /home/deck/.local/share/Steam/compatibilitytools.d/GE-Proton7-37/proton waitforexitandrun /home/deck/.local/share/Steam/steamapps/common/Fallout New Vegas/FalloutNVLauncher.exe /home/deck/.local/share/Steam/compatibilitytools.d/GE-Proton7-37/proton waitforexitandrun /home/deck/.local/share/Steam/steamapps/common/Fallout New Vegas/FalloutNVLauncher.exe'

Just to absolutely confirm, you are running SteamTinkerLaunch from Desktop Mode with this log file, yes? Does the timestamp also look correct to you?

Yes and Yes.

I also notice that you are trying to launch a custom command for Fallout New Vegas? Is this a mistake, or perhaps an attempt to skip the launcher? I am not sure if custom commands use GameScope or how that works, so I would try disabling using a custom command just in case.

I was not to my knowledge, no.

However, the "disabling own gamescope on SteamDeck" message might be the real problem here.

Worth noting that the default_template.conf has GameScope disabled, but I assume that game-specific changes override the default setting.

Correct, GameScope is disabled by default for all games and it has to be enabled on a per-game basis - SteamTInkerLaunch almost always won't touch per-game settings by default. So if you just enabled STL for a game and launched it, it should launch virtually identically to a regular game launch. It's up to users to enable the tweaks, which are really just passing environment variables.

If GameScope only provides benefits in the Desktop Environment, then would it be a good idea to scrap it for the Deck version all together then? Considering trying to actively play games in the DE on the Deck is a generally dumb idea. The only benefit this testing may prove valuable for might other limited permission distro's that STL can run on.

[sonic2kk]

I can make a Bug Report on this too if you'd like.

I am sort of hesitant as DXVK Hud could have some extra info and such that Valve's MangoApp overlay doesn't have. I think letting a user enable DXVK Hud in Game Mode is fine, I don't think we disable MangoHud in Game Mode so I would lean more in favour of letting a user keep DXVK hud enabled. It's less likely to cause real problems that can't be solved by simply disabling Valve's MangoApp overlay in Game Mode, whereas Feral GameMode (performance boosting tool enabled and configured in Game Mode by Valve, but STL lets you enable this on Desktop if you have it installed) and GameScope could cause hindrances beyond just visual overlap.

If GameScope only provides benefits in the Desktop Environment, then would it be a good idea to scrap it for the Deck version all together then? Considering trying to actively play games in the DE on the Deck is a generally dumb idea.

I can see where you're coming from, but a user might have any number of reasons to wanting to use GameScope on Deck including testing. I am not in favour of removing the option to use features in a Linux desktop specifically to appeal to Steam Deck use-cases. Users are tinkering with SteamTinkerLaunch at their own risk, and user-error is on them. There might be a situation where a user wants to play a game in Desktop Mode, and they're heavily customised their SteamOS install, tinkered around with Feral GameMode, and they want to use GameScope to play games that have windowing issues/want to restrict a game for any number of reasons.

I do understand the logic in removing it but I am not in favour of removing features that power users might find useful, and SteamTinkerLaunch imo appeals most directly to power users.

---

I'm still not sure why STL thinks GameScope should be disabled. I'll have to investigate more into this, but other issues take priority at the moment :-)

[sonic2kk]

I just did a quick test again with Cookie Clicker on the latest Git, and GameScope was enabled fine for me. When you start a game, the notifier should tell you the Proton version and if it's starting with GameScope.

I'm going to add some more logging to properly log when STL thinks its in Game Mode and Desktop Mode on Steam Deck. The logging is already there, but I didn't see the note that GameScope was running "forced" on Deck. I'll have to test and check again.

If you have any other games on your Deck that you're willing to test with, please do and report back! It doesn't have to be anything major, just something small that you don't really care if you mess up tinkering with - Just a simple test with a simple game, enabling GameScope and maybe something else like MangoHud or DXVK Hud.

EDIT: I wonder if DXVK Hud is breaking GameScope... Doubt it though, since there is that explicit warning that we're disabling GameScope

[sonic2kk]

If you are still having trouble with the automatic updating for STL as per #635, don't worry about this issue for now.

I added some more logging in the latest version (20221024-3), if you've got STL updated and if you have a moment please run FONV (or any game, really) and attach a log so I can take a look at the updated logs. Feel free to look yourself of course too, the logs might seem a little scary but they're a nice trace once you understand the flow.

[SentaiBrad]

Doesn't look like anything is being activated still. No 60fps clamp.

From /home/deck/.config/steamtinkerlaunch/logs/steamtinkerlaunch/id/ 22380.log

From /home/deck/.config/steamtinkerlaunch/logs/gamelaunch/id/ 22380.log

[frostworx]

the log from https://github.com/sonic2kk/steamtinkerlaunch/issues/639#issuecomment-1289237819 looks a bit confusing (prepare launch after the game was closed). But using the custom command CUSTOMCMD is enabled USECUSTOMCMD, which might not have an extra check for gamescope FIXGAMESCOPE Also it seems the last release version "SteamTinkerLaunch v11.11" was used, so I'd suggest

• re-try with disabled CUSTOMCMD and/or check why the auto-update to git master didn't work (or quickly reading through #635 - check if the update really worked)

sorry if anything I wrote is already known, haven't read through this issue not too carefully as well...

[sonic2kk]

Good catch on the version, that is really strange.

Auto update should be working last time I tested on my Deck, not sure what might've gone wrong there.

And you seem to be bang on about the custom command being the problem. I just tested with Cookie Clicker pointing to a couple of custom commands including to the Game exe itself (to simulate what OP is doing with New Vegas) with the latest STL git and GameScope was not used. I also tested GameMode and MangoHud and they were not used either.

Disabling "Use custom command" and "Only custom command" launched the game like normal with GameScope, MangoHud and GameMode.

As you say Frostworx I don't think this feature was ever implemented, so I don't think this was something that "broke".

@SentaiBrad I skimmed through and didn't see us test this so could you test with the custom command disabled (uncheck the custom command and only custom command checkboxes basically iirc) and see if GameScope is used?

---

This raises an interesting though. I'm not sure if we want things like GameScope to always be passed to the custom command. Specifically for GameScope I can see why someone would not want those things passed, however when "Only custom command" is selected, I think that's a different story.

And of course, there would be no GameScope passed in the launch options because v11.11 is being used as per the logs.

I think the solution here is that, when "Use custom command" and "Only custom command" are selected, STL should pass arguments to the custom command. I think this should be default behaviour, and there should be a checkbox to disable this. I think it's fine to only have one checkbox that says something like "No custom command arguments" which won't pass GameScope or anything. I don't think the naming is perfect exactly, as it might imply env vars don't be passed, but you get the idea :-) Basically a checkbox to disable passing GameScope/MangoHud/etc, and it is a checkbox to disable because I think it is more fitting to have the default behaviour pass GameScope and the like when "Only custom command" is checked.

This feature will need more thoughts and discussion so I may not work on it in the very near future, but I will keep it in mind and keep it on my radar :slightly_smiling_face:

[SentaiBrad]

It's worth noting that when I re-tested this, it was after upgrading to the at-the-time most recent git.

@SentaiBrad I skimmed through and didn't see us test this so could you test with the custom command disabled (uncheck the custom command and only custom command checkboxes basically iirc) and see if GameScope is used?

This raises an interesting though. I'm not sure if we want things like GameScope to always be passed to the custom command. Specifically for GameScope I can see why someone would not want those things passed, however when "Only custom command" is selected, I think that's a different story.

I think the solution here is that, when "Use custom command" and "Only custom command" are selected, STL should pass arguments to the custom command. I think this should be default behaviour, and there should be a checkbox to disable this. I think it's fine to only have one checkbox that says something like "No custom command arguments" which won't pass GameScope or anything. I don't think the naming is perfect exactly, as it might imply env vars don't be passed, but you get the idea :-) Basically a checkbox to disable passing GameScope/MangoHud/etc, and it is a checkbox to disable because I think it is more fitting to have the default behaviour pass GameScope and the like when "Only custom command" is checked.

Unchecking the "Use Custom Command" box does pass over GameScope settings now. I get a notification that GameScope is starting w/ ProtonGE now. I would have thought that this box being checked or unchecked wouldn't matter if you specifically checked to Enable GameScope. I'm not sure the exact best way to go about it, but yea. So it seems this was the case, and I am re-reupdated to the latest Git as of 20 minutes ago.

[sonic2kk]

So it seems this was the case, and I am re-reupdated to the latest Git as of 20 minutes ago.

Nice :+1:

I would have thought that this box being checked or unchecked wouldn't matter if you specifically checked to Enable GameScope

Well if only "Use custom command" is checked and a custom command is selected, that means the custom command would appear with the game in the same window. GameScope puts all applications into one isolated Xorg/Xwayland window. This means if GameScope was passed to both, you couldn't switch between your custom command (if it's a GUI program - which generally it is) and the game! You could I suppose pass GameScope to both the custom command and the game separately, but this could still be unexpected and undesirable behaviour.

In my mind, I think if "Use custom command" is enabled, a custom command is selected, and "Only custom command" is enabled, then we should pass over arguments like MangoHud, GameScope and GameMode to the custom command. And for users that don't want this, there will be a checkbox to not do this.

In the instance where a user is using a custom command and the game, I think the current behaviour is a fine default. Usually someone isn't going to want two GameScope instances and it'll probably be preferable to have the custom command and the game running separately. But I could see a case where a user would want their custom command to run with GameScope separate from their game, or they would want MangoHud/MangoApp passed to it.

I think for the latter case, where a custom command is selected to run with the game and not instead of it, that'll have to wait for #625.

So it seems this was the case, and I am re-reupdated to the latest Git as of 20 minutes ago.

Just to confirm, the latest version should be something like 20221028-1. Can you confirm this is the version you're using? :slightly_smiling_face:

[SentaiBrad]

Just to confirm, the latest version should be something like 20221028-1. Can you confirm this is the version you're using? 🙂

[sonic2kk]

Haven't forgotten about this, but no time to look into it recently. Contributions would be welcome on this :-)

[sonic2kk]

Small note: I wonder if setFullGameExePath would be useful in resolving this...

[sonic2kk]

Will probably look into this as a semi-priority after v12 is released. I don't have the time to try and investigate this at the moment, and I don't want to implement something like this so close to a release as it could break various things :-)

[sonic2kk]

Taking a look at this again and just wanted to note that custom commands have a separate textbox for inputting arguments, however arguments like gamescope etc is what this issue refers to specifically. Will hopefully resolve this soon!

Issue seems to be that custom program launches are handled separately from a regular game launch. The launch command "building" that happens for regular Steam games does not happen for custom programs. The functions of interest that I can see are checkCustomLaunch and launchCustomProg. Probably one of these will need to have the logic to check for things like GameScope/MangoHud/etc and properly append to the custom program. Perhaps a generic function could be created to do this, unsure yet how feasible/worth the effort that is, just thoughts at midnight :-)

Initially I want this to apply to custom commands when "Only custom command" is used, as noted above:

In my mind, I think if "Use custom command" is enabled, a custom command is selected, and "Only custom command" is enabled, then we should pass over arguments like MangoHud, GameScope and GameMode to the custom command. And for users that don't want this, there will be a checkbox to not do this.

Whether or not I will wait for #625 for game+custom command arguments, as mentioned by past-sonic2kk, I am not sure yet. Potentially this will be the case as I think that is a much more niche use-case, whereas using ONLY a custom command and wanting things like GameScope etc to be passed could be more common (for example, using a third-party game launcher e.g. RuneLite for OldSchool RuneScape).

Having browsed the logic a little, I think launchCustomProg is the function where we should build the only custom command arguments, since after this call, checkCustomLaunch expects ONLY_CUSTOMCMD custom programs to have already launched already and exists.

[sonic2kk]

Initial work has started at this branch.

[sonic2kk]

Good progress has been made on the branch mentioned. For Proton games, full functionality should be available when ONLY_CUSTOMCMD is 1. Native games are still WIP, and system Wine executions have not been touched yet as it will require touching some of the extWine launch logic which will need thorough testing.

Notifiers have also been added for launching custom Proton/Wine commands, and I will add notifiers for native games shortly too.

The next priority is fixing up the argument passing for native games and once that works, I will look into probably changing the behaviour of when this is used slightly. Initially, I thought a good default would be to pass these commands if ONLY_CUSTOMCMD is enabled. However if a user is switching back and forth this could get annoying. So instead I think for all cases, I will gate this behind a checkbox. Something like Pass external programs to custom command and a tooltip stating that this is for GameMode, GameScope, MangoHud etc.

[sonic2kk]

This should be fixed following #732's merge. I did some tests and it worked with the custom programs I tried, and it should not have any detrimental effects to other parts of STL (I tested the refactoring to share some of the outgoing command code with Steam games and custom commands, and did not run into any issues).

@SentaiBrad it's been quite a while, sorry it took so long to implement this (was busy with Hedge Mod Manager support + holidays + personal life), but please feel free to test it and report any issues :-)