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.17k stars 73 forks source link

⚠ [Help wanted] Vortex Compatibility Testing #555

Closed sonic2kk closed 1 year ago

sonic2kk commented 2 years ago

Been spending some time trying to debug some issues I'm having with Vortex. I can't get it to launch at all with SteamTinkerLaunch and I can't seem to get any useful debugging output. When trying to launch for Vortex executable manually from the command line with WINEPREFIX=/home/blah/.config/steamtinkerlaunch/vortex/compatdata/pfx /home/blah/.local/share/Steam/compatibilitytools.d/GE-Proton7-29/files/bin/wine Vortex.exe it launches perfectly fine.

Is there a way to get further logging about what's going wrong with Vortex and Wine? The steamtinkerlaunch.log and installDotNet logs don't have anything useful, as dotnet seems to install fine (though Vortex prompts when I launch it that it needs DotNet6 and then seemingly installs it fine?) and the steamtinkerlaunch log just says "starting vortex with no commands" and then "vortex exited". Running steamtinkerlaunch vortex start from the command line doesn't produce any real output either.

I've kind of hit a wall here. Vortex seems to work without SteamTinkerLaunch but won't open when I try to open it from SteamTinkerLaunch. Anyone know what the problem could be?

frostworx commented 2 years ago

It looks like Vortex no longer works in steamtinkerlaunch (or the dotnet 4 installation used conflicts with some (wip?)) dotnet6 implementation) Either way I won't find the time and motivation to fix this issuee, because I don't use Vortex at all. I'll help anybody interested in submitting a PR to fix this when possible.

sonic2kk commented 2 years ago

Seems like Vortex is making an effort to target Wine, with the move to DotNet 6 actually making Vortex work out of the box with Wine 7.15 :open_mouth: https://github.com/Nexus-Mods/Vortex/issues/10686#issuecomment-1219083544

As that issue primarily mentions targeting Lutris, I'm not sure what the situation is for installing with Proton. But that issue is worth looking at for anyone that wants to take a look at the issue. Seems like Vortex in future could just need a specific path variable set and a reasonably up-to-date Wine version!

frostworx commented 2 years ago

ah nice. I've partially seen that thread, because the one person showing off their lutris script (or something similar) pinged me for doubtful reasons. haven't read the originally intended context of the thread though.

frostworx commented 2 years ago

crazy idea, but if vortex installs dotnet6 itself automatically correctly, it might be worth to test if the problem persist, if the dotnet install functions are commented out.

sonic2kk commented 2 years ago

This is actually something I was planning on trying haha, haven't gotten around to it as I'm working on a couple of other things but I could also see that working.

When launching Vortex with WINEPREFIX=/home/blah/.config/steamtinkerlaunch/vortex/compatdata/pfx /home/blah/.local/share/Steam/compatibilitytools.d/GE-Proton7-29/files/bin/wine Vortex.exe after installing from STL, it gave me the same prompt mentioned in this comment on another STL issue. However whenever I clicked "Fix", Vortex downloaded and installed DotNet6. When I restarted I was able to navigate the Vortex UI, I didn't try installing mods though, and Vortex still didn't launch from SteamTinkerLaunch.

I'm wondering if maybe STL trying to install dotnet48 (as it was previously required) messes up Vortex installing DotNet6, if it tries to install it itself at all. It might also be worth trying to get STL to export the DOTNET_ROOT (as mentioned in the earlier linked Vortex issue). Though I'm not sure, I guess this is meant to point to where DotNet6 is installed in the Wine prefix?

frostworx commented 2 years ago

I'm wondering if maybe STL trying to install dotnet48 (as it was previously required) messes up Vortex installing DotNet6

yeah, that's what I wanted to suggest. I'd guess as well that DOTNET_ROOT should point to a dotnet6 intallation. so a clean automated approach would probably be either

sonic2kk commented 2 years ago

Going to take a stab at fixing this over the weekend. Famous last words :-) I'll report back with anything I find out. I'll start by not installing DotNet6 at all and setting DOTNET_ROOT, and take things from there. We could run into a few issues since this might only work with very new versions of Wine - Wine 7.15, released August 19th, is the only one I've seen reports of working. I would say GE-Proton will have relevant patches eventually for this if it doesn't already.

