*********** Opening comments *************************************************
This thread is a Work In Progress!

Not only are the tutorials still being written but the formatting of the posts and their layout is in flux. You may see many organizational changes and new content if you revisit in a week or two.

If things look incomplete they probably are. If you see something that is a mistake please let me know by PM as I will be editing these opening posts several times and I'd rather not have to repost this every couple of weeks or have the thread full of grammar corrections. This editing of these posts may take a week or so. My eyes see things differently after posted and that will often mean I will edit several times.

In terms of formatting I'm currently making use of quote boxes to break up the walls of text. I'm trying to avoid color use when possible for those that have modded their browsers with different skins. Code and codebox do not seem to work like they used to so for it is quote boxes.
*************************** thanks for understanding.*****************************

================ TESIV:POSItive ===============================================
Fellow forum regular Tomlong75210 has been working diligently on an all inclusive website http://sites.google.com/site/oblivionpoinfo/ designed to illustrate how to mod oblivion and maintain a modded oblivion. Many subjects from the basics of modding, installation, optimization, troubleshooting, and a general knowledge pool of TES4 goodness. It promises to be far more comprehensive than anything I planned for this thread.

The section on BAIN installations may be easier to read and understand than what I write and heartily give that website and author kudos for taking on this task. Tomlong and I have different styles of writing. I'm not really a technical writer and generally prefer prose and explaining the why of everything while Tomlong appears to approach the subject from a more technical 'how to do every step' approach. I focus on arguments for and against while TESIV:POSItive is more about unbiased instruction. I would consider this thread what to read after that website or if you want to read more rationale and further uses of BAIN. The current project being developed by Tomlong75210 is an http://www.gamesas.com/index.php?/topic/1083993-in-depth-guide-for-installing-fcom-and-non-fcom-setups-with-bain/

I hope that if you are a forum regular and want to contribute to this knowledge pool that you consider giving Tomlong75210 a hand and support. Any material I write here may be used on TESIV:POSItive.
============================================================================

Table of Contents:

Mod Installing and Mod Management
Why this thread?
Mod Installation introduction
Why use a mod installer?
More links regarding installer tools
Recent Updates

http://www.gamesas.com/index.php?/topic/1084204-bain-mod-installation-projects/page__view__findpost__p__15797988
Bash Installer (BAIN) tab functions
Navigating the Installers Tab
Installing and Updating Packages
Mod Packaging
Repackaging Mods for BAIN
Mod management and your own mod catalog

http://www.gamesas.com/index.php?/topic/1084204-bain-mod-installation-projects/page__view__findpost__p__15797991

http://www.gamesas.com/index.php?/topic/1084204-bain-mod-installation-projects/page__view__findpost__p__15797993

http://www.gamesas.com/index.php?/topic/1084204-bain-mod-installation-projects/page__view__findpost__p__15797997
Install Order
Naming Conventions
Updating best practices

http://www.gamesas.com/index.php?/topic/1084204-bain-mod-installation-projects/page__view__findpost__p__15797999
Planning Your Mod Archive
Rationale for Complex Custom Packages
Examples of Very Complex Custom BAIN Packages

http://www.gamesas.com/index.php?/topic/1084204-bain-mod-installation-projects/page__view__findpost__p__15798004

http://www.gamesas.com/index.php?/topic/1084204-bain-mod-installation-projects/page__view__findpost__p__15798007

http://www.gamesas.com/index.php?/topic/1084204-bain-mod-installation-projects/page__view__findpost__p__15798012

http://www.gamesas.com/index.php?/topic/1084204-bain-mod-installation-projects/page__view__findpost__p__15798020

===============================================================

Mod Installing and Mod Management
A manual for the use of BAIN both for the beginner and the advanced user

Why this thread?

My http://www.gamesas.com/index.php?/topic/957424-custom-bain-projects/ on this subject created a year ago has now 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.

Mod Installation introduction

