[Skyrim SE] SKSE won't load properly when launched from the game prefix (Vortex)

[dermalikmann]

System Information

• SteamTinkerLaunch version: 2a4db27
• Distribution: Manjaro, up2date as of 2023-06-20_16:15:00+0000
• Installation Method: source
• Vortex version: 1.8.5
• SKSE version: 2.2.3rev6 on SSE 1.6.640.0.8
• Mod list:
  • RaceMenu AE 0.4.19.14

Issue Description

Well, I hate to open an issue, but I kinda dont know what to do anymore.
SKSE does not properly load, regardless if I start it by letting the wait timers run out on launch, or interrupt the vortex timer, open vortex and start the game from there.

The result I observed was the same either way: I start a new save, get to the character creation menu, but instead of the expected RaceMenu tabs, i just get empty tabs titled $EXTRAS and $EXPRESSIONS

The reason I belive that there is something wrong with STL/Vortex tho, and not with SKSE, is, that

1. I do get the xterm window with the SKSE log (see below)
2. There is actually some difference between lauching through Vortex and launching straight from STL.
   Namely: When I got Nordic UI/SkyUI/SkyHUD installed, the Mod Configuration menu actually gets properly populated by launching it through Vortex, but not thourgh STL itself.

Also, to eliminate that question from the get-go: Yes, I have made sure that STL actually launches skse64_loader.exe

Logs

Launch from STL

steamtinkerlaunch.log
skee64.log
skse64.log
skse64_loader.log

Launch through Vortex

steamtinkerlaunch.log
skee64.log
skse64.log
skse64_loader.log

---

If you want I can also do the same with Nordic UI enabled, tho I thought the more minimal the setup the better.

[dermalikmann]

Ah what the heck, here it is with Nordic UI

Straight form STL

skee64.log
skse64.log
skse64_loader.log
steamtinkerlaunch.log

Through Vortex

skee64.log
skse64.log
skse64_loader.log
steamtinkerlaunch.log

I also just noticed one more small difference:
I only get the "Mods active, no Achievements 4 u" message when launching through Vortex AND having the Nordic UI + deps. installed (plus only the three UI mods have a checkmark next to their ESPs in the native mod menu, and RaceMenu does not)
This really points to a SKSE loading problem, but the fact that its can partially load, but loads further depending on launch method, also points to some STL environment shenanigans, imo. :/

[sonic2kk]

I'm sorry but mod issues are not SteamTinkerLaunch issues. I'm not sure what you'd like me to do here. If you're expecting mod support I can't really help, especially if STL is launching the script extender mod. Though really if STL gets as far as launching Vortex that's about all that I can do from my end. Issues after that can't be resolved by me.

SteamTinkerLaunch manages launching tools but it's up to users to get mods themselves working. I cannot and do not provide mod support. Unless I'm missing something it sounds like you've got Vortex launching but you're having issues using a specific mod, so you're asking for mod support. I utterly detest Vortex so I'm missing some of the context and want to make sure I'm understanding properly.

If it is a mod support issue you'll have to ask around elsewhere, this doesn't seem like a SteamTinkerLaunch bug. Mod compatibility is never guaranteed on Linux.

---

Just saw your second reply, apologies.

This really points to a SKSE loading problem, but the fact that its can partially load, but loads further depending on launch method, also points to some STL environment shenanigans, imo. :/

I have only modded SkyrimSE through MO2 and it was a long time ago and only briefly, so I'm gonna take your word as someone more knowledgeable than me that this could be an SKSE loading issue.

If that's the case, it could be a Wine/Proton version issue, noting that launching through Vortex and launching directly with STL are probably using different Proton versions. But I'm not sure why a mod not working on Linux immediately points to SteamTinkerLaunch. And either way, mod compatibility issues would need to be investigated by users. If there is an issue that I can fix I can apply it, but I can't be the one to investigate.

[sonic2kk]

It happened in #837 so I'll also point it out here just in case: Make sure you're using the right version of SKSE ano/or relevant mods. Different versions may be required for different game versions of DLC. I'm not too sure, I'm a MO2 user and an Oblivion gamer, but because it came up before it's something else that might be worth checking.

[dermalikmann]

You are probably right about it not being directly dependent on STL itself. I will do some more research, and if I find, that it actually is a bug in STL I will reopen this :)
Have a nice day, and thx for your continuation of this awesome project :)

