Rattledagger

Uhm, unless you disable updates, until a new version fixing the problem was released, wouldn't you basically get stuck in the infinite loop "install 1.5.7" --> "get upgraded to 1.5.8" --> "install 1.5.7" --> "get upgraded to 1.5.8" etc.

Messages permanently going-away after a few seconds isn't very useful if you expect users to see the message and even less useful if users are supposed to have the option to interact with the message.

I've never tried this particular Vortex extension, but you can in Vortex under "Extensions"-tab click "Find more" and search for "Download Game Assigner". After installing this extension and re-starting Vortex, under Settings - Downloads where should now be a new option where you can assign downloads for game X is compatible with game Y and afterwards any new downloads for game X should be possible to install in game Y without getting any warning about "different game".

Doing a very quick test with Skyrim, not SSE but the original one. With only SKSE + SkyUI + unofficial patches, putting game and Vortex mod-files on network drive works and starting game only takes 16 seconds, whereof a few of the seconds is for playing the logo-video. Still, one disadvantage is, every time you deploy, purge or switches between profiles it seems all files are detected as "External changes". At least with original Skyrim it kind-of-work, but I wouldn't recommend doing this. edit - running Skyrim from SSD takes 11 seconds to start the game, meaning even with this small setup you'll use 5 second longer to start the game off networked HD.

While the MO2-executable as default installs to c:\modding\mo2, if you create a global MO2-instance this as default uses %localappdata% for storing downloads, mods, profiles etc. for this instance.

Note, "dinput" has been re-named to "Engine Injector" in more resent Vortex-versions like v1.4.12.

Quick test, after manually downloading the mod the zip-file includes 9 sub-directories of the main folder, thereof 5 of them are empty while the 6th. sub-directory includes two empty sub-directories. So clearly you can't rely on file preview to see empty directories. Since I've not got Mount and Blade, tried adding mod to SSE instead and using the option "Unpack (as is)", but this only unpacked the 3 sub-directories with files in them.

As the warning say, you've got a BSA that claims it's made for Oblivion but you're trying to use this BSA in another game. Trying to use for another game has 3 possibilities: 1: BSA crashes the game. 2: BSA is not loaded at all. 3: BSA is successfully loaded and you can continue using BSA even it claims to be for another game. It's possible where are some kind of penalties for using BSA, but you can still use the BSA. So, did you try to run the game with the bad BSA? Did the game crash, did the game run but BSA did not load, or does everything seem to work ok? If the last, chances are you don't need to do anything at all. For more information, and ways to remove the warning-message, see Bethesda mod archives - Nexus Mods Wiki

For most mods install-order doesn't matter, making it easy to batch-install 100+ mods at once. But, where exist mods using FOMOD-installers that is so "intelligent" they absolutely refuse to install unless the mod(s) they depends on are already installed and enabled. A few FOMOD-installers auto-pick correct choices depending on enabled mods but still allows you to pick option for disabled mods. For these FOMOD-installers it can be an advantage to install mod after all other mods.

In addition, it's recommended to click gear-icon on far right and enable "LOOT Messages (inlined)", since this way you'll see the various messages like "Patch available at ..." or "Don't use plugin X with plugin Y" etc., directly on Plugins-tab, without having to double-click plugin to see this information. Note, you need to sort Plugins for LOOT messages to update.

I've got no experience with Valheim, but would guess you've got the same problem as with Skyrim, where the installer is "clever" enough to remove the \data\-directory then extracting the mod-files, unless you uses "Unpack (as-is)" but you can't really expect mod users to remember using this option. The easy method to work-around Vortex deleting \data\-directory is, split the mod into two mod-archives, where first mod-archive has all the files going to games root directory (and sub-directories except \data) and the second mod has all files going to \data\-directory. The more difficult method that hopefully would work is using FOMOD in the following way: <file source="\root-directory-files\file1" destination="\plugins\file1" /> <file source="\root-directory-files\file2" destination="\plugins\file2" /> <file source="\data-directory-files\file1" destination="\valheim_data\file1" /> <file source="\data-directory-files\file2" destination="\valheim_data\file2" /> <file source="\data-directory-files\file3" destination="\valheim_data\file3" />By not using \valheim_data\ in mod-archive you're at least sure Vortex won't put the files somewhere else during Vortex extracting of mod. Since \valheim_data\ now is part of FOMOD, hopefully Vortex won't change files destination, but you'll need to test what Vortex does in this case. Also, not sure if you in FOMOD need to create the \valheim_data\-directory before copying files or not.

