Symlinking Vortex directories fails on Arch Linux for Fallout New Vegas, possibly others

[macinsight]

Hey fw,

I just confirmed that symlinking fails for Fallout: New Vegas when using Proton 6.17-STL after a fresh install of both F:NV and STL.. Pretty much everything related to Vortex fails, it seems. (Yes, I know, descriptive, but I am braindead right now. Will update later)

Here is the stl.log, the relevant logfile under $STLCONFIG/logs[...] does not exist.

If you need any additional information, shoot.

[frostworx]

hi mi,
please describe exaclty which steps you took so I cvan reproduce this here.

[macinsight]

Warning: Might contain a lot of babble. You asked.
Yeah, okay, I also said I'd update, didn't I?

---

1. Removed Fallout: New Vegas by uninstalling it through the Steam UI installation should not matter, but removing an outdated compatdata might lead to different results indeed
2. Cleaned up any residual files still lingering by rm -rf'ing the F:NV directory inside steamapps should not affect steamtinkerlaunch, but sure why not
3. Removed STL by running yay -R steamtinkerlaunch, not required, as you installed the same system-wide files again later - could have been related, if the previous install was manual and with a different (git)-version
4. Removed the AUR helper package cache (I like as much free space as I can get, thank you)
5. Removed $HOME/.config/steamtinkerlaunch always good for a clean test
6. Rebooted, just to be sure. sure why not, but should not be related - instead removing the temp. directory /dev/shm/steamtinkerlaunch/ would have been the better step here
7. Switched over to my nvidia card using optimus-manager
8. Opened Steam
9. Installed STL from AUR
10. Installed F:NV from Steam
11. Set STL as launch argument for F:NV I recommend using it always as compatibility tool for windows games and only as launch argument for native linux binaries, the launch argument code might be outdated and might be even removed, depending on how much time I spend into the project in the future
12. Added F:NV to Steam Category "Vortex"

should happen automatically, but might be a good idea to separately install vortex into its own prefix here initally via command line

