Setting Custom AppID for Non-Steam Game

[MattyXarope]

So I see that you can add via command line a non-steam game with certain parameters here, but I don't see any way to set a custom AppID for that app.

Is this possible? Perhaps I'm missing the correct setting to be changed?

[sonic2kk]

I don't think there's a way of setting a custom AppID for a game. Maybe this is possible with something like Steam Rom Manager though? I haven't really heard the idea of setting a custom AppID for non-Steam games before. I figured either they didn't have AppIDs or that Steam set that automatically somehow.

It's interesting though! What is the use-case for this, and do you know the process of doing it "manually"? If we can get more information on this I would consider taking a stab at implementing it :slightly_smiling_face:

[MattyXarope]

The process for assigning games using Proton (which the Proton prefix folder's name is essentially the AppID of the game) their ID works as follows:

1. Non-Steam game exe is added to Steam, being appending to the shortcuts.vdf (this is something that can currently be done use the CLI of STL). There is no ID assign to the added .exe at this point, at least in the shortcuts.vdf file.

2. Once a compatibility tool is selected OR a game icon is assigned to the added .exe, an appID is generated. When running the game with Proton, a prefix folder is created in the compatdata folder with the name of this ID, and the game is appended as the last entry within the config.vdf under the CompatToolMapping section which includes the AppID of the game and three parameters:

• name (which shows the Proton version selected)
• config (no idea what this does)
• priority (no idea what this does)

So it would be idea to be able to reassign an ID to the game which would in turn affect the name of the Proton prefix folder name, as well as the name for the image files assigned to the game in Steam's frontend. Also, being able to return the AppID in the CLI would be helpful.

A pending question is, though - is the AppID generated for these games upon either adding game art or starting it with Proton, or does it already exist in a file other than shortcuts.vdf or config.vdf?

[sonic2kk]

Ah alright, I can see how this would be useful now.

SteamTinkerLaunch doesn't currently offer this and while I suppose we could look into it, there is an open issue here (#467) and upstream (tralph3/Steam-Metadata-Editor#18) to add Steam-Metadata-Editor integration into SteamTinkerLaunch, which I believe supports this.

So assuming Steam-Metadata-Editor supports this, I think for now it would be best to hold off on implementing this feature until we can integrate that project into SteamTinkerLaunch. If SME doesn't support this feature please get back to me and we can revisit implementing it!

If you need this feature now, I'm sorry STL can't provide it yet and I hope it doesn't come off as simply brushing your feature request aside - Basically I don't want to temporarily add a feature only to have it be removed and superseded, or perhaps even forgotten about and then we end up with unnecessarily duplicated functionality.

Hopefully in the meantime SME standalone can solve your use-case for now, while we wait for upstream to get back on the process of abstracting and integrating SME into SteamTInkerLaunch.

Thank you for your explanation and feel free to offer any further feedback. We can leave this issue open so we don't forget to implement and subsequently close this with SME integration in future.

[MattyXarope]

So I've taken a look at that program, and it likewise cannot edit Non-Steam game data. It has had an open issue (https://github.com/tralph3/Steam-Metadata-Editor/issues/3) since last year about adding support.

Steam-Metadata-Editor only edits the appinfo.vdf, which essentially makes it a GUI for some of the info that the CLI interface in STL has already implemented, although afaik STL edits the shortcuts.vdf file while that other program edits the appinfo.vdf.

For non-Steam games, at least in order to retrieve/return the AppID (which would be needed to even find the app), we would need to read config.vdf which is a non-binary vdf file - essentially meaning it's a JSON file that can be parsed and read.

[frostworx]

IIRC the steamapp ids for custom games are autogenerated and they even share their Id sometimes (for unknown reasons, likely depends on the proton version used). I'm afraid this feature can't be implemented. steamtinkerlaunch doesn't alter any steam files, but just reads them btw. leaving open for a while for possible further discussion

[MattyXarope]

IIRC the steamapp ids for custom games are autogenerated and they even share their Id sometimes (for unknown reasons, likely depends on the proton version used). I'm afraid this feature can't be implemented. steamtinkerlaunch doesn't alter any steam files, but just reads them btw. leaving open for a while for possible further discussion

I'd be surprised if they share wine prefixes or IDs - that would create issues.

While the editing of the ID may not be able to be implemented, I do think that simply returning the ID by reading the appropriate vdf is possible and would be really helpful for non-steam games.

[sonic2kk]

SteamTinkerLaunch has the command steamtinkerlaunch getid <gamename> but this doesn't seem to work correctly at all from my tests. Most games I tried return nothing, except for Half-Life which incorrectly returns 32 instead of 70.

I suspect this command would do what you're looking for, but for me at least it isn't working :sweat_smile:

EDIT: Doesn't seem to work for Non-Steam games but for regular Steam games, steamtinkerlaunch gettitle <appid> seems to return correctly. steamtinkerlaunch gettitle 70 correctly returns "Half-Life".

[sonic2kk]

So for Non-Steam games launched through Proton, their prefix is stored on $HOME/.local/share/Steam/steamapps/compatdata/<appid>, and their AppIDs tend to be really long.

I can't get Non-Steam games (Proton and Native Linux) to launch through SteamTinkerLaunch, and the issue might have something to do with the launch command. A section of interest from my steamtinkerlaunch.log when trying to launch a Non-Steam game with Proton:

Sat Aug 27 15:51:53 BST 2022 INFO - setProtonCmd - Prepending Proton 'experimental-7.0-20220826' (='/run/media/user/500GB SSD/Games/steamapps/common/Proton - Experimental/proton') to the command line '/run/media/user/500GB SSD/Non-Steam Games/HoloCure/HoloCure.exe'
Sat Aug 27 15:51:53 BST 2022 INFO - setProtonCmd - UPDATED game start command is: /run/media/user/500GB SSD/Non-Steam Games/HoloCure/HoloCure.exe
Sat Aug 27 15:51:53 BST 2022 INFO - setProtonCmd - Starting 'HoloCure (3020415623)' with Proton: 'experimental-7.0-20220826'
Sat Aug 27 15:51:53 BST 2022 INFO - launchSteamGame - Original incoming start command: ''
Sat Aug 27 15:51:53 BST 2022 INFO - launchSteamGame - Final outgoing start command: '/run/media/user/500GB SSD/Games/steamapps/common/Proton - Experimental/proton waitforexitandrun'
Sat Aug 27 15:51:53 BST 2022 INFO - loadCfg - '/home/user/.config/steamtinkerlaunch/meta/id/general/3020415623.conf' START
Sat Aug 27 15:51:53 BST 2022 INFO - loadCfg - '/home/user/.config/steamtinkerlaunch/meta/id/general/3020415623.conf' STOP
Sat Aug 27 15:51:53 BST 2022 INFO - startGame - Getting the Game Window name:
Sat Aug 27 15:51:53 BST 2022 INFO - getGameWindowName - No gamewindow name stored in metadata '/home/user/.config/steamtinkerlaunch/meta/id/general/3020415623.conf' yet. Trying to find it now
Sat Aug 27 15:51:53 BST 2022 INFO - startGame - Full start command is '/run/media/user/500GB SSD/Games/steamapps/common/Proton - Experimental/proton waitforexitandrun'
Sat Aug 27 15:51:53 BST 2022 INFO - startGame - ## ORIGINAL INCOMING LAUNCH COMMAND: ''
Sat Aug 27 15:51:53 BST 2022 INFO - startGame - ## STL LAUNCH COMMAND: '/run/media/user/500GB SSD/Games/steamapps/common/Proton - Experimental/proton waitforexitandrun'
Sat Aug 27 15:51:53 BST 2022 INFO - startGame - ## GAMESTART HERE ###
Sat Aug 27 15:51:53 BST 2022 INFO - restoreOrgVars - Restoring previously cleared Variables
Sat Aug 27 15:51:53 BST 2022 WAIT - getGameWindowPID - Sec 0/20 Game Window with pwd '/run/media/user/500GB SSD/Non-Steam Games/HoloCure' not yet in front
Sat Aug 27 15:51:54 BST 2022 WAIT - getGameWindowPID - Sec 1/20 Game Window with pwd '/run/media/user/500GB SSD/Non-Steam Games/HoloCure' not yet in front
Sat Aug 27 15:51:55 BST 2022 WAIT - getGameWindowPID - Sec 2/20 Game Window with pwd '/run/media/user/500GB SSD/Non-Steam Games/HoloCure' not yet in front
Sat Aug 27 15:51:56 BST 2022 WAIT - getGameWindowPID - Sec 3/20 Game Window with pwd '/run/media/user/500GB SSD/Non-Steam Games/HoloCure' not yet in front
Sat Aug 27 15:51:57 BST 2022 WAIT - getGameWindowPID - Sec 4/20 Game Window with pwd '/run/media/user/500GB SSD/Non-Steam Games/HoloCure' not yet in front
Sat Aug 27 15:51:58 BST 2022 WAIT - getGameWindowPID - Sec 5/20 Game Window with pwd '/run/media/user/500GB SSD/Non-Steam Games/HoloCure' not yet in front
Sat Aug 27 15:51:59 BST 2022 INFO - startGame - Symlink '/home/user/.config/steamtinkerlaunch/logs/gamelaunch/title/HoloCure.log' already exists
Sat Aug 27 15:51:59 BST 2022 INFO - startGame - ## GAMESTOP after '6' seconds playtime

What's really interesting here is that STL can see the game's (HoloCure) AppID: 3020415623. However the outgoing Proton command doesn't seem right to me?

Sat Aug 27 15:51:53 BST 2022 INFO - launchSteamGame - Final outgoing start command: '/run/media/user/500GB SSD/Games/steamapps/common/Proton - Experimental/proton waitforexitandrun'

It doesn't look like it appends anything related to the game executable and just tries to run Proton Experimental? I could be wrong, but I wanted to share the lines of interest from my log.

[MattyXarope]

While the AppID can be seen as the prefix folder name from $HOME/.local/share/Steam/steamapps/compatdata/<appid>, it is also stored within the non-binary config.vdf file where it is associated with the compatibility tool associated with it in Steam.

I did not know about steamtinkerlaunch getid <gamename>, thanks for that info. It makes sense that it won't work for non-steam games, however, as it is pulling from shortcuts.vdf (afaik) and not config.vdf.

I'm a bit busy today but I'll try and inspect the log you provided tonight.

Also, @frostworx , I'm confused when you say "Steamtinkerlaunch doesn't alter any steam files" when the CLI interface edits the shortcuts.vdf file, no?

[sonic2kk]

Another quick note: Adding a Non-Steam Game, then removing it and then adding it again to Steam, generates two different AppIDs.

Earlier today, HoloCure was 3020415623. Today after adding it again for some testing, it's 2468522275. The original compatdata directory is still there at $HOME/.local/share/Steam/steamapps/compatdata/3020415623.

I would imagine then that this means if you attempt to configure a Non-Steam Game with STL, then later remove and re-add it, that STL won't track the configuration files and also that any information that might be stored in the Proton prefix will be lost (this issue is unrelated to STL though). Probably this is something we can eventually note on the wiki, though there are a few issues with STL and Non-Steam Games which should be ironed out before we go making any wiki changes :)

@MattyXarope This may be relevant to your question earlier:

A pending question is, though - is the AppID generated for these games upon either adding game art or starting it with Proton, or does it already exist in a file other than shortcuts.vdf or config.vdf?

It might be generated when the game runs with Proton.

[MattyXarope]

Another quick note: Adding a Non-Steam Game, then removing it and then adding it again to Steam, generates two different AppIDs.

Earlier today, HoloCure was 3020415623. Today after adding it again for some testing, it's 2468522275. The original compatdata directory is still there at $HOME/.local/share/Steam/steamapps/compatdata/3020415623.

I would imagine then that this means if you attempt to configure a Non-Steam Game with STL, then later remove and re-add it, that STL won't track the configuration files and also that any information that might be stored in the Proton prefix will be lost (this issue is unrelated to STL though). Probably this is something we can eventually note on the wiki, though there are a few issues with STL and Non-Steam Games which should be ironed out before we go making any wiki changes :)

@MattyXarope This may be relevant to your question earlier:

A pending question is, though - is the AppID generated for these games upon either adding game art or starting it with Proton, or does it already exist in a file other than shortcuts.vdf or config.vdf?

It might be generated when the game runs with Proton.

Yeah, unfortunately they do change when added again, but at the least that could be done is being able to call the ID that is in place at the time.

Also, you can add a non-steam game and then add game art to it through Steam, and it will generate an ID in .\Steam\userdata\<id3>\config\grid\, so it's not only related to running the game, though I don't know if that generated ID is held anywhere after adding game art and not running using a compat tool.

[sonic2kk]

Thanks for the information! I have no real clue about AppIDs so all information here is very much appreciated :+1:

I was able to fix Non-Steam Proton games running, by changing the line 16765 to include GAMESTARTCMD[*]: PROTSTARTCMD=("${RUNPROTON//\"/}" "$WFEAR" "${GAMESTARTCMD[*]}")

I have yet to test regular Proton games though, just wanted to chime in that this fixed it. If this is a stable fix I'll get a PR up.

EDIT: The fix seems stable. PR incoming...

[MattyXarope]

Thanks for the information! I have no real clue about AppIDs so all information here is very much appreciated 👍

I was able to fix Non-Steam Proton games running, by changing the line 16765 to include GAMESTARTCMD[*]: PROTSTARTCMD=("${RUNPROTON//\"/}" "$WFEAR" "${GAMESTARTCMD[*]}")

I have yet to test regular Proton games though, just wanted to chime in that this fixed it. If this is a stable fix I'll get a PR up.

EDIT: The fix seems stable. PR incoming...

Thanks! Definitely one step in the right direction. How does this command deal with the specific Proton version used? Does it have to be assigned beforehand or Is it possible to pass an argument to run it with a certain version?

If this works, it means STL can launch the game, which will generate the AppID in the compatdata folder, and also update the config.vdf file.

Now we just have to figure out a way to fix the steamtinkerlaunch getid <gamename> to read the config.vdf to return the ID.

Edit: Actually, I'm realizing that the config.vdf only contains the AppID and the Proton version associated with the game - I'm not sure where else those AppIDs are held for non-steam games. I'll have to dig deeper.

[sonic2kk]

Thanks! Definitely one step in the right direction. How does this command deal with the specific Proton version used? Does it have to be assigned beforehand or Is it possible to pass an argument to run it with a certain version?

From my understanding (and Frostworx can correct me if I'm wrong) by looking at the code and the logs, it has RUNPROTON which knows which Proton version to run the game with, the one set in the Game Menu:

This selected version then, in this Non-Steam Proton path to launch at least, prepended onto the path to the Proton version selected. In-between the path to the selected Proton version and the game executable, there is a waitforexitandrun command, which I'm not too sure what it does but it's something compatibility tools need as far as I know.

So if you tried to run your game with GE-Proton7-30, the actual game launch command that gets executed would look like: /home/gaben/.local/share/Steam/compatibilitytools.d/GE-Proton7-30 waitforexitandrun /home/gaben/Non-Steam Games/Dungeon Keeper 2/DKII-DX.exe.

If this works, it means STL can launch the game, which will generate the AppID in the compatdata folder, and also update the config.vdf file.

Yup, that should work once the PR is merged. At least in my tests that's what happens with Non-Steam Games.

Now we just have to figure out a way to fix the steamtinkerlaunch getid to read the config.vdf to return the ID.

Indeed, the code for that is in the aptly titled getIDFromTitle function. Though I'm not entirely sure how it works yet.

[sonic2kk]

Okay so getIDFromTitle seems like it looks in ~/.config/steamtinkerlaunch/meta/, which has a list of metadata about games launched with SteamTinkerLaunch (but only games launched with SteamTinkerLaunch?). It searches for files with a matching GAMENAME= line in their file I think?

As an aside, in this meta folder, there is a general and custom folder - in meta/id/custom and meta/title/custom, which symlinks the conf files using the game's actual title so you can more easily see which file corresponds to which game. The custom folder has less files than the general folder and most of the files just hold the wine prefix path and another path. But this custom folder also has files for Non-Steam Games with correctly listed AppIDs. So the AppIDs and Game Titles are associated somewhere in STL but the function to search for a game's AppID with its title seems to not work.

Since Half-Life was the only game returning anything for me with steamtinkerlaunch getid, I opened the file to see what it had. And it has a GAMEARCH="32" line. Right above it is the AppID, with GAMEID.

However there are a couple of problems:

• Some meta files, seemingly only native-Linux ones, don't have a GAMEID line (I ran Half-Life with STL only once and as a compatibility tool to test it through Proton, that might be why it has the AppID)
• I found a game that had the same kind of variables as Half-Life did: Oblivion. It has the GAMEID line, but trying to search for it doesn't work either. It doesn't return any value.

So it seems however the AppID is searched for by title is wrong, and that even if it does, not all files have the AppID. That's strange though, because STL is able to correctly generate these metadata files with the correct AppID as the title.

Maybe the function itself to search for games' AppIDs by title needs an overhaul?

[frostworx]

I haven't read the whole discussion, but yes, reading any data from the self-created meta data files was added relative late and is not integrated very deeply. therefore I would not call it a reliable source. functions like steamtinkerlaunch getid are closer to a side-effect of some other intended implementation than a standalone working function. Can't think of any serious function which relies on it and I doubt that it is heavily used by anybody and therefore never enhanced/removed it. apart from that I'd guess https://github.com/frostworx/steamtinkerlaunch/issues/550#issuecomment-1227456500 is still valid (haven't installed any non-steam games for a while, but I doubt anybody is working on that dead end on Valve's side), but happy tinkering in any case.

[frostworx]

Just took a look into the old add non steam code because of @sonic2kk's PR and STL actually already creates a random AppID for the added non-steam game. Totally forgot about it... 🙄 And yes, @MattyXarope - the shortcuts.vdf is of course written by steamtinkerlaunch (for obvious reasons) Either way I indeed had the situation in the past where 2 non-steam games shared a compatdata path (not steamtinkerlaunch related). Maybe it was just a temporary glitch no idea, I rarely add any non-steam games.

[frostworx]

There is no obvious reason to keep this open, is it?

[sonic2kk]

If there's no way to set a custom AppID for Non-Steam games, maybe not. It's a nice idea but I don't know what would be needed for it

[frostworx]

Ah, ic - the idea was to actually CHANGE an existing appid to a different one or defining an own appid manually(instead of adding a function which auto-creates an appid automatically, which already exists) Sorry for the confusion, I'm short of time...

Well, yes, it should be possible to A) add an "enter appid to be uses field" (instead of creating the NOSTAIDHX which is currently used) and B) it should also be possible to add a function which replaces the existing appid of a non-steam game with a new one. I'm not convinced if the effort required to add any is worth the result. Also B might lead to follow-up problems, which makes the benefit even more questionable imho. I wouldn't mind merging a proper PR if the author would also support corresponding possibly upcoming issues, but personally I would not work on this.