[sonic2kk]

No problem, if you do find something that STL needs to set feel free to re-open or open a new issue.

I was not able to investigate the SKSE logs you attached (they're probably the main ones that have any useful information I'd guess) because opening and browsing text files efficiently on a phone is apparently much more difficult than you'd think (don't have access to my PC currently, in the middle of a small move). But having said that it might be useful to attach the logs from SKSE anywhere online or use the information inside them to troubleshoot further.

It might also be worth trying v12.12 and seeing if SKSE works there, just to make sure #784 did not cause this. I would say I'd hope it would've been reported before now, but I'm not sure how many people actually use STL from git to test and find bugs 😅

I think previously LC_ALL was for getting Vortex to start so I don't think it would be related in any way to mods, I don't think a locale variable would need to be set to C for mod support to be honest.

Have a nice day, and thx for your continuation of this awesome project :)

No problem, and if you make any progress and remember do report back (feel free to re-open for visibility, I often miss closed issues) so that either I can try and fix something, or document something.

[dermalikmann]

Update: I kinda feel bad rn, that I even bothered you with that. I have a very similar behaviour on windows too, so this has obviously nothing to do with STL.

[sonic2kk]

It's no problem, I appreciate the follow-up! From a quick search yesterday I did see some similar issues posted online but sometimes these can be red-herrings and also I lack a lot of the context around the specific modding process for this game especially with Vortex, so it's all kinda Greek to me :-)

It might be total gibberish or irrelevant but one thing I did see mentioned was to launch a specific SKSE executable I think. Maybe that doesn't apply anymore or doesn't apply to Linux/Vortex/both.

If you figure out what the problem is and if there's a manual step needed that can be documented/applied to STL feel free to open an enhancement, either to document what the step is or to discuss adding it to STL if it's straightforward enough.

[dermalikmann]

Update 2 and a reason to reopen this 😅

I found the underlying problem. The issues I had on windows were somewhat of an user error. The RaceMenu plugin was simply not activated. But this pointed me into the right direction and made me try it on linux again.

After going on a journey of how plugins get loaded for SSE and how to activate and deactivate them on manual level, I noticed that Vortex is running inside its own prefix - just as the Wiki explains 😁

But exactly there is the problem. SSE loads Plugins via files inside of %LOCALAPPDATA%/Skyrim Special Edition which is inside of the Vortex prefix, and not inside of the Game Runtime prefix.

The easiest workaround for me for now was to just copy the two files in there to the SSE compdata prefix and tadaa - suddenly my mods worked.

After I figured that out, I was kinda confused why seemingly noone noticed that until now. My guess probably is, that most folks just run the game through vortex, which launches the game not inside the official compdata, but the STL-Vortex compdata. This is sadly just not really viable for me, as my machine is not powerful enough to run an already resource-demanding electron app through wine - which does not help improve that situation - and running the game at the same time.

[sonic2kk]

Thanks for the follow-up! Hopefully this is a straightforward fix for STL to implement. There is also some steps that could be documented I think around this, basically to tell users to do this manually in case STL fails to do so.

The easiest workaround for me for now was to just copy the two files in there to the SSE compdata prefix and tadaa - suddenly my mods worked.

So I'd like a bit more context around this:

• Is this Skyrim Special Edition folder created by Vortex, or SKSE? I am wondering this for two reasons
  • Does this apply to other Creation Engine Bethesda games? For example, Fallout 4, Fallout 76, SkyrimVR, etc
  • Does this apply to older Bethesda games with Vortex, such as Fallout: New Vegas or Oblivion?
  • Does this apply to other moddable Vortex games?
  • Is there a consistent way to "guess" the name for this folder? e.g. will it use the Vortex name (see the names in vortexgames.txt, i.e. "Fallout: New Vegas" becomes "Fallout New Vegas" without a colon)

If this is some generic behaviour, it should be easy to look for the folders here and symlink them based on the Vortex name (usually the game name without special symbol, colons, etc) . This would avoid having to, for example, hardcode a list of names in the code. But this leads to a couple more questions:

• Does your workaround work if you symlink the Skyrim Special Edition folder from the Vortex appdata to the game prefix appdata?
• Does your workaround work if you symlink the files only (e.g. create the Skyrim folder yourself in the game prefix, but symlink the files you mentioned into that folder)
• Could you give some more info on the files you copied? Are they specific to your mod, or SKSE, or something else entirely?