Modding games has been around for a while and I'm not really here to present a history of modding (although that would be interesting).
http://modhistory.fliggerty.com/ ... will add links as found.

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 http://www.gamesas.com/index.php?/topic/449239-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.

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 http://timeslip.users.sourceforge.net/ or OBMM for short. http://www.tesnexus.com/downloads/file.php?id=2097.

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 http://sourceforge.net/projects/fomm/files/ , 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 L0ki and Kaburke. Recent Thread found http://www.gamesas.com/index.php?/topic/1037768-relz-fallout-mod-manager/. And with OBMM scenttree is making additions with http://www.tesnexus.com/downloads/file.php?id=32277.

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:
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:
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:

http://www.uesp.net/wiki/Tes4Mod:Wrye_Bash/Bash_vs._OBMM

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 (mostly related to the OGE/OBGE mods), 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.

More links regarding installer tools:

http://www.tesnexus.com/downloads/file.php?id=22368
http://wryemusings.com/Wrye%20Bash.html
http://www.uesp.net/wiki/Tes4Mod:Wrye_Bash
http://cs.elderscrolls.com/constwiki/index.php/Wrye_Bash
http://cs.elderscrolls.com/constwiki/index.php/Bain
http://wryemusings.com/ Many Things Wrye ... including wrye views.
The latest http://www.gamesas.com/index.php?/topic/1081915-relz-wrye-bash/ 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!!

http://www.tesnexus.com/downloads/file.php?id=2097
http://www.tesnexus.com/downloads/file.php?id=32277 ** New improvements in graphic interface and presentation as well as scripting.
http://timeslip.users.sourceforge.net/
http://lhammonds.game-host.org/obmm/default.asp - this site contains a lot of information about archive management in general as well.
http://lhammonds.game-host.org/obmm/tutorial_create_omod.asp
http://cs.elderscrolls.com/constwiki/index.php/How_To_Create_an_OMOD

http://wryemusings.com/Wrye%20Mash.html
http://wryemusings.com/#WryeMash
Latest http://www.gamesas.com/index.php?/topic/1068986-wrye-mash-thread-%235/ as of this writing. Use search if not up to date.

http://www.tesnexus.com/downloads/file.php?id=26260
There are so many Morrowind Tutorials and mod use instructions pages. Here are only a few:
http://www.mwmythicmods.com/ -has many tutorials for the utilities.
http://www.mwmythicmods.com/Gluby/Gluby_Main.htm - great if new to Morrowind.

http://www.gamesas.com/index.php?/topic/449239-oblivion-mods-faq/
http://cs.elderscrolls.com/constwiki/index.php/Oblivion_Mods_FAQ
http://cs.elderscrolls.com/constwiki/index.php/Category:Glossary
http://cs.elderscrolls.com/constwiki/index.php/Category:Tools

Recent Updates!!!
Fallout Mod Manager has been updated to include the following features.
1. Load Order Report which accesses the http://www.fallout3nexus.com/downloads/file.php?id=10193 http://better-oblivion-sorting-software.googlecode.com/svn/FO3Masterlist/masterlist.txt for latest load order rules and option to utilize BOSS on load order.
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.
http://sourceforge.net/projects/fomm/files/
http://www.gamesas.com/index.php?/topic/1037768-relz-fallout-mod-manager/

The Gary Bash project (may soon be called Wrye Flash) by Valda:
1. Is the first fully functional port of Wrye Bash (based off of Wrye Bash 275 no less) to Fallout3.
2. Has complete functioning of BAIN tab.
3. Has working Bashed Patch functions that rival and will soon out-perform the merged list option of FO3edit.
Valda is actively supporting and updating this utility. So if, like me, you play both games please give him support.
http://fallout3nexus.com/downloads/file.php?id=11336
http://github.com/valda/garybash
http://www.gamesas.com/index.php?/topic/1079607-relz-garybash/ as of this writing. If not active then use search.

Pacific Morrowind announced that he will update Wrye Mash with many features of Wrye Bash that have since been developed. Stay tuned.

And thanks to the modders and utility developers that make playing and modding these games so much fun.

