Tannin42

Please don't confuse the two kinds of orders there are. What we refer to as the "load order" is the order in which a game loads its plugins, the effect of this order depends on the game engine. The "mod order" (or deploy order) is the order in which files are being put into the (virtual) file system, this order is game independent, it always decides which files (assets, plugins, scripts, ...) end up actually visible to the game, doesn't really matter to the mod order, what (if anything) the game does with the files. In the mod order case the order only really matters between mods that actually conflict. E.g. if you have one mod containing only one file named "foo.dds" and a second mod containing only one file named "bar.dds", it doesn't matter which one you deploy first, the end result is always an output directory with two separate files. In many games, like the bethesda games, this is also true for the load order. Plugins are just a set of records with ids deciding what part of the game they modify, if both plugins are clean (no spurious changes) and modify completely independent areas of the game, the load order doesn't matter. Vortex only stores rules, deciding conflicts (e.g. two mods, both containing "foo.dds"). This means for a given list of rules Vortex has there is a huge number of different flat mod orders that are all equivalent (produce the exact same output). And again, the same is kind of true for plugins in bethesda games. The method by which you go from rules to a flat list is by using a so called "topological sort" which is usually part of any graph library so you shouldn't have to implement this, just get a graph library for your language, feed in the mods as nodes, rules as edges, call the toposort function and you have a flat list for MO2. Going the other way though is not trivial, you would have to identify conflicts then, for each conflict, generate a rule that reflects the order from the flat list, making the assumption all of it was intentional.

The Vortex state is stored in a leveldb database (https://github.com/google/leveldb). There are tools and libraries for many languages to access these databases directly but you have two other options: a) Vortex has a command line interface that lets you access or change the state (vortex --get ..., vortex --set ..., vortex --del, vortex --merge, vortex --store) but you'd have to be super careful with that. b) Any Vortex extension (see https://nexus-mods.github.io/vortex-api/) can get read-access to the state as a plain old javascript object, changing state is a wee bit more complicated (we don't usually allow arbitrary changes to the state, there has to be logic (actions) behind every state change). The best solution depends on what you're trying to achieve but if your trying to export/import larger chunks of state, using an extension to dump the state (or whatever part you need from it) and the command line "vortex --merge" to insert state (in json format) would be my suggestion. The reason I'd use an extension to dump is because you get clean, validated data out, the reason to use the command line to insert is that it ensures your import happens before the the UI tries to render that state so you don't have to worry about if/when the UI updates to match. You could also integrate state at runtime though, the keyword for loading entire chunks of state is "hydrate". We don't really document this, this is decidedly "only use if you know what you're doing" territory.

If you know a bit of javascript or are willing to learn, you can write an extension for Vortex to add support to the game, the documentation for that is here: https://nexus-mods.github.io/vortex-api/2020/09/04/Introduction.html Otherwise you may be able to use this extension: https://www.nexusmods.com/site/mods/155 to do it without coding but that only really works if the game is simple to mod.

Vortex does add "files" to the game data directory, the way it does that is special in two ways though: a) it does not take up extra space, the actual data is shared with the file in the staging folder b) unless you mess with the game directory outside Vortex, Vortex can 100% reliably identify the files it added and clean them up. So while the game directory isn't "clean" while you have mods applied you can always return it to a clean state and that is perfectly reliable unless - again - you mess with the files outside Vortex. The advantage of what Vortex does is that you don't have to run the game, or related tools, from inside Vortex, everything works as if you were modding manually and it works with all kinds of games, works with xbox store games, ...

DA Inquisition uses the Frostbite Engine which isn't easy to mod, currently we have no support for any such game. Fundamentally Vortex can be extended to support any game but many games do still require developer work, the first game of any engine is a particular hurdle, after that you can usually reuse most of the logic.

Hrmm, good question. I'm using BethINI myself, never had that kind of problem so at least that's not a common problem with that tool.

The savegame location is set in Skyrim.ini (in %USERPROFILE%\Documents\My Games\Skyrim Special Edition), section [General] -> SLocalSavePath Vortex will update that setting every time you deploy so a) You can't manually override this in this location b) It won't be outdated unless you haven't actually ever deployed your new profile However, as Picky suggested, you might have this setting in SkyrimCustom.ini, that would take precedence over what Vortex is assigning.

File access is denied either if the file permissions say so (right click on the file in windows explorer -> properties -> security) or if the file is open in another application. If it's the latter, LockHunter (https://lockhunter.com/) is one tool you can use to find out _who_ locks the file.

