Arch Linux User Repository

ok, so i found issue:

beta had a bug that made so it couldnt migrate to new config structure - so it coudnt load it and crashed.

it was fixed in 2.0.0 (that i just pushed), and i discovered that first downgrading to 1.16.9-1, launching it, and then upgrading to 2.0.0 (non beta) fixes this.

so if you were on beta.1 or beta.2 build, downgrade to 1.16.9-1 first

I second updating to v2.0.0-beta.1

question: do we update to Pre-release v2.0.0-beta.1?

@yochananmarqos yes, I mean the runtime. For some reason when I checked earlier pacman only showed me 6.0 and 8.0 as available runtimes unless I installed the SDK 9.0, but I can't reproduce that, so I don't know why that was. But my point still stands, the runtime should be a dependency.

@RayJW: You mean dotnet-runtime-9.0. The SDK is only ever required to build.

@Tymon3310: I tested without dotnet-runtime-9.0 installed and running Vortex displays:

Vortex requires .NET Desktop Runtime 9 to be installed to run FOMOD mod installers.

I think dotnet-sdk-9.0 should actually be a regular dependency, not just for make. Unless I manually install it after installing this package, Vortex throws an error, that .NET Desktop Runtime 9 is required, and the only option is to quit the application.

Another thing I noticed while trying to install Cyberpunk 2077 mods is that some mods, like Cyber Engine Tweaks, are not unpacked properly - which may not be entirely related to Vortex (despite having 7z, unzip and unarchiver installled). What happens is you end up with a file, such as "bin\x64\plugins\cyber_engine_tweaks.asi" in your Cyberpunk 2077 root folder when trying to install a mod (instead of it being in the appropriate folder(s)).

@Arszilla @super-cooper its a know issue, they are working about it. We have to wait https://github.com/Nexus-Mods/Vortex/pull/19825

Also, not sure if it was the current release or the previous one, but I noticed it totally messed up my game directory for Oblivion Remastered. It dumped all the plugins and resource files in the root directory, and I had to manually move them to the right places to get them to load again. This did not happen when I was running Vortex through Wine.

Builds for me now as well. Still having plenty of issues:

1. Every time I open, it gives me a message that nxm links will now be handled by Vortex
2. Says I am missing a gamebryo plugin, tries to download and fails, saying it is not in the repository
3. On deployment, it gives me a successful toast notification, but the notification in the top right says "Failed to bake settings files" and the mods don't actually deploy. Stack trace below:

TypeError: winapi.GetPrivateProfileSectionNames is not a function
    at WinapiFormat.readSectionList (/opt/Vortex/resources/app.asar/node_modules/vortex-parse-ini/lib/WinapiFormat.js:34:39)
    at WinapiFormat.read (/opt/Vortex/resources/app.asar/node_modules/vortex-parse-ini/lib/WinapiFormat.js:9:21)
    at IniParser.read (/opt/Vortex/resources/app.asar/node_modules/vortex-parse-ini/lib/IniParser.js:9:29)
    at /opt/Vortex/resources/app.asar/renderer.js:8734:99
    at tryCatcher (/opt/Vortex/resources/app.asar/node_modules/bluebird/js/release/util.js:16:23)
    at MappingPromiseArray._promiseFulfilled (/opt/Vortex/resources/app.asar/node_modules/bluebird/js/release/map.js:68:38)
    at PromiseArray._iterate (/opt/Vortex/resources/app.asar/node_modules/bluebird/js/release/promise_array.js:115:31)
    at MappingPromiseArray.init (/opt/Vortex/resources/app.asar/node_modules/bluebird/js/release/promise_array.js:79:10)
    at MappingPromiseArray._asyncInit (/opt/Vortex/resources/app.asar/node_modules/bluebird/js/release/map.js:37:10)
    at _drainQueueStep (/opt/Vortex/resources/app.asar/node_modules/bluebird/js/release/async.js:97:12)
    at _drainQueue (/opt/Vortex/resources/app.asar/node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (/opt/Vortex/resources/app.asar/node_modules/bluebird/js/release/async.js:102:5)
    at Async.drainQueues (/opt/Vortex/resources/app.asar/node_modules/bluebird/js/release/async.js:15:14)

While the build is successful with the latest iteration, it seems that there is a few hiccups getting Vortex to recognize game folders and versions. I tried defining my Cyberpunk 2077 folder, which is under ~/.local/share/Steam/steamapps/common/Cyberpunk 2077/ but Vortex kept throwing "This directory doesn't appear to contain the game. Usually, you need to select the top-level game directory, containing the following files: bin/x64/Cyberpunk2077.exe"

Exiting the window still defined the game by the looks of it, but trying to add a collection throws an error regarding "version mismatch". Sadly, this is a vast difference to "nexusmods-app-bin" package. I hope Nexus/Vortex will fix this ASAP.