Opinions please - Per-file overwrites

[Tannin42]

A frequently requested feature is the ability to decide file conflicts on a per-file basis instead of entire mods, I'd like to hear opinions on

how this could be implemented from a UI perspective.

Current Situation:

Right now you can only resolve file conflicts between mods (Mod page!) by setting rules (load after) between them, which controls the

installation order of the entire mod.

In some cases it may be necessary to set how a conflict is resolved for each file individually.

It's important to keep in mind that this can be arbitrarily complicated: two mods may conflict on only a few files or they could conflict on

thousands.

Other Mod Managers:

In NMM you have to decide which files to keep during mod installation, you can click "Overwrite All", "Skip All" or you have to pick between

Overwrite or Skip for each file individually.

While this is very intuitive it can be a tremendous amount of work if you have to overwrite 2000 files and skip 3. It also doesn't let you correct

a mistake, if you misclick you have to reinstall the mod (potentially both) and start over.

It's also not very "visual", all you have available to make the decision is the name of the file.

I consider this the worst possible solution that still solves the problem.

In MO you arrange the mods first. It then offers you a "preview" of how the output directory will look like, including which mod provides each file.

You can then navigate this preview and hide individual files from the highest priority mod, thereby allowing the file from other mods used.

This lets you do over as much as you need and you can browse relatively quickly to the file you need.

MO even provides previews of some file types, e.g. textures so you can see the file before making your choice.

This solution is a lot more user friendly but it still has some issues:

* For one thing it can get rather slow with many (loose file) mods installed and

* second "hiding" a file is an action you have to undo manually. Lets say "mod a" and "mod b" both provide the file "x.dds" (among other thigs). You have a rule

to load "mod b" after "mod a" but you want the "x.dds" from "mod a". So you go and hide the "x.dds" from "mod b".

This gets you what you wanted. However, if you ever disable "mod a" the "x.dds" is gone entirely. You'd still have to unhide it manually.

That's because MO doesn't know why you hid the file and that that reason is gone with the removal of mod b.

* also, if you have, say, 5 mods providing the same file you may have to hide up to four files to get the one you wanted.

Proposed Solution:

What I think would be the best solution is this: In the menu of each mod we add an action "show me all the files in this mod that have been overwritten by something else".

It shows a new dialog with a file tree, similar to MO but only with the files that exist in this mod but aren't used because another mod overwrites it. This makes it a much

more compact list than the one in MO.

Then you can select all the files (checkbox) you want from this mod and save. If you ever uninstall the mod this list of "overrides" is uninstalled along with it so the

corresponding files from other mods get used again. We can also show an icon on the mod list to signify that this mod has such overrides and we can offer file previews in

the dialog.

I think this adresses all the issues with the MO system while also being a bit more intuitive (You express the reason why you override the install order "I want this file from this mod". With MO you say "I don't want this variant of the file", but you don't state which one you want.). Only drawback is that it doesn't provide an overview of all file conflicts across all mods.

Thoughts?

[Grestorn]

I agree with this solution.

 

BUT you should also have an overview of the resulting file tree - where you can see each file and which mod provides that file. Using color codes like in MO to make it clear if a file is provided by more than one mod.

 

And, to make things easier, you should also be able to right click on a file and select which mod should be providing this file in the way you proposed.

 

It would also be very user frienldy, if the same context menu would allow to add rules: I click on a weapon texture and see that my mod x is overwritten by mod y. Instead of having to move to the mod page to make a rule there, it would be perfect if there'd be a way to add a rule right here and there which forces x to be loaded after y.

[LawrenceFB]

Will this only be for loose files? If a file in a .bsa is being overridden will this be reported? Much that I would like to select files from a .bsa to be my chosen file ,at least for textures and meshes, it would be nice to be able to indicate that you do not want any copy of a loose file if there is one in a .bsa.

[SkunkMonkey]

Honestly, I think you should be able to not install any file, not just those with conflicts. I find mods installing all kinds of crap that are not required for the mod to work. Things like readmes, screenshots, etc. that just clutter up the game directories. This is one of the features I liked most about MO. Even if it's something like hiding the file, anything to reduce the amount of cruft that ends up all over the Data folder.

 

Regardless, anything that gives the advanced user more control is always a Good Thing^™ in my book.

[rmm200]

I go with what Skunky said.

But I really miss the ability to unpack BSAs as part of installation. If it is a mod I am working with - BSAs are nothing but a hindrance.

This sort of goes along with the need to detect conflicts within BSAs.

[LawrenceFB]

 

 

Honestly, I think you should be able to not install any file, not just those with conflicts. I find mods installing all kinds of crap that are not required for the mod to work. Things like readmes, screenshots, etc. that just clutter up the game directories. This is one of the features I liked most about MO. Even if it's something like hiding the file, anything to reduce the amount of cruft that ends up all over the Data folder.

 

Regardless, anything that gives the advanced user more control is always a Good Thing^™ in my book.

 

 

 

Being able to hide files would be a nice feature, especially for those that like things tidy, but I think that is a separate issue for conflict resolution. I like the idea of choosing the file you want rather than hiding the files you do not want.

 

By all means hide a file you never want to use.

[Tannin42]

Will this only be for loose files? If a file in a .bsa is being overridden will this be reported? Much that I would like to select files from a .bsa to be my chosen file ,at least for textures and meshes, it would be nice to be able to indicate that you do not want any copy of a loose file if there is one in a .bsa.

 

Not necessarily, the feature could be extended later to also include bsas so that if you select a file from a bsa as the override, vortex would effectively not install the loose file at all, allowing the bsa to get loaded.

 

However: file conflicts between bsas can not be resolved this way. If we wanted to support that we could build a feature where vortex extracts individual files from the bsas during deployment, this way you don't change the mod but can still have bsas override loose files and other bsas.

 

BUT: This requires separate consideration, extracting from bsas can be quite problematic, especially regarding scripts so I ask that you please don't consider this as part of this discussion.

For the time being this feature is only about loose files.

[Tannin42]

Honestly, I think you should be able to not install any file, not just those with conflicts. I find mods installing all kinds of crap that are not required for the mod to work. Things like readmes, screenshots, etc. that just clutter up the game directories. This is one of the features I liked most about MO. Even if it's something like hiding the file, anything to reduce the amount of cruft that ends up all over the Data folder.

 

Regardless, anything that gives the advanced user more control is always a Good Thing^™ in my book.

 

Good point, but I'd argue that this is a separate feature.

As I described above: The MO variant of hiding files has some serious disadvantages in regards to file conflict resolution, I'd rather add two features, one for removing clutter, one for file overrides that are both

custom fit for that task than have one tool that is mediocre for both.

 

Avoiding clutter could be assisted by stuff like matching expressions, so instead of hiding each file individually you could hide

- readme*

- screenshots/*

and so on, with the option to create patterns that apply to all mods and patterns that apply to only one mod specifically.

 

But again: This would be a separate feature, please keep this thread focused on file conflicts

[LawrenceFB]

 

Will this only be for loose files? If a file in a .bsa is being overridden will this be reported? Much that I would like to select files from a .bsa to be my chosen file ,at least for textures and meshes, it would be nice to be able to indicate that you do not want any copy of a loose file if there is one in a .bsa.

 

Not necessarily, the feature could be extended later to also include bsas so that if you select a file from a bsa as the override, vortex would effectively not install the loose file at all, allowing the bsa to get loaded.

 

However: file conflicts between bsas can not be resolved this way. If we wanted to support that we could build a feature where vortex extracts individual files from the bsas during deployment, this way you don't change the mod but can still have bsas override loose files and other bsas.

 

BUT: This requires separate consideration, extracting from bsas can be quite problematic, especially regarding scripts so I ask that you please don't consider this as part of this discussion.

For the time being this feature is only about loose files.

 

 

I agree extracting from bsas needs to be considered separately, possibly as an 'advanced' feature. I was only suggesting having a 'none' option if the file was available in a bsa as, at this time, you cannot select a file from a specific bsa and it would be misleading to suggest the user could.

 

I do hope we will at some point get some indication in the Mods tab that a mod is using bsa files :smile: .

[Rattledagger]

Only showing the files currently being overriden has two immediate disadvantages, for one if you now says you want to override instead, saves and re-enter you'll come up with a blank list and in case you made a mistake this makes it difficult to fix this mistake. For another if you've just set a per-file rule for mod A to override one of mod B's files, when you later opens-up mod B it's not certain you remember the rule you've created for a particular file.

 

On the mods tab when you click on the lightning-bolt the two main options are "load before" and "load after" and additionally any mods currently having a rule is indicated. One immediate weakness here is, if you set a rule for a mod with a rule already indicated you won't remove the current rule, you'll instead very likely create a cyclic rule - and this is definitely a weakness that should be fixed.

 

Having the same functionality for the per-file loose file load order (and later extendable to bsa) but without the weakness the best would be something with togglable lists:

 

1: Show files being overriden by other mods where you haven't set a per-file loading-rule.

2: Show files overriding other mods where you haven't set a per-file loading-rule.

3: Show files with a per-file loading-rule.

 

Default should be 1, where you can toggle 2 and 3 on/off as you wants. For very short lists always showing all three categories would make sense. Additionally for each file number of conflicting mods for this file should be shown.

 

Functionality:

 

If you're in list 1 and select a file where only one other mod conflicts, you've got three options:

 

a: No rule, current mod loses. ==> on saving and re-loading this file is in caregory 1.

b: Create rule, "load after" meaning current mod wins the conflict ==> on saving and re-loading this file is now in category 3.

c: Create rule, "load before" meaning current mod loses the conflict ==> on saving and re-loading this file is now in category 3.

 

If you're in list 1 and select a file where two or more other mods conflicts, you've got at least two options:

d: No rule. ==> Is kept in category 1.

e: Mod X wins the conflict. ==> is moved to category 3.

 

List 2 has basically the same options, except choosing a: No rule means current mod wins.

 

List 3 includes the options:

f: Remove current rule. ==> on save and re-load file shows-up in either category 1 or 2.

g: Change current rule, swapping before/after to after/before in case of one conflicting mod, chosing example mod Y wins in case of 2 or more conflicting mods.

 

The advantage for always having the option of choosing which mod wins a particular conflict is, when you opens-up a mod and see 2 or more mods conflicts, you look on file-preview (when applicable) and example see "Current mod A I don't like, mod B I don't like even B is currently winning but I like mod C the best and want to use this mod's file", having the option of immediatley picking "mod C" solves the conflict. If this isn't an option you'll instead need to exit current mod, find mod C in the list, for so trying to find-out the same armour or whatever conflicting and finally saying "mod C wins". This adds unnecessary extra steps and is avoided by always having the option to say which mod wins a conflict.

 

While having the option "loose conflict" seems redundant when you're already losing the conflict, and the same for "win conflict" when you're already winning, the advantage is when you explicitely says you're loosing/winning the conflict Vortex will remember this and since the file now shows-up in a different category you're always aware you've made a choice of "I want this file to loose or win", instead of having the doubt "Have I already looked on this mods files and didn't care to change anything, or do I care but haven't looked on this mods files?"

 

Also worth nothing, with example mod A, B and C containing the same file and you say mod C wins the conflict, regardless of which of mod A, B and C you opens-up the particular file always shows-up in category 3 with "mod C wins" (unless you removes/changes the rule). One concern is, what should happen if mod C now is disabled/uninstalled...