We have a name! And a Q&A session with Tannin regarding the new mod manager.

[Tannin42]

In response to post #49984317.

  Reveal hidden contents

  Quote

Kesta wrote:

  On 5/10/2017 at 6:23 PM, Tannin42 said:

 

  On 5/10/2017 at 5:50 PM, Kesta said:

"Rely on NMM-like vfs": So, one more question. Sorry to play the MO fanboy (especially since there is a lot more people who are much more fanatics than I am).

Let's say I'm a mod author, or tinkerer, who don't only edit already existing files, but need to add new ones to a mod's "folder".
If I do this with NMM's current way of handling things, this is extremely cumbersome, as I have to create the file while modding (with the "target mod" installed), then copy-paste said file back in the NMM mod's folder (which I have to guess since those are just IDs, but I already expect Vortex to be more convenient in that regard), then uninstall the mod through NMM and re-install it again so the software properly recognize that my new file belong to this mod and is properly linked with the one already in the game folder when it'll come to future updates, uninstallation, or profile change.

Are we going to see a convenient alternative to this awful behavior ?

 

Do you have a suggestion how this could work? It shouldn't be too hard to avoid the last step (uninstall/reinstall) with Vortex.
Say you create the file, copy it to the Vortex mod folder (which is still an ID because we have to ensure it's unique even when you install multiple versions of the same mod), Vortex can figure out that the files are the same and turn the one in the game directory into a link.

But Vortex will always need your help to determine which mod a new file belongs to, it can't guess that.

 

 

Thanks for the answer.

 

First thing before answering properly:

 

  Quote

(which is still an ID because we have to ensure it's unique even when you install multiple versions of the same mod)

 

 

It's ok for it to be an ID, as long as there is a decent way to find the mod's folder (typically, right click in the installed mod in the UI and select "Open Mod's Installation Folder"). Right now, with 2 or 3 thousands of "mods" installed, it is absolutely impossible to find which one is what with NMM.

 

 

 

 

As for "how it could work", my first post was a bit rushed, there is actually 3 scenarios with the current NMM implementation that I'd like to see improved. The first two were "natural" with MO. The last one is for an alternative to the lack of "overwrite".

 

1) A file is added directly to a mod's folder without going through the installation process.

We'd still want the file to be treated properly, i.e. put in the game's directory, and properly removed upon mod's deactivation.

Typical use case: Adding third-party ressources to a wip mod without having to open the game's directory (which can get ridiculously cluttered in some folders) / Pulling from your mod's git repo (happen at least once in a week for beyond skyrim devs, and it is probably the same for any other large-scale project teams).

Suggestion: An icon or other visual indicator in the UI that there is files in the mod's directory which aren't present in the game's directory, allowing to "refresh" with a single click (+validation?).

 

2) A file is deleted from mod's directory.

The expected result would be that the file is also deleted from the game's directory, but the technicalitiies regarding conflicts obviously make it impossible. I honestly don't have a suggestion for this one, when I need to do this I de-activate the mod in NMM beforehand, and I'm pretty sure I'll do the same with Vortex.

Typical use case: Trimming down a huge texture pack to keep just the part you're interested in.

 

3) The first example I gave in my original post, a file is created "for" a mod, but directly in the game's directory.

The mod author will then want to put it back in the proper mod's directory.

Typical use-case: Daily modding.

Suggestion 1: Have access to a panel that show all folder/files in the game directory which are not coming from installed mods. From this list, files/folders can be added to an existing mod (right-click -> add to... -> select mod, or drag & drop). Providing an additional config file in .gitignore style to filter what's seen in this panel would be awesome. And pretty much needed anyway to ignore the original game's files.

Suggestion 2: ("Hidden" option so regular users don't go f***** up there install) Set a mod as "current wip". At this point, a snapshot of the current game's directory is taken. From this point, every new file added to the game's directory is automatically considered to be in this mod's folder. (either "live", or even just when the "current wip" option is deactivated).

re 1) This wouldn't be a real problem in Vortex. The "deployment" steps works by determining the target state (which files should be mapped to the game directory based on the files and priorities of mods), comparing it to the actual state and then updating as necessary. Thus in the deployment-phase it would pick up on the new file, find it missing in the game directory and then link it.
The only thing is that Vortex wouldn't automatically notice that a file was added and thus "deployment" needs to happen because to discover _that_ it would have to do the comparison which is 90% of the work of the deploment. So you'd still have to click the button to manually run deployment.

re 2) Again, this would usually work in Vortex. I said in the QA that Vortex doesn't need a manifest and that is true. It does have one however, it just doesn't mind terribly if the manifest breaks or goes missing.
As long as the manifest is fine however, Vortex will notice that a deployed file no longer exists and will then offer you to remove it from the game directory as well next time deployment happens.

re 3) I like suggestion 1. It wouldn't be terribly hard to implement and since the user has full control it wouldn't break anything. With suggestion 2 I'm worried that you will get dynamic stuff like logs from skse or skse plugins, files added from a game update, ... all assigned to your wip mod and then turned into links. Best case this will spam your wip mod with unrelated stuff, worst case your game may break if you deactivate the wip mod because it got assigned important files. Edited May 11, 2017 by Tannin42

[Tannin42]

In response to post #49986482.

  Reveal hidden contents

  Quote

Dragon_Mech wrote: Is there a way ordinary users can help speed up the development of Vortex? Blood sacrifices to C'thulhu, volunteers for whipping Tannin when he tries sleeping, etc?


In all seriousness, thank you for your hard work Tannin! I can't wait to use Vortex.

Once first public releases are out you can help by providing well thought-out bug reports and improvement requests.
Of course Vortex will also be open-source so anyone with coding skills can contribute as well. And I believe people will find Vortex to be easier to contribute to than NMM and MO.

[Tannin42]

In response to post #49989557.

  Reveal hidden contents

  Quote

FinalFrog wrote: Will users be able to tell which mods had file conflicts and which mods won those conflicts by looking at their mod list?

For me this has always been the most significant advantage of MO over all other Mod Managers. The VFS was just a cherry on top and I have no problem with the compromise of symbolic/hard links so long as it doesn't hide mod conflicts from the users once a mod has been installed the way NMM did.

yes

[Tannin42]

In response to post #49990037.

  Reveal hidden contents

  Quote

strontian wrote: Hi Tannin,

Will we be able to edit the ini files for the game with this Mod Manger?

not yet but I'm sure something like this will be added at some point.

[Tannin42]

In response to post #49990432.

  Reveal hidden contents

  Quote

Pillock wrote: Will it support the older 32 bit games, or is it purely for 64 bit?

It will work with 32 bit games as well.

[Tannin42]

In response to post #49985947. #49987062, #49988082, #49990747 are all replies on the same post.

  Reveal hidden contents

  Quote

Dorryn wrote: Will Vortex be able to handle mod priorities like MO did, with drag-n-drop?

  Quote

RDubon wrote: Hope so otherwise their new mod manager would be no different than current nexus, i personally can live without mod organizer style virtualisation but mod priorities is a must in my book.

  Quote

Gruftlord wrote: From how i understood the explanation by Tannin on a technical level: yes.

  Quote

StukaXCII wrote: If it doesn't have that feature it's not worth installing, in my opinion. I'll just stick with Mod Organizer.

It will be able to handle mod priorities, it will work slightly different though.
Instead of ordering mods in the list you assign dependencies between two mods, i.e. "UDGP has to load after USKP" and Vortex will then figure out the correct order based on all these dependencies.
Similar to the loot lists work.

[Tannin42]

In response to post #49989632. #49992812 is also a reply to the same post.

  Reveal hidden contents

  Quote

alt3rn1ty wrote: Will legacy FOMod scripted mods be supported ?
And will you be including support for Wizards (Wrye Bash) scripting for mods without FOMod scripting, similar to how you did for MO ? (In the case of a mods zip including both FOMod and Wizard, I think FOMod scripting took priority)

  Quote

Magickingdom wrote: Thanks for the update. :)
I to would like to know about older mods. I have a huge collection of stuff I use that is no longer available anyplace but my WD Passport back up drive. I in fact decided against Skyrim SE for this reason(one of several), so it is important. I don't want to go back to manual install, but I can do that.