[sonic2kk]

Information on Steam shortcut AppIDs seems sparse at best, and even implementations I've seen in Python for generating them don't seem to work anymore. The only program I can see which is able to properly generate the AppIDs is Steam ROM Manager (see my comments in #576).

Note the word generate, as far as I can tell Steam generates AppIDs for Non-Steam games and you can't actually set them? It also seems like each time you add a Non-Steam game to Steam that this ID changes. I have absolutely no idea how Steam ROM Manager gets it, I can see the code where they generate it but I can't find out how they use this. Do they generate it using these functions and then set this as the AppID, or do they use this to get the same AppID that Steam generates?

If they use these functions to generate an AppID that they set themselves (meaning they tell Steam what AppID they want, not that they try to generate the same one Steam uses), then it looks like the request in this PR could work.

If they use this to generate the same AppID that Steam itself generates internally for each shortcut, then we might be in a stickier situation.

Basically we need to figure out how AppIDs for Non-Steam games work. How do we get them first of all, and is it possible to set them, and if so, where?

---

@MattyXarope For what it's worth, in STl-GIt you should now be able to get the AppID of Non-Steam Games launches through SteamTinkerLaunch at least once. It rips this ID from the meta file that SteamTinkerLaunch generates. If you've added the shortcut twice and launched it twice with STL, it'll show two AppIDs since as discussed earlier here, new AppIDs are generated each time the shortcut is added to Steam (unrelated to SteamTinkerLaunch).

Example:

[paintballkev812]

It looks like non steam appids are generated using the path and shortcut name. See Here

EDIT: It looks like SteamGridDB uses the same logic. (Here)

[sonic2kk]

Indeed, and I've tried replicating this in Bash, but it never seems to match what Steam generates.

Below is the Bash script I wrote, with quite a lot of the code borrowed from SteamTinkerLaunch code (replace the variables with your game paths ofc :)):