Please feel free to provide screenshots if you can of the folder structure/paths, just for extra, extra clarity to my ignorant eyes :-)

---

I ask these questions because if we can get the folder names "automagically" without extra hardcoding, we should be able to do the following:

• On a Vortex run without the SLR (probably won't allow symlinks), check if we need to create any symlinks from the Vortex prefix to the game prefix
• In the Vortex prefix, if we have a folder at the appdata (such as %LOCALAPPDATA%/Skyrim Special Edition), then create a symlink in the game prefix if it doesn't exist already

Using a symlink at the folder-level instead of copying files or even symlinking individual files should cover any cases where the contents of this game appdata folder changes. For example if any extra files are added, the folder in the game prefix appdata will not need to be updated as the symlink will just point directly to the Vortex prefix.

I would also prefer to symlink each game's appdata folder from the Vortex prefix instead of the entire appdata. Ideally we would only symlink the relevant per-game folder from the Vortex prefix to the game's prefix (i.e. don't symlink a Fallout 4 folder to the Skyrim folder). I would also not want to overwrite anything in the appdata folder for the game if I can help it. In short, it would be much, much cleaner to just symlink the relevant per-game folder.

---

This is sadly just not really viable for me, as my machine is not powerful enough to run an already resource-demanding electron app through wine - which does not help improve that situation - and running the game at the same time.

I don't use Vortex, but if I did, I would also not want to launch a game through Vortex. In fact, I am a bit surprised this works given DRM limitations. I suspect Vortex is installed with Proton which may copy the Steam exe to the prefix and thus allow things to work, but I haven't checked the code. Still, it is much more desirable to launch without Vortex. Games should be launched in their prefix. I will add a note about this on the wiki too once this is resolved :-)

Also, even though I use vscodium begrudgingly, Electron apps are a pain. Chromium is such a resource hog.

---

I appreciate the investigation here. It seems like, if the odds are in our favour here, the solution is to find and symlink the relevant game folder from the Vortex prefix to the game prefix, e.g. in this case, if we're going through all Vortex games:

1. Check Vortex appdata to see if a matching folder exists, e.g. if we hit Skyrim, check if %LOCALAPPDATA%/Skyrim Special Edition exists
2. If so, and if Skyrim is installed, symlink this folder to the Skyrim prefix (we can get this based on appid, which we already have thanks to vortexgames.txt)
3. This can be checked at each startup and only if the SLR is disabled as this will probably stop symlinks from working correctly, but I'll need to test this

If you could test and report back on the questions I had that would be great! If you can't answer them no worries, like if you don't own any other Bethesda games to find out what names they use for their folders etc. The most straightforward fix would be to just check for and symlink folders in a hardcoded fashion but I like to over-complicate things 😅

Fingers crossed this is a straightforward fix! I don't have access to my PC at the time of writing but later today I should get it set up again and I should be able to take a look at this. I may need your help testing though ;-)

P.S. if you'd like to look into this yourself please stop me and mention, I'm trying to get better at allowing others the opportunity to contribute if they want, but of course there is never any pressure 😃

[dermalikmann]

• Does this apply to other Creation Engine Bethesda games? For example, Fallout 4, Fallout 76, SkyrimVR, etc
• Does this apply to older Bethesda games with Vortex, such as Fallout: New Vegas or Oblivion?

I have no info on that, I could check FO4 sometime later (probably this evening or on the weekend)

This should be from SKSE and not from Vortex, as the %LOCALAPPDATA%/Skyrim Special Edition directory existed in the runtime prefix too (which, as we established, never was touched by Vortex)

Does your workaround work if you symlink the Skyrim Special Edition folder from the Vortex appdata to the game prefix appdata?

I have actually done it the other way around, with ~/.confg/stl/.../vortex/.../Local/SSE being the symlink and ~/.confg/stl/compdata/SSE/.../Local/SSE the real directory. But it should work SSEcompdata -> Vortexcompdata too. (Yes, I symlinked the symlink, from Vortex -> STL compdata shortcuts -> Steam runtime compdata)

I dont see any "Linux level" difference between linking the dir or the files inside the dir, but if you want I can check this later.

Could you give some more info on the files you copied? Are they specific to your mod, or SKSE, or something else entirely?

loadorder.txt defines, well, the order in which the plugins get loaded. this is for priority reasons (e.g. two mods want to modify the same thing. only the last mod changing that thing will take precedence - read: the later to more important).
plugins.txt defines what to load at all. lines beginning with a * are enabled, without are disabled.

(Both files are my currently active config, with a lot of additions. Ignore the content itself :)

Both files start with # Generated by vortex because they are. You can modify those files per hand tho, if you dont use Vortex. I think they are actually generated by a programm called LOOT (Load Order Optimization Tool)

I will add a note about this on the wiki too once this is resolved :-)
This reminds me, there should also be a comment added, that you need to skip Vortex at least one time, because if you start STL, open vortex, close it and then the game auto runs, and you do this every time, you wont get asked if STL should launch SKSE or the vanilla exe

