Vortex broken - but easier

[ajventer]

So the latest update to vortex broke it again - but it also makes it easier to fix and removes the need for work-arounds.

As of the latest update: two main things changed.

1. It now requires windows 10, this breaks the installer but should be an easy fix
2. The DotNet requirement is now DotNet6. This is actually good news because DotNet6 doesn't require winetricks or work-arounds, it just installs cleanly under wine and is directly usable.
   I've tested it, and you don't even need to preinstall it, Vortex will install it automatically on a clean prefix.

So this means - it should no longer be mandatory to run Vortex in it's own distinct prefix with symlinks etc. It could conceivably just be installed in game prefixes like we do with ModOrganizer.
Even if you opt to stick to the current model, it should simplify the installer as you no longer need to use winetricks to install the very broken dotnet48 into it.

I tested it by simply downloading the installer and installing it using the "custom setup file" in Lutris, this created it's own prefix but for testing that's fine anyway, and hte only missing functionality is browser integration.

So, with a little luck, once STI fixes this one - it's fixed for a long time, and should not require nearly as much handholding. At this stage Vortex is actually very important because Wabbajack is still unusable on the steam deck (or linux in general) and Nexus collections is currently the only real alternative out there.

[ajventer]

Update: did some more testing, it may not be quite as easy as I thought, since out of the box it doesn't run in a proton prefix. I tried installing it into one using protontricks, the installer seems to run but the app crashes on load without any useful information.
I'm not sure what Lutris did differently so I can't reproduce it, but thought it worth mentioning.

[sonic2kk]

Is this something that broke with Vortex 1.8.3? Vortex 1.8.0, 1.8.1 and 1.8.2 were fixed in STL git. The DotNet6 change was also already implemented in STL-git (#803).

The DotNet requirement is now DotNet6. This is actually good news because DotNet6 doesn't require winetricks

Vortex can install DotNet6 itself, but STL-git will actually install dotnetdesktop6 during installation so that Vortex doesn't have to. It's one less step for a user who may not fully trust the .NET 6 install process from Vortex (ex: me :-) )

It now requires windows 10, this breaks the installer but should be an easy fix

The default version for Proton 8 at least should already be Windows 10. My Vortex prefix defaulted to Windows 10 with GE-Proton8-2.

Even if you opt to stick to the current model, it should simplify the installer as you no longer need to use winetricks to install the very broken dotnet48 into it.

From this, I get the impression you're not using STL-git, please try using STL-git and seeing if the issue is resolved as there were various changes to Vortex recently.

So this means - it should no longer be mandatory to run Vortex in it's own distinct prefix with symlinks etc. It could conceivably just be installed in game prefixes like we do with ModOrganizer.

This is not what ModOrganizer does. It is installed to and runs in its own prefix in Standalone Mode, and symlinks are used to run games in game-specific prefixes. Also, any changes that would be done here should come from the community.

So, with a little luck, once STI fixes this one - it's fixed for a long time, and should not require nearly as much handholding.

Unfortunately this is also wrong, as Vortex always has a good chance of breaking under Wine with updates because of its dependencies, just like how 1.8.0 did because of the Chromium dependency (Vortex is an Electron app, so uses Chromium under the hood).

---

Update: did some more testing, it may not be quite as easy as I thought, since out of the box it doesn't run in a proton prefix. I tried installing it into one using protontricks, the installer seems to run but the app crashes on load without any useful information.
I'm not sure what Lutris did differently so I can't reproduce it, but thought it worth mentioning.

To this end, check that you're using GE-Proton8-2 or higher, as this is something Lutris may have done differently. Also, Vortex currently does not seem to work on Steam Deck in general (someone who maintains a downstream project mentions that Vortex doesn't work, and I have seen other numerous Wine project breakages on SteamOS lately).

