Closed cchulo closed 9 months ago
Good catch! Sorry you ran into that. The good news is I have some ideas on the problem. The tl;dr: the AppID we're creating is probably not unique enough as I can reproduce the issue if I have similar names and/or paths, but not if they are sufficiently unique, which they seem to have been in testing up to this point. I have some ideas on generating a more unique AppID, and I'll try to push it later today.
I suspect we're not generating unique enough AppIDs and something is going wrong. An AppID is a unique identifier for a game on Steam. Games on the store have a fixed AppID, but Non-Steam Games can have any AppID so long as the format is correct. The format is most likely correct, as this has worked in my and others' testing, but if the AppID is not unique then Steam will do weird things. I confirmed that the AppID that STL generates is not always unique.
I can re-create the problem if I use similar app names and paths: "Test Game 1" and "Test Game 2", in mostly the same path but with one or two directories different at the end, give the same AppID. So I suspect games in your /home/user/Games
path, or even "Biohazard 2" and "Biohazard 3" could cause this issue.
I agree with you that it looks like it should have succeeded, however if AppIDs are the same, there will be a conflict and so the compatibility tool will be set incorrectly. In my tests up to this point, I guess the paths have all been sufficiently different so it has worked. Adding "Test Game 1" worked and set the compat tool, but "Test Game 2" generated the same AppID, and partially caused a conflict that Steam probably wouldn't fully resolve until the game launched, so the compat tool was not set.
I have some ideas for how to generate a random number from a seed better, using an md5 hash, so I'll work on this hopefully later tonight. It should preserve the AppID being the same when the name is the same (so prior artwork/compat tools can be preserved) but also ensure the AppID is unique at least among games added by SteamTinkerLaunch and when the name and EXE path are unique. It is conceivable that with enough shortcuts, there could be overlap, but we're talking about millions of shortcuts :sweat_smile:
Unfortunately, you will need to re-add your Non-Steam Games, though hopefully removing it from Steam (optional, just keeps the library cleaner) and re-running the command you posted should result in things working, once I get the fix up. This kind of commandline usage is the kind of use-case I envisioned for ansg
, so it is important to me that it works. It seems like it isn't totally broken at least from my tests, and hopefully making some changes to ensure the AppID is unique will work.
As a heads-up, though you may already know, if you have your artwork in the same folder as the exe and you name them hero
, logo
, boxart
, tenfoot
, then you should be able to use --auto-artwork
to pick them up automatically instead of passing the paths explicitly. Though this is probably not going to work so good since setting artwork relies on the AppID, so probably best not to try it out much until I can get the fix up. It's also not very important, and you may already know this as based on your usage it seems like you actually read the wiki, it was just a small heads-up in case it helps you :-)
If you need to bulk-remove shortcuts, ProtonUp-Qt from git has a shortcut editor which you can access from the games list.
Though I'm very confident this is the issue, if you're interested, you could try to verify this: You can check your ~/.local/share/Steam/config/config.vdf
file, look for AppID 3980761242
in a block like this under the CompatToolMapping
section (though it will be indented more):
"3381908488"
{
"name" "GE-Proton8-16"
"config" ""
"priority" "250"
}
Then in Steam, from the Properties dialog, edit the compatibility tool for your Biohazard shortcut, and then go back to your config.vdf
and refresh. Steam should have created or updated a different entry to the one above.
Steam uses this to map what games (by AppID) are using which compatibility tool. If you see a block below it or a different block somewhere else being updated, then this means STL is inserting the block correctly, but since the AppID that STL creates is not unique, it is not reading this compatibility tool mapping entry.
Thanks!
2be16b3c186b6b6218324c1f02c0c24898965fd1 contains the updated AppID generation code, let me know if that resolves the issues for you :-)
I try to be fast when investigating problems but I'll be out for a bit tonight so the issue may persist for a while longer if the above commit didn't fix it. But hopefully that fixes it, in my tests the AppIDs are always unique and the cases before where I could reproduce the AppID overlap (my suspected root cause of this issue) were fixed by this commit.
wow thank you very much for the speedy turn-around on this, wasn't expecting it! :) will check it out
@sonic2kk it seems to work, but its a bit weird
I readded it and it was assigned 3449158112
I found that it still had not set the GE version. I added it manually again. Saw that config.vdf assigned it correctly to 3449158112
. I removed the game, reran the same command, and it was once again readded but the GE version was correctly set. So it now "permanently" works, with just that quirk.
attached additional log above in the OP
It might be working because this entry is now in my config.vdf permanently, it does not get cleaned up automatically after removing the non-steam game:
Side note, i kinda like how the random number generation is deterministic, not sure if that was a feature before
The other thing I'm noticing is this file is edited/generated every time steam launches, so it might be getting information for what to set compatibilitytool elsewhere :\
I readded it and it was assigned 3449158112 I found that it still had not set the GE version. I added it manually again. Saw that config.vdf assigned it correctly to 3449158112. I removed the game, reran the same command, and it was once again readded but the GE version was correctly set. So it now "permanently" works, with just that quirk.
At least there is a little bit of good news here :-) But that is a very odd quirk.
The other thing I'm noticing is this file is edited/generated every time steam launches, so it might be getting information for what to set compatibilitytool elsewhere :\
It is editing it because there are a lot of things in this file, and I don't think this file is being edited because other tools like ProtonUp-Qt edit this file to update the compatibility tool in use by a game, as well as for the bulk-update feature. It could have changed recently I suppose, but I think this file is working.
You can check if it works by renaming GE-Proton8-19
to a different tool, making sure to use the tool's internal name (i.e. proton_8
for vanilla Proton 8 may be a good one to test with).
Steam does seem to look elsewhere than config.vdf
and shortcuts.vdf
though fwiw so the idea isn't too far fetched. For example, although it sets collections as tags
in shortcuts.vdf
, Steam does not read from this file, and it isn't clear where it reads it from for Non-Steam Games other than it seems to use a different location than regular Steam games (#949).
It might be working because this entry is now in my config.vdf permanently, it does not get cleaned up automatically after removing the non-steam game:
This is also odd... I thought Steam was meant to clean this up when you remove the entry from Steam. I'll test this now in fact.
If you remove this entry from your config.vdf
, save it, and then re-add your game with the same parameters:
And on a related note, can you reproduce this behaviour generally? I will also test this from my side :-)
If we can't reproduce the issue again I'm willing to chalk it up to some weirdness and leave it be.
attached additional log above in the OP
Thank you! It all looks like it should be set properly from the logging:
Tue Oct 31 07:57:48 AM PDT 2023 INFO - addNonSteamGame - Adding selected compatibility tool 'GE-Proton8-19' for Non-Stteam Game
Tue Oct 31 07:57:48 AM PDT 2023 INFO - getVdfSection - Searching for VDF block with name '"CompatToolMapping"' in VDF file '/home/cchulo/.local/share/Steam/config/config.vdf'
Tue Oct 31 07:57:48 AM PDT 2023 INFO - getVdfSection - Searching for VDF block with name '"3449158112"' in VDF file '/tmp/tmp.vdf'
Tue Oct 31 07:57:48 AM PDT 2023 INFO - createVdfEntry - Creating VDF data block to append to '"CompatToolMapping"'
Tue Oct 31 07:57:48 AM PDT 2023 INFO - getVdfSection - Searching for VDF block with name '"CompatToolMapping"' in VDF file '/home/cchulo/.local/share/Steam/config/config.vdf'
Tue Oct 31 07:57:48 AM PDT 2023 INFO - createVdfEntry - Will insert new block into bottom of '"CompatToolMapping"' VDF section
Tue Oct 31 07:57:48 AM PDT 2023 INFO - createVdfEntry - Generated VDF block string ' "3449158112"\n {\n "name"\t\t"GE-Proton8-19"\n "config"\t\t""\n "priority"\t\t"250"\n }'
Tue Oct 31 07:57:48 AM PDT 2023 INFO - createVdfEntry - Writing out VDF block string to VDF file at '/home/cchulo/.local/share/Steam/config/config.vdf'
Tue Oct 31 07:57:48 AM PDT 2023 INFO - backupVdfFile - Found existing VDF backup file '/home/cchulo/.local/share/Steam/config/config_steamtinkerlaunch.vdf'
Tue Oct 31 07:57:48 AM PDT 2023 SKIP - backupVdfFile - Existing VDF backup file is not older than 1 day, not overwriting
Tue Oct 31 07:57:48 AM PDT 2023 INFO - backupVdfFile - Not backing up VDF file 'config.vdf'
Tue Oct 31 07:57:48 AM PDT 2023 INFO - addNonSteamGame - Finished adding Non-Steam Game compatibility tool to '/home/cchulo/.local/share/Steam/config/config.vdf'
Tue Oct 31 07:57:48 AM PDT 2023 INFO - addNonSteamGame - Finished adding new non-steam game
But it was useful to see and document nonetheless, thanks for attaching an updated log.
Side note, i kinda like how the random number generation is deterministic, not sure if that was a feature before
Heh, it was present before and was something that I didn't do intentionally at first but when I noticed it I thought it was useful since Steam will generate a seemingly random AppID. The original behaviour was due to the --random-seed
being given to shuf
before, now it's due to md5
generating a consistent sum, which is by design of md5). This behaviour is something I'm thinking of making "optional" though on by default because I also like it, but I can't see a case when you would want the behaviour Steam provides, which is why I haven't done it yet :smile:
I can't re-create the problem, if you can't recreate the problem again either maybe this was some one-off weirdness.
Something that is very weird, if I'm understanding your description correctly:
I readded it and it was assigned 3449158112 I found that it still had not set the GE version. I added it manually again. Saw that config.vdf assigned it correctly to 3449158112. I removed the game, reran the same command, and it was once again readded but the GE version was correctly set. So it now "permanently" works, with just that quirk.
SteamTinkerLaunch actually won't update the config.vdf
entry. Right now we can't, I haven't figured out the details of overwriting an existing entry in a VDF file yet. So the fact that re-running it updated the entry, and I can see from your log that it did actually try to re-insert an entry.
I am not too sure what caused the quirk, if removing and re-adding the game worked, maybe for some reason the AppID for the game was picked up wrong. Because the AppIDs are deterministic, re-adding it should have used the same AppID, and so Steam would pick it up correctly.
But if STL was able to re-insert the compatibility tool block into config.vdf
(and I can see it did from the log), that suggests to me that the entry was not added, which is very odd.
I did confirm just now that Steam does not remove these compatibility tool mapping entries from config.vdf
, which is actually kinda crazy. I even tested closing and re-opening Steam just to see if it did it on close/on boot, but nope, the entries are still there. This even applies to games added through Steam's "Add Non-Steam Game" option in the Steam Client! So if you added a bunch of Non-Steam games, you would have a bunch of dead entries laying around in the VDF file. I wonder if I should report that upstream to Valve...
I reported this config.vdf
permanence issue and some other related issues upstream to Valve at ValveSoftware/steam-for-linux. I don't really expect much action (it's quite technical, has probably affect a tiny fraction of people, even smaller fraction fraction noticed, and a smaller fraction again actually care :-)) but it's been documented and even if the issue is closed, it's there for others to reference in future.
I'll leave this open for a bit to allow for further discussion and testing, as it can understandably take time to test and collate findings. But if the issue is resolved for you now you're absolutely free to close the issue :-)
thanks I appreciate it, give me until Saturday, I got a bit tied up at work and haven't had time to come back to this quite yet. Will retest as soon as I can, Saturday the latest!
There is absolutely no rush, real life should always come first. When an OP is active at trying to help with issues and has done their bit to help, I'm a lot more inclined to leave issues open compared to blank ones :-)
okay i got around to retesting, this time using Biohazard 3, and still same quirky behavior as before:
command used:
./steamtinkerlaunch ansg \
--appname="Biohazard 2" \
--exepath="/home/cchulo/Games/Biohazard3/BIOHAZARD(R) 3 PC.exe" \
--startdir=/home/cchulo/Games/Biohazard3 \
--iconpath=/home/cchulo/Games/Biohazard3/steamgrid/icon.ico \
--launchoptions="WINEDLLOVERRIDES=\"ddraw.dll=n,b\" %command%" \
--compatibilitytool=GE-Proton8-19 \
--hero=/home/cchulo/Games/Biohazard3/steamgrid/hero.png \
--logo=/home/cchulo/Games/Biohazard3/steamgrid/logo.png \
--boxart=/home/cchulo/Games/Biohazard3/steamgrid/boxart.png \
--tenfoot=/home/cchulo/Games/Biohazard3/steamgrid/tenfoot.jpg \
--copy
Restarted steam and:
The log is attached on the original issue. I am sure that if i force the compatibility tool on, remove the game, re-run the command it will "stick" because the config.vdf
would preserve the manually edited entry
I can keep tinkering with it to see if i can figure out a workaround, i can report back if I find anything
also, i realized that i accidentally left the Biohazard 2 label, see im creating these type of self-install .sh scripts, forgot to edit that part out for Bio3, im sure the label does not actually matter
That is odd, I can't reproduce the problem. Your log also looks fine. I'll investigate some more tomorrow though.
Before running anything agin, by the looks of the log, it created a backup of your config.vdf
. This is at /home/cchulo/.local/share/Steam/config/
, and should be named something like config.vdf.bak
. It would be interesting to see if AppID 3610055705
was already in the file.
I tested with the same label name and a similar path (on my home drive, different username ofc) and didn't have any trouble. Is the artwork being set correctly for your inserted game, and when inserted, before you open Steam, does the config.vdf
already have an entry with that AppID?
I don't have config.vdf.bak, i have a config_steamtinkerlaunch.vdf though
and I do not see 3610055705 in either one of these
btw there are a couple of more bugs i have since discovered around this feature, making it not viable for my purposes, do you want me to open two additional issues or should i go ahead and add them here?
One issue: is that the --exepath has to be a fullpath, otherwise --startdir is ignored and will default to "." Second issue: I cannot add two separate non-steam games consecutively, i need to add one at a time, and restart steam after each one. Cannot bulk add, otherwise i get multiple entries for whatever was the last game I added.
I can add these issues separately.
I don't have config.vdf.bak, i have a config_steamtinkerlaunch.vdf though
Ah, my bad, yes it's called that (I think the first name was one I used briefly during development)
and I do not see 3610055705 in either one of these
If it gets inserted into the new VDF file, under "CompatToolMapping"
, but Steam isn't reading it until you force the compat tool, and if it just updates this exact same entry, then I'm stumped. I can't re-create the behaviour yet.
One issue: is that the --exepath has to be a fullpath, otherwise --startdir is ignored and will default to "."
This is intentional, this is true for any SteamTinkerLaunch path. All paths must be absolute, as noted on the help screen:
(All
args must be absolute paths)
The reason StartDir
defaults to .
is that paths like ~/Games/blah
do not actually exist. You should be able to pass expanded paths as an argument though, if you can be sure it is safe (which is why STL does not do it). Something like --exepath="$(realpath "$HOME")/Games/blah"
may work. But in general it is good practice to pass full, absolute paths to commands.
Second issue: I cannot add two separate non-steam games consecutively, i need to add one at a time, and restart steam after each one.
Steam should be closed when running ansg
. Most programs that modifies shortcuts.vdf
will tell you to ensure Steam is closed, and some (Steam-ROM-Manager) will actually refuse to run with Steam open. If you have Steam closed, do you see this behaviour? I can add two games consecutively, assuming you mean running something like
steamtinkerlaunch ansg <args blah blah>
steamtinkerlaunch ansg <args blah blah>
steamtinkerlaunch ansg <args blah blah>
If you're seeing this problem with Steam closed, then please open a separate issue. It sounds very strange as well.
With Steam open, I can reproduce the behaviour of the compatibility tool not being set correctly. I just tested adding a game with Steam opened, and the compatibility tool was not set. I suspect Steam, when closing itself, overwrites the config,vdf
, as 4206540963
is not even present in my config.vdf
.
Removing the shortcut, closing Steam, and re-running the exact same command adds the shortcut with the compatibility tool selected as expected.
If this resolves the issue for you, perhaps we just need better documentation that Steam should be closed when adding shortcuts. I was just thinking last night that the "Add Non-Steam Game" button should be removed from the main menu because it won't quite work as expected with Steam running. Especially when we start modifying localconfig.vdf
, but it seems this is already an issue for config.vdf
.
I guess I incorrectly assumed that users would close Steam before performing these actions. It is probably not obvious that this should be done unless you're pretty close to how the whole thing works.
The Add Non-Steam Game GUI does already note that the Steam Client should be closed before adding shortcuts. A note should probably be added to the help menu as well as the wiki. I will update both now.
Updated the Add Non-Steam Game wiki page, and added a note to the help screen that the Steam Client should be closed before adding any shortcuts in https://github.com/sonic2kk/steamtinkerlaunch/commit/9b56004b7dfddf87c7282b58d83d8acec924a35d.
ah yea i just discovered that before seeing your reply haha, sounds good!
Will disregard the other two non-issues then. Will keep tinkering with the original issue for now.
If the double-entry thing persists please feel free to open an issue, I'd be very interested in trying to fix that.
I appreciate the tinkering too, the more testing for these features, the better! And in future if I find a safe way to expand the paths in a way that has minimal risk, I can implement. Or if someone opens a PR for it I'll accept that too :-)
If your paths always start with the home directory, you could set them as $HOME/Games/Biohazard 3/Biohazard
.
And also, in the case of the command you showed, you can leave --startdir
blank, as SteamTinkerLaunch will infer the base directory of the exe as the start directory. So for /home/deck/Games/Biohazard 3/Biohazard(R) game.exe
(or "$HOME/Games/Biohazard 3/Biohazard(R) game.exe"
), it will infer /home/deck/Games/Biohazard 3
:-)
The reason $HOME
works and something like ~/Games
doesn't, is because Bash doesn't automatically expand ~
, but $HOME
is an environment variable. For example, assuming a username of gaben
:
echo "~/Games" # Will return ~/Games
echo "$HOME" # Will return /home/gaben/Games
[ ! -d "~/Games" ] && echo "Path '~/Games' does not exist"
[ -d "$HOME/Games" ] && echo "Path '$HOME/Games' does exist" # Note how the echo here still expands '$HOME'
If you run into any more trouble please don't hesitate to ask or open another issue, because this feature is one I'm really excited about and am really happy to improve wherever possible, or explain shortcomings where there are some.
A couple of other tricks you may be interested in with the ansg
command:
steamgrid
folder), you could use --auto-artwork
to set the artwork. Perhaps in future I'll add an option to tell SteamTinkerLaunch which directory to search for artwork, defaulting to the EXE directory, for cases where this may not be possible--use-steamgriddb
to fetch artwork from SteamGridDB. It will search based on --appname
by default, but you can pass a custom --steamgriddb-game-name
, or --steamgriddb-game-id
if you have a specific SteamGridDB Game ID in mind, or --steamgriddb-steam-appid
to search based on the Steam AppID if you want Steam artwork
--link
option instead of --copy
for game artwork, most of the time especially for jpegs I really doubt this is going to be a problem, but if you had animated APNG artwork, it could be handy-ct="default"
and this will use the default global Steam compatibility tool at that time. Usually this is the latest Proton stable, but you can change it. It can be a useful shorthandThere are also a couple of shortcomings to note:
jq
being installed. This is installed on a lot of systems already, including SteamOS, and the reliance on jq
will increase so much in future that I'm probably going to make it a hard dependency. Just something to keep in mind that jq
is a good dependency to install!--hide
, --allowoverlay
and --tags
options don't quite work. They work in that they successfully update the shortcuts.vdf
file, but as of maybe a month or so ago, Steam updated to use a file called localconfig.vdf
to store this information. It is feasible to fix the --hide
and --allowoverlay
options, I spent the last 2 days painstakingly crafting functions to update values in VDF files (branch here), but tags is going to be more tricky. That's being tracked at #949.
localconfig.vdf
, but parsing LevelDB in Bash is tricky.config.vdf
in the first place, and release it as an open-source text-based VDF parser written in Bash.config.vdf
will not update. I think this is fixable with the functions described above, we should be able to update an existing entry to use the new compatibility tool, but it is not implemented yet. It may be implemented soon though!--hide
, --allowoverlay
, --allowdesktopconf
, and --openvr
is not super nice. They expect 0 or 1 values, like --hide="1"
, but I would prefer to be able to simply pass --hide
and if the flag is not passed, SteamTinkerLaunch should assume we don't want to hide. The same applies for the other three flags. The trouble is that conflicts with how we call the function on the UI. I'm exploring ways to change that syntax, but just a heads up of the current behaviour which is documented on the wiki, but I still consider unintuitive, and will explore fixing.grid update owned/installed
command does not apply to Non-Steam Games, but #963 is changing that.getid
to work for Non-Steam Games.Did closing Steam before adding the entries resolve the issues? :-)
oh oops idk why it appears like i closed this, i might've been distracted. Yes still experimenting with my install scripts, and I do suspect that having steam closed actually has an effect, though i need to retest with other non-steam games
No problem, GitHub has a keyboard shortcut for closing issues that I end up doing by accident all the time :-)
Seems like ensuring Steam is closed has resolved the problem, I can't reproduce anymore. Assuming this is fixed now, please re-open if the issue persists while Steam has been closed - ensuring the client has fully closed, sometimes it takes a few moments after the window disappears. Once the tray icon disappears, that's generally a good indication (if you have a system tray configured for your desktop).
Thanks!
@sonic2kk i found out that from time to time, valve updates their format slightly. What makes it difficult is the vdf binary format is hard, as well as the ascii vdf format since it uses tabs rather than spaces. I ended up writing my own python based tool that handles automating adding shortcuts using python with a pypi library that handles all the vdf reading/writing for me: https://github.com/cchulo/steam-conductor
I do realize this might not be appealing solution to you, i think you keep everything in a single bash file so it is lightweight and as portable as it can be. My python program is portable since it bundles everything, including the python interpreter, into a single exe with pyinstaller, but it is a bit of a chonky .exe as a result. Still I thought i'd share since i did run into the same problem i ran into with your script. I figured out that valve, on occasion, updates the objects inside binary VDFs, breaking automation tools like this one, it takes a while to figure out what changed, but on the bright side, its python, and so its a bit easier to read and debug than a bash script.
I don't think the shortcuts.vdf
format has not changed here, and if the format does change, it should be straightforward to update. At least to my knowledge no programs that interact with the shortcuts.vdf
have had to update their formats. ProtonUp-Qt, for example, which still uses the older version of the Python vdf
library which has not yet updated to the appinfo.vdf
format, works fine.
Can SteamTinkerLaunch no longer set compatibility tools? The issue here was that the Steam Client was open when trying to write to config.vdf
, and that format surely has not changed (ProtonUp-Qt can still update shortcuts' compatibility tools.
The only format that should have changed with the Steam Client Beta is the appinfo.vdf
bumping to v29.
but on the bright side, its python, and so its a bit easier to read and debug than a bash script.
There was no call for this...
Adding a shortcut with SteamTinkerLaunch and setting the compatibility tool still works fine on the latest Steam Client Beta, I just tested. If you tried to add a shortcut again and it didn't update the tool it's probably because there was an existing entry in config.vdf
(although Steam does sometimes clean this up, it doesn't always).
The shortcuts.vdf
format as well as the ASCII VDF format has not changed to my knowledge in a very, very long time. It is rather the structure and usually the size of the header that changes, and in almost every instance in the last decade, that has only affected appinfo.vdf
(which SteamTinkerLaunch also parses, but the specific bytes pattern it parses for don't seem to change very often).
So the Python project you have linked, while indeed cool, doesn't affect this project, and I won't be switching over to using a Python utility when Bash works just fine for this project. We will most likely already soon have to introduce a small C++ dependency to parse Steam categories using LevelDB which I am not pleased about (I would like to figure out how to write a LevelDB parser in Bash for our purposes) and it would be considerably smaller than bundling a Python project.
its not shortcuts.vdf
that was the problem, that one is simplistic actually, its the other config where you map compat tools, config.vdf
when I originally wrote steam-conductor, compattools were mapped under an object just called "CompatToolMapping", and it was working for a while, then suddenly it stopped, turns out that now CompatToolMapping is nested under 'InstallConfigStore.Software.Valve.Steam.CompatToolMapping'
Like i had it working, then suddenly it stopped working after an update
For the last while at least, it has always been under InstallConfigStore.Software.Valve.Steam.CompatToolMapping
, going by my experience with ProtonUp-Qt.
SteamTinkerLaunch parses for the first heading matching a given indent level, so even if the format did change, it would be a matter of SteamTinkerLaunch just bumping which indent level it should look at, if it can't guess the initial indent level (which it probably can).
also understood, was not suggesting that you move to using my script, mine is going to have more specialized automation built into it for my purposes, but wanted to show you how the add_shortcut works, could give you clues as to why yours compat tool mapping does not work
The CompatToolMapping
does work though, I just tested it... In my earlier comment:
Adding a shortcut with SteamTinkerLaunch and setting the compatibility tool still works fine on the latest Steam Client Beta, I just tested.
was not my intention to start an argument, simply put this issue was started because that feature never worked for me, it did add shortcuts, but quite simply it never mapped compat tools for me. i simply wanted to share that i created a python utility for doing the exact same thing that works, and was sharing it with you to see if maybe you could check it out, im glad it works for you, it does not work well for me, for whatever reason.
Well it has worked for at least a couple of other users (can't find the exact comments but there were two users that were particularly interested in Add Non-Steam Game that tested it, one even uses it downstream for an FFXII script iirc), and has worked across a couple of devices for me including a very recent one. Sorry it doesn't work for you, but the solution here seems to work across devices and at least a handful of other users.
If it never worked for you, it wasn't due to a format change at least. The format has been InstallConfigStore.Software.Valve.Steam.CompatToolMapping
for over two years - this line was added on November 2nd 2021 and uses the same format as it does today. And SteamTinkerLaunch doesn't even parse it this way to begin with, it doesn't do it the same way ProtonUp-Qt or steam-conductor
does it where it essentially stores the whole VDF as a dict and parses data out. We used shell utilities to do essentially glorified find and replace.
addNonSteamGame
function will call createVdfEntry
to create the VDF block in config.vdf
: https://github.com/sonic2kk/steamtinkerlaunch/blob/144347b1c1b322bda8d3cdc5559ad284a9f8578c/steamtinkerlaunch#L24977-L24986createVdfEntry
works by finding the parent block we want to write into in the given VDF file. It does this via indent. It figures out the indent that the parent block is at (it can also optionally be specified, if the same heading can exist at multiple indent levels).
CompatToolMapping
wasn't nested under the format above, it would still be able to find it. I know this because otherwise #1119 wouldn't work.So even if it doesn't work for you, the reason for why is very different than what you might have expected coming from Python. It does not work in the same way, as Bash does not have the same concept of data structures. The file is treated as a string that we run sed
on to append into, and other actions do some other spice as well.
System Information
Issue Description
Writing some automation to automatically reinstall games to freshly imaged desktop and steam deck. I run the following command, and while it mostly works, it failed to set the compatibility tool:
I did not get any errors, and inspecting the log, from first glance, looks like it would've worked.
I made sure compatibility tool was spelled correctly, as
GE-Proton8-19
Logs
steamtinkerlaunch.log steamtinkerlaunch-10-31.log steamtinkerlaunch-11-4.log