That error message means that the Vortex application files, meaning the files in "C:\Program Files\Black Tree Gaming Ltd\Vortex" - or your custom install location if you picked the other installer - are either deleted or modified. This might have been you, your AV, a Virus or a hardware defect or, like HellFreezer suggested, file permissions such that Vortex can't read its own files (though it _is_ running the executable so clearly it can read some of those files). Or you're using an unofficial release. Or a bug that no one else encountered. But it is unreadable application files, it is nothing else, just this. So please do NOT delete %appdata%\Vortex, that would reset Vortex and lose everything you've done in it with 0 chance of fixing this problem. You can look at the vortex log (in %appdata%\vortex\vortex.log, it will contain the list of files that actually failed to read and whether they are missing or modified, maybe that gives us a clue. E.g. if the file in question is an exe, .dll or .node file it's probably an AV or Virus.

Indirectly, yes. If the md5+size lookup gives a result, Vortex knows which file this is on nexusmods.com and then it can use the API to fetch additional detail like the description and image and everything. But if the file was downloaded from nexus directly (through the "Download with Manager" link) then we don't need the lookup so fetching that data is one step instead of two.

renaming the file shouldn't have any effect, that's pretty much the point of using an md5 hash. If you add a file to Vortex through the site (from a "Download with Manager") button then Vortex can already identify the file based on Nexus Mods specific ids. But when you add files in any other ways, either by downloading from Nexus Mods manually or a third party site, _then_ we generate an md5 hash and, together with the file size query if Nexus Mods knows that file. So even if you got the file from a third party site, if the file was _also_ uploaded to our site it should be identified. Since we use hash + size it's practically impossible we would identify the file incorrectly but it is possible that users re-uploaded other peoples files, potentially with incorrect or localized descriptions.

If you don't want to mod the game anymore this should be fixable if you ignore the error message, then go to "Games", click the ... button on 7 days to die and select "Stop Managing". This will remove profiles for that game which should stop that error from coming up.

Changing network should indeed not be a problem, all a resume is is that Vortex tells the server to download a file but start at an offset. However, not every server _supports_ doing that in which case a resume won't be possible, there is nothing Vortex can do about that. Further: download links from nexusmods.com are tied to the user account so if you were logged in with a different account a resume won't be possible. And finally, download links from nexusmods.com are only valid for a limited time. None of these cases Vortex can do anything about I'm afraid. The error message you're getting implies this is caused by one of the latter reasons, the link has either expired or belongs to a different user account.

Re 1&3: They are almost the same, if there are recommendations for a mod, these install them. "Install Optional Mods" will only work with collections containing optional mods, "Install Recommendations" works only for games where there is a (supported) third-party service making recommendations for mods for that game. Re 2: "Remove Related" will offer to remove other versions, variants or optional files belonging to the same mod. So if, for example, a mod has one main file and then optional files on nexusmods.com and you install the options, "Remove Related" will offer to remove those options as well so you don't have to find them yourself Re 4: If you reinstall a mod you get an option to Replace the existing install or create a variant. When you do the latter you get the option to switch between variants the same way you can switch between different versions of a mod you have installed Re 5: No, Vortex currently has no option for that but I would suggest you change the file extension (e.g. .dds to .dds.hidden) instead of actually deleting the files. That way they would still be deployed to the game directory but have no effect on the game. If you then find you made a mistake it's much easier to restore the files.

This feature is only available on certain games (TES and Fallout)

Depending on the application you use to edit a file (let's say "foobar.dds"), it might change the file in-place or create a new file with a new name (usually something like foobar.dds.tmp), then, only when writing the file was successful, it moves foobar.dds.tmp -> foobar.dds. In the first case (file edited in-place) Vortex should not prompt at all because the original file is edited so there is nothing to restore/apply anyway. In the second case, what Vortex detects is that the file exists but is no longer a link but a "proper" file, Vortex simply deduces that this means it was edited, for performance reasons we don't actually compare content. Now if this worked as expected, you would get a choice to apply or revert the changes but you seem to be getting the option to restore or delete the file instead so Vortex believes the file no longer exists (in the directory and with the name it previously had). There isn't really any magic in how it works, it just checks the existence of the file path it previously deployed to. There are a few obscure things I can think of that might be adding confusion there could be a) permissions: Are you editing the files with a different windows account/as admin such that the account running Vortex can't access the files after they were changed? b) directory links aka junctions: Do you have your own setup of "virtual" directories using directory junctions that might make files appear with a different path in a different location? c) weird filesystem setup: What filesystem are you using on the drive? NTFS can be configured through the registry in a way. Vortex tries to determine whether the filesystem is case sensitive on the fly but maybe there is a combination of settings where Vortex thinks the filesystem is case sensitive (e.g. "foobar.dds" would be a different file than "FOOBAR.dds") when your filesystem actually drops case information thereby automatically renaming "foobar.dds" -> "FOOBAR.DDS" when you edit the file. This last one being possible would be new to me but it wouldn't be the first time windows "surprises" me... As mentioned earlier: It would be really good to get a screenshot of the dialog or the exact wording in the dialog, does it say "Source files were deleted" or "Links were deleted"? Further, please go to settings->mods and check which "Deployment Method" is selected.