All fomods that were supported in NMM should work.
MO never supported BAIN wizards, only mods packaged in a certain way for BAIN options. Support for that is on the todo list but not yet implemented.

[Tannin42]

In response to post #49992922.

  Reveal hidden contents

  Quote

turulo wrote: Unless you can create an exact copy of the game and the mod manager as it was when the backup was made, the virtualization mode is inferior to a regular naked file copy system because you cannot store the game state when you need to remove the game from the system.

I know it's easier for you to develop a virtualized solution but it does not solve the problem.

You ignore most of what the QA says. Virtualisation doesn't just make our life easier. It makes the solution more robust for you and it allows us to implement more features (due to the gained flexibility and time)

With links, if you use a proper backup solution, the backup software will handle links correctly and restore them like they were before, without taking up more space. This problem exists only if your backup software is crap or if you're manually copying files instead of using a proper backup solution.

But even then, with vortex it's just a few extra steps
- purge in vortex
- create backup of game and mod management
- let vortex re-deploy (which will happen automatically)

When you restore the backup
- restore backup
- let vortex re-deploy (which will happen automatically)

This is a ridiculously cheap price for what you gain in return.

[Tannin42]

In response to post #49989912. #49994582 is also a reply to the same post.

  Reveal hidden contents

  Quote

Exchange324 wrote: Would like to see an option, when choosing between 2 textures, to visually compare them both, just 2 images opened at once, it won't be too hard to implement, but will help a lot believe me. Thx

  Quote

BryanMichaelD3 wrote: I second this. That would be super helpful!

MO had this option and I have it on the todo list for Vortex. But it's not as trivial as it may sound because support for reading/displaying dds textures isn't as widespread as - say - jpg.
I can't guarantee we will find an appropriate library with support for it. I haven't looked into that yet though.
Plus supporting textures that are packed in bsas for example would of course require the extra step of extracting them...

[Tannin42]

In response to post #49996382.

  Reveal hidden contents

  Quote

ozoak wrote:

  On 5/11/2017 at 12:47 AM, stormymiller said:

If Vortex will have virtualization "more like NMM" and a UI "more like NMM", why not call it by its real name--NMM 0.7?

 

 

  On 5/11/2017 at 12:57 AM, Vahras said:

Unfortunately, so long as Vortex lacks the same virtualization system as the original Mod Organizer, I'll be yet another person who doesn't plan to use it.

 

I have to agree. I'm pleased we've had an update, and I know Tannin you've said that proper VFS isn't permanently off the table, but the two greatest strengths of MO were the VFS and the (I'm going to say it) simple drag and drop reordering and priority organisation. The later is merely (I mean no disrespect) an orderly UI and process, whilst the first, the VFS, is a technological superior solution. I understand that it may have been a solution looking for a problem, as you say, but without it...this feels a bit disappointing.

 

Anyway, sorry for the criticism but if we all just shut-up about it you might not get a real appreciation for how much *we* appreciate the vfs :)

What it provided was brilliant, really, and if whitelisting Vortex in any antivirus is really a factor in the decision to not pursue it, then I think we're not giving enough credit to users; so many things require whitelisting these days, it's not really a 'tech-head' thing any more. I'm sure there's more to it than that one factor, but it really would be the one thing I would keep from MO if I had to get rid of everything else.

 

That said, how will Vortex handle running a multi-user shared environment, ie: one PC, multiple Windows users using same game (not simultaneously, of course)?

Well, everything is trade-off and we've been considering the options we have and I'm very confident that we have the best trade-off for the majority of users.
I know many are sceptical because they had bad experiences with NMM 0.6 but I would really suggest you try Vortex once it's out with an open mind.
The attitude "I didn't like NMM 0.6 so I'm not touching anything that works similar" is just not very productive.

And the AV thing was a serious problem with MO, even there there were enough users who didn't understand the error was a false positive and were worried MO contained a virus.
Plus there is AV software around that will simply delete files from the MO package during install without even telling the user about it or why.