190 replies to this topic

[Psymon]

BAIN Mod Installation Projects

Comprehensive instructions for people who like to read

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

The Basics of BAIN and Mod Archiving
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

Complex BAIN archives
Examining BAIN archives
Pros and cons of combining mods into complex archive packages
Repackaging a complex archive example

Managing Installer Packages
Install Order
Naming Conventions
Updating best practices

Creating Your Own Complex BAIN Packages
Planning Your Mod Archive
Rationale for Complex Custom Packages
Examples of Very Complex Custom BAIN Packages

BAIN Wizards, OMODS, and BAIN Conversion Files
BAIN Wizards concept and use
OMOD reading feature
BAIN Conversion Files: arguments for and against
Examples and links

BAIN for Other Games
Fallout3 and New Vegas
The Fallout Mod Manager
Morrowind and Wrye Mash

Managing BAIN with Multiple Installs
Best use practices of mTES4Manager
Setting up multiple BAIN archives
Setting up multiple installs to use the same BAIN archive
Notes on updating

An open letter appealing to the use of BAIN and Wrye Bash by mod makers

Related Topics
The Bashed Patch
Other Bethesda Game Interests of Mine

=================Mod Installing and Mod Management=================

The focus of the first post of this thread is to attempt to explain the need for using an installer and BAIN in particular. In the following posts will be explanations of BAIN functions and related topics.

Why this thread?

My original thread on this subject has long since reached its end. My intentions at that time were to mostly have a place to post about how I was using the then new installer created by Wrye and part of the Wrye Bash program. I tend to not like to create threads and usually try to post whatever questions or statements in existing threads. I know when I find something I like I can get a bit zealous about it and, at the time, didn't want to overwhelm other threads with my extremely self-indulgent uses of this new installer. Having it be instructional was really an after-thought. Having gotten the zealous part mostly out of my system I now return to this and hope that this thread, or at least the opening posts will be more instructional and I will do my best to collect and/or link all the best material related to this subject.

I'd like to point out that I am primarily what most would consider a mod-user. [I do not like that term and will explain why below, but for now let me play along.] While I've altered many esp files and even created my own house mod (that will remain unreleased), all the rest I've learned I've picked up from the perspective of a person who uses other, 'real modders', work. Because of this most of what I will attempt to write will be for those who are new to mod using and are trying to get a handle on how to best apply already made mods to their install. Primarily this is being written with TES4: Oblivion in mind, but most of it will and can also apply to TES3: Morrowind and Fallout 3.

Mod Installation introduction

Let's just start with - "well here we are wanting to mod these Bethesda games." Asking 'How best can I do this?' is not usually where most people start. The way I take it most people start with a game they like then play it for a while maybe do some internet searches and read or hear about these 'unofficial add-ons' called mods and then maybe find a link somewhere to download and then the first learning curve hits with the question 'what is the fastest way I can get this in my game without straining my brain too hard?' Perhaps there is also the thought that 'wow this is complicated', or 'only computer tech people could do this.' If a person is reading this to really learn how to do use mods then they may have an inkling that many consider Bethesda to make some of the most moddable games, promotes modding, and has three of the most modded games on the market.

From this then a person may just dive right in and install these user made mods the old fashion way: manual installing. That means finding out what file needs to go where and then installing it there by copying or cutting from the downloaded content and pasting into the appropriate folder directory of the game install. Doing this, in my opinion, is the most educational way of learning how to add mods. It is by this method that one really has to read the readme and get familiar with all the file directories and the general directory layout and functioning of the game in question.

So with this we learn that the game exe calls upon information from the data directory for the material of what is presented in-game and that where the presented material presents is stored in the save game files often found in another directory. Most modding has to do with adding user made mods to the Data directory. Most of what it takes to do manual installing can be read in the pinned thread called ***OBLIVION MODS FAQ*** He does describe the use of installers. This thread will be about the use of installers and specifically BAIN.

So the next phase of most mod users learning curve is after they get in over their head. This is the result of shiny new mods and the very, very deep catalog of mods created for these games. So a user begins by installing some mods to improve graphics, then game settings, then an overhaul is isntalled, but wait that is not the right one ... err maybe that one. Then the game crashes begin - the dreaded ctds: crash to desktops. Then thinking that 'well I guess I should uninstall my game and start over, but next time I will get it right!' Then we are at the original question of how best to do this. Unfortunately, that really is just the beginning because using programs to automate installation means that they are subject to the same rules as all software programs: Junk in = Junk out.

Why use an installer?

So from this frustration of losing track of all that is installed the need for an automated way to do things is born. Mod Managers are not exclusive to bethesda games and doing a quick google search of the words and you will see many games have mod managers available. Mod Managers automate the installation of user-made-mods (from now on called 'mods'). They are tools whereby the data from a user made mod can be installed and better yet removed with the click of a few buttons. For Oblivion the standard has been Oblivion Mod Manager or OBMM for short. the OBMM download page.

OBMM is a great mod installer. There are a few older ones but as far as a straight away mod installer it is rich with features and by the standards of most light to moderate mod users it will serve the purpose of installing mods very well. It can automate mod installation so that very little thought about what is happening and where things go can blissfully be ignored. All the better that many mods come as either OMODS (packaged to be used by OBMM) or OMOD ready (able to be made into OMODS). There is also a Morrowind Mod Manager, which is primitive, and a very highly developed Fallout Mod Manager, which is starting to make the Oblivion Mod Manager look as primitive as the Morrowind Mod Manager looks when compared to OBMM. The author, Timeslip, continues to develop the FOMM with the help of Kaburke. Recent Thread found here. And with OBMM scenttree is making additions with Oblivion Mod Manager Extended, which includes more control in installing loose files.

The issues or problems with OBMM (or the other varieties) is really a matter of perspective. From a mod makers point of view these programs may indeed be heaven sent because with just some tinkering and packaging a very complex mod can be made available for instant download and installation. This cuts down on the number of complaints and inquiries about how to install the uber-mod-to-end-all-mods (... ohh shiny). And for users who only want to use a moderate amount of mods and not think about what is happening under the hood then it is great. On the other hand, those who do wish to see what is happening under the hood or want to use many mods then the Mod Managers start to show their weaknesses and shortcomings.

My critique of the mod manager is not meant to be unfair to it and I will own that it is my own viewpoint. The Morrowind Mod Manager is not nearly developed enough to warrant using as an installer and the FOMM in its current editions includes many features that attempt to address the shortcomings of the OBMM. To summarize my points:

• The OBMM does not encourage users to think about file directory or about how a manual install of the same mod would work. This has a net effect of reducing a person who is 'modding their game' down to a mere mod-user. To me that further creates a rift between mod makers as the real modders and mod-users as their customers. The caveat being that yes one can script the OMOD files to install in any fashion whatsoever, but again the effect I've seen this have is encouraging sloppy and confusing packaging of mods.
• The OBMM does not offer a comprehensive solution to managing install order, particularly of replacer files. i.e. if one were to want to make sure that a certain replacer was always installing last and was part of larger mod then one would have to uninstall and reinstall said mod. As a caveat there is an option to be notified of conflicts and will even tell you what other OMOD the file comes from and whether you want to overwrite the file in question. This can be very tedious with lots of files to individually click yes/no to.
• The OBMM conflict detector is near useless. Unless you've trained yourself to make sense of what it is telling you mostly it is a confusing report.
• The OBMM can crash and when it does it will lose records of all installed OMODS and require a reinstall of all of them. The unfortunate part of this is the more OMODS you have installed the more likely that this is to happen. This, ultimately, is what made me want to move onto another installer. After several crashes in a short span of time I was about ready to give up on a modded Oblivon.

In concurrent development there was another utility for these games brought to us by Wrye. This was originally the Wrye Bash program for Oblivion but he also created a Wrye Mash program for Morrowind. Wrye Bash (sometimes shortened to WB) is a multipurpose tool with many many features for modders (mod users and mod makers alike). Here is a short and very incomplete summary of its features:

• An advanced load order tool (adjust and manage load ordering of mods).
• A save game managing tool (create profiles, remove same game bloat, etc).
• Allow automating of INI edits.
• Manage screenshots and archive PM messages from boards such as this one.
• Bashed Patch creation (which includes):

• Merge leveled list altering mods to reduce conflicts.
• Further merge mods and reduce active mods thereby increasing max mods useable.
• Import only specific records within mods and further control load order via Bash Tags.
• Library of game settings that can be adjusted with each bashed patch building.

The last portion of Wrye Bash that Wrye worked on before passing the project on to others to manage in his absence is what is known as BAIN which is short for BAsh INstaller. The BAIN component aptly handles the shortcomings of the Oblivion Mod Manager and in my opinion offers features that greatly expand upon the functions of mod installer programs to date. The features that I'd like to point out are:

• BAIN encourages thinking about what a manual install is and how things work 'under the hood.'
• BAIN offers minute control of files and gives sensible conflict reports and control options of resolving those conflicts.
• BAIN gives us the ability to manage install order - a term analogous to load order with regard to esm/esp files.
• BAIN Provides detailed reports of what it installs and can tell you if what was installed has changed, been overwritten, is missing, or even if a file was not installed.
• BAIN requires no special OMOD files and can work with 7zip, rar and other common archiving methods (7zip being the recommended though), as well as, regular file folders (projects).
• BAIN offers the ability to create your own packages that can include any number of mods with the limit being only what you can manage to create with file directory juggling.

Most of what this thread will be about is the general uses of the BAIN tab, formatting of BAIN ready packages, and the creation of custom BAIN packages.

Many took my last thread as if I were bashing on OBMM. Not true and the point is that really they each have their strengths. There are things that OBMM can do that Wrye Bash cannot. Some of these include:

• The installation and merging of Shaders. installation of shaders is possible with Bash 291, but not shader merging or editing.
• OBMM Will install anything you put into an OMOD and create any directory you create as well. Including other archives and executable files.
• Scripted installs that edit the ini automatically and change the name of plugins on install. There are plans to create scripted BAIN wizards - keep checking new bash versions.
• BSA management including extraction and the packaging of BSA files.
• OBMM handles foriegn language characters on file names (unicode) much better than BAIN can.

More about comparing BAIN and OBMM (though a bit outdated).

In short I use both with about 96% of my install managed through BAIN and the rest via OBMM. So for most replacers, large projects, loose random files, mainstream regularly formatted mods and so on I use BAIN. For OBSE extensions, Shader mods (Night eye shaders), and heavily and elegantly scripted OMODs such as those made by theNiceOne or ABO it is OBMM. The main feature I use on OBMM is drag and drop load ordering.

The advantages I've experienced in moving to BAIN include:

• It has kept me grounded in thinking about manual installing and what that implies which has in turn kept me thinking of the this process as modding instead of mod-using.
• It has made it so that I never really have to think about uninstalling and reinstalling the game again. In other words I've never again felt overwhelmed by the amount of material installed and never felt as though I could not manage this material.
• It has allowed me to manage and catalog an enormous mod collection where I could change my load order in very dramatic and comprehensive ways within a very short time.
• It gave me a hobby, some might say an addiction.

=================More links regarding installer tools=================

I'm often told that I'm too wordy, so if you prefer pictures then check out:
Pictorial Guide to Wrye Bash and BAIN by Alt3rn1ty's
Perhaps someday these two guides can be merged!

Many a great resource and more Wrye Bash instructions for the mod user:
TESCosi by Tomlong
... soon to be available in Wiki format. Current forum thread.

Wrye Bash Main download
Wrye Bash Manual ** very outdated compared to the readme included with the latest download.
Wrye Bash on UESP
Wrye Bash on CS Wiki
BAIN on the CS Wiki
Wrye Musings Many Things Wrye ... including wrye views.
The latest Wrye Bash thread as of this writing. If not current just search the last day or two and you will likely find it. This is where you go for technical help in operating the tool.

Oblivion Mod Manager Alternate Download
Oblivion Mod Manager Extended ** New improvements in graphic interface and presentation as well as scripting.
OBMM main project page
OBMM instructions - this site contains a lot of information about archive management in general as well.
OMOD creation tutorial
OMOD creation on CS Wiki

Mods general FAQ
Mods FAQ on CS Wiki
Modding Glossary
Tools of mod makers and mod users alike

See Post 7: BAIN for Other Games for information on how to use BAIN for other other games.

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

Edited by Psymon, 24 July 2012 - 02:41 PM.

[Psymon]

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 Wrye bash readme (the most current version packaged with the latest Wrye Bash and accessed with ? button on bottom toolbar of Wrye Bash) and I highly suggest you take that as the authority and follow it if I deviate from what is presented there. Next one should direct general questions about the technical problems and functioning in the current Wrye Bash thread. Otherwise if everything is understood and I can answer (or anyone can answer) then ask. I just want to emphasize that those places are a higher authority.

When first installing Wrye Bash (or Wrye Mash or Gary Bash/Wrye Flash) the Installers tab is usually deactivated and when you first click on it you will get a notice asking if you really want to activate the tab. After activating the tab the it will take a few minutes to initialize. It is important do not interrupt this scan because each time you open the tab from this point forward it will scan what you have installed to check if anything has been altered or removed in order to inform you. This is a good thing. The first time you open this may take a few minutes. If you do interrupt the scan then most often you can reopen the tab after restarting Wrye Bash and it will scan again.

This will also create a new directory outside of the main game directory. For Wrye Bash and Gary bash this will be a directory called either Oblivion Mods or Fallout 3 mods and are found right next to the main game directories. Each of these will, in turn, contain a folder called 'Bash Installers.' (There may be a way to alter that so that another drive or directory is used as you can with screenshots.) For Wrye Mash (at this time) the BAIN installers directory is found at the top directory of the game ... Morrowind\installers.