The Basics of BAIN and Mod Archiving

Bash Installer (BAIN) tab functions

to begin with most of what I'm writing is an elaboration of what is in the http://wryemusings.com/Wrye%20Bash.html (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 http://en.wikipedia.org/wiki/Crc32. 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.

Navigating the Installers Tab

Firstly read over the http://wryemusings.com/Wrye%20Bash.html#InstallersTab from the Wrye Bash readme.

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: The next two panels are located below these sub-tabs and are content filters: 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.

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 not install or more importantly merge and manage Shader files.
  
• It will not install OBSE plugins or other dll type files.

... Installing these types of files is where OBMM performs very well.

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 concerning package shapes, colors and general health:
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.

Mod packaging

Most mods that one were to download today are packaged using an archiving program called http://www.7-zip.org/ 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.

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: 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 ... :goodjob: ), 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 http://www.gamesas.com/index.php?/topic/1081915-relz-wrye-bash/page__view__findpost__p__15790564. 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

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 anolysis? 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 http://www.gamesas.com/index.php?/topic/1084204-bain-mod-installation-projects/page__view__findpost__p__15797997 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 http://sites.google.com/site/oblivionpoinfo/ this site is growing with good information.
Recently he has begun a section on http://sites.google.com/site/oblivionpoinfo/walkthroughs/bain-installation-of-modded-oblivion that promises to be very helpful.
http://www.uesp.net/wiki/Oblivion:Technical_Support
http://www.gamesas.com/index.php?/topic/1090232-50-steps-to-stable-fcom/ (good advice even if not installing FCOM)
http://www.gamesas.com/?showtopic=762701&hl= 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.
http://www.gamesas.com/index.php?/topic/881204-the-oblivion-performance-project-topp/ (some outdated information use with caution, but some gold too).
http://www.gamesas.com/index.php?/topic/1064823-pyffi-optimized-thread-2/page__view__findpost__p__15469849

For more information about mod conflicts please read this pinned thread: http://www.gamesas.com/index.php?/topic/775917-compatibility-and-you/
The http://www.gamesas.com/index.php?/topic/1079933-50-steps-to-ctd-almost-free-fcom-game/page__view__findpost__p__15725150 of 50 steps provides a basic install order for FCOM and other popular and common mods some thinking about this could provide information about how packages should be ordered. This will be covered much more in later posts.

Examples that Wrye made to illustrate how to package mods in order to be BAIN friendly: http://www.tesnexus.com/downloads/file.php?id=22170 and again in his http://www.gamesas.com/index.php?/topic/952489-relz-bain-for-mash/ he gives a lot of advice on best practices. The http://cs.elderscrolls.com/constwiki/index.php/Bain 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.

This post will be updated further.

Complex BAIN archives
or ... 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 http://www.gamesas.com/index.php?/topic/957424-custom-bain-projects/ was all about.

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.

so 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:
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. The advantages to this are numerous. The main 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 http://www.tesnexus.com/downloads/file.php?id=18305 (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_0.9.9   ├[00 Core]   ├[01 Real Lights]   ├[02 Atmospheric Weather System]   ├[02 Enhanced Weather]   ├[02 EW + AWS]   ├[02 EW + NW]   ├[02 EW + NW + AWS]   ├[02 Natural Weather]   ├[02 NW + AWS]   ├[03 Bash Filter For Various Mods]   ├[04 Nascosto Isles Weather Patch]   ├[05 Kvatch Rebuilt Patch]   └[omod conversion data]

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 weather versions are in packages numbered the same (02) to indicate that only one is to be chosen. 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 http://cs.elderscrolls.com/constwiki/index.php/Bain#Triple_.28Bain.2FOBMM.2FManual.29_Archives - 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).

We could do this ourselves with existing mods. To illustrate this I will share my repackaging of the quest mod http://tesnexus.com/downloads/file.php?id=21816 I repackaged the mod and combined it with various available patches like so (quote box used because code box does not activate links):
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 http://tesnexus.com/downloads/file.php?id=11598 . 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 :huh:)

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.
  
