Oblivion Mod:Mod Package Contents

Intro

It is always best to check the package structure before installing and finding out that something is wrong, especially when the problems do not show immediately. The preferred package structures are those that are easiest to install, so the goal is to have packages reflect installation structure, if possible. Often the complexity of a mod's structure makes exact reflection of installation structure impossible. Most mods do have simple a simple installation configuration. However, many mods have multiple installation configurations. There are also many mod packages that look like they have a simple structure but actually have mupltiple installation configurations. This is another step where a mod's ReadMe is very important. Evaluating packages before trying to install them is a quick, valuable step.

Notes: 1) OBSE plugins are not discussed here. They differ vastly from regular mods. All of that information can be found on the OBSE page. 2) BAIN and OMOD users do not have to extract archives in order to evaluate archives (unless they are OMOD archives or some other unsupported format, but those would have to be extracted anyway.)

Mod Install Structure

When dealing with mods, installed means that the content that is to be loaded in-game is in the Data folder. After a mod is successfully and correctly installed, its structure reflects that of almost evey other mod. Plugins are in the Data folder, data files are in one of the default folders (i.e., Textures, Meshes, Sound) or packed in custom BSA archives, and INI files and Docs are wherever the utility or package placed them.

There is not a special location for INI files and docs because they are not loaded by the game engine itself. INI files are read by their mod's respective plugins and documentation is for the user. Although, there is not a set location, many modders place INI files in a folder named "INI". Otherwise, INI files are generally placed in the Data folder or a folder reflecting the mod or author's name. BAIN installs files it recognizes as documentation in the Docs folder. Bash and a number of mods use that folder as well. OBMM, in contrast, does not install the ReadMe file that is treated as the OMOD's ReadMe (the one that appears when you choose 'View ReadMe' from the OMOD menu), but it places all other documentation-type files wherever they appear in the OMOD package.

Installed Mod Structure

(Data Folder view)

• Plugins: ESMs, ESPs
• Default Folders: Video, Trees, Textures, Meshes, Sound, Shaders, Music, Menus, Fonts, Distant LOD
• Other Folders: INI, Mod-named or Author-named(containg docs and/or INI files)
• BSAs
• Docs: TXT, DOC, HTML, HTM, RTF, PDF, etc.
• INI files

Notes: An installed mod may have any combination of the items listed above.

Simple Packages

These are the nicest packages. They are installation-ready. In these archives, there is a folder contained within that represents the Data folder, which is either the top level of the archive or the one folder contained within the archive. If there is a folder contained within, it is often named "Data" or the name of the mod. Not only are they simple for manual installers to install, these are also OMOD-friendly and BAIN-friendly. OMOD users can just pack them into an OMOD and BAIN users are good to go if the archive is in their Installers folder.

Not all mods that reflect the install structure are simple mods, and some packages just contain extras that have no reason to be in the Data folder, cluttering it. Clutter hurts performance. In these cases check the ReadMes and the extra (non-default) folders. The only files that can be installed in a non-default folder are INI files and BSAs. The extra folder might contain alternate texture files or some other alternate configurations that can be installed, but those would have to be moved to the appropriate folder. Those packages are complex packages, not simple packages. The other complex packages that may look like simple packages are those where there are multiple main plugins or optional plugins. Some mods offer SI and non-SI main plugins or OBSE and non-OBSE plugins. If a package contains multiple plugins, check the ReadMe.

Complex Packages

There are many variations of these, not even including badly-packaged, disorganized mod packages. These range from small mods that just have multiple versions of the main plugin to overhauls with a hundred possible configurations. Most BAIN-Ready and OMOD-Ready packages fall under this category. That is part of why those tools were made, to facilitate the installation of the more complex packages. However, an OMOD-Ready or BAIN-Ready package is not necessarily complex. Most mod packages include installation instructions that suffice for manual users, but in these cases the utility users are much better off if there is a download available with the relevant "Ready" label (or the both OMOD-Ready and BAIN-Ready label.)

Nearly all complex packages are OMOD-friendly IF you are willing to write (or find) an OMOD-script (which is what the OMOD-Ready downloads often include.) BAIN-friendly packages define a much more narrow group. All packages simple packages and complex packages that look like simple packages but have multiple main plugins and optional add-on plugins are BAIN-friendly.

Not "Nicely-Packaged" Packages

"Nicely-packaged" packages are those that the user does not have to repack. Manual users do not usually have to worry about this, of course. There are a few mods that fit this category for which the user should not even both complaining about, and that would be resources. Whenever you see "Modder's Resource" or something along those lines, who knows what the downloaded archive contains, other than the resource. The DDS (texture) file and the PSD (Photoshop) file, might be sitting at the top level of the archive. Another group of mods that can sometimes be a headache are cosmetic compilations. If they are not packaged in an OMOD-Ready format, they can contain a lot of folders to go through in order to find the different options.