When adding a BAIN friendly archive (called packages once installed) place it in this added directory in the folder called 'Bash Installers'. At each opening of the Installers tab this folder is scanned each package is compared to each other package to the contents of the data folder. The purpose of this is to inform you of changes to what was installed (including if files were altered or missing).

The method by which this is done is called a cyclic redundancy check. If this check fails then the tab will be blank. A frequent cause of this is moving archives in and out of the bash installers folder while the check is happening, so make sure to add or remove all packages you want to be included in the scan prior to opening or refreshing the the installers tab. If there is another cause for this then please direct the question to the latest Wrye Bash thread and the developers overseeing the latest version.

Navigating the Installers Tab

Firstly read over the Installer Tab readme from the Wrye Bash readme (the Readme is always more up to date than this one).

Upon opening the tab one is confronted with 5 panels. Along the entire left side is the package list that looks much like a load order launcher app. If the scan was successful it will contain all the archives added to the Bash Installers folder. Here they are called packages and each has a column describing install order and date modified. The Modified date is of little importance (although it can be informative for telling you when a package was created). the Install Order column though is very helpful in managing your BAIN packages and automating the install order.

Much was made previous to BAIN about the importance of install orders and what mods and their attendant replacers should be installed before (or after) any number of other mods. These concerns are no as of longer of great import with the inherent functionality of BAIN. The install order can now be adjusted without necessarily uninstalling or reinstalling as the management of all files will be handled by BAIN.

Key functions of the installers tab are found with the info-tabs (sub-tabs to the main tab which is the installers tab) that are found at upper right side of the installers tab these include:

• General info-tab: The ability to view the contents of a package prior to installing.
• Matched info-tab: The ability to see what in the packages matches what is already installed in the data folder. If two files share the same name but different sizes then that is not a match.
• Missing info-tab: The ability to view if anything that was installed from the package has since gone missing.
• Mismatched info-tab: will tell you if any files with the same name are actually different in other ways.
• Conflicts info-tab: will tell you what other packages are either overwriting the contents of the current package or what packages the current package is overwriting. This is reflected in the designation of higher and lower. If conflicting with manual or OBMM installation then no info is given here, but most likely is given in the other sub-tabs. This tab provides a meaningful conflict detector for replacers that can give valuable information about what your install order should be.
• Underridden info-tab: Shows packages which should be overridden, but are not, due to install order errors. This will often give reports after the install order of packages is changed.
• Skipped info-tab: will tell you what was not installed. This is likely because it is a file or directory type that is not recognized by BAIN.

The next two panels are located below these sub-tabs and are content filters:

• A filter for sub-packages: Shows which of the sub-packages are installed (explained later).
• A filter for esm/esp: Shows which of the esm or esp are installed and the area where you also decide which (if any) of the plugins or master files you want installed.

The final pane is a comments pane and it allows you to input comments about each package. Contrary to hopeful thinking it does not present the readme for the package. You ca, however, copy and paste a readme or two into this pane. I use it to write myself little notes like 'Load this package after package so and so.'

The package list can be sorted with Wrye Bash by ctr+arrow keys the packages can also be sorted and new install orders can therefore be automated. This is a leap from what Oblivion Mod Manager offers. For example say you wish to make sure that a certain replacer set ( a clothing texture overhaul for example) was installed last. With each new mod you installed with OBMM you would have to check to make sure it did not overwrite any replacers the replacer set installed and if it did you would have to uninstall the entire replacer set an reinstall over the new mod. With BAIN you can simply move the package you want to win the conflict and adjust just those files with the anneal feature.

Many functions of the BAIN tab are accessed through what are known as context menus. You will notice in the packages panel there is a bar along the top that says obviously enough 'Packages.' Right click on this and a context menu will drop down. Much like with the mods tab you are more likely to find more global commands on the top bar while the context menu accessed through right clicking a package is more likely to be commands for only that package.

Installing and Updating Packages

The packages are installed by right clicking the package to bring up the context menu and clicking install. This will install all the content from the package (or sub-packages you have filtered to install) including replacers, BSA, ESM and ESP files as well as readmes and other commonly found files used in Oblivion modding. You will find as you go on that there are certain files that BAIN will not install:

• It will not install exe or executable files.
• It will not install archives in a further embedded, zipped/compressed state.
• It will install Shaders but it will not merge and edit Shader files.
• It will install OBSE plugins But only after prompting you to approve this.

... These are areas where OBMM does outshine BAIN.

If you run across a file that BAIN seems to refuse to install or that you can see will place in a non-usual folder in the data directory (such as data\ini or data\streamline) then with the context menu make sure to check Has Extra Directories if this does not work and the file is not of the non-supported variety above then report that in the latest Wrye Bash thread.

As you learn more about package management and adjust the install order of packages you may notice the package names turning different colors. This is mean to notify you that overwrites and underwrites are happening. Usually you can read the info-tabs for more information. The likely cause is that you have:

• Moved another package lower in the load order which now wants to overide a file in the package in question.
• Installed an archive that similarly wants to overide a file in the package in question.
• Have moved the package in question to override another package and it has not yet installed the files it should be overriding.
• You have used another program to replace or remove the same files (at least by name) that the package in question wants to has installed.
• You have manually removed or replaced the files that the package in question has installed.
• Somehow the file installed has been altered (cleaning a mod can cause this).

The following is quoted directly from the Wrye Bash readme (where it is better illustrated) concerning package shapes, colors and general health:

Checkmarks

• Installed packages will be marked with a "+".

Icon Colors
Icon colors indicate the degree to which the package is synchronized with the Oblivion\Data directory:

• Green: Package is fully synced. Note that a package can be green even if it is not "Active". E.g. if you have two identical packages and one is (fully) installed, then it will be green and checked. But the identical package will also be green – since it too is fully synced with the data directory.
• Red: Some files in the package are missing from the data directory.
• Orange: All package files are present in the data directory, but some esps/esms are not identical. (E.g. another package installed an alternative version of that file, or the user modified the file after installation.)
• Yellow: All package files are present in the data directory, but some resource files are not identical. (E.g. another package installed an alternative version of that file, or the user modified the file after installation.)
• White: This is relatively rare. It just means that the package is configured in a way that it has no files to install. This can happen for complex packages where none of the sub-packages are checked.
• Grey: This indicates that the package has a structure that Bain does not recognize, and so cannot install.
• Red X: The package is corrupt and/or incomplete. You'll likely see this for packages that you are currently downloading into the Installers directory.

Icon Shape

• Diamond: A project, i.e. a subdirectory in the Installers directory.
• Square: A mod package archive. Note that only rar, 7z and zip formats are supported.

Text Colors

• Blue: Indicates a package with sub-packages. The files to be installed, and thus the install state of the package will depend on which sub-packages you have activated.
• Grey: This indicates that the package has a structure that Bain does not recognize, and so, cannot install.

Text Background

