Mod Types in Elder Scrolls

There are two major problems with Mods in Elder Scroll games. The first is mod conflicts, where two mods which work separately create issues when combined. Easy modding in Elder Scrolls relies on reducing mod conflicts as much as possible. The way that moders build mods and the tools that they use to do so should encourage proper mod creation where possible. Any remaining conflicts should be detected when the player attempts to start a game with conflicting mods. In these cases, the player should be given tools to resolve the conflict in intuitive ways. If a resolution can't be found, the player should be given as much information about the issue as possible, so that they can decide whether or not to remove one of the mods.

The second major problem is with save file corruption—the loss of save files which occurs whenever a change in mods is incompatible with the old save. Most of the solutions for save file corruption share a striking resemblance with the solutions for mod incompatibility. Moders should be encouraged to avoid corrupting save files, and players should be warned when potential corruption is detected, but, unlike in the case of incompatible mods, the resolutions for corrupted saves can be much more powerful.

Database of mod conflicts, load orders, and patches. (LOOT) Enforce and encourage proper modding in mod tools. Detect problems with mods at runtime. Automatically correct some issues. Inform the player.

Expanded equipment

Mods can add weapons, armor, and spells to the game without effecting much. The game should allow for common additions to be integrated into the game world (and subsequently removed) without affecting save files or creating incompatibilities with other mods. Equipment—weapons, armor, and clothing—can be added to a game roster and automatically spread throughout the world, including equipping them to NPC's. If these mods are removed, the game should regenerate the game world with new, relatively compatible equipment. NPC's that carried the new weapons will be given equivalent weapons. Saves should retain information about the old items, however, and if the player reactivates the mod, those items should reappear in the players inventory, or in the environment where the items were discarded.

Changing textures and meshes

Mods should be able to swap out textures and meshes of common objects without creating conflicts with saves or other mods. These changes should be cataloged and players should be able to select which changes to keep and which to throw away. The game should automatically detect the performance consideration of different mods. For example, counting the triangles in a mesh or checking the resolution in texture files. The game should then be able to load these files based on performance settings in menu's, by applying a budget equation to the assets of different items. Mods could then come with several variants with different performance requirements, which would automatically be loaded based on player settings.

It is possible that a new mesh for an item from one mod could be combined with a new texture for that same item from another mod. As long as the vanilla texture lines up with the new mesh the two will be compatible. If a 3d mesh is very different from the vanilla model, however, the mesh author could create a mapping between the locations of the vanilla texture file and the new texture file. The game could then automatically warp textures to match the mesh.

Altering terrain

The game should allow for moders to change the environment by adding structures, collision boxes, and nav meshes for AI. The game should detect where these changes were made, and check for collisions with other mods. In the case of collisions, the game should allow for the player to select one mod to supersede the other, causing any colliding changes to simply disable the conflicting change from the supplanted mod. The player could also leave both mods as is, such that the structures of both mods simply overlap. Nav mesh consolidation would then need to be performed.

If the player character is inside of one of these collision boxes whenever they load a save, they will be moved to a safe distance before the game loads. The same will happen for any other characters and any movable items in the game world. Character and enemy AI will need to be able to cope with changing navigation meshes. And players that would spawn standing on a platform that no longer exists would need to be moved in order to avoid fall damage. The safest place to move a player would be onto the closest navigation mesh. Though the player lacks an AI that might require the mesh, the mesh still represents an area that is safe to stand on and avoids the player getting stuck.

Adding locations

Adding new locations has the same potential for conflicts as altering terrain. A mod which extends a cities limits to contain more shops, houses, and citizens might conflict with a player house mod which attempts to add a cabin to the same general area. These conflicts could be detected by the terrain collision system, and the fixes would be much the same as with altered terrain.

Deleting content.

Mods should be allowed to disable content, like removing barrels from an area, but other mods that alter that same content, possibly by updating the items in said barrels, should not crash the game or corrupt save files. Editing an entity that's been disabled should be allowed, even though the edits will have no effect. Mods should be allowed to check if items have been disabled, but if they fail to check, it should simply be a non-operation.

Disabling content in an existing game will need to be handled carefully, but removing content in the base game would be no different than disabling a mod which added content to the base game. Disabling items would simply unequip them from the player, disabling characters and enemy types would despawn those entities, and players that saved inside an area that was disabled by a mod would be moved to a safe distance.

Added quests.

Adding new quests without conflict would be difficult. An important item added to a disabled barrel would block the player from progressing in the quest, but detecting that this item is of vital importance (rather than some unimportant trinket) would be necessary. Quest creators would need to be able to hint at the engine that certain changes are vital for the proper execution of their quest. Characters, items, and locations that are lost or displaced by other mods should trigger conflict detection, and corrections or warnings to the player should be issued.

For an extreme solution, a constraint solver could be used to try to fix quest conflicts with other mods. A quest author could require that an item be available in a given city, but suggest that that item spawn in a particular barrel. If that barrel is disabled, the constraint solver could attempt to move the item to another nearby container. If there are no containers nearby that haven't been disabled the item could simply be placed on the ground in a safe location. The quest creator could then further refine this process by introducing new constraints. Maybe the item should always be locked away, or should always be for sale. The constraint solver could try to satisfy these constraints to the best of its abilities, even going so far as to disable small parts of other mods to meet them. If a solution cannot be found the player should be warned of the conflict.

#games #active