Hello everyone!

I have started comtemplating unpacking all my BSA's to gain greater control over which files are being used in-game. I install everything with BAIN and I'm wondering what the advantages with having files in BSA's really are.

Discussion, input and opinions are welcome.

Check out http://www.gamesas.com/index.php?/topic/1132683-to-bsa-or-not-to-bsa/page__p__16587484__fromsearch__1&#entry16587484 thread.

For a mod user the pros and cons are pretty clear.

The good thing is that a bsa is as easy to install and remove as it can get. Just drop the bsa into your data folder and play, to remove it just delete the bsa. No additional programs needed, no maintaining, nothing to worry about. An additional advantage is the small performance gain that comes from having multiple files in a single archive. Dozens or even hundreds of files cluttered on your hard drive are bad for performance (stuttering). Of course this is only true if the bsa has no compression, but I guess most modders do that if they go the bsa route.

The bad thing is that some people eventually reach a limit of esp/esm/bsa files in their data folder which can cause game crashes (IIRC). That limit is said to be around 400. So if you play with 255 mods and have too many bsa files in your data folder then you may get problems. Unlikely, but I guess it can happen if you are a bit excessive about using mods.

I'm wondering what you mean with gaining 'greater control over which files are being used in-game'. Whether your bsas are unpacked or not doesn't change anything about the files that are used in game. A mod that comes with a bsa file will need all files inside the bsa, whether you unpack them or not. In my opinion there is no reason for the extra work of unpacking bsas only to put them into BAIN format - unless you are experiencing the ~400 files crash problems described above.

With, greater control I get to see in BAIN which of my replacers are overriding other files. With BSA files you never know which ones are taking effect.

Discussing the 400 limit, I'm at around 220 actice mods with an additional 55 BSA files so I don't know ir that's starting to get close.

Aah I see, no that should never be a problem, if a mod creator includes a custom bsa the only mod using/referencing it will be that mods esp (unless another author also references the same bsa with a patch esp for varying circumstances).
And all files within the custom bsa should be unique to the author in the naming convention so that no loose files from other mods will be able to replace them in game via invalidation. Again anyone providing a patch for different circumstances and also needs to replace files from the custom bsa as part of that patch they would also use the same naming convention for that particular mod to just override the bsa's files.

Emmas Vilja for instance, has a bsa, all textures etc in there are uniquely named and do not replace any file from the vanilla game bsa's, and are only called for use on vilja by the vilja esp. Anyone can invalidate those with further patches or loose files with the same unique names but these will not be invalidating anything from the vanilla game files, just the target mods bsa files.

OK, thanks for the explanation!

So, basically there is no need to extract my BSA's then unless I add a lot more mods.

Nope not really, the only thing I have heard people doing is to re-pack bsa's with no compression, so the files within are accessed quicker, but unless you have a computer thats struggling no need really. And if you ever get to the hairy edge of your files limit with mods etc such considerations are going to be the least of your problems, managing a big mod list gets quite complicated and potentially more unstable with each additional mod.... before long you are investigating refining your load and studying which combination of mods caused the latest instability will be your biggest concern, unless you are expert at all the combination complications reaching the file limit is going to be cut short by all the other problems before you even get there.

The files within a BSA are not always unique and do override other lower order BSA's, which is indirectly why we have the invalidation issue to deal with.
Without BSA's, there is no invalidation problem and you do have greater control as Poddmeister suggests. IE. You cannot control which files will be replaced when one BSA overrides another. It's all or nothing.

Unique naming is just a convention when the content really is unique, but that is not always the case.
Most replacers override the vanilla BSA's for example.

As Phitt pointed out though, having all of your BSA's unpacked can actually decrease performance as windows can spread all of those 100's or 1000's of files all over your harddrive, causing fragmentation that results in harddrive IO latency.
Even if you defrag, the files may not be clumped together, so there is still latency from all the file lookups.
Alot of content gets preloaded into RAM (cached) though anyway, so any latency will be most noticable when you enter new cells (ie, when new textures or meshes are being cached), not really a constant performance loss.

