Executable Arguments Are Not Passed to Custom Commands #639
Comments
|
I was able to get a Frame Limiter going by enabling a 60fps lock in DXVK.
Still unsure why GameScope was not enabled. |
SentaiBrad
changed the title
|
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.
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 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.
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. |
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.
That's what I presumed. Totally different environment, but curiosity.
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 22380.txt Worth noting that the default_template.conf has GameScope disabled, but I assume that game-specific changes override the default setting. |
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.
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.
Looking at your log, it looks like GameScope is still being disabled. The outgoing start command is not passing GameScope either, as would be expected from the above message: 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.
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. |
I realized after the screenshot and did enable it.
On this most recent test, I disabled MO2 in the settings and we're still at no changes.
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.
Yes and Yes.
I was not to my knowledge, no.
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. |
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.
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 :-) |
|
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.
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 |
|
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 ( |
|
the log from #639 (comment) looks a bit confusing (prepare launch after the game was closed).
sorry if anything I wrote is already known, haven't read through this issue not too carefully as well... |
|
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 🙂 |
|
It's worth noting that when I re-tested this, it was after upgrading to the at-the-time most recent git.
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. |
Nice 👍
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.
Just to confirm, the latest version should be something like |
|
sonic2kk
changed the title
|
Haven't forgotten about this, but no time to look into it recently. Contributions would be welcome on this :-) |
|
Small note: I wonder if |
|
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 :-) |
|
Taking a look at this again and just wanted to note that custom commands have a separate textbox for inputting arguments, however arguments like 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 Initially I want this to apply to custom commands when "Only custom command" is used, as noted above:
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 |
|
Initial work has started at this branch. |
|
Good progress has been made on the branch mentioned. For Proton games, full functionality should be available when 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 |
|
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 :-) |
System Information
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
The text was updated successfully, but these errors were encountered: