Request: Help on reading the source code

[garaiza-93]

Hello, I'm trying to make a patch for steamtinkerlaunch for use on NixOS, and I need some help trudging through the source code.

What I'm trying to figure out is where STL deletes a language file from lang/ when a game is started in Steam. After looking through the source code for rm statements, I have a gut feeling that this file is not deleted on its own, but alongside other files. However, I'm not able to pin down an exact line number.

Any tips would be appreciated.
Here's the original issue for context and log messages: NixOS/nixpkgs#226086

[sonic2kk]

First off, I love the dedication here and that you linked to the original issue for context :-)

I'm more than happy to help, I'm currently a little busy and feeling a bit under-the-weather but later today I'll try to refresh my memory on how the language files are handled. I'm pretty sure STL removes them and re-creates them to update the langfiles to the latest each time (primarily for Steam Deck iirc where it's installed locally and not system-wide).

As for how they're removed, I think I created a helper method to do it, so that may explain why searching for rm on its own may not make it immediately obvious how they're being removed.

For how a game is started, I think it's launchSteamGame. There is a "master" launch function that makes slightly different calls for Non-Steam Games, MO2, and maybe others. I'll have to double-check on that.

And lastly, I'm not sure how things are handled with NixOS packages, but I'm more than happy to accept a patch/work on a patch to improve support on the STL side, to save having to potentially manage a patched STL specifically for NixOS. I don't use NixOS and I am not overly familiar with it but as long as the "GNU" flavour of the tools STL uses work then I'm happy to try improve things here to help users.

There is much room for improvement with STL and I'm looking at improving how various things are handled where I can, removing various outdated parts of the code, removing duplicated code where I can, but it's a slow process :-) Even though I've been maintainer for almost 8 months now I'm still getting to grips with some of the "intricacies" 😉

---

Once I have some more time I'll look at the code and give a more contextual and thorough answer. Once again I appreciate the initiative here and I'm happy to help!

[garaiza-93]

Thanks for the kind comment! I'll look at the functions you mentioned more closely once I can get some free time 😄

In regards to Nix/NixOS for clarity, it wouldn't be having a separate STL just for NixOS, but instead making patches in the process of packaging STL. We'd still be using this repo! It's nuanced, but the real important part is that all packages (including STL) are stored in a read-only file system (the "Nix store"), by design.
That conflicts with the current way lang files are being handled (Nix does not like files in its store being modified) , so one approach I have in mind is to skip over lang files in that step and see how it plays out. Might not be the best idea, but it's an idea! If that's not a good approach please let me know.

I'm unsure if I'd be able to contribute to STL directly with the little know-how I have, but I think I'll be learning regardless and maybe I will come up with an improvement as I keep looking through the source code!

Thanks again for your help. I love this tool as I used it all the time when I was still using Manjaro!

[garaiza-93]

I'm a little off in my explanation of how lang files conflict with how Nix does things.
All available lang files are in the Nix store, so they are read-only. Then, when lang files are copied to the user's config directory, they keep those same read-only permissions!
My gut tells me that somewhere in STL's code can be patched to ensure that write permissions are set on lang files when they are copied to the user's config directory. I might be onto something, but again, if you have some more insight let me know!

Or, I could also be totally wrong 🤪

[sonic2kk]

My gut tells me that somewhere in STL's code can be patched to ensure that write permissions are set on lang files when they are copied to the user's config directory. I might be onto something, but again, if you have some more insight let me know!

Ah okay! So the problem is something like this:

• User installs SteamTinkerLaunch X and in the Nix Store it has the language files for that version
• Then, SteamTinkerLaunch Y comes out, and adds a very cool new feature that has an equally cool language string added to, say, english.txt
• User updates to SteamTinkerLaunch Y, and SteamTinkerLaunch tries to copy the update language file english.txt (or whatever they configured) to its config folder (~/.config/steamtinkerlaunch/lang)
• The english.txt file already exists at the config folder, so STL sees this and tries to remove it (in loadLangFile, it does rm "$LAFI" to remove existing language file before replacing it)
• Problem! The existing language file that was copied from the Nix Store has kept its read-only permissions, and so cannot be removed!
• As a result, the language files cannot be updated, and the downfall of humanity is imminent (probably)

