[Feature request] Install mods in root directory

[Tannin42]

If it's a dll it could just as well be a skse plugin.

What's currently there is basically a heuristic but it has to be such that if there is any doubt it has to fall back to installing to data under the assumption that it was packaged for existing mod managers.

That's why the enb modtype is currently disabled, there are regular mods around that include a "suggested" enb in some subdirectory that confused the detection so the mod installed incorrectly.

 

In the future the "mod type" could simply be something set up on the website by the mod author and then vortex doesn't have to guess.

For the moment it would probably be better to look at the category as an additional hint (ok, it looks like an enb and it is in the enb category, then it might actually be an enb)

[kamikatze13]

screw guessing.

 

have the user click a checkbox (slider like esp index locking): it gives control to the user and solves the problem efficiently and reliably.

Edited May 14, 2018 by kamikatze13

[XJDHDR]

I feel that you have misunderstood what I said. My suggestion will not install existing mods incorrectly nor will it require that thousands of mods be re-packaged. If anything, the only mods that would have to be re-packaged are mods whose files are supposed to be installed into the Root folder.

 

I'll try to use this picture to illustrate:

 

 

 

 

 

If my suggestion is implemented as I suggested, the mods inside the red box will be installed into the Data folder because they do not have a Data folder distributed with their mod package.

Conversely, the mods in the green boxes will be installed to the games Root folder because they have a Data folder inside their archive. I have seen some existing mods distributed in this manner where the archive contains only a Data folder with all the plugins, textures, meshes, etc. contained in the Data folder. This type of mod will be installed into the Root folder but because the root of the archive has only a Data folder in it, this means that all the mod's files will be installed into the game's Data folder.

[kamikatze13]

 

... they have a Data folder inside their archive

 

what if a mod contains a data folder, accompanied by a bunch of readmes and screenshots? will they automagically land in the root, thus cluttering it?

[XJDHDR]

 

what if a mod contains a data folder, accompanied by a bunch of readmes and screenshots? will they automagically land in the root, thus cluttering it?

 

 

Good point, thanks. If my suggestion were implemented as-is, then readmes and screenshots next to the Data folder will end up cluttering the Root folder. One solution I can think of is to copy what Wrye Bash does in this case: add an option to either skip or put any readmes and screenshots into a dedicated Docs or Images folder when installing a mod rather than placing them where the mod's author put them. As a bonus, this would also prevent the Data folder from getting cluttered with those files.

[Tannin42]

I feel that you have misunderstood what I said. My suggestion will not install existing mods incorrectly nor will it require that thousands of mods be re-packaged. If anything, the only mods that would have to be re-packaged are mods whose files are supposed to be installed into the Root folder.

 

I'll try to use this picture to illustrate:

 

If my suggestion is implemented as I suggested, the mods inside the red box will be installed into the Data folder because they do not have a Data folder distributed with their mod package.

Conversely, the mods in the green boxes will be installed to the games Root folder because they have a Data folder inside their archive. I have seen some existing mods distributed in this manner where the archive contains only a Data folder with all the plugins, textures, meshes, etc. contained in the Data folder. This type of mod will be installed into the Root folder but because the root of the archive has only a Data folder in it, this means that all the mod's files will be installed into the game's Data folder.

But how would Vortex know if a mod is "green or red"?

It could look at the contents and determine "ok, there is a data subdirectory and no fomod subdirectory so it probably goes to the root" but that doesn't catch enbs, those don't

necessarily have a data subdirectory so we need further rules like "ok, there is an enbseries.ini so put it in the root"

 

But that's exactly what we already do. Look at the content and based on some rules try to deduce the mod type.

[Graybark]

 

I feel that you have misunderstood what I said. My suggestion will not install existing mods incorrectly nor will it require that thousands of mods be re-packaged. If anything, the only mods that would have to be re-packaged are mods whose files are supposed to be installed into the Root folder.

 

I'll try to use this picture to illustrate:

 

If my suggestion is implemented as I suggested, the mods inside the red box will be installed into the Data folder because they do not have a Data folder distributed with their mod package.

Conversely, the mods in the green boxes will be installed to the games Root folder because they have a Data folder inside their archive. I have seen some existing mods distributed in this manner where the archive contains only a Data folder with all the plugins, textures, meshes, etc. contained in the Data folder. This type of mod will be installed into the Root folder but because the root of the archive has only a Data folder in it, this means that all the mod's files will be installed into the game's Data folder.

But how would Vortex know if a mod is "green or red"?

It could look at the contents and determine "ok, there is a data subdirectory and no fomod subdirectory so it probably goes to the root" but that doesn't catch enbs, those don't

necessarily have a data subdirectory so we need further rules like "ok, there is an enbseries.ini so put it in the root"

 

But that's exactly what we already do. Look at the content and based on some rules try to deduce the mod type.

 

What about mods that do have a Data folder in them but no conventional subfolder? Vortex sometimes put this whole data folder into the Data directory. So you end up with Data\Data\mod files. Is that a bug or something you will not do because of design philosophy?

[Tannin42]

 

 

What about mods that do have a Data folder in them but no conventional subfolder? Vortex sometimes put this whole data folder into the Data directory. So you end up with Data\Data\mod files. Is that a bug or something you will not do because of design philosophy?

 

When you encounter something like that, please make sure to report it.

 

