Tannin42

> When you use a mod collection, can you add other mods on top of the collection after you have installed it?
 
A collection is just an automated way of installing a set of mods so yes, you can add other mods or even additional collections on top.
But of course when you do that you may have to do more "manual" modding, e.g. you might see conflicts between the mods from the collection and the stuff you added on top. When you have a large collection and don't know what half the mods do, solving conflicts can get extra tricky.
 
> Can you use more than one mod collection on the same game (the same individual profile for a given game, I mean)?
 
yes. As above: understand collections as just an automated way of installing mods and making adjustments to them, it's nothing you couldn't have done installing mods regularly, it just would have taken more time and knowledge.
 
> Can you turn off mods from a collection that you don't want to use, or is the whole thing a package deal?
 
yes, you can. However: as long as a collection is active (enabled on the mods screen) it will occasionally check whether it is fully installed and if not (because you turned off a mod) offer to "finish the installation".
To get rid of that you either have to
a) fully "unsubscribe" from the collection, as in: you disable the collection entry in "Mods" but keep the included mods enabled
b) go to the collections screen and set the mods you don't want to use to "Ignore", that way the collection remains enabled but will no longer notify about that specific mod
 
> Has anybody created collections specifically for some of the more difficult systems (I'm thinking FINIS, SKSE64 and so on) that so many other mods use as a base set?
 
That I can't answer, there's just so many collections and I haven't reviewed them all but I would imagine there'd be collections to act as a baseline for further modding.

What you showed there should work just fine.
What it means is that
"test" would load after "Late Fixes & Changes"
"test2" would load after "test"
and "Dynamic LOD" would load after "test2"
"Dynamic LOD" would also explicitly load after "Late Fixes & Changes" which is implicitly the case anyway.
 
Meaning: The masterlist rule between "Late Fixes & Changes" and "Dynamic LOD" becomes redundant but it does no harm still being there.
If this isn't clear, maybe start thinking differently about what these rules mean. "b loads after a" means "b can't load before a". It doesn't say "b follows a immediately".
 
You can create new groups to load before the existing chain, after the existing chain and between any existing groups.
 
The only thing you can't do is change the order between predefined masterlist groups, you can't have "Late Fixes & Changes" load after "Dynamic LOD"

The downloads tab lists all archives in the game download directories (not subdirectories though) doesn't really matter whether they were downloaded through vortex or otherwise, as long as they're in those directories they will show up.
The table can be filtered though and by default it only shows the downloads you haven't installed already, you have to click "View All Downloads" to show the rest.

You are confusing cause and effect.
Vortex can't deploy _because_ your system has messed up file permissions.
You don't get messed up file permissions _because_ deployment fails.
 
There is no deployment bug in Vortex, hasn't been one in any stable release as far as I can recall and even then it wouldn't lead to permission errors. Deployment/permission problems are a symptom of your setup being broken, not the cause.

I was careful with my wording saying "don't leave it disabled" ;)
How you achieve that is up to you: put an event in your calendar for 2 days later or something going "re-enable vortex updates", stick a post-it node to your monitor or whatever works for you as a reminder.
 
Apart from the potential of security issues through third-party software we may also have to change the API between vortex <-> nexusmods.com at which point older versions will start failing; and we may receive an amount of bug reports from outdated Vortex versions that could become problematic.
 
Currently we have the option to disable automatic updates because most of our users are sensible and keep Vortex updated but a scenario where a significant number of our users remains on older versions is not sustainable for a small team like ours. If it becomes a pattern we always have the option to cut off older versions from the api to force users to update.
We don't _want_ to do that but the option to ignore updates is only there as long as the vast majority of users doesn't use it. No one should consider it a long term solution to anything is my point.

The "reset masterlist" button is no longer needed, the problem it was supposed to solve doesn't happen any more.

It's really difficult to provide help for these kinds of issues.
First of all, what this isn't:
- This error isn't caused by LOOT. Since the latest version Vortex downloads the masterlist itself. The error message about deleting the masterlist directory is also a bit outdated, since that update I can almost guarantee it won't help.
- ECONNRESET is also *not* a permission error, it's a network error.
- It's not a bug in Vortex
 
As I explained in the other thread: ECONNEREST means that the network connection was interrupted outside of Vortex's control, either by the server or your router/firewall/proxy or the backend.
 
Since it seems to affect you reproducibly and isn't intermittent, it's safe to say this isn't a server issue.
Do you use a regular consumer ISP or are you on a university campus or military network or anything like that?
If you live in China, they block various websites including github of course.
 
If it's none of that, that leaves only local network setup: your PC and its firewall/AV, router with _its_ firewall, proxy settings, ...

It should work but a lot of functionality will not work correctly. E.g. you won't be able to update mods you installed while offline because Vortex can't identify the files and where to get updates from.
For the same reason you won't be able to include it in a collection.

The backup doesn't (just) back up your setting, it backs up your entire application state. The only supported use for that backup is to restore it from inside Vortex on the same system, so why would you need to know the location?
 
The only thing we would make easier by showing you the location is to shoot yourself in the foot and considering large parts of this community will somehow manage to take their entire foot off with a spoon, it's not in our interest to hand you an actual gun.
 
The way you're asking this question, the thing you were obviously planning to do shows that you are exactly the kind of people why we have to lock these things down. If you had found the "Save copy" function you would have broken something because you didn't read the explanation for what the backup even does, even though there is a fat warning border around it.
Which makes me think we need to lock this down more, not less.
 
Vortex at this time has no functionality to transfer settings or mods to a different system, end of story. It could be done with a third-party extension or you could request it as a feature and we'll put it on the massive pile of features we've been asked for and prioritize
but there is no safe way to do it right now and you shouldn't just look for a feature that looks like it may be this if you squint really hard and then complain that that feature works as described rather than what you wanted.

My "Theme Snippets" extension also has an option for this so you can get rid of the overlay in any theme: https://www.nexusmods.com/site/mods/359

That is intended behavior, the __folder_managed_by_vortex don't having to clean them up would require deployment to look for empty directories, making it slower.
The directories will disappear if you purge and then deploy again.
 
Alternatively you can enable "Clean up empty directories during deployment" in Settings->Workarounds but it is a waste of time every time you deploy.

1.5.4 was indeed a stable release.
 
But people have to consider this: We had 49 alpha builds - ~30 of which where released to voluntary testers - and 3 beta builds over the course of 7 months. The number of testers was gradually increased, the final builds were used by thousands of users.
 
The only change I could identify that might have caused this issue was done 9 months ago, it was there for all those builds and this problem was not reported.
 
Some bugs just don't come up in testing, there's so many different ways people set up their modding environment, so many ways NMM might have been broken before people imported their mods from there and - yes - bugs in earlier versions of Vortex that cause trouble later. No amount of testing will prevent all problems when you go from 2000 users to 100.000 and we will never find them *without* releasing to more users at some point.

No, you have to purge if you want to add or remove mods with Vortex.
 
Going "Vortex in all its infinite wisdom" after you manually moved it is a bit like breaking someones legs and then going "why did you decide to not walk any more?"
You're the only one who made a choice here, Vortex is offering to repair it for you, that's how nice it is.

Es ist keine Bevormundung, was du versuchst macht nur einfach keinen Sinn.
Die Reihenfolge der mods hat nur ganz genau einen Effekt, unabhängig vom Spiel: Sie entscheidet welche Dateien überschrieben werden. Wenn zwei mods die Datei "textures/foobar.dds" enthalten entscheidet die Regel aus welcher Mod die Datei kommt.
Das ist alles, versprochen.
Wenn also zwei Mods keine Dateikonflikte haben (also keine Datei in beiden Mods vorkommt) dann brauchst du auch keine Regel um zu entscheiden welche Mod Vorrang hat, das wäre bestenfalls Zeitverschwendung.
 
Das gleiche gilt übrigens für die Pluginverwaltung: "steht natürlich schon auf manuelles sortieren" und so. Plugins definieren Records die in die Spielwelt eingepflegt werden, solange zwei plugins nicht versuchen das gleiche Record zu ändern ist es auch egal in welcher Reihenfolge du sie lädst. LOOT, was wir für die Sortierung verwenden, sieht die einzelnen Records und daraus entstehende Konflikte, du als Nutzer nicht (wenn du nicht gerade jedes Plugin mit xedit öffnest)

You can use a tool like Lock Hunter (https://lockhunter.com/), that will tell you which application is keeping the file locked.

The staging folder is not just the extracted archives, it contains only files the mod installer (fomod or otherwise) told us to install under the name they gave us.
That's not just options in a fomod, c# fomods can generate files directly, files can me renamed and moved and whatnot.
But also if you manually edit/remove files that would also affect the mods in staging.
So yeah, for a proper backup you have to back up the staging folder too.
 
The download folder is not actually required to play the modded games, those are "only" required to (re-)install the mods and if necessary you can re-download them from the server.

It really depends on the game. With a game like WOW, which is an MMO so modding is fairly limited (to ui enhancement I presume), sure, things are simpler.
But most games aren't like that, mods for single player games let you change a lot more but that also leads to more problems.
 
With Bethesda games (Skyrim, Fallout) and many others, modders have to take care of load order and compatibility patches between the mods they installed. Games like GTA5 or Dragons Dogma, modders have to open custom archives, arrange their mod files in there and generate new archives, taking care of keeping backups so they can restore the original game.
Games like Flight Simulator, Witcher 3 or Dragon Age you have to merge multiple text files (e.g. xml or scripts) together to get the mods to even get loaded.
Unity games (like Valheim) for example require a mod "loader" on top of a manager that needs to be kept updated when the game updates.
 
No mod manager can turn that into a one click affair or they will be super limited.
E.g. GTA5 mod managers, all except Vortex afaik, only manage one type of mods (script mods) while others (asset mods, as in new models, sounds, textures) have to be installed manually. Or Dragons Dogma: sure, NMM supports it and some find NMM simpler, but you can install exactly one mod for DD with NMM, the second one you install will replace the first one (with few exceptions).
 
Vortex supports > 170 games and for many of them it's the most fully featured manager there is and when it's not that's purely a matter of us not having the time, the framework is there.
Sure, the UI could be a bit nicer but by and large, for the interface to be simpler we'd have to drop functionality that maybe you don't need but others do.
 
Regarding updating: Vortex does update your mods but it is indeed more complex than on other services for a few reasons, not least because this site (Nexus Mods) doesn't force mod authors to provide an exact update-path for mods. Authors can upload an arbitrary number of files for each mod, those files can be updates, options, variants or completely separate mods.
Vortex (or any other mod manager) as a tool has no 100% reliable way of figuring out which file is actually the newer version of what you have installed, it has to guess.
And even if the site changed that today, that would still leave tens of thousands of mods for 1500 games, a lot of which have been abandoned that will never get fixed up for a proper, robust, update mechanism.
It may be secondary to you but this problem is not because of Vortex but because this site has existed as purely a download page for mods long before we started providing tools around downloading&installing mods.

Profiles do let you have separate mod lists but you seem to be confused about the different mod states.
 
If you uninstall a mod (removing the archive or not doesn't matter), it gets removed from all profiles - because it's no longer installed.
What the profile stores is the Enabled/Disabled state of mods. Only the "Enabled" mods will be applied to the game when you deploy.

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.

There is an undocumented, unsupported, use-at-your-own-risk-and-live-with-the-consequences option:
Run Vortex with the command line option "--user-data" like this: "Vortex.exe --user-data z:\my\totally\custom\location". You can of course create a shortcut for that. Vortex will then use that location for everything it would previously have used %APPDATA%\vortex or c:\programdata\vortex for.

Usually Vortex shouldn't block significant amounts of resources while in the background.
However with windows being what it is, it's really difficult to know how third party tools (overclocking tools, Antivirus, desktop themes/themeing tools, ...) affect that.
 
On the dashboard, if you press the '...' button for skse and in dropdown menu click "Edit" you can select between a few option on what Vortex should do when you start it, you could try if setting up Vortex to "Hide" (aka Minimize) when skse is started helps. Otherwise your best bet might be to simply set up Vortex to close when you start skse but then you'll have to start it again once you exit the game. Vortex doesn't need to be running for the mods to be active in the game.

Grounded is supported through a third-party extension (https://www.nexusmods.com/site/mods/268), not officially so maybe the variant you have (depending on the store you got the game from, e.g. Steam vs xbox) is not supported yet, but to get that fixed you should contact the extension author directly.

OneDrive is a cloud storage system that is integrated into windows.
That means that files in certain folders of your system (e.g. c:\users\<username>\OneDrive\Documents) are uploaded to and synchronized with a server and when Windows feels like it it may delete the local files and only restore it when applications try to access them.
If OneDrive has decided to remove a file from disk and then their servers are unavailable (because come on, it's Microsoft we're talking about), so are your files. Same is true if you're having network problems of any kind: your system, your router, your AV, your ISP, doesn't matter who's fault it is, files you thought you had on your computer are suddenly dependent on a network connection.

"Today the same bs happened again, i havent even started Vortex yet, and yet the skse64_loader.exe is gone[/size]"

How do you suggest Vortex deleted the file if Vortex wasn't even running?
Vortex doesn't "Take ownership" on anything, Vortex does the thing you ask it to at the time you *run Vortex*. Vortex doesn't do anything if it's not running.

The fact you have ".vortex_backup" files indicates that you installed skse through Vortex but at the time you did, you already had skse installed manually (or with another tool). That's why vortex created these backups, they are the manually installed skse files. Because Vortex doesn't overwrite if it doesn't know where files came from, it renames them to .vortex_backup.
If Vortex had uninstalled skse it would have restored these files, renaming them from something.someting.vortex_backup to something.something.
 
The fact the actual files are gone but the .vortex_backup files are still there means that something else deleted those files and Vortex didn't even have any opportunity yet to try and repair anything.
 
The fact you had to take ownership on the directory after you were obviously able to install to it before means that either you ignored the recommendation of not running software as admin or something else changed the file permissions on that directory. Something not Vortex, because Vortex can only losen file permissions where necessary, it doesn't even have the code to make them stricter, not even accidentally.
 
You will continue being very unhappy if you insist on randomly pointing fingers at the first thing you can think of and insist that is at fault instead of trying to figure out what is actually causing your problem.

The .base and .baked files are indeed created by Vortex but please ignore them, don't edit or delete them.
Vortex needs these files to figure out which changes _you_ made (in the game, launcher, bethini, ...) vs changes Vortex itself (or one of its extensions) made so that it can undo its own changes without reverting yours.
But you can make any changes you want to the regular ini files. As I said: you can completely ignore the base/baked files.