Complete Installation Guide for Oblivion/Part 2/BAIN/Analyze Mod and Package Structure
Analyze Mod and Package Structure
All of the mods used explicitly in this guide are BAINBAsh INstallers-Ready, simple packages or have BCFs available; therefore, many details of mod structure and packaging are "invisible" to the user. Understanding mod install structure is vital to understanding what a valid package is in the Installers Tab.
About Mod Structure
...excluding OBSEOblivion Script Extender plugins.
Mods may have two parts, plugins and data files. Some have only one or the other. Those that include only data files are what are referred to as "replacers", mods intended to change visual or aural features of the game (or even certain mods.) Data files are merely loaded and used according to rules defined in plugins. As such, no record of which data files are installed for Oblivion is kept for the game, and replacer's files can be switched out at anytime without affecting save files at all. The only minor exception is when dealing with BSAs, if they are registered in the Oblivion.ini, removing them without updating the game's INI, will likely result in the game being unable to fully load. Removing the original BSAs is slightly more tedious than dealing with mod-added BSAs and should generally be left alone.
Plugins are the files that really change how the game is structured (up to a certain level.) A poorly structured plugin can cause crashes and all sorts of issues, but, fortunately, their being causers of serious issues is not the norm. There are two types of plugins, ESMs and ESPs. The former are almost always only resource files, their primary purpose being to hold new records. Mods' ESPs do all of the work, from placing structures to modifying NPCs' inventories. Most mods are simple, and will only have a single plugin, but many have multiple plugins.
ReadMes, with respect to mods' structure, become very important when a mod has multiple installation configurations, not just multiple plugins; although, some complex mods may only have plugins. For example, many mods provide both Vanilla and Shivering Isles (SIShivering Isles) versions of their main plugin. Some mods include an SIShivering Isles add-on plugin, but that is not always a convenient option. Another common example is a mod that provides a full and a reduced version of the main plugin, the latter being stripped of some of the default features (i.e., Ren's Beauty Pack's hairs-only plugin versus the Ren's Beauty Pack Full plugin.) The best way to determine whether or not a mod includes a multiple configuration is to read the installation section of the ReadMe. Furthermore, when choosing add-ons, some may have extra requirements or may not be compatible with other offer add-ons (which might be because there are multiple versions of an add-on.) A complex mod may even have multiple data file configurations, as is the case with cosmetic compilations that may offer various textures for a given body type.
In the end, only one configuration of a mod should be installed. If multiple versions of a plugin are present, any number of problems may evidence themselves in the game. With the exception of INI files and BSAs, if data files (i.e., meshes, textures, voice files, etc.) are not installed to one of the default folders (i.e., Meshes, Textures, Music, Sound, Voice, Font, DLOD, Menus, Video, etc.) they are not installed. If plugins are not in the Data folder (not any subfolders) they are not installed.
Mod downloads are generally of only a few formats: compressed archives (7z, RAR, ZIP, OMOD), executables (EXE) or, in rare cases, loose files (e.g., ESM, ESP, BSABethesda Softworks Archive, etc.) The process for dealing with the latter two groups varies greatly, but most downloads will be of one of the types in the former group. Loose files can simply be compressed into an archive and dropped into the Installers folder. EXEs are mainly used for quest mods, due to their size. This is good because most quest mods have a simple install structure, and the files installed by such EXEs are just loose files to be added to an archive and installed.
Ignoring OBSEOblivion Script Extender plugins (which are a whole different type of extension for the game) mods can have two parts. Compressed archive mod downloads either have a simple package format or a complex format. Simple packages' contents reflect installed mod structure. Once extracted (from the proper location) all files are installed. However, that does not mean that it would be installed correctly. A package that contains only plugins may have multiple versions of some plugins, which the user should choose between instead of installing them all. The installation can be complex, even if the package is not.
BAINBAsh INstallers Packages
The reason why BAINBAsh INstallers is practically facilitated manual installation is because using BAINBAsh INstallers's Install function is nearly the equivalent of 'Extract to Oblivion\Data'. If you look at the files listed in the General tab of a package, those files are being extracted to the Data folder, just as they are listed. That implies a couple of things, but the most important implication is that packages must be install-ready. This rule defines three types of packages, simple, BAINBAsh INstallers-Ready (complex), and invalid.
Simple packages are those that would extract simply. The whole archive is install-ready. This is why most mods are BAINBAsh INstallers-friendly; they are simple packages. When uninstalled, these are indicated by a light gray checkbox. An archive with what could be considered a single subpackage is still a simple package. That subfolder could be 'subfolder' or 'subfolder\subfolder'. The only requirement is that at some directory level there is one folder that contains all of the mod's files in an install-ready format.
BAINBAsh INstallers-Ready packages are complete packages. Obviously, a mod with multiple data file configuration cannot be a simple package. (They contain multiple files with the same file path and filename.) You can apply the same comparison mentioned earlier (BAINBAsh INstallers installation being similar to extracting to the Oblivion Data folder) by thinking of the installation of BAINBAsh INstallers-Ready packages as, not the installation of the archive itself, but as the installation of its subpackages. Therefore, a BAINBAsh INstallers-Ready package is an archive that is entirely split into subpackages, all of which must be install-ready. The priority of a subpackage is determined by its alphanumeric position. For example, if a package had subpackages 00, 01 and A, the texture file 'Textures\menus\example.dds' in subpackage '00' will be overwritten by another version of that file in subpackages '01' or 'A'. If all thre subpackages are checked, the version in A would be installed. BAINBAsh INstallers packages' files are installed according to order as well, albeit set in a slightly different manner.
Invalid packages, then, are those that are incomplete archives (indicated by red-Xs), non-archives (not visible to BAINBAsh INstallers), and archives that break the install-ready rule (dark grey). Breaking the install-ready rule is as simple as having a folder within the archive labeled 'Data', which, on its own, is considered a package, but at that same level is a plugin. If the folder containing those two files was extracted into the Data folder, the plugin would be installed and the Data folder would simply be there. The install-ready requirement can be broken on any level because an archive can be install-ready at any level. If a plugin is found in a (would be) subpackage, that part of the archive is invalid because plugins have to be installed to the Data folder. The same goes for the default folder. The Textures, Meshes and other default folders have to be found at the same level as the plugins.
Another more subtle art of BAINBAsh INstallers packaging is deciding on how to label subpackages. The reason why many BAINBAsh INstallers-Ready archives use numbers to order the subpackages is because that makes the ordering obvious. It is also important to label subpackages informatively. If, for example, BCBetter Cities's "00 Core" subpackage was instead labeled "Better Cities ESM and Dummy ESP", it could end up anywhere among the other subpackage, at the end if the rest of the packages were labeled as they are and who knows where if all of the subpackages were labeled "Better Cities ...". The label "Core" says very clearly "must be installed." Using numbers also gives the author flexibility to name the packages logically, as opposed to worrying about whether or not the names will allow the subpackages to sort correctly. The other thing authors can do with the numbering convention is convevy extra information by prepending subpackages with the same numbers: "these subpackages are of the same type" or "only one of this group should be chosen." BCBetter Cities, for example, uses the first digit to mark a macro group (i.e., 0s, 1s, 4s) where the subpackage with 0 as the second digit is the core subpackage of the group and the others (i.e., 01, 11, 41) should only be checked if the core subpackage of that macro group is also checked. Whether or not the macro group or it's core subpackage's dependencies are required should be detailed in the BCF's ReadMe.