Current Vortex Shortcomings (from my perspective)

[primem0ver]

Up until now, I have enjoyed the flexibility of Vortex and its attempt to bring the "best of both worlds." I was hoping that Vortex would be able to replace MO as I use it but I have come to a point where it is unable to do things (or doesn't do things as well) which I need it to do. I am wondering if these are glitches, unfinished features, or if I should just go back to MO.

 

1. Vortex does not appear to be detecting conflicts between loose files and BSA's. For example, I have two mods that replace the same vanilla script installed. One script is loose and the other in a BSA. Vortex is not detecting a conflict.

2. Managing mod load order in Vortex is a pain.

• in the past when I needed to troubleshoot a load order/crash/mod conflict/or just needed to temporarily change the order in order to work on one of my own mods (changing the master bit in an esp), it was easy to copy the load order files from my profile and back them up so that I could restore the original load order (and take out the culprit when found during troubleshooting) after I was done. Now, it seems, I must overwrite files in two places for this to work.
• I am not able to change load order manually which is something I do fairly often. Am I missing something?

3. Does Vortex allow the game to load all BSA's regardless of esps like MO did? Or must the esp be loaded?

4. I have not actually tested this in Vortex yet, but in MO it was easy to add a new mod to the mod list by just creating a folder in the installed mod folder and adding files to it. MO was great because it double checked and tested everything quickly. Can I do this in Vortex?

5. Lastly... and this isn't a big issue but it is annoying. Vortex seems to take a significanlty longer time than MO to 'deploy' mods. This makes sense I suppose since it needs to recheck and manipulate all the hardlinks for each file on the disk rather than in memory. Is there any way to improve this or is this pretty much the way it has to be?

 

EDIT:

6. I really miss knowing what a mod had inside it (textures, scripts, esps, extender, etc...)

Edited April 19, 2018 by primem0ver

[rmm200]

6) All mods are unpacked in a folder structure. Use the right-most dropdown on a mod, and one of the choices there is Open in file manager.

There you can see everything the mod contains. Meshes, textures, esp, etc. Don't know if it is recommended, but I have added and removed things from mods within that file manager view. Deploy afterwards - and it had the desired effect.

Edited April 19, 2018 by rmm200

[Tannin42]

re 1.: Might be added in a later version. The reason this isn't in yet is that it basically depends on another feature which is file conflict resolution on a per file basis. The only "sensible" way to resolve a "loose file conflicts with bsa" problem is to not install the loose file (since loose files have priority over bsa files and turning bsas into loose files is a bad idea) but unless we want to permanently delete the file we need Vortex to be able to skip deploying certain files.

 

re 2.: I'm assuming you're talking about plugin load order, not mod order. With Vortex (using loot) your load order is "stable" meaning the rules/priorities you set will be enforced and you can't manually change the order directly. So what's the point of a backup/restore feature? When you're working on your own mod and want to temporarily enforce a certain mod index to test conflicts you can do so very easily by directly specifying the mod index directly. Apart from that, mapping the community knowledge (including yours) about plugin conflicts into rules and then automatically deriving a load order specifically for your installed set of plugins is simpler and more robust than directly setting a load order. I know it requires a rethink but trust me, it's worth it.

 

re 3.: The esp has to be loaded. The esp-less bsa loading in MO actually has pretty far reaching consequences that people may not be aware of. For one thing, it requires api hooking (which may trigger AV software and any bug can crash your game) because MO has to list those bsas in the game ini file and there is only very limited space to list bsas so MO has to hook the ini functions to allow more bsas to be loaded this way.

Second, since ini-loaded bsas get loaded in a different phase than the ones associated with esps, the "load order" of bsas and in consequence the order in which files (especially scripts) get loaded can get messed up, unless you allow MO to load all bsas this way.

Which then means your plugin load order doesn't affect bsa order at all which invalidates all loot rules and all installation instructions for mods made to avoid asset conflicts - unless you follow MOs "potential mod order problem" suggestions, which apparently very few people did.

 

re 4.: yes, you can manually add mods to Vortex. Atm you have to restart vortex for it to pick up on the new mod though.

 

re 5.: How long are we talking about when you say "significantly longer". One thing you have to realize is that "deployment" in MO happened while the game was starting so with MO your game would start slower.

With Vortex the deployment happens visibly in the application so you can more directly attribute the delay to Vortex, doesn't mean you're actually waiting longer.

It's true that Vortex deployment will be slower per-file because it does actual file operations whereas in MO everything happens in memory but on the other hand Vortex only creates the links for files that changed since the last deployment so after the first deployment, unless you purge or enabled/disabled a mod with a lot of files, any further one should be very quick. In MO the full deployment happens every time you start the game or application.

 

re 6.: This will almost certainly be added later. Remember: This is an alpha

[primem0ver]

@Tannin42

 

Thank you very much for that insight. So the only issue for me will be #2 (in the long run... right now I will probably end up using MO to address #1 and #6 as I rebuild my mod set from oldrim). If there is a backup/restore order feature that allows backups (plural) by name, then that will work just fine, especially if I can manually assign a load order spot by number (you suggest this but as of yet I haven't been able to figure out how to do it). The biggest issue here is troubleshooting. When the game always crashes at a certain spot, finding out which mod is causing it when you have 200+ mods is a real pain. Allowing us to be able to systematically uncheck mods to find the culprit, and then restoring the load order from a backup will make a big difference.

 