If Vortex is starting to target Wine then in time hopefully the days of Vortex breakages will behind us soon :-)

sonic2kk commented 2 years ago

Even when trying to use system Wine (7.15) manually, I can't get Vortex to see the DotNet 6 installation :frowning:

frostworx commented 2 years ago

the days of Vortex breakages will never be behind us. dotnet is only one of multiple possible issues. have fun either way.

NicBOMB commented 2 years ago

ah nice. I've partially seen that thread, because the one person showing off their lutris script (or something similar) pinged me for doubtful reasons. haven't read the originally intended context of the thread though.

@frostworx :smile:

Going to take a stab at fixing this over the weekend. Famous last words :-) I'll report back with anything I find out. I'll start by not installing DotNet6 at all and setting DOTNET_ROOT, and take things from there. We could run into a few issues since this might only work with very new versions of Wine - Wine 7.15, released August 19th, is the only one I've seen reports of working. I would say GE-Proton will have relevant patches eventually for this if it doesn't already.

If Vortex is starting to target Wine then in time hopefully the days of Vortex breakages will behind us soon :-)

@sonic2kk I have gotten Vortex 1.6.8 working in the default wine prefix by doing the following:

I tested this on a clean prefix and on my used default prefix.

  1. Add .NET 4.8 Framework to the prefix via winetricks Default prefix: winetricks dotnet48. Custom prefix: env WINEPREFIX="/your/pfx/" winetricks dotnet48

  2. Add .NET 6 Runtime to the prefix via the executable installer Default prefix: Launch it with the "Wine Windows Program Loader" or wine start windowsdesktop-runtime-6.0.8-win-x64.exe. Custom prefix: env WINEPREFIX="/your/pfx/" wine start windowsdesktop-runtime-6.0.8-win-x64.exe

    Running the installers and .NET Framework && .NET Runtime The application loader uses `wine start /unix`, but the /unix option makes no difference to the installers or Vortex. The above link I provided is from the [official .NET changelog for 6.0.8](https://github.com/dotnet/core/blob/main/release-notes/6.0/6.0.8/6.0.8.md#downloads) and is also a [slightly newer link than the download used in Vortex as of writing this](https://github.com/Nexus-Mods/Vortex/blob/c70c502ed6c9219da62e3292734ca1ed4e17e20a/src/extensions/installer_fomod/constants.ts#L6-L7). [Per microsoft,](https://dotnet.microsoft.com/en-us/download/dotnet/6.0#runtime-desktop-6.0.8) > The .NET Desktop Runtime enables you to run existing Windows desktop applications. This release includes the .NET Runtime; you don't need to install it separately. The above installer includes runtime/host but not the .NET Framework. Unfortunately, the dotnet framework is still required by Vortex and is not provided by the latest installers. .NET 6 is therefore essentially another dependency on top of dotnet 4.8, which provides the framework. Vortex will complain about a missing or broken dotnet installation without both the .NET Framework and .NET Runtime since they are shipped separately. ~~thanks Microsoft.~~
  3. Run vortex-setup-1.6.8.exe or whatever the latest release is. Default prefix: Launch it with the "Wine Windows Program Loader" or wine start vortex-setup-1.6.8.exe Custom prefix: env WINEPREFIX="/your/pfx/" wine start vortex-setup-1.6.8.exe

  4. When Vortex finishes loading it will complain about a broken dot net installation, or even indicate the native linux runtime was selected. Ignore Vortex's struggling and select the quit option when prompted or close Vortex yourself.

    fix prompt? Vortex will run the installer when using the provided fix button, but will continue complaining about the missing/broken .NET after installing and reopening since it is still looking in the wrong place by default. You need step 5 to fix that. Since Vortex also uses an older link for .NET 6, I opted to recommend these steps instead. It's just better to fix it before Vortex prompts the user.
  5. We will now use the previously mentioned environment variable DOTNET_ROOT to negate the error. Default prefix: 
    env DOTNET_ROOT="c:\Program Files\dotnet\\" wine start /d "c:\Program Files\Black Tree Gaming Ltd\Vortex" Vortex.exe

    Custom prefix:

    env WINEPREFIX="/your/pfx/" DOTNET_ROOT="c:\Program Files\dotnet\\" wine start /d "c:\Program Files\Black Tree Gaming Ltd\Vortex" Vortex.exe

    The above paths are relative to the wine prefix which guarantees the .NETs we just installed are selected. in dos land case sensitivity doesn't exist for paths so c: is C:, still so cursed everytime writing a command like this, smh You now have Vortex running with the appropriate .NET. No errors should appear on startup. :clap:

Also, I have been contributing directly to Vortex and gotten the development environment building on Linux. A native linux package of Vortex has a non-zero chance of occurring, which may obsolete all of this.

sonic2kk commented 2 years ago

Holy heck! Thank you so much for the detailed writeup and excellent news!

So the dotnet48 winetrick is still required, gotcha. I understand the consensus is that DotNet 6 installs and Vortex works with Wine 7.15, though STL is currently set up afaik to use a user-selected version of Wine as I believe the version of Wine used to run Vortex is also the version used to run the game once its launched. I'm aware there are no guarantees that your steps will work with, say, GE-Proton7-30, but I will try them nonetheless if nothing else but out of morbid curiosity :smile:

(If it still requires dotnet48, I wonder if #549 (which seems to be Steam Deck only) is unrelated to this. There are other reports of Winetricks not working on Steam Deck so it could be an entirely unrelated matter?)

Also, I have been contributing directly to Vortex and gotten the development environment building on Linux. A native linux package of Vortex has a non-zero chance of occurring, which may obsolete all of this.

Assuming a native Linux Vortex package appears and works with installing mods for games running through Proton, this would probably obsolete all of this - but imo that would be a very worthy successor to the hoops we currently jump through to install and use Vortex on Linux with Wine. Personally I would be very happy to see a native Linux Vortex and have STL integrate with that. Perhaps that could even allow for better integration on Steam Deck and maybe even STL running through Flatpak Steam!

Of course I understand that isn't a guarantee that a native Linux build will appear, so for the meantime, looking into getting Vortex working with Wine again is probably fine. A native Linux package once it appears will need testing too but as mentioned if a package did come along and obsolete this, I'd be perfectly happy with that :slightly_smiling_face:

Thanks for outlining the steps needed. I'll see if I can implement this into STL once I have a moment (of course anyone else that wants to contribute is welcome to, as I am in-between PRs here and working on adding STL to ProtonUp-Qt). And also a big thanks for your efforts on trying to improve the Linux Vortex experience upstream :+1:

SeongGino commented 2 years ago

So basically, in a legitimate (and largely successful) attempt at making Vortex Linux-friendly, the change has subsequently broken its behavior on Linux environments with a pre-existing dotnet-host.

This. Is. Hilarious. XD

...a-Anyways--I found that prepending the env var DOTNET_ROOT="c:\Program Files\dotnet\\" before the steamtinkerlaunch vortex start command works in a terminal, but same method doesn't seem to work in the context of a .desktop starter. I'm assuming that's simply a limitation of XDG app files, but mayhaps STL might wanna export this value itself in the future?

Guess we can add this along with Halo MCC in the top 10 Linux Oopsies for this year, of games that try to support the platform only to cause more unintended issues. I am laughing at this more than I should, but it is also genuinely appreciated to see progress like this in embracing Linux for game modding.

*Though, if Vortex is to be made a native app, I do hope it'll have some way of forking off utility processes in Wine, since a lot of Skyrim animation mods rely on Nemesis, it and FO4 use BodySlide for models, others using xEdit (which currently doesn't work for texture generation in Wine???), and so on.

sonic2kk commented 2 years ago

Though, if Vortex is to be made a native app, I do hope it'll have some way of forking off utility processes in Wine

I also hope this to be the case for the exact reasons you outlined. Being able to run Nemesis and BodySlide was essential when I used MO2 to mod Skyrim SE.

I found that prepending the env var DOTNET_ROOT="c:\Program Files\dotnet\" before the steamtinkerlaunch vortex start command works in a terminal, but same method doesn't seem to work in the context of a .desktop starter

Adding variables like this in a .desktop file can be really finicky because of how escape characters work I believe. At least in my experience this has been a massive headache. For one of my own projects I had to do something like this:

Exec=env WINEPREFIX="/home/user/Downloads/WineApp/pfx" wine C:\\\\users\\\\user\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start\\ Menu\\\\Programs\\\\App\\ Space\\ Name.lnk
NicBOMB commented 2 years ago

So basically, in a legitimate (and largely successful) attempt at making Vortex Linux-friendly, the change has subsequently broken its behavior on Linux environments with a pre-existing dotnet-host.

No attempt was made based on .NET version change alone? Vortex changing .NET version seems largely separate from the status of building on non-windows platforms, let alone running in WINE.

...a-Anyways--I found that prepending the env var DOTNET_ROOT="c:\Program Files\dotnet\\" before the steamtinkerlaunch vortex start command works in a terminal, but same method doesn't seem to work in the context of a .desktop starter. I'm assuming that's simply a limitation of XDG app files, but mayhaps STL might wanna export this value itself in the future?

The Exec key does not provide variable assignment like a shell. You need to use env to add the variable, then the command.

Adding variables like this in a .desktop file can be really finicky because of how escape characters work I believe. At least in my experience this has been a massive headache. For one of my own projects I had to do something like this:

The problem lies in the Exec key's escape logic. In the Desktop Entry Spec,

to unambiguously represent a literal backslash character in a quoted argument in a desktop entry file requires the use of four successive backslash characters ("\\\\").

So you've gotta spam those or write your command into a field which will populate those slashes for you, like the properties menu of a desktop entry in Dolphin (plasma desktop's file manager). It's really not too much trouble. For example, I wrote a whole shell script into the Exec key of my desktop entry.

