Help understanding mod types and installer selection

[agc93]

Sorry for the newbie questions, but looking through the existing Vortex (and Nexus-maintained extensions) code has me a bit stumped and I think I'm just missing something high-level.

 

If an extension registers a new mod type using context.registerModType , what does that actually do inside Vortex? If an extension registers multiple mod types and also registers multiple mod installers, how does Vortex (or the extension) control which installer gets called for a specific mod type?

 

From what I can tell, the mod type registration never sees the file list, and the mod installer registration never sees the mod type so I'm just having trouble working out how the two play into each other.

 

-----

 

To make it a more practical example, if a game has two types of mods, one to be installed in the root of the game directory, and the other to be installed in some arbitrary data folder, should that be controlled by different mod types? or just multiple installers? or both.

[Tannin42]

The installer controls how a mod gets extracted, e.g. if mod authors in a community have adopted a certain directory layout in their archives or to support installer options (fomod), you use an installer.

 

The mod type controls how a mod gets deployed, e.g. skyrim mods are designed to be installed to the Data directory (and are packaged under the assumption they go there) whereas enbs go to the base game directory and savegames (which we currently don't support but it would be easy enough) go somewhere in c:\...\documents I guess.

For some games files from different mods have to be merged during deployment which can also be influenced by the mod type.

 

So there isn't really a direct connection between installer and mod type. There may be cases where an installer determins what type a mod is but not the other way around, the mod type is set _after_ installation, either manually or automatically based on the files that got installed.

[agc93]

Awesome, thanks for the info Tannin!

 

So in an extension with multiple mod types with different installation targets (just like the enb/Data example you gave), am I right in over-simplifying things to say that the installer controls *how* the files are deployed (i.e. creating the instructions) and the mod type mostly controls *where* those instructions are executed?

[Tannin42]

Well, the instructions the installer generates are evaluated when the archive is extracted whereas the mod type is evaluated during every deployment so the mod type is more "dynamic". A user can change the mod type of an installed mod and thereby change where the mod gets deployed, but the "instructions" that define the directory layout of a mod can't be changed without reinstalling the mod.

 

Since the mod type is a flag on the mod you can also use it for custom logic, e.g. an extension can react to events Vortex triggers and then have behavior that differs depending on the mod type, whereas the installer that was used during the installation is "forgotten". This is maybe something to reiterate: Once the installation of a mod is done, the installer is done, you can't have logic that goes "if mod x was installed with installer y do z". You can however have logic that goes "if mod x has mod type y do z".

 

Another consequences of mod types that has to be mentioned though: Each mod type is deployed individually, Vortex is not (currently) able to detect file conflicts between mods of different types. E.g. if you have a regular skyrim mod with default type that contains the file "foobar.esp" and then you have a enb mod that contains "data\foobar.esp" it will not show a conflict between the mods and it will always use the foobar.esp from the enb mod (which gets deployed later) and the user has no way of affecting that order.

Because the deployment process is done separately for each mod type, having many mod types is also bad for performance.

 

Both of these mean that mod types currently have to be used with care. In particular we ourselves try to avoid introducing mod types that aren't limited to individual games, because there is a performance overhead for every registered mod type where the "isSupported" function returns true.

[agc93]

[...]

 

Both of these mean that mod types currently have to be used with care. In particular we ourselves try to avoid introducing mod types that aren't limited to individual games, because there is a performance overhead for every registered mod type where the "isSupported" function returns true.

 

Just to revisit this: is the performance impact still that bad for game-specific mod types? It's looking like I might end up with 3 or 4 mod types for this game, but they're all game-specific, at least.

[Tannin42]

If the "isSupported" call returns false the overhead is practically zero so it really just affects your specific game.

 

I don't really have any benchmarks about this but I'm pretty sure we're talking milliseconds here per type so 3 or 4 game specific mod types aren't going to make a difference performance wise, it's just that we're now past 100 supported games, if they all brought with them mod types that aren't game-specific that would add up.

[agc93]

Awesome! I'm trying to keep as much type-specific logic out of the installer as possible, so mod types make it a bit easier to draw those (completely arbitrary ) lines.

All the mod types I'm adding are specific to the game so hopefully shouldn't cause much of a drag. Thanks for the info!