[sonic2kk]

Thanks for the info! Since this is specific to SKSE (and perhaps other script extender tools e.g. F4SE) and based on other info it's probably safe to just symlink.

One more question:

(Both files are my currently active config, with a lot of additions. Ignore the content itself :)

Are these two files the only things present in that folder? Just these two text files? Just wondering :-)

[dermalikmann]

Jup

[sonic2kk]

Interesting, I just checked and for New Vegas (a game I have never modded with Vortex), I have a "FalloutNV" folder in the Vortex and game prefix. I can't find any part of the code that does this though. The files were last updated in May 2023 though so... I have no idea 🤷‍♀️

Well anyway, it seems there may not be a good way to tell what the folder names will be for the script extenders, since the New Vegas folder is "FalloutNV". I wonder if the unpacked Vortex app has any hints on what it might name the folders as, so that I can figure it out for each game...

[sonic2kk]

Oh, I missed this until now.

This reminds me, there should also be a comment added, that you need to skip Vortex at least one time, because if you start STL, open vortex, close it and then the game auto runs, and you do this every time, you wont get asked if STL should launch SKSE or the vanilla exe

I had no idea STL did this, and when I was browsing the code just now, I see where it does it. Interesting!

[sonic2kk]

Interesting. On my system, the Vortex prefix contains a bunch of symlinks in its AppData/Local, and these point to equivalent folders in per-game prefixes. For example:

• AppData/Local/FalloutNV in the Vortex prefix points to the same folder in the New Vegas prefix
• AppData/Local/Oblivion in the Vortex prefix points to Local Settings/Application Data/Oblivion in the Oblivion prefix
• AppData/Local/BloodstainedRotN points to Local Settings/Application Data/BloodstainedRotN in the Bloodstained: Ritual of the Night prefix

I am installing SkyrimSE to check what the behaviour is on my machine with that game.

[dermalikmann]

Very intresting. This suggests that something has to have that logic already, but I grepped through stl and was not able find "FalloutNV" or "BloodstainedRot" anywhere in it. Vortex cant really be creating those Symlinks either, because it does not know its running in a proton prefix and especially does now know that there are two prefixes (vortex and runtime).

Could it be that you created those Symlinks yourself some time ago while debugging something linke this already?

I am also fetching FO4 just now, to check what this will do.

---

Edit: Wait... could it be that this is doing exactly that? and if so, why didn't it do it for SSE (at least in my case) 🤔
This also explains why nobody complained about that (with both MO2 and Vortex), because it should already do that...

[sonic2kk]

I think you're right, good spot! I had a look at this yesterday but I was still quite confused.

STL only runs this for Vortex-compatible games that it hasn't "seen" before (list is in seenvortexgames.txt). There are a couple of symlinking functions that it runs and I'm currently on a lunch break so I can't investigate too much. But I did a very quick test where I installed:

• SkyrimSE and Fallout 4 (apparently didn't finish downloading but will probably have the same behaviour)
• Removed the AppData/Local folders for Oblivion and SkyrimSE from the Vortex prefix (Skyrim Special Edition and Oblivion respectively)
• Removed SkyrimSE and Oblivion from seenvortexgames.txt
• Re-ran steamtinkerlaunch vortex start

And the results were that an Oblivion symlink was created in the Vortex prefix (including INI symlinks in Documents/My Games), but SkyrimSE was skipped entirely! Looking at the logs:

Oblivion

prepModGameSym - Not creating symlink from '/run/media/username/BigSSD/Games/steamapps/compatdata/22330/pfx/drive_c/users/steamuser/Local Settings/Application Data/LOOT' to '/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/AppData/Local/LOOT', because '/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/AppData/Local/LOOT' is a real directory
prepModGameSym - Removing symlink '/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/AppData/Local/ModOrganizer' pointing to '/run/media/username/BigSSD/Games/steamapps/compatdata/22330/pfx/drive_c/users/steamuser/AppData/Local/ModOrganizer'
prepModGameSym - Creating symlink from '/run/media/username/BigSSD/Games/steamapps/compatdata/22330/pfx/drive_c/users/steamuser/Local Settings/Application Data/ModOrganizer' to '/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/AppData/Local/ModOrganizer'
prepModGameSym - Removing symlink '/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/AppData/Local/Oblivion' pointing to '/run/media/username/BigSSD/Games/steamapps/compatdata/22330/pfx/drive_c/users/steamuser/AppData/Local/Oblivion'
prepModGameSym - Creating symlink from '/run/media/username/BigSSD/Games/steamapps/compatdata/22330/pfx/drive_c/users/steamuser/Local Settings/Application Data/Oblivion' to '/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/AppData/Local/Oblivion'
prepModGameSym - Not creating symlink from '/run/media/username/BigSSD/Games/steamapps/compatdata/22330/pfx/drive_c/users/steamuser/Local Settings/Application Data/cache' to '/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/AppData/Local/cache', because '/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/AppData/Local/cache' is a real directory

SkyrimSE

setModGameSyms - Found game 'Skyrim Special Edition (489830)' with pfx '/run/media/username/2B/Games/steamapps/compatdata/489830/pfx'
prepModGameSym - Not creating symlink from '/run/media/username/2B/Games/steamapps/compatdata/489830/pfx/drive_c/users/steamuser/Documents/My Games/Skyrim Special Edition' to '/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/Documents/My Games/Skyrim Special Edition', because '/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/Documents/My Games/Skyrim Special Edition' is a real directory
prepModGameSym - Not creating symlink from '/run/media/username/2B/Games/steamapps/compatdata/489830/pfx/drive_c/users/steamuser/Documents/My Games/Skyrim Special Edition' to '/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/Documents/My Games/Skyrim Special Edition', because '/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/Documents/My Games/Skyrim Special Edition' is a real directory

There was some extra logging that I put in for debugging which i didn't include here. But what I've found from these logs is that, for some reason, STL never tries to create a symlink for SkyrimSE, but it does for Oblivion. I suspect that same would happen for the other games that have symlinks in my Vortex folder.

It's strange that this is happening, I'll need to look into this some more, but I think you're right - There is code that is meant to do this, but which is not.

I thought that maybe the common denominator was that New Vegas and Oblivion were modded by me with MO2 and are supported by MO2, but I don't think Bloodstained and some others are. I also have No Man's Sky installed and that was seen by MO2, but it wasn't symlinked. So this is a massive shot in the dark, but I wonder if spaces in the folder names is causing issues. I do have one symlinked folder with spaces in the Vortex prefix though so I'm also doubtful of that. I'm not sure why this isn't working for SkyimSE.

I have Oldrim and Fallout 3 in my library, I will download those and check this evening.

[dermalikmann]

Thank you for being so quick about it and looking into it :)
My PC crashed some time ago, and i have to redownload FO4, but i can do Oldrim too while i am at it.

---

Update: FO4 got a symlink, but in My Documents/My Games/Fallout4

prepareVortexGame - Preparing Vortex game 'Fallout 4 (377160)' with Nexus GameID 'fallout4'
notiShow - Message 'Preparing Vortex game 'Fallout 4 (377160)' with Nexus GameID 'fallout4'' should go to StatusWindow
setModGameSyms - Found game 'Fallout 4 (377160)' with pfx '/opt/games/steamapps/compatdata/377160/pfx'
prepModGameSym - Creating symlink from '/opt/games/steamapps/compatdata/377160/pfx/drive_c/users/steamuser/My Documents/My Games/Fallout4' to '/home/malik/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/Documents/My Games/Fallout4'
setModGameSyms - '/opt/games/steamapps/compatdata/377160/pfx/system.reg' not found
prepareVortexGame - Game dir for '377160' found is: '/opt/games/steamapps/common/Fallout 4')

Seems line Oldrim/SkyrimLE got a link too

