Ramifications of BSA Extraction in Mod Organizer

[z929669]

This will graduate to wiki guide format once we get sufficient community input ...

---

 
I am creating this thread to address some important information about BSA extraction and related modding concepts that come up over an over again with respect to STEP's use of Mod Organizer (MO) and MO/STEP critics that disagree with STEP's general advocacy of BSA extraction and MO's BSA-extraction functionality. In order for this to be meaningful to all users, I am providing some background information required for understanding the ramifications of BSA extraction and why STEP advocates it while other respected modders do not.
 
WARNING: Extracting BSAs deviates from the intent and expectation of the respective mod provider, so it is fair to expect that once a user extracts a BSA supplied with a given mod, that mod's author has every right to refuse support on the basis that the user implementation is no longer the same mod. Further, if a user extracts vanilla Skyrim BSAs, ALL mod authors and the modding community at large have the right to refuse ANY support to said user!
 
NOTE: The STEP community follows Wrye's cathedral model of modding, and since we advocate experimentation and an open modding approach, we also try to encourage 'creativity' (but not flagrant stupidity, TYVM) and users are welcome to support each other in this community, and we'll do our best to help as we are able, particularly with regard to what we advise in any of our guides. After all, modding is a largely creative endeavor and a learning experience!

---

 
Executive Summary
 
STEP provides instruction for a range of methods to mod Skyrim. Novice users can follow the STEP Guide, which is pretty straight forward and adheres to conventional modding methods. More advanced users or users that want to take it further can follow the additional guides and employ some more advanced and less conventional techniques (like BSA extraction and texture optimization) that we have found to be viable and optimal for the 'perfectionistic' or 'adventurous' modder. Some of these techniques are traditionally the jobs of the mod providers rather than the mod users, but we encourage and empower our community to take on these tasks if they wish, because many mod providers do not optimize their mods, and we advocate customization of mods by the user.
 
STEP advocates BSA extraction because it allows for more granular control of the modded Skyrim (but see 'cons' below). Critics object that this practice 'breaks' the fundamental standards of install-order and load-order methodology that many mods and modding utilities are built around. Nevertheless, I and many STEP staff and members have not found this to be the case and propose that these concerns likely stem as a result of Mod Organizer users having problems and complaining and blaming the mod authors on mod threads like the USkP when something goes wrong with their game. Why MO users? Because MO is the only mod manager that exposes BSA extraction to any user that installs a mod with a BSA in it (basically, all MO users).

