Tannin42

Just for the record: I'm the creator of the extension, it's open-source, Nexus Mods has my number. At no point did anyone reach out to me to figure out what the problem is or if it could be fixed before deleting it. I learned about the removal from this very thread.

https://forums.funcom.com/t/mods-on-microsoft-store-pc-and-how-to-install-them/168411 Obviously this does not detail how to do it in Vortex, I suspect a programmer would have to add support for the game pass variant of the game. But tbh, Conan Exiles has such great modding support, doing it manually is barely more effort than using a mod manager. Also, the game is a bit old and often on sale, maybe you could just try to get it on steam for cheap. I think the steam workshop actually has a bunch of mods for this game you might not get on Nexus Mods.

"manually set location" is not profile specific though, once you change the game location, all profiles will deploy to that location. I think what the others have suggested is to use the "--user-data" command-line switch to have to completely separate Vortex "instances" (with distinct sets of mods, downloads, profiles, settings, ...). Then you can have one instance targeting the gog install of the game and the other for the steam install.

Don't take this the wrong way, just something I have to ask to rule out the most obvious explanation: Vortex has a button to "Power off when done" so you can start a bunch of downloads and go away and then Vortex turns your system off when all downloads are completed. I've seen systems where, due to driver issues or something, they will reboot instead of shutting down. You're saying the downloads aren't done so I'll assume this isn't it though. I haven't heard of others having an issue like this when I was still supporting Vortex. One thing that may be relevant is that while downloading, Vortex will send a signal to windows every minute to *prevent* sleep mode. This is so that if you leave your system running while doing a large download it doesn't active sleep mode. Maybe there is Your system randomly rebooting is almost certainly some sort of driver problem. I wouldn't suspect a hardware defect or virus because why would that only happen while you download something? But maybe there is a driver that doesn't deal well with the "don't go to sleep" signal? Since this is almost certainly a low-level issue - I can assure you Vortex has no code to trigger reboot other the one mentioned above - maybe look at your windows event viewer (there under windows logs -> system), if you're lucky it will tell you what triggered the reboot if it was indeed software triggered or it might have error messages for driver errors.

The error message is unfortunately truncated so it's hard to tell but I can almost guarantee you that this is a broken or incomplete .NET install. One thing to keep in mind is that you likely have multiple copies of .NET because its versions aren't usually backwards compatible and there are variants with and without UI so it's perfectly possible that one .NET application works fine because it's using the .NET 5 installation on your system while another fails because the .NET 6 install is kaputt. And because .NET installers are such a clusterf***, many .NET applications nowadays ship with their own full copy of .NET so you might even have multiple copies of the same .NET version, one of which works the other doesn't. In this case the System.Windows.Forms library - which is part of the ".NET desktop runtime" but not part of the ".NET runtime" (great job microsoft, really, great job) is either missing, broken or inaccessible. Vortex isn't imagining that, the error message is from .net itself, not from Vortex. The solution Picky posted (or, more precisely, the wiki link it leads to) should absolutely fix all three potential problems that could cause this error.

Depending on the Game it can be complex, the documentation isn’t wrong but over-simplified (the wiki tends to prioritize simplicity over correctness). Hard-link is the default because it has best game compatibility but it requires staging to be on the same drive as where the mods need to be put for the game to find them. This is the often mis-described. Not every game reads its mods from the game installation directory, some require them to be in the windows „documents“ directory for example, then staging needs to be on the same drive as your documents directory. And then there are games (e.g. Witcher 3) that require some mods in documents and others in the game directory so unless those are on the same drive, hard-link deployment is not an option no matter where you put staging.

With default settings vortex does not download multiple files at the same time because - assuming everything works correctly - one server serving you one file at full speed causes the least amount of overhead and your system gets that file sooner and can start installing the mod sooner. It’s a better use of available resources all around compared to trying to download multiple files at once, then potentially unpacking them at the same time. If your downloads do not happen at full speed (your connection speed) you can increase the number of download threads in settings (vortex will use up to four threads per file so 8 threads means two files downloads with 4 open connections each) But if the server doesn’t give you max speed, that indicates the server is at capacity so using multiple threads just means the available bandwidth is split up more and more bandwidth is lost to overhead. Changing the server in site settings makes more sense.

Does the file in the error message exist? Is it open in another application? Is it write protected? try moving/deleting it manually and see if that works, if it fails, restart Vortex, maybe it's Vortex itself keeping it locked?