When the files are all packed in a BSA, windows sees it as one file and will try to place the entire BSA data into one location on the harddrive, instead of spread all over.
In this case when you defrag your drive, all of the data will be clumped together if it's not already, so any latency is minimized.

Like Phitt also mentioned, compressing the BSA will most likely negate the performance benefit of using a BSA though.

IMO, using a BSA or not is simply a compromise between convenience and control. In reality, any performance loss or gain because of using a BSA or not is minimal compared to other things which are not in our control, like RAM and VRAM. If you are noticing a performance loss, the proper course of action is to reduce your gfx settings and/or the amount of content used in your game. Reducing gfx settings, amount of content, texture sizes and mesh complexity will provide worthwhile optimizations.

That one was new to me. I always thought content from one bsa cannot override content from another bsa. I might be wrong though.

Hi Gaticus,

I'm thinking about packing QTP3R in a .BSA, I'm using BAIN and have many smaller replacers installed later in order, as loose files mostly.

I'm not sure I understand: how can be problems among different BSAs?

Does a later-ordered BSA just replace the before-ordered BSA's same-named content, and leave the rest intact?

Or, for example, if I have a BSA installed after my QTP3R.bsa replacing a single file in QTP3, that will "void" the whole effect of QTP3R.bsa over vanilla's?

Hope my question is clear enough, thanks

Has anyone actually done speed profiling to see if the extra disk reads are a genuine issue? Fragmentation issues aside and assuming a non-FAT32 filesystem, concern over the directory reads seems half-baked considering that Oblivion is already reading those directories to see if there's an override file, and the directory listings are probably in cache for the majority of reads.

QTP3 is a replacer and therefore should not be included in a BSA, unless you're unpacking the original vanilla BSAs, copying the QTP3 content over the files, and repackaging them. Otherwise you'll get a situation where one BSA or the other will override, and you have no control over which one the game picks.

Thanks Arthmoor, I guess I'll follow your ruote and repackage QTP3R-updated vanilla BSAs.

Is http://tesnexus.com/downloads/file.php?id=18417 considered a replacer as well?

Until now my only hint was to BSA-pack when dealing with large number of resource files..

Cheers

No Armamentarium is not a replacer so it can be packed in bsa, but, Since it comes with a esm, you should read the armamentariumcomplete thread in which we talk about naming the bsa a certain way in order to get it to load correctly..Armamentarium thread in my sig, also read the artifacts thread has well.

Hi Corepc,

can you please clarify? In your thread you suggest naming to ArmamentariumArtifacts.bsa, while PetrusOctavianus in the http://www.gamesas.com/index.php?/topic/1063553-relz-armamentarium-complete-135-artifacts-ii-support/page__st__80
says

"Some of the meshes and textures don't show up in the game, both using Armamentarium.BSA as well as ArmamentariumArtifacts.BSA, even though they definitely are in the BSA.
I'm not using the Artifacts plugin, but I do use ArmamentariumLL4OOO.esp. Any suggestions for another name for the BSA I could try?

EDIT: since DLCShiveringIsles.esp is already uses as a dummy file I renamed the BSA to DLCShiveringIsles.bsa, and that worked."

Should I go for a dummy or "ArmamentariumArtifacts.bsa"?

Thanks

I could be wrong. From the above posts, it sounds like I am wrong and I'm not going to argue. But I will test and report.

It just makes sense that one BSA could override another, since the whole purpose of the BSA is for distribution of modular content (EG. official addons)
Why they would not, I have no idea. I think Bethesda would have to explictly code the BSA management to lack that ability, since all of the content from every BSA plus loose files must be pooled together before Oblivion can determine which files have precedence, even if it's true that one BSA does entirely supercede another.