EDIT: One other (hopefully) helpful suggestion. Since Vortex is still not quite finished implementing planned features this may already be in the works... but the overwrite feature of MO was very nice. It allowed us to see what changes were made by things like FNIS, TES5Edit, CK, etc... When Vortex detects changes, it allows us to restore the old or replace the old. What about at least one more option, to create a new mod folder that takes precedence? (It is much more difficult to locate individually changed files now that the overwrite folder no longer exists).

Edited April 19, 2018 by primem0ver

[rmm200]

@Tannin42

 

Thank you very much for that insight. So the only issue for me will be #2 (in the long run... right now I will probably end up using MO to address #1 and #6 as I rebuild my mod set from oldrim). If there is a backup/restore order feature that allows backups (plural) by name, then that will work just fine, especially if I can manually assign a load order spot by number (you suggest this but as of yet I haven't been able to figure out how to do it). The biggest issue here is troubleshooting. When the game always crashes at a certain spot, finding out which mod is causing it when you have 200+ mods is a real pain. Allowing us to be able to systematically uncheck mods to find the culprit, and then restoring the load order from a backup will make a big difference.

 

EDIT: One other (hopefully) helpful suggestion. Since Vortex is still not quite finished implementing planned features this may already be in the works... but the overwrite feature of MO was very nice. It allowed us to see what changes were made by things like FNIS, TES5Edit, CK, etc... When Vortex detects changes, it allows us to restore the old or replace the old. What about at least one more option, to create a new mod folder that takes precedence? (It is much more difficult to locate individually changed files now that the overwrite folder no longer exists).

 

Bump on the suggestion. I never want to have to go through all my mods again, one by one, looking for textures that Vortex deleted, with the only option being to reinstall the mod. And most of my mods are "Installed from a file", so they were not even in Vortex downloads.

[primem0ver]

Bump on the suggestion. I never want to have to go through all my mods again, one by one, looking for textures that Vortex deleted, with the only option being to reinstall the mod. And most of my mods are "Installed from a file", so they were not even in Vortex downloads.

 

Forgive my ignorance. Not sure I follow what you are saying. "Bump" meaning you agree or disagree? (to me bump usually means remove(d), hence disagree). I am not sure how this applies since I am talking about a specific feature that occurred in MO when files were overwritten by the user; not by Mod Organizer. I am suggesting we add a user option when Vortex finds changes to files so that we don't have to go looking through all the mods/files to find files changed by an external utility. So from where I sit, my suggestion is helping your cause, not hurt it.

 

EDIT: perhaps you are interpreting my suggestion to mean my addition should replace the replace/revert (restore) options. That is not the case. It would be a third option. There might even be room for more choices.

Edited April 20, 2018 by primem0ver

[rmm200]

 

Bump on the suggestion. I never want to have to go through all my mods again, one by one, looking for textures that Vortex deleted, with the only option being to reinstall the mod. And most of my mods are "Installed from a file", so they were not even in Vortex downloads.

 

Forgive my ignorance. Not sure I follow what you are saying. "Bump" meaning you agree or disagree? (to me bump usually means remove(d), hence disagree). I am not sure how this applies since I am talking about a specific feature that occurred in MO when files were overwritten by the user; not by Mod Organizer. I am suggesting we add a user option when Vortex finds changes to files so that we don't have to go looking through all the mods/files to find files changed by an external utility. So from where I sit, my suggestion is helping your cause, not hurt it.

 

EDIT: perhaps you are interpreting my suggestion to mean my addition should replace the replace/revert (restore) options. That is not the case. It would be a third option. There might even be room for more choices.

 

 

Bump the way I used it was just to agree. Like bringing an old topic back to the front. Texture files I lost were deleted by Vortex after thinking Mod Organizer deleted them. Unfortunate overlap of organizers. Brought up Mod Organizer to see what my load list looked like. Won't do that again.

[primem0ver]

@rmm200

Gotcha. Yeah... I have set both up so its easy to switch between them if I decide to convert back to one or the other. I have already been warned against using them both at the same time.

Edited April 20, 2018 by primem0ver

[Tannin42]

@Tannin42

 

Thank you very much for that insight. So the only issue for me will be #2 (in the long run... right now I will probably end up using MO to address #1 and #6 as I rebuild my mod set from oldrim). If there is a backup/restore order feature that allows backups (plural) by name, then that will work just fine, especially if I can manually assign a load order spot by number (you suggest this but as of yet I haven't been able to figure out how to do it). The biggest issue here is troubleshooting. When the game always crashes at a certain spot, finding out which mod is causing it when you have 200+ mods is a real pain. Allowing us to be able to systematically uncheck mods to find the culprit, and then restoring the load order from a backup will make a big difference.

 

EDIT: One other (hopefully) helpful suggestion. Since Vortex is still not quite finished implementing planned features this may already be in the works... but the overwrite feature of MO was very nice. It allowed us to see what changes were made by things like FNIS, TES5Edit, CK, etc... When Vortex detects changes, it allows us to restore the old or replace the old. What about at least one more option, to create a new mod folder that takes precedence? (It is much more difficult to locate individually changed files now that the overwrite folder no longer exists).

 

Wouldn't this be easier to solve with a second profile? Clone the profile you want to debug, disable mods to fin the culprit, then go back to the original and disable that culprit.

 

Regarding the edit: A "put into separate mod" option for the external changes dialog is an interesting idea, I'll look into it.