Rattledagger

1: If you ever accidentally deletes the wrong file, or make a bad edit, you would see the advantage of Vortex detecting any changes made to data-directory. As long as you don't pick the wrong choice you'll not lose anything you want to keep. BTW, if you're frequently making changes, I would recommend to create a new sub-directory in the "mod staging folder" and put the files here instead. You'll either need to switch to another game and back again or to re-start Vortex to detect the new sub-directory. 2: Despite using drag-and-drop for many years to sort my plugins in NMM, MO1 and MO2, after learning to put plugins into different Groups in Vortex I've not really missed drag-and-drop. If you "need" drag-and-drop sorting of plugins, you can use Wrye Bash for this and since Wrye Bash has been popular for many years to create the Bashed patch sorting the plugins at the same time shouldn't be much of a problem. 3: If you uses Vortex "integration", it's easy to use different FNIS setups per profile. If you want an example of poor FNIS "integration", try MO2 v2.2.1, where all profiles uses the same output-directory, meaning you'll need to manually change output-directory every time you switches profiles if you want MO2 to have different FNIS output-directory per profile. 4: Hit purge and Vortex will remove all these folders for you. Since cleaning-out empty directory will take some time and coupled with it's irrelevant for playing modded game if you have a few extra empty directories present or not, Vortex to speed-up things every time you Deploy is choosing to not delete these extra empty directories. 5: Vortex has no way of knowing some of the files in a mod-archive don't need to be installed, unless the mod uses FOMOD or another installer to tell Vortex which of the files should be installed. As an improvement to 1 would be the option "create new mod of the changed files".

Since MO never installs anything into the data-directory it will always be "squeaky clean". As for anyone that "need" a clean data-directory, they can get the same in Vortex, if they goes to Vortex Extensions-tab and download "Fully Virtual Deployment". Note, running FNIS and another tool that creates new files isn't currently working, but it's possible to first use hard-link as deployment-method, run FNIS etc., and afterwards switch to USVFS deployment if you "need" clean data-directory. Also note, if you uses USVFS, Vortex can't install mods to the games root directory any longer.

To report bugs, click the 3 vertical dots in the upper right corner and choose "Send Feedback".

This behaviour is known as Vortex bug number 4956. Profile-specific ini-files doesn't work correctly and it won't work correctly until Vortex finally fixes this bug.

Fatal bug, you must be a Nexus premium user, otherwise this plugin are fairly useless. Also, the plugin only exports Nexus mods, meaning large parts of your mod-list can be missing.

Under Vortex - Settings - Mods, make sure you're not using Softlinking as deployment-method, since the Witcher 3 script merger don't support softlinking and would guess many mods relies on script merger Vortex has stopped supporting softlinking for Witcher 3. If you're using softlinking due to mods are installed on another disk than Witcher 3, you'll need to change the mod-location in Vortex, have Vortex move the mods for you and afterwards make sure you're using hardlink deployment.

HadToRegister, you get one message if you change a file and another message if you delete a file. I just tested with v1.1.1 and I got both types of message, depending on editing or deleting a file in data-directory.

If you re-Enable mod + Deploy, the mod will be used, unless: 1: Another mod is overwriting the mod. 2: The mod includes one or more plugins but you've disabled the plugins. 3: The mod depends on another mod, but you don't have this other mod active. Example for 3 can be, you've installed a texture-replacer for some mod-added armour, but you've not installed the mod-added armour and for this reason you won't see anything to the texture-replacer in-game. Another reason for mod not showing up in-game can be, some mods only works if you start a new game but you've only tested by continuing an old save-game.

Hmm, yes, you're correct, the picture does say "Links were deleted". Now the "Revert will restore the links" would be correct, since in this case Vortex will re-create hard-link between data-directory and mod staging folder. Using link for the first is on the other hand not a good description, since "Save will permanently delete the files from the mod staging folder and the only way to get the files back is to re-install the mod" is that will be the outcome here.