function getCRC {
    echo -n "$1" | gzip -c | tail -c 8 | od -An -N 4 -tx4
}

function dec2hex {
        printf '%x\n' "$1"
}

function hex2dec {
    printf "%d\n" "0x${1#0x}"
}

function getAppID {
    ID="$1$2"
    CRC="$( getCRC "$1$2" )"
    DECCRC="$( hex2dec $CRC )"

    echo "$((DECCRC | 0x80000000 ))"
}

gamepath=""
gamename=""

bigint=2**32

appid="$(( $( getAppID "/path/to/Game.exe" "Game" ) >> $bigint ))"
echo "$appid"

Below is Python code which is also meant to generate the AppID (taken from StackOverflow). In my tests, this matches the Bash script, but does not match Steam:

import binascii

def get_steam_shortcut_id(exe, appname):
    """Get id for non-steam shortcut.

    get_steam_shortcut_id(str, str) -> int
    """
    grid = Path(f"{steam_path}/userdata/{steamid}/config/grid")
    unique_id = ''.join([exe, appname])
    id_int = binascii.crc32(str.encode(unique_id)) | 0x80000000
    return id_int

In my tests for my game, both of these generate 3620140177, and Steam currently holds 3470731288. When added originally, Steam held the ID 2468522275 (the game name and path never changed).