Some games only works with hardlink deployment and hardlinks only works if game and Vortex mod staging folder is on the same disk. Example, the Fallout games and the Elder Scroll games only works with hardlink deployment. Meaning, depending on game, it's maybe not possible to move mod staging folder to HD, unless you also move the game to HD. In any case, to move mod staging folder, you must do this inside Vortex, by specifying a new location of the mod staging folder and Vortex will move the files for you.

Vortex v1.4.x on Plugins-tab in addition to "Enabled" and "Disabled" now includes the 3rd. option "Ghost". A ghosted plugin is in /data/-directory re-named by Vortex to include a .ghost at the end of the file-name and is wherefore not included in plugin sorting.

While automatically deploying is a good idea then you've got 10 or less mods, if you've got 100+ mods and frequently install more than a single mod at a time, disabling auto-deploying is my recommendation.

Some games, like Skyrim and Fallout has in additiion to the Mods-tab the Plugins-tab, where you can enable/disable plugins. This comes in addition to first enabling and deploying the mod the plugin comes from.

Auto-deploy is the Vortex default and this is likely the reason the guide you're looking on don't mention you can turn on auto-deploy. The default progress is Download --> install --> enable --> deploy --> fix mod conflicts --> deploy --> handle plugins (if relevant for selected game). In Vortex v1.4.x you can change the settings so Vortex automatically after finish download does the --> install --> enable --> deploy steps, but you'll need to manually fix mod conflicts and you need to manually deploy afterwards (Vortex will tell you you need to deploy after handling mod conflicts). As for editing files, depending on how you did edit the file it's possible the hardlinked file already was updated and in this case deploy won't do anything. If on the other hand the hardlink was broken by editing the file, next time you deploy you'll get the "External change"-dialogue. If you example uses Notepad to edit ini-file this will not break the hardlink and you won't get any "External change"-dialogue for this, meaning after Notepad editing deploying again won't do anything. As for having auto-deploy on or off, since you anyway need to manually deploy after fixing mod conflicts, coupled with Vortex is AFAIK still too stupid to understand that if you've example got 9 more mods in your installation-queue where's a waste of time to deploy after installing the first mod, so in practice disabling auto-deploy can be a good idea.

With a few mods unhelpful name like "Update" or "version 2" or something similar it is unfortunate Vortex don't have the option to directly use the mod-archive name. But, after you've installed a mod, you can double-click the mod in Vortex to open-up extra dialogue on the right, for so change "Mod Name" to whatever you want. The problem here is, auto-detecting which Nexus-mod a mod-archive comes from is a feature (and 99% of the time this is a highly desirable feature) and not a bug, and part of this feature is to use whatever Nexus-information the mod-creator has set, including calling this "Update 2" or something similarly unhelpful. Since it's not really a bug, you can instead use one of the following work-arounds: 1: Never log into Vortex and if not mistaken this way Vortex can't query for Nexus-information. 2: For the few mod-archives this is relevant, re-package the mod-archive yourself. Example you can take the original 7z-archive and create a zip-archive instead and since zip-archive is unknown to Nexus you won't have any Nexus-information for this self-created mod-archive. 3: Re-name mod after installation.

Since MO2 never physically adds any files to /data/-directory any mod installed by MO2 won't interfere with Vortex. Vortex on the other hand as default uses hardlink deployment and this means mods will physically appear in /data/-directory or games root directory. This means after using Vortex to mod a game, to use MO2 afterwards to mod the same game without being "contaminated" with the Vortex-installed mods, where's at least 4 methods to handle this: 1: Every time finished in Vortex, make sure uses "Purge". 2: Every time finished in Vortex, make sure to switch to another Profile with no active mods. 3: In Vortex under Extensions, click "Find More" and install "Fully Virtual Deployment" and after Vortex is re-started you can under Vortex - Settings - Mods choose "USVFS Deployment". 4: Use separate Windows user accounts with separate game directory. Disadvantages: 1 + 2, you must in Vortex remember to purge or switch profile before using MO2. Also with 1, if you in Vortex switches to another game, Vortex always Deploys the purged game. 3: USVFS is the same method MO2 uses, but with at least last time I tried in Vortex you can't use FNIS and similar tools to generate new files (in MO2 this goes in /overwrite/-directory but Vortex don't have overwrite). As a work-around, you can use hardlink deployment, generate FNIS and similar for so switching to USVFS. Also with USVFS you can't in Vortex install mods to games root directory, but having to manually install SKSE, ENB etc. isn't really much of a problem. 4: Separate Windows user accounts with separate game directory means duplication of game files. Note, since I've not got VR I've no idea if where's any special considerations then it comes to Vortex and Skyrim VR, but at least with original Skyrim and SSE jumping between Vortex and MO2 is possible.