new-file-monitor is a utility that game extensions may use but don't have to. It's basically there to detect files added to the game directory by mods that Vortex can't automatically assign to the corresponding mod without help. Think mods that create a log file or save their configuration to a newly created file. For Vortex to detect that files were added compared to the last time it ran it has to take note of which files were there before. This doesn't usually take that long, in your set up though it tracks over a million files apparently in at least 360 thousand directories. That seems - excessive. You might want to check if your setup actually contains that many files or whether there is some kind of directory link shenanigans that confuse it. Otherwise it might also be safe to disable the new-file-monitor extension unless the Starfield extension uses it (one of the current Vortex devs should know) because previously I think it was only Stardew Valley that needed the information anyway. Finally, my personal preference is to disable the automatic deployment anyway, only deploy once before actually starting the game - especially when setups start to get bigger.

Vortex probably detects both installations and gives one priority but you can manually change the game directory from the games screen. If you manually set the game directory that always has precedence over what Vortex auto-detected. Technically I don't think there's anything stopping you from "purge" the existing (gog) mod install change the game directory to the steam instance deploy again In regards to the mod deploy at least it shouldn't matter to Vortex that it's now deploying to a different target directory than before or that that directory contains a different game version/store variant. The only thing I could see as potentially problematic would be a) fomods that installed different things based on which CC content was available at the time the mod was originally installed b) savegames, ini files and profiles in general since the gog instance has its own copy of all that so it might be a good idea to clone the profile you're going to be using first, enable the clone and then not touch the original profile while Vortex is "targeting" the other game install. I don't think savegames should be a big deal as Vortex doesn't "remember" save games, it doesn't care about saves appearing or disappearing but it does maintain copies of the ini files with each profile so it might end up mixing settings from the two instances, not entirely sure how robust that is.

IIRC the tool is required to determine the unique id of the mod which is required to control the load order. So it doesn't change the mod files, it just has to read some meta data from it.

Vortex doesn't explicitly support _any_ browser, it just talks to Windows, going "please open this Link in whatever browser the user has configured as the default" and "if a default browser tries to open a nxm:// link in the default application, call me!". Whether your Browser supports these interfaces is entirely up to the browser. If it doesn't though, it's shite, don't use it. I really don't care what awesome features it may have, if it refuses to adhere to standards - to me that'd be a total no-go.

The error message is from the server authentication, effectively denying you use the server api. This could be - a temporary server hiccup, does it still happen now? - your account somehow got corrupted or is banned (I can't verify that you're logged in to post on the forum here is the same you were trying in Vortex) - The server is bugged - Vortex is bugged and trying to do something it shouldn't attempt The latter two are less likely as they would likely be encountered by more users

Vortex itself doesn't make use of multiple threads but most of what Vortex does is either I/O limited (downloading/copying/linking files and such), handled by libraries (that _are_ multithreaded if necessary) (like extracting archives, hashing files, ...) or would always be single-threaded even when using other technology (UI rendering). Downloading files for example would usually be limited by your internet or disk speed, even on 1GB/s internet downloading at full speed from a premium server I had no problem with my cpu becoming a bottleneck. The main CPU load when downloading files (from nexusmods) is ssl decryption (because all downloads from this site are needlessly delivered via https) but Vortex uses a standard library for that (openssl/libressl), it's not up to Vortex whether that happens single- or multi-threaded.

I'm still around, still need to mod my games. ;)

Yes, Vortex is open source and you can make a Linux native version. In fact, Vortex should mostly just build on Linux with a few optional components failing. The question is how far you want to go. The basis of Vortex is written platform independent. There are a few windows-native libraries but this is for the most part because node.js is mimicking posix and while that works on windows, it's not covering all of windows' functionality or would perform badly. Those native modules wouldn't be required on Linux/Mac OS as in: you wouldn't have to port them, just replace with simple JS code. Just because Vortex builds and runs on Linux doesn't necessarily make it particularly useful out of the box though. It will work fine with games that run natively on Linux but to manage games that are emulated through wine/proton, you'd either need (part of) Vortex to also run in that same sandbox as the game or you need to extend Vortex to know about wine and deal with it specifically. And then you might need to support different ways to configure wine. E.g. as far as I understand it, the steam deck uses a separate sandbox for each game whereas someone setting things up themselves might run all games in a single sandbox. Another user (NicBomb) has done quite a bit of work on Linux support (https://github.com/NicBomb/vortex) unfortunately he also insisted on changing the build system and on making sweeping coding style changes in his fork which made it impossible to merge his changes to the official repo or vice versa.

Ok, so you're very likely trolling so I'm out. If you're actually having a problem, this is a case of PEBKAC. The way you fix it is you take a step back, realize that you are misunderstanding how things work and what people have been telling you. With that understanding, re-read what you have been told. Everything you need is there.

You have not provided any proof that Vortex *does* load stuff out of order. You refer to files in the wrong directory (quote: Go to "My Doicuments /My Games /Fallout 4" & see for yourself.) And you use a tool that clearly states it's in an early version to "prove" that the load order is wrong. Meaning: - We don't know if the order is actually wrong - If the order is wrong we don't know if it's the actual load order file containing the wrong order - If the order is wrong we don't know if it was Vortex that created it

a) You're not looking at the right directory, the game does indeed not use those files and Vortex didn't put them there. The actual plugins.txt file is in %LOCALAPPDATA%\Fallout4 b) The loadorder text file is indeed not used by the game, never has been, that file is being used to synchronize load order between mod managers, the game only looks at plugins.txt c) It's important to note that when people speak of an "ESM file" that doesn't necessarily mean "file with .esm file extension". A .esp file can still be a master through a flag in the file header and will then have to be sorted with the other masters so it's not automatically wrong if you see a .esp file at the top of the plugin list.

