Tannin42

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.

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.

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.

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.

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.

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)

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.

When you had Vortex installed previously, the one-click installer acts as an updater, using the existing install location from your registry.
So you initially installed Vortex with the custom installer, installed to F, didn't uninstall Vortex and now you've unmounted drive F.
 
You could clean up the registry key manually but the simpler solution is to just use the custom installer (from https://www.nexusmods.com/site/mods/1?tab=files) again.

There is an extension for that: https://www.nexusmods.com/site/mods/88
but a thing to keep in mind is that Vortex is based on chrome for the browser but it's on a slower release cycle so the browser component may be affected by publicly known security issues so you might want to limit your browsing to well known/trusted sites.

The "Content" column in the mods list shows icon indicating whether the mod contains textures, audio, scripts or whatever.
"Refresh Content" re-analyses the mod directory to update those icons. If you haven't modified the mod it will do nothing.

Usually I do try to assign feedback with too little information to an existing ticket with a canned response asking for more information.
 
The only tickets I close immediately are those with profanity or threads, those that would dox the sender if published and sometimes messages that we can't do anything about but constantly get reports for - so for example over the last weekend there was a bit of an api outage and the error messages in Vortex very clearly stated that it was a temporary server error yet we got dozens of message about that. I'm not going to spend most of my Monday replying to those individually.
 
But as Picky said: we get more feedback than I can reply to while still doing developing Vortex so feedback can pile up. So currently, if a request is already on the agenda or a bug already known I may leave the ticket in the queue as a reminder but not export it.

Anyone can create a collection but currently Vortex is the only tool for that and it doesn't support Mass Effect 3.

The best strategy I find for large cycles like this is to identify mods you would want to load last, stuff like patches/fixes, that are supposed to load after everything else. right-click that mod and then select "load last among connected".
Then also repeat this for mods that are very "specific", e.g. a texture mod changing only a specific location vs a big texture overhaul for the entire game.
 
At that point it's really up to you in which order you want stuff to load but generally I find that identifying the mod that should definitively override the others and then selecting the "Load Last" option more convenient than flipping individual rules.

Ok, so what you deleted were the archives, any mod that was already installed is still there.
Technically you should be able to hit the "Resume" button on the collection and it will (re-)download everything that's missing.
 
The failure to remove mods is a separate problem. You should have also gotten a notification (top right) telling you that no deployment method is available.
This is very likely because Vortex, by default, sets its staging folder on drive c: but for some games, including Skyrim, the staging folder is required to be on the same drive as the game (that's just how the game works unfortunately).
 
The way you fix that is: before you resume the collection, go to settings->mods. Besides the input field that says "Staging Folder" there is a button that says "Suggest", that's the easiest way to assign a "valid" folder. Then click Apply and follow the instructions on screen.
Once it's done you can either resume the collection installation or remove the mods if you like.

To be more specific: FOMM (FallOut Mod Manager) introduced a mod format where the mod includes a piece of code written in c# that is then responsible for offering and installing options in the mod.
The mod manager compiles this script into a runnable application, then executes it.
 
There is no way to support these mods and not depend on .NET because the scripts depend on .NET, doesn't matter which programming language the manager itself is written in.
 
To safe ourselves work and for better compatibility and since we had to depend on .NET anyway, Vortex uses part of the old NMM application (written in c#) to handle most mod installations even for mods that do not use the above format but these installers are the reason it just never made sense for us to rewrite that functionality.

If you purge mods they get removed from the game but not from Vortex - when you deploy the next time they're all back.
 
You could also create a new profile that has no mods enabled, switch to that profile if you need the game to be vanilla.

Theoretically it should work. You have to pause the collection and any active downloads. Then, as rmm200 said, use settings to change the download directory. When it's done, resume.
 
Do NOT move the download directory manually with windows explorer, always go through Vortex settings.

yeah, move deployment is the only option if your filesystem is fat32 (or more generally: doesn't support symlinks or hardlinks)
 
The way move deployment works is that the actual files are moved to the game directory, leaving behind (in staging) vortex_lnk files to keep track of which files were deployed this way.
It is super easy for users to mess this up, e.g. if you delete the vortex deployment file, Vortex may forget it deployed at all and then treat the link files as actual files.
 
Also, and I think that may be the problem in your case: You can't run tools from the staging folder directly because the staging folder doesn't contain actual files any more. The only solution is to deploy the tools and run them from the game directory, not from the staging folder.

you're using Vortex 1.4 or older.
Collections were added in Vortex 1.5.

You say you read the other posts about hard links but you clearly haven't understood them: The hard links in the skyrim game folder do not take up space on your disk. They are not copies, they are links.
 
You are plain simply wrong about not being able to use the space because it's not gone.
 
Have an example:
Assume you have a 2TB disk. You have 1.5TB of data on the disk. So you have 0.5TB space left.
Now you create hard links of all the data on disk.
Now you have a 2TB disk. Windows will tell you you have 3TB data on that 2TB disk. And you still have 0.5TB space left.

Download and install this: https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170 (The x64 version)
Please report back whether this helped or not.

Just let Vortex do it's thing, these updates are a few kilobytes usually.
 
For one thing: these extensions provide the information on how to detect the game in the first place so without the extension, Vortex wouldn't know that you don't have the game and thus couldn't decide to not update it and for all Vortex knows you might have the game and the update is what fixes the detection.
 
But also: Vortex extensions aren't "isolated", an extension can provide functionality for a whole bunch of games (like the gamebryo plugins extension providing the functionality for a whole range of Bethesda games).
Game extensions are fundamentally the same, just because an extension is the "Skyrim" extension doesn't mean bugs in that extension can't negatively affect you when you try to play other games.
They shouldn't of course but I can't vouch for the code of everyone else.
 
So just allow Vortex to update - even if just so we know everyone is on the same version.
The alternative is for us to release more full Vortex updates which are then >100MB downloads...

The way I read the article the security vulnerability is in the User Interface of 7zip (7zFM.exe), we don't even use that. Vortex uses the 7z command line tool.
 
EDIT: Reading further into it the issue is disputed because it couldn't be reproduced and is now considered a hoax by many.

Settings -> Downloads -> Download Threads
 
As a premium user you can increase this. Vortex will use up to 4 threads per single download so if you increase it to 5 or higher, Vortex will download 2 files at once, at 9 it will download 3.
As long as you only download one large file at a time, this should ensure the small ones get finished and you can start getting them set up.
 
We have no smarter scheduling at this time - reserving one download thread for small files could be a really neat feature though. Feel free to create a feature request for that through the feedback system if you want.