I'm not sure how many times you all have had to deactivate your load order for troubleshooting an unknown crash.
After a dozen times of doing this, I finally decided to wise up and create a method that would allow for easier tear down and re-build of my load order...

Using this naming method allows you to keep track of the order in which you load your mods. As we all know, the way you load your mods can effect many different things, such as which textures will show up in game etc...

It's simple...

Start naming all of your OMODS like so...

000 - Name Of Mod
001 - Name Of Mod
002 - Name Of Mod

If you find that you meant to put "x" mod where 001 - mod is, you can always do this rather than start renaming from scratch...

000 - Name Of Mod
001 - Name Of Mod
001a - Name Of Mod
002 - Name Of Mod


Using this naming scheme will also allow you to run an semi-automated mod re-install by choosing the "Activate Filtered" option. OBMM will automatically activate all mods according to the numeric order. All you have to do from there is is choose the options for your scripted OMODS.

From there, just import a backup of your Load Order and re-create your bashed patch Use BOSS if you want to double check that your load order is correct.


What are some methods you guys use?

EDIT - Spelling

I use BOSS. Seems to be working great. Havn't had a conflict or crash due to a mod...yet. Just have to manually put the mods it cannnot recognize into a good position in the load order which isn't too terribly difficult. So no more time consuming manual load orders.

I use Wrye Bash's BAIN function for installation, because of its much greater control over install order. You can actually adjust your install order without uninstalling anything by moving things up and down a list and using the anneal function.

However, your naming scheme sounds very handy. It is similar to something I do with my folders before moving them into the BAIN install folder
1 Utilities
2 Patches
3 FCOM + COBL
...etc. All with subfolders. Then, I can go through each folder in order, and as I get a particular subfolder installed, I rename it to begin with D for done or with X for not installed. So, after installation the 2 Patches folder contents would look like this:
D UOP + hotfixes
D DLC UOP
X Refurbed DLC patches

Very easy this way to return to an unfinished installation process and be able to tell at a glance where I left off.

gothemasticator

I've found that BAIN is more reliable and faster than OBMM for most mods, end most importantly it keeps track of conflicts properly. Psymon's http://www.gamesas.com/index.php?/topic/957424-custom-bain-projects/ has become somewhat of a bible to me since re-returing to Oblivion.

I use BOSS as well, but after I've decompressed all of my OMODS. What I am speaking about above is just for decompressing OMOD archives in a specific order that helps prevent unwanted mod conflicts and file overwrites. Sure OBMM reports these things, but it becomes very difficult to remember how you loaded 200+ mods after a while. :facepalm:

@PetrusOctavianus & gothemasticator - I tried BAIN once. Just couldn't get used to it. Unless there are some features that I am unaware of which make it WAY better than OBMM, I just don't see the need to change yet. Wrye Bash was hard enough for me to use at first. Shows you how well i do with different software interfaces. :blink:

Installing with OBMM only gives you the option to overwrite this or that file or not. So, with texture replacers, for instance, if you install 5 of them and later want to uninstall the 3rd, you have to uninstall number 3 and then reinstall numbers 4 and 5, else some intended textures will be missing.

In BAIN, you have your 5 replacers listed in install order. You can see at a glance which files are going to overwrite which. If I don't like what I see, I can simply change the order and voila! a new set of overwrites, more to my liking. In addition, if I decide to uninstall number 3, I just uninstall it. BAIN autoanneals, filling in any now-missing textures from the other mods. No additional uninstallation necessary.

There are other benefits, too, but that one is the one I appreciate the most.

gothemasticator

BAIN over OBMM: reason - for what

#1 Conflict detection - (overlapping files) overhauls, cosmetic mods, replacers

#2 Why waste time renaming archives, files, OMODs, whatever, when BAIN has prioritized loading - multiple textures, cosmetic mods

#3 You can modify installed packages (without reinstalling the entire thing) - overhauls

#4 Faster

#5 You do not have to have BAIN open to modify archives or packages.

#6 BAIN is less sensitive to packaging. For example, if a mod is packaged [somemod.7z > somemod(folder) > Meshes, Textures] BAIN still works

#7 It is a part of Wrye Bash

#8 You can view conflicts between archives that are not installed, what conflicts are higher, what conflicts are lower (priority)

#9 BAIN does not have to be restarted after installing big mods like QTP3

#10 It does not fail to install plugins when there are plugin conflicts.

#11 BAIN does not complain at your when you try to delete a plugin that does not belong to it.