• It will not install OBSE plugins.

... 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 http://wryemusings.com/Wrye%20Bash.html#Overview (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 http://www.tesnexus.com/downloads/file.php?id=20516 - both of the overlooked approaches can also give information on how to organize packages and sub-packages.

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 http://wryemusings.com/Wrye%20Bash.html#BainConversionFiles 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:
Here is a http://www.gamesas.com/index.php?/topic/957424-custom-bain-projects/page__view__findpost__p__15682766 from FrodoDarkLord about how to make BAIN Conversion Files:
and a http://www.gamesas.com/index.php?/topic/957424-custom-bain-projects/page__view__findpost__p__15675606 to the BCF he created. I believe it is a compilation of weapon retextures.

Lojack has created a Nexus page of http://www.tesnexus.com/downloads/file.php?id=31062 with plans to add more BCF to once completed.

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.

Managing Installer Packages

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.

[Of note: Fallout Mod Manager now can give better conflict reports and even anneal function for each individual file - more powerful than BAIN!!]

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 modsNPC face modsUOP & Vanilla fixesBSA tricksOverhauls I - Initial Fran's files for FCOMLoading Screen AlternativesWeather mods and overhaulsSound modsLightingGeneral Base ModsMap marker TweaksHotkeysDLC group Body replacersItems (armor and weapons)Body Replacer Armour & ClothingHorse ModsOverhauls - Main FCOM, WAC, TIE files.Tamriel TravellersOverhaul compatibilityPost OverhaulQuests and Locations Unique LandscapesCity overhaulsOverridesAlternative startsVampiresMagicAlchemyEnchantmentThievery, Sneaking and CrimeGuards and BountyCombatSkills, Attributes and LevelingPose and Animation ModsSemi-final overridesBeauty Packs Race Changes\AddonsCompanionsRespawn & day length overridesShader 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).

DCLUnofficial PatchesDarNSoundsWorld textures - expandableEnvironmentsWeatherOther replacersOverhauls - muchOverhaul Overrides and PatchesQuestsDungeonsLocationsHousesUnique LandscapesProvinces/LODCities and villagesRoads and infrastructureRaces and BodiesCompanionsMagicStealthCombatScaling and levelingerratanewly acquired and testing modsmy 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.

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-BAINREPLACER-Sky Textures Compilation-BAINOVERHAUL-Warcry-BAINOVERHAUL-MMM-BAINDUNGEONS-Dungeon Compilation-BAINDUNGEONS-David Brasher-BAINQUESTS-Simyaz-BAINQUESTS-Dragon Captions-BAINHOMES-Castles-BAINHOMES-Yevic Homes-BAINNEW LANDS-Tamriel Heightmaps-BAINNEW LANDS-Elsweyr-BAINSETTINGS-Leveling and Skills-BAINSETTINGS-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 dummy archives that contain no real installable information. 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==.7z==Overhauls==.7z==Quests==.7z ... and so on.

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 A120 Animation Mod B, etc200 ==Idle mods==210 Idles Mod A220 Idles Mod B300 ==Pose Mods==310 Pose Mod A320 Pose Mod B ... and so on.

Also using leading dashes '-' will work the same as the equal '=' sign.

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.   └ 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 http://www.softpedia.com/progDownload/File-Folder-Tree-Viewer-Download-107749.html 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 http://www.tesnexus.com/downloads/file.php?id=29790 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 http://www.gamesas.com/index.php?/topic/957424-custom-bain-projects/page__view__findpost__p__15541388.

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 http://www.tesnexus.com/downloads/file.php?id=29790 (the main download).

Creating Very Complex BAIN Packages

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 http://sites.google.com/site/oblivionpoinfo/lists/mybainlist 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.

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 http://www.gamesas.com/index.php?/topic/957424-custom-bain-projects/page__view__findpost__p__13861975 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:
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.
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 http://devnull.sweetdanger.net/texturesfaq.html 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.

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.

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.


