Tome of Psymon
Main Table of Contents
General
Welcome
Contribute: Generate Wiki pages from Text Files
Wrye Bash Related
Wrye Bash Features
Wrye Mash Usage
General Usage
Advanced Usage
Technical References
Tome of Alt3rn1ty
Morrowind Related
Morrowind And Beyond
TES Plugin Tool (TESTool) 1.3 Docs
Oblivion Related
Tome of Psymon - BAIN Mod Installation Projects
Oblivion And Beyond
Comprehensive instructions for people who like to read
Original Threads
• BAIN Mod Installation Projects
• Original author Psymon.
• Other then TesAlliance I have not found a way to get ahold of him except the old bethesda forums and I don't think it will send out notifications for personal messages.
Contents
• 7.1 Mod Installing and Mod Management
• 7.1.2 Mod Installation introduction
• 7.1.4 Wrye Bash Download and Manuals
• 7.1.5 More links regarding installer tools
• 7.2 The Basics of BAIN and Mod Archiving
• 7.2.1 Bash Installer (BAIN) tab functions
• 7.2.2 Navigating the Installers Tab
• 7.2.3 Installing and Updating Packages
• 7.2.5 Repackaging Mods for BAIN
• 7.2.6 Mod management and your own mod catalog:
• 7.3.1 Examining BAIN archives
• 7.3.2 Pros and cons of combining mods into complex archive packages
• 7.3.3 Repackaging a complex archive example
• 7.4 Managing Installer Packages
• 7.4.3 Updating best practices:
• 7.5 Creating Your Own Complex BAIN Packages
• 7.5.1 Planning Your Mod Archive
• 7.5.2 Rationale for Complex Custom Packages
• 7.5.3 Examples of Very Complex Custom BAIN Packages:
• 7.5.5 Sky Replacers Compilation
• 7.6 BAIN Wizards, OMODS, and BAIN Conversion Files
• 7.6.1 BAIN Reading OMOD conversion files
• 7.7.1 Fallout3 and Fallout New Vegas
• 7.8 Managing BAIN with Multiple Installs
• 7.8.1 Wait did you say multiple installs?
• 7.8.3 Multiple Oblivion Manager
• 7.8.4 Managing Multiple installs and the problem of Wrye Bash
• 7.8.5 Other Methods and notes:
• 7.8.6 Multiple Installs - One Wrye Bash
• 7.8.7 Tip for starting a new install...
• 7.9 An open letter appealing to the use of BAIN and Wrye Bash by mod makers
• 7.9.1 Reasons for utilizing BAIN:
• 7.9.2 To summarize the advantages of using BAIN packaging for your mods:
• 7.10.1 Why use a Bashed Patch?
• 7.11 Other Bethesda Game Interests of Mine
• 7.12.6 Oblivion Script Extender
• 7.13 Porting mods from Oblivion to Nehrim
• 7.14.1 Nehrim English fixes and Improvements:
• 7.14.11 Graphic Improvements:
• 7.14.12 Environments/Weather:
• 7.14.15 OBSE Plugins that so far work:
7.1 - Mod Installing and Mod Management
The focus of the first post of this thread is to attempt to explain the need for using an installer and BAIN in particular. In the following posts will be explanations of BAIN functions and related topics.
7.1.1 - Why this information?
My original thread on this subject has long since reached its end. My intentions at that time were to mostly have a place to post about how I was using the then new installer created by Wrye and part of the Wrye Bash program. I tend to not like to create threads and usually try to post whatever questions or statements in existing threads. I know when I find something I like I can get a bit zealous about it and, at the time, didn't want to overwhelm other threads with my extremely self-indulgent uses of this new installer. Having it be instructional was really an after-thought. Having gotten the zealous part mostly out of my system I now return to this and hope that this thread, or at least the opening posts will be more instructional and I will do my best to collect and/or link all the best material related to this subject.
I'd like to point out that I am primarily what most would consider a mod-user. [I do not like that term and will explain why below, but for now let me play along.] While I've altered many esp files and even created my own house mod (that will remain unreleased), all the rest I've learned I've picked up from the perspective of a person who uses other, 'real modders', work. Because of this most of what I will attempt to write will be for those who are new to mod using and are trying to get a handle on how to best apply already made mods to their install. Primarily this is being written with TES4: Oblivion in mind, but most of it will and can also apply to TES3: Morrowind and Fallout 3.
7.1.2 - Mod Installation introduction
Let's just start with - "well here we are wanting to mod these Bethesda games." Asking 'How best can I do this?' is not usually where most people start. The way I take it most people start with a game they like then play it for a while maybe do some internet searches and read or hear about these 'unofficial add-ons' called mods and then maybe find a link somewhere to download and then the first learning curve hits with the question 'what is the fastest way I can get this in my game without straining my brain too hard?' Perhaps there is also the thought that 'wow this is complicated', or 'only computer tech people could do this.' If a person is reading this to really learn how to do use mods then they may have an inkling that many consider Bethesda to make some of the most moddable games, promotes modding, and has three of the most modded games on the market.
From this then a person may just dive right in and install these user made mods the old fashion way: manual installing. That means finding out what file needs to go where and then installing it there by copying or cutting from the downloaded content and pasting into the appropriate folder directory of the game install. Doing this, in my opinion, is the most educational way of learning how to add mods. It is by this method that one really has to read the readme and get familiar with all the file directories and the general directory layout and functioning of the game in question.
So with this we learn that the game exe calls upon information from the data directory for the material of what is presented in-game and that where the presented material presents is stored in the save game files often found in another directory. Most modding has to do with adding user made mods to the Data directory. Most of what it takes to do manual installing can be read in the pinned thread called OBLIVION MODS FAQ He does describe the use of installers. This thread will be about the use of installers and specifically BAIN.
So the next phase of most mod users learning curve is after they get in over their head. This is the result of shiny new mods and the very, very deep catalog of mods created for these games. So a user begins by installing some mods to improve graphics, then game settings, then an overhaul is isntalled, but wait that is not the right one ... err maybe that one. Then the game crashes begin - the dreaded ctds: crash to desktops. Then thinking that 'well I guess I should uninstall my game and start over, but next time I will get it right!' Then we are at the original question of how best to do this. Unfortunately, that really is just the beginning because using programs to automate installation means that they are subject to the same rules as all software programs: Junk in = Junk out.
7.1.3 - Why use an installer?
So from this frustration of losing track of all that is installed the need for an automated way to do things is born. Mod Managers are not exclusive to bethesda games and doing a quick google search of the words and you will see many games have mod managers available. Mod Managers automate the installation of user-made-mods (from now on called 'mods'). They are tools whereby the data from a user made mod can be installed and better yet removed with the click of a few buttons. For Oblivion the standard has been Oblivion Mod Manager or OBMM for short. the OBMM download page.
OBMM is a great mod installer. There are a few older ones but as far as a straight away mod installer it is rich with features and by the standards of most light to moderate mod users it will serve the purpose of installing mods very well. It can automate mod installation so that very little thought about what is happening and where things go can blissfully be ignored. All the better that many mods come as either OMODS (packaged to be used by OBMM) or OMOD ready (able to be made into OMODS). There is also a Morrowind Mod Manager, which is primitive, and a very highly developed Fallout Mod Manager, which is starting to make the Oblivion Mod Manager look as primitive as the Morrowind Mod Manager looks when compared to OBMM. The author, Timeslip, continues to develop the FOMM with the help of Kaburke. Recent Thread found here. And with OBMM scenttree is making additions with Oblivion Mod Manager Extended, which includes more control in installing loose files.
The issues or problems with OBMM (or the other varieties) is really a matter of perspective. From a mod makers point of view these programs may indeed be heaven sent because with just some tinkering and packaging a very complex mod can be made available for instant download and installation. This cuts down on the number of complaints and inquiries about how to install the uber-mod-to-end-all-mods (... ohh shiny). And for users who only want to use a moderate amount of mods and not think about what is happening under the hood then it is great. On the other hand, those who do wish to see what is happening under the hood or want to use many mods then the Mod Managers start to show their weaknesses and shortcomings.
My critique of the mod manager is not meant to be unfair to it and I will own that it is my own viewpoint. The Morrowind Mod Manager is not nearly developed enough to warrant using as an installer and the FOMM in its current editions includes many features that attempt to address the shortcomings of the OBMM. To summarize my points:
• The OBMM does not encourage users to think about file directory or about how a manual install of the same mod would work. This has a net effect of reducing a person who is 'modding their game' down to a mere mod-user. To me that further creates a rift between mod makers as the real modders and mod-users as their customers. The caveat being that yes one can script the OMOD files to install in any fashion whatsoever, but again the effect I've seen this have is encouraging sloppy and confusing packaging of mods.
• The OBMM does not offer a comprehensive solution to managing install order, particularly of replacer files. i.e. if one were to want to make sure that a certain replacer was always installing last and was part of larger mod then one would have to uninstall and reinstall said mod. As a caveat there is an option to be notified of conflicts and will even tell you what other OMOD the file comes from and whether you want to overwrite the file in question. This can be very tedious with lots of files to individually click yes/no to.
• The OBMM conflict detector is near useless. Unless you've trained yourself to make sense of what it is telling you mostly it is a confusing report.
• The OBMM can crash and when it does it will lose records of all installed OMODS and require a reinstall of all of them. The unfortunate part of this is the more OMODS you have installed the more likely that this is to happen. This, ultimately, is what made me want to move onto another installer. After several crashes in a short span of time I was about ready to give up on a modded Oblivon.
In concurrent development there was another utility for these games brought to us by Wrye. This was originally the Wrye Bash program for Oblivion but he also created a Wrye Mash program for Morrowind. Wrye Bash (sometimes shortened to WB) is a multipurpose tool with many many features for modders (mod users and mod makers alike). Here is a short and very incomplete summary of its features:
Quote
• An advanced load order tool (adjust and manage load ordering of mods).
• A save game managing tool (create profiles, remove same game bloat, etc).
• Allow automating of INI edits.
• Manage screenshots and archive PM messages from boards such as this one.
• Bashed Patch creation (which includes):
• Merge leveled list altering mods to reduce conflicts.
• Further merge mods and reduce active mods thereby increasing max mods useable.
• Import only specific records within mods and further control load order via Bash Tags.
• Library of game settings that can be adjusted with each bashed patch building.
The last portion of Wrye Bash that Wrye worked on before passing the project on to others to manage in his absence is what is known as BAIN which is short for BAsh INstaller. The BAIN component aptly handles the shortcomings of the Oblivion Mod Manager and in my opinion offers features that greatly expand upon the functions of mod installer programs to date. The features that I'd like to point out are:
Quote
• BAIN encourages thinking about what a manual install is and how things work 'under the hood.'
• BAIN offers minute control of files and gives sensible conflict reports and control options of resolving those conflicts.
• BAIN gives us the ability to manage install order - a term analogous to load order with regard to esm/esp files.
• BAIN Provides detailed reports of what it installs and can tell you if what was installed has changed, been overwritten, is missing, or even if a file was not installed.
• BAIN requires no special OMOD files and can work with 7zip, rar and other common archiving methods (7zip being the recommended though), as well as, regular file folders (projects).
• BAIN offers the ability to create your own packages that can include any number of mods with the limit being only what you can manage to create with file directory juggling.
Most of what this thread will be about is the general uses of the BAIN tab, formatting of BAIN ready packages, and the creation of custom BAIN packages.
Many took my last thread as if I were bashing on OBMM. Not true and the point is that really they each have their strengths. There are things that OBMM can do that Wrye Bash cannot. Some of these include:
Quote
• The installation and merging of Shaders. installation of shaders is possible with Bash 291, but not shader merging or editing.
• OBMM Will install anything you put into an OMOD and create any directory you create as well. Including other archives and executable files.
• Scripted installs that edit the ini automatically and change the name of plugins on install. There are plans to create scripted BAIN wizards - keep checking new bash versions.
• BSA management including extraction and the packaging of BSA files.
• OBMM handles foriegn language characters on file names (unicode) much better than BAIN can.
More about comparing BAIN and OBMM (though a bit outdated).
In short I use both with about 96% of my install managed through BAIN and the rest via OBMM. So for most replacers, large projects, loose random files, mainstream regularly formatted mods and so on I use BAIN. For OBSE extensions, Shader mods (Night eye shaders), and heavily and elegantly scripted OMODs such as those made by theNiceOne or ABO it is OBMM. The main feature I use on OBMM is drag and drop load ordering.
The advantages I've experienced in moving to BAIN include:
• It has kept me grounded in thinking about manual installing and what that implies which has in turn kept me thinking of the this process as modding instead of mod-using.
• It has made it so that I never really have to think about uninstalling and reinstalling the game again. In other words I've never again felt overwhelmed by the amount of material installed and never felt as though I could not manage this material.
• It has allowed me to manage and catalog an enormous mod collection where I could change my load order in very dramatic and comprehensive ways within a very short time.
• It gave me a hobby, some might say an addiction.
7.1.4 - Wrye Bash Download and Manuals
All 4 sections are listed seperatly because of a lack of smooth navagation between pages
7.1.5 - More links regarding installer tools
I'm often told that I'm too wordy, so if you prefer pictures then check out:
Pictorial Guide to Wrye Bash and BAIN by Alt3rn1ty's
Perhaps someday these two guides can be merged!
Many a great resource and more Wrye Bash instructions for the mod user:
TESCosi by Tomlong available in Wiki format. Current forum thread.
Wrye Bash Manual very outdated compared to the readme included with the latest download.
Wrye Musings Many Things Wrye ... including wrye views.
The latest Original Wrye Bash thread as of this writing. If not current just search the last day or two and you will likely find it. This is where you go for technical help in operating the tool.
NOTE: The latest thread for Wrye Bash is on AFK Mods at this time.
Oblivion Mod Manager Alternate Download
Oblivion Mod Manager Extended New improvements in graphic interface and presentation as well as scripting.
OBMM instructions - this site contains a lot of information about archive management in general as well.
• Originally http://lhammonds.game-host.org/obmm/default.asp needs verification
Tools of mod makers and mod users alike
See Post 7: BAINandOtherGames for information on how to use BAIN for other other games.
And thanks to the modders and utility developers that make playing and modding these games so much fun.
7.2 - The Basics of BAIN and Mod Archiving
7.2.1 - Bash Installer (BAIN) tab functions
To begin with most of what I'm writing is an elaboration of what is in the Wrye bash readme (the most current version packaged with the latest Wrye Bash and accessed with ? button on bottom toolbar of Wrye Bash) and I highly suggest you take that as the authority and follow it if I deviate from what is presented there. Next one should direct general questions about the technical problems and functioning in the current Wrye Bash thread. Otherwise if everything is understood and I can answer (or anyone can answer) then ask. I just want to emphasize that those places are a higher authority.
When first installing Wrye Bash (or Wrye Mash or Gary Bash/Wrye Flash) the Installers tab is usually deactivated and when you first click on it you will get a notice asking if you really want to activate the tab. After activating the tab the it will take a few minutes to initialize. It is important do not interrupt this scan because each time you open the tab from this point forward it will scan what you have installed to check if anything has been altered or removed in order to inform you. This is a good thing. The first time you open this may take a few minutes. If you do interrupt the scan then most often you can reopen the tab after restarting Wrye Bash and it will scan again.
This will also create a new directory outside of the main game directory. For Wrye Bash and Gary bash this will be a directory called either Oblivion Mods or Fallout 3 mods and are found right next to the main game directories. Each of these will, in turn, contain a folder called 'Bash Installers.' (There may be a way to alter that so that another drive or directory is used as you can with screenshots.) For Wrye Mash (at this time) the BAIN installers directory is found at the top directory of the game ... Morrowind\installers.
When adding a BAIN friendly archive (called packages once installed) place it in this added directory in the folder called 'Bash Installers'. At each opening of the Installers tab this folder is scanned each package is compared to each other package to the contents of the data folder. The purpose of this is to inform you of changes to what was installed (including if files were altered or missing).
The method by which this is done is called a cyclic redundancy check. If this check fails then the tab will be blank. A frequent cause of this is moving archives in and out of the bash installers folder while the check is happening, so make sure to add or remove all packages you want to be included in the scan prior to opening or refreshing the the installers tab. If there is another cause for this then please direct the question to the latest Wrye Bash thread and the developers overseeing the latest version.
7.2.2 - Navigating the Installers Tab
Firstly read over the Installer Tab readme from the Wrye Bash readme (the Readme is always more up to date than this one).
Upon opening the tab one is confronted with 5 panels. Along the entire left side is the package list that looks much like a load order launcher app. If the scan was successful it will contain all the archives added to the Bash Installers folder. Here they are called packages and each has a column describing install order and date modified. The Modified date is of little importance (although it can be informative for telling you when a package was created). the Install Order column though is very helpful in managing your BAIN packages and automating the install order.
Much was made previous to BAIN about the importance of install orders and what mods and their attendant replacers should be installed before (or after) any number of other mods. These concerns are no as of longer of great import with the inherent functionality of BAIN. The install order can now be adjusted without necessarily uninstalling or reinstalling as the management of all files will be handled by BAIN.
Key functions of the installers tab are found with the info-tabs (sub-tabs to the main tab which is the installers tab) that are found at upper right side of the installers tab these include:
Quote
• General info-tab: The ability to view the contents of a package prior to installing.
• Matched info-tab: The ability to see what in the packages matches what is already installed in the data folder. If two files share the same name but different sizes then that is not a match.
• Missing info-tab: The ability to view if anything that was installed from the package has since gone missing.
• Mismatched info-tab: will tell you if any files with the same name are actually different in other ways.
• Conflicts info-tab: will tell you what other packages are either overwriting the contents of the current package or what packages the current package is overwriting. This is reflected in the designation of higher and lower. If conflicting with manual or OBMM installation then no info is given here, but most likely is given in the other sub-tabs. This tab provides a meaningful conflict detector for replacers that can give valuable information about what your install order should be.
• Underridden info-tab: Shows packages which should be overridden, but are not, due to install order errors. This will often give reports after the install order of packages is changed.
• Skipped info-tab: will tell you what was not installed. This is likely because it is a file or directory type that is not recognized by BAIN.
The next two panels are located below these sub-tabs and are content filters:
Quote
• A filter for sub-packages: Shows which of the sub-packages are installed (explained later).
• A filter for esm/esp: Shows which of the esm or esp are installed and the area where you also decide which (if any) of the plugins or master files you want installed.
The final pane is a comments pane and it allows you to input comments about each package. Contrary to hopeful thinking it does not present the readme for the package. You ca, however, copy and paste a readme or two into this pane. I use it to write myself little notes like 'Load this package after package so and so.'
The package list can be sorted with Wrye Bash by ctr+arrow keys the packages can also be sorted and new install orders can therefore be automated. This is a leap from what Oblivion Mod Manager offers. For example say you wish to make sure that a certain replacer set ( a clothing texture overhaul for example) was installed last. With each new mod you installed with OBMM you would have to check to make sure it did not overwrite any replacers the replacer set installed and if it did you would have to uninstall the entire replacer set an reinstall over the new mod. With BAIN you can simply move the package you want to win the conflict and adjust just those files with the anneal feature.
Many functions of the BAIN tab are accessed through what are known as context menus. You will notice in the packages panel there is a bar along the top that says obviously enough 'Packages.' Right click on this and a context menu will drop down. Much like with the mods tab you are more likely to find more global commands on the top bar while the context menu accessed through right clicking a package is more likely to be commands for only that package.
7.2.3 - Installing and Updating Packages
The packages are installed by right clicking the package to bring up the context menu and clicking install. This will install all the content from the package (or sub-packages you have filtered to install) including replacers, BSA, ESM and ESP files as well as readmes and other commonly found files used in Oblivion modding. You will find as you go on that there are certain files that BAIN will not install:
• It will not install exe or executable files.
• It will not install archives in a further embedded, zipped/compressed state.
• It will install Shaders but it will not merge and edit Shader files.
• It will install OBSE plugins But only after prompting you to approve this.
... These are areas where OBMM does outshine BAIN.
If you run across a file that BAIN seems to refuse to install or that you can see will place in a non-usual folder in the data directory (such as data\ini or data\streamline) then with the context menu make sure to check Has Extra Directories if this does not work and the file is not of the non-supported variety above then report that in the latest Wrye Bash thread.
As you learn more about package management and adjust the install order of packages you may notice the package names turning different colors. This is mean to notify you that overwrites and underwrites are happening. Usually you can read the info-tabs for more information. The likely cause is that you have:
• Moved another package lower in the load order which now wants to overide a file in the package in question.
• Installed an archive that similarly wants to overide a file in the package in question.
• Have moved the package in question to override another package and it has not yet installed the files it should be overriding.
• You have used another program to replace or remove the same files (at least by name) that the package in question wants to has installed.
• You have manually removed or replaced the files that the package in question has installed.
• Somehow the file installed has been altered (cleaning a mod can cause this).
The following is quoted directly from the Wrye Bash readme (where it is better illustrated) concerning package shapes, colors and general health:
Quote
Checkmarks
• Installed packages will be marked with a "+".
Icon Colors
Icon colors indicate the degree to which the package is synchronized with the Oblivion\Data directory:
• Green: Package is fully synced. Note that a package can be green even if it is not "Active". E.g. if you have two identical packages and one is (fully) installed, then it will be green and checked. But the identical package will also be green - since it too is fully synced with the data directory.
• Red: Some files in the package are missing from the data directory.
• Orange: All package files are present in the data directory, but some esps/esms are not identical. (E.g. another package installed an alternative version of that file, or the user modified the file after installation.)
• Yellow: All package files are present in the data directory, but some resource files are not identical. (E.g. another package installed an alternative version of that file, or the user modified the file after installation.)
• White: This is relatively rare. It just means that the package is configured in a way that it has no files to install. This can happen for complex packages where none of the sub-packages are checked.
• Grey: This indicates that the package has a structure that Bain does not recognize, and so cannot install.
• Red X: The package is corrupt and/or incomplete. You'll likely see this for packages that you are currently downloading into the Installers directory.
Icon Shape
• Diamond: A project, i.e. a subdirectory in the Installers directory.
• Square: A mod package archive. Note that only rar, 7z and zip formats are supported.
Text Colors
• Blue: Indicates a package with sub-packages. The files to be installed, and thus the install state of the package will depend on which sub-packages you have activated.
• Grey: This indicates that the package has a structure that Bain does not recognize, and so, cannot install.
Text Background
• Orange: Indicates that the install is dirty. This will occur for packages for which the configuration has been altered (either by altering active sub-packages and esmps, or by altering the package itself). This can be repaired by running Anneal or Anneal All.
• Yellow: Indicates that the package has "underrides" i.e. some of its installed files should be overridden by higher order packages. This may happen after reordering mods that have already been installed. It can be repaired by running Anneal or Anneal All.
• Grey: Indicates that some files present in the package will not be installed. This is usually due to a complex structure that is only partially handled by Bain, but can also be due to having files that Bain refuses to install (exe's, dlls, sub-archives, etc.)
Annealing is a method whereby you can auto-correct the errors reported in the above described package colors and sub-tabs. Using it will take out conflict losers and replace them with the winners. It will replace files that have been removed by other methods (such as OBMM use or manual alterations. It will also replace files that it determines are different than the one installed. This includes cleaned plugins (which is why I recommend cleaning prior to installing with BAIN as covered below). You can anneal individual packages or using the context menu off of the top packages bar set the installers tab to auto anneal when changes are made. This will work only for files installed via the packages and will not take into account files installed via OBMM or manual. You can also do group anneal of all packages installed
Exercise caution and take notes if using OBMM and BAIN together! For instance if you do want to install a mod via OBMM and the result is that it makes a package turn red because it overwrote the files installed by a package then please remember that annealing that package will remove or change back what OBMM installed. Also my own experience is that setting to auto-anneal is a great option to have set all the time. It will auto-adjust files as you juggle package load order and sub-package options. it will not handle the manual changes or if OBMM is overwriting (but anneal all will).
After you install a package then please keep in mind that you still have to manage the install order of any plugins (including bashing patch and other mod tab functions). If one were to install their entire mod list with BAIN then the need to ever wash it all and install it all again is a thing of the past. With a few clicks you can install many mods or remove many mods and it will keep track of everything for you. No more hunting through directories looking for those obtusely named repalcers that you manually installed and thought was great but that now drag your performance down. No more trying to remember what the last OMOD you installed was. With BAIN it is all tracked for you and conflcits reports are given in dynamic, immediate, and user friendly format.
As for reinstalling your entire install. One can either pick to tackle changing each package over or do them all at once - it really doesn't matter because the more you transfer to BAIN the more it will provide better information about your install. Before getting into creating packages let's first examine how mods are packaged.
7.2.4 - Mod packaging
Most mods that one were to download today are packaged using an archiving program called 7zip it is free, versatile, and powerful. It can also handle other types of archives such as rar files, which are the runner up format for the most common archives you will download. I recommend grabbing that program for both extracting the archives you download and repackaging archives that you will make.
Protocols for packaging mods and the standards of how a mod should be installed vary greatly and it took me some time to make sense of all the variations. For a while it made no sense. It seemed that mod makers and packagers were all randomly just packaging material without rhyme or reason. Over some time I quickly recognized that there was a logic and this usually betrayed the point of view of the mod maker with regard to how they installed mods, their familiarity with installer programs, and their expectations of mod users.
Archives will remain after what is in them is extracted. Sometimes they are packaged in such a way as to easily be categorized as either 'installer friendly' or 'installer unfriendly.' By installer I mean the automated tools such as OBMM or BAIN. Being installer friendly means usually that the archive is packaged in such a way as to be almost immediately useable with OBMM or BAIN. Uninstaller friendly usually means that an installer program would not be able to automatically utilize the archive and therefore they must be repackaged in order to be used by these installer programs.
The installer friendly format is one that contains a directory (or file) tree that matches the directory tree of your game installation. Here is the file tree of my game installation:
Games\Oblivion │ ├[Data] │ ├[Bash Patches] │ ├[DistantLOD] │ ├[Docs] │ ├[Extras] │ ├[Fonts] │ ├[ini] │ ├[INI Tweaks] │ ├[menus] │ ├[meshes] │ ├[Music] │ ├[OBSE] │ ├[Sound] │ ├[Streamline] │ ├[Textures] │ ├[trees] │ ├[Video] │ │ │ └[The ESM, ESP and BSA files] ├[lex] ├[Mopy] ├[obmm] ├[src] │ └[the main game directory where the .exe and other tools are often found]
This is from a heavily modded game so I reduced the list down to the essentials you will see if you have moderate amount of mods, OBSE, OBMM and Wrye Bash installed.
Having an archive that matches the file tree above means that once extracted at the appropriate directory (data) all the files then go where they are supposed to and the mod is installed. If there is no plugin then the installation is complete and if there is then arranging load order activating it is all that is left.
To do this an archive needs to be packaged at the level of the data folder and the first folders you should see (if there are replacers involved) is the folders directly under the data folder. Many mods are packaged this way and this is very handy for installing manually. This also is the ideal packaging needed for transforming packages into OMODs or direct plugging into BAIN. These are BAIN ready archives (also called BAIN friendly). Of note OBMM can recognize package archives one level higher at the game directory.
But many archives are not packaged like this. Older mods and even today many Morrowind mods generally are packaged in such a way as to necessitate unpackaging into a temporary folder then cutting and pasting files into the proper order. This is BAIN unfriendly. With regard to these patterns of packaging I think I've seen all variety. Examples include having all the optional esp in the main top directory of the archive while the replacers are tucked away in an obtusely named folder or screenshots galore in the main or top folder while the esp files are likewise tucked away in folder structures that could never match game directory (or common sense). Male body mods are the most obtuse and mod-user unfriendly packages. These often include the actual meshes and textures renamed in extra folder not even accessed by the plugins themselves or just left loose where the main replacers are also at.
So for the purpose of brevity your basic BAIN friendly archive should look like this when unzipped:
Mod of Awesomeness:
├[meshes] ├[Sound] ├[Textures] └[The ESM, ESP and BSA files]
This is also the basic structure of BAIN (and OMOD) packaging. This means the extracted material matches this pattern you are golden. You do not want the result to be that when you extract a package the first folder you see is 'data'. That may be acceptable for manual installing (or OBMM if the OMOD is scripted rightly to take that into account) but not ideal for use with this installer program. Further, it is worth checking all the lower order folders and directories for misplaced files. I've found meshes in texture folders, textures in the wrong texture folder, screenshots and other errata mixed in with the replacers. Usually it is best to double check. You will develop a quick eye for it.
7.2.5 - Repackaging Mods for BAIN
There are pros and cons to consider when it comes to whether or not to repackage. Usually people will become involved in repackaging simply because an archive is not BAIN friendly. There are other reasons for doing this:
• To make sure the readme is installed in a more organized manner and not swept into the docs folder generically named and unorganized. BAIN has a function where it will sweep the readme into the docs folder and if not called readme will add that extension to the title. This can be problematic if many readme files are simply named readme (many overwrites) and with many mods the docs folder could quickly be overfull with misnamed and uncategorized readme docs.
• You may want to perform basic edits on a plugin such as adjust the date to effect load order or complex edits or mergers with other plugins.
• You may want to combine archives into one archive and create what are called complex packages. This could include making available to install options in the main mod that are not normally installed such as alternate version esp. More will be expalined about this in the next post.
• You may want to clean the plugins.
• You may want to optimize the meshes. PyFFI Optimized offers the information you will need for that
• You may want to clean the plugins (highly recommended):
• For Morrowind there is testool - more info found here
• For Oblivion and Fallout 3 there is the same edit program created by Elminster called either tes4edit or FO3edit. Depending upon how you name the exe. The latest version found here.
Information on cleaning Oblivion or any plugin:
Please keep in mind that cleaning mods is a complex subject and that while these tutorials give very clear steps how to use TES4/FO3edit to automate cleaning it is also ideal to read the readme (and comments on the download site) and possibly bring the existence of dirty edits to the attention of the mod maker. Of course many mods are no longer supported. To be very brief do not clean the unofficial patches, overhauls, esp that have other esp as masters, or esm files. Even if you did run the automated program it may find bad edits (the dirt) but they may be intentional and needed. The best bet if your are not sure is to ask the mod maker or barring that ask on a forum release thread.
From my experience of cleaning 100s if not upwards of over a 1000 mods the most common dirty edits are cell and worldspace that result in moving things by accident and other common CS events like just deleting that tree, so as usual I find the most dirty mods are house and building additions, Landscape (other than UL mods ... ), and quest mods.
The most recommended method for repackaging is to rezip or recompress the mods into new archives. One could also place them into simple file directories within the installers directory which would then be recognized as a project; however, doing this may result in the scanning that occurs skipping the project (simple file directory) and therefore missing any changes applied to that project. Waruddar has posted a more technical explanation. Projects are more ideal for mod making and or other editing projects but not for finished projects and or your own mod catalog.
There is also a rationale for not repackaging archives and that is that BAIN has a feature where if the archive were downloaded from TESNexus or TESAlliance and has the ending file designation (each file at these sights has a unique file extension) then using the archives context menu you have an option to open the download page from these sites in your web browser. This can be very handy when checking for updates to mods.
A workaround for this issue is to simply append those file numbers to the end of whatever custom BAIN package you make. The problem with this, however, is that you can only append one file extention number per package so complex archives with may mods would only get one. I tested this with my custom package of Castle Ravenpride and the package is named like this: CastleRavenpride-BAIN-11999.7z
7.2.6 - Mod management and your own mod catalog:
If you have collected even a moderate amount of mods you may find yourself confronted with a few choices. Do you keep the archives you downloaded after installing the mods either manually or with an installer? Do you back them up multiple times?
Why keep a mod archive even if it is not the archive you use to install the mod in the final analysis? Well there are a few reasons I do this. One being that you never know if a mod website like Nexus is going to go down (knock on wood that does not happen). Another reason being that more than a few times I've suddenly found that a modder had decided to pull their mods and these mods are therefore no longer available ... period. Other reasons could include:
• The length of time it takes to download may be so long that it is better to store them than wait for that again.
• The archives serve as source material and so if you make a mistake repackaging then you readily have the source to fall back on for reference and material.
Even these reasons are going to be mitigated by one overriding factor - disc space. If you have less space then active packages and mods are, of course, going to take precedence over archived and unused mods. Basically keeping archives is a sure way to at the most double the amount of space this project will take. External drives and other storage options are, of course, to be considered.
If one were to opt to repackage archives into another package then using 7zip (linked above) is the best option. A few things to consider with this option. Each update of a mod would mean unzipping the original, doing whatever is necessary like cleaning the plugins, repackaging the archive and then placing that archive in the installers directory.
At each step you would then decide things such as whether to save the original archive or delete it, or whether to copy and paste or cut and paste the new package into the installers directory. Doing things this way one could then have backups of not only the original archives but also the file directories of the new repackaged archives. A smarter move yet is to manage the repackaging and storage on a separate drive from the drive where the game and installers directory is located. In the unfortunate event of drive failure you would have a back up in one place or another.
This was the option I chose for my oblivion install and it consumed enormous amounts of disc space. I have another drive where it is filled with directories where the extracted and recombined archives are laid out ready to be rezipped. I often combine mods into complex packages so if one small esp is updated then I'd unzip it into a folder then rezip the entire package up and copy it to the installers directory. This has resulted in about 3 times the necessary space being used. I will cover best practices for updating packages that will explain how I have the directories backed up in post 5 below.
What follows are links I'd highly recommend reading if you are thinking of a complete reinstall and transition to BAIN:
Tomlong75210's helpful site TESCosi by Tomlong this site is growing with good information.
There is a section on BAIN Installation of Modded Oblivion that promises to be very helpful.
50_Steps To CTD (Almost) Free FCOM+++ Game (good advice even if not installing FCOM)
Windows Vista Performance Guide For those installing on a Windows7 or Vista Platform and have UAC concerns: The basic instructions are to install these games outside of default locations and thereby circumventing the need for elevated privileges.
The Oblivion Performance Project (some outdated information use with caution, but some gold too).
PyFFI and other optimizations and A new PyFFI tool by Ulrim.
For more information about mod conflicts please read this pinned thread: Compatibility and you
Examples that Wrye made to illustrate how to package mods in order to be BAIN friendly: [https://www.nexusmods.com/oblivion/mods/22170 | BAIN Mods]] and again in his BAIN for Wrye Mash thread he gives a lot of advice on best practices. The BAIN CS Wiki page was also largely written by Wrye.
The best advice managing install orders: Read the Readme!! Next, Use BOSS - both of these overlooked approaches can also give information on how to organize packages.
7.3 - Complex BAIN archives
Approaching the ability to make ... Custom BAIN Projects.
By now one should be familiar with the game directory pattern, how mods are often packaged and how to examine mod packaging, What installers do and in particular how the Wrye Bash installers tab operates. Spend some time getting familiar with these ideas and steps and before you know it you will be skipping over the first two posts annoyed by the noobish instructions in no time. This post is really what most of this thread was all about.
7.3.1 - Examining BAIN archives
BAIN has a feature that really expands upon what an installer does and what the currently available versions of OBMM cannot do. This is the ability to combine packages (of mods) together in novel combinations. With this feature one could then combine mods together in such a way as to make each addition an option that can be installed or not. Really the only thing limiting the combinations is that the packages are read in a hierarchical manner and one's own imagination about how to combine or break apart archives into sub-packages. Since BAIN (like OBMM) can read one layer further into a packages directory to find the recognized structure of the data directory one can then add other directories that have the similar structure.Taking our Mod of Awesomeness example above one could then assign an alpha-numeric prefix to each sub-package then as long as each new sub-package has such a prefix then it will be recognized by BAIN and the alpha-numeric ordering will then be the order by which these packages will be installed. The reason for Alpha-Numeric is explained by PacificMorrowind:
the reason is that in computers (at least generally and is certainly the standard in UIs) numbers are sorted before letters... same as underscores etc. (ie like in Windows Explorer defaults sort is <underbar and similar chars><digits><letters>)
So, with the lower numbers/letters being installed first (being higher in the install order) and the higher number/letters being installed last (being lower in the install order). This basically allows for micro install order options to be embedded in larger packages.
Mods of Awesomeness-BAIN ├[00 Mod of Awesomeness Core] │ ├[Docs] │ │ └[Quests] │ │ └MoA_Readme │ ├[Meshes] │ ├[Music] │ ├[Sound] │ ├[Textures] │ └Mod of Awesomeness.esm │ └Mod of Awesomeness.esp ├[10 Mod of Awesomeness Part 2] │ ├[Docs] │ │ └[Quests] │ │ └ MoA-2_Readme │ ├[Meshes] │ ├[Music] │ ├[Sound] │ ├[Textures] │ └Mod of Awesomeness part 2.esp
The adding of the BAIN suffix is not really necessary it is one method by which you can track what packages you create as opposed to the ones made by others or it can be used to signify that the package is BAIN ready. Notice I make further directories for the readme which makes them much easier to find. MoA part 2 could easily be an alternate version and so if the esp are named the same then the second loading version would win the conflict and if all the replacer meshes and textures are identical then there would be no need to package them twice and the second sub package could contain only what is different from the core package. These sub-packages will show up in the sub-packages filter and you then have them as options to install.
7.3.2 - Pros and cons of combining mods into complex archive packages
The advantages to this are numerous. The primary advantage that it provides is that you can reduce the amount of packages in the installers directory and this makes viewing and organizing then easier. Other advantages include:
• Combine similar mod archives together for central access.
• Combine related mod archives together for central access.
• Combine many disparate yet miniscule mods together instead of having your install order cluttered by packages as simple as a set of three replacers for repair hammers.
• Combine variations on mods in such a way that one could have the core aspects available and many other versions available with the ability to have immediate implementation.
• Combine whatever you like.
Disadvantages include:
• The sub-tabs that keep track of various installed yet separate packages will not read the differences between sub-packages of the same package. It will see all the data contained as one package. The good news is that when comparing to other packages it will only take into account what is installed from each package.
• It is up to the user to make sure that the packages are packed rightly and that they do not inherently conflict in a manner not intended or wanted.
• If updating any portion is necessary then rezipping/repackaging the entire package is also necessary.
• Perhaps forgetting what you packaged?
For myself the advantages far outweigh the disadvantages.
Taking a real world example of the available weather overhaul called All Natural (note it currently has a fix file available but usually not and it is closing to a more complete version one). Extracting the package we see that it is a complex BAIN package:
All Natural-18305.7z ├ -- Screenshots ├[00 Core] ├[01 Real Lights] ├[02 Bash Filter For Various Mods] ├[03 Nascosto Isles Weather Patch] ├[04 Kvatch Rebuilt Patch] ├[05 Oblivifall - Losing My Religion Patch] ├[06 MMM Patch] ├omod conversion data ├All Natural Readme.rtf ├Wizard.txt
Upon further examination we can see that the individual packages are laid out following commonly adopted rules of BAIN packaging. The mandatory files are in the 00 sub-package. The optional files are in subsequent packages. Also the authors have included extra content of a Wrye Bash filter for use in importing weather sounds to mod added interiors and patches for the mods Nascosto Isles and Kvatch Rebuilt. This is great as it cuts down on other packages just for those patches and extra content. Also of note is the fact that this mod is actually packaged as a triple compliant BAIN package - notice that there is a folder called omod conversion data. What this means is that the package is also ready to be converted into an OMOD for use with OBMM. This means that the OMOD script will seek out the data from the given folders for installing based upon the choices given in the OMOD installation. This is one of the very advanced BAIN ready mods available (and the best weather mod imo). Also note that the twoo hash marks in front of the screenshots folder mean that this sub-package folder will not even be seen by BAIN so you don't have to worry about your data folder being cluttered with screenshots on a mod you already decided was cool.
7.3.3 - Repackaging a complex archive example
Taking the above information and considerations we could do this ourselves with existing mods. To illustrate this I will share my repackaging of the quest mod Et in Arkay in Ego I repackaged the mod and combined it with various available patches like so:
Et in Arkay Ego-BAIN ├[00 Et in Arkay Ego Core] │ ├[Docs] │ │ └[Quests] │ │ └EiAmod V1-1_Readme │ ├[Meshes] │ ├[Music] │ ├[Sound] │ ├[Textures] │ └EiAmod.esp ├[10 Spiritus Version] - contains only the portions necessary for this au natural version │ ├[Docs] │ │ └[Quests] │ │ └EiAmod V1-1 (spiritus)_Readme │ ├[Meshes] │ ├[Textures] │ ├EiAmod.esp │ ├MaleBodyReplacerV3.esp │ └TFF_FantasyFigures_Base.esp ├[20 Shivering Isles Patch] │ ├[Docs] │ │ └[Quests] │ │ └EiAmod_ShiveringIsles_Readme │ └EiAmod_ShiveringIsles ├[25 Choices and Consequences Patch] │ ├[Docs] │ │ └[Quests] │ │ └EiAmod_ChoicesandConsequences_Readme │ └EiAmod_ChoicesandConsequences.esp ├[30 [EiA delayer] - this is an alternate delayer found here: https://www.nexusmods.com/oblivion/mods/25859 │ ├[Docs] │ │ └[Quests] │ │ └EiAmod_Knights_readme │ └EiAmod_Knights.esp ├[30 KotN Patch] - this original delays the mod till after the completion of KoN available only from authors. │ ├[Docs] │ │ └[Quests] │ │ └EiAmod_Knights_readme │ └EiAmod_Knights.esp ├[35 [TOTF Patch]: https://www.nexusmods.com/oblivion/mods/24624 │ ├[Docs] │ │ └[Quests] │ │ └EiA+TOTF Patch_readme │ └TOTF-EiAE Patch.esp ├[50 [UL Patches]: https://www.nexusmods.com/oblivion/mods/13834 │ ├[Docs] │ │ └[Unique Landscapes] │ │ └EtinArkay-UniqueLandscapes patches Readme │ ├EtInArkay-BravilBarrowfields patch.esp │ ├EtInArkay-CheydinhalFalls patch.esp │ └EtInArkay-ColovianHighlands patch.esp ├[50 UL Patches Merged] - made by myself using the above as sources. │ ├[Docs] │ │ └[Unique Landscapes] │ │ └EtinArkay-UniqueLandscapes patches Readme │ └EtInArkay-UniqueLandscapes Merged patch.esp
With this all in one package you will see several features. The core package number 00 to make sure it is always at the top contains all the main replacers needed. The next sub=package contains an esp that would overwrite the esp in the core sub-package if chosen. It also contains supplementary body replacer material for use with that version (although probably best to use other updated body replacers and only the esp here). The next two subpackages are available at the main download page and are to be used only if SI or C&C are also loaded. There are two numbered 30 sub-packages this is a method of saying that the choice is either/or and that one should not install both. The first one is part of another package of quest delayers made by statttis and the second one is (or was) available only by request from the authors. Since I would not want both installed they got the same number sub-package. The next package is another patch made by somebodys_kid for the mod Tears of the Fiend. The next sub-package is a the collected Unique Landscapes patches made by Vorians. And the final sub-package was a merger of the UL patches that is packaged with the other UL patches. It is likewise number the same as the UL patches to indicate that it should not be installed along with the normal UL patches. Notice also, as above, I took renaming the readme into my own hands and added further directories to the docs folder to better organize the ever growing library of readmes (you know ... those things we read after all else fails
This package therefore contains several examples of the benefits and some of the rules necessary for constructing complex BAIN packages/projects. Later in other posts I will illustrate much more elaborate combinations of mods.
You will find as you go on that there are certain files that BAIN will not install:
• It will not install exe files.
• It will not install archives in a further embedded, zipped/compressed state.
• It will not install or more importantly merge and manage Shader files.
... this is where OBMM performs very well.
If the package contains all the normal types of files that are found in 95% of all mods then there should be no issue as long as it is formatted appropriately. Sometimes, though, a package or mod will require a unique folder to be installed under the data directory folder and it will appear that BAIN is refusing to install it. this is most likely remedied though the installer context menu. Find the problem package and right click on it a context menu will appear and then choose the option 'has extra directories.' In most cases this should resolve the issue.
The context menu has other options as well. Please read the Wrye Bash readme (the most current version packaged with the latest Wrye Bash and accessed with ? button on bottom toolbar of Wrye Bash) for more information. Remember that each package has a context window and the top bar if the package window has a different bar with some global options available for further filtering and package control:
The single most important thing to learn is package colors which indicate the health and status of a package and thereby queue one to read the sub-tabs for more information. After adding and moving packages the most common command you will use is anneal to correct the install of various data files. Just moving packages around in the install order will not automatically remove or add data files one must use the anneal command for that to happen. There is a global auto-anneal feature on the top context menu, but I've still seen examples where it did not kick in and so recommend annealing individual packages anytime you see yellow, red, or orange. These colors may not go away as one package may override due to being at a lower position, but there may be parts that should still be annealed and can be annealed.
Read the Readme!! and Use BOSS - both of the overlooked approaches can also give information on how to organize packages and sub-packages.
7.4 - Managing Installer Packages
7.4.1 - Install Order
Install order is an important part of planning a modded game of Oblivion. Install order is different from what is commonly called load order because it deals with the entire mod including any replacer files (which could include meshes , textures, and sounds) or extra files (added meshes , textures, sounds, or any other number of files). Load order is about how the game reads the instructions from the esm and esp to run the game engine; whereas, install order is about what files are in place to be referenced by the game engine.
There are several factors to consider. Many mods may attempt to replace the same files or even add variants of the same extra file. It is important to remain aware of this and it is especially salient with meshes and textures as they can have a symbiotic relationship (certain meshes require certain textures). Another important variant of this is LandscapeLOD meshes and textures. Another common consideration is that there are often base replacers which you want in place but that are OK to overwrite by other replacers or the base replacers may contain more files while the other replacer only handles a few variants. From this then a logic about install orders has been promoted. Some of the mods though are considered essential (and that is often debatable as well), and some of the mods are considered elective.
This concern for maintaining install order integrity takes on varying levels of difficulty depending upon the method of installation. Basically better tools give better ease. With manual install it is you that will have to track everything. With OBMM then it is you who will have to track everything, but OBMM automates a lot of the work. BAIN offers dynamic, in the moment, conflict reports and the ability to move BAIN packages around in the install order much like esm and esp are shifted around in the load order.
If we look at BOSS master list we also see several categories categories for load ordering which I've reduced down to this more general list:
Earliest mods NPC face mods UOP & Vanilla fixes BSA tricks Overhauls I - Initial Fran's files for FCOM Loading Screen Alternatives Weather mods and overhauls Sound mods Lighting General Base Mods Map marker Tweaks Hotkeys DLC group Body replacers Items (armor and weapons) Body Replacer Armour & Clothing Horse Mods Overhauls - Main FCOM, WAC, TIE files. Tamriel Travellers Overhaul compatibility Post Overhaul Quests and Locations Unique Landscapes City overhauls Overrides Alternative starts Vampires Magic Alchemy Enchantment Thievery, Sneaking and Crime Guards and Bounty Combat Skills, Attributes and Leveling Pose and Animation Mods Semi-final overrides Beauty Packs Race Changes\Addons Companions Respawn & day length overrides Shader mods
Since mod makers often take into account this evolving load order logic, an argument could be made that often even the replacers they use would account for this as well. There are many many exceptions to this ordering and so again the best place to refer to is the readme of each mod, BOSS, and general advice given in threads.
From my own installers list I've culled a similar install order which I present as my general recommendation for install ordering (Remember though every rule has an exception).
DCL
Unofficial Patches
DarN
Sounds
World textures - expandable
Environments
Weather
Other replacers
Overhauls - much
Overhaul Overrides and Patches
Quests
Dungeons
Locations
Houses
Unique Landscapes
Provinces/LOD
Cities and villages
Roads and infrastructure
Races and Bodies
Companions
Magic
Stealth
Combat
Scaling and leveling
errata
newly acquired and testing mods
my own projects
====
Unused Mods
These lists are not meant to be exhaustive and really are used for determining load order of plugins rather than to be considered for install orders.
I'm certainly not as familiar with Morrowind and what may be the best install order, but plan to research than and will revise this post when I do. The same goes for Fallout3.
The organization of installed packages can itself become a necessity as the list continues to grow. The following are suggestions for bringing order to the installed packages via naming and other methods.
7.4.2 - Naming Conventions:
Even with combining replacers and mods into complex packages and mashing as many errata files into other archives power mod users are likely to have an installer tab that is filled with many mods that can become confusing to navigate. This is where naming conventions can come in handy.
The common suffix for BAIN packages is simply the -BAIN at the end of the package. Although not necessary it does serve the purpose of letting one know that the package in question is supposed to be BAIN ready. Prefixes for packages have not been more fully thought out and this is an area where more tags could be used to notify the user of information.
When a package is put in the installer directory and after BAIN scans the package the package is assigned a number that relates to its install order. Because of this there is more freedom in naming the packages than there is with naming the sub-packages of a complex package. Prefixes can therefore be used to further tag a package with information that relates to common install orders or types of packages. Some examples might include:
REPLACER-World Textures-QTPIII-BAIN REPLACER-Sky Textures Compilation-BAIN OVERHAUL-Warcry-BAIN OVERHAUL-MMM-BAIN DUNGEONS-Dungeon Compilation-BAIN DUNGEONS-David Brasher-BAIN QUESTS-Simyaz-BAIN QUESTS-Dragon Captions-BAIN HOMES-Castles-BAIN HOMES-Yevic Homes-BAIN NEW LANDS-Tamriel Heightmaps-BAIN NEW LANDS-Elsweyr-BAIN SETTINGS-Leveling and Skills-BAIN SETTINGS-Vanilla fixes-BAIN
These could also be abbreviated to one or two letters (I don't recommend numbers). And I'd think it not necessary to add them to every package as even a peppering of them would help the eye train in on what is essential. I've started using these tags with Fallout 3 and when peppered like that they are helping me see what is what faster. Spoiler of that installer list.
Another method is to create Markers to better organize the BAIN archive. They will show up as grey and look like the one that is automatically included named ==last== by doing this one could create dividers for the various packages along the lines of:
==Environment== ==Overhauls== ==Quests== ... and so on.
Using this as section headings you could create a very orderly looking BAIN archive that is easy to navigate and catalog. Sub-packages must be alpha-numeric in their naming in order to determine install order and override logic. Of course the conventions mentioned above do not have to be used. You could number every sub-package the same or different as long as the install order is as you want it and you know how to read it.
A few conventions have been promoted by myself and others:
• If two sub-packages have competing data and only one should be installed then often they are named or numbered the same.
• If mods are packed together and there are several main or core mods then the main mod often gets the numbering that starts a small series (i.e. 10) and each addition to it would complete that series (i.e. 11, 12 ... 16, 17, etc). With the next main mod starting the next series (i.e. 20).
• The core of a mod that is essential is often packed at the lowest number (00 Core Mod).
• Recently the idea of seperating docs into an extra core core package has been promoted (00 Core Mod docs).
The numbering does not have to stop at 99 either. you could number packages 110 ... 120, 125 ... 130, 131,132 ... 140 or as high and complicated as you like. Just remember then that lower number must contain as many digits as the higher numbers so 3 digits would need leading zeroes.
Alphanumeric ordering can be useful too. If all the mods in a package compilation are of the same type or named similarly and/or there is no need for install ordering (between sub-packages) then there is no harm in them having the same prefix designation. Such as the following:
Companion - Baddy Companion - Eyja Companion - Neeshka or you could provide the mod authors name as a prefix if they have several of a type mods like Umpa - Pose Umpa - Martial Arts
Another method of bringing order to sub-packages is like the dummy archives above wherein one could create dummy sub-packages. One could make dummy esp (that should never be installed) or better yet rename a small texture into something that would never be accessed by a mod and place into an innocuous texture folder and it will install but not be used. (This is necessary as empty sub-packages will not appear as options in the sub-packages folder.) examples may include:
100 ==Animation mods== 110 Animation Mod A 120 Animation Mod B, etc 200 ==Idle mods== 210 Idles Mod A 220 Idles Mod B 300 ==Pose Mods== 310 Pose Mod A 320 Pose Mod B ... and so on.
Also using leading dashes '-' will work the same as the equal '=' sign.
7.4.3 - Updating best practices:
The most important thing to remember is: Renaming packages means reinstalling it. Sad but true. Unfortunately if in updating a package you misname it or name it differently than what is currently installed then to BAIN it is a new package. You will have to install the package again which may mean reordering plugins and other annoyances.
One method of avoiding this mistake is possible - if you have the disc space for it - is to keep your mod catalog as a directory (preferably on another drive) with all the sub-packages prenamed, organized and ready to be zipped again at any time. What this, in essence, means is having two catalogs - one in the installers directory full of archives (packages) and the other in another directory unzipped yet containing both the downloaded original archives and the unzipped and organized archives. a lot, I know. Really it all about how much you want to get involved in this. External drives and other back up media could be very useful (but not burning one-off kind)
When using 7zip to create an archive you will find that by selecting folders to include as sub-packages to an archive that 7zip will automatically name the archive after whatever the directory is one level above the folders selected if they are all from the same directory (you of course can change the name). So if you name that upper/top directory after the name of the future package then that future package is automatically named for you.
Here is the protocol I use for updating:
• Download your updated or original archive you want to include in an package compilation.
• Extract the mod from a downloaded archive into a directory that is laid out like the future sub-packages under the directory named as the archive you want to create (or recreate).
• Remove the downloaded archive and either store it or delete it.
• Do the maintenance required (clean esp, redate esp, edit esp, optimize meshes, rename readme, etc).
• Using 7zip select all the directories you want as sub-packages and click add (green plus sign).
create the archive and it will be named the same as the top directory.
What I do is also have another folder under each package directory called _source_ it contains the original archives (that I save). I've made enough mistakes in packaging that I've learned to save most things because I do not want to re-download repeatedly. the underscore is just a visual clue for me not to include it in the final product.
So here is the Et in Arkay-BAIN directory prior to archiving and installing:
Mod Catalog\Custom Bain Projects\quests\Et in Arkay Ego-BAIN │ ├[00 Et in Arkay Ego Core] ├[10 Spiritus Version] ├[20 Shivering Isles Patch] ├[25 Choices and Consequences Patch] ├[30 EiA Patch] ├[30 KotN Patch] ├[35 TOTF Patch] ├[50 UL Patch] ├[50 UL Patches Merged] ├___Source <- this folder contains the original archives - not included when zipping. └ Et in Arkay Ego-BAIN.7z <- the final package to be placed in the installers folder.
Notice the directories above ending in the folder named like the archive created. I keep the extacted folders categorized and cataloged for convenience. Again I admit this is costly to disk space so use your discretion about what is best.
Another tip for speeding up both the compression process and speed up the scanning of new or updated packages is to use very light compression that is preferably non-solid. In the 7zip splash screen you will find Compression level (choose fastest) and further down Solid Block size (chose non-solid). This is again about a trade off as low compression means bigger packages and that means more disc space used. With less disc space you may need to choose high compression and that means a slower opening of the installers tab.
If you are updating a package that is named the same then prior to opening the installers tab remove the old package from the installers directory and replace with the new package (or overwrite). Then when the installers tab is opened it will scan and recognize the changes and give warning in the sub-tabs and in the colors of the packages. Simply make sure that all the options you want are chosen then right click on the package and click anneal. You may need to anneal other packages too and may further need to adjust load order of plugins or bash patch again or related activities.
If you are adding a package that has the same content as another package (such as BAIN ready mods being updated by the authors) and BAIN sees them as discreet and separate packages then it is best to move the newer package to prior to the older package in the install order, install the same options, then uninstall first and then delete the older and later install ordered package.
If you like the file trees I've been using and will continue to use in future posts and want to make them too the tool to use is called FileFolderTree which will create these trees after choosing a directory to scan. Surazal created a Word 2007 Macro enabled document that will take the readouts generated and further reduce them to give only the sub-packages listed provided the sub-packages use numeric and not alphanumeric naming. This is available here as a miscellaneous file.
Much thanks to Surazal for showing me this tool and creating the macro. A macro that you can import into Word 2007 is available in this post. Surazal also provided many suggestions utilized in this selection. And one step further he created a Word Macro Enabled document to update the BOSS master list with your own updates called BOSS Master List Manager (the main download).
7.5 - Creating Your Own Complex BAIN Packages
7.5.1 - Planning Your Mod Archive
After becoming familiar with BAIN packaging and repackaging you may want to give some consideration to how you will make BAIN ready the rest of your install and new mods that you come by.
Tomlong75210 provides a very persuasive argument that repackaging mods into complex packages is not ideal. As outlined above BAIN has the feature to open the download page of the mod if the package has the file extension that matches. That is great for checking for updates. Further there is the preference of sorting through simple packages in the installer tab rather than sub-packages through the sub-package filter. Doing this would render better conflict reports via the info-tabs. Tomlong's entire BAIN package (No updated Link) list illustrates how to organize such an enormous amount of packages.
To review the pros and cons I'd advise looking at what you want to accomplish. If you want to only use mods and delve into splitting replacers or doing cleaning and optimization of files and prefer easy access to Nexus and more comprehensive conflict reports then I'd advise Tomlong's method of keeping the packaging simple and originally named. If, on the other hand, you know how mods will conflict because you have reviewed that stuff to no end, you want to clean, optimize, break apart and/or combine salient mods together because you 'know' what you are doing then I'd recommend the very complex packages I will describe below.
Of course there is nothing preventing the use of both methods or the creation of your own. As I've learned more of Tomlong's method I would likely do it more that way if I were to reinstall all BAIN packages. That would take several weeks work to do and so not likely to happen. I see the advantages but believe that cleaning mods prior to packaging is the best option, even so in hindsight one could repackage as simple archives and append the file extension. Tomlong's package list comes out to 733 while mine comes out to 211 with each package containing further sub-packages. So whichever method you use (even both) is up to you.
7.5.2 - Rationale for Complex Custom Packages
Doubtless as one goes along in collecting and playing with mods there will come a point where they will want to combine mods in a variety of ways. This could be especially true when dealing with replacers like textures replacers and LOD. Often these two types of replacers can contribute greatly to performance lag and so many find that they have to test various different versions of a repalcer or remove aspects of a texture overhaul. Conversely others with a more powerful system may find that they can not only handle their favorite replacers but will want to add even more on top of those replacers. This will be trend as more powerful PC hardware is made available. This balancing act is part of creating a well modded Oblivion experience.
This section will deal with repackaging replacers into BAIN ready archives so that they are both broken down into component pieces and so that they could then be combined together with other replacers.There is no best practices for repackaging large, extravagant replacers but there are a few things to keep in mind. For one the conflict detection that BAIN offers between packages does not exist within packages and between sub-packages. So with this area of repackaging one will have to be much more conscious of what is being packaged and whether there are inherent conflicts. Doing this can take some time so that is something to consider.
The advantages to repackaging in this manner is really more about preference and control. Preference in that if you only liked certain aspects of a texture replacer, such as the clutter or architecture, and preferred the landscape and plant textures of another replacer set then breaking down the packages could be very worthwhile. Preference also in that this gives further ability to test performance and customize your install to fit the best performance models. Control in that if after building up what you think is a great combination and later find that maybe you need to tone down an aspect this provides a means of doing that be giving the option to remove certain portions.
There are a few different approaches to this. In my older thread I presented a model where I put Everything related to a texture overhaul in one giant archive This, however, has become very cumbersome and not an ideal approach. Primarily I wanted to see if I could do this and having done it the current size of that archive is 7 gigs. In fact so big that it is my intention to break this thing apart and start over. The internal structure though can provide a map for the individual packages.
When examining comprehensive texture replacers one may note that they cover many things from ground and road, to walls and ceilings ... from plants and trees to coins, cups, and furniture. These provide divisions in the texture replacer overhauls that we can use to create packages and sub-packages. When thinking about performance and due to the nature of the game it is easy to see that the game engine is not placed under as much stress when your character is in interiors as when outside and the game is rendering much more information. My own game has rarely ever crashed when my characters have been in interiors. this provides another reason and rationale for breaking apart texture replacer overhauls and packs.
So taking Qarls Texture Pack III into consideration here is a list of the main types of replacers it provides:
Architecture contains architecture folder, Qarl (Chorrol door?) and Wood (as it mostly was worked) textures. Clutter contains only clutter textures. Landscape contains landscape folder, Sky (only Snow), Plants (Butterflys?) textures Rocks Contain only those meshes and textures Dungeon Base contains Fort Ruins, Misc, Chargen (prisons) meshes and textures [I found no retextures of fort ruins?] Ayleid Ruins contains only those meshes and textures Caves Contain only those meshes and textures. Sewers contain only those meshes and textures.
With these divisions it is easy to see that Architecture and Clutter can be found in interiors and exteriors. While Landscape and Rocks are most often used in exteriors and the rest are various replacers mainly seen in interiors (their interiors). This is not an exact division. Cave textures of course will include the entrances that are in the exterior world as do Sewers and especially Ayleid Ruins, and dungeons (forts). This may concern some but having a forest full of hi resolution trees will have a much greater impact upon performance than one hi resolution fort exterior. I'm certain that these exteriors could be further separated out if one wanted to research what is the exact pieces that are in the exterior. Thematically mixing and matching of textures could also be a factor and although you may squeeze minimal performance out of doing this it may not look great. Again that is a matter of preference.
With the above type of replacers we could then start to create packages in any number of combinations including:
1. Repackage a specific replacer but have the various types of textures further sub-divided as sub-packages.
2. Create solitary replacer packages of both a type and brand (i.e. QTPIII Architecture only).
3. Create combination packages of a type with several brands (i.e Architecture from 5 texture packs each sub-divided into sub-packages).
With thought-out naming and numbering conventions one could even do all three at once.
Taking Architecture as an example for choice 1 above one could create sub-packages for a texture replacer out of each folder within the Architecture folder.
├[anvil]
│ └[anvilinterior]
├[arena]
├[basementsections]
├[bravil]
├[bruma]
│ ├[brumawallset]
│ └[interioronly]
├[castle]
│ ├[anvil]
│ └[cheydinhal]
├[castleinterior]
│ ├[narrowhalls]
│ └[towers]
├[cathedral]
├[cemetery]
├[cheydinhal]
│ └[interior]
├[chorrol]
│ └[interior]
├[daedricstatues]
├[doorstones]
├[farmhouse]
├[godstatues]
├[imperialcity]
│ ├[icbasementset]
│ └[icinterior]
├[leyawiin]
│ └[interior]
├[lowerclass]
│ └[lowinterior]
├[priory]
├[ships]
├[sidewalk]
├[skingrad]
├[statue]
│ ├[bravil]
│ └[kvatchstatue]
├[stonewall]
│ └[bravil]
└[tents]
This would be a very complex task especially if you were to then combine with other texture replacers so that only one option of each is installed. Option 1 above gives a lot of organization over a specific replacer set while Option 2 provides the most control with relation to other replacer sets. Option 3 probably has the main advantage of an economical replacer package in terms of managing your installers tab, but again using naming conventions could again make this redundant.
Of a cautionary note when having textures packs that may lay over the top (be lower in the install order) of other texture replaces it is important to note which versions may also have normal maps and or even meshes.
The main thing you want to avoid is having a texture replacer that also replaces meshes installing prior to a texture replacer that does not. The result could be that the meshes are looking for specific textures and those added by another replacer set may not be what is required even if named the same. The result could be graphic anomalies or performance issues. Of less of a concern is some textures have specific normal maps (texture add ons that give the appearance of a physical surface texture that provides more depth to the appearance of textures in game). More about understanding texture replacers at the Total Oblivion texture Overhaul (no optional link found except and it didn't help much) site.
The advice is to make sure to package meshes and normal maps with the textures that they support and then to make those textures reside in either/or decision tree sub-packages so that other textures are not accidentally mixed in.
7.5.3 - Examples of Very Complex Custom BAIN Packages:
These examples illustrate both the breaking apart of mods into component parts and the recombination of them with other mods that are also broken apart. The following examples of LOD and Sky Textures illustrate how one could mix and match component parts of mods with greater ease by having them repackages in this manner.
7.5.4 - LOD Compilation
This BAIN project combines most of the LOD variants available today. The package is divided up into five distinct sets of sub-packages or directories. The Core files are optional to use, Border regions are next, then the normal maps, color maps, and finally the optimized land meshes. Further the Shivering Isles maps are separated out for further customization. The purpose of this is to be able to have a BAIN archive that allows for easy switching between these mods in order to test mixing and matching, stability, and when what your looking at bores you. Most of these mods came as is and only cover the either normal or color maps. Zacherots, and Xerus had combined maps which I extracted and separated.
LOD Compilation-BAIN
│
├[00 LOD NormalMap Fix MipMap Fix ]
├[10 Border Regions Color -pk- 512 ]
├[10 Border Regions Color Blade -pk- 1024 ]
├[10 Border Regions Color Blade9722 2048 ]
├[10 Border Regions Color Shaja 2048 ]
├[20 Normal Maps -pk- 256 ]
├[20 Normal Maps -pk- 512]
├[20 Normal Maps CorePC Vibrant ]
├[20 Normal Maps Deathb0rn 512 ]
├[20 Normal Maps Deathb0rn Vanilla]
├[20 Normal Maps Qarl 1024 Reduced ]
├[20 Normal Maps Qarl 2048 Reduced]
├[20 Normal Maps Qarl 4096 Compressed ]
├[20 Normal Maps Qarl 512 Better Looking]
├[20 Normal Maps Qarl 512 Reduced]
├[20 Normal Maps Xerus 512 ]
├[21 SI Normal Maps Xerus 512 ]
├[25 Color Maps Main Landscape -pk- 1024 ]
├[25 Color Maps Main Landscape -pk- 2048]
├[25 Color Maps Main Landscape -pk- 4096]
├[25 Color Maps Main Landscape -pk- 512]
├[26 Color Maps Important Landscapes -pk- 1024]
├[26 Color Maps Important Landscapes -pk- 2048]
├[26 Color Maps Important Landscapes -pk- 4096]
├[26 Color Maps Important Landscapes -pk- 512]
├[27 Color Maps Less Important Landscapes -pk- 1024]
├[27 Color Maps Less Important Landscapes -pk- 2048]
├[27 Color Maps Less Important Landscapes -pk- 4096]
├[27 Color Maps Less Important Landscapes -pk- 512]
├[30 Color Maps Blade9722 2048 ]
├[30 Color Maps Blade9722 4096 ]
├[30 Color Maps CorePC 1024 ]
├[30 Color Maps CorePC 2048]
├[30 Color Maps Diverse Grasses 2048 ]
├[30 Color Maps Diverse Grasses 4096 ]
├[30 Color Maps Qarl Better Tiling 1024 ]
├[30 Color Maps Qarl Better Tiling 2048]
├[30 Color Maps Qarl Better Tiling 4096]
├[30 Color Maps Qarl Better Tiling 512]
├[30 Color Maps Shaja 2048 ]
├[30 Color Maps Xerus 1024 ]
├[30 Color Maps Zacherot 4096]
├[35 SI Color Maps CorePC 1024 ]
├[35 SI Color Maps CorePC 2048]
├[35 SI Color Maps Xerus 1024]
├[40 Noise Replacer - CorePC ]
├[40 Noise Replacer - HTF 1]
├[40 Noise Replacer - HTF 2]
├[40 Noise Replacer - HTF 3]
├[40 Noise Replacer - Koldorn Light ]
├[40 Noise Replacer - Koldorn Medium]
├[40 Noise Replacer - Koldorn Strong]
├[40 [[https://www.nexusmods.com/oblivion/mods/17300 | Noise Replacer - Xerus] ] Again if the terms are unfamiliar please read over the Texture Overhaul page for more information. This package zipped in a non solid format comes to about 1 gig in size.
7.5.5 - Sky Replacers Compilation
This compilation focuses on making the sun, moons, stars, and nebula more interesting. It falls short of Cosmic Sky Cycling because it does not cycle. But, then again one less thing running in the back ground. Actually I went through many of the images with Cosmic Night sky and only liked a handful. Many merely had nebula that invaded the entire sky and drowned out stars or mismatched very badly with existing star mods. Plus, there are many great crafted stars included below. Of the nasa images only nebula that was clear, not glaring, and meshed well with star packs got my inclusion.
Sky Climates-BAIN
│
├[00 Sky Core]
├[10 Sun - Beaming Sunglare]
├[10 Sun - Brumbeck Sky Pack]
├[10 Sun - Natural Environments]
├[10 Sun - Subtle Sunshine[/url]
├[10 Sun - Vibrant Sun]
├[20 Stars - Beautiful Stars]
├[20 Stars - Brumbeck Sky Pack]
├[20 Stars - Fire & Ice 2]
├[20 Stars - Fire & Ice 3 - version 1]
├[20 Stars - Fire & Ice 3 - version 2]
├[20 Stars - Natural Environments]
├[20 Stars - Vibrant Stars]
├[20 Stars - Wolfen]
├[21 Stars 0 - Beautiful Stars]
├[21 Stars 0 - Brumbeck Sky Pack]
├[21 Stars 0 - Fire & Ice 2]
├[21 Stars 0 - Fire & Ice 3 - version 1]
├[21 Stars 0 - Fire & Ice 3 - version 2]
├[21 Stars 0 - Natural Environments]
├[21 Stars 0 - Real Night Sky]
├[21 Stars 0 - Vibrant Stars]
├[21 Stars 0 - Wolfen]
├[22 Stars 1 - Beautiful Stars]
├[22 Stars 1 - Brumbeck Sky Pack]
├[22 Stars 1 - Fire & Ice 2]
├[22 Stars 1 - Fire & Ice 3 - version 1]
├[22 Stars 1 - Fire & Ice 3 - version 2]
├[22 Stars 1 - Natural Environments]
├[22 Stars 1 - Real Night Sky]
├[22 Stars 1 - Vibrant Stars]
├[23 Stars 2 - Beautiful Stars]
├[23 Stars 2 - Brumbeck Sky Pack]
├[23 Stars 2 - Fire & Ice 2]
├[23 Stars 2 - Fire & Ice 3 - version 1]
├[23 Stars 2 - Fire & Ice 3 - version 2]
├[23 Stars 2 - Natural Environments]
├[23 Stars 2 - Real Night Sky]
├[23 Stars 2 - Vibrant Stars]
├[30 Moons - Masser - ANB No Masser]
├[30 Moons - Masser - Better Nightsky 1]
├[30 Moons - Masser - Better Nightsky 2]
├[30 Moons - Masser - Better Nightsky Enhanced]
├[30 Moons - Masser - Brumbeck Sky Pack]
├[30 Moons - Masser - Dione]
├[30 Moons - Masser - Earth Image]
├[30 Moons - Masser - Far&Away3D]
├[30 Moons - Masser - Fire & Ice 2 - Blue]
├[30 Moons - Masser - Fire & Ice 2 - Green]
├[30 Moons - Masser - Fire & Ice 2 - Red]
├[30 Moons - Masser - Fire & Ice 3 - Dark Red]
├[30 Moons - Masser - Hi Rez]
├[30 Moons - Masser - Io]
├[30 Moons - Masser - Krensadas]
├[30 Moons - Masser - Loch Hi Rez]
├[30 Moons - Masser - Natural Environments]
├[30 Moons - Masser - Rhea]
├[40 Moons - Secunda - ANB Earth Moon]
├[40 Moons - Secunda - ANB Hunters Moon]
├[40 Moons - Secunda - Better Nightsky 1]
├[40 Moons - Secunda - Better Nightsky 2]
├[40 Moons - Secunda - Better Nightsky Enhanced]
├[40 Moons - Secunda - Brumbeck Sky Pack]
├[40 Moons - Secunda - Earth Moon Image]
├[40 Moons - Secunda - Europa]
├[40 Moons - Secunda - Far&Away3D]
├[40 Moons - Secunda - Fire & Ice 2]
├[40 Moons - Secunda - Ganymede]
├[40 Moons - Secunda - Krensadas]
├[40 Moons - Secunda - Loch Hi Rez]
├[40 Moons - Secunda - Natural Environments]
├[50 Nebula - Better NightSky Enhanced]
├[50 Nebula - Brombeck SkyPack]
├[50 Nebula - Celestial - Carina]
├[50 Nebula - Celestial - Horse Head]
├[50 Nebula - Cloud Nebula]
├[50 Nebula - Cloud Nebula with star flares]
├[50 Nebula - CSC AntennaeGalaxies]
├[50 Nebula - CSC Bubble]
├[50 Nebula - CSC HorseHeadNGC3576]
├[50 Nebula - CSC Lagoon1]
├[50 Nebula - CSC LMCmosaic]
├[50 Nebula - CSC MilkyWayEarthView]
├[50 Nebula - CSC NGC 6188]
├[50 Nebula - CSC NGC1333 Reflection Nebula]
├[50 Nebula - CSC ngc2207collision]
├[50 Nebula - CSC NGC4526]
├[50 Nebula - CSC OrionNebula]
├[50 Nebula - CSC VeilNebula]
├[50 Nebula - Fire & Ice 2 - Blue]
├[50 Nebula - Fire & Ice 2 - Red]
├[50 Nebula - Fire & Ice 3 - version 1]
├[50 Nebula - Fire & Ice 3 - version 2]
├[50 Nebula - Fire & Ice 3 - version 3]
├[50 Nebula - Natural Environments]
├[50 Nebula - New Nebular 1 - High_2048x1024]
├[50 Nebula - New Nebular 1 - Ultra_4096x2048]
├[50 Nebula - New Nebular 2 High_2048x1024]
├[50 Nebula - New Nebular 2 Ultra_4096x2048]
├[50 Nebula - Real Night Sky]
├[50 Nebula CSC NGC 1365 Island Universe]
├[50 Nebula CSC NGC1333 Reflection Nebula] Sorry I'm not going to include links as it would be a mountain of work to get them all checked and in place. The old thread had a bunch of links, but it also only contained a lighter version of this. That said this package is only 90 mb that is really light considering the amount of diversity it gives to the game. Searching under the names sky, stars, moons, and sun and you will find them.
7.6 - BAIN Wizards, OMODS, and BAIN Conversion Files
Many familiar with Oblivion Mod Manager had lamented that BAIN lacked the ability to provide scripted installations of mods that OBMM provided. OBMM is able to modify the Oblivion ini, Mod ini files, rename plugins, arrange package contents and other related goodies that have made it so popular over the years.
In response developers of BAIN have been laboring to create scripted installs with BAIN packages. For a while the most one could have hoped for is what was called triple packaging which meant BAIN ready, OMOD scripted, and packaged for manual installation ease (if that makes sense).
But now BAIN scripted installs are here and they are called BAIN wizards. As this thread is mostly directed at mod users the inner workings of how to create BAIN wizards or edit them is beyond the scope of this thread (and my ability to describe). One of the main developers of Wrye Bash, Lojack, has his own thread for BAIN wizards. If you have questions about current wizards or feature requests that is the place to take them.
Metallicow has created WizBAIN a utility to help in the creation of BAIN wizards ... and other things? Forum Thread
Malonn is also collecting together BAIN wizard scripts and script ideas: BAIN Wizard Installation Project
I will say that I've been very impressed with the progress with this feature. There are several very well put together mods that make use of BAIN wizards and here is a list of some of the best:
Animated Windows Lighting system
Lush and Gaudy landscapes and Grass and Tree Mod
With Wrye Bash 292+ Archives that have a BAIN wizard will show up in the BAIN tab as having a magic wand superimposed over them. To begin the Wizard you right click on the package in question and scroll down to where it says wizard and click. This should prompt the wizard to start. At this point the wizard will prompt you for options based on your load order and preferences. It will not install the mod for you just help you choose what packages to install and you must then install the package as normal.
7.6.1 - BAIN Reading OMOD conversion files
Development on Wrye bash being able to read OMOD conversion files and therefore install OMODs (archives specifically for Oblivion Mod Manager) is happening! Stay tuned as this may be incorporated into the next version of bash (292)!
7.6.2 - BAIN conversion files
BAIN conversion files are encoded instructions one can create for use with Wrye Bash/BAIN that recombine already existing packages in new ways. These can be handy for making a set of instructions to combine several premade packages into a BAIN compilation.
There is a set of instructions on the Wrye Bash readme for both creation and use of them. What is required is that a user download the archives, add them to their installers directory. With this in mind then it does require quite a bit of work to get them operational with the advantage that one does not need to offer or upload the mods that are going to be combined (although links might help).
Waruddar writes:
The premade packages do not have to be BAIN friendly. In fact, the entire purpose of BCFs is to convert non-friendly packages into friendly packages in such a way that minimizes bandwidth and preserves author's rights.
Without them, there are only two ways to distribute converted non-friendly packages:
• Convert the package manually, and upload the entire BAIN friendly package. Get yelled at by authors who don't want people altering & spreading their work without permission. Possibly consume large amounts of bandwidth if the package is of any decent size (uploading a repackage of QTP3 for instance). End user only has to download one thing and install.
• Convert the package manually, and post instructions on what was done (typically a checklist or similar). Low bandwidth (typically a few kilobytes, more if images are used), no intrusion against author's rights. Time consuming to install since the end user has to do exactly the same things someone else already did. End user has to download the original package(s) and the instructions for the conversion (the checklist).
With BCFs, you have all the advantages of the checklist approach without the disadvantage:
• Convert the package manually, and upload the BCF. Low bandwidth (typically a few kilobytes), no intrusion against author's rights (the
BCF doesn't contain any of the authors original files). Quick to install; the end user can get exactly the same conversion in three mouse clicks. End user has to download the original package(s), and the instructions for the conversion (the BCF).
BCF's also have a couple extra advantages:
• The person who originally created the conversion can include custom BAIN readme's, patches, etc without a separate install file.
• The converted file has all the options set that the BCF author chose. Whether the converted package uses solid or non-solid compression, Has Extra Directories, Comments, selected sub-packages, etc can all be pre-filled in.
A BCF is really not that different from a checklist. The main difference is that the BCF is read and used by the computer, whereas a checklist has to be read by a human. What they do is allow one person to do the work that you mention (cleaning, checking file structures, pyffi'ing, etc), and then package that work for other people to use. All a BCF contains is a set of instructions on how to rearrange the files, the settings you used, and any files that the BCF author added or changed. The only thing the BCF automates is all the work you previously did.
Here is a quote from FrodoDarkLord about how to make BAIN Conversion Files:
Basically it works like this- if you want a compilation similar to my weapons archive, but don't want to or can't do all the moving around and rearranging and work that goes into it, the creator of the archive can release a BCF. You then download the BCF, the necessary archives, apply the BCF and remove the BCF and the source archives. You then have the desired complex package, without any remanining clutter or packages lying around your BAIN folder- yes, you do need to temporarily have the source archives in your BAIN folder. However, once you have applied the BCF, you can delete them. And since applying a BCF takes no more than a minute or so, you're not really messying up your BAIN folder.
If you want to create a BCF for a package that contains a cleaned esp, the cleaned esp is packed into the BCF- so you can do that as well. Of course, there's no real benefit for the author of the BCF- just for the user that would like to have a certain BAIN project (for example, one shown in this thread) but is intimidated by all the work necessary to get it right.
For example, I would, eventually, like to have a Darnified UI BAIN package like yours- however, I am lazy and if it means doing much more work than selecting the install options in the OMOD installer, I can't be bothered. So, if you, hypothetically, created a BCF for your Darnififed UI BAIN structure, I would download all the packages you used to create it, then apply the BCF and delete or move the source archives outside of the BAIN folder. I now have the Darnified UI archive without doing any work at all. Win for me, no gain for you- other than being able to easily share your BAIN archives without permission difficulties.
As far as creating the BCF goes, it works in much the same way that you apply one. You have an archive that you want to create a BCF for so you can share it with others (this is the "target archive") and you have the archives whose files went into the creation of that archive (the "source archives"). In Wrye Bash, you select all the source archives, select "Create Conversion", pick the target archive, and Wrye Bash does the rest. The BCF is now in your Bain Converters folder and you can upload it for the enjoyment of others. Again, if there are files in the target archive not present in the source archives (like a cleaned esp for example), Wrye Bash adds that file to the BCF, and when the BCF is applied by the end user, the file is drawn from the BCF archive instead of one of the source archives.
As another example, say you have a quest mods archive (that you created some time ago) that you would like to share with others. Clearly, it would be endless work to get permission to upload the archive (and many mod authors will be opposed to the idea, so you would have to remove those mods and your archive would be incomplete), not to mention it is a huge file. You've also cleaned all the esp's to make sure you have a completely stable game. You then create a BCF. You get together all of the original mod archives that the mod author created and put those in your Bash Installers folder. In Wrye Bash, you select these source archives, right click on them and select "Conversion", then "Create". Wrye Bash will ask you to select a target archive. This is your finished quest mods BAIN collection. You select it in the file browser and Wrye Bash creates your BCF. This will now contain several items. First is the information of what the BCF is trying to do, what its source archives are, what the target archive is supposed to look like, details about the packages in general etc. Since you also cleaned the esps though, and those files are missing from the source archives, these cleaned esps are also present in the BCF (which is just a regular 7-zip archive).
So you're pretty much done with the BCF now and can delete or remove the source archives from your BAIN folder and upload the BCF. Now, someone sees your compilation in this thread, and thinks to himself "Boy, this looks awesome, but darn, that is a helluva lot of work." So now he sees that you've created a BCF to make his life easier, and excitedly downloads your prepared BCF. He reads the readme, and downloads all the source archives - but omits one because he simply can't stand that mod. He dumps all these archives into his Bash Installers folder, puts the BCF in the Bain Converters folder and opens Wrye Bash. He selects all the source archives, right clicks and selects "Conversions" then "Apply" and finally the BCF he wants to apply. Wrye Bash asks him to name the new archive it is about to create, and then does its magic. It will copy the necessary files from the source archive to the new archive except for the missing one, which it simply omits, and then copy over the cleaned esps because those were not present in the source archives. The user now has the full BAIN archive, except for the one mod which he chose to omit. He can now remove the source archives from his Bash Installers folder, removing any unneeded clutter and install and play with the BAIN archive without having done any work.
1. Put the -BFC.7zip into your Bash Installers\Bain Converters folder.
2. Download all source archives
3. Select all source archives in BAIN, right click, "Conversions", "Apply", "Weapon Retextures-BCF"
4. Name your new archive
5. Wait
6. Install new archive
7. Play & Enjoy!
Unfortunately this file no longer is available.
Lojack has created a Nexus page of BAIN Conversion Files with plans to add more once completed.
XJDHDR has also created a Nexus page of Scripted BCFs for Wrye Bashs BAIN installer
I will be honest ... I do not see the value in this function and have only really encountered the above use of it. This could well be my own bias as I see BAIN as a tool for extending and assisting with manual installation and I do not see it as an automated tool that requires no thought by the user. This strikes me as an attempt to make BAIN more of an automated gizmo. What it will not do is the steps I consider necessary to installing mods which include:
• Cleaning plugins (very essential)
• Examining file structure for problems and conflicts
• Other things such as optimizing meshes and renaming readmes
For instance if one were to create a BCF of a popular quest mod that also required cleaning (like Et in Arkay described above). You would download the quest mod's original archive plus all the patches and body replacer information, use the BCF to create a more BAIN friendly and inclusive archive. Upon installing though you would still have a dirty plugin, so you would clean that. This would cause the mismatched sub-tab to show the esp as mismatched. You could ignore that but then if you decide to install a body replacer and it want to anneal out the body mod changes this mod provides then doing so would again give you the dirty plugin installed again.
I concede that for overhauls that do not need cleaning or pure replacers this could be useful. I recall Wrye stating that he included this feature but that he thought it more important to convince mod makers and packagers to just adapt BAIN from the onset to avoid yet more installation steps and problems.
I'm sorry if I sound unfair and I am willing to change my mind with the right argument ... Having looked at it I'm certain that I could whip together a packaged mod compilation faster than I could make a BCF of the same archives. Better yet I could, hopefully, write a passage teaching you how to do it faster too and also encourage more manual installer or modder mentality as well!
So please do not ask me to make any. I will refuse.
I will leave this post open to anyone willing to write a more fair and balanced assessment or expand upon the set of instructions given above.
7.7 - BAIN and Other Games
7.7.1 - Fallout3 and Fallout New Vegas
The Wrye Flash project (formally Gary Bash). Valda fully ported over Wrye Bash for the fallout games. He has been very conscientious about updating it and even incorporating bash tags particular to Fallout. As of this writing the latest version of Wrye Flash is based on the latest version of Wrye Bash (291). Valda has also contributed to helping squash Wrye Bash bugs. Wrye flash has the following salient features:
1. Is the a fully functional port of Wrye Bash (Usually based off of the latest version of Wrye Bash) to Fallout3.
2. Has complete functioning of BAIN tab.
3. Has working Bashed Patch functions that rival and (in my opinion) out-perform the merged list function of FO3edit.
Valda is actively supporting and updating this utility. So if, like me, you play both games please give him support.
latest Gary Bash thread as of this writing. If not active then use search.
As with Wrye Bash and OBMM - it would not be fair to not mention the competition. Kaburke continues to develop the Fallout Mod Manager and has incorporated several BAIN like features:
1. Meaningful Conflict reporting with data files that are also installed with FOMM or manually.
2. File Manager which allows for functions much like BAIN offers with regard to managing replacers. This addresses one of the main issues with Oblivion Mod Manager but is not implemented in OBMM (only FOMM).
3. Can be tasked to manage either Fallout3 or Fallout New Vegas or both.
Fallout Mod Manager Main Download
7.7.2 - Morrowind
Wrye Mash for Morrowind has been taken up by Yacoby and he has been slowly importing changes from bash to mash. he has also announced work on creating a core Wrye Bash code that would allow for more easy porting to new games (such as the upcoming Skyrim).
Wrye Mash Readme - Original Wrye Mash Readme
[https://www.nexusmods.com/morrowind/mods/27588 | Original Wrye Mash Download]]
For those that prefer the Mod Manager approach there is a decent port of it here: Morrowind Mod Manager
There are so many Morrowind Tutorials and mod use instructions pages. Here are only a few:
Mod Recommendations for New Players
Morrowind Mythic Mods has many tutorials for the utilities.
Gluby's Guide to a Modded Morrowind - great if new to Morrowind.
7.8 - Managing BAIN with Multiple Installs
7.8.1 - Wait did you say multiple installs?
Yes that is right - having multiple installs of Oblivion is now very possible. This is not a difficult issue with the earlier game of Morrowind, but has not been readily available in an automated format with Oblivion until recently. After Nehrim was released many found out that installing it meant messing up your Oblivion installation and that it was either one game or the other, but not both. Several fixes were tried to address this issue (Documented in this thread). Finally Gaticus came forward with a simple yet powerfull tool for managing multiple installs and it works with Fallout 3 as well.
7.8.2 - mTES4Manager
What mTES4Manager does is take control of all related folders used by Oblivion on most operating systems. For Vista/Win7 these folders are:
1. The Oblivion Directory - the main game folder
2. The Oblivion Save Game Directory - containing all the save games and the game ini file
3. The AppData folder - contains the Plugins.txt file that records your load order
What the program does is mark these folders and put an ini file in them. It then groups the folders together per installation (called clones). With the program you can create new clones from existing ones and switch the active clones as desired. With each switch the program will swap out the related folders and 'fool' the computer into thinking (anthropomorphically) that it is the same game. The result is that you could have drastically different installations going on each of the folders and switch them as often as you like. Oblivion can be a long game and if you want two more versions going or use Nehrim and Oblivion then it is easy to set up (but kind of a lot of work to maintain). I think this also provides a feature that mod makers would adore if they knew it better: You could have one virgin/modding game an another a testing/modded game.
mTES4Manager is available at Nexus. Several have asked me for tips in troubleshooting the tool. I've not solve all issues so here is my best (and good luck to you):
1. Make sure the original Oblivion Game is installed outside the domain of UAC. If it is not then Wrye Bash will likely already give you grief as it will engage UAC. Do not turn UAC off - just move the install(s) outside of the area it wants to protect.
2. Make sure when switching clones that the related folders are not open in windows explorer or being accessed by any open program such as OBMM or Wrye Bash.
3. You can remove a clone from its control by deleting the ini file it places in the clone. This makes trouble shooting less daunting and you could manually place back whichever clone you prefer if it stops working.
Serious problems should be reported in the mTES4Manager thread.
7.8.3 - Multiple Oblivion Manager
Mutliple Oblivion Manager Is an alternate and superior tool based off the shorcommings of mTES4Manager. It performs most of the same functions of mTES4Manager and It has an option to replicate the BAIN archive (Oblivion Mods folder). It cannot manage multiple fallout installs. The notes above apply as well to this tool.
A more advanced version is being slowely developed: MIMI - Multiple Install Manager Interface
I use MOM and recommended it.
7.8.4 - Managing Multiple installs and the problem of Wrye Bash
With each install then it is important to note that most of the tools and utilities of the game will remain local to the clone in question. OBMM, Tes4edit, OBSE ... all will stay with the clone they are installed for. You could then have different versions of these tools for each clone too (even different Construction Set versions).
Wrye Bash is the only tool that presents a problem. This is mainly due to how BAIN was crafted. When you first open the BAIN tab and have not adjusted the Bash.ini then Bash will generate a folder outside of the Oblivion game directory (right next to it) called Oblivion mods. Within this directory folder There should be a stucture that looks like this:
Oblivion Mods │ ├[Bash Installers] │ │ │ ├[Bash] contains the files converters.dat and installers.dat (records all BAIN settings and what is installed) │ │ │ └ The actual archive of mods (the BAIN archive) │ └[Bash Mod Data] contains the file table.dat (data about your mods, ini edits, etc.)
Since this directory is not within any of the three folders managed by mTES4Manager they are not local to the game clones and will not change when games clones are switched. This is very problematic as you may want specific mods and replacers for one clone but another set for another clone - as soon as you switch and open BAIN you will see a nightmare of various colors which makes the point of using BAIN pointless. (the game data files are not affected but the tracking of it by BAIN is once a new data folder is presented to it). There are two solutions to this each with their own merit.
Solution 1: Multiple BAIN Archives - available with Wrye Bash 291 or older
For both solutions one must use the bash.ini - which is made by taking the bash_default.ini and copying it then renaming to just bash.ini
This has been the main solution until very recently. It is not outdated, as it has advantages of its own. This makes use of a single bash.ini setting:
;--sOblivionMods is the Alternate root directory for installers, etc. ; It is strongly recommended that you do NOT put it anywhere under the ; Oblivion install directory itself, because Oblivion.exe will search through ; every directory under the install directory. ; This "directory thrashing" can then cause performance problems during gameplay. ; sOblivionMods is defined specifically to circumvent this bug by storing files elsewhere. sOblivionMods=..\Oblivion Mods
With this you can change the location of the OBlivion Mods directory and all it contains (including all BAIN archives). By moving this folder you can therefore create a different BAIN archive for each clone (install). So one install might have:
sOblivionMods=G:\Bethesda Games\BAIN Archives\Oblivion Main Mods
and another might have:
sOblivionMods=G:\Bethesda Games\BAIN Archives\Oblivion Alternate Mods
For Nehrim perhaps:
sOblivionMods=G:\Bethesda Games\BAIN Archives\SureAI mods
The benefit of this is that each BAIN archive is discreet and separate from each other. This could be advantageous for some and in some circumstances. Say you want to keep the BAIN mod archives separate as might be the case with Nehrim where they likely need translating to that game before they will work.
The advantages of this are:
• Each BAIN archive is unique and can be taylored to each install.
• If small the BAIN tab will open faster.
• Less clutter on the BAIN tab.
The disadvantages are:
• It multiplies the amount of hard drive space needed to have multiple BAIN archives
• Makes updating take longer as you will need to update BAIN packages in multiple locations.
• Not all BAIN packages available in all installs (initially)
Solution 2: One BAIN archive for Multiple Installs - Available to those who use Wrye Bash 292+
Thanks to Lojack two new ini options have been added:
;--sInstallersData is the directory containing data about which installers ; are installed by Wrye Bash. This is where 'Installers.dat' and 'Converters.dat' ; are stored. Only change this for advanced configuration, such as when using ; mTES4 Manager to manage multiple Oblivion installs. sInstallersData=..\Oblivion Mods\Bash Installers\Bash ;--sBashModData is the directory containing data about your mods, ini edits, etc. ; Only change this for advanced configuration, such as when using mTES4 Manager ; to manage multiple Oblivion installs. sBashModData=..\Oblivion Mods\Bash Mod Data
With these one can now move the locations of the data about the BAIN archive instead of the entire archive. The point would be to move these to locations that move with the clones (installs). For example here are versions that would work:
sInstallersData=F:\Bethesda Games\Oblivion\Mopy\BAIN sBashModData=F:\Bethesda Games\Oblivion\Mopy\BAIN
What this does is assigns the files to a new folder within the Mopy folder called BAIN (would need to create that folder). Then with each install these files could contain differing reads on the same BAIN archive.
The advantage are:
• Less Hard Drive space used up, as each installer only exists once on your harddrive. If you have 4 Oblivion installs, you could (potentially) have 4x the hard drive usage from BAIN. This is of course assuming that every package you have is in each Oblivion Mods folder.
• Easier updating. When a new version of, say OOO comes out, you only have to update the one BAIN folder, and each Wrye Bash instance sees the updated package. If you went with the 4 BAIN folders in the above example, you would have to copy the updated BAIN into each Oblivion Mods folder = 4x the work (potentially)
• And one that wasn't mentioned yet: Creating a new clone/image of Oblivion would need to make a copy of that Oblivion Mods folder. Depending on the size, this could take a while.
Disadvantages are:
• Updates to a BAIN package have the potential to screw up each Oblivion's install archive. Say Clocks of Cyrodiil comes out with an update. You download the BAIN, plop it into the shared Oblivion Mods folder, each Wrye Bash instance sees the updated package. But...this time you're unlucky. You managed to download a corrupted zip file this time, one that triggers a bug in Wrye Bash so you can no longer refresh the Installers Tab. Now each instance of Wrye Bash will have that problem until you remove the offending archive.
• Some of your Oblivion installs may not require many of all your installers. Say you have a very slimmed down clone, that only uses 10 out of 300 of your installers available. The refresh time of that instance of Wrye Bash still has to look at each of the 300 installers on startup. The refresh time for any "zipped" installers (7z, zip, rar) is very quick, so not too bad. Nothing like the data folder scan, where CRCs have to be calculated.
• Also, as we currently have no good way of hiding installers (the popup menu->Hide command just moves the installers, not viable for a multiple Oblivion, single BAIN setup). So you'll end up with 280 unused installers, probably sorted to the bottom of the screen. Not a huge deal, but it gets in the way.
One install might have QTPIII installed while another would have Vibrant Textures. The limit is your imagination and what is available. Each install would have its own install order to read from the BAIN archive and its own set of markers and so on. It takes some getting used to this as each install would then read alterations to BAIN packages. If you alter one BAIN package in the BAIN archive then all installs will see that change. This makes updating easier but tracking alternate packages more difficult. Warning this does not address hidden files or hidden save games. The location of these will be shared between the clones with this solution.
You can switch over to this kind of system easily. Just back up this data (highly recommended in case you miss a step) then move it with bash closed. Alter the ini to point to the new location of these files - then open the BAIN tab and check to make sure it worked.
At this point I use both a shared BAIN folder and game dependent BAIN folders. I have three installs that share the same archive and two other installs that have their own (one for mod testing/making the other is Nehrim).
7.8.5 - Other Methods and notes:
This method holds a lot of promise and is stable. With it you can set separate or shared BAIN archives for each instance/install of the game. Essentially an Oblivion.ini tweak. Change this line like so:
bUseMyGamesDirectory=0
Which then moves all the info about save games and what plugins are active to the local install folder.
The major drawback comes when using tools - specifically TES4Edit and TES4LODGEN. Both look in the AppData\Oblivion folder for the plugins.txt. Since infinite Oblivions moves this file to the local install directory these programs cannot find it and there is no mechanics for having them look for the correct files.
7.8.6 - Multiple Installs - One Wrye Bash
I'm not sure when this feature was implemented into Wrye Bash. It is a feature in at least version 295.3+. If one only installs the data folder from a wrye bash package into each install and then move the Mopy folder to somewhere else (outside of an install) then on starting the wrye bash launcher one will be prompted with a question of which game they want to manage (Oblivion or Skyrim).
This however really cannot work with multiple installs sharing the same BAIN archive or infinite Oblivions - so far. Perhaps with further ini settings or at least being able to locate the bash.ini in the local game directories this could then work for those cases too.
As it is this only manages things correctly if the BAIN archive location is in the default location. It will work with MOM if MOM is set to copy the BAIN archive and has. The only advantage I see to this is having to update only one Mopy folder with each update of bash. Until more options are implemented I will not consider this viable.
7.8.7 - Tip for starting a new install...
If you copy and paste over the Bash.ini and the Installers.dat, converters.dat, and table.dat to the new install you will find the installers tab already configured with all the installers in the order you had from the install you copied from markers and all. It will show all the packages that were installed in the other install as red - simply opt to uninstall all packages and you are good to go. Might be worth checking if other settings also got copied over or if you want them.
7.9 - An open letter appealing to the use of BAIN and Wrye Bash by mod makers
Having used BAIN since it was created I realize that I've become very used to using it. Not that I consider myself a Wrye Bash aficionado as there is much about the program I definitely do not know how to use. Part of my goal for writing this thread was to introduce the idea that BAIN really is not that complicated. I suspect that my style of writing may not have been conducive to this goal though as I prefer prose writing to technical writing. I picked up BAIN pretty quickly and have found that most people do as well. I wrote the first thread Custom BAIN Projects only two months after the program feature was implemented and only after 6 months of really getting into modding oblivion. My point being that BAIN is not really this arcane and needlessly difficult utility and is actually intuitively easy to pick up.
A few years ago mod cleaning was still pretty new and today it is now common practice by many modders to clean their mods prior to release. Mod packaging, however, has remained an area of mod making that has not taken advantage of the tools available.
While there are many mods that are BAIN ready they are only out of simplicity and default. I'm surprised at the number of new mods that are not BAIN ready and could very easily be made so. Mod packaging is intimately entwined with mod installation. They are two sides of the same coin. To create a mod then package it in such a way as to necessitate the user repackaging it just to use the mod is asking for needless problem reports and posts. In the few years of posting on these forums I've seen a connection between the number of problem reports and how mods are packaged. This is not to say that all problems will go away with BAIN friendly packaging and in some cases there will be those who do not like it. The reports I've seen for BAIN installation of are usually brief and are not ongoing drudgery of the same issues over and over again.
For simple packaging this will not matter as a simple BAIN ready package does not have multiple folders and sub-packages and looks indistinguishable. There are distinct advantages to releasing your mods BAIN ready and furthermore BAIN ready to the degree that it is a complex package. Doing this allows you to organize your mod in such a way that installation is also organized. This is especially true for mods that require the use of Wrye Bash and bashed patch, since that tool will be used anyway.
FCOM is such an example. It is the ultimate WIP for Oblivion. Some salient points being that while two of the four main components (MMM and FCOM patches) have been regularly updated and the readme for those have also been updated the other components remain in inconsistent packaging. This is compounded by the fact that the main readme has not been updated to keep pace with the FCOM patches available. The result is that the FCOM thread consists of many posts about installation questions. This could be remedied by better packaging and distribution of the material. While the rest of this open letter will address FCOM as an example please consider how your mod may be made more user friendly by adopting BAIN ready packaging.
7.9.1 - Reasons for utilizing BAIN:
• The current installers are a pain (exe for OOO and FRANS).
• The diversity of and conflicting instructions provided.
• A lack of coherent install method for all portions involved.
• Requirement to look elsewhere for OMOD scripts for many Mods.
• Current installation methods do not promote use of Wrye Bash.
• Begs for more installation problem reports.
7.9.2 - To summarize the advantages of using BAIN packaging for your mods:
• Promotes users thinking about modding and manual installation.
• BAIN makes manual installing easier.
• Any BAIN ready mod can also concurrently be made OMOD compatible via OMOD scripting.
• BAIN encourages further use and integration of Wrye Bash.
• Bain now has Wizards that provide for scripted installs.
BAIN is not necessarily more complicated and the mods that are BAIN ready do not have their relz threads filled with endless questions about how to install them - whereas the FCOM oriented mods that are at best offered in exe format or with a third party OMOD script are overflowing with questions about how to install. FCOM which depends upon Wrye Bash to even function that having them BAIN ready would be beneficial and have the users first introduction to the use of Wrye Bash be the installer tab and not the creation of a bashed patch. Further, nothing in FCOM relies upon an ini or is OBSE dependent so there is no need for OMODs to configure anything and when it comes down to it and really it is about choosing plugins and bashing the patch.
A big part of FCOM - the bashed patch (which is not a simple concept nor easy to pick up that well) is required and discussed in detail in the FCOM readme, but then it is recommended that one use a completely different installer utility for installing the mods than one that will use for making the bashed patch - when Wrye Bash can do it all. At times the message with FCOM is 'this is advanced and not for new users' but then when it comes to use with installers the more simple version is the recommended method. This seems strange.
Finally, why not? Is there a better installer everyone is waiting for? Certainly it is worth noting that BAIN is still under active development and support from multiple individuals unlike OBMM which is considered a finished and for the most part un-supported installer. Until the time that the above is addressed expect others to provide their own solutions - why wouldn't they? It has been a year now that BAIN has been available in its current form. People are using it, many mods are now best installed with it, and adapting it for FCOM's primary means of installation would end many questions and remove the need for third party instructions. Further now there are two newer resources to send a person to if they do not understand BAIN.
In conclusion I'd like to emphasize that I intend no bashing or flaming here. They are your mods, your creations. I'm merely attempting to get you to think about packaging as a tool to promote your product, make life easier, and reduce bug reports.
Thank you for reading and considering the above.
7.10 - Related Topics
7.10.1 - Why use a Bashed Patch?
This was originally a post I made in a thread debating which is better to use a bashed patch or merged patch (created by FO3edit) with Fallout 3. Since then I've cited that post to people asking me why use a bashed patch. So in order to make it simpler to access and possibly save from forum pruning I'm copying it here and editing it:
A bashed patch is a lot of things today. Originally it was a way of merging leveled lists. The issue being that multiple mods that alter or add to leveled lists and loaded into a more traditional load order would still be subject to the rule of one: that the last loaded mod would win the conflict.
So having mod A that has leveled list encounters added - say ancient snow yeti of 5 variety then have mod B loaded after that adds purple ants. With that scenario (and if I understand correctly - always willing to be corrected I am) then the Yeti might not appear as the lists with ants would override the mod A list.
To resolve that the tools for merging lists were created. With Morrowind I believe TESTool was implemented. With Oblivion Wrye Created Wrye Bash and it is still the most developed version of the Wrye tools. He then went back and created Wrye Mash for Morrowind. He announced that he would not create one for F3 as he planned not to play or mod it in favor of having a life (good for him). So it has been late in coming for F3. Elminster stepped up and implemented the most bare bones version in FO3edit called merged list plugin - which merged list doing the basic necessities so that lists do not block each other. It is cumbersome though by comparison to Wrye Bash and lacks many things that WB can do that no other program does.
Here I detail to the best of my limited ability things that Wrye/Gary Bash can do in addition to just merging leveled lists. I quote:
1. Merged Mods - if a mod is in the load order that only changes existing records (of either the main esm or even other esp) then that entire mod can be merged into the bashed patch. It can then be left deactivated. This greatly reduces the number of esp you need active and makes it so that you can have well beyond the 254 limit of mods. My oblivion install is near 380 esm/esp. This is also internally consistent in that the order in which mods are merged is also a the order in which records are over and under written. So like all the merged mods are merged and then even in that there are conflict winners and losers.
2. Bash tagging - with these tags (only viewable in Wrye/Gary Bash) you can tag a mod with specific tags so that the records indicated by these tags will carry forward and be merged/bashed patch winners even if they would normally be losers - this is great for when you need the merged mod to lose at some records but win at others. Another example of bash tag usage is that you could import records from a mod without ever even needing to activate or merge the mod. This is usually though for graphics mods like lighting or face data.
3. Game Settings. Again like tags this is an area of growth with each new update. With these then you can have game settings like crime detection, Bounties, Length of time essential NPCs are unconscious and many other settings become settable with each new bash. So if you set essential NPCs to become unconscious for 10 seconds and then after playing find that is too short rebash and set for a minute.
With Wrye Bash this is getting into some pretty arcane and cool things which is in turn out dating many other mods and thereby shrinking the the load order further. A well made and full bashed patch can almost constitute an overhaul in and of itself. I'd add to that even with all these settings bash will remember your last settings on each new bashed patch so that you don't start from scratch each time.
So with these extra abilities then merging mods like Project Beauty in with the overhauls gets much easier. Of course a person can record by record, edit by edit create a merged patch with whatever of whichever mod winning at each occurrence of conflict. It can get that detailed and you can go there with edit, but most people do not want to go there and so when it comes to doing basic merges bash provides more that can be merged, greater ability to adjust now things are merged, the ability to save mod slots and so on.
7.11 - Other Bethesda Game Interests of Mine
This led to my exploring how to run Nehrim and Oblivion at the same time and then how to mod Nehrim. This information is collected in the thread:
7.12 - Nehrim and Mods
How to install and manage mods with Nehrim
Problems and solutions for managing two installs
7.12.1 - Informative threads:
Nerhim is a total conversion of the Oblivion game that includes an entirely new world space, plot, quests and can basically be thought of as a new game. Since it is a modified version of the Oblivion game it uses most of the resources, models, meshes, textures, and so on from Oblivion. further, while many things about game play and mechanics have been altered there are still many areas that are not altered and play much like the vanilla Oblivion game. For some this is a call for mods. others may just want to mod the new facets of Nehrim. The purpose of this thread is to provide a forum for both how to add mods to Nehrim and use the mod tools with Nehrim, specifically the English version of Nehrim.
A few things first ... This is not the official Nehrim thread and is meant to give a forum for those who want to mod Nehrim so that they do not clutter the official thread with questions and requests. Please direct all questions about Nehrim that do not have to do with mods to the official Nehrim thread, which last I checked was locked but there is also their official forum a forum section of SureAI for the English version. It is no more complicated than signing up here.
This first post will be about the problems with using Mod managing tools with Nehrim, the second post will concern itself with how to port mods from oblivion to Nehrim, the third post will be describe mods that are Nehrim ready and other resources.
7.12.2 - Install Choices
The main choice with reading this thread is whether to set Nehrim up a a stand alone game that overrides Oblivion or as a parallel game that does not interfere with Oblivion. In other words if you want to mod Nehrim then first decide if you want both a Nehrim and Oblivion game playable - if yes then investigate the tool mTES4 Manager or Multiple Oblivion Manager.
(set it up first) If you don't and only want Nehrim then install Oblivion then immediately Install Nehrim. Doing this will clarify most things as you will see it will create a different install path.and data folder. If you later get nostalgic for Oblivion and want to play it again you can still use mTES4 Manager later - it is just easier to set all up prior to adding mods to either game.
7.12.3 - Nehrim Game Contents
If one follows the Nehrim installers recommendations and creates an entirely new game directory then the installer will extract the resources it needs from your Oblivion directory and copy them the new Nehrim directory. These include the Oblivion.exe and the BSA files, but not the Oblivion plugins (it uses none of them). Nehrim will then have its own directory and data folder that is separate from the oblivion directory and data folder. This means that mods can be added manually much like with Oblivion. This is the good news.
The not so great news is that the Nehrim game wants to use the same Oblivion.ini and the save game folder, and the same Plugins.txt file (found in %appdata%\Local\Oblivion\Plugins.txt) which tells the launcher or other mod manager what plugins are active) with Oblivion. This has been the central hitch to being able to run both games concurently. A primary reason for this is that the Nehrim Launcher (once you run the settings tab) will reformat the Oblivion.ini which can make issues for the normal Oblivion game just as using the normal Oblivion.ini will make issues for Nehrim. Likewise having both games share the same save game folder can lead to problems as the last save game has an interaction with the current mods active. Another issue is that Nehrim does not make use of the Oblivion.esm and so some utilities have issues with that esm missing.
More about these below, but first some basics that do work well. These first three topics for those not so concerned with consecutively running Oblivion and just want to mod Nehrim.
7.12.4 - Archive Invalidation
Nehrim makes use of a now antiquated method of applying its modifications with the use of an archive invalidation.txt that serves to tell the game which files are to overwrite the files included in the BSA archives. More about this can be found ( NEEDS LINK | here). If one just wanted to add replacement textures and meshes then a more universally useful way of being able to put the files in the Nehrim data folder and play is to use Archive Invalidation Invalidated. This is a BSA that redirects the engine to use loose files to overide BSA files. You simply put it in the data folder and then add it to the Oblivion.ini as per the readme. Wrye Bash has this as an option and OBMM also has this function integrated.
7.12.5 - Oblivion Mod Manager
This has been the premier mod manager for Oblivion and the good news is that installing this into the Nehrim folder as you would into the Oblvion folder will give you the Nehrim Mod Manager (well you might have to rename it yourself). It will not interact with the regular Oblivion Mod Manager and you can set it to store it OMODs in a different directory closer to your Nehrim Directory. It is not finicky with the Oblivion.esm missing and so it is the most friendly tool to port over to Nerhim. The only file that OBMM needs to run that is not in the Nehrim folder is the Oblivion>default.ini, which you can copy over to the Nehrim folder. Nehrim will not access this default ini so it will not disturb Nehrim. The one function I could not get to work was the launch the game function. OBMM also has a function similar to Archive Invalidation Invalidated called BSA redirection. If you use OBMM with this set you do not need Archive Invalidation Invalidated. Here is the extended version for more tools
7.12.6 - Oblivion Script Extender
Much like the mod manager OBSE can be installed as you would in the Oblivion directory. And likewise you can create a shorcut for the OBSE launcher called 'Nehrim' or whatever. The question then remains whether mods that use OBSE can be ported over to Nehrim. It is my belief that it mostly works with Nehrim.
Regarding OBSE and Nehrim
Here is a question I asked and the answer I recieved regarding OBSE and Nehrim.
Question
Some of us have been attempting to port OBSE mods over and focusing on mods that are scripted and therefore do not rely much on the Oblivion.esm. What we are noticing is that some features of these mods work and some do not. Some initialize and some do not.
I suppose one track could be to mod directly for nehrim but was wondering if perhaps it is something that could be handled with OBSE more directly. Perhaps there are entries that are needed from the Oblivion.esm or some other arcane thing I may not understand that is missing when trying to use OBSE with Nehrim. Maybe it needs a tweak or two so that these mods do initialize in this TC.
Answer
If OBSE is successfully loading and running the game then the .exe hasn't been modified. OBSE itself doesn't depend on anything in the .ini to the best of my knowledge. There may be a handful of commands that expect certain default objects to be present (I'm thinking things like Gold001, magic effects, skills, and game settings); if those objects are removed then some commands may fail to execute correctly. As you're probably finding, most mods are dependent on some of the data defined in Oblivion.esm as well, which will cause problems with or without OBSE.
Conclusion: Porting mods (described in the second post) that are primarly OBSE/Script driven and do not reference the Oblivion.esm are the best candidates. Mods that do reference entries in the Oblivion.esm may have certain functions that are not working or working properly.
The next set are more specifically about porting mods over to Nehrim
Can be used normally and you can direct it look anywhere on your computer you like for plugins. This is the best tool for reassigning masters (see post two).
The most current and up to date version of xEdit can be found here. Current discussion forum here.
There are two ways to use Tes4edit. You can leave it as it is working with the Oblivion directory and move Nehrim mods over to the Oblivion data directory for cleaning and examining, or you can change the directory it examines with Tes4Gecko as described here.
JdeRau
I've just figured out a bit of a hack to make TES4Edit work with Nehrim, the only problem being that you can't use TES4Edit to work with mods in Oblivion's and Nehrim's data directories at the same time.
First, you need TES4Gecko installed and working. Then again, if you're porting mods from Oblivion to Nehrim, you should probably already have it since TES4Gecko, IMHO, is the safest way of changing the master list of a plugin.
Next, open TES4Gecko then click on the button that says "Set Directory". You will then get the option of choosing a new data directory, navigate to Nehrim's "Data" folder and make that the new directory. Once that is done, TES4Edit should show you a list of mods in Nehrim's directory instead of Oblivion's. Once you are finished, open TES4Gecko again and change the Data folder back to Oblivion's one.
As described here the CS can work with Nehrim:
Many try to open the Nehrim Files with the TES-CS from the Oblivion-Directory. But this is false! The two files NehrimData.esp + Nehrim.esm are just placeholders with zero content. You have to proceed differently to modding Nehrim. You need these two files from your Oblivion-Directory (I'm assuming, that you have the latest "TES-CS_vers.1.2.404" installed): TESConstructionSet.exe ssce5432.dll Copy this into the Nehrim Directory: Nehrim\TESConstructionSet.exe Nehrim\ssce5432.dll Now you can modding Nehrim with the TESConstructionSet.exe from the Nehrim-Directory. Attention! The file NehrimData.esp should not to be loaded. It is not needed for modding and may later cause unnecessary troubles. Please only upload Nehrim.esm!
BOSS
BOSS version 2.3.0 is nerhim compatible and it will download the Nehrim Masterlist when you run the BOSS update. This masterlist is a separate list from Oblivion.
BOSS for Nehrim thread - please take questions and topics about BOSS and Nehrim to that thread.
If you receive an error downloading the master list you can review the solution Here. I was able to get it working just installing the quick fix from the windows site. Some people may need to make a registry key.
LOOT
LOOT v0.15.1 is nerhim compatible and it will download the Nehrim Masterlist when you run the BOSS update. This masterlist is a separate list from Oblivion.
The more complex issues
Here things become much more complex and if any section is going to be updated it is likely this one either because I got something wrong or there is an update. I'm not perfect and I do make mistakes and certainly this has stretched my understanding of the game, so just let me know what I did wrong.
To return to the issues above regarding Nehrim wanting to share the games folder under my documents. I've found that trying to load Oblivion with the Nehrim altered version of the Oblivion.ini or trying to load Nehrim with the normal Oblivion.ini that neither game will work. To resolve this manually I initially made temporary folders for each ini and swapped them out depending upon which game I was going to load.
Another issue is save game folder sharing. By default the save games are found in the oblivion folder under documents/my games/Oblivion (where the ini also is). if one does not use a save game manager or swap save folders manually the save games from each game will be in the same folder. Wrye Bash offers save game profile options to create multiple save game folders. If one does not want to use Wrye Bash then there are a few other save game managers. I use LazyMonk's The Simple Manager which can also handle Fallout 3 and can do more than just manage save profiles - it can list masters for saves and renumber saves.
In a sometimes hidden folder (located in %appdata%\Local\Oblivion\Plugins.txt) is the Plugins.txt - this is a list that the Oblivion launcher, Nehrim Launcher, Oblivion Mod Manager, or Wrye Bash reads as the active plugins. If one switches between utilities like the launchers to OBMM to the Nehrim ported Mod Manager and especially Wrye Bash then they will become (anthropomorphically) confused about what is loaded.
The manual work around I've been doing is to finish whatever I'm doing in Wrye Bash and close it or the normal Oblivion Mod Manager prior to opening the Nehrim ported Mod Manager. This way I can reactivate the mods for Nehrim and the normal utiities will not undo this process. If these are opened again then they will deactivate most of the nehrim plugins.
The INIzer is an OBSE plugin that ShadeME designed to address this issue. It can be used with either Oblivion or Nehrim to reassign the Oblivion.ini and the plugins.txt
With this then whenever you want to switch games you will just have to make sure you have the right save game profile as the active one and make sure that you close the utilities of the game you don't want to play first then open the utlilities of the game you do want to play to make sure all the plugins are active then launch that game. If you open the utilities of the other game (that you don't want to play) then it might override the settings and active plugins. This is completely unnecessary and unneeded if using mTS4 Manager.
Wrye Bash unfortunately is not designed to support multiple installs. It creates settings and folders in several locations and evn if you install it in the Nehrim directory it will impact the normal Wrye Bash settings and vice versa. It also requires the Oblivion.esm in the data folder to even start.
roxahris has been working with Pacific Morrowind and as of version 290+ Wrye Bash will work with Nehrim installed and does not need Oblivion.esm!! More work in this area may be forthcoming for having bash work with the Nehrim.esm.
The next big step:
mTES4 Manager - Old thread
or (don't use both)
From all the issues discussed here and for reasons of inspiration all his own fellow forum goer Gaticus has created the tool to manage all tools. With this tool one resolves all the issues with managing multiple installs on the same operating system. What this simple tool does is add small ini files to the Oblivion, game profile, and associated app data folder. From there one can then clone these folders with unique names and with a few clicks you will be switching entire game installs before you know it.
Warning: Unless you want to clone your entire modded game as it is - it is recommended that you clone a fresh install. The thread details how to do that.
It resolves all the above issues because with each swap there is a new Oblivon directory and associated folders. The caveate being that one would have to also install the modding tools and mods for each new clone. This means that even the INIzer is not needed.
The one area where there is issue is in the fact that the way that Wrye Bash is currently formatted the BAIN folder (bash installers) is shared between the clones when using Wrye Bash default settings. Using he Bash.ini one can repath this directory and for each bash have a seperate BAIN archive. This does eat a lot of disk space and the great news is that the Wrye Bash team is already working on removing this issue by having the location of what BAIN packages are installed stored within the game profiles folder.
I highly recommend the use of this tool which I've found very useful in testing tool and mods as well as now having three fully modded Oblivion games that I can swap between with ease.
Resources:
Unconfirmed links
Old Link SureAI English forum:http://sureai.de/forum/viewforum.php?f=81
Old Link a subforum for modding Nehrim:http://sureai.de/forum/viewforum.php?f=86
Confirmed it exists, but unsure if it's correct
Confirmed link
Nehrim Total Conversion - English Version
7.13 - Porting mods from Oblivion to Nehrim
Many mods are easy to port to Nehrim while others are cumbersome and will never work unless modified.
7.13.1 - Replacers:
Considering that Nehrim uses the Oblivion BSA archives most replacer files for Meshes, Textures, Sounds, etc that are meant to override these BSAs should work fine and it is just a matter of installing them in the right file path. I've not explored the Nehrim exclusive BSA archives but the process should be the same. If replacing the music then remember to back up the files as these are not in a BSA and replacing them will mean losing them. The same with menus.
There are reports of success in porting body mods such as Roberts and HGEC on the Sure AI forums.
7.13.2 - Plugins:
The best candidates for an easy port to Nehrim are Plugins that do not reference the Oblivion.esm. While most mods that have Oblivion.esm as a master that does not mean that this master is always necessary. The quickest way to see this is to open the plugin in tes4edit and look at what records are overwritten by the plugin. If no records are touched then the plugin has the master of Oblivion.esm in name only and that can be changed.
The easiest way to change the name of the master is to use tes4Gecko and edit the master reassigning the master to Nehrim.esm (I keep a copy of the Nehrim.esm in my Oblivion data folder just for this purpose and hide it with Wrye Bash before playing Oblivion). This could also be done with the Construction Set (but don't ask me how) and with Wrye Bash (but that may effect similarly named esp in the Oblivion data folder).
Some Plugins have no master and they should automatically work with Nehrim. These are often game mechanic and script driven plugins.
What will not work is plugins that reference the Oblivion.esm, as well as, other esm or esp not in the Nehrim data folder. So while you may be able to change the master over to Nehrim.esm the plugin will still need to reference entries in the Oblivion.esm and unable to do so could mean that those parts of the plugin will not work up to and including the plugin not working at all and even ctds.
Many esp minimally reference the Oblivion.esm and it may be possible that adjsuting scripts or pointing the plugin to reference something similar in the Nehrim.esm may work to port the plugin. If anyone wants to write tips on how to do that then let me know and I'll add it here or use the How to Make mods for Nehrim thread.
The following is a cut and paste of a post by Rylasasin regarding mod conversions:
A few notes i've found Shivering Isles compatibilty. Some mods will require shivering isles. Conversion of some (but not all) of these mods IS possible. But first you need to find out to what extent you use shivering isles. IF THE MOD ONLY USES SHIVERING ISLES MODELS/SOUNDS/TEXTURES AND NOT RECORDS: Here is the procedure to get those to work: Simply copy over the shivering isles bsa's (they start with DLCShiveringisles and end with .Bsa) as well as the DLCShiveringisles.esp over to your nehrim data folder. Using either wrye bash, TES4edit, or TESGecko (my preference for Nehrim dependance changing.), change the DLCShiveringisles.esp's reliance on Oblivion.esm to Nehrim.esm, and make sure you activate it in your Nehrim load list. That's it, nothing else needs to be done. Truthfully, the DLCShiveringisles.esp really doesn't do anything other than load the BSA files. It has no scripts, no quests, no records of any sort. Any Shivering Isles Records are actually loaded into the Oblivion.esm upon installing it. Though speaking of which: IF THE MOD IN QUESTION USES ANY SIMPLE RECORDS: (In other words: not shivering scripts, not shivering quests, not shivering exteriors or interiors. This includes but isn't limited to: NPCs (not refs), Weapons, armors, ingredients, statics etc.) This is a tad trickier. Obviously nehrim.esm does not have shivering isles records in it. So you will have to put these into the mod you wish to convert yourself. There are two ways you can do this and the choice is yours. First, you could use the TESCS to manually recreate the missing records. However, this is rather tedious. Secondly, you could open up Oblivion.esm and (insert mod here) in TES4edit (note: make sure if your running TES4edit in the oblivion folder to copy over nehrim.esm, or if in the nehrim data folder to copy over the oblivion.esm to your nehrim data folder). Make sure you've already changed the mod's reliance from Oblivion.esm to Nehrim.esm, and Find out which records you will need, and use TES4edit to copy them from the oblivion.esm directly into the mod you are trying to convert. Note that you want to Copy as new record, NOT copy as override. When it asks for prefexes and such, ignore it. If it says that the mod will have to add oblivion.esm as a master, don't worry, just go to the file header for the mod and get rid of the oblivion.esm entry. Also note you may have to do this for some normal oblivion mods too, especially ones that rely on records like "NPCHumangrunt" or other records that most oblivion modders take for granted. IF A MOD REQUIRES/MODIFIES AN OBLIVION/SHIVERING ISLES CELL Note by this I'm refering to something that significantly alters a shivering isles/oblivion exterior, such as a house mod, not for something simple like an armor or note found in (insert dungeon here). In the case of the former, this one is quite a bit tricker but it CAN be done. First and foremost, you must do this BEFORE you change the mod's esm reliance. 1.Open the mod in TESCS (yes, you're working with cells now, you can't use TES4Edit for this unless your really good with maths.) Create a new cell (interior, even if what your taking it from is an Exterior.) 2. Find the exterior[s] in question, and the objects in question (Example: lets say a mod that adds a shack to an island north of new sheoth... the object of interest here is the shack. Any vegitation or landscaping surrounding it is to be ignored.) 3. Cut and paste the objects in question from the exterior to your temporary cell you created. 4. Save your mod, close it in TESCS (your done with that for the moment) and open the mod in TES4edit. 5. Remove all vanilla cell/exterior overrides from the mod. DONT delete any custom interiors though (in other words, the interior of the shack.) 6. NOW change the reliance on oblivion.esm to Nehrim.esm (preferably using TES4edit since you should still have it open.) 7. Take note of any Shivering objects/missing oblivion objects the interior might have, and as with the simple records above, copy them over to your mod via the method described. 8. save and close the mod in TES4edit and reopen it in TESCS (we're doing cell/exterior editing again.) 9. Check both the temporary and interior cells of your mod to make sure everything shows up. if there are any missing meshs or objects, make note of what these are, open it in TES4edit again and go back to step 7. Otherwise, move on to the next step. 10. Find a suitable location in Nehrim to put your house (or whatever it is). 11. Cut and paste your house from the temporary interior to your chosen location. Note that you may need to do some landscaping/exterior decorating. Also check the exterior and interior doors to make sure they point to the right place. 11. Delete the temporary interior and save. you should be good to go now. with simpler things, such as putting a set of armor someplace where the player can pick it up, this step is FAR easier: You simply need to delete the cell overrides and manually use the CS to put it someplace else in nehrim. IF A MOD IS RELIANT ON CHANGING OBLIVION/SHIVERING SCRIPTS (ie integration the stranded light, choices and consequences, etc.) Forget it. It's not going to happen. OTHER OBLIVION/SHIVERING NOTES: scripts and editiorIDs One thing to remember is that Nehrim runs off the german oblivion.esm, which means german editiorIDS. for things like interiors and cells, this is self-correcting. For scripts however, it is not. This is EXACTLY why duke patricks won't work for example: a script in DP CA references the object "Apple", whereas in nehrim the object is "Afel" (the german word for apple). What I would recommend is if a mod has scripts, that you check them using the CS. Just use the arrow keys to skim through the scripts (most modders like to use a prefix for their scripts so it shouldn't be hard.) If a script asks you to save, it means something is wrong. Hit "yes" when this happens and it will give you an error telling you what is wrong (usually along the lines of "Error on line 123: Record "Apple" not found.") you will need to either fix this error or blank out the trouble spot if you can. It's usually either one of two things: 1. A record that is actually in nehrim, but the script doesn't reconize it cause it's looking for the english version of the editorID (example: if it references daedra hearts, the nehrim equivilent is "herz", or "Heart" in english.) Use TES4edit to find these equivilents. 2. A record in the oblivion.esm that isn't in nehrim at all (IE certain sounds... most common i found was NPCHUMANGRUNT or something like this.) in this case, follow the above procedure to manually insert that record into the mod. These are the observations I was able to make before my computer broke down, so now i'm getting it fixed, so I might not remember everything I learned 100%. Nevertheless, I hope this helps your Nehrim modding/converting adventures some.
and an idea:
In fact, I had an idea for a Nehrim modders resource someone could make if they're interested. (I would do this myself, but I'm still waiting for my PC to be fixed... if you do it though before I get to it at least give me credit for the idea) It's called the "Oblivion/Shivering Records Resource" WHAT IT DOES: essentially its a large collection of oblivion/Oblivion & Shivering isles (seperate mod for shivering isles mode) of all the non-overlapping simple records (IE ingredients, statics, NPCs, the three shivering races, etc. You might be able to get away with/have to add the generic dialogue quests as well, but none others.) so that nehrim modders don't need to copy these records over manually (as described above) WHAT IT WOULD DO: Give modders/converters access to the oblivion & shivering isles editor records that are not overlapping with nehrim.esm What qualifies: Ingredients that don't overlap (deadra hearts, apple, etc for example DONT qualify, since these are already in nehrim.esm under a different name.), statics, NPCS, misc objects, books, the three added shivering isles races (goldensaints, sheogorath, and darkseducer races), effects, sounds, spells/abilities, enchantments, etc. What does NOT qualify: complex records like cells, exteriors, quests, scripts, etc. Also I would personally stay away from Magic effects and birthsigns (though their ability effects are just fine to copy over), etc. classes are okay though if there's no overlap, they aren't used by the player anyway.) What it would NOT do: Give players a free copy of shivering isles (You still need the BSAs to make it work) give players a way to play both oblivion and nehrim at once. it only gives modders access to the simple records they'd need to convert/make their mods. anyone willing to make this idea happen? Like I said I'd be willing to do this myself, but for the moment my pc is being repaired.
7.13.3 - Resources:
Guide To Converting Oblivion-Mods to Nehrim
7.13.4 - Considerations:
As with Oblivion it is a good idea to add mods very slowly and to test each mod you add. It is also a good idea to know what you are changing, just because there is now a growing list is not a prescription to dump them all in and press play. This can be as involved as modding Oblivion and so take your time. I've only averaged one mod every 2-3 days. Some of the changes to Nehrim are subtle and are not easily seen it is a good idea to play a while to get a feel for what is new and what is plain old vanilla. My bias is that I played vanilla and so when I want a new game I don't want vanilla in a new world space, so I focus on changing those vanilla aspects that I find annoying and then add tweaks from there.
A lot of the most dramatic changes to game play can be seen in the character development area. Leveling is based on experience points and not skill ups, so most leveling mods will not work. Magic is also altered and rebalanced with a pretty dramatic pacing put in place regarding the way spells are attained. In short play the game then decide what you want to tackle, assuming you know what to change before checking if it already is changed could get you in trouble.
7.13.5 - Optimizations:
These optimization methods for Oblivion should port over just fine into Nehrim. Optimizing is often another form of modding.
The meshes that come with Nehrim are not optimized and really benefit from optimizing - as does the original meshes for Oblivion. The linked thread is a comprehensive guide to this process.
By having OBSE working for Nehrim this is easy to install and use.
Large Address Aware flag for the Oblivion.exe
I know this works with Nehrim because when Nehrim installed it pulled this version of the exe out of my Oblivion folder. This is for operating systems that can handle more memory.
Clean your mods
This may not matter for badly ported mods that still reference or duplicate the Oblivion.esm, but in exploring mods Nehrim I've found that there are edits that are duplicates and I've no doubt that as more dungeon and quest mods come out that deletions of the Nehrim.esm will come with them.
7.14 - Mods for Nehrim
This could potentially turn into a very long post and I make no commitments to long term tending to this list. I will start it though and update it sporadically as people post success and news.
I will borrow from Running4Covers list in using colors to code what kind of mod a plugin is.
• Green means the mod will work with Nehrim and was designed for Nehrim.
• Blue means the mod will work with Nehrim because it has no master and could work with Nehrim or Oblivion.
• Orange means that the mod will work with Nehrim after reassigning the master as described in post two.
At this point I'm not interested in posting about mods that only partially work or mostly don't work. Of course there may be parts of the orange listed mods above that don't fully work but the requirement I have is that they mostly work.
7.14.1 - Nehrim English fixes and Improvements:
Nehrim English Supplemental The most comprehensive Unofficial English translation update.
7.14.2 - Leveling:
Skill-Independent Attributes- a leveling mod for Nehrim.
NEEDS LINK | Intelligent Learning
Exponential Levelling Nehrim (version for use with Progress here)
SPAM is purported to work.
7.14.3 - Menu Management:
Nehrim Interface Extension - integrates the journal with the interface (will conflict with DarnUI)
DarUI will conflict with NIE above plus you will lose some of the cool things about Nehrim Menus and interface. I would imagine that a version that only effects inventory and other parts of menues and character sheet would be very popular - more so if combined with NIE.
7.14.4 - HUD:
Nehrim Experience Progress Bar
HUD status bars - may need a lot of work!!
7.14.5 - Hotkeys:
Enhanced Hotkeys - amazing mod, recommended
7.14.6 - Annoyance Removers:
Creature Idles - fixes creature animations when they get knocked down.
Initial Glow mods both armor and weapon and only armor variants
Nehrim Refractionless Chameleon
No Spiders - German mod but it shouldn't matter. There are a lot of spiders.
7.14.7 - Combat:
Nehrim Weapon Rebalance English Version
Deadly Reflex 5 replacement plugins
Attribute-based and skill-based damage modifiers
7.14.8 - Stealth:
Nehrim Sneak Fix - may be outdated with 1.0.8.0 patch.
7.14.9 - Companions:
7.14.10 - Immersion-Realism:
Basic Primary Needs -Nehrim- - Status compatible. Designed to work with Nehrim
Kuertee Inventory is a backpack - not 100% sure but reported that it works.
7.14.11 - Graphic Improvements:
Nehrim Landscape LOD Textures by Xerus - finally better land LOD.
Robert Male Body V5 for Nehrim
7.14.12 - Environments/Weather:
All Natural Nehrim by AN team.
7.14.13 - Homes:
Andrews Terminus System - both a home and new travel system more immersive than fast travel being activated.
7.14.14 - Other:
7.14.15 - OBSE Plugins that so far work:
7.14.16 - Replacers-Textures:
Evercharmer's Nehrim Mod list - a list of replacers recommended to work with Nehrim.
As far as replacers go this is an area that is large and I'm not going to link everything that can be replaced. You can figure it out. Body mods are generally good and realizing that the Aeterna use mystic Elves resources makes finding replacers for them easier.
(NEEDS LINK | Flora/Landscape retexture) - Vurt has relased landscape textures specifically with Nehrim in mind. Check back for more updates!
QTP3 Dark Cave Textures for Nehrim ... and see above the new LOD textures and also by Xerus Nehrim HiRes Palm Tree Retexture
7.14.17 - The Bashed Patch:
Very few of the settings in the bashed patch will work. But it can still be used for camera tweaks, and clothing tweaks for certain. Perhaps more - I've just not tested. You can also merge bashable mods with it. I've not seen anything level list related at all.
To use the bashed patch you want to first rename the master to Nehrim.esm then bash the patch and even though it is not referenced (that I can see) it will add Oblivion.esm as a master - delete that as all the tweaks will work on the Nehrim.esm.
And again great place to search for more is in the SureAI mod forum and Nexus