• Orange: Indicates that the install is dirty. This will occur for packages for which the configuration has been altered (either by altering active sub-packages and esmps, or by altering the package itself). This can be repaired by running Anneal or Anneal All.
• Yellow: Indicates that the package has "underrides" i.e. some of its installed files should be overridden by higher order packages. This may happen after reordering mods that have already been installed. It can be repaired by running Anneal or Anneal All.
• Grey: Indicates that some files present in the package will not be installed. This is usually due to a complex structure that is only partially handled by Bain, but can also be due to having files that Bain refuses to install (exe's, dlls, sub-archives, etc.)

Annealing is a method whereby you can auto-correct the errors reported in the above described package colors and sub-tabs. Using it will take out conflict losers and replace them with the winners. It will replace files that have been removed by other methods (such as OBMM use or manual alterations. It will also replace files that it determines are different than the one installed. This includes cleaned plugins (which is why I recommend cleaning prior to installing with BAIN as covered below). You can anneal individual packages or using the context menu off of the top packages bar set the installers tab to auto anneal when changes are made. This will work only for files installed via the packages and will not take into account files installed via OBMM or manual. You can also do group anneal of all packages installed

Exercise caution and take notes if using OBMM and BAIN together! For instance if you do want to install a mod via OBMM and the result is that it makes a package turn red because it overwrote the files installed by a package then please remember that annealing that package will remove or change back what OBMM installed. Also my own experience is that setting to auto-anneal is a great option to have set all the time. It will auto-adjust files as you juggle package load order and sub-package options. it will not handle the manual changes or if OBMM is overwriting (but anneal all will).

After you install a package then please keep in mind that you still have to manage the install order of any plugins (including bashing patch and other mod tab functions). If one were to install their entire mod list with BAIN then the need to ever wash it all and install it all again is a thing of the past. With a few clicks you can install many mods or remove many mods and it will keep track of everything for you. No more hunting through directories looking for those obtusely named repalcers that you manually installed and thought was great but that now drag your performance down. No more trying to remember what the last OMOD you installed was. With BAIN it is all tracked for you and conflcits reports are given in dynamic, immediate, and user friendly format.

As for reinstalling your entire install. One can either pick to tackle changing each package over or do them all at once - it really doesn't matter because the more you transfer to BAIN the more it will provide better information about your install. Before getting into creating packages let's first examine how mods are packaged.

Mod packaging

Most mods that one were to download today are packaged using an archiving program called 7zip it is free, versatile, and powerful. It can also handle other types of archives such as rar files, which are the runner up format for the most common archives you will download. I recommend grabbing that program for both extracting the archives you download and repackaging archives that you will make.

Protocols for packaging mods and the standards of how a mod should be installed vary greatly and it took me some time to make sense of all the variations. For a while it made no sense. It seemed that mod makers and packagers were all randomly just packaging material without rhyme or reason. Over some time I quickly recognized that there was a logic and this usually betrayed the point of view of the mod maker with regard to how they installed mods, their familiarity with installer programs, and their expectations of mod users.

Archives will remain after what is in them is extracted. Sometimes they are packaged in such a way as to easily be categorized as either 'installer friendly' or 'installer unfriendly.' By installer I mean the automated tools such as OBMM or BAIN. Being installer friendly means usually that the archive is packaged in such a way as to be almost immediately useable with OBMM or BAIN. Uninstaller friendly usually means that an installer program would not be able to automatically utilize the archive and therefore they must be repackaged in order to be used by these installer programs.

The installer friendly format is one that contains a directory (or file) tree that matches the directory tree of your game installation. Here is the file tree of my game installation:

Games\Oblivion
   │
   ├[Data]
   │   ├[Bash Patches]
   │   ├[DistantLOD]
   │   ├[Docs]
   │   ├[Extras]
   │   ├[Fonts]
   │   ├[ini]
   │   ├[INI Tweaks]
   │   ├[menus]
   │   ├[meshes]
   │   ├[Music]
   │   ├[OBSE]
   │   ├[Sound]
   │   ├[Streamline]
   │   ├[Textures]
   │   ├[trees]
   │   ├[Video]
   │   │
   │   └[The ESM, ESP and BSA files]
   ├[lex]
   ├[Mopy]
   ├[obmm]
   ├[src]
   │
   └[the main game directory where the .exe and other tools are often found]

This is from a heavily modded game so I reduced the list down to the essentials you will see if you have moderate amount of mods, OBSE, OBMM and Wrye Bash installed.

Having an archive that matches the file tree above means that once extracted at the appropriate directory (data) all the files then go where they are supposed to and the mod is installed. If there is no plugin then the installation is complete and if there is then arranging load order activating it is all that is left.

To do this an archive needs to be packaged at the level of the data folder and the first folders you should see (if there are replacers involved) is the folders directly under the data folder. Many mods are packaged this way and this is very handy for installing manually. This also is the ideal packaging needed for transforming packages into OMODs or direct plugging into BAIN. These are BAIN ready archives (also called BAIN friendly). Of note OBMM can recognize package archives one level higher at the game directory.

But many archives are not packaged like this. Older mods and even today many Morrowind mods generally are packaged in such a way as to necessitate unpackaging into a temporary folder then cutting and pasting files into the proper order. This is BAIN unfriendly. With regard to these patterns of packaging I think I've seen all variety. Examples include having all the optional esp in the main top directory of the archive while the replacers are tucked away in an obtusely named folder or screenshots galore in the main or top folder while the esp files are likewise tucked away in folder structures that could never match game directory (or common sense). Male body mods are the most obtuse and mod-user unfriendly packages. These often include the actual meshes and textures renamed in extra folder not even accessed by the plugins themselves or just left loose where the main replacers are also at.

So for the purpose of brevity your basic BAIN friendly archive should look like this when unzipped:
Mod of Awesomeness:

├[meshes]
   ├[Sound]
   ├[Textures]
   └[The ESM, ESP and BSA files]

This is also the basic structure of BAIN (and OMOD) packaging. This means the extracted material matches this pattern you are golden. You do not want the result to be that when you extract a package the first folder you see is 'data'. That may be acceptable for manual installing (or OBMM if the OMOD is scripted rightly to take that into account) but not ideal for use with this installer program. Further, it is worth checking all the lower order folders and directories for misplaced files. I've found meshes in texture folders, textures in the wrong texture folder, screenshots and other errata mixed in with the replacers. Usually it is best to double check. You will develop a quick eye for it.

Repackaging Mods for BAIN

There are pros and cons to consider when it comes to whether or not to repackage. Usually people will become involved in repackaging simply because an archive is not BAIN friendly. There are other reasons for doing this:

• To make sure the readme is installed in a more organized manner and not swept into the docs folder generically named and unorganized. BAIN has a function where it will sweep the readme into the docs folder and if not called readme will add that extension to the title. This can be problematic if many readme files are simply named readme (many overwrites) and with many mods the docs folder could quickly be overfull with misnamed and uncategorized readme docs.
• You may want to perform basic edits on a plugin such as adjust the date to effect load order or complex edits or mergers with other plugins.
• You may want to combine archives into one archive and create what are called complex packages. This could include making available to install options in the main mod that are not normally installed such as alternate version esp. More will be expalined about this in the next post.
• You may want to clean the plugins.
• You may want to optimize the meshes. PyFFI Optimized offers the information you will need for that
• You may want to clean the plugins (highly recommended):

• For Morrowind there is testool - more info found here
• For Oblivion and Fallout 3 there is the same edit program created by Elminster called either tes4edit or FO3edit. Depending upon how you name the exe. The latest version found here.

The following are tutorials for cleaning Oblivion and Fallout 3 plugins:
Cleaning a mod on UESP
Cleaning a mod on CS Wiki A more extensive version here

Please keep in mind that cleaning mods is a complex subject and that while these tutorials give very clear steps how to use TES4/FO3edit to automate cleaning it is also ideal to read the readme (and comments on the download site) and possibly bring the existence of dirty edits to the attention of the mod maker. Of course many mods are no longer supported. To be very brief do not clean the unofficial patches, overhauls, esp that have other esp as masters, or esm files. Even if you did run the automated program it may find bad edits (the dirt) but they may be intentional and needed. The best bet if your are not sure is to ask the mod maker or barring that ask on a forum release thread.

From my experience of cleaning 100s if not upwards of over a 1000 mods the most common dirty edits are cell and worldspace that result in moving things by accident and other common CS events like just deleting that tree, so as usual I find the most dirty mods are house and building additions, Landscape (other than UL mods ... ), and quest mods.

The most recommended method for repackaging is to rezip or recompress the mods into new archives. One could also place them into simple file directories within the installers directory which would then be recognized as a project; however, doing this may result in the scanning that occurs skipping the project (simple file directory) and therefore missing any changes applied to that project. Waruddar has posted a more technical explanation. Projects are more ideal for mod making and or other editing projects but not for finished projects and or your own mod catalog.

There is also a rationale for not repackaging archives and that is that BAIN has a feature where if the archive were downloaded from TESNexus or TESAlliance and has the ending file designation (each file at these sights has a unique file extension) then using the archives context menu you have an option to open the download page from these sites in your web browser. This can be very handy when checking for updates to mods.

A workaround for this issue is to simply append those file numbers to the end of whatever custom BAIN package you make. The problem with this, however, is that you can only append one file extention number per package so complex archives with may mods would only get one. I tested this with my custom package of Castle Ravenpride and the package is named like this: CastleRavenpride-BAIN-11999.7z

Mod management and your own mod catalog:

If you have collected even a moderate amount of mods you may find yourself confronted with a few choices. Do you keep the archives you downloaded after installing the mods either manually or with an installer? Do you back them up multiple times?

Why keep a mod archive even if it is not the archive you use to install the mod in the final analysis? Well there are a few reasons I do this. One being that you never know if a mod website like Nexus is going to go down (knock on wood that does not happen). Another reason being that more than a few times I've suddenly found that a modder had decided to pull their mods and these mods are therefore no longer available ... period. Other reasons could include:

• The length of time it takes to download may be so long that it is better to store them than wait for that again.
• The archives serve as source material and so if you make a mistake repackaging then you readily have the source to fall back on for reference and material.

Even these reasons are going to be mitigated by one overriding factor - disc space. If you have less space then active packages and mods are, of course, going to take precedence over archived and unused mods. Basically keeping archives is a sure way to at the most double the amount of space this project will take. External drives and other storage options are, of course, to be considered.

If one were to opt to repackage archives into another package then using 7zip (linked above) is the best option. A few things to consider with this option. Each update of a mod would mean unzipping the original, doing whatever is necessary like cleaning the plugins, repackaging the archive and then placing that archive in the installers directory.

At each step you would then decide things such as whether to save the original archive or delete it, or whether to copy and paste or cut and paste the new package into the installers directory. Doing things this way one could then have backups of not only the original archives but also the file directories of the new repackaged archives. A smarter move yet is to manage the repackaging and storage on a separate drive from the drive where the game and installers directory is located. In the unfortunate event of drive failure you would have a back up in one place or another.

This was the option I chose for my oblivion install and it consumed enormous amounts of disc space. I have another drive where it is filled with directories where the extracted and recombined archives are laid out ready to be rezipped. I often combine mods into complex packages so if one small esp is updated then I'd unzip it into a folder then rezip the entire package up and copy it to the installers directory. This has resulted in about 3 times the necessary space being used. I will cover best practices for updating packages that will explain how I have the directories backed up in post 5 below.

What follows are links I'd highly recommend reading if you are thinking of a complete reinstall and transition to BAIN:
Tomlong75210's helpful site TESIV: POSItive this site is growing with good information.
There is a section on BAIN Installation of Modded Oblivion that promises to be very helpful.
UESP Tech Support
50_Steps To CTD (Almost) Free FCOM+++ Game (good advice even if not installing FCOM)
Windows Vista Performance Guide For those installing on a Windows7 or Vista Platform and have UAC concerns: The basic instructions are to install these games outside of default locations and thereby circumventing the need for elevated privileges.
The Oblivion Performance Project (some outdated information use with caution, but some gold too).
PyFFI and other optimizations and A new PyFFI tool by Ulrim.

For more information about mod conflicts please read this pinned thread: Compatibility and you

Examples that Wrye made to illustrate how to package mods in order to be BAIN friendly: BAIN Mods and again in his BAIN for Wrye Mash thread he gives a lot of advice on best practices. The BAIN CS Wiki page was also largely written by Wrye.

The best advice managing install orders: Read the Readme!! Next, Use BOSS - both of these overlooked approaches can also give information on how to organize packages.

Edited by Psymon, 30 May 2011 - 05:43 AM.

[Psymon]

Complex BAIN archives
Approaching the ability to make ... Custom BAIN Projects.

By now one should be familiar with the game directory pattern, how mods are often packaged and how to examine mod packaging, What installers do and in particular how the Wrye Bash installers tab operates. Spend some time getting familiar with these ideas and steps and before you know it you will be skipping over the first two posts annoyed by the noobish instructions in no time. This post is really what most of this thread was all about.

Examining BAIN archives

BAIN has a feature that really expands upon what an installer does and what the currently available versions of OBMM cannot do. This is the ability to combine packages (of mods) together in novel combinations. With this feature one could then combine mods together in such a way as to make each addition an option that can be installed or not. Really the only thing limiting the combinations is that the packages are read in a hierarchical manner and one's own imagination about how to combine or break apart archives into sub-packages. Since BAIN (like OBMM) can read one layer further into a packages directory to find the recognized structure of the data directory one can then add other directories that have the similar structure.

Taking our Mod of Awesomeness example above one could then assign an alpha-numeric prefix to each sub-package then as long as each new sub-package has such a prefix then it will be recognized by BAIN and the alpha-numeric ordering will then be the order by which these packages will be installed. The reason for Alpha-Numeric is explained by PacificMorrowind:

the reason is that in computers (at least generally and is certainly the standard in UIs) numbers are sorted before letters... same as underscores etc. (ie like in Windows Explore defaults sort is <underbar and similar chars><digits><letters>)

So, with the lower numbers/letters being installed first (being higher in the install order) and the higher number/letters being installed last (being lower in the install order). This basically allows for micro install order options to be embedded in larger packages.

Mods of Awesomeness-BAIN
   ├[00 Mod of Awesomeness Core]
   │   ├[Docs]
   │   │   └[Quests]
   │   │       └MoA_Readme
   │   ├[Meshes]
   │   ├[Music]
   │   ├[Sound]
   │   ├[Textures]
   │   └Mod of Awesomeness.esm
   │   └Mod of Awesomeness.esp
   ├[10 Mod of Awesomeness Part 2]
   │   ├[Docs]
   │   │   └[Quests]
   │   │       └ MoA-2_Readme 
   │   ├[Meshes]
   │   ├[Music]
   │   ├[Sound]
   │   ├[Textures]
   │   └Mod of Awesomeness part 2.esp

The adding of the BAIN suffix is not really necessary it is one method by which you can track what packages you create as opposed to the ones made by others or it can be used to signify that the package is BAIN ready. Notice I make further directories for the readme which makes them much easier to find. MoA part 2 could easily be an alternate version and so if the esp are named the same then the second loading version would win the conflict and if all the replacer meshes and textures are identical then there would be no need to package them twice and the second sub package could contain only what is different from the core package. These sub-packages will show up in the sub-packages filter and you then have them as options to install.

Pros and cons of combining mods into complex archive packages

The advantages to this are numerous. The primary advantage that it provides is that you can reduce the amount of packages in the installers directory and this makes viewing and organizing then easier. Other advantages include:

• Combine similar mod archives together for central access.
• Combine related mod archives together for central access.
• Combine many disparate yet miniscule mods together instead of having your install order cluttered by packages as simple as a set of three replacers for repair hammers.
• Combine variations on mods in such a way that one could have the core aspects available and many other versions available with the ability to have immediate implementation.
• Combine whatever you like.

Disadvantages include:

• The sub-tabs that keep track of various installed yet separate packages will not read the differences between sub-packages of the same package. It will see all the data contained as one package. The good news is that when comparing to other packages it will only take into account what is installed from each package.
• It is up to the user to make sure that the packages are packed rightly and that they do not inherently conflict in a manner not intended or wanted.
• If updating any portion is necessary then rezipping/repackaging the entire package is also necessary.
• Perhaps forgetting what you packaged?

For myself the advantages far outweigh the disadvantages.

Taking a real world example of the available weather overhaul called All Natural (note it currently has a fix file available but usually not and it is closing to a more complete version one). Extracting the package we see that it is a complex BAIN package:

All Natural-18305.7z
   ├ -- Screenshots
   ├[00 Core]
   ├[01 Real Lights]
   ├[02 Bash Filter For Various Mods]
   ├[03 Nascosto Isles Weather Patch]
   ├[04 Kvatch Rebuilt Patch]
   ├[05 Oblivifall - Losing My Religion Patch]
   ├[06 MMM Patch]
   ├omod conversion data
   ├All Natural Readme.rtf
   ├Wizard.txt

Upon further examination we can see that the individual packages are laid out following commonly adopted rules of BAIN packaging. The mandatory files are in the 00 sub-package. The optional files are in subsequent packages. Also the authors have included extra content of a Wrye Bash filter for use in importing weather sounds to mod added interiors and patches for the mods Nascosto Isles and Kvatch Rebuilt. This is great as it cuts down on other packages just for those patches and extra content. Also of note is the fact that this mod is actually packaged as a triple compliant BAIN package - notice that there is a folder called omod conversion data. What this means is that the package is also ready to be converted into an OMOD for use with OBMM. This means that the OMOD script will seek out the data from the given folders for installing based upon the choices given in the OMOD installation. This is one of the very advanced BAIN ready mods available (and the best weather mod imo). Also note that the twoo hash marks in front of the screenshots folder mean that this sub-package folder will not even be seen by BAIN so you don't have to worry about your data folder being cluttered with screenshots on a mod you already decided was cool.

Repackaging a complex archive example

Taking the above information and considerations we could do this ourselves with existing mods. To illustrate this I will share my repackaging of the quest mod Et in Arkay in Ego I repackaged the mod and combined it with various available patches like so:

Et in Arkay Ego-BAIN
   ├[00 Et in Arkay Ego Core]
   │   ├[Docs]
   │   │   └[Quests]
   │   │       └EiAmod V1-1_Readme
   │   ├[Meshes]
   │   ├[Music]
   │   ├[Sound]
   │   ├[Textures]
   │   └EiAmod.esp
   ├[10 Spiritus Version] - contains only the portions necessary for this au natural version
   │   ├[Docs]
   │   │   └[Quests]
   │   │       └EiAmod V1-1 (spiritus)_Readme
   │   ├[Meshes]
   │   ├[Textures]
   │   ├EiAmod.esp
   │   ├MaleBodyReplacerV3.esp
   │   └TFF_FantasyFigures_Base.esp
   ├[20 Shivering Isles Patch]
   │   ├[Docs]
   │   │   └[Quests]
   │   │       └EiAmod_ShiveringIsles_Readme
   │   └EiAmod_ShiveringIsles
   ├[25 Choices and Consequences Patch]
   │   ├[Docs]
   │   │   └[Quests]
   │   │       └EiAmod_ChoicesandConsequences_Readme
   │   └EiAmod_ChoicesandConsequences.esp
   ├[30 [EiA delayer] -  this is an alternate delayer found here: http://www.tesnexus.com/downloads/file.php?id=25859
   │   ├[Docs]
   │   │   └[Quests]
   │   │       └EiAmod_Knights_readme
   │   └EiAmod_Knights.esp
   ├[30 KotN Patch] -  this original delays the mod till after the completion of KoN available only from authors.
   │   ├[Docs]
   │   │   └[Quests]
   │   │       └EiAmod_Knights_readme
   │   └EiAmod_Knights.esp
   ├[35 [TOTF Patch]: http://www.tesnexus.com/downloads/file.php?id=24624
   │   ├[Docs]
   │   │   └[Quests]
   │   │       └EiA+TOTF Patch_readme
   │   └TOTF-EiAE Patch.esp
   ├[50 [UL Patches]: http://www.tesnexus.com/downloads/file.php?id=13834
   │   ├[Docs]
   │   │   └[Unique Landscapes]
   │   │       └EtinArkay-UniqueLandscapes patches Readme
   │   ├EtInArkay-BravilBarrowfields patch.esp
   │   ├EtInArkay-CheydinhalFalls patch.esp
   │   └EtInArkay-ColovianHighlands patch.esp
   ├[50 UL Patches Merged] - made by myself using the above as sources.
   │   ├[Docs]
   │   │   └[Unique Landscapes]
   │   │       └EtinArkay-UniqueLandscapes patches Readme
   │   └EtInArkay-UniqueLandscapes Merged patch.esp

With this all in one package you will see several features. The core package number 00 to make sure it is always at the top contains all the main replacers needed. The next sub=package contains an esp that would overwrite the esp in the core sub-package if chosen. It also contains supplementary body replacer material for use with that version (although probably best to use other updated body replacers and only the esp here). The next two subpackages are available at the main download page and are to be used only if SI or C&C are also loaded. There are two numbered 30 sub-packages this is a method of saying that the choice is either/or and that one should not install both. The first one is part of another package of quest delayers made by statttis and the second one is (or was) available only by request from the authors. Since I would not want both installed they got the same number sub-package. The next package is another patch made by somebodys_kid for the mod Tears of the Fiend. The next sub-package is a the collected Unique Landscapes patches made by Vorians. And the final sub-package was a merger of the UL patches that is packaged with the other UL patches. It is likewise number the same as the UL patches to indicate that it should not be installed along with the normal UL patches. Notice also, as above, I took renaming the readme into my own hands and added further directories to the docs folder to better organize the ever growing library of readmes (you know ... those things we read after all else fails )

This package therefore contains several examples of the benefits and some of the rules necessary for constructing complex BAIN packages/projects. Later in other posts I will illustrate much more elaborate combinations of mods.

You will find as you go on that there are certain files that BAIN will not install:

• It will not install exe files.
• It will not install archives in a further embedded, zipped/compressed state.
• It will not install or more importantly merge and manage Shader files.

... this is where OBMM performs very well.

If the package contains all the normal types of files that are found in 95% of all mods then there should be no issue as long as it is formatted appropriately. Sometimes, though, a package or mod will require a unique folder to be installed under the data directory folder and it will appear that BAIN is refusing to install it. this is most likely remedied though the installer context menu. Find the problem package and right click on it a context menu will appear and then choose the option 'has extra directories.' In most cases this should resolve the issue.

The context menu has other options as well. Please read the Wrye Bash readme (the most current version packaged with the latest Wrye Bash and accessed with ? button on bottom toolbar of Wrye Bash) for more information. Remember that each package has a context window and the top bar if the package window has a different bar with some global options available for further filtering and package control:

The single most important thing to learn is package colors which indicate the health and status of a package and thereby queue one to read the sub-tabs for more information. After adding and moving packages the most common command you will use is anneal to correct the install of various data files. Just moving packages around in the install order will not automatically remove or add data files one must use the anneal command for that to happen. There is a global auto-anneal feature on the top context menu, but I've still seen examples where it did not kick in and so recommend annealing individual packages anytime you see yellow, red, or orange. These colors may not go away as one package may override due to being at a lower position, but there may be parts that should still be annealed and can be annealed.

Read the Readme!! and Use BOSS - both of the overlooked approaches can also give information on how to organize packages and sub-packages.

Edited by Psymon, 30 May 2011 - 04:45 AM.

[Psymon]

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.

If we look at BOSS master list we also see several categories categories for load ordering which I've reduced down to this more general list:

Earliest mods
NPC face mods
UOP & Vanilla fixes
BSA tricks
Overhauls I - Initial Fran's files for FCOM
Loading Screen Alternatives
Weather mods and overhauls
Sound mods
Lighting
General Base Mods
Map marker Tweaks
Hotkeys
DLC group 
Body replacers
Items (armor and weapons)
Body Replacer Armour & Clothing
Horse Mods
Overhauls - Main FCOM, WAC, TIE files.
Tamriel Travellers
Overhaul compatibility
Post Overhaul
Quests and Locations 
Unique Landscapes
City overhauls
Overrides
Alternative starts
Vampires
Magic
Alchemy
Enchantment
Thievery, Sneaking and Crime
Guards and Bounty
Combat
Skills, Attributes and Leveling
Pose and Animation Mods
Semi-final overrides
Beauty Packs 
Race Changes\Addons
Companions
Respawn & day length overrides
Shader mods

Since mod makers often take into account this evolving load order logic, an argument could be made that often even the replacers they use would account for this as well. There are many many exceptions to this ordering and so again the best place to refer to is the readme of each mod, BOSS, and general advice given in threads.

From my own installers list I've culled a similar install order which I present as my general recommendation for install ordering (Remember though every rule has an exception).

DCL
Unofficial Patches
DarN
Sounds
World textures - expandable
Environments
Weather
Other replacers
Overhauls - much
Overhaul Overrides and Patches
Quests
Dungeons
Locations
Houses
Unique Landscapes
Provinces/LOD
Cities and villages
Roads and infrastructure
Races and Bodies
Companions
Magic
Stealth
Combat
Scaling and leveling
errata
newly acquired and testing mods
my own projects
====
Unused Mods

These lists are not meant to be exhaustive and really are used for determining load order of plugins rather than to be considered for install orders.

I'm certainly not as familiar with Morrowind and what may be the best install order, but plan to research than and will revise this post when I do. The same goes for Fallout3.

The organization of installed packages can itself become a necessity as the list continues to grow. The following are suggestions for bringing order to the installed packages via naming and other methods.

Naming Conventions:

Even with combining replacers and mods into complex packages and mashing as many errata files into other archives power mod users are likely to have an installer tab that is filled with many mods that can become confusing to navigate. This is where naming conventions can come in handy.

The common suffix for BAIN packages is simply the -BAIN at the end of the package. Although not necessary it does serve the purpose of letting one know that the package in question is supposed to be BAIN ready. Prefixes for packages have not been more fully thought out and this is an area where more tags could be used to notify the user of information.

When a package is put in the installer directory and after BAIN scans the package the package is assigned a number that relates to its install order. Because of this there is more freedom in naming the packages than there is with naming the sub-packages of a complex package. Prefixes can therefore be used to further tag a package with information that relates to common install orders or types of packages. Some examples might include:

REPLACER-World Textures-QTPIII-BAIN
REPLACER-Sky Textures Compilation-BAIN
OVERHAUL-Warcry-BAIN
OVERHAUL-MMM-BAIN
DUNGEONS-Dungeon Compilation-BAIN
DUNGEONS-David Brasher-BAIN
QUESTS-Simyaz-BAIN
QUESTS-Dragon Captions-BAIN
HOMES-Castles-BAIN
HOMES-Yevic Homes-BAIN
NEW LANDS-Tamriel Heightmaps-BAIN
NEW LANDS-Elsweyr-BAIN
SETTINGS-Leveling and Skills-BAIN
SETTINGS-Vanilla fixes-BAIN

These could also be abbreviated to one or two letters (I don't recommend numbers). And I'd think it not necessary to add them to every package as even a peppering of them would help the eye train in on what is essential. I've started using these tags with Fallout 3 and when peppered like that they are helping me see what is what faster. Spoiler of that installer list.

Another method is to create Markers to better organize the BAIN archive. They will show up as grey and look like the one that is automatically included named ==last== by doing this one could create dividers for the various packages along the lines of:

==Environment==
==Overhauls==
==Quests== ... and so on.

Using this as section headings you could create a very orderly looking BAIN archive that is easy to navigate and catalog. Sub-packages must be alpha-numeric in their naming in order to determine install order and override logic. Of course the conventions mentioned above do not have to be used. You could number every sub-package the same or different as long as the install order is as you want it and you know how to read it.

A few conventions have been promoted by myself and others:

• If two sub-packages have competing data and only one should be installed then often they are named or numbered the same.
• If mods are packed together and there are several main or core mods then the main mod often gets the numbering that starts a small series (i.e. 10) and each addition to it would complete that series (i.e. 11, 12 ... 16, 17, etc). With the next main mod starting the next series (i.e. 20).
• The core of a mod that is essential is often packed at the lowest number (00 Core Mod).
• Recently the idea of seperating docs into an extra core core package has been promoted (00 Core Mod docs).

The numbering does not have to stop at 99 either. you could number packages 110 ... 120, 125 ... 130, 131,132 ... 140 or as high and complicated as you like. Just remember then that lower number must contain as many digits as the higher numbers so 3 digits would need leading zeroes.

Alphanumeric ordering can be useful too. If all the mods in a package compilation are of the same type or named similarly and/or there is no need for install ordering (between sub-packages) then there is no harm in them having the same prefix designation. Such as the following:
Companion - Baddy
Companion - Eyja
Companion - Neeshka
or you could provide the mod authors name as a prefix if they have several of a type mods like
Umpa - Pose
Umpa - Martial Arts

Another method of bringing order to sub-packages is like the dummy archives above wherein one could create dummy sub-packages. One could make dummy esp (that should never be installed) or better yet rename a small texture into something that would never be accessed by a mod and place into an innocuous texture folder and it will install but not be used. (This is necessary as empty sub-packages will not appear as options in the sub-packages folder.) examples may include:

100 ==Animation mods==
110 Animation Mod A
120 Animation Mod B, etc
200 ==Idle mods==
210 Idles Mod A
220 Idles Mod B
300 ==Pose Mods==
310 Pose Mod A
320 Pose Mod B ... and so on.

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

Updating best practices:

The most important thing to remember is: Renaming packages means reinstalling it.
Sad but true. Unfortunately if in updating a package you misname it or name it differently than what is currently installed then to BAIN it is a new package. You will have to install the package again which may mean reordering plugins and other annoyances.

One method of avoiding this mistake is possible - if you have the disc space for it - is to keep your mod catalog as a directory (preferably on another drive) with all the sub-packages prenamed, organized and ready to be zipped again at any time. What this, in essence, means is having two catalogs - one in the installers directory full of archives (packages) and the other in another directory unzipped yet containing both the downloaded original archives and the unzipped and organized archives. a lot, I know. Really it all about how much you want to get involved in this. External drives and other back up media could be very useful (but not burning one-off kind

When using 7zip to create an archive you will find that by selecting folders to include as sub-packages to an archive that 7zip will automatically name the archive after whatever the directory is one level above the folders selected if they are all from the same directory (you of course can change the name). So if you name that upper/top directory after the name of the future package then that future package is automatically named for you.

Here is the protocol I use for updating:

• Download your updated or original archive you want to include in an package compilation.
• Extract the mod from a downloaded archive into a directory that is laid out like the future sub-packages under the directory named as the archive you want to create (or recreate).
• Remove the downloaded archive and either store it or delete it.
• Do the maintenance required (clean esp, redate esp, edit esp, optimize meshes, rename readme, etc).
• Using 7zip select all the directories you want as sub-packages and click add (green plus sign).

create the archive and it will be named the same as the top directory.

What I do is also have another folder under each package directory called '___source' it contains the original archives (that I save). I've made enough mistakes in packaging that I've learned to save most things because I do not want to re-download repeatedly. the underscore is just a visual clue for me not to include it in the final product.

So here is the Et in Arkay-BAIN directory prior to archiving and installing:

Mod Catalog\Custom Bain Projects\quests\Et in Arkay Ego-BAIN
   │
   ├[00 Et in Arkay Ego Core]
   ├[10 Spiritus Version]
   ├[20 Shivering Isles Patch]
   ├[25 Choices and Consequences Patch]
   ├[30 EiA Patch]
   ├[30 KotN Patch]
   ├[35 TOTF Patch]
   ├[50 UL Patch]
   ├[50 UL Patches Merged]
   ├___Source <- this folder contains the original archives - not included when zipping.
   └ Et in Arkay Ego-BAIN.7z <- the final package to be placed in the installers folder.

Notice the directories above ending in the folder named like the archive created. I keep the extacted folders categorized and cataloged for convenience. Again I admit this is costly to disk space so use your discretion about what is best.

Another tip for speeding up both the compression process and speed up the scanning of new or updated packages is to use very light compression that is preferably non-solid. In the 7zip splash screen you will find Compression level (choose fastest) and further down Solid Block size (chose non-solid). This is again about a trade off as low compression means bigger packages and that means more disc space used. With less disc space you may need to choose high compression and that means a slower opening of the installers tab.

If you are updating a package that is named the same then prior to opening the installers tab remove the old package from the installers directory and replace with the new package (or overwrite). Then when the installers tab is opened it will scan and recognize the changes and give warning in the sub-tabs and in the colors of the packages. Simply make sure that all the options you want are chosen then right click on the package and click anneal. You may need to anneal other packages too and may further need to adjust load order of plugins or bash patch again or related activities.

If you are adding a package that has the same content as another package (such as BAIN ready mods being updated by the authors) and BAIN sees them as discreet and separate packages then it is best to move the newer package to prior to the older package in the install order, install the same options, then uninstall first and then delete the older and later install ordered package.

If you like the file trees I've been using and will continue to use in future posts and want to make them too the tool to use is called FileFolderTree which will create these trees after choosing a directory to scan. Surazal created a Word 2007 Macro enabled document that will take the readouts generated and further reduce them to give only the sub-packages listed provided the sub-packages use numeric and not alphanumeric naming. This is available here as a miscellaneous file.

Much thanks to Surazal for showing me this tool and creating the macro. A macro that you can import into Word 2007 is available in this post. Surazal also provided many suggestions utilized in this selection. And one step further he created a Word Macro Enabled document to update the BOSS master list with your own updates called BOSS Master List Manager (the main download).

Edited by Psymon, 30 May 2011 - 05:39 AM.

[Psymon]

Creating Your Own 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 entire BAIN package list illustrates how to organize such an enormous amount of packages.

To review the pros and cons I'd advise looking at what you want to accomplish. If you want to only use mods and delve into splitting replacers or doing cleaning and optimization of files and prefer easy access to Nexus and more comprehensive conflict reports then I'd advise Tomlong's method of keeping the packaging simple and originally named. If, on the other hand, you know how mods will conflict because you have reviewed that stuff to no end, you want to clean, optimize, break apart and/or combine salient mods together because you 'know' what you are doing then I'd recommend the very complex packages I will describe below.

Of course there is nothing preventing the use of both methods or the creation of your own. As I've learned more of Tomlong's method I would likely do it more that way if I were to reinstall all BAIN packages. That would take several weeks work to do and so not likely to happen. I see the advantages but believe that cleaning mods prior to packaging is the best option, even so in hindsight one could repackage as simple archives and append the file extension. Tomlong's package list comes out to 733 while mine comes out to 211 with each package containing further sub-packages. So whichever method you use (even both) is up to you.

Rationale for Complex Custom Packages

Doubtless as one goes along in collecting and playing with mods there will come a point where they will want to combine mods in a variety of ways. This could be especially true when dealing with replacers like textures replacers and LOD. Often these two types of replacers can contribute greatly to performance lag and so many find that they have to test various different versions of a repalcer or remove aspects of a texture overhaul. Conversely others with a more powerful system may find that they can not only handle their favorite replacers but will want to add even more on top of those replacers. This will be trend as more powerful PC hardware is made available. This balancing act is part of creating a well modded Oblivion experience.

This section will deal with repackaging replacers into BAIN ready archives so that they are both broken down into component pieces and so that they could then be combined together with other replacers.

There is no best practices for repackaging large, extravagant replacers but there are a few things to keep in mind. For one the conflict detection that BAIN offers between packages does not exist within packages and between sub-packages. So with this area of repackaging one will have to be much more conscious of what is being packaged and whether there are inherent conflicts. Doing this can take some time so that is something to consider.

The advantages to repackaging in this manner is really more about preference and control. Preference in that if you only liked certain aspects of a texture replacer, such as the clutter or architecture, and preferred the landscape and plant textures of another replacer set then breaking down the packages could be very worthwhile. Preference also in that this gives further ability to test performance and customize your install to fit the best performance models. Control in that if after building up what you think is a great combination and later find that maybe you need to tone down an aspect this provides a means of doing that be giving the option to remove certain portions.

There are a few different approaches to this. In my older thread I presented a model where I put Everything related to a texture overhaul in one giant archive This, however, has become very cumbersome and not an ideal approach. Primarily I wanted to see if I could do this and having done it the current size of that archive is 7 gigs. In fact so big that it is my intention to break this thing apart and start over. The internal structure though can provide a map for the individual packages.

When examining comprehensive texture replacers one may note that they cover many things from ground and road, to walls and ceilings ... from plants and trees to coins, cups, and furniture. These provide divisions in the texture replacer overhauls that we can use to create packages and sub-packages. When thinking about performance and due to the nature of the game it is easy to see that the game engine is not placed under as much stress when your character is in interiors as when outside and the game is rendering much more information. My own game has rarely ever crashed when my characters have been in interiors. this provides another reason and rationale for breaking apart texture replacer overhauls and packs.

So taking Qarls Texture Pack III into consideration here is a list of the main types of replacers it provides:

Architecture contains architecture folder, Qarl (Chorrol door?) and Wood (as it mostly was worked) textures.
Clutter contains only clutter textures.
Landscape contains landscape folder, Sky (only Snow), Plants (Butterflys?) textures
Rocks Contain only those meshes and textures
Dungeon Base contains Fort Ruins, Misc, Chargen (prisons) meshes and textures [I found no retextures of fort ruins?]
Ayleid Ruins contains only those meshes and textures
Caves Contain only those meshes and textures.
Sewers contain only those meshes and textures.

With these divisions it is easy to see that Architecture and Clutter can be found in interiors and exteriors. While Landscape and Rocks are most often used in exteriors and the rest are various replacers mainly seen in interiors (their interiors). This is not an exact division. Cave textures of course will include the entrances that are in the exterior world as do Sewers and especially Ayleid Ruins, and dungeons (forts). This may concern some but having a forest full of hi resolution trees will have a much greater impact upon performance than one hi resolution fort exterior. I'm certain that these exteriors could be further separated out if one wanted to research what is the exact pieces that are in the exterior. Thematically mixing and matching of textures could also be a factor and although you may squeeze minimal performance out of doing this it may not look great. Again that is a matter of preference.

With the above type of replacers we could then start to create packages in any number of combinations including:
1. Repackage a specific replacer but have the various types of textures further sub-divided as sub-packages.
2. Create solitary replacer packages of both a type and brand (i.e. QTPIII Architecture only).
3. Create combination packages of a type with several brands (i.e Architecture from 5 texture packs each sub-divided into sub-packages).

With thought-out naming and numbering conventions one could even do all three at once.

Taking Architecture as an example for choice 1 above one could create sub-packages for a texture replacer out of each folder within the Architecture folder.

Spoiler

├[anvil]
│ └[anvilinterior]
├[arena]
├[basementsections]
├[bravil]
├[bruma]
│ ├[brumawallset]
│ └[interioronly]
├[castle]
│ ├[anvil]
│ └[cheydinhal]
├[castleinterior]
│ ├[narrowhalls]
│ └[towers]
├[cathedral]
├[cemetery]
├[cheydinhal]
│ └[interior]
├[chorrol]
│ └[interior]
├[daedricstatues]
├[doorstones]
├[farmhouse]
├[godstatues]
├[imperialcity]
│ ├[icbasementset]
│ └[icinterior]
├[leyawiin]
│ └[interior]
├[lowerclass]
│ └[lowinterior]
├[priory]
├[ships]
├[sidewalk]
├[skingrad]
├[statue]
│ ├[bravil]
│ └[kvatchstatue]
├[stonewall]
│ └[bravil]
└[tents]

This would be a very complex task especially if you were to then combine with other texture replacers so that only one option of each is installed. Option 1 above gives a lot of organization over a specific replacer set while Option 2 provides the most control with relation to other replacer sets. Option 3 probably has the main advantage of an economical replacer package in terms of managing your installers tab, but again using naming conventions could again make this redundant.

Of a cautionary note when having textures packs that may lay over the top (be lower in the install order) of other texture replaces it is important to note which versions may also have normal maps and or even meshes.

The main thing you want to avoid is having a texture replacer that also replaces meshes installing prior to a texture replacer that does not. The result could be that the meshes are looking for specific textures and those added by another replacer set may not be what is required even if named the same. The result could be graphic anomalies or performance issues. Of less of a concern is some textures have specific normal maps (texture add ons that give the appearance of a physical surface texture that provides more depth to the appearance of textures in game). More about understanding texture replacers at the Total Oblivion texture Overhaul 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.

Spoiler

LOD Compilation-BAIN
│
├[00 LOD NormalMap Fix MipMap Fix]
├[10 Border Regions Color -pk- 512]
├[10 Border Regions Color Blade -pk- 1024]
├[10 Border Regions Color Blade9722 2048]
├[10 Border Regions Color Shaja 2048]
├[20 Normal Maps -pk- 256]
├[20 Normal Maps -pk- 512]
├[20 Normal Maps CorePC Vibrant]
├[20 Normal Maps Deathb0rn 512]
├[20 Normal Maps Deathb0rn Vanilla]
├[20 Normal Maps Qarl 1024 Reduced]
├[20 Normal Maps Qarl 2048 Reduced]
├[20 Normal Maps Qarl 4096 Compressed]
├[20 Normal Maps Qarl 512 Better Looking]
├[20 Normal Maps Qarl 512 Reduced]
├[20 Normal Maps Xerus 512]
├[21 SI Normal Maps Xerus 512]
├[25 Color Maps Main Landscape -pk- 1024]
├[25 Color Maps Main Landscape -pk- 2048]
├[25 Color Maps Main Landscape -pk- 4096]
├[25 Color Maps Main Landscape -pk- 512]
├[26 Color Maps Important Landscapes -pk- 1024]
├[26 Color Maps Important Landscapes -pk- 2048]
├[26 Color Maps Important Landscapes -pk- 4096]
├[26 Color Maps Important Landscapes -pk- 512]
├[27 Color Maps Less Important Landscapes -pk- 1024]
├[27 Color Maps Less Important Landscapes -pk- 2048]
├[27 Color Maps Less Important Landscapes -pk- 4096]
├[27 Color Maps Less Important Landscapes -pk- 512]
├[30 Color Maps Blade9722 2048]
├[30 Color Maps Blade9722 4096]
├[30 Color Maps CorePC 1024]
├[30 Color Maps CorePC 2048]
├[30 Color Maps Diverse Grasses 2048]
├[30 Color Maps Diverse Grasses 4096]
├[30 Color Maps Qarl Better Tiling 1024]
├[30 Color Maps Qarl Better Tiling 2048]
├[30 Color Maps Qarl Better Tiling 4096]
├[30 Color Maps Qarl Better Tiling 512]
├[30 Color Maps Shaja 2048]
├[30 Color Maps Xerus 1024]
├[30 Color Maps Zacherot 4096]
├[35 SI Color Maps CorePC 1024]
├[35 SI Color Maps CorePC 2048]
├[35 SI Color Maps Xerus 1024]
├[40 Noise Replacer - CorePC]
├[40 Noise Replacer - HTF 1]
├[40 Noise Replacer - HTF 2]
├[40 Noise Replacer - HTF 3]
├[40 Noise Replacer - Koldorn Light]
├[40 Noise Replacer - Koldorn Medium]
├[40 Noise Replacer - Koldorn Strong]
├[40 Noise Replacer - Xerus] Again if the terms are unfamiliar please read over the Texture Overhaul page for more information. This package zipped in a non solid format comes to about 1 gig in size.

Sky Replacers Compilation

This compilation focuses on making the sun, moons, stars, and nebula more interesting. It falls short of Cosmic Sky Cycling because it does not cycle. But, then again one less thing running in the back ground. Actually I went through many of the images with Cosmic Night sky and only liked a handful. Many merely had nebula that invaded the entire sky and drowned out stars or mismatched very badly with existing star mods. Plus, there are many great crafted stars included below. Of the nasa images only nebula that was clear, not glaring, and meshed well with star packs got my inclusion.

Spoiler

Sky Climates-BAIN
│
├[00 Sky Core]
├[10 Sun - Beaming Sunglare]
├[10 Sun - Brumbeck Sky Pack]
├[10 Sun - Natural Environments]
├[10 Sun - Subtle Sunshine[/url]
├[10 Sun - Vibrant Sun]
├[20 Stars - Beautiful Stars]
├[20 Stars - Brumbeck Sky Pack]
├[20 Stars - Fire & Ice 2]
├[20 Stars - Fire & Ice 3 - version 1]
├[20 Stars - Fire & Ice 3 - version 2]
├[20 Stars - Natural Environments]
├[20 Stars - Vibrant Stars]
├[20 Stars - Wolfen]
├[21 Stars 0 - Beautiful Stars]
├[21 Stars 0 - Brumbeck Sky Pack]
├[21 Stars 0 - Fire & Ice 2]
├[21 Stars 0 - Fire & Ice 3 - version 1]
├[21 Stars 0 - Fire & Ice 3 - version 2]
├[21 Stars 0 - Natural Environments]
├[21 Stars 0 - Real Night Sky]
├[21 Stars 0 - Vibrant Stars]
├[21 Stars 0 - Wolfen]
├[22 Stars 1 - Beautiful Stars]
├[22 Stars 1 - Brumbeck Sky Pack]
├[22 Stars 1 - Fire & Ice 2]
├[22 Stars 1 - Fire & Ice 3 - version 1]
├[22 Stars 1 - Fire & Ice 3 - version 2]
├[22 Stars 1 - Natural Environments]
├[22 Stars 1 - Real Night Sky]
├[22 Stars 1 - Vibrant Stars]
├[23 Stars 2 - Beautiful Stars]
├[23 Stars 2 - Brumbeck Sky Pack]
├[23 Stars 2 - Fire & Ice 2]
├[23 Stars 2 - Fire & Ice 3 - version 1]
├[23 Stars 2 - Fire & Ice 3 - version 2]
├[23 Stars 2 - Natural Environments]
├[23 Stars 2 - Real Night Sky]
├[23 Stars 2 - Vibrant Stars]
├[30 Moons - Masser - ANB No Masser]
├[30 Moons - Masser - Better Nightsky 1]
├[30 Moons - Masser - Better Nightsky 2]
├[30 Moons - Masser - Better Nightsky Enhanced]
├[30 Moons - Masser - Brumbeck Sky Pack]
├[30 Moons - Masser - Dione]
├[30 Moons - Masser - Earth Image]
├[30 Moons - Masser - Far&Away3D]
├[30 Moons - Masser - Fire & Ice 2 - Blue]
├[30 Moons - Masser - Fire & Ice 2 - Green]
├[30 Moons - Masser - Fire & Ice 2 - Red]
├[30 Moons - Masser - Fire & Ice 3 - Dark Red]
├[30 Moons - Masser - Hi Rez]
├[30 Moons - Masser - Io]
├[30 Moons - Masser - Krensadas]
├[30 Moons - Masser - Loch Hi Rez]
├[30 Moons - Masser - Natural Environments]
├[30 Moons - Masser - Rhea]
├[40 Moons - Secunda - ANB Earth Moon]
├[40 Moons - Secunda - ANB Hunters Moon]
├[40 Moons - Secunda - Better Nightsky 1]
├[40 Moons - Secunda - Better Nightsky 2]
├[40 Moons - Secunda - Better Nightsky Enhanced]
├[40 Moons - Secunda - Brumbeck Sky Pack]
├[40 Moons - Secunda - Earth Moon Image]
├[40 Moons - Secunda - Europa]
├[40 Moons - Secunda - Far&Away3D]
├[40 Moons - Secunda - Fire & Ice 2]
├[40 Moons - Secunda - Ganymede]
├[40 Moons - Secunda - Krensadas]
├[40 Moons - Secunda - Loch Hi Rez]
├[40 Moons - Secunda - Natural Environments]
├[50 Nebula - Better NightSky Enhanced]
├[50 Nebula - Brombeck SkyPack]
├[50 Nebula - Celestial - Carina]
├[50 Nebula - Celestial - Horse Head]
├[50 Nebula - Cloud Nebula]
├[50 Nebula - Cloud Nebula with star flares]
├[50 Nebula - CSC AntennaeGalaxies]
├[50 Nebula - CSC Bubble]
├[50 Nebula - CSC HorseHeadNGC3576]
├[50 Nebula - CSC Lagoon1]
├[50 Nebula - CSC LMCmosaic]
├[50 Nebula - CSC MilkyWayEarthView]
├[50 Nebula - CSC NGC 6188]
├[50 Nebula - CSC NGC1333 Reflection Nebula]
├[50 Nebula - CSC ngc2207collision]
├[50 Nebula - CSC NGC4526]
├[50 Nebula - CSC OrionNebula]
├[50 Nebula - CSC VeilNebula]
├[50 Nebula - Fire & Ice 2 - Blue]
├[50 Nebula - Fire & Ice 2 - Red]
├[50 Nebula - Fire & Ice 3 - version 1]
├[50 Nebula - Fire & Ice 3 - version 2]
├[50 Nebula - Fire & Ice 3 - version 3]
├[50 Nebula - Natural Environments]
├[50 Nebula - New Nebular 1 - High_2048x1024]
├[50 Nebula - New Nebular 1 - Ultra_4096x2048]
├[50 Nebula - New Nebular 2 High_2048x1024]
├[50 Nebula - New Nebular 2 Ultra_4096x2048]
├[50 Nebula - Real Night Sky]
├[50 Nebula CSC NGC 1365 Island Universe]
├[50 Nebula CSC NGC1333 Reflection Nebula] Sorry I'm not going to include links as it would be a mountain of work to get them all checked and in place. The old thread had a bunch of links, but it also only contained a lighter version of this. That said this package is only 90 mb that is really light considering the amount of diversity it gives to the game. Searching under the names sky, stars, moons, and sun and you will find them.

I may later add other example packages later.

Edited by Psymon, 30 May 2011 - 05:44 AM.

[Psymon]

BAIN Wizards

Many familiar with Oblivion Mod Manager had lamented that BAIN lacked the ability to provide scripted installations of mods that OBMM provided. OBMM is able to modify the Oblivion ini, Mod ini files, rename plugins, arrange package contents and other related goodies that have made it so popular over the years.

In response developers of BAIN have been laboring to create scripted installs with BAIN packages. For a while the most one could have hoped for is what was called triple packaging which meant BAIN ready, OMOD scripted, and packaged for manual installation ease (if that makes sense).

But now BAIN scripted installs are here and they are called BAIN wizards. As this thread is mostly directed at mod users the inner workings of how to create BAIN wizards or edit them is beyond the scope of this thread (and my ability to describe). One of the main developers of Wrye Bash, Lojack, has his own thread for BAIN wizards. If you have questions about current wizards or feature requests that is the place to take them.

Metallicow has created WizBAIN a utility to help in the creation of BAIN wizards ... and other things? Forum Thread

Malonn is also collecting together BAIN wizard scripts and script ideas: BAIN Wizard Installation Project

I will say that I've been very impressed with the progress with this feature. There are several very well put together mods that make use of BAIN wizards and here is a list of some of the best:

Animated Windows Lighting system
Really AEVWD
All NAtural
Better Cities
Lush and Gaudy landscapes and Grass and Tree Mod

With Wrye Bash 292+ Archives that have a BAIN wizard will show up in the BAIN tab as having a magic wand superimposed over them. To begin the Wizard you right click on the package in question and scroll down to where it says wizard and click. This should prompt the wizard to start. At this point the wizard will prompt you for options based on your load order and preferences. It will not install the mod for you just help you choose what packages to install and you must then install the package as normal.

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

BAIN Reading OMOD conversion files

Development on Wrye bash being able to read OMOD conversion files and therefore install OMODs (archives specifically for Oblivion Mod Manager) is happening! Stay tuned as this may be incorporated into the next version of bash (292)!

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

BAIN conversion files

BAIN conversion files are encoded instructions one can create for use with Wrye Bash/BAIN that recombine already existing packages in new ways. These can be handy for making a set of instructions to combine several premade packages into a BAIN compilation.

There is a set of instructions on the Wrye Bash readme for both creation and use of them. What is required is that a user download the archives, add them to their installers directory. With this in mind then it does require quite a bit of work to get them operational with the advantage that one does not need to offer or upload the mods that are going to be combined (although links might help).

Waruddar writes:

The premade packages do not have to be BAIN friendly. In fact, the entire purpose of BCFs is to convert non-friendly packages into friendly packages in such a way that minimizes bandwidth and preserves author's rights.

Without them, there are only two ways to distribute converted non-friendly packages:

• Convert the package manually, and upload the entire BAIN friendly package. Get yelled at by authors who don't want people altering & spreading their work without permission. Possibly consume large amounts of bandwidth if the package is of any decent size (uploading a repackage of QTP3 for instance). End user only has to download one thing and install.
• Convert the package manually, and post instructions on what was done (typically a checklist or similar). Low bandwidth (typically a few kilobytes, more if images are used), no intrusion against author's rights. Time consuming to install since the end user has to do exactly the same things someone else already did. End user has to download the original package(s) and the instructions for the conversion (the checklist).

With BCFs, you have all the advantages of the checklist approach without the disadvantage:

• Convert the package manually, and upload the BCF. Low bandwidth (typically a few kilobytes), no intrusion against author's rights (the BCF doesn't contain any of the authors original files). Quick to install; the end user can get exactly the same conversion in three mouse clicks. End user has to download the original package(s), and the instructions for the conversion (the BCF).

BCF's also have a couple extra advantages:

• The person who originally created the conversion can include custom BAIN readme's, patches, etc without a separate install file.
• The converted file has all the options set that the BCF author chose. Whether the converted package uses solid or non-solid compression, Has Extra Directories, Comments, selected sub-packages, etc can all be pre-filled in.

A BCF is really not that different from a checklist. The main difference is that the BCF is read and used by the computer, whereas a checklist has to be read by a human. What they do is allow one person to do the work that you mention (cleaning, checking file structures, pyffi'ing, etc), and then package that work for other people to use. All a BCF contains is a set of instructions on how to rearrange the files, the settings you used, and any files that the BCF author added or changed. The only thing the BCF automates is all the work you previously did.

Here is a quote from FrodoDarkLord about how to make BAIN Conversion Files:

Basically it works like this- if you want a compilation similar to my weapons archive, but don't want to or can't do all the moving around and rearranging and work that goes into it, the creator of the archive can release a BCF. You then download the BCF, the necessary archives, apply the BCF and remove the BCF and the source archives. You then have the desired complex package, without any remanining clutter or packages lying around your BAIN folder- yes, you do need to temporarily have the source archives in your BAIN folder. However, once you have applied the BCF, you can delete them. And since applying a BCF takes no more than a minute or so, you're not really messying up your BAIN folder.

If you want to create a BCF for a package that contains a cleaned esp, the cleaned esp is packed into the BCF- so you can do that as well. Of course, there's no real benefit for the author of the BCF- just for the user that would like to have a certain BAIN project (for example, one shown in this thread) but is intimidated by all the work necessary to get it right.

For example, I would, eventually, like to have a Darnified UI BAIN package like yours- however, I am lazy and if it means doing much more work than selecting the install options in the OMOD installer, I can't be bothered. So, if you, hypothetically, created a BCF for your Darnififed UI BAIN structure, I would download all the packages you used to create it, then apply the BCF and delete or move the source archives outside of the BAIN folder. I now have the Darnified UI archive without doing any work at all. Win for me, no gain for you- other than being able to easily share your BAIN archives without permission difficulties.

As far as creating the BCF goes, it works in much the same way that you apply one. You have an archive that you want to create a BCF for so you can share it with others (this is the "target archive") and you have the archives whose files went into the creation of that archive (the "source archives"). In Wrye Bash, you select all the source archives, select "Create Conversion", pick the target archive, and Wrye Bash does the rest. The BCF is now in your Bain Converters folder and you can upload it for the enjoyment of others. Again, if there are files in the target archive not present in the source archives (like a cleaned esp for example), Wrye Bash adds that file to the BCF, and when the BCF is applied by the end user, the file is drawn from the BCF archive instead of one of the source archives.

As another example, say you have a quest mods archive (that you created some time ago) that you would like to share with others. Clearly, it would be endless work to get permission to upload the archive (and many mod authors will be opposed to the idea, so you would have to remove those mods and your archive would be incomplete), not to mention it is a huge file. You've also cleaned all the esp's to make sure you have a completely stable game. You then create a BCF. You get together all of the original mod archives that the mod author created and put those in your Bash Installers folder. In Wrye Bash, you select these source archives, right click on them and select "Conversion", then "Create". Wrye Bash will ask you to select a target archive. This is your finished quest mods BAIN collection. You select it in the file browser and Wrye Bash creates your BCF. This will now contain several items. First is the information of what the BCF is trying to do, what its source archives are, what the target archive is supposed to look like, details about the packages in general etc. Since you also cleaned the esps though, and those files are missing from the source archives, these cleaned esps are also present in the BCF (which is just a regular 7-zip archive).

So you're pretty much done with the BCF now and can delete or remove the source archives from your BAIN folder and upload the BCF. Now, someone sees your compilation in this thread, and thinks to himself "Boy, this looks awesome, but darn, that is a helluva lot of work." So now he sees that you've created a BCF to make his life easier, and excitedly downloads your prepared BCF. He reads the readme, and downloads all the source archives - but omits one because he simply can't stand that mod. He dumps all these archives into his Bash Installers folder, puts the BCF in the Bain Converters folder and opens Wrye Bash. He selects all the source archives, right clicks and selects "Conversions" then "Apply" and finally the BCF he wants to apply. Wrye Bash asks him to name the new archive it is about to create, and then does its magic. It will copy the necessary files from the source archive to the new archive except for the missing one, which it simply omits, and then copy over the cleaned esps because those were not present in the source archives. The user now has the full BAIN archive, except for the one mod which he chose to omit. He can now remove the source archives from his Bash Installers folder, removing any unneeded clutter and install and play with the BAIN archive without having done any work.

1. Put the -BFC.7zip into your Bash Installers\Bain Converters folder.
2. Download all source archives
3. Select all source archives in BAIN, right click, "Conversions", "Apply", "Weapon Retextures-BCF"
4. Name your new archive
5. Wait
6. Install new archive
7. Play & Enjoy!

Unfortunately this file no longer is available.

Lojack has created a Nexus page of BAIN Conversion Files with plans to add more once completed.

XJDHDR has also created a Nexus page of Scripted BCFs for Wrye Bashs BAIN installer

I will be honest ... I do not see the value in this function and have only really encountered the above use of it. This could well be my own bias as I see BAIN as a tool for extending and assisting with manual installation and I do not see it as an automated tool that requires no thought by the user. This strikes me as an attempt to make BAIN more of an automated gizmo. What it will not do is the steps I consider necessary to installing mods which include:

• Cleaning plugins (very essential)
• Examining file structure for problems and conflicts
• Other things such as optimizing meshes and renaming readmes

For instance if one were to create a BCF of a popular quest mod that also required cleaning (like Et in Arkay described above). You would download the quest mod's original archive plus all the patches and body replacer information, use the BCF to create a more BAIN friendly and inclusive archive. Upon installing though you would still have a dirty plugin, so you would clean that. This would cause the mismatched sub-tab to show the esp as mismatched. You could ignore that but then if you decide to install a body replacer and it want to anneal out the body mod changes this mod provides then doing so would again give you the dirty plugin installed again.

I concede that for overhauls that do not need cleaning or pure replacers this could be useful. I recall Wrye stating that he included this feature but that he thought it more important to convince mod makers and packagers to just adapt BAIN from the onset to avoid yet more installation steps and problems.

I'm sorry if I sound unfair and I am willing to change my mind with the right argument ... Having looked at it I'm certain that I could whip together a packaged mod compilation faster than I could make a BCF of the same archives. Better yet I could, hopefully, write a passage teaching you how to do it faster too and also encourage more manual installer or modder mentality as well!

So please do not ask me to make any. I will refuse.

I will leave this post open to anyone willing to write a more fair and balanced assessment or expand upon the set of instructions given above.

Edited by Psymon, 20 September 2011 - 03:23 PM.

[Psymon]

BAIN and Other Games

Fallout3 and Fallout New Vegas

The Wrye Flash project (formally Gary Bash). Valda fully ported over Wrye Bash for the fallout games. He has been very conscientious about updating it and even incorporating bash tags particular to Fallout. As of this writing the latest version of Wrye Flash is based on the latest version of Wrye Bash (291). Valda has also contributed to helping squash Wrye Bash bugs. Wrye flash has the following salient features:
1. Is the a fully functional port of Wrye Bash (Usually based off of the latest version of Wrye Bash) to Fallout3.
2. Has complete functioning of BAIN tab.
3. Has working Bashed Patch functions that rival and (in my opinion) out-perform the merged list function of FO3edit.
Valda is actively supporting and updating this utility. So if, like me, you play both games please give him support.
Wrye Flash download page
latest Gary Bash thread as of this writing. If not active then use search.
Wrye Flash for New Vegas
Wrye Flash NV Forum thread

As with Wrye Bash and OBMM - it would not be fair to not mention the competition. Kaburke continues to develop the Fallout Mod Manager and has incorporated several BAIN like features:
1. Meaningful Conflict reporting with data files that are also installed with FOMM or manually.
2. File Manager which allows for functions much like BAIN offers with regard to managing replacers. This addresses one of the main issues with Oblivion Mod Manager but is not implemented in OBMM (only FOMM).
3. Can be tasked to manage either Fallout3 or Fallout New Vegas or both.
Fallout Mod Manager Main Download
Recent FOMM Thread

Morrowind

Wrye Mash for Morrowind has been taken up by Yacoby and he has been slowly importing changes from bash to mash. he has also announced work on creating a core Wrye Bash code that would allow for more easy porting to new games (such as the upcoming Skyrim).
Yacoby Wrye Mash forum thread
Original Wrye Mash Readme
Original Wrye Mash Download
For those that prefer the Mod Manager approach there is a decent port of it here: Morrowind Mod Manager

There are so many Morrowind Tutorials and mod use instructions pages. Here are only a few:
Mod Recommendations for New Players
Morrowind Mythic Mods -has many tutorials for the utilities.
Gluby's Guide to a Modded Morrowind - great if new to Morrowind.

I look forward to adding a section on Skyrim!

Edited by Psymon, 09 June 2011 - 03:58 AM.

[Psymon]

Managing BAIN with Multiple Installs

... Wait did you say multiple installs???

Yes that is right - having multiple installs of Oblivion is now very possible. This is not a difficult issue with the earlier game of Morrowind, but has not been readily available in an automated format with Oblivion until recently. After Nehrim was released many found out that installing it meant messing up your Oblivion installation and that it was either one game or the other, but not both. Several fixes were tried to address this issue (Documented in this thread). Finally Gaticus came forward with a simple yet powerfull tool for managing multiple installs and it works with Fallout 3 as well.

mTES4Manager

What mTES4Manager does is take control of all related folders used by Oblivion on most operating systems. For Vista/Win7 these folders are:
1. The Oblivion Directory - the main game folder
2. The Oblivion Save Game Directory - containing all the save games and the game ini file
3. The AppData folder - contains the Plugins.txt file that records your load order

What the program does is mark these folders and put an ini file in them. It then groups the folders together per installation (called clones). With the program you can create new clones from existing ones and switch the active clones as desired. With each switch the program will swap out the related folders and 'fool' the computer into thinking (anthropomorphically) that it is the same game. The result is that you could have drastically different installations going on each of the folders and switch them as often as you like. Oblivion can be a long game and if you want two more versions going or use Nehrim and Oblivion then it is easy to set up (but kind of a lot of work to maintain). I think this also provides a feature that mod makers would adore if they knew it better: You could have one virgin/modding game an another a testing/modded game.

mTES4Manager is available at Nexus. Several have asked me for tips in troubleshooting the tool. I've not solve all issues so here is my best (and good luck to you):

1. Make sure the original Oblivion Game is installed outside the domain of UAC. If it is not then Wrye Bash will likely already give you grief as it will engage UAC. Do not turn UAC off - just move the install(s) outside of the area it wants to protect.

2. Make sure when switching clones that the related folders are not open in windows explorer or being accessed by any open program such as OBMM or Wrye Bash.

3. You can remove a clone from its control by deleting the ini file it places in the clone. This makes trouble shooting less daunting and you could manually place back whichever clone you prefer if it stops working.

Serious problems should be reported in the mTES4Manager thread.

Multiple Oblivion Manager

Mutliple Oblivion Manager Is an alternate and superior tool based off the shorcommings of mTES4Manager. It performs most of the same functions of mTES4Manager and It has an option to replicate the BAIN archive (Oblivion Mods folder). It cannot manage multiple fallout installs. The notes above apply as well to this tool.

A more advanced version is being slowely developed: MIMI - Multiple Install Manager Interface

I use MOM and recommended it.

Managing Multiple installs and the problem of Wrye Bash

With each install then it is important to note that most of the tools and utilities of the game will remain local to the clone in question. OBMM, Tes4edit, OBSE ... all will stay with the clone they are installed for. You could then have different versions of these tools for each clone too (even different Construction Set versions).

Wrye Bash is the only tool that presents a problem. This is mainly due to how BAIN was crafted. When you first open the BAIN tab and have not adjusted the Bash.ini then Bash will generate a folder outside of the Oblivion game directory (right next to it) called Oblivion mods. Within this directory folder There should be a stucture that looks like this:

Oblivion Mods
   │
   ├[Bash Installers]
   │   │
   │   ├[Bash] contains the files converters.dat and installers.dat (records all BAIN settings and what is installed)
   │   │
   │   └ The actual archive of mods (the BAIN archive)
   │
   └[Bash Mod Data] contains the file table.dat (data about your mods, ini edits, etc.)

Since this directory is not within any of the three folders managed by mTES4Manager they are not local to the game clones and will not change when games clones are switched. This is very problematic as you may want specific mods and replacers for one clone but another set for another clone - as soon as you switch and open BAIN you will see a nightmare of various colors which makes the point of using BAIN pointless. (the game data files are not affected but the tracking of it by BAIN is once a new data folder is presented to it). There are two solutions to this each with their own merit.

Solution 1: Multiple BAIN Archives - available with Wrye Bash 291 or older

For both solutions one must use the bash.ini - which is made by taking the bash_default.ini and copying it then renaming to just bash.ini

This has been the main solution until very recently. It is not outdated, as it has advantages of its own. This makes use of a single bash.ini setting:

;--sOblivionMods is the Alternate root directory for installers, etc.

;  It is strongly recommended that you do NOT put it anywhere under the
;  Oblivion install directory itself, because Oblivion.exe will search through
;  every directory under the install directory.
;  This "directory thrashing" can then cause performance problems during gameplay.
;  sOblivionMods is defined specifically to circumvent this bug by storing files elsewhere.
sOblivionMods=..\Oblivion Mods

With this you can change the location of the OBlivion Mods directory and all it contains (including all BAIN archives). By moving this folder you can therefore create a different BAIN archive for each clone (install). So one install might have:

sOblivionMods=G:\Bethesda Games\BAIN Archives\Oblivion Main Mods

and another might have:

sOblivionMods=G:\Bethesda Games\BAIN Archives\Oblivion Alternate Mods

For Nehrim perhaps:

sOblivionMods=G:\Bethesda Games\BAIN Archives\SureAI mods

The benefit of this is that each BAIN archive is discreet and separate from each other. This could be advantageous for some and in some circumstances. Say you want to keep the BAIN mod archives separate as might be the case with Nehrim where they likely need translating to that game before they will work.

The advantages of this are:

• Each BAIN archive is unique and can be taylored to each install.
• If small the BAIN tab will open faster.
• Less clutter on the BAIN tab.

The disadvantages are:

• It multiplies the amount of hard drive space needed to have multiple BAIN archives
• Makes updating take longer as you will need to update BAIN packages in multiple locations.
• Not all BAIN packages available in all installs (initially)

Solution 2: One BAIN archive for Multiple Installs - Available to those who use Wrye Bash 292+

Thanks to Lojack two new ini options have been added:

;--sInstallersData is the directory containing data about which installers
;  are installed by Wrye Bash.  This is where 'Installers.dat' and 'Converters.dat'
;  are stored.  Only change this for advanced configuration, such as when using
;  mTES4 Manager to manage multiple Oblivion installs.
sInstallersData=..\Oblivion Mods\Bash Installers\Bash

;--sBashModData is the directory containing data about your mods, ini edits, etc.
;  Only change this for advanced configuration, such as when using mTES4 Manager
;  to manage multiple Oblivion installs.
sBashModData=..\Oblivion Mods\Bash Mod Data

With these one can now move the locations of the data about the BAIN archive instead of the entire archive. The point would be to move these to locations that move with the clones (installs). For example here are versions that would work:

sInstallersData=F:\Bethesda Games\Oblivion\Mopy\BAIN
sBashModData=F:\Bethesda Games\Oblivion\Mopy\BAIN

What this does is assigns the files to a new folder within the Mopy folder called BAIN (would need to create that folder). Then with each install these files could contain differing reads on the same BAIN archive.

The advantage are:

• Less Hard Drive space used up, as each installer only exists once on your harddrive. If you have 4 Oblivion installs, you could (potentially) have 4x the hard drive usage from BAIN. This is of course assuming that every package you have is in each Oblivion Mods folder.
• Easier updating. When a new version of, say OOO comes out, you only have to update the one BAIN folder, and each Wrye Bash instance sees the updated package. If you went with the 4 BAIN folders in the above example, you would have to copy the updated BAIN into each Oblivion Mods folder = 4x the work (potentially)
• And one that wasn't mentioned yet: Creating a new clone/image of Oblivion would need to make a copy of that Oblivion Mods folder. Depending on the size, this could take a while.

Disadvantages are:

• Updates to a BAIN package have the potential to screw up each Oblivion's install archive. Say Clocks of Cyrodiil comes out with an update. You download the BAIN, plop it into the shared Oblivion Mods folder, each Wrye Bash instance sees the updated package. But...this time you're unlucky. You managed to download a corrupted zip file this time, one that triggers a bug in Wrye Bash so you can no longer refresh the Installers Tab. Now each instance of Wrye Bash will have that problem until you remove the offending archive.
• Some of your Oblivion installs may not require many of all your installers. Say you have a very slimmed down clone, that only uses 10 out of 300 of your installers available. The refresh time of that instance of Wrye Bash still has to look at each of the 300 installers on startup. The refresh time for any "zipped" installers (7z, zip, rar) is very quick, so not too bad. Nothing like the data folder scan, where CRCs have to be calculated.
• Also, as we currently have no good way of hiding installers (the popup menu->Hide command just moves the installers, not viable for a multiple Oblivion, single BAIN setup). So you'll end up with 280 unused installers, probably sorted to the bottom of the screen. Not a huge deal, but it gets in the way.

One install might have QTPIII installed while another would have Vibrant Textures. The limit is your imagination and what is available. Each install would have its own install order to read from the BAIN archive and its own set of markers and so on. It takes some getting used to this as each install would then read alterations to BAIN packages. If you alter one BAIN package in the BAIN archive then all installs will see that change. This makes updating easier but tracking alternate packages more difficult. ** Warning this does not address hidden files or hidden save games. The location of these will be shared between the clones with this solution.

You can switch over to this kind of system easily. Just back up this data (highly recommended in case you miss a step) then move it with bash closed. Alter the ini to point to the new location of these files - then open the BAIN tab and check to make sure it worked..

At this point I use both a shared BAIN folder and game dependent BAIN folders. I have three installs that share the same archive and two other installs that have their own (one for mod testing/making the other is Nehrim).

Other Methods and notes:
Infinite Oblivions
This method holds a lot of promise and is stable. With it you can set separate or shared BAIN archives for each instance/install of the game. Essentially an Oblivion.ini tweak. Change this line like so:

bUseMyGamesDirectory=0

Which then moves all the info about save games and what plugins are active to the local install folder.

The major drawback comes when using tools - specifically TES4Edit and TES4LODGEN. Both look in the AppData\Oblivion folder for the plugins.txt. Since infinite Oblivions moves this file to the local install directory these programs cannot find it and there is no mechanics for having them look for the correct files.

Multiple Installs - One Wrye Bash
I'm not sure when this feature was implemented into Wrye Bash. It is a feature in at least version 295.3+. If one only installs the data folder from a wrye bash package into each install and then move the Mopy folder to somewhere else (outside of an install) then on starting the wrye bash launcher one will be prompted with a question of which game they want to manage (Oblivion or Skyrim).

This however really cannot work with multiple installs sharing the same BAIN archive or infinite Oblivions - so far. Perhaps with further ini settings or at least being able to locate the bash.ini in the local game directories this could then work for those cases too.

As it is this only manages things correctly if the BAIN archive location is in the default location. It will work with MOM if MOM is set to copy the BAIN archive and has. The only advantage I see to this is having to update only one Mopy folder with each update of bash. Until more options are implemented I will not consider this viable.

Tip for starting a new install...
If you copy and paste over the Bash.ini and the Installers.dat, converters.dat, and table.dat to the new install you will find the installers tab already configured with all the installers in the order you had from the install you copied from markers and all. It will show all the packages that were installed in the other install as red - simply opt to uninstall all packages and you are good to go. Might be worth checking if other settings also got copied over or if you want them.

This post will likely be edited further later on.

Edited by Psymon, 29 January 2012 - 08:09 PM.

[Psymon]

An open letter appealing to the use of BAIN and Wrye Bash by mod makers

Having used BAIN since it was created I realize that I've become very used to using it. Not that I consider myself a Wrye Bash aficionado as there is much about the program I definitely do not know how to use. Part of my goal for writing this thread was to introduce the idea that BAIN really is not that complicated. I suspect that my style of writing may not have been conducive to this goal though as I prefer prose writing to technical writing. I picked up BAIN pretty quickly and have found that most people do as well. I wrote the first thread Custom BAIN Projects only two months after the program feature was implemented and only after 6 months of really getting into modding oblivion. My point being that BAIN is not really this arcane and needlessly difficult utility and is actually intuitively easy to pick up.

A few years ago mod cleaning was still pretty new and today it is now common practice by many modders to clean their mods prior to release. Mod packaging, however, has remained an area of mod making that has not taken advantage of the tools available.

While there are many mods that are BAIN ready they are only out of simplicity and default. I'm surprised at the number of new mods that are not BAIN ready and could very easily be made so. Mod packaging is intimately entwined with mod installation. They are two sides of the same coin. To create a mod then package it in such a way as to necessitate the user repackaging it just to use the mod is asking for needless problem reports and posts. In the few years of posting on these forums I've seen a connection between the number of problem reports and how mods are packaged. This is not to say that all problems will go away with BAIN friendly packaging and in some cases there will be those who do not like it. The reports I've seen for BAIN installation of are usually brief and are not ongoing drudgery of the same issues over and over again.

For simple packaging this will not matter as a simple BAIN ready package does not have multiple folders and sub-packages and looks indistinguishable. There are distinct advantages to releasing your mods BAIN ready and furthermore BAIN ready to the degree that it is a complex package. Doing this allows you to organize your mod in such a way that installation is also organized. This is especially true for mods that require the use of Wrye Bash and bashed patch, since that tool will be used anyway.

FCOM is such an example. It is the ultimate WIP for Oblivion. Some salient points being that while two of the four main components (MMM and FCOM patches) have been regularly updated and the readme for those have also been updated the other components remain in inconsistent packaging. This is compounded by the fact that the main readme has not been updated to keep pace with the FCOM patches available. The result is that the FCOM thread consists of many posts about installation questions. This could be remedied by better packaging and distribution of the material. While the rest of this open letter will address FCOM as an example please consider how your mod may be made more user friendly by adopting BAIN ready packaging.

Reasons for utilizing BAIN:

• The current installers are a pain (exe for OOO and FRANS).
• The diversity of and conflicting instructions provided.
• A lack of coherent install method for all portions involved.
• Requirement to look elsewhere for OMOD scripts for many Mods.
• Current installation methods do not promote use of Wrye Bash.
• Begs for more installation problem reports.

To summarize the advantages of using BAIN packaging for your mods:

• Promotes users thinking about modding and manual installation.
• BAIN makes manual installing easier.
• Any BAIN ready mod can also concurrently be made OMOD compatible via OMOD scripting.
• BAIN encourages further use and integration of Wrye Bash.
• Bain now has Wizards that provide for scripted installs.

BAIN is not necessarily more complicated and the mods that are BAIN ready do not have their relz threads filled with endless questions about how to install them - whereas the FCOM oriented mods that are at best offered in exe format or with a third party OMOD script are overflowing with questions about how to install. FCOM which depends upon Wrye Bash to even function that having them BAIN ready would be beneficial and have the users first introduction to the use of Wrye Bash be the installer tab and not the creation of a bashed patch. Further, nothing in FCOM relies upon an ini or is OBSE dependent so there is no need for OMODs to configure anything and when it comes down to it and really it is about choosing plugins and bashing the patch.

A big part of FCOM - the bashed patch (which is not a simple concept nor easy to pick up that well) is required and discussed in detail in the FCOM readme, but then it is recommended that one use a completely different installer utility for installing the mods than one that will use for making the bashed patch - when Wrye Bash can do it all. At times the message with FCOM is 'this is advanced and not for new users' but then when it comes to use with installers the more simple version is the recommended method. This seems strange.

Finally, why not? Is there a better installer everyone is waiting for? Certainly it is worth noting that BAIN is still under active development and support from multiple individuals unlike OBMM which is considered a finished and for the most part un-supported installer. Until the time that the above is addressed expect others to provide their own solutions - why wouldn't they? It has been a year now that BAIN has been available in its current form. People are using it, many mods are now best installed with it, and adapting it for FCOM's primary means of installation would end many questions and remove the need for third party instructions. Further now there are two newer resources to send a person to if they do not understand BAIN.

In conclusion I'd like to emphasize that I intend no bashing or flaming here. They are your mods, your creations. I'm merely attempting to get you to think about packaging as a tool to promote your product, make life easier, and reduce bug reports.

Thank you for reading and considering the above.

Edited by Psymon, 25 June 2011 - 05:25 PM.

[Psymon]

Related Topics

===========Why use a Bashed Patch?===========
This was originally a post I made in a thread debating which is better to use a bashed patch or merged patch (created by FO3edit) with Fallout 3. Since then I've cited that post to people asking me why use a bashed patch. So in order to make it simpler to access and possibly save from forum pruning I'm copying it here and editing it:

A bashed patch is a lot of things today. Originally it was a way of merging leveled lists. The issue being that multiple mods that alter or add to leveled lists and loaded into a more traditional load order would still be subject to the rule of one: that the last loaded mod would win the conflict.

So having mod A that has leveled list encounters added - say ancient snow yeti of 5 variety then have mod B loaded after that adds purple ants. With that scenario (and if I understand correctly - always willing to be corrected I am) then the Yeti might not appear as the lists with ants would override the mod A list.

To resolve that the tools for merging lists were created. With Morrowind I believe TESTool was implemented. With Oblivion Wrye Created Wrye Bash and it is still the most developed version of the Wrye tools. He then went back and created Wrye Mash for Morrowind. He announced that he would not create one for F3 as he planned not to play or mod it in favor of having a life (good for him). So it has been late in coming for F3. Elminster stepped up and implemented the most bare bones version in FO3edit called merged list plugin - which merged list doing the basic necessities so that lists do not block each other. It is cumbersome though by comparison to Wrye Bash and lacks many things that WB can do that no other program does.

Here I detail to the best of my limited ability things that Wrye/Gary Bash can do in addition to just merging leveled lists. I quote:
1. Merged Mods - if a mod is in the load order that only changes existing records (of either the main esm or even other esp) then that entire mod can be merged into the bashed patch. It can then be left deactivated. This greatly reduces the number of esp you need active and makes it so that you can have well beyond the 254 limit of mods. My oblivion install is near 380 esm/esp. This is also internally consistent in that the order in which mods are merged is also a the order in which records are over and under written. So like all the merged mods are merged and then even in that there are conflict winners and losers.

2. Bash tagging - with these tags (only viewable in Wrye/Gary Bash) you can tag a mod with specific tags so that the records indicated by these tags will carry forward and be merged/bashed patch winners even if they would normally be losers - this is great for when you need the merged mod to lose at some records but win at others. Another example of bash tag usage is that you could import records from a mod without ever even needing to activate or merge the mod. This is usually though for graphics mods like lighting or face data.

3. Game Settings. Again like tags this is an area of growth with each new update. With these then you can have game settings like crime detection, Bounties, Length of time essential NPCs are unconscious and many other settings become settable with each new bash. So if you set essential NPCs to become unconscious for 10 seconds and then after playing find that is too short rebash and set for a minute.

With Wrye Bash this is getting into some pretty arcane and cool things which is in turn out dating many other mods and thereby shrinking the the load order further. A well made and full bashed patch can almost constitute an overhaul in and of itself. I'd add to that even with all these settings bash will remember your last settings on each new bashed patch so that you don't start from scratch each time.

So with these extra abilities then merging mods like Project Beauty in with the overhauls gets much easier. Of course a person can record by record, edit by edit create a merged patch with whatever of whichever mod winning at each occurrence of conflict. It can get that detailed and you can go there with edit, but most people do not want to go there and so when it comes to doing basic merges bash provides more that can be merged, greater ability to adjust now things are merged, the ability to save mod slots and so on.

===========Other Bethesda Game Interests of Mine===========

Nehrim
Nehrim SureAI Forum
Nehrim Bethesda Forum Thread

This led to my exploring how to run Nehrim and Oblivion at the same time and then how to mod Nehrim. This information is collected in the thread:
Nehrim and Mods

Edited by Psymon, 11 August 2011 - 02:24 AM.

[camaro-69_327]

Nice Job on the Guide.

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

[Tomlong75210]

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.

Edited by Tomlong75210, 01 April 2010 - 04:32 PM.

[Psymon]

Psymon, I can make space for you 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.

Edited by Psymon, 28 March 2010 - 08:05 PM.

[Tomlong75210]

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

[Waruddar]

Very informative post!

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.

BAIN conversion files

BAIN conversion files are instructions one can create to recombine already installed packages in new ways. These can be handy for making a set of instructions to combine several premade (but BAIN friendly) packages into a BAIN compilation.

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.

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 esp, examining file structure for problems and conflicts, and other things such as optimizing meshes and renaming readmes.

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.

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!

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.

[Psymon]

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.

[Surazal]

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.

[Waruddar]

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.

Edited by Waruddar, 29 March 2010 - 01:19 PM.

[Bal Cleric]

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.

[Tomlong75210]

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 a guide 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/ )

[Psymon]

Honestly, I don't know of many examples floating around. ...

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.

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.

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.

Hence the necessity of threads like this. If BAIN were adapted

In theory, I could do the same thing with CBash with cleaning the esp. I won't though.
.
.
.
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.
.
.
.
So, sometimes a "dirty" edit is quite intentional.

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.

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.

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

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.

Edited by Psymon, 29 March 2010 - 04:27 PM.

[camaro-69_327]

I have finished the first draft of a guide 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/ )

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

[Tomlong75210]

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

Edited by Tomlong75210, 29 March 2010 - 05:20 PM.

[Psymon]

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.

Edited by Psymon, 29 March 2010 - 05:20 PM.

[camaro-69_327]

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

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.

Edited by camaro-69_327, 29 March 2010 - 05:26 PM.

[Tomlong75210]

When you run the Frans EXE and change the installation path, does it end in "Oblivion" or "Data." I need to know what the folder structure is after choosing a folder to install it too.

[camaro-69_327]

When you run the Frans EXE and change the installation path, does it end in "Oblivion" or "Data." I need to know what the folder structure is after choosing a folder to install it too.

Just Fired up both Installers for Frans this was the Defualt path for me......C:\Program Files (x86)\Bethesda Softworks\Oblivion\data

That was already There, thinking Frans installer pulls that data from the Registry? That IS where my Oblivion install is on Win 7.

Edit:

Changed the Default Path to this
c:\Temp1

All the ESM/p files end up in the top folder . another folder is created under that .. C:\Temp1\Francesco's mod has all the readme and Link to Forum, next is C:\Temp1\Francesco's mod\Unistall data empty cept for next Folder C:\Temp1\Francesco's mod\Unistall data\Main files 2 files in here...unis000.dat and Unis000.exe

It all depends on what you select while installing Frans.

Edited by camaro-69_327, 29 March 2010 - 05:46 PM.

[Tomlong75210]

Just Fired up both Installers for Frans this was the Defualt path for me......C:\Program Files (x86)\Bethesda Softworks\Oblivion\data

That was already There, thinking Frans installer pulls that data from the Registry? That IS where my Oblivion install is on Win 7.

Edit:

Changed the Default Path to this
c:\Temp1

All the ESM/p files end up in the top folder . another folder is created under that .. C:\Temp1\Francesco's mod has all the readme and Link to Forum, next is C:\Temp1\Francesco's mod\Unistall data empty cept for next Folder C:\Temp1\Francesco's mod\Unistall data\Main files 2 files in here...unis000.dat and Unis000.exe

It all depends on what you select while installing Frans.

This is very helpful, thanks. What I was trying to determine was whether the Fran installation was adding a data folder to the target folder, or whether it was installing to the target folder directly.

Edit: Are the instructions clearer now? The other reason not to go that route is you have to remove the extra junk from the Francesco's mod folder. I will just have users move the ReadMe out of the "Francesco's mod" folder and then delete the folder. The link to the forum must be out of date by now...it's been ages.

Following those instructions, did the Fran installer install the creatures-items ESM? the one FCOM users should not use.

Edited by Tomlong75210, 29 March 2010 - 06:31 PM.

[camaro-69_327]

This is very helpful, thanks. What I was trying to determine was whether the Fran installation was adding a data folder to the target folder, or whether it was installing to the target folder directly.

Edit: Are the instructions clearer now? The other reason not to go that route is you have to remove the extra junk from the Francesco's mod folder. I will just have users move the ReadMe out of the "Francesco's mod" folder and then delete the folder. The link to the forum must be out of date by now...it's been ages.

Following those instructions, did the Fran installer install the creatures-items ESM? the one FCOM users should not use.

Frans is a tough one cause of the EXE....I just redid the Install into that temp folder and Got a differant Size ESM for frans. this time it is Smaller then the one I have installed? I picked default Cell respawn AND default Day Length...

Also I dont see mention of ....Lycondor Combat Behavior?...That is the Choice before you pick MOBS.....I thought Mobs was a NO for the OOO version? and that we install OMOBS over everything? Ahhh Wheres CorePC you should be Picking His brain...lol

[Tomlong75210]

Frans is a tough one cause of the EXE....I just redid the Install into that temp folder and Got a differant Size ESM for frans. this time it is Smaller then the one I have installed? I picked default Cell respawn AND default Day Length...

Also I dont see mention of ....Lycondor Combat Behavior?...That is the Choice before you pick MOBS.....I thought Mobs was a NO for the OOO version? and that we install OMOBS over everything? Ahhh Wheres CorePC you should be Picking His brain...lol

OMOBS is related to MOBS. The FCOM setup contains OMOBS and MOBS components and tweaks where necessary (i.e., with FCOM_Francescos.) However, not all of the MOBS settings are different. ONLY use the options listed in that section. You do not HAVE TO use the ones marked "(Optional)."

Edit: I need to add Lyondor's combat behavior. That should be used as well, thanks.

Edited by Tomlong75210, 29 March 2010 - 07:07 PM.