Error messages like these occur in response to an error from the operating system which then unfortunately get filtered through the middleware we're using (node.js in our case but it wouldn't be fundamentally different with Qt or .NET) and the information value can only diminish for every layer the message goes through. But fundamentally: Vortex doesn't do some weird tests that might fail and then decide it can't write, it literally just goes "Windows, give me the content of file x" or "Windows, write data y to file x" and that then fails with an error message that hopefully explains why. Meaning that if Vortex tells you a disk access failed, that is a fact. The reason/cause might be muddied, by the middleware or Vortex itself but not the fact that Vortex can't access a file it's supposed to be able to access (the error message you're reporting implies a hardware or filesystem defect but I'm not willing to bet that's actually the case). Further, I'm pretty sure what you're describing as the solution is a red herring. The notification is a fire-and-forget message we generate once on startup, it being there does not trigger any further disk accesses, dismissing it only makes the notification disappear until the next time you start Vortex. I don't see how it could have any further effect.

There are some mods that Vortex can't control the load order of because of the way the engine loads them and we _have_ to treat those differently. AstarionBard shouldn't be one of those though, so if that mod is what it says it is there is something else going wrong. Vortex uses a tool called divine/lslib to identify which kind of mod it is and my suspicion is that running that tool sometimes fails for you which leads to Vortex misidentifying the mod. I've seen a couple of reports of divine failing with various error messages but I couldn't make sense of what might trigger it, whether it's something we're doing wrong or if it's a bug in divine or some third-party tool interfering. Can you see any error messages in your log mentioning "divine" or "lslib"? Can you try narrowing down what you did when the mod is "locked" incorrectly? Is it truly random or is there a pattern (e.g. "any time I removed a mod, after the next deployment the mod is locked")

Sorry, missed this mention. I dont use this feature outside testing environments. I have SSE setups with 1000+ mods, cyberpunk with a couple hundred, not needed a file override once.

Because it is broken. All software is broken to some degree. But security vulnerabilities are only a risk for the general public from the moment they are published to the moment they are fixed (because the average script kiddy doesn't discover security flaws, they just use flaws someone else publicised). If a security flaw is discovered by a white hat hacker, the software vendor has time to fix the issue before it gets published, otherwise they are usually fixed within days. But if you don't update your software, you are no longer vulnerable for days but forever, your individual risk of being affected by a security flaw was stable on a rather low level while Windows 7 was supported - not because the threads were constant - that was constantly in flux whether you noticed or not - but because the number of flaws fixed was roughly the same as the number of flaws that became public. But since january your risk of being affected by a flaw has grown exponentially and grows every day. Users sticking with software past end-of-life are a gift and favored target to every lazy hacker in the world. Your system today is probably a thousand times more vulnerable than it was in 2009. That is what changed. Your argument of "why fix something that isn't broken" in this context is like a captain on a boat acting like the sea doesn't matter. You're supposed to update software not because your system changed but because the world around your system changed. Running an old Vortex version isn't a solution, it's a workaround and the shorter you rely on it the better - because chrome and electron too have received a bunch of security fixes since 1.7.8 that are all publicly known and documented and exploitable today and were unknown when 1.7.8 was originally released.

Sorry, I got confused. The error message refers to the backup of the manifest. Not sure why that is missing, it could be that the version of Vortex you last used to deploy we didn't even create backups yet. The invalid file will be in your skyrim \data directory, something like "D:\SteamLibrary\steamapps\common\Skyrim Special Edition\Data\vortex.deployment.json"

As Pickysaurus explained, the vortex_deployment.json file is defective (the one mentioned in the error message) You should try to purge (Purge button on the Mods page). If that fails, remove the vortex_deployment.json file and then try to purge again. After purging, check that the game directory is clean (as in: Vanilla unmodded state plus pontentially some configuration files the skse plugins or tools might have created but not the mods themselves). Then deploy again, that will create a fresh deployment manifest.