prepareVortexGame - Preparing Vortex game 'Skyrim (72850)' with Nexus GameID 'skyrim'
notiShow - Message 'Preparing Vortex game 'Skyrim (72850)' with Nexus GameID 'skyrim'' should go to StatusWindow
setModGameSyms - Found game 'Skyrim (72850)' with pfx '/opt/games/steamapps/compatdata/72850/pfx'
prepModGameSym - Creating symlink from '/opt/games/steamapps/compatdata/72850/pfx/drive_c/users/steamuser/Documents/My Games/Skyrim' to '/home/malik/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/users/steamuser/Documents/My Games/Skyrim'
prepareVortexGame - Game dir for '72850' found is: '/opt/games/steamapps/common/Skyrim')

Turns out, you dont have to wait for the DL to complete, as STL just checks the install location, which is created as soon as the game DL starts :D

[sonic2kk]

It turns out the symlink will only be created if the Skyrim Special Edition folder exists in the Skyrim game's Local/AppData, then the Vortex prefix will get the symlink it. It doesn't work the other way around, if the Skyrim folder exists in the Vortex prefix then it isn't moved to the game prefix and symlinked.

If you move the folder from the Vortex AppData/Local to the game prefix AppData/Local, and then remove the game from seenvortexgames.txt, then it will get symlinked to the Vortex prefix. But the behaviour we want is the other way around; existing load order info from Vortex should be symlinked to the game prefix.

My guess based on this behaviour is that STL intends for games to be launched from Vortex? Since it symlinks from the game prefix to the Vortex prefix, which would only be required if there was INI/load order info only in the game prefix but not the Vortex prefix. This would also explain why Vortex is installed with the Proton script and not the Wine binary, because this allows the Steam.exe and associated information to be set in the game prefix so that games launch. It also looks like registry information is modified for the Vortex prefix so that games can run in it. The reason STL symlinks from the game prefix -> Vortex prefix and not the other way around is because if you have any existing load order info in the game prefix, it wants Vortex to be able to read and modify it when running from Vortex.

I don't like this behaviour or use-case, so I will probably make an effort to support the opposite use-case, allowing load-order information set in the Vortex prefix to be accessed by a game prefix.

I am not sure of the best way to tackle this, to be honest. My guess is that checking if there's a non-symlink, regular folder in the Vortex AppData/Local for a game (i.e. it isn't part of the STL exclude list which is a Microsoft folder, cache folder, maybe some others), then we should symlink to the game AppData/Local, but only if the equivalent in the game prefix is empty or doesn't exist. For example with Skyrim:

1. If there is a Skyrim Special Edition folder in the Vortex prefix that is NOT a symlink
2. If there isn't a Skyrim Special Edition folder in the SkyrimSE prefix OR if that folder is empty
3. Create a symlink from the Vortex prefix to the SkyrimSE prefix

The problem is applying this, since this folder probably won't exist before Vortex starts up once, but will exist once SKSE is installed with Vortex and executed once (which we can only really guarantee at shutdown). There is probably a place this can be executed, just not sure where yet. This isn't something we'd want to run all the time, only during Vortex-specific operations (there is probably a place where this could be executed in the code, I just haven't checked yet).

At worst, it could be added as a Vortex command-line option.

[dermalikmann]

Hmmm...
AFAIK SKSE is creating this dir initially. As I installed SKSE through Vortex in close to all of my tries, and did not wipe STL in the runs I installed it manually, it did not create the symlink.

One possibile way of handling this would be to just create those symlinks every time a game gets launched (I am speaking of the symlink for that game, not all symlinks lol)
It does not occupy any drive space, it would prevent cases like this, where people only install the script extender after already having opened Vortex/MO2 at least once, and jsut creating a symlinks takes close to no time at all. Sure, maybe there is a dead smylink in my Vortex prefix, dangling and pointing to a nonexistend dir in my FO4 prefix, but what harm would that actually do? IMO, none.

---

Whoops, wrong button.

[dermalikmann]

Oh, i just saw you added some stuff.

STL intends for games to be launched from Vortex?

No, i dont think so. As those files are not bound to the Mod Tool, but to the game, i guess its done this way to ensure portability (it was also the "direction" to do it, that first came to my mind)

This would also explain why Vortex is installed with the Proton script and not the Wine binary.

This could be it, but it could also be for compatibily reasons. The Vortex dev is quite loud spoken about wanting people to run Vortex through proton to keep it as "close" to the game as possible.

registry information is modified for the Vortex prefix so that games can run in it.

