After a long break from Oblivion I recently reinstalled it (I actually had to buy it again because I lost my disc). I used to play with FCOM, so it was natural for me to install that again, this is when I became aware of a problem.

The problem is when a BSA has file replacer in it, and the way Oblivion gives priority to resources when using BSA-redirection.

After several tests this is what I have discovered so far:

• All Vanilla BSA has priority over any other BSA registered in the INI
  
• Any BSA registered in the INI has priority over any other BSA.
  
• Any BSA registered in the INI (sans Vanilla), has priority based the order they are in (first listed has priority over later)
  
• Any BSA loaded via a *.esp has priority based on Alphabetical order.

This is all based on there NOT being a corresponding file in the data\* folder that the BSA tries to replace.

If there is a corresponding file in the data\* folder priority is only given to BSAs newer than the file in the data\* folder, but still in the order above.


So what does this mean...

• A BSA cannot replace a vanilla file.
  
• A BSA loaded via a *.esp cannot replace a file in a BSA loaded via the INI.
  
• A BSA loaded via a *.esp cannot replace a file in another BSA loaded via a *.esp that is higher in the alphabetical order.

Unless there is a corresponding file in the data\* folder, that is newer than BSA with the file being replaced, but older than the BSA with the file replacing it.


I could of cause have made a mistake somewhere, so I would like it if people could confirm or refute any of these findings.

I currently can't take a look into it myself, but did you always keep in mind the file date of the BSAs you were testing with (and maybe also the file dates of the files within)? File date in Oblivion always has a vital influence on prioritizing. It can even eliminate any effect from BSA Redirection or other Archive Invalidation methods (e.g. Steam Oblivion and its Vanilla BSAs having way more recent file dates than any replacer-type mod's resource files, rendering these useless).

He did.

Yes I did. File dates has no influence on how BSA files are prioritized unless there is a corresponding file in the data\* folder, and then the file date only "filter out" any BSA that is older than that file. Any BSAs newer than that file in the data\* folder are still not prioritized on dates.

I haven't investigated this at all myself, so I rely fully on the expertise of others, but the findings seems solid as far as I can tell. Hopefully this will resolve lingering issues with mods switching to bsa format. Thanks for investigating this so thoroughly. :goodjob:

I also think the priority can change from time to time in game depending on if something that uses that texture has been loaded into RAM previously and is still in the cache --- If say you have 2 textures that are both named the same in seperate BSA's or folders and an item using the texture from one BSA is loaded in game and then stored in the memory cache and you then try to load an item using the same texture but from another mod that would normally use its copy from its own BSA if the game still has the other copy from the other mod in RAM it will not load the second texture but will use the one from RAM instead yet if the second item is loaded first then both models will use the texture from the second mods BSA. (which is where you can run into problems with replacers if you are using multiple mods that are replacing the same textures - since there is no sure way to get a specific copy to be used.)

For example say you have 2 versions of Textures\armor\imperial\cuirass.dds stored in 2 different bsas ie. mod1.bsa and mod2.bsa and in game you come across a copy of mod2's item using that texture it will load it from mod2.bsa then you walk along a bit and come to the item from mod1 using that same texture you will either get the game loading the texture from mod1.bsa if the cache has been cleared after running into mod2's item or at other times loading the texture from mod2.bsa if it is still in RAM. (As far as I can tell the game first checks the RAM cache to see if that texture is found and if it is uses it and if not moves to the next search location)

That is not what my tests showed.

I did a test where I replaced a mesh from Vilelair by packing a replacement mesh in a bsa, it followed the results I posted.

I don't think the game keeps track of associations between a esp and any bsa loaded by it.

I have heard of this before, and I think this was the cause behind the original warning I heard about with respect to having a file (same file path) in multiple BSAs.

I haven't ever done any BSA testing quite that thorough, but it seems like your results are consistent with what others have found in their own testing efforts, and with what I've found.

The only thing you don't address is that the game can crash if two different BSA files have something pointing to the same file path. I don't have the links handy, but it's come up often enough that people need to be warned about it. A crash isn't guaranteed, but it happens enough to be a serious issue.

Actually... This was the source of the first warning I heard about the file across multiple BSAs issue...

It is difficult to test these things, because they are both random.

But if there is merit to this, it really shows that a bsa should not contain ANY replacement files.

This would also mean that a mod user would have to unpack ALL bsa files and move any files they share to the data\* folders, before they can be repacked as bsas and used safely by the game. This would have to be done every time a mod gets updated and/or a new mod is installed.

Edit:

The only strange result I got during my tests was when I put a bsa before the Archive Invalidation bsa in the INI file. The bsa contained a texture and normal map, in that case the game used the vanilla texture and the replacement normal map.

While we're on the subject, is there a significant performance increase by having your files packed in BSAs? It seems like one way this issue could be resolved (although the data folder would be pretty cluttered) is by just unpacking all your BSAs. But would that negatively impact performance a lot?

It would make sense to me that there would either be no discernable difference, or some, but in favour of loose files (vs. BSA).

Also, I happen to prefer loose files in archives, for a variety of reasons, not least of which being that I'm (almost) purely a user of BAIN, when it comes to mod installation. So, could be I'm biased.

It would be a drive seek nightmare to have thousands upon thousands of loose files floating about in your Data folder. I proposed doing much the same at one point and that was universally the response I got from it: bad idea. Which makes sense. Fragmenting everything all over the place would drag down disk performance badly.

As far as mods go, with the rise of BAIN, it's far more efficient to have loose files, though for really large mods like Lost Spires, Blood & Mud, Bartholm, etc, it's easier to manage then when they have a BSA.

Hm. Could be you're right. But then again, if the [Oblivion] folder is defragged, I don't see what the issue might be, really. Rifling through an archive every time, to extract whatever is needed... doesn't strike me as any more efficient than doing the same in a directory.

:shrug:

One of these days, I'll try dismantling *everything* (well, everything I can) and see if I can get some comparitive numbers and impressions (e.g., FPS, "smoothness", etc.)


edit: Heh, would also (presumably) nix that whole "soft limit" on esp/esm+bsa thing... Perhaps it's time I did that experiment.

There should be a small performance benefit to using non-compressed bsa files, simply due to the indexing that bsa files provide (direct knowledge of where a file is vs. querying the filesystem time after time). There should be less OS overhead with keeping a bsa open than opening / closing multiple smaller files. Lastly, assuming the bsa is one contiguous block on disk and isn't highly fragmented, it should take the game less time to seek each resource than with loose files.

Of course, this is assuming Oblivion takes the extra steps to optimize bsa access...and this is Oblivion after all. :rolleyes:

I can vouch for there being a small but noticeable difference in using all uncompressed BSA files. It doesn't translate into boosted framerates, but does help with disk stuttering related to CPU overhead. Even bigger help when the drive is properly defragged and the behemoths are all in contiguous blocks. Which would seem to support the idea that scattering the loose contents wouldn't be a great idea. You'd need a 3rd party defrag utility that could keep everything in one area of the drive.

They have an excellent utility on http://www.auslogics.com/en/software/. :user:

Indeed! Happens to be the one I'm already using.

Recommended.

Ultimate Defrag is even better for a thorough defrag, but Auslogic is great for a quick defrag after running TES4LODGen.

Much useful info on BSAs here, so bumping is a bonus.