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.

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.

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.

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.

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...

I have reviewed a similar report today but was not able to reproduce.

If you edit anything in the main .ini file and deploy, vortex will transfer your manual change to .ini.base, then regenerate .ini.baked and .ini from that information.
 
For the curious, this is the mechanism at play here:
 
Some Vortex settings require Vortex to change certain ini settings (e.g. to facilitate profile-local save files) but most it doesn't touch.
.ini.base is the reference file, containing your custom ini settings with none of the Vortex changes.
.ini.baked is .ini.base with the vortex settings applied.
.ini starts out as a 1:1 copy of .ini.baked
Early during deployment, Vortex compares the .ini file to .ini.baked, any changes it will assume you did manually (in a text editor, inside the game or bethini, doesn't matter) so it transfers these changed settings (and only those) to .ini.base, then regenerates the other two files.
 
Now regarding the shuffling:
First thing to note is: .ini is not a standardized file format, different tools use similar but different formats and call them .ini, they may be 95% compatible but never 100%.
 
That's relevant because Vortex, to retain perfect compatibility, uses the same interface (windows api) as the game to read and set ini settings.
And this interface does not allow me to look at the file as a whole, I only ever read or set individual values, like I can say "windows api, please tell me the value of [General] -> iSomeValue" or "windows api please set the value [General] -> iFoobar to 42" and then windows changes the value and writes the file in whatever way it sees fit. The api doesn't usually change the order of the ini but it also doesn't let me dictate it. To take that control I would have to use a different interface which is then not fully compatible.
 
But also: because I transfer only the values that changed from .ini to .ini.base and then re-create .ini.baked and .ini from it, any changes to the order will be lost. Again: Vortex doesn't _see_ the order of entries, only the values. It will always fall back to the order in .ini.base which was created the first time you started managing the game.

Please try installing the visual c runtime (https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads - this is an official microsoft download) and let us know if this helps

The notification is generated by parsing the skse log files, so it will only go away after you ran the game (via skse) with the incompatible plugin disabled.