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

[ZjemTwojegoKota]

Please consider support for HDPI like 4K monitors.

[DAOWAce]

Don't like virtualization, never will.

 

I don't use "profiles", I don't have multiple characters playing through a game at once that I need to hotswap mods for.. I don't do any of that stuff. Maybe some people do, but I'd assume they're a minority.

 

I have all my mods on a large, slow RAID array. They can't be virtualized from it because it would heavily impact game performance. Sure, maybe I can set the virtualization folder to be in the same place the game is installed.. but that's just defeating the entire point.

 

There's nothing wrong with having the actual files in the actual directories; anything other than that can, and has, caused problems.

 

Options options options.. Giving users options is the best thing you can do in software development.. and unfortunately seems to be one of the hardest things to do for the majority of developers.

[DeathAfterDeath]

I wasn't sure where to post this, but I made a quick mockup of a possible idea for a logo. I was more practising rather than trying to make something proper, but I thought I would show it to someone:

http://imgur.com/a/8ac81

[Sigel77]

In response to post #49982777.

Tannin42 wrote:

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

If I may offer suggestions for how to simplify finding a specific mod's folder:

1) "unique ID"+"Shown name" as Vortex mod folder name (You still have to guess which is what if you have multiple versions of the same mod but it's much easier with 2-3 folders than with 100+)

2) "Open the mod's folder" option directly from the UI (most likely through right click menu) Edited May 29, 2017 by Sigel77

[Sigel77]

In response to post #50467712.

DAOWAce wrote: Don't like virtualization, never will.

I don't use "profiles", I don't have multiple characters playing through a game at once that I need to hotswap mods for.. I don't do any of that stuff. Maybe some people do, but I'd assume they're a minority.

I have all my mods on a large, slow RAID array. They can't be virtualized from it because it would heavily impact game performance. Sure, maybe I can set the virtualization folder to be in the same place the game is installed.. but that's just defeating the entire point.

There's nothing wrong with having the actual files in the actual directories; anything other than that can, and has, caused problems.

Options options options.. Giving users options is the best thing you can do in software development.. and unfortunately seems to be one of the hardest things to do for the majority of developers.

Either I don't understand your setup at all, or you don't get the point of virtualization.

If you store the mods' archives on your RAID array then virtualization of the install folder won't change a thing.

If you store the install folder on your slow RAID then you're doing virtualization in a very inefficient way.


The way you're supposed to do is:

1) If you store the mods' archives, do it in a large slow storage (it's optional with the way MO and Vortex work as you can erase those archives after install)

2) Have the install folder on a fast disk (possibly the same as the game) but different folder.

The goal is not to store the files on different disks (tho it's possible to do so) It's to store them in a different folder (usually on the same disk), and then form links from that folder to the game.
That way you can manipulate the structure of the install folder independently from the game folder and just reform links.

What's wrong with having the actual files in the game's folder is that it's a second folder structure the software has to be maintained on.

[Olivir2019]

In response to post #50467712. #50518937 is also a reply to the same post.

DAOWAce wrote: Don't like virtualization, never will.

I don't use "profiles", I don't have multiple characters playing through a game at once that I need to hotswap mods for.. I don't do any of that stuff. Maybe some people do, but I'd assume they're a minority.

I have all my mods on a large, slow RAID array. They can't be virtualized from it because it would heavily impact game performance. Sure, maybe I can set the virtualization folder to be in the same place the game is installed.. but that's just defeating the entire point.

There's nothing wrong with having the actual files in the actual directories; anything other than that can, and has, caused problems.

Options options options.. Giving users options is the best thing you can do in software development.. and unfortunately seems to be one of the hardest things to do for the majority of developers.

Sigel77 wrote: Either I don't understand your setup at all, or you don't get the point of virtualization.

If you store the mods' archives on your RAID array then virtualization of the install folder won't change a thing.

If you store the install folder on your slow RAID then you're doing virtualization in a very inefficient way.


The way you're supposed to do is:

1) If you store the mods' archives, do it in a large slow storage (it's optional with the way MO and Vortex work as you can erase those archives after install)

2) Have the install folder on a fast disk (possibly the same as the game) but different folder.

The goal is not to store the files on different disks (tho it's possible to do so) It's to store them in a different folder (usually on the same disk), and then form links from that folder to the game.
That way you can manipulate the structure of the install folder independently from the game folder and just reform links.

What's wrong with having the actual files in the game's folder is that it's a second folder structure the software has to be maintained on.

What I think DAOWAce means is, that the downloaded mods (archives) are on the RAID and when installing them, they are installed right into Data game folder on another (not RAIDed...ehm) disk. So virtualization from RAID would really hurt the performance.

However, I would say that setting up the virtualization folder (which contains just the installed mods, not all the downloads) to the same disk as the game, but outside the game folder, would do the job - so now I am stumped:-(

[rmm200]

I have never used Mod Organizer to download a mod from Nexus.

Like most Mod Organizer users, I select the "Manual" option and put it where I want it.

If you are using download method to count Mod Organizer users - you should add the manual downloads to them. Pretty much all NMM users will download through NMM.

[Olivir2019]

In response to post #50552232.

rmm200 wrote: I have never used Mod Organizer to download a mod from Nexus.
Like most Mod Organizer users, I select the "Manual" option and put it where I want it.
If you are using download method to count Mod Organizer users - you should add the manual downloads to them. Pretty much all NMM users will download through NMM.

Don't you also have to login into Nexus in MO, so that you can check new versions for the mod? I would think, Nexus counts logins, not downloads... Edited May 31, 2017 by J.O.D.

[ozoak]

 

In response to post #50552232.

 

 

 

rmm200 wrote: I have never used Mod Organizer to download a mod from Nexus.

Like most Mod Organizer users, I select the "Manual" option and put it where I want it.

If you are using download method to count Mod Organizer users - you should add the manual downloads to them. Pretty much all NMM users will download through NMM.

Don't you also have to login into Nexus in MO, so that you can check new versions for the mod? I would think, Nexus counts logins, not downloads...

 

 

I'm not certain MO does require a login to Nexus to check versions. You can check versions (and download files <2mb) without logging in.

[justinmaupin]

In response to post #49977347. #49977612, #49977627, #49977747, #49977772, #49978322, #49978412, #49978502, #49978607, #49978752, #49978832, #49978967, #49979042, #49980232, #49980267, #50066187, #50066557, #50067157, #50083477 are all replies on the same post.

Dark0ne wrote: It's been awhile since we mentioned our work on the new mod manager. For a quick recap of "recent" events, back in August 2016 we brought on Tannin (of Mod Organizer fame) to head up work on a completely new mod manager for Nexus Mods. He's been working on it along with the two original NMM programmers ever since.

Tannin's remit is simple on the surface, we want a mod manager for Nexus Mods that can handle modding for as many games as possible and that can be both simple for newcomers to use while containing (or supporting) all the advanced functionality users have come to expect from mod managers for games like Skyrim and Fallout. Simple on the surface, not so simple when you get down to it!

Tannin has been given a very wide berth to decide the how and the when of things. My thinking is that Tannin was able to make a great piece of software in his spare time while also working a full-time job, so I really don't need to tell him how to do things -- he knows how to do things. And I'm certainly nowhere near as qualified to make the choices he's making for the good of the mod manager. So, Tannin is most definitely the project lead and I just comment on (and argue with Tannin about) UI related things. Something I'm sure he can attest to!

Since details about the new mod manager are thin at the moment (we're simply being tight-lipped as we're not ready to talk about too much yet -- we'd rather work on it than be constantly answering questions or doing PR!), I thought we could do a little Q&A about the things we can now talk about as we head towards a closed alpha of the software.

What I can tell you now is that we have agreed (this week!) on a name for the new mod manager. It's taken us a long time to come up with one mainly because I was looking for some particular criteria in the name. I wanted a single word name that was interesting, marginally relevant and "brandable". While this might sound odd, I also didn't want a name that was specific to mods. Who knows what this software will become in 2, 5 or even 10 years time. For example, I'd like at some point to provide a cloud save game storage service to members of Nexus Mods so they can easily backup and restore their saved games. At such a point, we've gone past a mod manager and the name is no longer relevant. I'd rather just have a more generic software name now, than have to "rebrand" in the future.

I vetoed things like Nexus Client (though it was a fallback!), Nexus Mod Manager 2 and Nexus Mod Organizer because they're either boring, cumbersome or both. Instead, we took up a suggestion from the last news post we made about NMM from users in our community. I asked around a little and most people polled liked it, so...done!

I can confirm that the new mod manager at Nexus Mods will be called Vortex.

We'll begin working on a logo soon.

With that out the way, I've already done the introduction to Tannin, so without further ado let's get on with the questions and answers…

Robin: So first things first, Tannin, what would you say are the key differences between your goals and your ethos working on Mod Organizer compared to your goals and your ethos working on Vortex?

Tannin: When I started Mod Organizer, the virtual file system software that made it special was already mostly done. I had created the vfs for a separate purpose and when I played around with mods for Oblivion it occurred to me that this tech could be applied to that problem.

I never really expected a lot of success and for the first year or so I didn’t have any. I was always in it for the technical challenge and my attitude was, "This is what I have, if others like it I'm happy, otherwise they have alternatives". It was never my goal to create the best possible mod manager for everyone, I was happy in a niche.

Now with Vortex that has changed of course. We're making the official mod manager for Nexus Mods and it has to be accessible and trouble-free for everyone.


Robin: I think we both know the biggest questions we've received around Vortex have been in regards to virtualisation and how Vortex will handle and store files on people's hard-drives. Is Vortex going to use virtualisation?

Tannin: Yes it does.

I know people have - often very strong - opinions on the topic so I ask that you please read my reasons before you go to the comments and vent.

In the initial release of Vortex, virtualisation will be implemented using links (symbolic or hard links), similar to NMM v0.6. We've left the door open so we can implement different approaches (i.e. the usvfs library from Mod Organizer) but at this point I don't think there will be a "no virtualisation" option.


Robin: Can you explain why Vortex is going to be using virtualisation and why it's preferred to using the old method of simply extracting mod files into the game directory?

Tannin: I'll try to be brief!

Managing mods without virtualisation is slower, takes more space on your hard-drive and has a lot of hidden complexity that makes it more error prone as well as more work to implement (this translates to "fewer features per time" for those of you who don't care about a programmer's pains) and harder to understand.

It's best to work with an example to demonstrate. Imagine:
You install mod X that contains "spider.dds" and "bear.dds" And you install mod Y that contains "spider.dds" and "dragon.dds"

You expect "spider.dds", "bear.dds" and "dragon.dds" to be in your game directory and "spider.dds" can be either the one from mod X or the one from mod Y, depending on the order of and choices made during installation. Let's assume it's from mod Y.

You then decide you don't like it and remove mod Y.

You now expect "spider.dds" and "bear.dds" to be in your game directory and "spider.dds" should now be the one from mod X.

To make this happen, a mod manager that doesn't use virtualisation needs to keep a manifest of where files come from and which files have been overwritten so that it can know there is another "spider.dds" in mod X and how to restore it.

Once this mod manager knows "spider.dds" exists in mod X it has to open the archive from which you originally installed it and extract the file again. This manifest is hidden in some database or xml file, probably invisible or unreadable to you. Most users will not know what information it contains or how it's used. You may not be aware you need to back it up together with the game directory, but the content of the manifest needs to be in sync with the actual installed mods.

This is a hidden complexity to the mod manager that you may not care about until it breaks.

If you restore a backup that contains an older manifest but not the mods or the other way around, your mod manager will no longer be able to correctly disable/remove/change the order of mods. And this is unrecoverable.

The same is true if you manually install a mod or remove a file from the game directory that the manager was tracking in its manifest. If you do this you're invalidating the manifest and forcing the manager to guess what has happened. It may guess correctly 9 out of 10 times, the other time you will get an error.

The manifest also needs to be migrated. Every time we change the manifest format we need to develop a migration path from the old format to the new format. If that migration code has a bug or can't deal with an already broken manifest it's potentially breaking the mod installation for thousands of users. Errors in the manifest can remain lingering until some day the manifest migration fails.

It also means you have to keep the archives for all installed mods around and if you delete one file for that mod, it can't be restored.

Similarly, extracting from an archive can be very slow, especially if it was heavily compressed to save space and bandwidth.

Finally, if you have modified "spider.dds" from mod X prior to installed mod Y those modifications are going to be lost. Whoops!

On the other hand, mod managers that use virtualisation, like Vortex, don't have to track individual files. They just need to know what mods you have (which is obvious since they are a bunch of directories on your disk) and how to prioritise them.

The "deployment" of files to the game directory is then simple, using the list of enabled mods and their priority at that point in time to reliably determine which files should be there. There is no need to know what happened in the past. When installing mod X and mod Y, it deploys the files from both mods to the game directory, the "spider.dds" from Y overloads that of X. Everything is as expected.

When mod Y is removed, it also removes all the files that mod Y deployed to the game directory (which it can detect without the need of a manifest because the links themselves tell us where each file came from) and then deploys a new. This time mod X gets to deploy "spider.dds".

Everything is as expected - without a manifest, without extracting files and as an added bonus, if the file was modified in mod X, those changes are still going to be there.

Therefore (and TL; DR) virtualisation is actually simpler, quicker and also saves space as you don't need the mod archives after installation (you can keep them if you want but it's optional).


Robin: That wasn't very brief. Why not make virtualisation an option that users can pick from?

Tannin: We may, at some point. However, to be honest, virtualisation is objectively superior and to implement a "no virtualisation" installation method is a lot of work both to develop and to maintain (for the reasons mentioned above). Without good reasons, it's just not a good use of our time when there are so many other useful features we could be doing right now.


Robin: You've already said that the virtualisation system Vortex uses will be more like the one NMM uses than the one Mod Organizer uses. You and I both know there are a lot of MO users who swear by their clean install folders and are likely to be upset by this. Can you explain your reasoning behind choosing the NMM way over the MO way?

Tannin: Well first of all, providing the "MO" vfs as an option at a later time is not off the table for Vortex. But there are a few reasons why having the MO vfs as the default option for Vortex wouldn't be a good idea.

Firstly, the way the vfs is implemented is more error prone. In particular, it's more likely to encounter incompatibilities with different applications. This was acceptable (to me) with MO where only a handful of games were supported with a few tools for each, but even then we had frequent problems with tools not running/producing odd errors that could take weeks to fix.

With Vortex, we want to support as many games as possible and fixing the vfs for each game and each tool for dozens of games would be a maintenance nightmare.

Secondly, the heuristics of virus scanners frequently (and incorrectly) tagged MO as a virus because the technology used to implement the vfs is similar to what some malware does. Again, this was ok when it affected a few percent of a few thousand MO users who tended to be more tech-savvy than the average user. However, Vortex aims to be accessible to all users and we really don't want bug reports about AV errors from 5% of 6 Million users…

Thirdly, I'd like to point out that when I initially started developing MO, the vfs technology (the 32-bit variant) was already mostly done as I had created it as part of my diploma thesis and merely rewrote that. So, really, I had a solution and was looking for a problem to solve with it.

MO was my experiment to see if this technology could be used for that problem. My goal with MO initially was not to write the most user-friendly Mod Manager I could. If I'd had the time I would have added a link-based option to MO2 as well...

While a clean game folder solution isn't possible right now with Vortex, there will be a "purge" feature which will remove all links installed by Vortex reliably and quickly so you shouldn't ever be more than a button-click away from a clean game directory.


Robin: Is there a performance cost to using virtualisation?

Tannin: For hard-links: no, none, zero.

For symbolic links: practically none. I doubt you could measure it and I can guarantee you won't be able to notice it.


Robin: Some users have reported and complained about their custom mod backups being twice the size they should be due to virtualisation. What's the solution to this?

Tannin: Get better backup software. Seriously, there is no excuse for a backup solution to not handle links properly.

But as an alternative, let me again refer to the "purge"-option that un-deploys all mods. You can do that before creating the backup, then just have Vortex re-deploy afterwards. This is a safe operation and will probably take less than a minute.


Robin: Moving forward, what are your release plans for Vortex? Will there be an alpha? What time scales are we talking here?

Tannin: Giving concrete dates is always difficult because one almost always underestimates the amount of work required to polish stuff towards the end.

My current plan is to have an early alpha build in the hands of a limited group of test users within a month, maybe 6 weeks.

Depending on their feedback we should expect somewhere between 1-3 months to fix bugs after which I think we can release a public alpha.

Madcat221 wrote: Will it force virtualization on us even if we don't want it? I'm still on NMM 0.56 because of that.

RoyBatterian wrote: Tannin will you not be implementing the BSA management feature? I've always had issues with it in any game other than Skyrim. In New Vegas I could never get MO to work correctly due to the install order problems. If files pre-existed or were installed into the base game directory then they could never be controlled and that is massively frustrating and time consuming, if not impossible to solve. The hard coded bsa loading of Update.bsa also proves to be an issue with New Vegas.

Tannin42 wrote: @RoyBatterian: No, the BSA management like MO1 did, overriding the bsa load order will not be included. I had actually removed that in MO2 too because it was a mistake I regretted a lot. With Vortex I try to be less "invasive" than MO was.

Loveblanket wrote: Sounds good. Will this install over the existing NMM, or will this be a completely separate piece of software that will require re-downloading all of our mod libraries?

Mitth90 wrote: What kind of transition is to be expected from Nexus Mod Manager to Vortex? I.e., profile settings, mods installed, et cetera...

Natterforme wrote: I very much look forward to testing and using the fruits of your labors tannin. These games will have even more longevity due to your efforts. :)

-Natterforme

Martimius wrote: +1 But my guess would be that since this is a separate piece of software, then mod libraries would have to be remade from the ground-up. I would like to see a migration feature though.

Tannin42 wrote: Vortex will be a separate piece of software so you can install it alongside NMM. The only part where they will squabble is who gets to handle the downloads from nexus, you can change that in the settings of each application.

We're currently working on a way to import mods&downloads from NMM (0.6) so you don't have to redownload what you already have. This will be a manual process and it won't change the NMM installation in any way so you are able to try out Vortex without risking your working NMM install.
Settings are too different, I don't think it would make sense to try and import those.
Profiles are also conceptually different so I doubt an import would work.

I hope to provide the same for importing from MO before we release publicly but no promises there.

SirSalami wrote: Regarding concerns about transitioning from NMM to Vortex, DuskDweller wanted me to let everyone know that he is working to ensure that the migration process will be automated and accomplished from within Vortex in some fashion.

Woodclaw wrote: Speaking of "invasive" since Vortex will be -- initially -- using a techonlogy closer to NMM, rather than MO, would it be possible to change the load as in MO?

Tannin42 wrote: You can change the load order.

Woodclaw wrote: Thanks.

Vyxenne wrote: Like MadCat221, I too am still on NMM 0.56 because the "conversion" process of 0.6x bricked my Oldrim game. I use 0.63 (latest) for SSE and FO4 because there was no conversion to be done (for me) on either of those games- I was able to use 0.6x from the very first mod.

However, like many people, I still play Oldrim, warts and all, mostly due to the lack of SKSE in SSE (still! *sob*), which prevents all the tasty mods that SKSE enables. I wish there was some way to 'get off' of 0.56 in my Skyrim, but once bitten, twice shy- I won't try again because if it fails (again) it's unrecoverable and with 302 mods and 231 plugins, unrecoverable is not good news for me. :wallbash:

What I'm trying to say is that the success of Vortex will be adversely affected by people like me not being able (or willing) to use it unless there is a stone-reliable conversion process to Vortex, both from the 0.56-style 'copy mods to folders' system and the 0.6x-style 'stinky-linky' process.

Yisregaurd wrote: Is it layered out more like NMM or MO?

Personally I dislike the NMM UI alot because of how it differentiates unistalled and installed mods and the white background and really like how MO solves categories and have everything in one tab rather then constantly switching between load order and mods.
My point exactly is MO is more 'Organized' and clean

Doc4943 wrote: Removed because I've offended a precious snowflake

TechAngel85 wrote: What is being forced? Either use it or don't. That's your choice. If you like NMM and don't like Vortex once it's released, then there is nothing saying you can't still use NMM. Tannin even mentioned above they could be used together.

If you don't like virtualization, I would say that WB is better than NMM. No offense to the Nexus staff, but NMM has never been a great manager for managing a heavily modded setup. There's several reasons why STEP was never able to use it to easily manage the Guide. WB worked, though. MO worked even better. I'm personally excited to get my hands on Vortex to test its' abilities.

I refrain from passing judgement until I've actually used the software, because I have nothing to pass judgement on except words...which, when you get down to it, don't really tell us much toward usability. It's just assumption/hype/PR until the software is in hand and users get a chance to break it...*err*...I mean use it. ^_^

Ethreon wrote: "working for the people on here"
He's working for Dark.

"if they want by majority"

3-4 people voicing against is not a majority. It's also absurd to expect a software to be rewritten just cause a few cannot cope with features integrated in the code, specially when you pay nothing or contribute nothing to this software's making.

Doc4943 wrote: Removed because I can't be bothered to explain to Etheron

sim4