• STEP advocates BSA extraction (given the user understands the ramifications!)
  • It is a prerequisite to texture optimization (NOTE: repackaging vanilla BSAs is possible with CK's Archive.exe but problematic with BSAopt)
  • Used properly, it does not cause any load-order issues at all
  • It allows more granular control of a modded setup
  • It can theoretically lead to excess disk fragmentation (HDDs only, not SSDs)
  • It can theoretically reduce in-game performance if most/all game assets are loose files under a heavily-modded game
• BSA extraction is not 'bad' (NOTE: it can alter the intended behavior of a mod's interaction with other mods if used improperly)
• BSAs are not 'bad'
  • simplify mod distribution
  • simplify user maintenance (NOTE: particularly for manual installation and traditional mod management ... but NOT for Mod Organizer users!)
  • simplify support by mod providers
  • BSAs are the future trend in Bethesda modding, so best to get used to them

---

 
Install Order vs Load Order
 
A word about game assets: Game assets are any files (resources) that get used by Skyrim. Plugins (*.esm & *.esp) are special assets that are used by Skyrim to call upon other assets and to provide instructions for their use. Thus, plugins are the 'brain' of the game. The only plugins needed to play Skyrim are Skyrim.esm &  Update.esm. Other plugins are from the DLC add-ons or other mods made by the modding community like the USkPs, etc.
 
Install order: The order of mod files installed onto disk. If two mod packages contain the same file names along the same file paths (e.g., textures/blah.dds), then the last installed version overwrites (i.e., overrides) any previous version and is thus the version that will be used by the game if it is called upon by the game (via a plugin). These mod files can be anything at all (e.g., text, images, ... whatever), but only certain file types are used by the game: textures, meshes, scripts, plugins, etc. Therefore, install order affects what resources the game will use.
 
(NOTE: MO does not install mods to the data directory, but rather mods are extracted into mod folders within a user-specified location. MO creates a virtual /Data/ that appears to Skyrim as the actual /Data/, and it populates this virtual directory with mod assets from the install directory as specified by the MO installation priority. Otherwise, there is effectively no difference between MO and other mod managers, but this difference is fundamental and confers a significant advantage to MO users).
 
Load Order: The order that plugins are loaded into the game. Like install order, the last plugin loaded overrides all previous plugins. Since plugins reference assets within /Data/ by file name, there is potential for two different plugins to reference the same named resource.  Additionally, since plugins provide instructions as to the use of these resources, load order can also affect game behavior. Therefore, load order affects both what the game will use and how the game will use it.
 
What are BSAs?
 
Mandatory reading: read this important background information!
 
BSA: A proprietary archive of game assets that mirrors /Data/ directory structure. Thus, a BSA file is an archive exactly like a folder that is simply packaged as a file. The same is true of any ZIP or 7z archive.
 
How do BSAs Work?
 
For Skyrim to be 'aware' of a BSA, it must either be registered in Skyrim.ini or loaded with a plugin of same name. Once recognized, the game sees any BSA as part of /Data/ itself; however, when conflicts exist between files contained within a registered BSA, a plugin-loaded BSA or within /Data/ as loose files, things are a little trickier:

• Registered BSAs: These load at Skyrim start in the order that they are listed in Skyrim.ini, last loaded BSA 'wins' in event of resource conflicts of contents within.
• Plugin-loaded BSAs: These load when a new or saved game is loaded after Skyrim starts. Each BSA is loaded at the time the plugin of same name is loaded. So any BSA with content resource conflicts corresponding to a plugin will 'win' if its plugin is loaded after the conflicting plugin. Basically, these BSAs (and all of their asset content) are referenced by their plugin and loaded according to plugin load order. Plugin-loaded BSAs always 'win' where they conflict with Registered BSAs. The only exception is with respect to resources required at Skyrim start but before savegame (or new game) load, like No Menu and Loading Smoke.
• Note about loose files: Loose files always override same files inside of registered AND plugin-loaded BSAs!

 
Summarizing in terms of prioritization and load order ...
 
Skyrim asset priority:

1. Loose assets always win
2. Plugin-loaded BSAs win all but #1 (EXCEPTION: plugins are only loaded when a new or saved game is started, so plugin-loaded BSAs have zero priority with regard to pre-game assets)
3. Registered-BSA assets lose to all #1 & #2
4. Registered Skyrim BSAs and other official content and DLCs behave no differently than "after market", mod BSAs

Plugin/BSA load order:

1. Registered BSAs load according to list order in Skyrim.ini
2. Plugin-loaded BSAa load with respect to the corresponding plugin load order
3. Plugins load according to %USERPROFILE%/Appdata/Local/Skyrim/plugins.txt, which is managed by BOSS/LOOT

BSA Pros:

• Keep the Data directory clean and uncluttered (NOTE: this does not apply to MO users though, since MO uses the virtual file system).
• Allow easy mod management, since all of a mod's files are much simpler to identify and update or remove (mitigates user error= less support burden)
• Make it easier for mod authors to distribute and maintain control over how the mod functions (mitigates user error = less support burden)
• UPDATE:
• Better performance (NOTE: a lot of loose files slows down game startup, especially when using MO)
• Less disk usage (NOTE: BSAs can be compressed; HDD fragmentation is less of an issue)

BSA Cons:

• Removes an element of user-level control ... and many mod users are control freaks (STEP especially)
• Users can no longer efficiently see contents of a mod (NOTE: although Wrye Bash does expose this information, albeit with a performance hit ... is this functionality inherent or is it off by default??)
• Incentivizes mod authors to provide BSA 'hotfixes' as loose files (NOTE: This has undesireable ramifications for MO users due to behavior of BSA extraction in MO ... BSA extracts last, so loose file hotfix is overridden by original version within the BSA! EDIT: this is fixed in the current beta and next release of MO)
• Mod authors are forced to upload all files (the entire BSA) for any updates (all files are contained within a BSA), and users are forced to either download again or deal with the issue just previous if the mod author has supplied a 'hotfix'-type update.

BSAs & Steam Workshop
Steam Workshop only allows mods that use the BSA + ESP format. STEP finds this overly restrictive and unnecessarily 'controlling'. I personally resent it and only deal with Steam because it is the wrapper for Skyrim (unfortunately, IMO). The Steam Workshop and Steam-Skyrim community are valid entities that do not deserve to be totally ignored, but STEP does not recommend that it be used as a primary source for mods or modding information. The Nexus is the STEP-preferred source for all modding needs. For information, STEP is a good primary source, and we point to the best alternative sources, but here are a few others:

• TESAlliance
• Bethsoft Forums
• Unofficial Elder Scrolls Wiki (UESP)
• SkyrimSearch.com
• Tamriel Maps 

BSAs & Mod Organizer
 
Since Mod Organizer allows users to extract BSAs during mod installation, MO potentially obviates any functionality of registered or plugin-loaded BSAs. Thus, any mod that uses a BSA is effectively constrained henceforth by rules pertaining to loose files, so its assets are no longer linked to hierarchies of BSA registration order or plugin load order. This and the fact that all or user-specified mod resources can be loose and manageable by MO confers a clear advantage to the user.
 
BSA Extraction Pros:

• MO users have a much more granular level of asset control and can prioritize BSA contents at the loose-files level
• It is a prerequisite to texture optimization (NOTE: repackaging vanilla BSAs is possible with CK's Archive.exe but problematic with BSAopt)

Other issues can arise though, so only informed users that understand the ramifications should be using this functionality (unpacking BSAs). Following are some things to be aware of when unpacking BSAs (that mod authors intended to remain packed as delivered!).
 
UPDATE: There does not seem to be any need for standard users to extract mod BSAs in MO, because once can subvert the constraints of the standard load order/asset prioritization system from the Archives Tab:

• Plugin checked, BSA checked - Follows mod priority order for conflict resolution. Plugin does not affect the situation at all.
• Plugin checked, BSA unchecked - Follows plugin load order for all unchecked BSAs. All loose file assets will "overwrite." OTHER checked BSAs will NOT overwrite, which is why unchecking BSAs can lead to unpredictable results or dificult-to-resolve conflicts (hence the warning).
• Plugin unchecked, BSA checked - Follows mod priority order for conflict resolution. Plugin does not affect the situation at all.
• Plugin unchecked, BSA unchecked - As if the plugin and BSA don't even exist in the mod setup.
• Furthermore, MO will scan all mod BSAs (aside from those in /Data/) and include these assets in the Mod > Information > Conflicts tab. So in MO, BSAs effectively behave like loose files when checked in the Archives Tab! Mod developers will still find the BSA extraction functionality handy for testing purposes during production of updates to their existing BSA-packed mods or when developing new ones dependent on assets contained within BSAs. 

BSA Extraction Cons:

• BSA assets are now given loose files priority, so this alters the mod author's original design intent and may introduce false 'bugs' that nobody on any forums will likely want to or know how to diagnose or fix ;)
• BSA extraction in MO happens after loose files are installed. This means that any loose 'hotfixes' would be overwritten by the BSA version, which is outdated. EDIT: this is fixed in the current beta and next release of MO

MO exposes BSA extraction functionality using a prompt when a mod containing a BSA is first encountered. This functionality can henceforth be "always allowed" or selective, based on user preference in response to this prompt. Users that do not fully understand the ramifications of BSA extraction on the specific mods they are using together should not use this feature. If "automatic BSA extraction" is in effect, it can be reset from Settings (click the wrench icon in the toolbar) > Reset Dialogs > click 'yes' at the prompt.
 
First, STEP recommends that users NEVER "always allow" automatic BSA extraction ... why? Because there is no need to do this at all, since the granular functionality already resides within the Archive Tab. More importantly, because many unknown or unintended prioritization issues can come into play as described previously. It is always safer to use the BSA unless it will cause a de facto undesirable result.
 
BSAs that have optimized textures and can be overridden completely by downstream mods should stay inside BSAs (or repackaged using CK's Archive.exe). If assets from inside a BSA need to overwrite some mods and be overwritten by others, then sometimes it makes sense to extract the BSA. MO has a beautiful tool accessible from within its Archive Tab. If a BSA is present in the load order, it will appear in the Archives Tab. Leave it unchecked to allow it to behave normally and be loaded by its plugin (if the plugin is active), and check it to extract the BSA to the mod folder and effectively confer loose-files prioritization.
 
Critics of Mod Organizer and STEP (for Officially Advocating BSA Extraction) 

Some within the well-respected modding community are at odds with the idea of BSA extraction advocated by STEP and facilitated by MO. The most notable contingent is the USkP team. This is relatively old news and nothing that should be shocking, so please do not treat it that way. The reasons are not unfounded and actually valid. I bring this up solely to address the idea to remove BSA-extraction from MO that Tannin suggested if MO-detected load order issues are not resolved properly (by submitting a ticket). In fact, I created this thread to address this one issue as much as to address the knowledge gap that is the real cause of any issues associated with BSA extraction.
 
Some modders are more or less happy with MO's ability to invoke BSA extraction. Generally, mod authors who have gotten a lot of grief with respect to their mods --for problems caused by the ramifications of rampant BSA extraction-- seem to have more of a problem with MO (see note below!). This has been somewhat problematic for STEP and MO with respect to outsiders privy to the argument but not privy to STEP or MO ... never mind that the 'fault' should be shouldered solely by the unwitting mod user for invoking BSA extraction without understanding the ramifications of doing so ... and ours for not properly educating our user base to that effect (hence this thread).
 
Let it be said that the STEP modding community and the vast majority of modders are the kinds of users that use PCs instead of Macs and tend to be somewhat removed from computing 'norms' imposed by Apple and Microsoft and their ilk. In general, we do not like our control restricted in favor of provider control over our resources to make their lives simpler. We are generally in favor of digital freedom, open source software, and the honor system. Big Brother and his methods are generally unwelcome. Demonizing BSA extraction in general and removing it from MO in particular in order to enhance level-of-conrtol by mod providers would be a big mistake, as STEP itself somewhat relies on this feature (and will to a larger extent in the future). However, I think that it is very important that our users understand the ramifications of using BSA extraction, and we need to address explicitly in the STEP Guide.
 
The MO user base (not its 'critic' base) should guide Tannin's direction of MO, IMHO ... 
 
I want to explore what we do (and do not) know with regard to the ramifications of BSA extraction to our MO users and how best to make MO a broadly accepted utility among all within the modding community ... not just STEP. In order to do so, we must not dredge up combative arguments. Constructive argument is good for all respective modding endeavors, so what has been said in the past is water under the bridge. So keep it lively and fact filled ... but keep it polite and considerate!
 
Please report bugs as Tannin requests using the link above. Also please post to this thread and help us to improve the breadth and accuracy of this OP!
 

[TheBloke]

I agree a lot with Aiyen. I'm on my phone and can't write much right now. But I had been thinking myself to re-establish this discussion.

 

There seems to be a general feeling that the changes in the latest MO were somehow meant to make BSA extraction irrelevant. In fact the changes made it safer with regard to the unofficial patches.

 

Regarding performance, on an SSD I can confirm performance differences are negligible or non existent. On HDD it may be noticeable, and one user, noobzor did report useful improvements.

 

All that said, it's worth remembering that no one outside MO users ever extracts. For avoidance of confusion alone, it's worth being mainstream where there is no downside. Similarlywdwe know that Tannin dislikes he feature, hence him moving it to a default disabled plug in.

 

 

But I absolutely agree that there is no need at all to suggest that extraction is fundamentally bad or broken. Many power users, modders especially, will benefit from it. However as it's been confirmed that, currently at least, no step mods require BSA extraction to achieve the required asset conflict resolution, I agree that default advice to not extract is best. If any mods later require it for conflict management, I would then have BSA extraction recommended case by case.

Edited July 1, 2014 by TheBloke

[DoubleYou]

I will say that MO seems to process BSAs faster than loose files. It used to well-nigh freeze MO when I had my HRDLC optimized textures in loose files. In BSAs, fast as a blink.

 

BTW, MO seems to stand a chance for File of the Month. It already has 42 votes, and it's only the first day.

[TheBloke]

BTW, MO seems to stand a chance for File of the Month. It already has 42 votes, and it's only the first day.

Ooh, thanks for the heads up! I have voted. And I see it's gained 1k endorsements - an increase of 10% - since 1.2.5 came out. Outstanding! 

 

I will say that MO seems to process BSAs faster than loose files. It used to well-nigh freeze MO when I had my HRDLC optimized textures in loose files. In BSAs, fast as a blink.

 

Yeah there's definitely going to be some improvement difference, I guess the question is in what configurations and setups it's significant.

 

Can I ask, how long ago was it when you had HRDLC textures as loose? When did you BSA them?  The reason I ask is because of the huge performance boost introduced by 1.2.1 beta relative to 1.1.2 and before (a major optimisation of findfirstfile Tannin said.)  At the time I moved to 1.2.1, I had 100% loose and I was on slow HDDs, and I noticed a vast improvement - something like 400% in fact (with all loose and on HDD, upgrading to 1.2.1 from 1.1.2 caused my cold/uncached MO refresh time to drop from 60+ seconds to 15 seconds. Later on SSD, still with all loose files, it dropped to 1-2 seconds max. My refresh time now, with lots of mods now in BSAs, is <1 second.)So I'm just wondering whether it might have been a little while ago that you had HRDLC as loose, and whether there's any chance you're comparing HRDLC-as-loose-in-1.1.2 versus HRDLC-as-BSA-in-1.2.1+?  In which case the massive performance boost introducd by 1.2.1 would be a big factor.If not, then yeah that's definitely worth factoring in.  I can't say I've noticed any freeze type situations even with 100% loose (including mods like Interesting NPCs which have 10s of thousands of files in their BSA.)  But I'm now on SSD; there were definitely noticeable loading lags when I was on HDD.  One user - noobzor - did report on these forums he got a noticeable performance benefit, both in startup times and in-game FPS/cell-loads. So I certainly wouldn't discount it. But I still believe it's primarily going to be a factor of disk speed. On slow HDDs, which have appalling random read speeds, you gain enormously from having large, contiguous files that can be read sequentially. On SSDs, 4kb random reads are nearly as fast as sequential reads, and more than 100x as fast as random on HDD. So on SSDs it doesn't matter nearly as much how your data is configured.Of course on any storage there's always going to be a small benefit to reading one file versus 10k or 100k, just in terms of the number of syscalls done. But I would guess that if the storage is fast enough, that's usually in the negligible category when it's a one time load. In my case for example, on SSD moving from all-loose to having lots of BSAs (all large mods as BSA), I saw my shortcut-to-Skyrim-menu time drop from about 30-31 seconds to 26-27.

 

So it's not nothing, even on SSD.  It's just not all that important overall, at least in my experience and in my opinion.  What would be far more valuable is measurable in-game performance changes, but I didn't experience that.

 

I'm thinking of doing some benchmarks - BSA vs loose on both HDD and SSD - so that we can have some hard data to work with.  That might give us a clearer picture from which to base recommendations.  

Edited July 1, 2014 by TheBloke

[DoubleYou]

My harddrive is 5400 RPM, so I realize the difference between 10 50 kb files versus 1 500 kb file (just an example).

 

And I switched during 1.2.1.

And MO is up to 71 votes already. If we keep at this rate, it will definitely be file of the month for July.

[TheBloke]

Yeah OK fair enough.  Yeah that's exactly the sort of hardware config where I could definitely see BSA providing noticeable, or even very major performance gains.  

 

With a mod like Interesting NPCs, we'd be comparing 10k or 20k small reads, a few blocks at a time, potentially scatted all across a slow HDD, versus one single 200MB file, which is quite possibly written contiguously and so can be read sequentially with only a handful of expensive disk seeks.  The difference in that case can be literally 100x or 200x greater.

 

I'll see what I can do on some benchmarks, I think it would be useful if STEP could say "If you have this sort of HW, then extracting BSAs isn't going to hurt your performance much; feel free to do so if you find it more convenient.  But if you have this sort of HW, your performance will be decreased by a factor of X and you are not recommended to extract unless you really need to, on a case-by-case basis."  Knowing what X is can be helpful for (advanced) users to make an informed choice.

 

(I realise the default recommendation of STEP is going to change to be not to extract by default, and I fully agree with that.  But I'd think that it would be useful, and appreciated by users, to provide some additional info to accompany that recommendation.  Especially as the default advice in 2.2.9 will be the exact opposite of before: going from 'always extract' to 'never extract'.  People will likely appreciate knowing more about why that is, and what factors are involved.)

Edited July 1, 2014 by TheBloke

[DoubleYou]

I suggest you make a new thread for such testing. This thread is already long enough.

[TheBloke]

Yeah I will :)

Edited July 1, 2014 by TheBloke

[GrantSP]

I just experienced the strangest bug with regard to MO's handling of bsa files.

 

I have Immersive Armors installed and it outfits Kjar (the ship captain that takes you to Solstheim) in a Sea-Dog pirate-like outfit.

Included in this mod is the Hothtrooper44_Armor_Ecksstra.bsa which also has an esp. Now since MO handles bsa files without the need for dummy esps like this one it prompts you to uncheck it, which is how my setup has had it for months now.

 

So with no other armour/clothing mods installed after this one, and the left-hand pane having Immersive Armors with a high enough priority to beat any other potential conflict I started the game and headed out to get my boat ride.

Well imagine my surprise to see Kjar sitting on his boat with no textures displayed on his fancy new Sea-dog outfit. He was all blue. So, quit out and check for load-order problems. None. On a hunch I checked the esp that would ordinarily load this bsa and started the game.

Success, he is now clothed in what are quite snazzy duds. Quit out again and check what is going on.

This time I unchecked the esp and started the game, just to make sure that was the problem. This time the textures are still loading.

 

To make things clear. After installing all the armor/clothing type mods for this profile many months ago I have not seen any issues with missing textures. In fact I haven't had missing textures on anything, clothing or environment. The only thing that I have done in the last week was check to see how MO handles the file conflict process with bsas as archives and without them as archives. That involved unchecking the option on the data tab and refreshing before examining the Conflict tab.

 

This makes me think we might need to actually have these esps checked just once and then disable them, though for the life of me I can't see why or how that would work.

 

Anyone else seen any oddities with MO's bsa handling? 

Edited November 3, 2014 by GrantSP

[Tannin]

To my knowledge there is no cache or something in the engine between runs, I don't think you need the esp active at any time.

My guess is that either the engine failed to load the texture due to a glitch (insufficient memory or something) which isn't actually related to how the bsa is loaded or (and I'm afraid this is more likely) MO failed to write/update its archives list before starting the game. In this case the bsa isn't loaded, but not because the mechanism is inherently broken but because of a bug in the implementation.

If you still have the ModOrganizer_.log from the time the texture was missing you could look into it and see if the bsa in question appears in the list of "aaa maps to soandso.bsa"

[GrantSP]

Thanks Tannin.

I purposely didn't post this in the MO bug reports since I don't view it as a bug, more of a curiosity that may be seen by others. I'll check the log tomorrow and see.

[DoubleYou]

One of these days I'll get around to "graduating" this into a wiki advanced guide to BSAs. I also would like to note the following facts about Skyrim's BSAs that I discovered when investigating the INI files:

sResourceArchiveList
This is a list of BSAs to be loaded without a plugin. Do not touch this if Mod Organizer is handling BSAs. The default value for this setting is incorrect if left out of the INI file. Unless you are using Mod Organizer, which automatically handles BSAs (it does not matter if you are using its BSA management or not), you need to include this line in your INI with Skyrim - Misc.bsa, Skyrim - Shaders.bsa, Skyrim - Textures.bsa, Skyrim - Interface.bsa, Skyrim - Animations.bsa, Skyrim - Meshes.bsa, Skyrim - Sounds.bsa. This prevents incorrect BSA handling.

Default is SKYRIM - MISC.BSA, SKYRIM - SHADERS.BSA, SKYRIM - TEXTURES.BSA, SKYRIM - MESHES.BSA, SKYRIM - ANIMATIONS.BSA, SKYRIM - VOICES.BSA, SKYRIM - VOICES2.BSA, SKYRIM - INTERFACE.BSA, SKYRIM - SOUNDS.BSA (although default set by the game from the Skyrim_default.ini is Skyrim - Misc.bsa, Skyrim - Shaders.bsa, Skyrim - Textures.bsa, Skyrim - Interface.bsa, Skyrim - Animations.bsa, Skyrim - Meshes.bsa, Skyrim - Sounds.bsa).

sResourceArchiveList=string


sResourceArchiveList2
This is a continuation of the list of BSAs to be loaded without a plugin. Do not touch this if Mod Organizer is handling BSAs. The default value for this setting is blank if left out of the INI file. Unless you are using Mod Organizer, which automatically handles BSAs (it does not matter if you are using its BSA management or not), you need to include this line in your INI with at least Skyrim - Voices.bsa, Skyrim - VoicesExtra.bsa. This prevents incorrect BSA handling, which is the cause of the infamous Esbern's missing voice bug.

Default is blank. (although default set by the game from the Skyrim_default.ini is Skyrim - Voices.bsa, Skyrim - VoicesExtra.bsa).

sResourceArchiveList2=string

It should also describe how Mod Organizer redirects BSAs to short names with aaa,aab,aac, etc. to avoid the problems with the string.

 

What I would really like to know is how MO avoids the 255-character limit. I think the above is the way that MO solves it, because you would need 64 BSAs to use up all 255 characters in sResourceArchiveList and 64 more BSAs to fill up SResourceArchiveList2, so you would need a massive 128 BSAs in your modded setup to break it.

 

I guess I could test that theory by coming up with a modded installation with that many BSAs.

[Tannin]

MO applies two tricks to increase the bsa limit.

One is the name-shortening: Every bsa only takes 4 letters (including the comma)

 

The other is a hack very similar to what nitpick does: The first time the game tries to read the archive list MO searches the call stack for the buffer being read to and replaces it with a far larger buffer. If this is successful the limit is increased to 65536 characters allowing MO to store thousands of bsas in the list.

Although this is quite hacky it appears to work fairly reliable unless nitpick is active as well or on cracked executables.

[DoubleYou]

MO applies two tricks to increase the bsa limit.

One is the name-shortening: Every bsa only takes 4 letters (including the comma)

 

The other is a hack very similar to what nitpick does: The first time the game tries to read the archive list MO searches the call stack for the buffer being read to and replaces it with a far larger buffer. If this is successful the limit is increased to 65536 characters allowing MO to store thousands of bsas in the list.

Although this is quite hacky it appears to work fairly reliable unless nitpick is active as well or on cracked executables.

Thanks! That is invaluable. At least I was half right. Is the buffer change applied to the other games (Oblivion, Fallout, etc.) or only to Skyrim?

[GrantSP]

Have to agree, that small piece of information is indeed invaluable. Thanks @Tannin.

[Tannin]

Thanks! That is invaluable. At least I was half right. Is the buffer change applied to the other games (Oblivion, Fallout, etc.) or only to Skyrim?

It should work on all games though it's hard to say if it will work on every possible variant (different languages, steam versions vs. standalone,...)