if your are talking about the vortset.cmd, that is so that vortex can "autodetect" the games. That is just that vortex is easier to use, as it wont find the games in Z:\....

I don't like this behaviour or use-case, so I will probably make an effort to support the opposite use-case, allowing load-order information set in the Vortex prefix to be accessed by a game prefix.

Again, this load order is not related to vortex, but to the game. I think it is best to keep it with the game, and not the modding tool. If I wanna switch over to MO2 tomorrow, i would have to port my load order manually (I know there are tools for switching the tools, thats not the point I am trying to make here :P )

I think the main issues in your suggested way of doing it, would go away by sticking to link from the Game to Vortex (meaning the Game has the real directory and Vortex the Symlink) and, altho hacky and kinda stupid, top just create or check and create for the symlink when the game starts.

---

As you said you are in the middle of a move, don't stress yourself about it and take your time. If someone else has this issue, we can just reference them to this thread.

---

Another way of handling this would be to just let it be and do nothing. Just add a note in the Wiki, to either link manually from ~/.config/stl/vortex -> ~/.config/stl/compatdata or to just run *SE_loader.exe before opening vortex.

[sonic2kk]

For now I have just added a note to the modding wiki to symlink the AppData folder :-)

One possibile way of handling this would be to just create those symlinks every time a game gets launched

Indeed, though the issue is, how do we know what folder to look for. One way is to just hardcode that when X AppID is loaded, look for Folder Name, but I'd like something a bit more dynamic. I guess, though, a text file could be created for it like we have for MO2/Vortex/HMM games, at worst :-)

I think the main issues in your suggested way of doing it, would go away by sticking to link from the Game to Vortex (meaning the Game has the real directory and Vortex the Symlink) and, altho hacky and kinda stupid, top just create or check and create for the symlink when the game starts.

That is a potential issue, because if Vortex was removed there could be issues. Moving the folder from AppData/Local in the Vortex prefix to the game prefix, and then restarting Vortex, will create the symlink as expected too. But eh, either works :-) Ideally STL will automate this someday.

if your are talking about the vortset.cmd, that is so that vortex can "autodetect" the games. That is just that vortex is easier to use, as it wont find the games in Z:\....

I was referring to editing the registry so that Bethesda games can find their executables, which can be an issue with prefixes that don't get set up correctly with Proton in general outside of STL (sometimes the Bethesda launcher can't find the game exe because the path to it isn't set properly in the registry).

This could be it, but it could also be for compatibily reasons. The Vortex dev is quite loud spoken about wanting people to run Vortex through proton to keep it as "close" to the game as possible.

Vortex and MO2 run with Proton, but MO2 runs using the Proton Wine binary (ProtonName/bin/wine) whereas Vortex installs using the Proton Python script (ProtonName/proton). But perhaps this is the reason STL implemented it the way it did (it was written before I had even found the project).

---

Perhaps the actual solution I will go with would be closer to what you described, where the game prefix is the one that has the "real" folder, and then this gets symlinked to Vortex. I wonder if when we autodetect Vortex games, could we hardcode something (based on the mentioned text file) to create the folders in each found games' prefix (i.e. when we find SkyrimSE, create a folder in skyrimprefix/AppData/Local/Skyrim Script Extender, then when Vortex loads STL will create this symlink). This would mean we could leverage the existing STL logic to create the symlinks in the Vortex prefix. I hope that description makes some sense at least, I just woke up from a nap 😅

Honestly, no real idea yet on how to resolve it, but it should be possible to automate with STL. The question is just about how to do it "efficiently"

[dermalikmann]

On another topic: There seems to be even more broken things with SSE + MO2, and I cant, for the life of me, figure out, what is happening. But that issue needs a bit more write up, maybe you could enable github discussions for this repository, so i can send you my findings? Or should i just create another issue?

And yeah, it is also related to symlinks and fun stuff -.-

[sonic2kk]

