⚠️ SteamTinkerLaunch v14.0 Feature Roadmap

[sonic2kk]

NOTE: YOU SHOULD ALWAYS BE USING THE LATEST STEAMTINKERLAUNCH COMMIT FROM MASTER, EVEN IF A NEW RELEASE COMES OUT. DO NOT STAY ON RELEASES UNLESS YOU HAVE GOOD REASON TO DO SO.

System Information

• SteamTinkerLaunch version: git
• Distribution: Arch Linux

Feature Description

This issue will outline the features I want to complete before I release SteamTinkerLaunch v14.0. A lot of work has already been done since the previous release, this is mainly just tying up the loose in-development ends. Some initiatives like improving SteamGridDB support are mostly complete but just need a couple of tweaks before it's in a complete state and ready to release.

My time (and motivation, honestly) are limited right now so it will likely not be released this year, even if all these features were completed I plan to take a break soon into the New Year, and I don't want to make a release while I am not around to deal with the potential uptick in issues (especially disrespectful issues).

Some of these features are ones that have been in development for a little while and just need a bit of polish. Others are ones that I would be happy simply investigating and documenting how to implement at a high level to work on after v14.0. Community contribution on any of these would be welcome, please drop a note here or on the issues themselves asking to contribute.

Refer to the issues themselves for the most detailed information on implementation and current progress.

This list may not be complete, if a high-priority item comes in I may update this list, but since this is not a hard-and-fast roadmap and its completion does not mandate an immediate release, bug reports and minor feature requests can be reviewed and may be included in v14.0 as well.

Bugs and feature requests will not be ignored and this is not a priority effort, this is just a rough idea of the issues I want to address before gearing up for a release.

Must-Haves

These issues are ones that must be completed before v14.0 can release. The main priority, in my mind, is finishing up #934, #949, and #960.