Try Exec=env DOTNET_ROOT='c:\\\\Program Files\\\\dotnet\\\\' steamtinkerlaunch vortex start

SeongGino commented 2 years ago

No attempt was made based on .NET version change alone? Vortex changing .NET version seems largely separate from the status of building on non-windows platforms, let alone running in WINE.

I was just making an observation as a mere user, was all. It's half-joking.

So you've gotta spam those or write your command into a field which will populate those slashes for you, like the properties menu of a desktop entry in Dolphin (plasma desktop's file manager).

Today I Learned:tm:. That's what I'd guessed, but good to have a source on that as well, thank you.

Arcitec commented 2 years ago

Initial install in STL in the Steam Flatpak was easy. STL successfully installed dotnet48 and then Vortex.

Fun fact. DotNet6 runs for me. I just had to run Vortex with GE-Proton 7-31. On first start Vortex gave me a "message log" popup with some error about a missing DotNet DLL and a button to Fix it. (That EXACT same dialog with same text shows up on Windows too.)

Clicking Fix made me briefly see a DotNet window which vanished quickly. I guess Vortex triggers a silent install.

On next launch of Vortex, there was no more warning and the app runs normally.

But... I got a notification on Vortex saying that Hardlinks mode has been removed from the app and that it wanted to fix my settings. I clicked fix and it switched to softlink mode. I went back into settings and tried to change Deployment Mode and Vortex only has softlinks, no other modes.

When I look in the game folder it seems like there are no mod links/files in there.

sonic2kk commented 2 years ago

Fun fact. DotNet6 runs for me. I just had to run Vortex with GE-Proton 7-31

Ah! 7-31 has a Wine update so perhaps that could be related!

But... I got a notification on Vortex saying that Hardlinks mode has been removed from the app and that it wanted to fix my settings. I clicked fix and it switched to softlink mode. I went back into settings and tried to change Deployment Mode and Vortex only has softlinks, no other modes.

When I look in the game folder it seems like there are no mod links/files in there.

I'm not totally sure what this means as I don't use Vortex but this could be related to Flatpak. Did Vortex remove your mods or is it just not seeing them now?

Arcitec commented 2 years ago

@sonic2kk

Did Vortex remove your mods or is it just not seeing them now?

Vortex lists my installed mods for the game (Mods I have installed VIA Vortexx), but it doesn't place the mods in the game's folder. I think this is because it's trying to make symlinks instead of hardlinks (STL's wiki says that hardlinks are the only method that works on Linux). So if Vortex has removed hardlinks, which it seems like, then that is bad news for us.

sonic2kk commented 2 years ago

Ah, I understand now. So Vortex itself has removed support for this kind of mod, and this feature being missing isn't a bug on STL's side. But still it means currently Vortex mods don't work, which is not good news.

I wonder why symlinks don't work and if this is something Vortex could fix on their side.

Arcitec commented 2 years ago

Yep. But it might be possible to make soft symlinks work on Wine... Or to edit Vortex config to force it to use old hardlink method (it cannot be selected via its GUI but maybe it still has code for it).

NicBOMB commented 2 years ago

I wonder why symlinks don't work and if this is something Vortex could fix on their side.

This is why.

NicBOMB commented 2 years ago

But... I got a notification on Vortex saying that Hardlinks mode has been removed from the app and that it wanted to fix my settings. I clicked fix and it switched to softlink mode. I went back into settings and tried to change Deployment Mode and Vortex only has softlinks, no other modes.

This is inaccurate. Hardlink mode is still present. You were simply warned that Vortex cannot deploy your mods. You may need to change your mod staging folder to a location on the same drive as the game. In the Vortex settings->mods->mod staging folder use a path like Z:\path\to\Storage\Vortex Mods\{GAME}\mods where the real mount path is /path/to/Storage I am still using Hardlink Deployment for multiple games. What game were you trying to deploy mods to?

frostworx commented 2 years ago

If you look a bit closer, steamtinkerlaunch already takes care that the staging dir is on the same partition as the game is, so messing around manually is not required when using it (when it works again 😏...)

steamtinkerlaunch prepares one VORTSETCMD cmd (VORTSETCMD="$STLSHM/vortset.cmd") by adding all vortex configuration options "required" for every game found, including the staging dir found. Depending on the list of installed, compatible games, this file can become pretty big.

When done, this file is run once within the vortex prefix to set up all games without any further user-configuration. This worked fine before, so if it no longer does something changed, apparently. Likely VORTSETCMD has some hints which variable/path broke.

frostworx commented 2 years ago

just ran DOTNET_ROOT="c:\\Program Files\\dotnet\\\\" steamtinkerlaunch vortex start (didn't test if the variable had an effect) with a clean ~/.config/steamtinkerlaunch/ after ~7 minutes Vortex opened (vortset.cmd had >170 lines which look fine so far) After clicking the new fix, dotnet6 seems to have installed correctly (haven't compared the before/after compadata). Unfortunately, unlike before, no of the detected games was set as "managed" automatically, but I was able to add Fallout4 by clicking manage. It kept its autoconfigured hardlink path as valid. Doesn't look THAT broken than what I have expected after this long discussion (sorry, haven't read everything) @ modders, I'd suggest you try to reproduce this and see if a managed game actually can be modded or not. Maybe the issue just requires a tiny fix. good luck so far!

edit: Vortex.exe --set settings.mods.activator.fallout4="\"hardlink_activator\"" (cut from the autocreated vortset.cmd) no longer seems to work, maybe the escaped quotes need to be removed (again?)

steamtinkerlaunch vortex getset still also outputs settings.mods.activator.fallout4 = "hardlink_activator" (after having it set to managed manually above), so the option seems to be unmodified otherwise.

frostworx commented 2 years ago

fyi (update from here):

Apparently I wasn't able to express correctly what I wanted to say with my last two comments in #555 (explains the silence following 😀) I do not think that it is broken very much. Likely only three fixes are required to get it completely working again as it worked before:

frostworx commented 2 years ago

I'll also add an automatic installer for dotnet6 (recycling the vortex download if available and downloading it automatically otherwise). Seems like the "Fix" button installation does not always work reliably (it is dotnet, so expected) and Vortex will loop in a FIX -> Install loop. I hope by installing dotnet before we have the chance to workaround this issue somehow.

NicBOMB commented 2 years ago

I'll also add an automatic installer for dotnet6 (recycling the vortex download if available and downloading it automatically otherwise). Seems like the "Fix" button installation does not always work reliably (it is dotnet, so expected) and Vortex will loop in a FIX -> Install loop. I hope by installing dotnet before we have the chance to workaround this issue somehow.

This may be helpful for installing dotnet 6 before Vortex https://github.com/NicBOMB/Vortex/blob/wine-installer/installer-scripts/vortex-installer.sh

frostworx commented 2 years ago

Thanks, @NicBOMB but too late 🤓 Already added it just right now with above commit

edit: hah, forgot to look for and add the silent flag. Thanks. Saves me searching 😀

NicBOMB commented 2 years ago

Thanks, @NicBOMB but too late nerd_face Already added it just right now with above commit

edit: hah, forgot to look for and add the silent flag. Thanks. Saves me searching grinning

You should download the latest installer (6.0.9) instead of 6.0.6. Links can be found in sub-directories here https://github.com/dotnet/core/tree/main/release-notes/6.0. Microsoft also publishes checksums which should be used to verify the downloaded file.

frostworx commented 2 years ago

Yeah I've seen 6.0.9 exists, but seems like 6.0.6 is currently used by Vortex (first attempt is to get the url directly from the app.asar file, my 6.0.6 is the hardcoded 2nd choice)

frostworx commented 2 years ago

In theory, Vortex should work just fine in the current state - reports would still be fine.

The only thing missing is the (optional) automated activation of the autodetected games, which worked perfectly fine before, by setting settings.mods.activator of the corresponding game to hardlink_activator automatically.

Apparently, this does no longer work (or better is no longer enough to actually activate the game)

When activating a game from within Vortex directly, the following three configurations options are automatically added for the activated game (besides settings.mods.activator):

settings.profiles.activeProfileId
settings.profiles.lastActiveProfile.$NEXUSGAMEID
settings.profiles.nextProfileId

All three have a random 9 chars long value. No idea yet, if those options need to be set now as well to actually activate the game, but the above commit introduces a (wip) command line option to activate a game within Vortex, which also tries to set those options to a random string. It does not work yet for still unknown reasons, but might help to further debug this. (example: steamtinkerlaunch vortex activate 996580)

(Vortex is a bit with confused/confusing with using quoted configuration options, still possible that this might cause new problems as well)

frostworx commented 2 years ago

ah, probably the NEXUSGAMEID directory in ~/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/AppData/Roaming/Vortex/ might need some autogenerated files as well to activate the self-rolled random string above.

./snapshots
./snapshots/snapshot.json
./profiles
./profiles/rkrOqInbs

maybe next week... 👋

edit: nope, seems like the ldb binary blobs in state.v2 are the problem. like not fixable, if Vortex doesn't offer a command line option to activate a game

NicBOMB commented 2 years ago

ah, probably the NEXUSGAMEID directory in ~/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/AppData/Roaming/Vortex/ might need some autogenerated files as well to activate the self-rolled random string above.

./snapshots
./snapshots/snapshot.json
./profiles
./profiles/rkrOqInbs

maybe next week... wave

edit: nope, seems like the ldb binary blobs in state.v2 are the problem. like not fixable, if Vortex doesn't offer a command line option to activate a game

Vortex already has a helper library which detects where Steam games are located. It will do so when given a valid Steam Library to read from. My installer copies the user's actual Steam Library configuration into the Vortex prefix and replaces the unix paths to each library's location with the generic C: Steam Library location. Then, by linking all real game locations to their respective location in that generic Steam Library, Vortex extensions can automatically detect Steam games without issue. The only downside to this approach is needing to update the symlinks when new games are added or installed games are moved in the native Steam library. Everything else game detection related can be solved within Vortex normally, like setting your own download and staging folders (although the option to have that process automated by your script is neat).

TLDR: Vortex is already looking for the games. Your strategy seems to be fighting with the command line interface, rather than leveraging the detection measures Vortex and its extension authors have already implemented to correctly identify games. So work with Vortex, not against it?

frostworx commented 2 years ago

not helpful in any way

frostworx commented 2 years ago

@ "😕" - Why not work with steamtinkerlaunch, not against it? 🤨

NicBOMB commented 2 years ago

@ "confused" - Why not work with steamtinkerlaunch, not against it? raised_eyebrow

Don't get me wrong, I do think it would be nice to be able to activate a game in the way you are describing. However, as an end user, I can already activate a game which has been detected by Vortex in 1 click on the game list view. Your implementation seems like over-engineering a script to edit Vortex via a fully featured CLI. I wrote my script in bash, so you could easily copy paste any portion of it directly to STL. I would like to see my strategy implemented instead, but I wasn't holding my breath for another contributor to or jumping to make those changes myself since I expected this response and I'm more interested in porting the app directly to Linux. My script not having a proper GUI to launch the symlinker, but already having a simple function call for it, I think, makes it a good fit for STL, but

not helpful in any way

is a quick way to turn down a suggestion. :shrug:

frostworx commented 2 years ago

Sorry, some of your replies seem to simply want to advertise your scripts for me and not actually help. Likely a misunderstanding from my side, so apologies for that.

No offense, but no - I won't copy paste anything from your script. I'd say the style doesn't match... I also haven't looked through your scripts in detail, but pretty much everything seems very limited and hardcoded and therefore adopting the code is no option as well (couldn't find your "strategy", but only read a few seconds in it).

Vortex offers exactly those command line parameters which are required to automatically activate all compatible installed games automatically. This worked excellent for a long time and apparently no longer does. So who works against whom? You might have missed that steamtinkerlaunch already does tons of automatic symlinking and I see absolutely no reason why I should spend even more time into more functions to work around the broken feature. I do not even use Vortex (or MO2). Would be nice for modders for sure when you succeed with your attempts. Good luck and much fun with it any way. Would make sense to freeze this "issue" until you're done, and then wait if someone is interested in adding a PR for your fork. shrug

frostworx commented 2 years ago

In theory, Vortex should work just fine in the current state - reports would still be fine.

The only thing missing is the (optional) automated activation of the autodetected games, which worked perfectly fine before,

I haven't touched Vortex since. Does anybody want to confirm or reject this?

sonic2kk commented 2 years ago

I haven't gotten around to testing yet but several users have reported issues with setting up "staging folders" and deploying mods with Vortex. I don't use Vortex so I'm not sure what this means but if anyone could look into this specifically that would be awesome - This seems to be the main problem people are having lately with their Vortex games and STL (and maybe in general with Vortex).

It seems like staging folders in z:\ paths are causing issues when users try to deploy mods. It seems like Vortex complains about permissions and not being able to write to a folder on a z:\ drive path, like z:\home\user\mods or whatever. If someone with experience modding games with Vortex could test and see what works, what doesn't and if applicable how to fix issues, as well as attaching any relevant log files (I think Vortex has specific logs but I'm not sure where?) it would be really helpful in figuring out the status of Vortex at the moment!

Even though I don't use Vortex I own several games compatible with it, so if there are any fairly straightforward steps to reproduce - and hopefully subsequently resolve - issues I can help try to verify this. Given my inexpensive with Vortex it's very possible that I could end up diving into using it and messing something up completely unrelated to STL, so reports from users that know what they're doing with Vortex are more than welcome to submit reports!

frostworx commented 2 years ago

Thanks for the summary. Indeed several people claim that the staging folders are broken. Whenever I test this, they still work for me, so we need additional information, apparently.

steps to reproduce from scratch (please ask if something is unclear)

If something does not work as expected during above steps, you're invited to report with brand new log (created during the steps above) steamtinkerlaunch.log installDotNet.log, vortset.cmd might be interesting (YMMV)

I haven't tested any further usage while writing this, but for the beginning it is enough to know if the above steps cause any trouble for anybody. If Vortex behaves unusual from here, this is a separate issue (which can be hopefully fixes from our side one day)

Happy testing

edit: as mentioned above, the windowsdesktop-runtime download urls built into Vortex seem to be fragile, so in theory it would be the best implementation to try that download first (to make sure the same tested version is used in the first place) and if it fails, pick the correct version from https://github.com/dotnet/core/tree/main/release-notes/6.0 and extract the up to date url and check sum from the corresponding subdirectory md (similar as @NicBOMB suggested earlier) I won't jump through the hoops and implement anything which uses this weird fragile structure though ("yeah sure we bought github, but we do not provide sane downloads anyway for our own stuff") If nobody wants to PR this, I guess the easiest solution would be to add user-configurable download urls and checksums (or better Vortex provides working download urls somewhere)

sonic2kk commented 2 years ago

Ah! Thank you! I will test this as soon as I have time but, I wonder if the problem stems from users wanting to change the staging folder? It seems like users want to change this folder to something else from the reports that I have seen. That would explain why it doesn't work. And in fact I could see why a user would want to do that, many times mods are stored on other drives because their game drives might be too small to store mods. But of course there's nothing STL can do about this - If you're using Vortex regularly you would need to do this (when I tested it out years ago with Lutris, you needed to install your Vortex instance onto the same drive as your games)