It's not so much a bug but more that the fomod format is rather fuzzy. Both NMM and Vortex implement the specification correctly and yet some mods that were tested with NMM will not install correctly with Vortex.

 

Now you may think: just make it work like NMM but that isn't trivial because under the hood Vortex is very different. Trying to fix one mod that currently doesn't install correctly could break five others that worked previously. It's a very annoying game of whac-a-mole.

[XJDHDR]

 

I feel that you have misunderstood what I said. My suggestion will not install existing mods incorrectly nor will it require that thousands of mods be re-packaged. If anything, the only mods that would have to be re-packaged are mods whose files are supposed to be installed into the Root folder.

 

I'll try to use this picture to illustrate:

 

If my suggestion is implemented as I suggested, the mods inside the red box will be installed into the Data folder because they do not have a Data folder distributed with their mod package.

Conversely, the mods in the green boxes will be installed to the games Root folder because they have a Data folder inside their archive. I have seen some existing mods distributed in this manner where the archive contains only a Data folder with all the plugins, textures, meshes, etc. contained in the Data folder. This type of mod will be installed into the Root folder but because the root of the archive has only a Data folder in it, this means that all the mod's files will be installed into the game's Data folder.

But how would Vortex know if a mod is "green or red"?

It could look at the contents and determine "ok, there is a data subdirectory and no fomod subdirectory so it probably goes to the root" but that doesn't catch enbs, those don't

necessarily have a data subdirectory so we need further rules like "ok, there is an enbseries.ini so put it in the root"

 

But that's exactly what we already do. Look at the content and based on some rules try to deduce the mod type.

 

Sorry for the late reply. I should clarify that I don't regard my suggestion as the only test that should be performed on mods nor do I regard it as a replacement for the ENB tests you currently do. Rather, I regard my suggestion as a supplement to the current checks. In fact, I don't really regard my suggestion as a feature for correctly installing ENBs for the reasons you stated. Rather, it is mainly for mods that are not ENBs.

 

I would like to draw your attention to these three mods that are currently being distributed on Nexus Mods and the contents of the archive you download from their page:

Oblivion Script Extender

 

 

 

DLL Plugin Loader

 

 

 

Construction Set Extender

 

 

 

All three of these mods have files that need to be installed into the game's root folder, they are not currently installed correctly by Vortex (everything is placed into the Data folder) and they are not ENBs so ENB detection rules won't work. If my suggestion were implemented into Vortex, however, this would allow it to correctly install these three mods as well as any others like them because they have a Data folder alongside the files that need to go into the Root folder.

 

I'm genuinely curious though, is there any reason you can think of why implementing my suggestion is a bad idea?

[Tannin42]

 

Sorry for the late reply. I should clarify that I don't regard my suggestion as the only test that should be performed on mods nor do I regard it as a replacement for the ENB tests you currently do. Rather, I regard my suggestion as a supplement to the current checks. In fact, I don't really regard my suggestion as a feature for correctly installing ENBs for the reasons you stated. Rather, it is mainly for mods that are not ENBs.

 

 

I would like to draw your attention to these three mods that are currently being distributed on Nexus Mods and the contents of the archive you download from their page:

Oblivion Script Extender

DLL Plugin Loader

Construction Set Extender

[

All three of these mods have files that need to be installed into the game's root folder, they are not currently installed correctly by Vortex (everything is placed into the Data folder) and they are not ENBs so ENB detection rules won't work. If my suggestion were implemented into Vortex, however, this would allow it to correctly install these three mods as well as any others like them because they have a Data folder alongside the files that need to go into the Root folder.

 

I'm genuinely curious though, is there any reason you can think of why implementing my suggestion is a bad idea?

 

 

Several

a) It's an entirely bethesda-games specific solution, for other games it might produce incorrect results and so we'd have an entirely separate code path for the bethesda games and we'd still have no solution for other games or for enbs and all the mods that don't have a data directory in them.

b) Just because a mod contains a data directory doesn't mean the author intended it to go to the root level. Your solution makes an assumption that's going to be right in at least 99% of the cases I'll admit but it could still break mods that worked before. There are more than 150k mods for the bethesda games alone just on nexusmods, more if you take mods that have only been uploaded to other pages and each mod could have different file variants (patches, optionals).

I have seen mods that contain stuff like "data\my awesome mod\data\textures\tex.dds". That mod would currently install correctly in MO/NMM/Vortex because they dig for the first directory with recognized names (textures in this case) and skip past "data\my awesome mod\data". Your solution would break that because it assumes "data on the top level -> install to root".

c) a lot of mods are packaged in such a way that they contain screenshots or a readme on the root level and a data directory, or a readme/screenshot/options directory plus data directory. Right now, afaik, all mod managers (MO/NMM/Vortex) will deploy only the stuff relevant to the game. With your solutions all those mods would start adding junk to the game root directory.

d) It messes up the responsibilities between installation and deployment. That's actually the reason it's so hard to reimplement fomod support compatible with NMM because NMM did that.

Vortex tries to resolve all the differences between mod installers during the install phase so that the installed mods end up in a normalized format (e.g. a texture mod would have a texture directory at the root, not somewhere below). This way all other parts of vortex can assume on mods having a certain format. With your solution any part of vortex that wants to look at the content of a mod then also needs to account for how the author may have structured it. This makes a lot of advanced features harder, more expensive and more error prone to implement.