search

sonic2kk / steamtinkerlaunch

Linux wrapper tool for use with the Steam client for custom launch options and 3rd party programs
GNU General Public License v3.0
2.13k stars 71 forks source link

USELUXTORPEDA does not function #1177

Open Jonathing opened 6 hours ago

Jonathing commented 6 hours ago

System Information

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 commented 6 hours ago

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 commented 5 hours ago

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`` isSTEAMUSERID`).

sonic2kk commented 5 hours ago

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 commented 4 hours ago

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 commented 1 hour ago

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 commented 1 hour ago

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 commented 1 hour ago

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 commented 1 hour ago

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 commented 50 minutes ago

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 commented 43 minutes ago

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.