Your system information

• Steam client version (build number or date): 1682708537
• Distribution (e.g. Ubuntu): Arch Linux
• Opted into Steam client beta?: [Yes/No] No
• Have you checked for system updates?: [Yes/No] Yes

Please describe your issue in as much detail as possible:

This is essentially a client issue, but I wasn't sure where to file this exactly, since it relates more to how third-party launchers interact with the Steam client. Since Valve has shown itself to be amenable to third-party launchers insofar as they drive users back to Steam and in terms of how they relate to the wider open-source ecosystem, I hope this topic is considered fair game.

In brief: when creating shortcuts to non-Steam games (NSGs) in the client (Stable or Beta), the metadata is written to shortcuts.vdf.

This can be parsed to obtain the canonical AppID (a randomized appid in a range reserved for NSGs) and the Big Picture shortcut id (BPID; used by the Valve browser protocol to launch the shortcut via, e.g, a .desktop shortcut).

Without elaborating the logic, it used to be possible to, using this file, calculate (albeit in a convoluted fashion) both the AppID and BPID a priori and use this to construct launch parameters for NSGs in the form of steam://rungameid/<BPID>.

Until recently, the BPID was a well-defined value that could be repeatably calculated. A recent update has changed this such that the BPID changes in an ad-hoc fashion every time a NSG is added, even if the absolute path and executable name are identical.

This has broken functionality in a wide range of third-party launchers that provide an interface over Steam to launch, among other things, Steam apps and NSGs. Native Steam apps have their own reserved browser protocol and can be launched as before, but because the rungameid protocol is reserved for NSGs and the BPID cannot be calculated ahead of time, there is no way to parse this without manual intervention:

A. Manually create desktop shortcuts via the right-click menu and inspect the contents of the Exe= line
B. Run the NSG at least once and inspect the contents of screenshots.vdf for recent entries

Method A is obviously quite fiddly, and method B is unreliable due to the propensity for collisions and the need to run each NSG first. As a result, there is no programmatic method of preparing a list of launch commands for all NSGs in a user's library.

According to comments by TTimo in #9237, the AppID (not the BPID) is in a randomized range reserved for NSGs, so it cannot overlap with the AppID of a Steam app itself. If this is the case, presumably the steam//launch protocol, rather than the rungameid protocol, could be updated to support these unique NSG AppIDs rather than relying on the more obscure BPID. Since the AppID to a given NSG can be repeatably obtained, this would provide a means of programmatically launching the NSGs unique to a given Steam installation.

Unlike the BPID, the AppID to NSGs is not an obfuscated value, either, being widely visible in other parts of the application and in logs when launching NSGs. (For that matter, the BPID is not exactly an obfuscated value insofar as it becomes immediately available in screenshots.vdf once the NSG is launched). Obviously it is Valve's prerogative to calculate these IDs via some undisclosed method, but exposing a better API for handling NSGs would allow a wide range of third-party utilities to request Steam to launch NSGs. Currently, all game library "managers" large and small, as well as an assortment of other utilities, have had to drop support for NSGs or, unaware of this change, have left it functionally broken.

Alternatively, some facility for extracting the new BPID format would help bridge this current limitation between third-party utilities and the Steam client.