Something is screwed-up, since uninstalling a mod should not give any "external changes" to other mods files. Now if not mistaken I have gotten "external changes" on a mod after uninstalling the mod, but this "external changes" was for the mod I've just uninstalled and not other mods. Doing a couple tests, I've not managed to trigger any "external changes" after uninstallation, but maybe it's not a bug that appears "on demand". Also, since I'm running the current test-build v1.1.1, it's possible the bug has already been fixed, in case the problem happened with an older version. As for the "External Changes" dialogue can be confusing, yes, but finding any good replacements can also be difficult. Example using "links" will possibly be even more confusing, since my guess is many isn't aware the files are linked, but instead they deleted that they thinks is a real file. Why an "external change" then it comes to hard-linked files? This is simpler to answer, since this happens if you or a tool breaks the hard-link. Where's basically two ways to break a hard-link, either you or a tool deletes a file (and possibly replaces it with new file afterwards), or the file is re-named and afterwards replaced with a different file. Example xEdit will break the hard-link, the same will Vortex if you toggle ESL-flag on or off. Some tools on the other hand will directly edit the file and in this case the hard-link is kept and both the contents in data-directory and mod staging folder is changed to the new content, with new saved date etc. Example Notepad will directly edit ini-files and Vortex won't know of these changes. NifSkope is the same, where hard-link is kept despite the file-contents can be very different from the original file.

Actually NMM will frequently refuse you to move a plugin to the desired location, since this will put a plugin before it's master(s) and NMM absolutely refuses you to create such an invalid load order. Still, if example plugin B is currently at location 55 and plugin A is currenty at location 56 it is fast and easy to drag-and-drop B after A if this is your desired load order. After you've done it once, it's also easy to put plugin B into a Group that is loaded after the Group A is currently in if you're using Vortex, but I would expect you'll use somewhat longer time doing this compared to drag-and-drop a plugin one location up or down. In practice all plugins you want to move don't come next to each-others, but example plugin A is suddenly at location 156 instead. This makes drag-and-drop B after A both time-consuming and difficult. In addition let's say plugin C has B as master and C is currently at location 77. This means you can't drag-and-drop B below A, until you also drag-and-drop C below A. In Vortex on the other hand even with plugin C in the mix it's still the easy "put B in a Group loaded after the Group A is current in". Meaning, Vortex approach can be significantly faster than NMM to handle this more advanced plugin load order. But, what about using LOOT + drag-and-drop afterwards? Sure, this would in many cases be fast and easy, but if you ever re-run LOOT I would guess "Why did LOOT take my carefully created load order and turn into this unsorted mess?" be a fairly common question, since by using drag-and-drop you can put a plugin in violation of the LOOT master-list. Meaning, if you uses LOOT + drag-and-drop + LOO I would expect you'll need to drag-and-drop the same plugin multiple times. Bottom line is, drag-and-drop is fast and easy for handling simple changes to plugin load order but can be difficult and time-consuming for more advanced plugin load orders. Vortex "putting plugin into another group" is fast and easy for both simple and advanced plugin load orders.

Until Vortex Fixes bug 4956 deploying won't help.

To create a backup you'll type-in a new file-name, personally I didn't include any extension and it worked, you don't type-in the name of an existing file. Taking a quick look on the resulting file, it only includes the mods currently installed and it only includes the Nexus-mods and not the other mods. For each mod the information stored is on the format: { "name": "Unofficial Skyrim Legendary Edition Patch", "game": "skyrim", "modId": 71214, "fileId": 1000300771 }, To restore a backup I've no idea, since it just spit-out an error about "need to be premium". BTW one other weakness is, the backup is for all games, where's no possibility to only backup a single game, meaning it's not a good method for distribution list of mods to someone else even if they are premium-members.

Conflicts showing-up has nothing to do with hard-link being present or not, but has more to do with Vortex can take a few seconds before showing this information, in case you've got very many mods or Vortex is busy installing multiple large mods or something. Since Deploying is a costly operation, especially if you've got many mods and/or many loose files, it's definitely more effective to disable auto-deploy, for so handling any conflicts after install + enable mod and only deploy after you've handled all the file-conflicts.

1: All profiles relies on the same collection of installed mods, but each profile uses profile-specific list of active mod-versions. This means if example profile A and B both uses mod X, version Y and you update to version Z on profile A, profile B will still use mod X version Y. If you uninstall mod X version Y on profile A, this means as far as profile B goes no mod X is active, until you choose to enable mod X version Z for profile B. 2: If you for profile A uses "Replace" then updating mod X to version Z, this means profile B won't have mod X active any longer since version Y was uninstalled as part of "replace". So personally I would recommend to always use "Variant", since this way I can still continue playing another profile with the old version. In addition some updates comes as one or more patch-files, as HadToRegister already mentioned, and for things to work correctly you must use "Variant".

Hmm, would A → B, A > B and "load A before B" mean the same? If yes, the problem here is that the actual "winner" is mod B, since it's mod B's files that actually "wins" any conflicts and is used in the game, despite this is counter to the order indicated by →

Where's a bug with saving of ini-files for different profiles, see https://github.com/Nexus-Mods/Vortex/issues/4956

Vortex uses %appdata%\vortex for storing information of mods, rules, profiles etc. In addition Vortex stores downloaded mod-archives under the "Download Folder" as mentioned under Vortex - Settings - Download For each game you manage Vortex also stores installed mod-files under the "Mod Staging Folder" as mentioned under Vortex - Settings - Mods for the specific game you're currently managing. Lastly for SSE, Fallout4 etc., you can have hard-linked files "Deployed" to the games directory, using "Purge" on Vortex mods-tab should remove these files again.

To re-run FOMOD installer you must use a mod that includes a FOMOD installer. The linked mod with the version "Aerys NPCs - All in One Compilation All DLCs Required" only includes a single esp-file and wherefore does not include any FOMOD installer. Since a search for "all in one" only gave this download option at least to me it doesn't look like this mod uses FOMOD, but graned I've not looked on the 43 other downloadable files.

This last test is useless, since FOMOD installers don't normally install the FOMOD installer in the mod staging folder. It's only mods that includes fomod\info.xml but not fomod\moduleconfig.xml you'll see "fomod" installed to the mod staging folder.

Uhm, what? I've had (and resolved) many mod conflicts before deploying, since it's more efficient to do it this way if you've just installed 100+ mods.

If manually extracts SKSE to mod-folder, I don't put anything in downloads.

Modifying the skse archive is a waste of time, since regardless of how you pack the archive the second Vortex extracts the data directory it is removed, meaning you can never install both exe + script without either change Vortex to correctly handle this, or you must manually move the files around yourself. Now if you split skse into two separate archives on the other hand with one only containing scripts and the other the rest re-archiving can work. While you can install scripts from original skse archive, if you tries the same with exe Vortex always screws up by putting exe + dll into a sub-directory. Now some will say skse is not correctly packaged, but this is nonsense since it is Vortex that isn't correctly extracting and installing the files, meaning it is Vortex that needs to be fixed. At the moment the best way to install skse in Vortex is to extract skse directly to the mod staging folder, re-start Vortex, and after Vortex detects the new mod change to dinput. Some of the advantages of installing at least the scripts with a mod manager are, conflicts with other mods are shown and you can easily make sure a mod using an outdated skse script is overwritten, updating skse makes sure all scrips are new. Also if you're looking for any non-managed files left over in data directory, by purging the installed scripts will be removed and you don't need to waste your time checking the scripts are from skse. Since Vortex can also manage exe + dll + anything else going under root and not under data, it is very unfortunate Vortex makes this unnessesarily complicated. One way to improve things would be if it was possible to select dinput before installing the mod and in this case change Vortex to not delete data and not put exe + dll into a sub-directory on installation. Alternatively Vortex could auto-detect skse and correctly install + automatically choose dinput.

Vortex, Settings, Downloads, "Download Folder"..., change this to something else, and Vortex will start moving all the downloads for you, a process that can take some time. Vortex, Settings, Mods, "Mod Staging Folder"..., change this to something else, and Vortex will start moving the installed mods for you, for the active game. Again, the move can take some time. So, Vortex can already do this, and at least in my experience you'll also keep the information, like all the rules etc. created between mods.

All the numbered directories looks like NMM's mod-directories as they're created under NMM's VirtalInstall-directory. You having such directories in Vortex is on the other hand not as it should be. One possibility is Vortex import from NMM has gone horribly wrong. Another possibility is you've copied the mod directories from NMM into Vortex, but made a mistake and put all of them under a sub-directory of the \mods\-directory (Mod Staging Folder). A third option is you've copied the mod directories from NMM to the data-directory. Making a mistake with the directories also is a possibility, but at least your current game data folder that appears to be "d:\program files\steam\steamapps\common\skyrim\data" should be ok and the same with your current mods-directory "d:\games\vortex\mod install\skyrim" To find out where all the numbered directories comes from, in Vortex on mods-tab click "Purge". After Purge has finished, check your data-directory again. If the numbered directories are still present, this means you've manually added these directories to the data-directory or NMM has screwed-up or something. In this case deleting everything in data-directory and afterwards verify game files in Steam would be my suggested approach. If on the other hand Purge removes the numbered directories from data-directory, this means these directories are located somewhere under your \mods\-directory and you should look here to find them.