In the log file you posted you got two network errors, the 500 from our api and a 502 from the beat saber extension, connecting to either bsaber.com or beatmods.com. considering you got errors from two separate servers it's safe to assume it's not a problem with those specific systems. However, 50x are usually server errors and 502 in particular would indicate a problem in a proxy/gateway system so it might be that a bigger service provider (like cloudflare) was experiencing issues (in your region) that affected both server rather than a problem with your local network. Generally (this is true for basically anything), if you get a 5xx network error suddenly in any application, wait for a few minutes and try again, 99.9% of the time these are temporary issues that sort themselves out.

That. Creating the links for the mod takes very little time, checking for external changes that might have happened since the previous deployment can take longer, that's why you might notice little difference between deploying one mod vs deploying all of them but technically Vortex only deploys the files that were changed.

Ignore the warning "required file for game version hashing is missing..." from the log, that's a non-issue that shouldn't actually be logged at all, probably a remnant from development. "Loose files may not get loaded" means you got a corresponding notification, informing you that archive invalidation is not active, at least not through Vortex and thus loose mod files may not get loaded at all. "Invalid primary tool" means that the tool set up to start the game, very likely f4se, is not installed or misconfigured. If your game crashes, that's a problem between you, your game and the mods you installed, Vortex itself doesn't cause the game to crash. The two warnings above however do indicate that your setup is misconfigured and Vortex is trying to get you to fix it.

The installation directory doesn't really matter as it contains only the application itself, no data, so that directory only contains the stuff you can get back by reinstalling Vortex anyway. Application data, that is settings, meta information about mods, profiles and so on, is stored in c:\users\...\appdata - the first or second directory you should include in every backup anyway. If this is lost, what you can recover is limited. Assigning the download and staging folder to what you previously had _should_ work though. Vortex looks for the file "__vortex_downloads_folder" when you assign the download folder. If you get the message "The destination folder has to be empty", that would indicate that that file does not exist in the directory you selected. And that means either you selected the wrong directory or you were using an absolutely ancient version of Vortex.

This bug will be fixed in 1.7.1. What's happening is that there is a minor bug in one of the third-party game extensions you're running. In 1.7.0 that error isn't caught, thus causing the crash instead of just logging it.

Even that wouldn't do it, the mod archives can be deleted, that would only break the "Reinstall" option. As long as the staging folders are there you can deploy.

Unfortunately it's an either or. Either we have all columns auto-resize or they all have a fixed size that you can/have to manually adjust, I don't think we can have them auto-adjust until you choose to resize some. We had to pick one or implement both and then have a toggle somewhere. With columns toggleable and large variation in content width (mod names, categories, archive names) I suspect it would be very frustrating to try to manually find a reasonable width you're happy with and near impossible to provide sensible defaults so we did the auto-resize first and stuck with it so far.

"scan for games" was removed because there is no way to make it work the way people would expect. Most of the games now are supported through third-party extensions and those can't be discovered until you install the extension. Thus many games, even those you do have installed, would not be discovered when you scan. Instead you should just find the game you want to manage and click it, if it's discovered, good, if not, Vortex will tell you what to do next.

We have a couple of tutorials and api reference here: https://nexus-mods.github.io/vortex-api/ You're taking offense because you choose to take offense. I didn't tell you "what to do and what not to do", I was explaining the limitations of the existing system and how it isn't a fit for what the OP was trying to do. We deal with a sh*tload of user feedback every day - every opportunity we give users to break something for themselves comes back to haunt us, that's why it's important to us we manage expectations correctly. But if you insist on doing what I told you the feature isn't able to do, go right ahead and find out for yourself.