When you re-add Non-Steam games, the AppID even seems to change. I've no idea how SteamGridDB and Steam ROM Manager are able to get it consistent.

The fact that these two projects (afaik maintained by the same or closely related teams) are able to do this makes me suspect that perhaps they are able to actually set the ID. Like they generate this ID and then tell Steam to use it. I have no idea if that's true and can't find anything to back it up. Really I should just bite the bullet and try to test this TypeScript code myself to see...

And also in case there's any doubt, I've personally verified that Steam ROM Manager sets these correctly, because it's able to set my game art with EmuDeck on Steam Deck.

[sonic2kk]

So I tested the TypeScript that Steam-ROM-Manager uses and... it returns the exact same thing as my Bash code and as the Python code returns. :shrug:

I have no idea why the one that Steam stores is different or why it changes but this is really strange. You can test this either locally if you have a TypeScript/NodeJS environment set up (you'll need to run npm install crc), or you can test online on somewhere like Replit (that's where I tested).

---

From what I understand however, it seems like you can't set AppIDs manually for Non-Steam games. To go back to the original comment:

So it would be idea to be able to reassign an ID to the game which would in turn affect the name of the Proton prefix folder name, as well as the name for the image files assigned to the game in Steam's frontend.

While I think this would be a nice feature, to my current understanding this cannot be done. Please, please correct me on this if I am wrong, I read through the existing discussion and nothing stood out to me to imply it was possible, but that OP was asking if SteamTinkerLaunch can do this without implying there was any existing way of doing this.