The reason for this version is that the Chromium version which Vortex 1.8.0 and above uses, requires a Wine version that implements DiscardVirtualMemory stub. This stub first appeared in Wine 8.4, but Valve Proton based on Wine 8.4+ currently doesn't include this patch, but GE-Proton (and Wine-GE) has the patch, and Proton-tkg based on Wine Master includes it. See #792 for some discussion.

---

I'm going to try STL-git with the latest Vortex version in a fresh prefix and see if it works on my end.

[sonic2kk]

Vortex 1.8.3 installed for me successfully with GE-Proton8-2 using SteamTinkerLaunch v14.0.20230516-4 (latest git commit, bb8142c) on Arch Linux KDE Plasma Wayland.

If you haven't already, try with a fresh Vortex prefix (you can rename an existing one and then copy whatever files you might need over again to the new prefix), ensuring you're using GE-Proton8-2 (or any other build you have verified should be compatible). You can check the SteamTinkerLaunch changelog to see the relevant changes and their attached PRs which should've already addressed the issues you described with Vortex.

The only one not addressed at all is the Wine prefix version not being Windows 10. It should be, but another user reported that for some reason MO2 set the prefix version to Windows XP (#682), but I was not able to reproduce this, and it seems the issue may have resolved itself. However, it may be possible to force the Vortex Proton version to win10 using winecfg during startVortex function.

[ajventer]

Is this something that broke with Vortex 1.8.3? Vortex 1.8.0, 1.8.1 and 1.8.2 were fixed in STL git. The DotNet6 change was also already implemented in STL-git (#803).

I'm unsure, I am using a steamdeck - Vortex updated itself last night and it after that it would not work anymore. But i'm glad to see that there is already a fix, though I'm not sure if it's possible to install the git version on the deck - currently 12.12 is still the latest version on protonupQT

The default version for Proton 8 at least should already be Windows 10. My Vortex prefix defaulted to Windows 10 with GE-Proton8-2.

When I try to do a clean install of vortex on 12.12 it fails saying the windows version isn't supported, checking winecfg shows it as windows 7.

From this, I get the impression you're not using STL-git, please try using STL-git and seeing if the issue is resolved as there were various changes to Vortex recently.
I'm using the latest available on steamdeck via protonup-QT - is there instructions for installing the git version on the deck somewhere ?

This is not what ModOrganizer does.
Fair enough, I'm not married to the idea, I thought it was an inconsistency with vortex, if it's already consisted - then no reason to mess with that part.

Unfortunately this is also wrong,
What a pity.

To this end, check that you're using GE-Proton8-2 or higher, as this is something Lutris may have done differently.
What do you know - I had used the latest lutris-proton-ge for that test, unfortunately it's rather harder to test directly in a prefix with proton-ge as protontricks won't work with it.

Also, Vortex currently does not seem to work on Steam Deck
It was working just fine for me until yesterday's update.

Seems to me all we need to get vortex fully functional for Deck users again is to get the current git version released to protonup ?

[sonic2kk]

though I'm not sure if it's possible to install the git version on the deck - currently 12.12 is still the latest version on protonupQT

It is already available, enable Advanced Mode to install SteamTinkerLaunch-git (I wrote the SteamTinkerLaunch support in ProtonUp-Qt).

Also, SteamTinkerLaunch can be installed on Steam Deck by cloning the repo and executing the script. ProtonUp-Qt does this with a little bit of extra spice :-)

The ProtonUp-Qt installation code for SteamTinkerLaunch is here, and the SteamTinkerLaunch-git support is here.

When I try to do a clean install of vortex on 12.12 it fails saying the windows version isn't supported, checking winecfg shows it as windows 7.

This is really strange and similar to the issue reported in #682. It may be possible to force the prefix version with winecfg during startup/installation though.

Seems to me all we need to get vortex fully functional for Deck users again is to get the current git version released to protonup ?

Again, apparently Vortex and other Wine applications don't work on SteamOS at the moment, so no guarantees. And if it doesn't, it's not a SteamTinkerLaunch issue.

[ajventer]

Thanks I'll give it a test drive then. Hopefully me asking will help the next person with the same issue too.

[sonic2kk]

Hopefully! Though this was already discussed in #792 and #797, and there is a note at the top of the changelog. The Vortex wiki also recommends GE-Proton8-2 The issue templates also recommend searching through open issues and checking the changelog.

As for STL-git with ProtonUp-Qt, several users have said they didn't know there was a git option available, but it is standard (and imo sensible) with ProtonUp-Qt to gate nightly/git builds behind "Advanced Mode" as they may be experimental, and it avoids clutter in the dropdown.

Good luck!

[ajventer]

I agree it's sensible to put those in an advanced module, it's not so standard to put the advanced setting in the About page - until you told me, I had no idea there was one and wouldnt' have found it if I wasn't actively searching.

[sonic2kk]

Quick follow-up: I investigated being able to set the emulated Windows version with Wine, and it is possible. It can be done with WINEPREFIX="/path/to/wineprefix" winecfg -v <version>, where <version> can be a few different values, stuff like win7, win10, etc. It can also be done with Winetricks, where you can run WINEPREFIX="/path/to/wineprefix" winecfg -q <version>, where <version> has the same accepted parameters as winecfg.

However when setting the version to win10, it defaults to vista, which sets Winecfg to vista. So, I looked into setting a key in the registry following the location given on the WineHQ wiki's Useful Registry Keys page. By setting this we can ensure the version is set to Windows 10. This did actually work, but when the prefix was opened again, the key was gone from the prefix's registry. So this may not be a solid way to tackle this.

Instead, a better way to set the Vortex prefix's Windows version should be found. I think using Winetricks to set it is a good path forward, but I need to figure out why it's setting vista when I choose win10.

[sonic2kk]

Also, to the auto-update point, STL-git has an option in the Global Menu under Vortex Settings to disable Vortex auto-updates. This forces the release channel to no automatic updates inside of Vortex (STL itself doesn't update Vortex), though Vortex does warn you that older versions will have some kind of "cut-off" so use with caution. It may be an option if you want to try and better guarantee stability.

This option was implemented in #804.

[ajventer]

Well, unfortunately it seems your earlier report about Vortex on steam deck was correct - with the current STL which can actually run current versions of Vortex - on the deck it won't install. It gets to the dotnet phase and just freezes, never moves on - even after 15m, no feedback or anything. So I did an experiment, and commented out the dotnet install command from the install_vortex function.
It did the exact same thing with vortex itself, as far as I can tell the app itself installed (the files are present in the prefix). But the window never closes or moves to the next step.
Looking at the process table, it appears to be stuck on
C:\windows\syswow64\rundll32.exe setupapi,InstallHinfSection Wow64Install 128 \?\Z:\home\deck.local\share\Steam\compatibilitytools.d\GE-Proton8-3\files\share\wine\wine.inf

I have no idea what is causing it, and because STL hides the full wine output (even if you run it from terminal) I can't provide any more information right now (I'll go look for a debug option or something to see if I can learn more) but at least it may help narrow down WHY vortex isn't working on the deck ?

[ajventer]

I found a possible explanation for why Lutris works and STL doesn't: the most recent GE-Proton that STL knows about is 8.3 but Lutris is using Lutris-ge-proton-8.5 - I'm guessing there is a bugfix between 8.3 and 8.5 that Vortex needs to function properly ?

[sonic2kk]

Lutris is likely using Wine-GE or a derivative and not GE-Proton. The latest GE-Proton available is GE-Proton8-3.

Depending on the directory structure (if the Lutris build is packaged the same way as a regular Proton build) it would be possible to use this build to run Vortex with it with STL. You can put it in the custom Proton folder or the Steam compatibilitytools.d folder and then select it from the STL Global Menu as the Vortex Proton version.

I have no idea what is causing it, and because STL hides the full wine output (even if you run it from terminal) I can't provide any more information right now

It should be available from /dev/shm/steamtinkerlaunch, or if you manually run the Vortex run command logged in steamtinkerlaunch.log.

but at least it may help narrow down WHY vortex isn't working on the deck ?

I agree with this and it would be good to document. It seems isolated to SteamOS, perhaps allowing the SLR for Vortex would help, but as it appears to work fine on various desktop Linux distributions I think this is specific to the Steam Deck for some reason. DotNet has various issues on SteamOS even with something like Protontricks, various people have even reported Protontricks not loading at all for them on SteamOS.

Wine breakages like this are useful to discuss, but i would like to continue making clear that these issues will not and cannot be addressed by SteamTinkerLaunch. It is not up to STL to try and guess which version of Wine to use or work around distro issues/Wine breakages e.g. by forcing specific Proton versions based on Vortex version or distro and so on. You didn't even so much as imply this, but I want to make it clear that whatever the outcome of this discussion, users are expected to do any resolution steps related to Wine breakages manually. The investigation you have done is the mindset expected of SteamTinkerLaunch users.

[sonic2kk]

I should also note that using Lutris Wine builds to run Vortex may work but I have no idea what impact this may have for modding or any other behaviour. Again, useful to discuss this too, just a small courtesy note to say "here be dragons" :-)