Skyrim Special Edition works with MO2 I'm fairly sure, it's been used by me and other users in the past, including recently (#836). It could be user-error.

However I don't have time to look into modding-related issues honestly so I'd prefer a PR than a bug report to be honest. I may take a long break from working on STL soon, I am not very interested in working on it anymore, so getting more community interest would help a lot with maintenance.

maybe you could enable github discussions for this repository,

Unfortunately there are too many users that can't use this feature properly, so I won't ever do this again. Sorry :(

[sonic2kk]

I tried to test SKSE with my installation of Skyrim and unfortunately, because I previously managed this install with Vortex, things probably won't work too good long-term. In general with modding, a full re-install should always be performed when switching mod managers (whether it's MO2, Vortex, or something else entirely, and this applies regardless of operating system), but I bit the bullet and thought I would risk it anyway.

Luckily, Skyrim with SKSE loaded up just fine in my quick tests. Things did not work so good when launched from Standalone Mode, as expected, but when launching from Game Mode everything was fine. I don't have any mods installed but the game launched and anything else is kind of up to users to figure out, as mentioned earlier in this issue.

[dermalikmann]

However I don't have time to look into modding-related issues honestly so I'd prefer a PR than a bug report to be honest. I may take a long break from working on STL soon, I am not very interested in working on it anymore, so getting more community interest would help a lot with maintenance.

I completely understand that, tbh I had the random idea earlier to rewrite STL in something like python or nodejs. Bash has its big advantage of being quick and installed on every. single. machine., but also the disadvantage of being a quite messy language. IDK if i ever will pull through with this (altho i already had the idea how one could do this in a transitional style, so that you don't have to migrate 23k+ lines at once.

Skyrim Special Edition works with MO2 I'm fairly sure, it's been used by me and other users in the past, including recently (#836). It could be user-error.

I am half-certain that its not purly user error, as i wiped STL between all my trails and always had the same problems.
but I know that it works for others, and that got me confused. thats why i asked for another communications channel :P

Unfortunately there are too many users that can't use this feature properly, so I won't ever do this again. Sorry :(

figured as much. 😅

Luckily, Skyrim with SKSE loaded up just fine in my quick tests. Things did not work so good when launched from Standalone Mode, as expected, but when launching from Game Mode everything was fine. I don't have any mods installed but the game launched and anything else is kind of up to users to figure out, as mentioned earlier in this issue.

I think that making a note in the wiki, as you did earlier, was a good call, and altho it's just a work-around, it's a good one, that can stay, imo.

I consider this issue closed at this point, esp. with the context of you getting exhausted of maintaining this project (i can understand, really), but I'd like to keep it open just for the off-chance someone stumbles upon it. As longs thats ok with you.

Thx for all the time you spend on this edge case of an edge case :D

[sonic2kk]

I completely understand that, tbh I had the random idea earlier to rewrite STL in something like python or nodejs. Bash has its big advantage of being quick and installed on every. single. machine., but also the disadvantage of being a quite messy language

If you go this road, I recommend Python, as it should come as part of the Steam Linux Runtime, but stick as much to the standard library as you can. For the UI you'd probably have to stick with Tkinter. But this means you should be able to distribute the Python script without having to fiddle with any kind of compilation, and you shouldn't have to worry about libraries being missing. Valve distribute Proton with a Python script (simply named proton), and Python is a dependency of Steam, so if you're creating something that is intended for use with Steam you should be able to guarantee Python as being able to run on each target machine.

I consider this issue closed at this point, esp. with the context of you getting exhausted of maintaining this project (i can understand, really), but I'd like to keep it open just for the off-chance someone stumbles upon it. As longs thats ok with you.

That's good with me, and I'm not totally done with STL, but I don't see myself working too much more on many features for now. Maybe I'll get a flash of motivation but for now, I am kind of in need of a break with no definite return date. I would call that an "indefinite" break, but that isn't quite right to me. I'm just drastically slowing down the pace and how much time I put into STL to focus on other things. Hopefully after a break I can get some motivation back :-) I'll still be around to answer questions and work on whatever tweaks I might want to make while I'm using STL, but I probably won't spend a lot of time working on new functionality for a while.

I'll keep this issue open. Feel free to comment of course with any findings you get from other users.

Cheers for being so understanding, and thanks for using STL. Sorry my motivation to work on things has been a bit... low recently. STL isn't going away and neither am I, but I just have less time and motivation, so issues like this might have to fall by the wayside a lot more than usual.

EDIT: I attached the "help wanted" label to this :-)

[sonic2kk]

Vortex is moving to a different application altogether in future which may not work on Linux at all. Once this happens, STL will probably remove Vortex support altogether since I highly doubt there will be any compatibility (the new app will use C# and .NET for example, but it may work natively, so STL should no longer be required).

Closing this issue since, as expected, no one came forward to help.