Mod Manager messed up Oblivion?

[Striker879]

Don't worry I'm the same. I held off on installing OBSE for the longest time, until I just had to have a mod that required it. And in the cause of full disclosure here, I still don't use BOSS or Wrye Bash myself, but I also don't use any of the mods that pretty well 'require' it.

 

Just to clarify further, Python is required for the Wrye Bash version 292 to work. The Python 04 will install the Python runtime libraries that WB needs. There is a planned version of WB that won't require Python, but as of yet it's not released.

 

It's good that you got your vanilla install working again. I personally prefer manual install for all but the most complicated mod installs, but I do use OBMM for a couple of mods I use. Then I use the versions that come as a pre-made OMOD with a script that walks you through the various installation options for the mod. I think that your woes weren't so much a case of OBMM causing the grief as mod conflicts (I lean towards your Unique Landscapes compliation ... I see a lot of compatibility patches for UL).

Edited June 24, 2011 by Striker879

[DrakeTheDragon]

From what I read it's likely OBMM wasn't the culprit to begin with. It was Archive Invalidation done wrong, no matter via which tool, which was causing the crashing it appears.

Archive Invalidation is inevitable, if you want the game to use different textures than the ones inside its BSA. Only textures require Invalidation though, meshes and everything else so far will be used over the internal ones right away.

 

Now Archive Invalidation was long ago done through manually adding entries of files to invalidate into an ArchiveInvalidation.txt file in your folders. Later this got covered by tools to automatically fill in those files it finds in your folders which should be used over the internal ones from inside the BSA. But this ArchiveInvalidation.txt file was never working reliably to begin with. There were situations where it suddenly stopped doing any invalidation after a certain number of entries, then after adding a few more all of a sudden it was working again, and worse things, all pretty random or at least it could not be any rule deciphered so far.

 

A while after this a method called "BSA Alteration" got pretty prominent. Basically altering the contents of the BSA, so the new textures replace the internal textures right inside there directly, no way back ever apart from a backup of the BSA or a complete reinstall, this was also not the ideal solution, especially as like you experienced it's pretty easy to mess up Archive Invalidation horribly and with game-breaking results, and having done this in a "permanent" change to one of the game's core files is a really bad thing.

 

The up-to-date most common solution is what's called "BSA Redirection". It simply exploits the fact that actually only the one BSA at a certain place in the "SArchiveList" variable in the Oblivion.ini ever requires Invalidation. So it installs an empty dummy BSA into your data folder and inserts it at exact this position in the "SArchiveList" variable in the ini. So from then on only textures from inside this dummy BSA need ArchiveInvalidation, and as there are none, this means no textures ever again will require Invalidation. It's a one-time-only fire-and-forget solution, and you only have to repeat it should your Oblivion.ini somehow get altered and this entry in "SArchiveList" be removed or undone. OBMM's Utilities, Wrye Bash's Replacer tab and the famous mod ArchiveInvalidationInvalidated! all provide this new way for Archive Invalidation and are doing exactly the same. Just leave everything on defaults, "never" include meshes, and only use BSA Redirection, and should only need to do it once and never again worry about Archive Invalidation anymore.

 

There's one more important thing to keep in mind though. When using BSA Redirection it is pretty fatal when there's a left-over ArchiveInvalidation.txt file telling the game to invalidate a texture file which isn't in the dummy BSA to begin with (as it's an "empty" BSA "any" entry will cause this)! So find "all" of those ArchiveInvalidation.txt files, as there can actually be more than one in different folders, depends on which tools you used to automatically write them and where they placed their files, and get rid of them.

 

OBMM's strength over other managers clearly is the OMOD way of "scripted" installation. If there are any optional features in a mod package you need to decide about, it gives you a step-by-step wizard-like walk-through through each decision where you can make your choices and the script compiles your selections and in the end installs only the files your choices require. That's the power of OMODs and "OMOD-ready" archives, zip-files including special data for automatic conversion to OMODs so you only have to state "Add Archive" when inside the OMOD creator and every information, scripts, additional files will be filled in automatically for you, so you only need to click "Create OMOD" and be done. Usually those scripts are written in their own simple language, but there is also the possibility to write them in C# or Delphi (I think) and this was what gave you the error for one of your packages, as its author might have made a mistake in such a script there or you're missing some interpreter the script the author wrote requires. I don't know.

 