9. Started F:NV, expecting STL to pop up.
10. Saw STL popping up as expected
11. Installed Vortex through the STL UI (Main Menu -> Vortex -> Install) using Proton-6.17-STL **internally this simply starts the command line installer, but might cause conflicts with a 2nd running steamtinkerlaunch instance (don't think so, though)
12. Watched the script install the STL Proton Version, .NET 4.x, etc a separate install log file is created in /dev/shm/steamtinkerlaunch/
13. Saw Vortex starting
14. Checked symlink config using stl vortex symlinks
15. Saw it was missing the symlink from steamapps/common (Arch) to steamapps\common (Windows) (Or the other way around), among others (Possible cause for failure to discover Steam Library? libraryfolders.vdf exists and point to $HONE/.steam/steamapps) ah, haven't checked your log yet, but that very likely IS the problem
16. Added that particular symlink manually. manual changes might help in your situation but don't help with the initial problem - so the results are unrelated
17. Verified that Vortex is able to find steamapps/common now. 16
18. Saw it is also missing the symlink from/to $stl/vortex/downloads as well. same cause
19. Came here and opened this issue
20. Ate Hähnchenbrustfilet with rice. nomnom

Now that I think about it, where do you source the vortex-symlinks from? I think there's a git repo somewhere hosting a file called "vortex-symlinks.sh". Might be that that's the cause, if it's in fact using that script. You do in fact do everything in the stl script (Also, props, this thing is massive, if unwieldy.)

[macinsight]

Note: Just grabbed another machine (Thank god I have so many!) and did the same process (minus the removing, 'cause that was a fresh arch install with my setup-script). The only different step was that I added stl to compatibilitytools.d instead of using it as launch command.

The issue persists. See screenshot for existing symlinks after a fresh install.

[macinsight]

Here's the "Games with Vortex Support" list. It's identical on both machines. F:NV is added to SteamCat "Vortex"

Edit an hour after posting the embedded screenshot: Now it's at least showing up there properly. Still no working mods, though.

[macinsight]

Oh, yeah, and the Vortex "Downloads" folder gets set automatically to, in my case, Z:\home\jh\.config\steamtinkerlaunch\vortex\downloads. This causes mod deployment to break and scream in agony, as hardlink is required, which in turn requires everything (close enough anyway) to be on the same drive, which, as can be seen, is not the case. I assume that that's also an issue caused by the feckered symlinks.

Oh, and trying to manually symlink /home/jh/.config/steamtinkerlaunch/vortex/downloads to C:\users\steamuser\AppData\Roaming\Vortex\falloutnv\downloads fails with "The path you selected refers to the same directory on disk as the existing one". Am I reading that right and is Vortex actually smart dumb enough to notice when it's a symlink, or am I just dense today?

[frostworx]

thanks for the comprehensive but unwieldy report.
I'll try to look deeper into it soon. for now I'll start with crossing out some probably unrelated points of your list above (feel free to comment if you think it is related)

steamtinkerlaunch usually autodetects/autocreates a "staging" directory per steamlibrary partition, so mods are always on the same partition like the actual game files (default is a Vortex directory besides every steamapps directory).
The only exception is ~/.config/steamtinkerlaunch/vortex/downloads/, because I felt it would be better not to drop a 3rd party directory into ~/.local/share/Steam/ which regularly is on the same partition as well and therefore valid (likely I documented this also in the wiki in detail(?))

[macinsight]

It does create the staging directory for Vortex under ‘C:/$FalloutNewVegas/Vortex’, that’s working. Vortex is resetting its download directory to ‘Z:/[…]’ however, and me trying to force it to be on ‘C:/‘ doesn’t work, unsure why.

As C:/ and Z:/ are not the same partition, Vortex errors out. And symlinking the Z:/ location to a valid C:/ location errors out with “The path you selected[…]” as mentioned above, causing Hardlinks and thus mod deployment to fail.

[macinsight]

Just got home and confirmed that the error that Vortex is throwing is (Unless somehow rights management is being applied (?!) is bogus. It's erroring out saying that F:NV must be on the same drive as the staging folder, which is the case.

For reference:
F:NV Install-path: C:\Program Files (x86)\Steam\steamapps\common\Fallout New Vegas (Manually symlinked since it, as referenced above, would fail to find the F:NV directory otherwise.)
Vortex Staging: C:\Vortex Mods\falloutnv.

The file __vortex_staging_folder exists under the Vortex Staging path.

Edit: *Also note that we're now working with STL set up as compatibilitytool instead of using it as launch option, which was the step I mentioned in #414 (comment).

[frostworx]

Just tested a bit and I can confirm that something is fishy with NewVegas.
It is easier explained with the following screenshots, both New Vegas and Oblivion are on the same separate partition.

New Vegas: Apparently the mod staging folder is wrong here as it still used the Vortex-default USERDATA variable.
The function in steamtinkerlaunch is pretty much generic and works for "all" (almost) games as expected, so this requires some separate tuning at least for NV. Do you get the same red errors in Vortex as well?

Oblivion; The autogenerated mod staging folder entry is identical to the autogenerated/-detected staging folder created on setup.

TL;DR:
should be fixable pretty easy, after a deeper review. can't tell when though.

[macinsight]

Alright, so at least it’s reproducible and I’m not (too) insane. That’s a relief.

Nuking and testing again now, following recommended procedure. Thank root for my 250mbit line (Thank you, Telekom! Hard enough as it is.).

And yes, I’m getting the exact same error as you posted above for F:NV.

[frostworx]

No fix yet, but a little description.
When initially launching
steamtinkerlaunch vortex install (or start)
among multiple other automated things, a temporary vortex.cmd file is generated in /dev/shm/steamtinkerlaunch
which gathers all Vortex commands and is started when done to auto-apply all Vortex settings at once (much faster than calling every single command on its own, and there's no better way to modify the Vortex internal db, I tried and even asked upstream somewhere)

(at least) for New Vegas the
Vortex.exe --set settings.downloads.path=\"Z:\\home\\USERNAME\\.config\\steamtinkerlaunch\\vortex\\downloads\"
is wrong. I just need to find the reason :)
scratch that - this is the download path, which is correct, but you get the point :)

edit:
btw, you can remove any game any time from ~/.config/steamtinkerlaunch/vortex/compatdata/seenvortexgames.txt
to force a re-check for the removed game.

edit2: ah, Hamburg! Great city! :)

edit3:
would have been too easy - the entry in the cmd is correct:

Vortex.exe --set settings.mods.installPath.oblivion=\"Z:\\media\\B4-1\\SteamLibrary\\Vortex\\{GAME}\\mods\"
Vortex.exe --set settings.mods.installPath.newvegas=\"Z:\\media\\B4-1\\SteamLibrary\\Vortex\\{GAME}\\mods\"

[frostworx]

stl vortex getset
outputs the current config of Vortex. Looks like settings.mods.installPath is not even set for New Vegas (and for several other games?), so Vortex simply falls back to its internal default (which is wrong for us linuxers)

[macinsight]

stl vortex getset outputs the current config of Vortex. Looks like settings.mods.installPath is not even set for New Vegas (and for several other games?), so Vortex simply falls back to its internal default (which is wrong for us linuxers)

That's another issue, getset prints an error message. I'll get back to ya in a bit about that, though I think I mentioned it somewhere.

[frostworx]

note for me:
Add a (basic)

steamtinkerlaunch vortex set $config

command line option to set Vortex configs manually easily (at users own risk)
f.e. something like

stl vortex set installPath oblivion "Z:\\path\\to\\SteamLibrary\\Vortex\\{GAME}\\mods"

[frostworx]

stl vortex getset outputs the current config of Vortex. Looks like settings.mods.installPath is not even set for New Vegas (and for several other games?), so Vortex simply falls back to its internal default (which is wrong for us linuxers)

That's another issue, getset prints an error message. I'll get back to ya in a bit about that, though I think I mentioned it somewhere.

you mentioned it in some closed issue, so no idea where, but this usually works and very likely did not work for you because of a non-default proton version used.

[frostworx]

btw your initial log is incomplete (likely caused by starting the launcher via guy/2nd instance).
Already got an own full log, so no need to upload another one.

edit:
the log is fine. I guess at least NVC (and probably some other Bethesda games) have some registry entry, which is used/missing here and needs to be created first. I once rewrote major parts of the Vortex implementation, and I'm pretty sure I dropped those functions as "no-longer-needed"
Will stop here with debugging for now.

[macinsight]

you mentioned it in some closed issue, so no idea where, but this usually works and very likely did not work for you because of a non-default proton version used.

I'm using, as of now, Proton 7.1 GE-2 for F:NV (pulled via steamtinkerlaunch dcp or what it was) and the STL-supplied Proton version for Vortex. If that classes it as a non-default proton version (Which, I guess, it does).

[frostworx]

you mentioned it in some closed issue, so no idea where, but this usually works and very likely did not work for you because of a non-default proton version used.

I'm using, as of now, Proton 7.1 GE-2 for F:NV (pulled via steamtinkerlaunch dcp or what it was) and the STL-supplied Proton version for Vortex. If that classes it as a non-default proton version (Which, I guess, it does).

The "STL-supplied" proton version, is the version which is used by default for the Vortex prefix.
When using getset that proton version is used (the proton version used for the game doesn't matter).
So please recheck with a clean setup and open a new issue (or reopen the one you already replied) with a log if the problem persists.

[macinsight]

And yes, Hamburg's a great city! 😄 Well, I'm in Geesthacht now, rent is cheaper. Then again, only Berlin and Munich are more expensive than HH, so... yeah.
If you're ever up here, hit me up! I owe you a beer, both for trying to debug this mess and for creating stl in the first place.

And I'll run getset once I finished eating.

[frostworx]

No hurry, I'm almost offline for today.
We might make a short trip to Hamburg again this year indeed (~5hrs, I'm in "Underfrangen" ;) ), so thanks for the offer :)

[macinsight]

See #417 for #414 (comment)

I'm in "Underfrangen"

Oh god. Okay, you bring the beer! Spent years in Bavaria (Abensberg to be precise). Absolutely great beer all around, especially Kuchlbauer, imo. Still get a case every couple months from down south.

[frostworx]

Hehe, (don't know Kuchlbauer yet, but) generally I prefer Schwarzbier which is not very popular in Bavaria for whatever reason :)
For example the "Möchshof Schwarzbier" is pretty good. CZ has good beer as well (f.e. černý Kozel), but my all time favorite is
"Carlsberg Jacobsen Porter" from Denmark - unfortunately almost impossible to buy it in (southern) Germany
(Carlsberg online shop is in an under construction endless loop)

[macinsight]

Interestingly (Assuming this is not default or expected behaviour, because I am unsure what even goes as default or expected here), everything is working fine and dandy after:

1. Starting from a clean, serene setup
2. Setting STL as Compattool
3. Setting the Game Directory for F:NV inside Vortex to Z:/home/$USER/$FNV-Path
4. Setting the staging folder to Z:/$STL/vortex/staging
5. Setting the download folder to Z:/$STL/vortex/downloads
6. Thus ensuring everything is in the same place and on the same partition for Vortex

The only issues I can currently see are:

• that STL seems to see some behaviour as F:NV unexpectedly closing. It at least says "The game exited unexpectedly after 1 second`. Everything launches fine, however. So I am not exactly sure what is being seen as an unexpected shutdown.
• that STL does not recognize NVSE_loader.exe and associated files and thus does not prompt for NVSE launching (yes, I chmod +x'ed everything related to NVSE.), but that can be worked around by simply renaming nvse_loader.exe to FalloutNVLauncher.exe.

After this procedure, Vortex works like it should and everything is working as expected.

[Retrograde-i486]

So I've been following this thread and just wanted to add, the one time I got MO2 working (like last May) with Skyrim was when it was on the same drive as my os install. Based on your #6 I'm assuming that still needs to be done? Bit annoying as I have a separate drive for games but was curious. This isn't related to steamstinkerlauncher but just wanted to check.

[frostworx]

@macinsight :

The only change which (likely) really needs to be done is setting
settings.mods.installPath.newvegas to
"Z:\YOURSTEAMLIBRARYPARTITION\SteamLibrary\Vortex\{GAME}\mods"

Some Proton versions (mostly GE) and also some games fork separate processes in the background and therefore the main process can return "too early". steamtinkerlaunch has some basic function to workaround this, but in rare cases this can still trigger the "unexpectedly closing"

@Retrograde-i486

Sorry, I have no clue how #6 is related here.
Either way, it indeed might be possible that Skyrim is affected as well from this "New Vegas" problem (and maybe some more Bethesda games), so I assume it will also work when I'm done.

[frostworx]

I think I found the initial problem (on vortex side) - need more time to investigate further and for a fix

[frostworx]

The problem was/is the following:
steamtinkerlaunch ships a static self-rolled list (/usr/share/steamtinkerlaunch/misc/vortexgames.txt) of vortex compatible games with their SteamAppid , the actual name and the "nexusgameid".
Seems like this "nexusgameid" changed for several titles (including newvegas, skyrimse and several others)

I'll push a commit after this comment, with several changes in that list, and also some (minor) changes in the code.
New Vegas, SkyrimSE, some other titles should work now, some others probably need additional changes.

If someone has an idea how to best drop that static list completely, you're very welcome to share it,
else the bundled list needs to be tested and maintained permantently.

I'll open a sticky issue soonish which describes the issue and also lists tested working and non-working games.

[frostworx]

sticky issue here:
#418

[macinsight]

Hm... I just nuked everything on my dev-machine and tried to see if anything had changed concerning F:NV and STL.
Answer: Kinda!

Now, when I...

• Install F:NV
• Launch t
• Quit it after first startup
• Install Vortex
• Launch Vortex

then it still fails to discover F:NV unless I manually direct it to Z:/home/jh/steamlibrary/Fallout New Vegas. Once that is done, it still fails to manage it, but errors out with a different error message, namely saying that Vortex is trying to look in Z:\Vortex\falloutnv\mods\__vortex_staging_folder, which does not exist, and is thus unable to manage F:NV (Why would it try to check in the root directory of Z?) (Yes, I know why, but still...)

Oh, and vortex getset still fails, so I can't be of as much help as I'd like to be.
Logfile here: steamtinkerlaunch.log

[frostworx]

the steps to reproduce are incomplete/useless.
manually changing anything apparently leads to an unexpected result.
so please continue with reproducing all steps here first:
#417 (comment)
This should generate a complete log with hopefully useful pointers to the problem.

[frostworx]

A (more than) complete list with steps for a clean test

[frostworx]

ping?