USELUXTORPEDA does not function

[Jonathing]

System Information

• SteamTinkerLaunch version: v14.0.20240904-1
• Distribution: Nobara Linux 40 (KDE Plasma)
• Installation Method: ProtonUp-Qt

Issue Description

Sorry to be bothering you with issues today haha. Though this one is more straightforward and not as weird as the custom command issue I posted today.

This one is simple. USELUXTORPEDA does not function at all. It looks like SteamTinkerLaunch is looking for /luxtorpeda/luxtorpeda which for obvious reasons does not exist. It's not a high priority bug since I can just use Luxtorpeda manually, but since it's an integrated feature, I figured I'd report it.

Logs

Here's the STL log. Unrelated to this issue, but Half-Life 2: DownFall seems to crash immediately when used with GE-Proton9-15.
https://gist.github.com/Jonathing/0971d56796916dc3bf93107ccaddbd52

[Jonathing]

Ah, I should add I realized that the LUXTORPEDACMD variable can be edited in ~/.config/steamtinkerlaunch/global.conf. It might still be better to have STL look for a Luxtorpeda compatibility tool in Steam, though. Or, have it download an instance of it like how custom protons can be downloaded.

[sonic2kk]

SteamTinkerLaunch isn't supposed to pull Luxtorpeda from the Steam compatibility tools, but rather systemwide as far as I understand (i.e. installed via your package manager).

Ah, I should add I realized that the LUXTORPEDACMD variable can be edited in ~/.config/steamtinkerlaunch/global.conf

You should also be able to edit the Luxtorpeda path via the Global Menu, which is what writes to this file. The vast majority of options available in the Per-Game and Global config file can also be edited via the Global Menu (the only one that comes to mind which cannot be set via the Global Menu but that is read via the global.conf`` is STEAMUSERID`).

[sonic2kk]

Actually, I'm wrong, the wiki states that Luxtorpeda can be sourced from the Steam compatibility tools folder. I'm not sure why it isn't being found then...

[Jonathing]

I assumed that STL would search for Luxtorpeda in $STEAMPATH/compatibilitytools.d/luxtorpeda/luxtorpeda, but it has the entire path to the compatibility tools directory omitted. Is it being eaten by something else?

[sonic2kk]

The path to Luxtorpeda defaults to $STEAMCOMPATOOLS/luxtorpeda/luxtorpeda. However it seems for some reason that this variable is not set when trying to build the Luxtorpeda command path, so $STEAMCOMPATOOLS/luxtorpeda/luxtorpeda becomes, since that variable is blank, /luxtorpeda/luxtorpeda as you described.

I am not sure why this variable is blank. Perhaps there is an ordering issue here. I can confirm that my Luxtorpeda command is also set incorrectly to the same value as yours. ROBERTACMD, which is also supposed to be prefixed with $STEAMCOMPATOOLS, is also missing the path to the Steam compatibility tools (it is supposed to be $STEAMCOMPATOOLS/roberta/run-vm but is just /roberta/run-vm).

As a workaround for now you can manually select the Luxtorpeda executable, but since I can reproduce this, I'll look into what might be causing the problem. Good find!

Extra implementation detail notes: SteamTinkerLaunch will also check if the Luxtorpeda executable is valid before launching and that we're using a native Linux game. You can see the further logic in setLuxtorpedaCmd, and then how it is used around the codebase here in launchSteamGame.

[sonic2kk]

Hmm, we called createDefaultCfgs pretty early on in main, and we only call saveCfg (which should create the config values) after that. The order goes: main, which calls createDefaultCfgs, which calls setSteamPaths (which calls setSteamPath "STEAMCOMPATOOLS" "$CTD"), and then afterwards calls saveCfg "$STLDEFGLOBALCFG" X.

Something is going awry here with this ordering and I am not yet sure why. I'll keep digging.

[sonic2kk]

Ah, loadLanguage is called before setSteamPaths in createDefaultCfgs, and loadLanguage calls saveCfg "$STLDEFGLOBALCFG". So it's loadLanguage that makes this call to create the global config before the Steam paths are set.

I wonder if this is as simple as just calling setSteamPaths earlier. I don't know if there's a detriment here, I don't think setSteamPaths relies on any languaue stuff...

EDIT: Damn, loadLanguage is also called early in main, which has the same problem... It's called before setDefaultCfgs. This is probably the early call that breaks things. This will be a tricky one to solve, since the language loading is a pain on SteamOS.

[Jonathing]

Also in case it affects your implementation, Luxtorpeda now uses luxtorpeda.sh as its launch file instead of luxtorpeda. I don't know if it was different before, though.

[sonic2kk]

Also in case it affects your implementation, Luxtorpeda now uses luxtorpeda.sh as its launch file instead of luxtorpeda.

Ah, yes that would indeed have an impact. Thanks! The Luxtorpeda stuff was implemented long ago, I'm not even sure who implemented it (whether it was the previous maintainer or a member of the community). I guess no one used it as no one reported this issue or this change, and the broken auto-detection behaviour you have reported seems to have been broken for many years :-)

Well, in saying "auto-detection", it really just tries to choose a default path.

I think changing the default path that we set to luxtorpeda.sh is probably fine. This global config value is only set once when the file is initially created, so there is no need to support older Luxtorpeda executables. Since we only set a default, if the path doesn't exist it won't display in the Yad box on the Global Menu, and a user can always select the valid path themselves, so changing the default path is fine.

I will change the path in a separate PR, and also update the wiki when I am working on that.

---

I have a PR up at #1178 to fix this default path for Luxtorpeda and Roberta. It just checks in loadLanguage that the global config file exists before it tries to create it (since it would create it here without setSteamPaths being called). This makes sense too, we only want to load the global config to get the language from it, but if it doesn't exist, there's no need to load anything. In my tests with a fresh global.conf this does fix the issue for Luxtorpeda (and Roberta, which had the same problem).

This won't retroactively affect global configs. Although we do have a migrateCfg function, I think there is no need to do that in this case, because we don't know which values were deliberately set by the user (and checking for specifically /luxtorpeda/luxtorpeda seems a bit flimsy and risky to me, and the equivalent for Roberta) and because this is just a default we set for convenience in the global config, there is never a guarantee that it exists in the first place and so the user can always edit it manually from the Global Menu (and on the Global Menu, the Yad box would not display anything if the path in global.conf does not exist, so the user would see there was no Luxtorpeda executable found and select the real one from the Global Menu, or enter it manually in global.conf).

I will do some more testing and merge the PR once I am confident this check has not introduced any regressions.

[sonic2kk]

PR to update the LUXTORPEDACMD path is up at #1179, just wanted to track this separately in case Roberta needs a similar change or anything else similar might crop up.

I appreciate you bringing both of these issues to my attention :-) Should be resolved once those two PRs are merged.

[sonic2kk]

This should be fixed with #1178 (fixes the Luxtorpeda path being /luxtorpeda/luxtorpeda as it was missing STEAMCOMPATOOLS variable due to global.conf being created too soon) and #1179 (changes the Luxtorpeda executable name to luxtorpeda.sh, since the old luxtorpeda was oudated).