#12 BAIN does not complain at you for making changes it does not know about.

#13 When you uninstall, the correct lower priority versions of files are reinstalled

#14 Comments for archives


OBMM over BAIN

#1 scripts

#2 scripts for people who do not know how to make scripts

#3 scripts for people who do not (want to) read ReadMes

#4 shader packages

#5 scripts INI changes (although Wrye Bash has INI tweaks)

#6 One required download instead of three to get it up and running

#7 RESET BSA TIMESTAMPS

#8 BSA BROWSER

#9 BSA CREATION


In conclusion, use both. BAIN kills OBMM in the installation department for users that have read ReadMes or are familiar with their mods. However, OBMM has userful utilities that are not a part of Wrye Bash. That specially renaming archives with the number would annoy me, especially when you edit an OMOD and the OMOD data overwrites your manual name change. You have to make sure to check that before you click create OMOD, or you are working all over again. If I want to quickly try out a new mod and put it in the right spot in my package list, that is as easy as finding the right section header, doing a quick move to, and hitting install. No renaming or any other extra hassle.

I agree that if you do not want to READ, stay away from BAIN. You will only frustrate yourself.

@gothemasticator- that is a very cool feature. Thanks for explaining the process.


@tomlong- thank you for laying out many possitives/negetives in both .


I hope you aren't implying that I don't read readme files... Cause that wouldn't be very nice.

Of course not, I have seen you around the forums. Seriously though, BAIN is allows users the freedom of manual installation, which gives many opportunities for errors when you do not first read about the installation process. At least, undoing those mistakes takes little to no time.

In addition to BAIN and OBMM, TES4FILES by MentalELf is a useful utility for (re)packing BSAs, as it will only include the files that the mod actually uses and it can fix incorrect Meshes file paths.

My procedure for installing a regular one ESP quest mod is:
1. Unpack to a new folder.
2. Clean the ESP using TES4EDITand Pyffi the Meshes.
3. Use TES4FILES to make a BSA file. Options: Fix NIFs, No LOD, No Compression. BSAs count towards the 375-400 file "thrashing" limit, so don't use BSAs if they only end up being a few MB.
4. Pack the ESP and the BSA into an archive that BAIN can read and move it to the BAIN Installers folder.
5. Make notes of what treatment (cleaned? Pyffied?) the package has had and install the mod.
6. Run BOSS to get the correct load order.
7. Make a new Bashed Patch using Wrye Bash.
8. Use TES4LODGen to generate new distant LODs.

Of course, this depends a bit on who made the mod. Not all modders are tech geeks like Arthmoor and Vorians.
If the ESP and meshes has already been "treated", then only steps 5-8 are needed.

Woah! Now this is intro to the http://sites.google.com/site/oblivionpoinfo/utilities, dude. You can save your breath. ^__^

@PO - good call! I used that to repair my file paths before I built an OOO.BSA. Can't remember who told me about that tool now, but they saved me such a huge headache! If anyone has benefited fro tes4files, drop what you are doing now and go to that thread to give thanks.

@TomLong - dont mind me man, I was just getting off work earlier and was still irritable from the long day. I'm interested to check out ur link. Don't have the time right this minute. Thanks again for all the helpful tips.

EDIT - Actually took a quick peak at it. DUDE! Why haven't I seen this before? You have a really nice site there. :goodjob: Have you thought about adding info about the 4gb LAA patch within the stability section?

I realize this was not a thread comparing Bain to OBMM But i would have to agree here..Give BAIN another go Far327 you wont ever go back! you will See things that you never knew were a problem . I had all my mods installed as .omods and i mean ALL. One by one I converted them to BAIN. Uninstalled the .omod thru OBMM, Then installed with BAIN. Doing it this way I was able to Keep an eye on my save file and keep it either Green or pink. Was a great way to learn the ins and outs of the BAIN way of doing things.

I think I will give it another shot then. I feared the idea of having to learn a new tool and screwing things up as I am very comfortable with my load order using OBMM, but there are still a few kinks I would like to work out on a few mods still causing some issues.

Ahhh...then you Can do it the way I did....

I did this with a Level 7 game. With 10 saves in different places. I picked one mod Dark Darn UI (I do NOT recomend you start with that if you use it)and In OBMM i right clicked and "extract to folder" extract to the BAIN directory. Many of your .omods will just be ready for BAIN. Many will not. Keep your Saves Pink and the Game Will Never know you did a thing!

IF you need i can elaborate this further...