sonic2kk
[Feature Request] Non-Steam Game Improvements
System Information
- SteamTinkerLaunch version: v14.0.20231525-1
- Distribution: Arch Linux
Feature Description
Non-Steam Games have had it a bit rough historically, but that has changed a lot in recent months with things like SteamGridDB integration, artwork selection, and compatibility tool selection. However, there are still some improvements we can make.
Integrate Non-Steam Games with getid, getname, getexe, getgamedir, getcompatdata
Right now it is not very easy to get things like the AppID or EXE name for Non-Steam Games, because they don't integrate with the associated commands. We should try to address some of this. We should be able to attempt to parse out information on Non-Steam Games from the shortcuts.vdf file, using some assumptions about the file format. This should be constant and we already do this when adding Non-Steam Games. I wrote a GitHub Gist which can extract all AppIDs from shortcuts.vdf, but it can't extract others and doesn't associate shortcut information, i.e. there is no way to know what game name an AppID corresponds to.
It may be tricky to do but it should be feasible, we can split the file based on the bytes around the part where a shortcut begins and ends I think (other parsers must do this too, right?) and then loop through each of those, parsing out the information for each.
For each of the commands:
- For
getid, we should be able to use the game name - For
getname, we can use the
General Command to List Non-Steam Games
This one should be quite handy, we should have a command to output all Non-Steam Shortcuts including their AppID. We could default to the format Game Name (AppID) -> /path/to/exe, with options to list only some fields i.e. name, exe, gamedir, etc. Basically the fields from above. Then we could have a command to display all, which would return the name, AppID, startdir, etc, perhaps in a format like this (could have more/less info and/or in a different format, this is just an example):
Name: Dungeon Keeper 2
AppID: 3849204543
Exe: /home/gaben/Games/GOG/Dungeon Keeper 2/DK2.exe
StartDir: /home/gaben/Games/GOG/Dungeon Keeper 2
Compatdata: /home/gaben/.local/share/Steam/steamapps/compatdata/3849204543
Command to Set SteamGridDB Artwork for All Non-Steam Games
(see also #934)
Following on from the above, we can have a command to get all Non-Steam AppIDs and then set SteamGridDB artwork on them, using the Game Name as the search field.
It should be possible to implement this though, because we can do it for all Steam AppIDs, and the gist I wrote returns the 32bit unsigned AppID, so it would just be a case of passing commandlineGetSteamGridDBArtwork --search-name="${SHORTCUTSENTRYNAME}" --filename-appid="${SHORTCUTSENTRYAID}" --nonsteam --apply inside of a loop.
The work here doesn't necessarily have to go in any order, but the command integration will probably come first, because it'll help proof out the remaining work. If we can list all Non-Steam Games with linked names and AppIDs, it'll make the SteamGridDB integration very straightforward, and all of this will be more straightforward to do if we can individually do this when Non-Steam Games are integrated with other commands.
TODO:
- [x] Integrate Non-Steam Games with other commands
- [x] Integrate with
getid(appid field already inshortcuts.vdf, though casing can vary) - [x] Integrate with
getname(appname field already inshortcuts.vdf, though casing can vary) - [x] Integrate with
getexe(Exe field already inshortcuts.vdf, though casing can vary) - [x] Integrate with
getcompatdata(compatdata for Non-Steam Games is always the Steam root steamapps folder's compatdata i.e./home/gaben/Games/steamapps/compatdata/000000000) - [x] Integrate with
getgamedir(use StartDir for this)
- [x] Integrate with
- [x] Command to Fetch SteamGridDB Artwork for All Non-Steam Games
- [x] Command to List All Non-Stem Games
- [x] Fix AllowOverlay not working (now set in
localconfig.vdf) - [x] Fix OpenVR not working (now set in
localconfig.vdf - [ ] Fix setting Hidden category for Non-Steam Games
This gist I made illustrates how to to get information from each shortcut entry: https://gist.github.com/sonic2kk/9bf61220ce6650db6cc3eddf5a7bc493
I've spent a couple of days investigating this, and while it is now 100% feasible and possible to get information about Non-Steam Games, we just need to find the best way to integrate it.
Most of this will be implemented in #963, it implements the core functions for parsing shortcuts.vdf and even a function for editing a field in a shortcut entry.
Some updates:
getidandgettitleintegration were added with #963.- Command to fetch artwork for all Non-Steam Games was added with #963.
- The
localconfig.vdfparsing functions to allow for setting shortcuts as hidden etc was added in #967. - The
shortcuts.vdfparsing functions to facilitate the rest of the work here were added in #963.
Most of the remaining work for this PR is just implementing the remaining functions following a similar pattern to how we implemented gi/gt command support.
The other work around setting fields like hidden in shortcuts.vdf is now possible thanks to the localconfig.vdf parsing functions.
The remaining work in this PR should be straightforward to do, I will work on it soon hopefully.
Support for getexe command was added in #969. Support for getcompatdata was added in #970.
Decided to go with using the shortcut Exe dirname for getGameDir. I think it makes much more sense, as explained in #971.
I looked at a friend's localconfig.vdf to see how it looks if no Steam Shortcuts have ever been added to the library.
If no shortcuts have ever been added to Steam, it seems like user-collections is not defined. So, for setting games into the hidden and favorites category, we will need to create this. I believe there is some commented code in debug that should give a hint.
For setting the OpenVR and AllowOverlay options, we do that in a block that looks like this:
"Apps"
{
"<AppId>"
{
"option" "value"
}
}
Noting that <AppId> is, for whatever reason, the signed 32bit AppID, like -998405935.
However, if no Steam shortcuts have been added, the "Apps" block is absent entirely! I am conscious of making sure we insert this into the right place in the VDF, but we may not be able to make assumptions about the file structure. Hopefully Steam is not fussy, and we can simply insert the "Apps" block into the bottom of the file. From there, we should be able to create the block for the Non-Steam AppID we're creating, and insert our desired values.
It'll be a bit tricky but it should be feasible. We should be able to check for and create VDF sections, maybe we could even make a helper VDF to create nested VDF sections, that way we could just say createNestedVdfSection "Apps/${signed_aid}" in addNonSteamGame, so we don't have to worry about whether or not Apps exists. There'd probably need to be more arguments there, like where to insert the block, etc.
Is there any way to decrease the size of the default icon for non-Steam games launched with the compatibility tool? It is problematic on non-Steam games on the Steam Deck OLED as the default icon occupies have the screen size with the icon itself.
Non Steam game launched with steamtinkerlaunch
Steam game launched with steamtinkerlaunch
This is not a help forum for using Non-Steam Games, especially ones available on Steam, and Steam Deck support is virtually gone from STL these days, but to answer your question: This is a gamescope issue as this doesn't happen on my Linux desktop, so no.
You could work around this by using SteamGridDB to set artwork for the game (see the wiki for guidance) or by using the Steam version of this game.
But please don't piggyback on issues that are only vaguely related to your question. This is for development of the features outlined in this issue only, not a place to ask questions. This goes for any project. I did not open this to be a support topic, I opened this for development transparency and for developers to volunteer to help out with the features outlined here.
For this reason I will be marking your comment and mine off-topic, but hopefully this sheds some light.
Apparently, only Non-Steam Games use the unsigned 32bit AppID in the "Apps" section. Regular Steam games will sometimes store controller config information here, and they use the regular Steam AppID. Not a problem for implementation, just worth pointing out for future reference.
This has been a real pain in the ass to work through. There's veeeery slow progress being made on this locally. I have a branch I'm testing things on (with an initial push here) but this is not an easy problem to solve with Bash. I somewhat regret not investing the time in trying to make this in like C++ or something, but here we are.
I'm hoping to get this resolved sometime soon, and once the remaining Non-Steam Game stuff is in place, v14.0 should be pretty close to releas.e
Implemented support to list all Non-Steam Games into the list command, you can now list all Non-Steam Games with steamtinkerlaunch list nsg.
The final remaining piece of work for this issue is to fix setting the "Hidden" option.
Steam treats hidden as a collection, and the Display Name is actually an uppercase H. If you use DumpSteamCollections to search for it, the internal name instead of being like uc-<blahblah> it will be hidden (note the lowercase h). The example script on DumpSteamCollections actually returns Hidden -> hidden and you have to search for the uppercase `Hidden``.
It also does not have from-tag-Hidden, so I am not sure if this name ever changes or changed. Do newer Steam libraries also have the collection name as hidden?
Despite all of this, however, because we can get the collection name from DumpSteamCollections, to me that indicates that we should. Instead of doing all of this guesswork, we should be using DumpSteamCollections to get the actual name. That also has the benefit of meaning if we implement support for adding Non-Steam Games to the "Hidden" collection, it should follow very closely with adding Non-Steam Games to any collection, which would solve #949.
Basically if we treat adding Non-Steam Games as Hidden as the same as adding them to any other category, we will solve both issues in one or very closely thereafter.