ESP files in sub-directories means the mod will likely require an installation script or you will have to move the proper ESPs according to your feature choices out of the subfolder into the data folder manually yourself afterwards. That's what manual installation instructions in readmes are made for then. You can of course always create an OMOD even from archives with such a structure, but the OMOD will only give you the same state as when you would simply extract the whole contents of the archive into your data folder, which is not necessarily a working mod install already, with non-used ESPs still in sub-directories and such.

 

OBMM's file conflict detector isn't really a "conflict" detector as it will only tell you when one OMOD is going to overwrite files from another OMOD, which in case of the one being the main mod and the other for example being an update or bugfix package is a totally valid situation and just what is intended. Still OBMM will report this situation as a file conflict between the two intended-to-be cumulative OMODs. Plus as was already mentioned, OBMM only keeps in mind which file is part of which OMOD, so if you deactivate an OMOD all its files will be removed, BUT if there's another OMOD containing the same files OBMM can't tell which one was installed last and will NOT remove the duplicate files altogether.

 

That's where BAIN, Wrye Bash's latest addition, comes in handy. BAIN (I think it's short for BAsh INstaller) also maintains an installation order, so if you uninstall a BAIN package the next package in this order will use its files to replace the ones removed, if there are files in common between different BAIN packages, or so I've understood it at least. However, Wrye Bash, and as such also BAIN, has a steeper learning curve and thus OBMM with its windows-like UI, automatic archive folder structure sanitizing on OMOD creation and the very comfortable OMOD installation scripts is better suited for a beginner.

 

Still it always stays a matter of choice and personal preference. I for one have switched to BAIN now, as it gives me more control over installation order (which after "load" order is the second most vital aspect of using mods properly), but I'm still providing OMOD conversion data in all my mod packages for users' convenience.

 

Oh, and there is no Oblivion.exe shipping with OBSE. That'd be illegal. The only thing required to get OBSE working is to place the DLLs and the obse_loader.exe into your Oblivion folder and from then on only start your game via obse_loader.exe instead of the Oblivion loader, or use start functions from OBMM or Wrye Bash, as both will either recognize OBSE in your folder and start the obse_loader.exe instead automatically (OBMM) or provide a means to start the obse_loader.exe instead through a checkbox (Wrye Bash). Nowadays there are also completely custom launcher apps available which again will provide means to start your game through obse_loader.exe or do this automatically, if you have OBSE installed. All the loader does is injecting code for additional script functions into the Oblivion.exe and then launch it, so if it's not started beforehand, those new functions will not be present and OBSE-dependent mods will not function properly. That's also why OBSE doesn't work with Oblivion from Direct2Drive, as they encrypted their Oblivion.exe and breaking it for the code injection is against the law. Steam however has long since realized the importance of OBSE and added functionality to start your game with OBSE support from its own launcher environment.

 

I hope this little information helps avoiding some confusion in future endeavours. Oh, and please refrain from claiming OBMM was messing up your install. The situation at hand was slightly different.

Edited June 24, 2011 by DrakeTheDragon

[ladlon]

Ya, I was doing the manual install method with my regular Oblivion (non-GOTY) with no problems. Quite honestly, I was tempted (after the frustrations with the various mod managers) to go that route again... At least that way, I (more or less) know what is going on.

 

If I were to go manual for those mods, would having a backup of the data folder be an airtight method of restoring back to vanilla? Are all changes exclusively within the data folder?

 

I don't imagine I will be going nuts with tons of mods... Just some graphic/UI improvements, and the monster additions (which pretty much covers the handfull of mods I had listed earlier). I'm not one to go nuts with 'silly' mods, or armour mods, etc. Probably the only other things I might like to get is the depth of field mod.

 

I know I will sound like some whiney, lazy bastard who wants to be 'spoon fed', when I express dislike for all the hoops you seem to have to jump through to use each of these mod 'helpers'... but it's more that I don't like tinkering with stuff I don't understand, and also want to keep things clean (and not a mess of patches and random files I gathered from various sources in order to make the previous workaround work). In a world of broken links, 'previously good' files that are now flawed/obsolete, and a seemingly endless series of 'Okay, that'll now work... but you still have to...', it does get a bit overwhelming... especially for guys like me who don't live and breathe code. I mean, I am sort of mid-level tech... I can figure things out (and often have to), but there are times when you just sigh and say, "You know... I really don't have time in my life for all this...". Heheheh...

 

Okay, well, the main crisis is remedied, it seems. I can address the mods (and all the support programs) at any point at my leisure now.

 

Side note.... Weird that none of the vanilla monsters and many of the items don't seem to be in the Shivering Isles. You have the new stuff, but all the existing (outside of SI) things don't exist in that world. Oddly enough, I find myself really enjoying going back to the regular land, as it seems more varied. I mean, I really miss fireballing crabs and rats, you know?

[DrakeTheDragon]

Having a backup of the data folder should be all that's needed to revert back to a previously working state. There are mods who can mess with your Oblivion.ini (found outside of the data folder in some system folders inside "My Games/Oblivion") though, but I guess from those none will be among the list of your intended mods anyways.

 

Actually that's why I'm providing scripted installs through OBMM in my downloads. My users can go into OBMM, click "create", then "Add Archive", select my 7z file, will get a nice message informing them there's conversion data included in my 7z and asking if they want to use it to fill in all fields in the dialog, they press "yes", wait for the file to be read completely, then they see any data filled in already for them and only need to click "Create OMOD", wait for it to be done, can activate it from the right list, the list of OMODs, navigate from dialog to dialog answering questions about their preferences and wishes, and eviola, they're done, my scripts will handle the rest and take care all files, and only the right files, will go exactly where they should go. If anything went wrong then, it'd be me to blame for writing nonsense in my installation scripts or providing an invalid folder structure in my downloads.

 

Coming to think of it, that's pretty close to being "spoon-fed" by the tool, isn't it?

[ladlon]

Thanks for all that info, DrakeTheDragon. That certainly tells me a lot about the process (although also makes my brain wobble as well).

 

Please note that I wasn't bashing OBMM, or claiming it was defective. Notice that my title ends in a '?', showing that I'm not sure if this is the case or not... as well as my abundant use of 'SEEMS' and 'seemingly' to show that I'm by no means some know-it-all, claiming to be an expert and/or bashing other people's impressive (and appreciated) work.

 

The only reason I even pointed to OBMM is that it was the only item I utilized with Oblivion, and the 'errors/CTD' occurred after using it. Even then, I wasn't claiming that it was the program's fault (in the sense that it was faulty), but that either I did something wrong, or something got messed up. For me to claim anything as fact would be seriously hypocrytical, since I know SFA about this subject, really (aside from the little I've quickly learned in the last 2 days). I'm just saying that 'something I did with OBMM seems to have messed up my vanilla install, even after I removed all the mods via the manager'.

 

I noticed that conversion data message that you mention. That was one thing I was wondering about (mentioned in one of my earlier posts in this thread)... where you have a mod that OBMM warns has .esp files in sub-folders. I was not sure what to do when that happened (ignore it, and select the topmost folder... or select something deeper in... or, if possible, select ALL the .esp files... or abort). I bit the bullet, and tried one, and got that conversion data message (which, although I had no idea what it was talking about, SOUNDED like it was going to work in my favour!).

 

Again, all the mods SEEMED (....there's my famous upper case 'seem' again...) to be converted fine (within the manager), but I didn't notice any mods 'working' in the game itself... but, again, the mods I had working in the manager were the type that woudn't make themselves immediately apparent in the game (..texture changes, etc)). I tried activating one that WOULD be obvious (the interface one), but that goe some C# (?) compilation error, so I coudln't get it to work in-game.

 

I'm looking into those other managers/support programs everyone's mentioning. I'm still nervous about how cryptic they are (for those not familiar with the process, quirks, requirements, etc). For me, it's like sitting at a control panel that you don't understand. A warning light might flash on, yet you have no idea that it even IS a warning light... and in the meantime, you are looking at the steady blue and green light, wondering if it's 'normal' that they are both on.

 

More reading/learning for me, I guess... I'm sure you'll hear more from me as I dive into those ones.

[eric31415]

Well, i can't match Drake's explanation,but i can answer your last couple questions.

 

When you see the warning about esp files in sub-directories you only need to be concerned if the mod didn't contain OMOD conversion data. You will get the warning either way. If you get this message on a mod which did not have OMOD data with it you will have to repackage the mod. This isn't as hard as it seems, especially if you have succesfully installed a few mods by hand already. Just take all the items the readme says to put in the data folder into a new folder in documents. then run OBMM, and use CREATE and ADD FOLDER to load the esp, meshes, etc. Folder structure is crucial here, everything in this file needs to be what would come immediately after "data" it the filepath. You should never have a folder named "Oblivion" or "data here, only esp, bsa, textures, meshes, sounds,etc. Dont forget to enter at least a name when you create the OMOD.

 

If you didn't do it this way before, make sure you delete the old (faulty) OMODs before creating new ones or name them differently.

[ladlon]

Welcome to the thread, eric31415!

 

How does one know in advance if the mod has conversion data? I see that it asks about it after you have initiated things, but by then, you've sort of committed, haven't you? Is there a file you can look for in the mod's folders?

 

When you say 'repack the mod', you sound like you are using OBMM. Is that right?

[eric31415]

After you DL a mod and unzip it, open the file to see if there is a sub-file named "OMOD conversion data".

 

Always check the folder structure to see if you need to repack.

 

Yes, i install every mod thru OBMM.

[bben46]

BTW, BOSS is actually a stand alone utility, it does not require either Wrye Bash or OBMM to work. Wrye Bash does have a direct link if you have both Wrye Bash and Boss installed though. (Wrye Bash also has a direct link to OBMM also as they are not incompatible) So, whether you use Wrye Bash, OBMM or no manager at all, use BOSS to help set the proper load order of your mods.

 

All of these utility programs actually work outside of the game and are turned off when the game starts. OBSE on the other hand is an extension of the Oblivion program and does run while the game is running. Trying to run Oblivion with a mod that requires OBSE will crash it the first time the mod makes a function call to OBSE if it is not present. Many times that first function call is during the game loading sequence. If there are no mods that require OBSE, it does nothing and the game will run fine if it is installed.

 

My advice, - go ahead and install OBSE and start the game with it instead of the Oblivion launcher (Both OBMM and Wrye Bash have launchers that will automatically start OBSE if it is present) Then, when you do install a mod that does need it, it will already be there. :thumbsup:

[DrakeTheDragon]

I'm sorry, BBen, and I can't explain where this is coming from knowing for how long you are around in the community, but the second paragraph is not 100% true.

 

OBSE is not a program. It will not run in the background or anything while the game runs. It's just the obse_loader.exe which injects the code-expansions into the game and then starts the game and "terminates" itself.

That's why OBSE itself cannot crash your game but only the mods requiring it the scripts of which weren't working without OBSE before.

 

Then using a mod requiring OBSE without starting the game with OBSE will "not" make it crash, especially not at startup, as this can only happen when a masterfile is missing (in general).

The only thing happening when a script tries to execute an OBSE command but the game doesn't know these is the script will terminate. This will not cause crashes, just the scripts of the respective mods will not work to their full extent. This, however, "could" cause crashes then, but it's not the general case.

 

For instance, the general action taken by the scripting engine when a function is called the game doesn't know is treating its return value as "0". That's why the common checks for OBSE's presence in mods requiring OBSE are working at all. They call a function only working "with" OBSE and usually not returning "0" and when it returns "0" it's not known and OBSE must be missing.<-- doesn't make sense with the last statement somehow... need to read it up again first.

 

It could be I'm wrong with all of this, but this is how I myself experienced it in my scripting and read it up in the documentations and tutorials. So I'm a little confused where your info is coming from here. I'm sorry. :unsure:

Edited June 25, 2011 by DrakeTheDragon