Sky Replacers Compilation

This compilation focuses on making the sun, moons, stars, and nebula more interesting. It falls short of http://tesnexus.com/downloads/file.php?id=21945 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.



I will add other example packages later.

This post is subject to updates.

BAIN Ready Packages
and creating packages for adding extra content (including supplemental packages).

Kudos to the following mods for being packaged as BAIN ready right from the start:
(will compile a lit of mods packaged for BAIN use in mind - not sure how exhaustive)
Wrye Mods
Arthmoor
Vorians
Ismelda

One method I've adapted is to repackage existing archives even if they are BAIN ready in order to add support mods to that archive. Some may find this tedious however and so another method is to create supplemental packages to support already BAIN ready mods. As long as you start the numbering of sub-packages to start after the sup-packages of the package you are supplementing ends you can do it either way.

One example being a Supplemental weather Compilation

More will be covered in the FCOM/Overhaul BAIN section...


This post will be completed later.

Various Mods Repackaged as Complex BAIN packages

*******************************************************************************************************
Originally I had intended to address how to package FCOM to be BAIN ready, but the more I've considered it the more I'm convinced that is a bad idea. The problem is that the instructions are always in flux as new updates become available and I do not want to suddenly have up on the board outdated instructions that no longer match what the basics of FCOM installation is. Further Tomlong75210 is really tackling this in a much more comprehensive manner with an http://www.gamesas.com/index.php?/topic/1083993-in-depth-guide-for-installing-fcom-and-non-fcom-setups-with-bain/ which is part of the http://sites.google.com/site/oblivionpoinfo/ project.

My basic plan was to repeat the basics I presented in the original http://www.gamesas.com/index.php?/topic/957424-custom-bain-projects/page__view__findpost__p__13906324 and expand more on the complex packaging of OOO, MMM, and Frans so as to make those overhaul packages useful in configurations other than FCOM.

Instead I save this as the repository for various Custom BAIN packages embedded in spoiler quotes.

********************************************************************************************************

This post will be completed later.

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 http://www.gamesas.com/index.php?/topic/957424-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.

About 1.5 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 my year and a half 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.

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.
  
• Current installation methods do not promote use of Wrye Bash.
  
• Begs for more installation problem reports.

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 OMD scripting.
  
• BAIN encourages further use and integration of Wrye Bash.

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 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.

After thoughts, Updates and Extensions

A planned place for posting:
1. Updates to the BAIN Utility.
2. Thoughts about other approaches and great suggestions from others.
3. Whatever else.

*******************************************************

There I got the initial posts up - will try and edit the first five soon to make them look less like scribbled notes and then work on the second five over the next week or two.

My Mail box might be a better place to comment on basic layout and formatting for now.

The forum seems much more difficult to format now - hope this thread lasts a year too.

Nice Job on the Guide.

Found this 4 pages down . Lots of reading but very informative and Helpful.

Psymon, I can make space for your BAIN instructions on the website. Linking the latest thread is kind of annoying, since it get lost eventually. In fact, I need to update the links already on the site. I will link this thread in the BAIN Organizaton part of the walk-through anyway. I have not yet added many outside resources to the walk-through yet. It is nearly a stay-in-one-place and correctly install some mod setup guide, which is my intention.

I will tell you what is annoying is formatting this thread. It needs tons more work and I know I will already be cutting and pasting each post into a txt file if ever I need to repost the thread. The last thread made it for a whole year. I thought it would have been purged long ago.

The advantage I see with your site is possibly hosting pictures of the BAN windows and sub-tabs - as well as the overall survivability of the posts.

Morrowind has many great websites for modding and tutorials for tools outside of the domain of forums and this is great since once you have the link no digging through mountains of threads to find the information. Other than a few pages on UESP Dev_Akm's site and some of Wrye Musings there is not much for Oblivion, so I applaud what you are doing.

Yeah I'm ok with this material being hosted. Thanks much for the offer.