I wonder if symlinking mods to that staging folder would work? Probably not if we need to use Vortex hardlinking on Linux.

Interesting though, the steps seem clear enough to follow so once I have time to download a few mods for a chosen game I'll give it a shot!

frostworx commented 2 years ago

the staging folder needs to be on the same physical partition as the game. it is used for the active mods, not for the downloaded ones. iirc you can also change the staging folder, but I'm sure many users would do it wrong (and actually already do).

edit: as always very nice of you that you test, but it would be nice to see some vortex users help as well.

Arcitec commented 2 years ago

Hi again, the thing that complicates makes totally fucking impossible (🤣) all testing for me is that I use Steam Flatpak, and the Flathub SteamTinkerLaunch is outdated because it uses tagged releases (not git-master). I cannot test new patches that I do not have access to, sorry. :/

I am on SteamTinkerLaunch 11.11, which by the way is unable to download GE-Proton as you know. I am starting to wonder if the Flathub version of STL should move to being built from Git-master instead. Here you can see how outdated it is:

https://github.com/flathub/com.valvesoftware.Steam.Utility.steamtinkerlaunch/blob/master/com.valvesoftware.Steam.Utility.steamtinkerlaunch.yml#L50

Furthermore, I can at least report that the Vortex "Hardlink Deployment" choice has come back in the Vortex GUI, so it's not removed, which is good news.

Arcitec commented 2 years ago

I compiled a flatpak version of the latest git commit for STL...

So far I am trying to install a Skyrim mod collection. I noticed 1 problem so far: Vortex isn't running with proper Locale I guess?

locale-error

I opened the archive manually to check what the filename really is and I see that it's like this:

actual-file

Edit: It's the 8.4.2 pack from https://www.nexusmods.com/skyrimspecialedition/mods/2347?tab=files, I am gonna keep investigating...

I suspect that this file is misnamed by the mod author, but at the same time I suspect that STL can start Vortex with some proper Locale info to make Vortex able to find that file.

Arcitec commented 2 years ago

The other issue I discovered is that if you get a notification about mod conflicts, and click resolve, you get the UI for resolving order. I then clicked the "???" field to mark it as "load after (suggested)". This made Vortex completely freeze. I had to force kill it after a few minutes of waiting.

freeze

frostworx commented 2 years ago

thanks for testing. for flatpak related issues please use the flatpak issue. can't help with that. Currently it is not unlikely that your screenshot issues are either flatpak and/or proton related, because I see nothing which would point to a steamtinkerlaunch issue at the moment.

NicBOMB commented 2 years ago

The other issue I discovered is that if you get a notification about mod conflicts, and click resolve, you get the UI for resolving order. I then clicked the "???" field to mark it as "load after (suggested)". This made Vortex completely freeze. I had to force kill it after a few minutes of waiting.

freeze

I encountered this as well, though not on the STL flatpak. I did not need to kill the window. Simply minimizing and maximizing a few times seemed to refresh the window. Your results may vary.

Arcitec commented 2 years ago

@frostworx Yeah the crash is probably Wine-related, but the Locale (filename language interpretation) issue is probably STL related. Starting Vortex with some Wine flag to set the language/filename interpretation is probably gonna fix that.

frostworx commented 2 years ago

@frostworx Yeah the crash is probably Wine-related, but the Locale (filename language interpretation) issue is probably STL related. Starting Vortex with some Wine flag to set the language/filename interpretation is probably gonna fix that.

then adding restoreOrgVars before the vortex launch should work, which sets LC_ALL to system default. edit: assuming flatpak doesn't do something additionally here, of course

Arcitec commented 2 years ago

I encountered this as well, though not on the STL flatpak. I did not need to kill the window. Simply minimizing and maximizing a few times seemed to refresh the window. Your results may vary.

Thanks, will try that next time it hangs. I just successfully used that window this time without it hanging.

then adding restoreOrgVars before the vortex launch should work, which sets LC_ALL to system default. edit: assuming flatpak doesn't do something additionally here, of course

Yeah setting LC_ALL sounds correct. But I can't build the Flatpak with that change so I cannot test it. Was hard enough to make a flatpak build from a specific git commit. It downloads the source code from GitHub every time it generates the flatpak, so I can't change things.

Anyway I have now deployed to Skyrim, things generally worked pretty okay. List of issues: