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

[TerminusVitae]

In response to post #50032012. #50032057, #50032732, #50052427, #50054092 are all replies on the same post.

othmanarnaout wrote: I don't know if this has been asked before, but here goes,..

Does this mean that a Vortex-made modded, say, Skyrim can run without launching it through vortex. What I mean to say is, will one be able to share one's custom Skyrim with a friend, by giving said friend a copy of one's Skyrim folder, and that friend would be able to run it by starting skse without the need for them to install or use vortex?

please forgive one for one's language.

othmanarnaout wrote: please note that I am not referring to piracy, but the act of sharing a modded Skyrim with a newb friend :P

Roccondil wrote: you specifically sharing just your (mod) data folders? probably not- if I understand this correctly, what's placed in your Skyrim directories are not the actual mod files, which are stored elsewhere. You'd have to share both your Data folders and your mod folders, and hope that the paths to the mod folders are identical on both machines.

othmanarnaout wrote: let me clarify,.. Im a hardcore MO user, as such, I know that sharing setups with a friend is a huge pain in the rear, because of the vfs and how it handles mods. Now don't get me wrong, I love MO more than anything, but i wish there were a way to easily "compile" a working setup that would run on another computer by simply running skse.As an upside to this, your skyrim folder would be very clean, relatively. NMM on the other hand, puts your installed mods into the skyrim folder and things get messy, yes, but in theory you should be able to run a copy of your nmm-modded skyrim on another pc by simply running skse(though i haven't really tested that). Point is, since Vortex will have a virtualization system similar to that of nmm, does that mean that the data folder in the actaul game folder will also contain the installed mods, making it copy-able and run-able on another pc without the need for vortex on said system? (since there is no vfs involved).

TechAngel85 wrote: "Profile sharing" has been planned for some time with Nexus. I'm not sure if it'll be implemented with Vortex, but that would be logical. The way I understood it is users would be able to save their setups and upload it to Nexus. Then users could download the setup and the manager would do most of the work of setting it up for the user. This is suppose to give an identical setup as the author. For example, if you wanted you have the exact same setup as Gopher, all you would have to do is download his shared setup.

If this was ever worked out completely, I'm not sure. I haven't heard anything on it in a long time. To be honest, this sounded like a dream because I can't see how they would be able to work out all the small details that come with modding (FOMOD installers, hidden/deleted assets, load orders, patches, etc, etc). I could see it being possible on more simple setups, but not on advanced ones.

@TechAngel85 oh my everloving frak... Skyrim Modpacks?!? hell to the yes, my god... modded Minecraft better step up their game, if that ever comes true. :) Edited May 13, 2017 by TerminusVitae

[TechAngel85]

In response to post #50032012. #50032057, #50032732, #50052427, #50054092, #50054512 are all replies on the same post.

othmanarnaout wrote: I don't know if this has been asked before, but here goes,..

Does this mean that a Vortex-made modded, say, Skyrim can run without launching it through vortex. What I mean to say is, will one be able to share one's custom Skyrim with a friend, by giving said friend a copy of one's Skyrim folder, and that friend would be able to run it by starting skse without the need for them to install or use vortex?

please forgive one for one's language.

othmanarnaout wrote: please note that I am not referring to piracy, but the act of sharing a modded Skyrim with a newb friend :P

Roccondil wrote: you specifically sharing just your (mod) data folders? probably not- if I understand this correctly, what's placed in your Skyrim directories are not the actual mod files, which are stored elsewhere. You'd have to share both your Data folders and your mod folders, and hope that the paths to the mod folders are identical on both machines.

othmanarnaout wrote: let me clarify,.. Im a hardcore MO user, as such, I know that sharing setups with a friend is a huge pain in the rear, because of the vfs and how it handles mods. Now don't get me wrong, I love MO more than anything, but i wish there were a way to easily "compile" a working setup that would run on another computer by simply running skse.As an upside to this, your skyrim folder would be very clean, relatively. NMM on the other hand, puts your installed mods into the skyrim folder and things get messy, yes, but in theory you should be able to run a copy of your nmm-modded skyrim on another pc by simply running skse(though i haven't really tested that). Point is, since Vortex will have a virtualization system similar to that of nmm, does that mean that the data folder in the actaul game folder will also contain the installed mods, making it copy-able and run-able on another pc without the need for vortex on said system? (since there is no vfs involved).

TechAngel85 wrote: "Profile sharing" has been planned for some time with Nexus. I'm not sure if it'll be implemented with Vortex, but that would be logical. The way I understood it is users would be able to save their setups and upload it to Nexus. Then users could download the setup and the manager would do most of the work of setting it up for the user. This is suppose to give an identical setup as the author. For example, if you wanted you have the exact same setup as Gopher, all you would have to do is download his shared setup.

If this was ever worked out completely, I'm not sure. I haven't heard anything on it in a long time. To be honest, this sounded like a dream because I can't see how they would be able to work out all the small details that come with modding (FOMOD installers, hidden/deleted assets, load orders, patches, etc, etc). I could see it being possible on more simple setups, but not on advanced ones.

TerminusVitae wrote: @TechAngel85 oh my everloving frak... Skyrim Modpacks?!? hell to the yes, my god... modded Minecraft better step up their game, if that ever comes true. :)

Here's the news article discussing it: http://www.nexusmods.com/skyrim/news/12569/?

As I mentioned, it just sort of died, so I don't know if they ever figured it out. Edited May 13, 2017 by TechAngel85

[Tannin42]

In response to post #50017357. #50023137, #50023837, #50026827, #50032642 are all replies on the same post.

sopmac45 wrote: Hi Tannin42 ... I started to play Skyrim SE like 4 months ago so I've never used MO and I am just familiar with NMM, however, I am practically a rookie to mods ( but I am not a teenager though .. lol .. ) and my question are :
1 - Will Vortex clean up files as SSEDIT does ?
2 - Will I have to use LOOT or Vortex will do the sorting ?
3 - Assuming that I want to restart the whole game again, will Vortex allow me to just deactivate/delete all the mods and most important, must I delete all Skyrim data/files and reinstall it again as I am doing now ?
If I do not make any sense, just please bear with me because I am new to mods as I said but it is a pain in the butt to go nuke and restart the whole thing again .. will be there a more practical/fast solution to this ?
Regarding the name, I did not vote for Vortex but I am ok with that name. It will be impossible to please the world. Simplicity and reliability of this new program is what it count IMHO.
Thanks so much.

Pabulum wrote: I'm not Tannin but at least there's a response.

1 - Will Vortex clean up files as SSEDIT does ?
2 - Will I have to use LOOT or Vortex will do the sorting ?

I hope not! xEdit doesn't belong within a mod manager. Same with LOOT. It makes stuff harder to keep updated.

3 - Assuming that I want to restart the whole game again, will Vortex allow me to just deactivate/delete all the mods and most important, must I delete all Skyrim data/files and reinstall it again as I am doing now ?

That won't be until the VFS-related crap is released.

TerminusVitae wrote: @Pabulum not Tannin either, but I'd dispute your last assertion; the "purge" feature that the Q&A describes would *effectively* uninstall all mods without un/re-installing the whole game, much like trying to run a game outside of Mod Organizer.

For those who don't know, when running a game with MO, the VFS makes it seem to the game as if the files are there when they aren't, (Virtual File System; think of it like a Virtual Reality headset that MO puts on the game's head, so the game can see and interact with files that aren't technically there.) But when not running the game through MO, the folders are clean of all those files, and the game is essentially entirely unmodded. No mod files visible, thus no mods installed.

Ostensibly, the purge feature would allow instant access to the exact same thing even in a symbolic link set-up, instantly and easily removing the file system links that made the files visible and the game modded at all. (For symbolic links, imagine that instead of making the game wear a headset, you just tie a bunch of strings to it's fingers, and tie the other end to stuff that's not usually in reach. The purge button feature would cut all the strings, until you pressed a different button to re-tie them.) You'd theoretically almost never have to "empty out the whole game folder and reinstall" again, as any files that are mod related could be automatically and precisely removed without ever touching or otherwise damaging the original game files (or, for that matter, the mod files at the other end of the strings), as opposed to the usual "wiping everything to make sure nothing got missed".

Additionally, the intent from day one to support a wide range of games means that unlike NMM or even MO, the manager would theoretically be able to handle a wider range of folders within the game's files than usual, as it'd have to... not all games are as cleanly organized as Bethesda's "stuff it all in .\ Data" mentality. :P This would still help Beth games though, because by being able to handle (for example) the main Skyrim folder (as opposed to only the Skyrim\ Data folder) even stuff like ENB presets and SKSE loaders can be handled (and for ENBs, even easily switched between) by the manager and thus purged by it if needed, even if only needed temporarily.

Tannin42 wrote: 1) No, we don't integrate xedit and for now we have no plan to do so. Vortex will be extensible through extensions so if someone with development experince comes along they could add such a feature
2) Vortex integrates loot and userlist management from inside the gui so you don't have to run loot manually. This can of course be disabled for users who don't like convenience. ;)
3) Sure. You could either simply create a new, empty, profile and switch to that or use the purge option.
Both should lead to a clean data directory (at least clean of the files Vortex added, of course we don't remove anything added through other means like steam workshop).

TechAngel85 wrote: 2) Will this solution be similar to that of MO's sort feature? The reason I ask is because you couldn't create any sort of meta rules with the sort feature alone, thus you were still required to have LOOT for any medium to heavily modded game unless you locked the plugins into place which wasn't the best solution for ease of management.

Vortex allows you to edit the loot userlist directly from the ui, this way you can customise the sorting.
Also, the sorting happens in the background so the UI doesn't lock while sorting happens. Apart from that it's similar to MO.

[Tannin42]

In response to post #50047712.

qwertyzeldar wrote:

not a fan of Vortex as a name but meh, i understand the reasoning behind the name.

 

on that though, i has a question!

 

 

so will the manager have add-on capabilities? like how i can use a button to launch Bodyslide in NMM.

Yes, you can add buttons for additional tools

[Tannin42]

In response to post #50031637. #50032802, #50039597, #50040132, #50040682, #50041942 are all replies on the same post.

axonis wrote: Does Vortex adhere to the FOMM XML schema for mods that use it ? Or does it allow invalid installer declarations to run on it when they would break FOMM ?

TechAngel85 wrote: I'd be interested to know this as well. MO's handling of FOMODs was far superior to NMM, imo. Having written dozens of FOMODs it was always NMM that was the pain in my backside. Not to mention that MO used the code more fully and accurately than NMM due to the work of ThosRTanner.

axonis wrote: Really ? I'm using NMM Legacy and as far as scriptless installer declarations go, it seems to perfectly match FOMM.

TechAngel85 wrote: MO has some heuristics involved so if you left something out or forgot to close a tag it didn't really care. This wasn't proper, but it was nice for those creating my hand. Also NMM behaves differently with some of the options vs MO. I know in the last version of MO, flags were somewhat broken though and that never got fixed. ThosRTanner put in quite a bit of time working on improving MO's handling of FOMODs, as far as I am aware.

axonis wrote:

MO has some heuristics involved so if you left something out or forgot to close a tag it didn't really care.

This is a very bad thing to do. This invalid code is now spreading on the Nexus as some authors claim that it's actually the right thing to do since others are doing it.

Of course that means FOMM users will now have to "upgrade" only because their mod manager refuses to run pizza-and-beer declarations. And the typical advice provided by authors of such mods would be to use "a modern mod manager".

I hope Vortex won't do this.

TechAngel85 wrote: I know it's not proper coding and is why I mentioned it not being such. I was simply stating it nice that MO was able to bypass it if you missed a ">" in the 2000 lines of code somewhere. ^_^ I always validate my code when I remember to do so. Ganda wrote a nice program for this that is convenient ( http://www.nexusmods.com/skyrim/mods/75140/? ).

Vortex should follow the schema for the installer to the letter.
Current schema: http://qconsulting.ca/gemm/ModConfig5.0.xsd (open with a text editor like Notepad++)

Vortex uses more or less the same code for reading scripted&xml installers as NMM. This is the only part of NMM we re-use. The assumption was that all mods on nexusmods were probably tested against NMM so we'd get the best compatibility this way.

[axonis]

In response to post #50031637. #50032802, #50039597, #50040132, #50040682, #50041942, #50058997 are all replies on the same post.

axonis wrote: Does Vortex adhere to the FOMM XML schema for mods that use it ? Or does it allow invalid installer declarations to run on it when they would break FOMM ?

TechAngel85 wrote: I'd be interested to know this as well. MO's handling of FOMODs was far superior to NMM, imo. Having written dozens of FOMODs it was always NMM that was the pain in my backside. Not to mention that MO used the code more fully and accurately than NMM due to the work of ThosRTanner.

axonis wrote: Really ? I'm using NMM Legacy and as far as scriptless installer declarations go, it seems to perfectly match FOMM.