(And actually while testing this, I noticed that STL seems to just do this on pretty much every launch, so... 🤷‍♀️ Probably a bug but a low-priority one to fix)

I am not sure why being unable to update the langfile is causing a problem, but maybe it's more fatal than I realised. Nevertheless:

My gut tells me that somewhere in STL's code can be patched to ensure that write permissions are set on lang files when they are copied to the user's config directory. I might be onto something, but again, if you have some more insight let me know!

I believe this is feasible for sure! It should be a case of running chmod -R +w /path/to/stlconfig/lang, which should append +write permissions to all files in the folder. It would be possible to do it only for the copied file but this should ensure any files in the directory can be updated at any time.

You could test this yourself to make sure this gives the desired behaviour, and if it does, I can add it to STL no problems. The langfiles are probably being copied to ~/.config/steamtinkerlaunch/lang, so you could run the command on that folder (yes, sadly doesn't follow the xdg spec, see #486). There is something to be said about explicitly modifying file permissions without notifying the user, but since this is modifying files in the STL config directory, I think it is fine :-)

[sonic2kk]

Also, as a high level overview of how STL sets the lang files:

• It calls loadLanguage in its main function (towards the bottom of the script) and then attempts to load the language based on the user preference, or find and set the language preference based on a passed in language string, e.g. steamtinkerlaunch lang="french"
• If no language is given from the commandline, or if we cannot find the language specified either in a manually updated preferences file or from the commandline, we fall back to english as the default (this may be where the langfile gets updated on each boot, not sure)
• We do things this way to ensure langfiles are always up-to-date on each launch, including and especially for non-root installs such as from ProtonUp-Qt/manual Steam Deck installs
• If you're interested, you can see how me and DavidoTek handled loading the STL language when installing via ProtonUp-Qt: https://github.com/DavidoTek/ProtonUp-Qt/blob/main/pupgui2/resources/ctmods/ctmod_steamtinkerlaunch.py (check get_tool method, didn't link to it because the STL ctmod is subject to a re-structure for a ProtonUp-Qt PR I'm working on, and a potential cleanup when I have the motivation 😅)

I was originally writing this out and then I saw your reply, so I thought responding to that first would take priority. I hope that explanation made sense.

There is also a configuration option (in the menus and in global.conf to specify where STL should look for language files, but I don't think that's entirely relevant here anymore since ideally just ensuring the permissions on the lang folder are set to read/write should be enough.

---

In regards to Nix/NixOS for clarity, it wouldn't be having a separate STL just for NixOS, but instead making patches in the process of packaging STL. We'd still be using this repo! It's nuanced, but the real important part is that all packages (including STL) are stored in a read-only file system (the "Nix store"), by design.

That makes sense, and this read-only store is what's causing the problem when STL tries to remove the copied langfiles - they keep their permissions.

so one approach I have in mind is to skip over lang files in that step and see how it plays out. Might not be the best idea, but it's an idea! If that's not a good approach please let me know.

Even though it isn't explicitly files in its store being modified (which should only happen after an update), the general idea here could also work, the problem is that langfiles may become out-of-date. Though STL should just fall back to the files in lang, I think...

I'm unsure if I'd be able to contribute to STL directly with the little know-how I have

There's never any pressure to contribute :-) But I appreciate you taking the time to learn how STL handles things and gain an understanding of the problem and hopefully improve things.

[garaiza-93]

Thanks for the detailed explanation! I think I'm getting the hang of the source code. I just put out a PR to address this, which adds a couple of chmod statements. When that PR gets merged or closed, I'll mark this as closed!