One thing though - I want to finish writing most of this before that happens. I'm not sure if the formatting I'm doing here will transfer over or even if it should.
As with most of the changes - I'm finding editing on the new forum a frustrating experience. I miss code boxes that scrolled down. I wish I knew how to indent - need to research that stuff. Hopefully within a week or less this will be finished and I can then go back to finishing off BAINing my Fallout 3 and Morrowind installs.

Yeah, I figured you wanted to format everything. Formatting content on the site is no easy chore either.

Very informative post! :goodjob:

I'll look through it all more carefully later. For now, I admit, I skipped to the BCF section since I'm the one most familiar with it.


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.

Forgive me, but it seems you don't have the clearest picture of what BCFs do. 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.


You're right. You can make a packaged compilation faster than a BCF by definition since (just like a checklist) a BCF requires a packaged compilation before it can be created. I assure you that it is faster making the BCF than it is to write up a checklist. A BCF will normally take at a couple seconds for average sized mods, and possibly a minute or two for large (300MB+) mods. It takes a total of 6 mouse clicks to make a BCF, and most of the time is spent waiting for the BCF to actually be made.

With a BCF, the end user can make the exact same mod compilation in a fraction of the time it took you, and with just 3 clicks after installing the BCF and original package(s). They still have to select which sub-packages to install. They just don't have to replicate the work you did.

Thanks Waruddar - great stuff.

I will likely edit the above and insert it into the post you quoted and correct that post.

All this talk of BCF and still I've only seen the one. If there are any other examples I'd sure like to link to them.

Still I will keep that part about how BCF do not address the point that the single best thing I can recommend for repackaging is cleaning the esp prior to installing it via BAIN.

Yes you can clean them after installing but then any annealing and you have the dirty plugin back in your load order.

So I always create my BAIN package, install it with WB, run BOSS, then clean it. If it was cleaned I rename the original ESP with a "_BU_" prefix (reminds me that it needed cleaning), copy the cleaned ESP to my working BAIN project and then re-create the archive. This approach ensures that I test that the installation does what I think, makes sure that BOSS placement is satisfactory, and does not take too long (especially now that I use the "Store" option on my archive creation).

Just adding another perspective.

Honestly, I don't know of many examples floating around. I think the problem is that BCF's aren't known about in a general sense, so nobody has really started using them. Nobody's using them, so nobody really knows about them. A typical chicken and egg problem. This wasn't helped by the fact that I disappeared from the mod scene for half a year immediately after BCF's were introduced. With me and Wrye both gone, there wasn't anybody to promote and explain their use.

When I coded BCF support, I figured that someone would take all the packages they converted, make BCF's, and upload all the BCF's in a single archive. The end user would download these conversion mega-packs, install them, and forget. When they downloaded a new mod, they would right-click on them in BAIN to see if there were any pre-made BCF's. If not, they could make their own and upload it (or submit it to a maintained BCF collection a la BOSS), or see if there was an updated BCF available online. There is absolutely no problem with installing BCF's that you don't have the original packages for; BAIN simply ignores them until the package is added.

Moving on...

Cleaning esp's is a bit tricky. If you clean the esp before making the conversion, the BCF will contain the cleaned esp. This is good in that the end user wouldn't have to clean it themselves. It's bad because then you're redistributing the author's work without permission. On the other hand, BCF's require the original archive to work, so they already have the original esp and you're just providing a cleaned copy of it. It's a gray area in regards to author permissions, but I'd lean against it just to avoid any negativeness.

The situation also exists with PyFFI'ing meshes. If you optimize the meshes before the conversion, the BCF will contain the optimized meshes. Same pro's and con's as above. However, there is something I can do about this. When I add CBash to Bash, I'll see about adding support for PyFFI as well. Then, the player can right-click on a package just prior to installation, click "Optimize Meshes", and Bash will take care of unpacking the archive, telling PyFFI to run, and then repack the archive with the optimized meshes. Then, the player installs the package, and everything works fine.

In theory, I could do the same thing with CBash with cleaning the esp. I won't though.