While old Vortex-versions, if not mis-remembers v1.1.x and earlier, did have multiple problems with ini-files, I'm not aware of any problems with current Vortex-versions. If you're using profile-specific save-games, Vortex must change skyrim.ini by changing the location of sLocalSavePath to point to the profile-specific location. In case you Purge the sLocalSavePath will be removed. I'm not sure if at the same time you switch back to the generic ini-files that is common for all profiles that don't say you're using profile-specific ini-files. If you're switched to the generic ones on purge, any changes you make to ini-files before you deploy again will be removed by Vortex, since you're basically editing another profiles ini-files. Apart for Purge removing sLocalSavePath and Deploy adding sLocalSavePath, the only other time Vortex makes changes to ini-files is if you switch to another profile. Example, if you've got two profiles A and B and with A active you makes some changes to ini-files for so switching to profile B, the changes you did to ini-files for profile A is not present for profile B. I'm not aware of any current problems with Vortex handling of ini-files, at least last time I checked skyrim.ini and skyrimprefs.ini was correctly handed if I used the launcher or changed something in-game. Directly editing ini-files also worked correctly. BTW, since you're directly editing the ini-files, are you absolutely sure you're editing the correct file, meaning you're editing skyrim.ini and not the two Vortex-specific files skyrim.ini.baked or skyrim.ini.base and similarly are you editing skyrimprefs.ini and not skyrimprefs.ini.baked or skyrimprefs.ini.base?

ctrl+a, choose "Remove" to uninstall all mods. If you also wants to delete the mod-archives choose "Delete archive" in the dialogue that opens-up after choosing Remove on all mods. To be even more extreme, you can also delete all save-games and delete all profiles.

Vortex option is better, since you only need to put a specific plugin into the last LOOT Group once. After doing this you can add or remove as many other mods and plugins as you want and your specific plugin will still load last. In MO2 on the other hand, if you install one new mod that includes plugin, you'll get a new plugin at the bottom, meaning a new plugin after the plugin you put last. This again means, if you still want your particular plugin to load last, in MO2 you need to put the same plugin last every time you add a new mod that contains plugin.

For Morrowind, Vortex uses drag-and-drop sorting and enabling of plugins. This means, to enable a plugin, you drag-and-drop it from "disabled" half of screen to the "enabled" half of screen. Similarly, to disable a plugin, you drag-and-drop it from "enabled" half of screen to "disabled" half of screen. To change order of enabled plugins, you drag-and-drop a plugin above or below the other plugin(s).

Alternative method to edit individual files is to right-click a mod that have conflicts and choose "Manage File Conflicts" (it won't show if you've not set mod-rule yet).

It's important to let Vortex move the "Mod Staging Folder", since if you do this manually it's a good chance all installed mods will be duplicated and you'll lose all the conflict-rules. So basically, you should do something like this, where let's say you first select SSE: 1: On Vortex mods-tab, click "Purge" and afterwards exit Vortex. 2: In Steam, move game to another disk. 3: Run game launcher to setup registry etc. 4: Start Vortex, you'll get a message about game moved. 5: Just to be on the safe side, re-start Vortex. 6: Make sure new location of game is detected in Vortex. 7: Under Vortex - Settings - Mods, type-in a new location of "Mod Staging Folder" to be on the new disk. 8: Let Vortex move all mods for you, this can take some time. 9: Under Vortex - Settings - Mods, make sure you're using "Hardlink Deployment". 10: Under Vortex mods-tab, click "Deploy". 11: If you want to move another game, in Vortex switch to another game and start on step 1 again. For step 1, the main reason to use Purge is to speed-up step 2, since if you don't purge the mods you'll copy all active mod-files twice, first in step 2 and afterwards in step 8. A minor reason is, it's possible some of the files isn't correctly handled afterwards, meaning even if you disable or uninstall mod the files will be left behind. It's possible you can move multiple games at once, but it's safer to take only one game at a time. Note, if you Purge and switch to another game, Vortex will re-deploy game before switching to another game, making the Purge a waste of time.

Going by the screen-shot, the mod is "Rustic armor and weapons", https://www.nexusmods.com/skyrimspecialedition/mods/19666?tab=description