Steam-ROM-Manager has a function to generate an AppID for use in the shortcuts.vdf file which was mentioned earlier, as well as functions to generate other AppIDs. Given this and another StackOverflow answer I found before which I believe I have linked earlier, the way I understand it is that Steam does not offer a mechanism to set these AppIDs. The closest STL could get would be to create a symlink with a custom AppID but this would probably only work for Proton games and I'm not sure of the benefit it provides. I think the initial idea was that implementing this would make it easier to find Non-Steam Games (also called "Steam Shortcuts", if you're doing any research this seems to turn up more results!) but as of very recently this is now possible with the getid function. Therefore...

Also, being able to return the AppID in the CLI would be helpful.

This part of the issue is solved! :smile:

A pending question is, though - is the AppID generated for these games upon either adding game art or starting it with Proton, or does it already exist in a file other than shortcuts.vdf or config.vdf?

This is one thing I haven't been able to find confirmation on. It is possible that the AppID is generated based on the exe and such that is passed to the shortcuts.vdf file, but I haven't been able to confirm this. I'll need to look into this but I don't think it's possible to really set a custom AppID, but rather the AppID is generated based on the exe and appname fields passed to shortcuts.vdf if that makes sense.

There are still some unanswered questions around why does the shortcut AppID change, but I guess that's for further investigation :smile:

[sonic2kk]

It seems like somehow, Depressurizer can do this. No idea how, though.

[sonic2kk]

I can't work out how Depressurizer does it, but SteamGrid (written in Go, which I don't know :sweat_smile:) seems like it just... reads it from the shortcuts.vdf? (https://github.com/boppreh/steamgrid/blob/master/games.go#L100-L137).

Maybe it's just because I can't read Go but it seems like this project also either reads or generates the AppID that Steam uses and does not offer the ability to set a custom AppID for shortcuts. Therefore I am still under the impression that this is not possible.

[sonic2kk]

Okay, so I did a little test and found that when a game is launched, shortcuts.vdf is updated and the AppID is changed. I can't actually read the AppID because shortcuts.vdf is in a binary VDF format (though it seems someone recently wrote a parser in Go for this: https://github.com/TimDeve/valve-vdf-binary).

But I wonder how the shortcuts file generates this AppID. It definitely changes it from what STL sets (which makes sense since STL generates it randomly). I guess the AppID is set for the shortcut when launched though.

Wow so when you add a Non-Steam game to Steam, it sets an AppID, but when you launch a game it changes. What the heck!

---

Found a commit to Steam-ROM-Manager where more work was done on shortcut AppIDs: https://github.com/SteamGridDB/steam-rom-manager/commit/dc8500ebe7df467f310b1d36fbc93b44494169be

This commt is where all the ShortAppID stuff was added.

[sonic2kk]

I'm not sure if this is possible and there has been no real update from OP (things happen, no hard feelings, just keeping the issue tracker tidy) :smiley: so I'm going to close this. Please feel free to reopen if you have any further information to add (OP or otherwise).