Why? For that, I'm going to have to go slightly off topic, and discuss some potential issues with cleaning esps. Feel free to skip the rest of this post. It's getting rather long

It isn't always safe to clean an esp. There are mods that intentionally use "dirty" edits, and it especially isn't safe to distribute those particular cleaned esps.

To be clear, most "dirty" edits are not intentional, and cleaning them poses no problems whatsoever. Cleaning mods with TES4Edit though is not fool-proof.

TES4Edit is aware of this, so it cleans esps by checking two main rules:

• Did the record change from it's master's record. If so, keep the change.
  
• If it didn't change, did the change revert a change made by a mod between the master and the mod in the load order. If so, keep the change. Otherwise, clean it.

The problem is that cleaning a mod is dependent on the load order. Different people have different load orders, so what is clean for one person may be broken for another.

If you try to bypass this load order problem by cleaning a mod by itself, just it and it's masters loaded, you run the risk of breaking the mod.

This is fine in theory, but here's a more concrete example:

In my mod, TQP, I require a game setting "iInventoryAskQuantityAt" to be at a specific value. For this argument, let's say that this value happens to be the same value it is in Oblivion.esm. I set this value directly in the mod just to be sure that it's correct in case a mod somewhere else in the load order happened to change it. I give instructions that TQP should be loaded near the end just to be sure that its value is used.

Player Bob has a mod that happens to change this game setting, but he follows the install instructions with TQP at the very end, and TQP works fine. He opens his load order in TES4Edit, cleans TQP, and it continues to work fine. TES4Edit didn't clean out the "dirty" edit because it reverted a change that Bob's other mod made.

Player Alice doesn't have any other mods that change this game setting, follows the install instructions, and it works fine. She cleans TQP just like Bob did, and it continues to work fine. TES4Edit DID clean out the "dirty" edit, because it was the same as the master (Oblivion.esm), but TQP then uses the value that Oblivion.esm defines.

Bob tells Alice about this awesome mod he has (the one that changes the game setting), so she installs it. Being careful, she follows TQP's install instructions and leaves it at the end. Now, when she plays, TQP is broken. She can't figure out why; she and Bob both have the same mod, in the same place, and they both cleaned it. The problem is that when her TQP was previously cleaned, it removed the game setting. When the new mod was added, it changed the game setting to a value that TQP didn't support, and TQP didn't have the game setting defined like it should. When Bob cleaned TQP, it kept the game setting.

The same thing would happen if Alice gave Bob her cleaned version of TQP. Her version doesn't have the game setting defined, so the last one that loads is the value the other mod set.

So, sometimes a "dirty" edit is quite intentional.

In reality, TQP does use the game setting "iInventoryAskQuantityAt", but it is a different value than Oblivion.esm, so this situation wouldn't occur with TQP specifically. Plus, being cautious, I set the value via script as well just to be sure. This also allows it to be loaded anywhere in the load order.

TQP is safe from this sort of problem, but other mods may not be. I believe the unofficial patches use these intentional "dirty" edits, and thus shouldn't be cleaned (Quarn and Kivan cleaned them by hand because of this). Ideally, mods would be cleaned after a load order is finalized, and if the load order is changed, the original "dirty" mods would be put back in place in order to be cleaned again.

This is a lot of trouble though, and at the risk of repeating myself, to be clear, most "dirty" edits are not intentional, and cleaning them poses no problems whatsoever. Cleaning mods with TES4Edit is not fool-proof. This is one reason why ElminsterEU encouraged people to contact the original author about any "dirty" edits. The author is normally the best person to know which changes were intentional, and which weren't.

Very informative, I shall try to fully BAIN my next install as much as possible but for now I'm just trying to mop up what's left of my brain.

I have finished the first draft of http://sites.google.com/site/oblivionpoinfo/walkthroughs/baininstallguide that you could start with before coming here. It sticks to the basics. Psymon's project takes off form the end of Part VII, so to speak. (Part VII is kind of lacking for non-FCOM users at the moment/ )