I don't think it's a genuine issue. No testing is needed to know how the mechanics of the computer and operating system work. Were are talking about a loss or gain of milliseconds as the needle on the harddrive has to seek to and fro between files. On 1000's of files, this can add up to be somewhat noticeable, but that is what caching is good for, which we can optimize in much more significant ways.
That Oblivion is already scanning the directory is of no consequence. The performance is affected by actually accessing the files, not by detection.


Dunno if it's what you actually meant, but you cannot redistribute any of the official game files, even those extracted from a BSA.

When the game is 1st loading, it is going through all the content from vanilla and plugins (official and mods) and looks (caches?) where those files are. This includes looking through BSAs, from those loaded from the SArchive list (which for most people will be the vanilla BSAs) and then those loaded from esp files with the same name.
So, if 2 files are in 2 different BSAs but have the same path, does it load/choose the one from the later loading esp, or from the BSA with the later time/date stamp?

Which one it chooses is entirely unpredictable. It doesn't follow any sort of logic. I can't find the thread right now but H2ODK did some pretty extensive testing on how BSAs that replace content in other BSAs behave.

There have also been scattered reports here and there than overlapping BSA content can lead to crashing the game.

To followup, I did some preliminary testing and was able to have a custom BSA override a texture in the vanilla BSA...

EDIT.
I've scraqed the test results I posted to avoid confusion as they were tainted.
I actually made a stupid mistake in my tests and forgot to delete the loose test textures from the data folder. :facepalm:
My blunder did reveal some things though, so it wasn't a waste. I'll elaborate more after I've have tested properly.

^ = :wacko: + :bonk:
All in all, best not to have overlapping BSAs then? :nope:

I'd listen to Phitt, alt3rn1ty, CorePC and Arthmoor. They all say that BSA's can't override and if they can, some people have reported errors in game.

This intrigues me though, so I am going to do some more testing and post an article later with more thorough documentation of my trials.
It does appear that the behaviour of bsa load order is consistent, though a little complex. Reliable, I dunno.

I googled for 'H2ODK BSA' and turned up nothing relevant.
It would be nice to see his conclusions if anyone can point me.
edit* I think I found http://www.gamesas.com/index.php?/topic/1105791-relzmartsmonstermod37b3-public-release-3-relz/page__view__findpost__p__16197922__hl__overlap__fromsearch__1.

The directory scan itself is a disk operation, and does matter (except, as you said, caching mostly negates it). Meanwhile, the process of accessing the data from the BSA is essentially identical to accessing it from the drive in separate files -- the header is checked to find the offset of the data you want, and the disk has to seek just the same. So except for very small BSAs which might be kept completely in cache, I don't think you're saving anything but file handle process/memory overhead.

I've long been in the habit of ripping BSAs open. It's a useful exercise and can at times be frightening. I have just this second ripped one open and found thumbs.db files. I've also found seriously non optimized Nifs full of dead nodes. (Someone used delete rather than block delete in Nifskope I guess)

BSAs makes a lot of extra work for me.

I'm not a modder nor I'm interested in distributing anything.. I'm aware of the copyrights as well.

I'm just pursuing the smoothest-running setup, and thought that repacking stuff like QTP3 and Arma could help

Btw, if anyone could clarify Armamentarium BSA proper naming issue.. Thanks!

To Symon69: Could you please let us know what BSAs you've found with that junk? Would be helpful..

I haven't read the other thread, but as far as I know, the rule is very simple: To get the game to load a BSA file, the FIRST PART of the BSA's name, must EXACTLY MATCH the FULL NAME of an ACTIVE ESP (not esm). So if you have an active mod name MyMod.esp, you can have BSA files named MyMod.bsa, MyMod_someMore.bsa or MyMod - some more.bsa, or all three.

'MyMod_someMore.bsa' dosn't work. I just tested.

The prefix must be either 'MyMod ' (with a space) or 'MyMod-'
So 'MyMod More.bsa', 'MyMod-More.bsa', 'MyMod - More.bsa' will all work.