SteamGridDB Overhaul (#934) ✔️

The SteamGridDB Overhaul is complete.

The core of this issue was to allow fetching several different kinds of artworks from SteamGridDB and to attach them to both Steam and Non-Steam Games, via the commandline. Before, we would only be able to set grid (boxart) artwork, but this issue detailed many improvements.

Most of this is complete, a GUI frontend for the commandline option is the main remaining piece of work to close this issue. The bulk of this work was already completed in the PRs linked to that issue.

Non-Steam Game Overhaul (#960)

This issue dealt with getting Non-Steam Games some handy features, such as incorporating support for them into the various getpath/getexe/getid commands. Significant work was done to implement utility functions to parse the shortcuts.vdf, and a lot of time was spent researching how Steam stores this information (a large part of this was actually generating the Non-Steam Game AppID properly).

Once again, a lot of this is complete. Primarily we need to fix how we write out the OpenVR and Steam Overlay options. This has to be stored in the shortcuts.vdf entry, but Steam reads it from localconfig.vdf. We have functions to interact with text-based VDF files, including many more to read and write out values, so the main remaining bit of work is to create the relevant sections in localconfig.vdf if they don't exist, in order to correctly insert the sections into when creating the shortcut entry.

We also need to fix writing out the "Hidden" option and "Favorite" option. In the past, Steam stored these as tags in the shortcuts.vdf entry. While it still does store them, it does not read them anymore and instead takes it from a LevelDB file. Hidden and Favorite are stored internally by Steam as categories/collections, so we have to add the Non-Steam Game AppID to the list of Steam Collections. Then the Non-Steam Game AppIDs (the 32bit unsigned integers) are stored in a stringified JSON block in localconfig.vdf called user-collections. The section this is stored in will always exist, so we just need to do the following:

• If no user-collections, generate a blank one with Hidden/Favorite specified
• If we have a user-collections, either update it to include a Hidden/Favorite section if the user does not have any games in these collections, or create the JSON object for this collection with the relevant AppID information

Getting the name of the Hidden/Favorite category can be done with a C++ tool I created which I'll talk about below.

Fix Non-Steam Game Collections (#949)

In the past, Steam stored information about which Non-Steam Games were part of which collections using the tags section of the entry in shortcuts.vdf. While this section still needs to be written out, Steam doesn't read from it anymore, and stores this information in a LevelDB. The internal names are stored as JSON objects in localconfig.vdf, inside a stringified JSON called user-collections.

To fix this issue, we need to write out or update an existing entry in the stringified user-collections to either add a new JSON object representing that collection, or update an existing object to include our new Non-Steam AppID.

The internal names of collections can vary; pre-library update collections are named from-tag-tagname, and new ones use LevelDB key names, which cannot be reverse engineered, such as uc-ds45+35ffd. To overcome this, I created a C++ program that uses the LevelDB library to parse the Steam LevelDB file called DumpSteamCollections (the readme has example usage). It compiles down to about 40kb but depends on LevelDB being installed, and this is not available on SteamOS.

To resolve the issue of LevelDB being required, I would like to create an AppImage which I could release on DumpSteamCollection's project releases, which would have the executable and LevelDB installed. Then STL can simply execute it and get the information it needs. This would be a great way to include the project as a dependency without adding a Google dependency (LevelDB) or having to juggle yet another Steam Deck dependency. It would be one executable we could download and run.

A nice way to help with this issue would be to offer guidance on how to package an AppImage for that project, if you are able! Otherwise, some proof-of-concept code is commented out and available for reference under the "debug" command in the script, you can refer to this to get some ideas of how to re-use existing functions and jq to implement this feature, though significant work is likely required to adapt it to work in all the possible constellations, it mainly covers a happy path.

Nice-To-Haves

These are issues that I would like to fix, implement, or at least research and document how to approach them/what causes them before v14.0 is released. They may not make it, or they may not be possible to implement.

These are lower priority issues that probably won't hold up a release, but the ones I want to resolve the most are #913 and #968.

Game Oddities with SteamTinkerLaunch (#913, #968)

Recently, a user has been extremely helpful in diagnosing rather obscure STL issues with some constellations of launch options. A huge amount of these have been fixed thanks to this user and their engagement, but a couple have not had much progress.

Mainly, there are issues with one game using STL, and issues saving one game with STL (FFXII). Despite thorough testing and investigation I have been unable to resolve these, but I would like a clean resolution to them before v14.0 comes out. This is probably the highest priority, as I have spent a lot of time investigating the issues and would love to figure out the problem before the next release.

If you own the games mentioned in the issue, please feel free to try and fix the problem, but please don't piggyback on the issue and simply re-confirm the issue with no additional context. I am looking for troubleshooting contributions, ways to reproduce the issue, diagnosing the problem, or best of all, a PR with a fix!

Custom DXVK Versions & LatencyFleX (#794, #872)

This one may not be possible, but I would like to investigate and document the feasibility of this feature. It does not have to be implemented and likely will not be implemented before v14.0, but I would like to figure out how possible it is.

The way a user is meant to do this manually is to explicitly update DLLs in a Proton version's files -- NOT the game prefix, as Proton will overwrite these with its own DLLs! To work around this, I considered a possibility of basically creating a symlink clone of a Proton version that the user has selected, and replacing any symlinked files that we want to overwrite (such as DXVK DLLs) with actual files. That way we don't end up having to either override Proton files (which would be messy) or duplicate an entire Proton version to achieve this (which would be costly in terms of space).

There are a lot of things to consider for implementation details, such as generically allowing to override specific DLLs, rolling back and restoring symlinked files only (likely have to remove the Proton version and then re-create the symlink clone, and re-apply the DLL file overwrites that we do want and skip the ones we want to roll back). But for now I would be happy to just investigate if this kind of approach would work. Please feel free to test and offer code snippets on the relevant issue (probably #872 is the most appropriate)

These two issues are tied because allowing overriding the DXVK DLLs to change the version would solve a significant part of the LatencyFleX request, since it has similar steps involved.

If there is another approach to this which I have not considered that would also be good to discuss as well, though on the relevant issue(s) please!

Use Steam Linux Runtime with Winetricks (#860)

Straightforward enough, I want a checkbox on the Global Menu that would specify to use the Steam Linux Runtime with Winetricks. This would do two things:

• Force a local Winetricks download to the STL downloads folder (the SLR can't access /usr/bin/winetricks), so in our function to check the Winetricks version we will have to take this option into consideration.
  • If Download Winetricks is enabled, we don't need to concern ourselves with this as a local version will be in use anyway
  • When the SLR option is disabled we should correctly fall back to the standard Winetricks version (the STL check should handle finding this, we basically want to go back to our current functionality without this feature when it's turned off while ensuring it works as expected when on and when used in conjunction with an explicit "Download Winetricks", and ensuring that "Download Winetricks" still works when this option is off)
• Wrap our Winetricks commands in the relevant Steam Linux Runtime for that Proton version.
• Ignore native games' Steam Linux Runtime version, and Winetricks isn't relevant for them anyway.
• Gracefully handle/notify/log a missing SLR, and fall back to simply not using the SLR if it's not available (we use getSLRReap to get the SLR, and if it's -z, we can assume not found and run Winetricks normally).

The benefit of this is compatibility, as Proton is built against and meant to be used with the libraries in the Steam Linux Runtime it targets. This may help resolve things like dotnet48 not installing for HMM as well, but not sure.

This option should be off by default.

Back to Default Option (#939)

A way to revert config files back to default would be useful. I am considering both a commandline and a GUI option. The STL pattern is to implement a command first, and then the GUI hooks into it.

The "Game Files" dialog could be used for this, to have a "Default" button along the bottom of the window that a user can click to reset selected files back to default.

Why Another Release?

SteamTinkerLaunch has not had a release in a long time, and intentionally so. I figured since I don't actually backport fixes to versions or anything like that they were nothing more than "development checkpoints". Further, users would be swayed from testing the latest development versions and would simply default to using the latest release.

Things have changed now though. A significant amount of downstream projects now package SteamTinkerLaunch (Garuda, Bazzite, Nobara has it in their repos, among others) and to my knowledge only package the latest stable. On this, some package managers don't offer the latest git. It can be messy trying to update STL or remove it from the system and replace it with a git release in these cases. And unfortunately, many users have still opted to go for a stable release, despite it being many months old, and do not even consider trying a git build, so the hope that giving up on releases would sway users to actually use the latest version and engage in the project's development were not successful, and has ended up creating duplicate issues.

For these reasons primarily, I have decided I will make another SteamTinkerLaunch release eventually, and because of downstream dependency, will likely make more in the future. I try to be transparent with the development of this project, and hope this issue serves as additional transparency.

---

I expect a new release to come around mid next year, and if half of the issues discussed here can get attention, I'll be very happy.

[Globetrotter129]

Nice to have reshade 3d working on all my games 😁

[sonic2kk]

The SteamGridDB Integration Overhaul (#934) is now complete.

[this-is-just-con-tribute]

NOTE: YOU SHOULD ALWAYS BE USING THE LATEST STEAMTINKERLAUNCH COMMIT FROM MASTER, EVEN IF A NEW RELEASE COMES OUT. DO NOT STAY ON RELEASES UNLESS YOU HAVE GOOD REASON TO DO SO.

Yet the front page doesn't say anything about that. Why isn't this on the front page?