Well All of this does not sound appealing to me. As I posted above it is a bias that I own as I prefer to have more control and assurance over my install. I mod my game by the maxim 'my load order is my responsibility.' I also recall Wrye stating several times in the BAIN thread that ideally mod makers and packagers should be encouraged to adapt BAIN packaging from the start and thereby remove the necessity to create yet further steps in the use of BAIN.
Hence the necessity of threads like this. If BAIN were adapted
I think I understand your concerns and I'd like to emphasize that really this is an issue with tutorials geared at cleaning mods and not with tutorials geared toward repackaging BAIN mods. I will do my best to link to good debate/tutorials regarding cleaning.

Not having been aware of your update to tqp I read the readme. Gotta say it would take some serious thought and careful consideration prior to reading it that one would pick this issue up. I'm surprised that you just did not spell out 'Don't clean this mod with TES4edit' and here is why ... right there in a known issue section. Would seem a safer approach than counting on people knowing.

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, and quest mods.

In short this is great information, but applies to a minority. Noted though.

Wow doesn't all that renaming lead to more work? Wouldn't it also necessitate even more shuffling of esp in and out of the data folder and potentially make BOSS less useful?

For myself if I suspect a dirty mod then I will throw just the esp in and check (wish edit would read out of data folder) then after it passes I may just use the given archive if it is formatted rightly. If not then repackage. Otherwise clean and repackage then install.

Another Nice Guide....Thanks For all the hard work you guys are doing. I am Still Reading thru the Guide on your Site.

Ummm how to say this. As FCOM is really not for a newbie per say. Thought i would Point out a couple things.

1) in the Section ......Fran 4.5b - Convert. You mention the Default path for Frans puts everything in the Data Folder....Which it Does...BUT you could instruct everyone to Change the path BEFORE they install, to go directly to the Installer folder for BAIN OR a temp Folder located outside the Oblivion Folder so as to not make any Mistakes??
(Personally I have Never extracted any mod Directly into Oblivion's folders & never will)

2) Don't know if this is widely known or not.....IF at any time you want BAIN to completely Ignore a folder you can put a Double "--" (Thats a 2 dashes) the key next to the "0", and this folder will Be Ignored.

For instance in the AWLS BAIN archive is a Screen Shot Folder IF you leave it as is, you will have a Gray Background for said Mod (just means there are files it wont/cant install) But if you were to add the -- (Double Dashes) then the Mod wont have the Grey background . your files are still there for reference but don't show up on BAIN installer tab.

Took me awhile to sort all this out But at this point I have 93 Packages (none have a gray Background), that install 207 mods. Of which Oblivion only sees 167. God I Love this Program.


Going back to Read more.....lol

1) I do not have my actual desktop nearby, so I am pulling a lot of this from memory. It has been a while since I installed Fran's mod, so I did not remember whether or not you had the option to changed the install path. I will definitely note that now. Not all installers give you that choice however, so that is okay.

2) I know about the folder ignoring feature. I will add a note about it for anol people (like me) who do not want grayed out packages for no reason, haha.

Well, you are doing well. I am less than 30 packages from 800, haha.

Edit: The reason I have Frans uninstalled is because it modifies the Oblivion.ini. It is easier for people to copy a few BSAs and plugins, then to modify the Oblivion INI. Installing a mod packaged as nicely as Fran would hardly stir up trouble in the data folder. If you did not uninstall Frans, edit the sArchiveList to remove the Fran's entries.

Well I think that post was meant for your thread Tomlong

Yes you can change the FRANs install path and run it multiple times even into different folders or future packages.

I will outline this at some future point for those who wish to package FRANS for other than FCOM use or better yet for an all options inclusive package of FRANs (which really should be made available anyway).

Thanks about the leading -- I forgot about that one and will use that info.

now off to my real job.

Got ya....

To Bold Part above ...AND ME!!!

So when you click the Installer Tab ...what you go to Store and get a coffee??

Edit..Crap this IS the wrong thread ...Hmmmm Sorry Psymon.