Though if it does work, allowing more flexibility with selecting a non-Proton Wine build to run Vortex may be a good idea. Doing this from a technical perspective (a new function to set the launch command may be needed) and a UI perspective may be a challenge but it is something I am considering across the board starting (hopefully) with One-Time Run (#788).

[sonic2kk]

Looking into it, it appears that the build you're referring to is Wine-GE. This will likely not work with Vortex and STL because of the launch command which relies on the proton Python script and a slightly different directory structure. Of course it may be possible to hack around and imitate this. Giving an option to use the SLR with Vortex might fix it, but it's hard to know for certain (I can't remember the issue but the SLR fixed one issue with a Non-Steam Game before).

As this issue is isolated to Steam Deck it may not be a high priority to look into, as users on Linux Desktop should still be able to mod fine, but I noted this as a possible enhancement on my personal ticket board.

[ajventer]

That's okay, for the moment I modified the .desktop file from steamtinkerlaunch to run my lutris vortex with --download to get browser integration and manually symlinked the game appdata directory in and successfully modded oblivion and fallout 4 on the deck.

I'd gladly switch back to STL once deck support for vortex works, or especially if we ever get a viable wabbajack solution. Rather than manually letting it see the game but for now this workaround works for me, though I would not advise it for anyone else unless you already know the underlying paths for things like loadorder.txt and mime type integration on Linux.

[sonic2kk]

I'd gladly switch back to STL once deck support for vortex works

Using the Steam Linux Runtime might fix it but I won't be able to guarantee anything. I make an effort to fix critical issues on Steam Deck but a Wine breakage is not a STL issue, and Steam Deck support is secondary-by-default (I make a consistent effort to keep my Steam Deck filesystem lean). Vortex support is also a low priority in general simply because I don't like Vortex or Nexusmods ;-)

I am looking into adding an option to use the SLR with Vortex, trying to figure out a clean way to integrate it into the Vortex launch command. Right now locally I have two separate launch commands based on a condition and I don't like that. Once the branch is up I'll send a reply and you can test it if you'd like - STL branches can be installed with ProtonUp-Qt, SteamTinkerLaunch-git's "versions" dropdown lists available branches.

If it fixes the issue that would be quite nice, however I am not fully convinced yet.

• Lutris has the option to use a Lutris Runtime, which may be different from the SLR (haven't checked if it uses pressurevessel under-the-hood).
• Though Steam Deck-specific game issues were fixed in the past with the SLR being added, I am not sure why Vortex would be broken. Previous issues were related to DXVK if I recall correctly, whereas this appears to be some kind of .NET failure on SteamOS.
• This is a recent breakage with Vortex 1.8.0+ on SteamOS only (though maybe it's a system library mismatch issue).

Regardless though it isn't necessarily a bad change. Vortex with the SLR works fine still on my Arch PC though I am hesitant to enable it by default as this issue is only for SteamOS and I am not sure if it could have any Unforeseen Consequences:tm:. Proton is meant to be used with the SLR, but ideally we should be using Wine to run Vortex/MO2/etc. STL was written before there was this dependency on the SLR for running applications, and I have been trying to improve the situation. For a while the SLR didn't work at all with STL and so wasn't used at all, because of a change in how Steam passed the command. I figured out a solution in #737 and have been using this to add the SLR to more of STL's Proton launch commands. Right now it has only been tested when running games and not with utility programs like Vortex, so I am not sure if the SLR container might cause problems for Vortex, so it will need some testing even if it allows Vortex to launch.

[sonic2kk]

#807 is up to add the option to force the SLR with Vortex under Vortex Options in the Global Menu. This option is separate from the per-game Steam Linux Runtime option and for various reasons this option is currently disabled by default (it is highly experimental, compatibility is unconfirmed, etc).

As with the SLR used for a game, you need to make sure the SLR the current compatibility tool requires is already installed, as there is no way for STL to silently download SLRs from Steam. You can sure the tool's SLR is downloaded by running a game with that Proton version at least once, as Steam will check the toolmanifest.vdf for that Proton version and download the required runtime before game launch. If the runtime is not found, Vortex will not crash solely from this, but there should be no behaviour change.

You can check if the SLR was found in the steamtinkerlaunch.log, looking for setSLRReap or Pressure Vessel Funtime (the internal codename for fetching the SLR per-game). Afterwards you can check if it has loaded correctly by searching for a pv-bwrap and/or pressure-vessel-adverb process from your process monitor of choice.

The langfiles have currently only been updated for English. I do this during development in case the wording of strings changes, so I only update the other langfiles right before merging once the wording is final. If you don't use English as your STL language I can update the relevant langfile for you.

Enabling/disabling the SLR for Vortex should not impact game launches. If a game has SLR enabled but Vortex has it disabled, or vice versa, the SLR should be added/not added accordingly, at least during my testing so far.

---

If you'd like to test this feature, you can install the SteamTInkerLaunch-git vortex-slr branch from ProtonUp-Qt. You can then verify it's being used by checking your SteamTinkerLaunch version. It should be v14.0.20230520-3 (vortex-slr) or higher - the (vortex-slr) suffix is the hint that you're on the correct branch (I have several local branches and use this naming convention to stay somewhat organized).

Before testing, feel free to back up your existing Vortex prefix at ~/.config/steamtinkerlaunch/vortex. The compatdata folder could be renamed as a backup, meaning you could test a "fresh" Vortex installation, with GE-Proton8-2 and with the new Steam Linux Runtime option enabled for Vortex. Notably, this SLR option actually currently doesn't apply to installation, but I think that's fine. If DotNet is failing to install altogether then it may need to be enabled earlier in the Vortex process as well, but I can cross that bridge later.

If you don't want to test, no problem, I'll continue testing and maybe try on my Steam Deck if I get super curious, otherwise I'll probably merge after a while. There's no fixed time on when I merge, usually when I'm semi-confident something works and when I want to work on another feature without worrying about conflicts too much.

[sonic2kk]

Re-opening for visibility.

Using STL-git to install Vortex 1.8.X was confirmed to work again with GE-Proton8-2 on Arch Linux (#809), confirming again that this issue should only be specific to Steam Deck. Adding the SLR option for other use-cases on Steam Deck has helped some issues, so using the SLR with Vortex might resolve the issues there, too. I am just not sure yet if it is required for booting Vortex or if it is also/only required for .NET 6 installation (could be one or the other or both).

[pikdum]

Did some testing, using SLR Sniper seems to fix things.

[sonic2kk]

To confirm, Sniper should be used (to my knowledge) by most/all Proton 8 builds, so did #807 fix things? :-)

If so, I'll probably do a little bit of further testing and merge sometime today when I've had more coffee.

---

EDIT: I did a bit more testing, it still appears to work fine. Fresh installs succeed for me, and it doesn't break anything on my Arch PC. It sounds like it fixes issues on SteamOS as well. So because of this I have decided to enable the Vortex SLR by default. If it breaks anything, users can turn it off.

One caveat that applies to using the SLR in general with STL and probably other tools (unless they actually fetch it themselves, somehow) is that the required SLR version by a compat tool will need to be installed already. This can be installed manually from the Steam client from its tools list, or by running a game with the desired Proton version outside of SteamTinkerLaunch so that Steam downloads the SLR before the game launch.

STL fetches the required SLR based on the AppID specified in the Proton version's toolmanifest.vdf (we can get Steam app paths by AppID with steamtinkerlaunch gg <appid>). If the required SLR version is not found, we fall back to running without the SLR. This is true for all cases where STL uses the SLR, because we don't want to stop a launch just because the SLR is not found. There is logging in place to follow how STL did/did not find the SLR though.

I don't believe there's a way to silently download SLR versions from Steam (investigated in #737) and we cannot specify a required SLR AppID for SteamTinkerLaunch, as I think you're restricted to one SLR version (and we could need at minimum Scout, Soldier and Sniper) and it would force STL to run inside of the SLR which does not work. STL itself launches without the SLR (the launch command sent to Steam is just ./steamtinkerlaunch run) and we build the launch command for a game with/without the SLR after-the-fact.

[sonic2kk]

The option to use the Steam Linux Runtime with Vortex was added and enabled by default in #807. I will leave this issue opened for some further feedback. @pikdum @ajventer if this resolves the problem on SteamOS feel free to report back. If everything is good or if there's no response for a while I'll close this issue after some time myself :-)

Thanks!

[pikdum]

Does this also use SLR when installing Dotnet and Vortex?
And is there any configuration I need to do, or should it be automatic if I have a Steam Linux Runtime installed?
How does it know which to use if I have multiple?

$ find ~/.steam/steam/steamapps/common/ -name "SteamLinuxRuntime*" -type d
/home/deck/.steam/steam/steamapps/common/SteamLinuxRuntime
/home/deck/.steam/steam/steamapps/common/SteamLinuxRuntime_soldier
/home/deck/.steam/steam/steamapps/common/SteamLinuxRuntime_sniper

It's still hanging at installing Dotnet for me on Seam Deck.

[sonic2kk]

I used Sniper to install Vortex, and then let Vortex handle installing Dotnet itself.

Ah okay, so Vortex would've installed dotnet with Sniper. I opted to install dotnetdesktop6 with Winetricks (works on Linux Desktop) because I really don't want to let Vortex install stuff on its own especially under Wine.

Maybe Winetricks needs updated and STL didn't update it (no idea how the Winetricks stuff is handled on Steam Deck apart from I know STL will download it if it is missing), but you could try removing Winetricks from ~/.config/steamtinkerlaunch/downloads/winetricks.

My money is still on Vortex needing dotnetdesktop6 to be installed while Winetricks is running inside the SLR. Pain. I love my Steam Deck for gaming but detest working around stupid issues with it...

---

This is how I installed Sniper:

That should be fine, you can check if STL is running Vortex in the SLR by checking if pv-bwrap is running when you launch Vortex with STL (you can comment out the dotnet6 installation if you haven't got it installed with STL) and checking the STL log. On my PC it runs with Sniper correctly.

Tested with both Proton Experimental and Proton GE 8.3, not familiar with toolmanifest.vdf though.

Those should both be using Sniper. The toolmanifest.vdf for both of those will be in the compat tool's root folder (e.g. "Proton - Experimental" or "GE-Proton8-3").

[sonic2kk]

So since the SLR is a container, it can't access files in root directories, such as /usr/bin/winetricks or /usr/bin/wine. On Steam Deck this won't be a problem, but won't on the Linux Desktop, the primary userbase. I'm not super keen on having special case hacks and assumptions about where Winetricks and Wine is/isn't stored on SteamOS.

Winetricks will work if you have a scenario like this, where none of the paths are in a root folder:

"/path/to/SteamLinuxRuntime_sniper/_v2-entry-point" "--verb=waitforexitandrun" -- WINEPREFIX="/path/to/prefix" WINE="/path/to/proton" /path/to/winetricks -q dotnetdesktop6

This will install dotnetdesktop6 using Winetricks running inside of the SLR. This won't work on Linux Desktop because Winetricks is, usually, installed by the user in /usr/bin/wine, and pressurevessel can't access this by design.

I guess removing the dotnet install is the simplest solution here. I really don't want to leave it up to Vortex to install things under Wine, but I don't know if there's another way. It might be possible to do some hacky symlinking of Winetricks to ~/.config/steamtinkerlaunch/downloads/winetricks or something, but that would mean a big rework of how Winetricks works.

I will comment out the dotnetdesktop6 lines from STL for now, and you can let me know if that resolves it. If it does, I'll look into adding general support for installing Winetricks related stuff with the SLR in a later feature.

[sonic2kk]

105d7bb comments out the dotnetdesktop6 installation. Feel free to re-test when you get a moment :-)

This means Vortex will prompt you when it opens to install dotnetdesktop6. I would rather rely on Winetricks to do this, but running Winetricks in the SLR will be tricky and require some effort.

[pikdum]

That should be fine, you can check if STL is running Vortex in the SLR by checking if pv-bwrap is running

Not seeing it when at the "Installing 'Vortex'..." step:

$ ps -aux | grep pv-bwrap
deck       14332  0.0  0.0   6564  2420 pts/1    S+   20:08   0:00 grep --color=auto pv-bwrap

Hanging here too.

[sonic2kk]

The SLR isn't running at the installing Vortex step, it only runs with Vortex. See:

function wineVortexRun {
	sleep 1  # required!

	# Is there a way to improve this without the duplicated start cmd?
	if [ -n "${SLRCMD[*]}" ]; then  # Should only be set if VORTEXUSESLR is defined
		PATH="$STLPATH" LD_LIBRARY_PATH="" LD_PRELOAD="" WINE="$VORTEXWINE" WINEARCH="win64" WINEDEBUG="-all" WINEPREFIX="$VORTEXPFX" "${SLRCMD[@]}" "$@" > "$VWRUN" 2>/dev/null
	else
		PATH="$STLPATH" LD_LIBRARY_PATH="" LD_PRELOAD="" WINE="$VORTEXWINE" WINEARCH="win64" WINEDEBUG="-all" WINEPREFIX="$VORTEXPFX" "$@" > "$VWRUN" 2>/dev/null
	fi

	unset "${SLRCMD[@]}"  # Ensure SLR is removed so that it won't be fetched and set for games launched after Vortex
}

The SLR should really not be needed just to run the Vortex installer. That seems a bit excessive...

[pikdum]

Proton 8 in general seems to require SLR for everything on Steam Deck.

[sonic2kk]

Jesus Christ Valve. Ok, I'll make a branch that wraps the Vortex installation in the SLR.

[sonic2kk]

59f5f60 on branch vortex-slr-install wraps the Vortex installation in the SLR. Confirmed on my machine that it's running with the SLR during install, and in the logs I can see installVortex is using SLR in its install command.

Vortex successfully installed for me on my PC, and it installed dotnet6 as well. It gave a big prompt on opening telling me it needed to fix dotnet. After it installed dotnet and I restarted it, it didn't show the warning again so I guess it worked. I don't use or like Vortex so I can't really test anything beyond Vortex opening.

Feel free to try that branch and see if Vortex works, if you have any patience left (I have typed SLR more times in the last week than I ever wanted to...)

[pikdum]

"/path/to/SteamLinuxRuntime_sniper/_v2-entry-point"

Do you know the different between _v2-entry-point, run, and run-in-sniper?
I've been using run with my SLR testing.

[sonic2kk]

_v2-entry-point is what Steam uses to launch games. This selects whether to use run-in-[suite] or run. You can check the _v2-entry-point script in wherever SteamLinuxRuntime_sniper is installed (search in Steam, right click -> Manage -> Browse local files).

Probably shouldn't make much difference.

Should also point out again that this code was not written specifically for Vortex, it's been in STL for a while and is used to launch games even on SteamOS.

[pikdum]

Feel free to try that branch and see if Vortex works, if you have any patience left (I have typed SLR more times in the last week than I ever wanted to...)

Seems to have installed, at least I can see the application files in Program Files.
When launching, it's been stuck at prepareAllInstalledVortexGames for a few minutes now.
Not really sure what that part does, I'll try just exiting out.

[sonic2kk]

That part does take a while on my PC, doesn't take a few minutes but on SteamOS I have no idea, I use my Steam Deck almost solely for playing games vanilla.

prepareVortexGame to my knowledge sets up a bunch of stuff for the Vortex prefix like registry keys and setting up symlinks (afaik broken on SteamOS because it creates the compatdata in the wrong place for games).

[pikdum]

Exited out and retried a few times, but ./steamtinkerlaunch vortex start is crashing.

[sonic2kk]

I'll need a bit more info than that, can you find out why it's crashing? Is it starting the SLR process?

On my PC it's still running fine. It runs with and without the SLR, and I can see when the SLR option is enabled that pv-bwrap is starting for Vortex.

[pikdum]

Not really seeing any useful logs or output. Bit of a pain to debug stuff on a handheld, lol.

Let me try a few things.

[pikdum]

Weird, after restarting seems to work fine.

[sonic2kk]

Restarting your Steam Deck? Huh, that is weird...

Maybe there was a lingering Wineserver that didn't close. That's happened a few times (#730 iirc) and isn't specific to SteamOS or even Proton, it happens sometimes with Wine.

Cheers for sticking with this, especially doing it on a handheld (don't envy you, I did most of #629 on my Steam Deck and never again tbh lol). I do appreciate it.

So I guess installing Vortex with the SLR is required here. The check in the branch isn't even wrapped in the Vortex SLR check, so I'll probably fix that and then get a PR up.

I don't think any other changes were made, though if you'd like you could check on master and see if Vortex works there after a restart - in case a restart is all that was needed on master as well, but I doubt it because as you said, Steam Deck must really need those pressurevessel libraries...

[pikdum]

I was restarting after every attempt just in case, so should be good once vortex-slr-install is merged.

[sonic2kk]

I am re-testing now that the conditional logic is in place to ensure the SLR is still being used. The process still appeared, just waiting to see if Vortex installs itself properly and if it works as expected with the SLR option disabled. In the time it took me to get some pepsi and write this reply, I confirmed it works on my PC.

Once that's confirmed I'll merge the changes.

You've spent a lot of time across your repo and a couple of issues here investigating Vortex issues with STL, so I included a mention in the changelog (which will be copypasted for the release notes once a new STL version is out). I do appreciate all the help you've given for STL Vortex support (and you did all your debugging on Steam Deck!), even if I was a bit more "frank" than usual in this issue. I'm sure a lot of users will be very thankful for the help you've given as well.

[sonic2kk]

#816 is merged, the Vortex fixes should be in master now. Hopefully, maybe, with a tiny bit of luck, the Vortex app at the very least, will work across Linux Desktop and Steam Deck.

Re-opening this issue in case it still doesn't work and I messed something up in the conditional check I added.

---

Was able to confirm on master that VORTEXUSESLR works as expected to toggle Vortex using the SLR for installation and running, so I am inclined to close this if you're happy that it works on master @pikdum.