TechAngel85 wrote: MO has some heuristics involved so if you left something out or forgot to close a tag it didn't really care. This wasn't proper, but it was nice for those creating my hand. Also NMM behaves differently with some of the options vs MO. I know in the last version of MO, flags were somewhat broken though and that never got fixed. ThosRTanner put in quite a bit of time working on improving MO's handling of FOMODs, as far as I am aware.

axonis wrote:

MO has some heuristics involved so if you left something out or forgot to close a tag it didn't really care.

This is a very bad thing to do. This invalid code is now spreading on the Nexus as some authors claim that it's actually the right thing to do since others are doing it.

Of course that means FOMM users will now have to "upgrade" only because their mod manager refuses to run pizza-and-beer declarations. And the typical advice provided by authors of such mods would be to use "a modern mod manager".

I hope Vortex won't do this.

TechAngel85 wrote: I know it's not proper coding and is why I mentioned it not being such. I was simply stating it nice that MO was able to bypass it if you missed a ">" in the 2000 lines of code somewhere. ^_^ I always validate my code when I remember to do so. Ganda wrote a nice program for this that is convenient ( http://www.nexusmods.com/skyrim/mods/75140/? ).

Vortex should follow the schema for the installer to the letter.
Current schema: http://qconsulting.ca/gemm/ModConfig5.0.xsd (open with a text editor like Notepad++)

Tannin42 wrote: Vortex uses more or less the same code for reading scripted&xml installers as NMM. This is the only part of NMM we re-use. The assumption was that all mods on nexusmods were probably tested against NMM so we'd get the best compatibility this way.

That's probably the best answer I could hope for. Thank you.

[MysteriousGuy]

Since whole point of canceling MO was to create new better mod manager my question is simple: Will Vortex be better than MO and if yes in what way?

[TechAngel85]

In response to post #49977347. #49977612, #49977627, #49977747, #49977772, #49978322, #49978412, #49978502, #49978607, #49978752, #49978832, #49978967, #49979042, #49980232, #49980267, #50066187 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: Having read this article I came up with one conclusion. Tannin sounds like a modder still, with a take it or leave it attitude. Which is fine when you are providing an option which you give away and people can use or not as the like takes them.

However when you are representing Nexus you are in effect working for the people on here and if they want by majority a non virtualization version then I feel you should put your bias aside and give them what they want either as an option or as a separate piece of software.

Now I freely admit I have no idea what the percentage would be for and against but I suspect Nexus will regularly receive input and could soon tell you which way the wind is blowing.

For the record I'm perfectly happy with the way the current version does things, so if Vortex works the same way that's fine, but it seems ill advised to force something upon people if they do not want it.

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]

In response to post #49977347. #49977612, #49977627, #49977747, #49977772, #49978322, #49978412, #49978502, #49978607, #49978752, #49978832, #49978967, #49979042, #49980232, #49980267, #50066187, #50066557 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: Having read this article I came up with one conclusion. Tannin sounds like a modder still, with a take it or leave it attitude. Which is fine when you are providing an option which you give away and people can use or not as the like takes them.

However when you are representing Nexus you are in effect working for the people on here and if they want by majority a non virtualization version then I feel you should put your bias aside and give them what they want either as an option or as a separate piece of software.

Now I freely admit I have no idea what the percentage would be for and against but I suspect Nexus will regularly receive input and could soon tell you which way the wind is blowing.

For the record I'm perfectly happy with the way the current version does things, so if Vortex works the same way that's fine, but it seems ill advised to force something upon people if they do not want it.

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

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

[matortheeternal]

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.

 

So we won't be able to install separate archive "mod options" for a single mod into the same mod "folder"/"item" in Vortex? That's pretty dissappointing, to say the least. I understand how you want to have unique folder names, but that significantly reduces the accessibility of the Mods folder to tinkering. Shouldn't it be the responsibility of the user to make certain a mod installs into the correct folder for their own organizational needs?

 

At the very least, you should have an option to rename these folders and install archives into existing folders, perhaps only accessible if a user has enabled a setting.

 

EDIT: Also, how is that unique ID determined for archives that do not originate from Nexus Mods, and thus do not have a File ID associated with them? I'm guessing you use some kind of hash/PRNG and check for conflicts? I honestly just don't see the value of this layer of obfuscation within the mods folder. If you really want to have some kind of unique method of checking if a particular mod is installed by checking folder names the Nexus should add unique string IDs for mods.