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!
 

[DoubleYou]

 

"BSAs may also be unpacked in this tab by right-clicking the BSA and selecting Extract... This will extract the BSA's contents to any folder you choose.An accompanying ESP file to extract the BSA is not necessary in Mod Organizer. The only requirement is for the BSA to be checked here. "

 

This is not very clear, since the ESP does not extract the BSA ... or is the BSA effectively extracted when the BSA is checked? .... I hope you see what I mean: there are ways we can be stating things that are more explicit and clear. The above leaves questions and even invokes new ones and is not isolated among the doc.

Sorry, that was my fault. Must have been a little confused that day. It should read "An accompanying ESP file to LOAD the BSA"

[DoubleYou]

 

@DoubleYou (and Tannin or whomever)

I am afraid that I am still not clear on how MO handles BSAs. If I take the explanation about BSA priorities in the MO guide, then

• It would seem that MO can prioritize BSA content (as a solid block of assets) according to the install prioritization rather than the plugin prioritization, thus, decoupling a BSA from its plugin. Yes, entirely, if the BSA is checked in the Archives tab. I would not say that it treats it as a solid block of assets, however, as a Mod Organizer proactively scans BSA/loose file conflicts and doesn't load loose files that would provide asset management contrary to mod priority order as perceived via the data tab.
• When a BSA in the Archives Tab is checked, it allegedly loads according to install prioritization, but if it is unchecked, it is loaded according to its plugin prioritization Yes ... this does not jive ??? at all with the caption on the bottom of the Archives Tab window ("Marked archives ( ) are still loaded on Skyrim but the regular file override mechanism will apply: Loose files override BSAs, no matter the mod/plugin priority") I think you are confusing MARKED-with-warning-icon BSAs with CHECKED BSAs; I only get the symbol if the BSA is unchecked and has a plugin that is checked in the Plugins Tab. Correct. Otherwise, the BSA is either checked or unchecked with a deactivated plugin. Furthermore, right clicking the BSA provides an option to extract. Very useful feature. Finally, dummy plugins used only to load a BSA are potentially redundant entirely unnecessary, but otherwise not if the BSA is unchecked in the Archives tab. This is all very confusing, so we need a very clear explanation of the four scenarios and if any of the four scenarios following do or do not apply if extract is/is not used AND/OR if the plugin is a dummy or not:
  • 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." Checked BSAs will NOT overwrite if I'm not mistaken, which is why unchecking BSAs can be dangerous.
  • 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 never existed.
• Is checking/unchecking in the Archives Tab an alternative to BSA registration or is this effectively accomplished by registering the BSA in Skyrim.ini? Yes and no. This goes back to the the Nitpick fix I think, and is a hack that acts like injection into the ini but is not actually doing so, if my memory is serving me correctly. BSA registration is definitely not an alternative to checking it in the Archives tab.
• Does MO scan BSA archives and include the asset conflict information in Mod-Right-Click > Information > Conflicts? Yes, except archives located in the actual data directory.

 

[fireundubh]

The only time we extract a BSA is if we need a lower priority BSA. Then we could hide the extracted file(s) as needed. Also, texture optimization, but we can get around that by uploading pre-opted BSAs.

I'd also wager that SSD read speed is faster than BSA decompression/read speed. Edited May 23, 2014 by fireundubh

[TechAngel85]

So in other words DoubleYou the only mods we need to extract are texture mods that are higher in priority that we want to hide files in so that lower priority files can take priority?

 

 

Currently I believe there is no STEP mod that requires such treatment, but that could be a potential case, but it wouldn't necessarily need to be a texture. It could be a mesh or other asset as well.

Keep in mind that we so have assets in STEP that have instructions to hide certain files and this is a feature that might become move important as STEP grows. Whether these are BSA assets or not, I couldn't tell you without checking every single one because I am one of those users that extract all BSAs. This is mainly a habit from Wrye Bash days where if you didn't extract them, you wouldn't be able to see the conflicts which is needed for testing/troubleshooting purposes; not just for STEP (which it is greatly important for us) but also for the community as a whole. If MO allows for proper conflicts to be registered (in the conflicts tab) for BSA assets then there is little reason to extract BSAs since MO essentially treats them as being loose files and the installation loader (normally) holds the keys to which assets are loaded in which order.

 

The exception to this and when BSAs should be extracted (from my point of view) are:

 

When the BSA contains assets that need to be hidden. This is necessary because the file tree tab (where you can hide these assets) will only show the BSA and its ESP. Thus, extraction will be needed to hide files. If Tannin were to ever be able to add a way to hide assets within BSAs without extracting them, then is one exception would go away and there would be no reasons (that I can think of) to extract BSAs while using MO.

[EssArrBee]

I'd also wager that SSD read speed is faster than BSA decompression/read speed.

Not sure what you talking about. SSD vs HD, obviously SSD is faster, but once you get to DRAM all the up the ladder to registers that wouldn't even matter. If you are talking about retrieving data from disk memory then you add like 5 clock cycles for decompression if it is considered native. I'm assuming that the Creation Engine has native support for decomp on Bethesda Software Archives, so the difference is negligible. It used to be something we worried about with Oblivion because it was single core dependent, but with multi-core support there is no longer a need to worry about the difference. 

[phazer11]

The only time we extract a BSA is if we need a lower priority BSA. Then we could hide the extracted file(s) as needed. Also, texture optimization, but we can get around that by uploading pre-opted BSAs.

Yes, for the STEP guide only, for packs like REGS or Skyrim Revisited where you have to optimize textures and such to play them without overload I'd think it's a bit much to expect the guide authors to do.

[Aiyen]

Afaik then the only way one can reasonably come up with the "performance" argument is if a user is on a PC where the CPU is rather old but is still able to run the game. More so if you have an SSD and or low amounts of RAM. However I am fairly certain that this does not apply to the vast majority of the player base. Even when one include the laptops. 

Even then most of the difference is in load times, and is measured in a few seconds tops... unless something is really bogging down the system. 

 

The only reason to do extraction is for convenience if you are going to alter assets. As for repackaging back when you are done for performance reasons then the above still apply.  

 

In general if one have issues with loading times and massive amounts of stuttering then it is much more likely that one is running way too many textures and high detail meshes. 

 

In fact I think the only reason some people still use this argument is because it has been around since oblivion where the PC´s where not as powerful, and where the differences where noticeable. 

 

All that said then nice to see that this discussion is producing some nice information! 

[Kuldebar]

I don't like archives in my mod folders because I want them readily searchable via a simple file name search and laid out in such a way that if I want to hide one file, or replace it even; I can do so.

 

I have had several problems with USKP "fixes" that broke something in my game. If I hadn't known about BSA extraction, I'd never resolved the issue by myself. Curiously, Arthmoor wanted to blame MO's BSA handling for the problem which it was certainly not the case! And here was the fix:

 

 

QuoteQuote

So, using MO, (proudly using MO!) I used the "hide" function on the mesh and texture that caused the problem:

"C:Mod OrganizermodsUnofficial Skyrim Patchmeshesactorscharacterfacegendatafacegeomskyrim.esm0001367c.nif"

"C:Mod OrganizermodsUnofficial Skyrim Patchtexturesactorscharacterfacegendatafacetintskyrim.esm0001367c.dds"

 

Just to be clear: these files weren't overwriting anything, they just were causing a problem from their very existence in my mod order.

 

This issue has persisted through the last two USKP releases, each time I have had to hide those two files or an NPC in Half-Moon Mill gets a bad face lift.

 

Without the USKP Fix:

 

 

With the USKP "Fix"

Edited May 23, 2014 by Kuldebar

[Kuldebar]

 

 

In fact I think the only reason some people still use this argument is because it has been around since oblivion where the PC´s where not as powerful, and where the differences where noticeable. 

 

 

The "argument" still has merit, compression adds another layer of work for the CPU to deal with, even if it is a relatively small work load by modern standards. The same principle is involved with the much discussed EnableCompression setting in the ENB config file; the consensus is that compression can cause stuttering/slowdown and performance penalties for some computer systems.

[Tannin]

The "expected/intuitive way" depends on the perspective of the user. That may be why I have been getting confused and seeing mixed messages.

We are sooo going in circles here... There are no mixed messages in MO. There are mixed messages between posts on the internet that don't discuss MO at all and what MO does.You are confused because you desperately try to apply knowledge that is completely unrelated no matter how often I tell you "MO doesn't work like Lojack said when he wasn't talking about MO but MO works like MO tells you how it works!"MO has a conflicts view. There it tells you which files conflict in which mod. And it gives you a warning if something you configured makes the conflicts view display wrong information. One line. And this is the truth, this is the reality and NOTHING you have ever read outside of MO is relevant to how asset ordering works in MO. There is one single line of information you have to read and comprehend to know everything you need to know.In standard Skyrim asset priorization you have to know which types of asset-containers are applied in what order, you have to know your installation order and you have to know your plugin order, all of which lojack documented in a lengthy post and from that information you can deduce which assets get used.In MO you don't have to know this stuff, you just look at the conflicts view. And therefore, since there is no need to "know" technical details to understand what happens we don't need a lengthy documentation.All it could ever do is confuse the users, make them think there is something complicated to necessitate hundreds of lines of documentation, make them believe there is difficult stuff they need to know when there really isn't.

This is effectively like not installing the mod; however, the BSA could still be registered in Skyrim.ini, but as I understand it, MO does not effectively register BSAs via INI tweaks, right ... ?

When did ini tweaks become a part of this discussion? Forget ini tweaks, they have nothing to do with anything.MO virtualizes the ini file as well as FS. When you allow MO to manage a bsa that bsa will be loaded through the (virtual) ini file but this is a technical detail, you don't care about it!And please stop talking about "registered BSAs"! That is a term lojack used and is explained as "BSAs that have priority lower than plugin-loaded BSAs and loose files". This is not how BSAs work with MO. They are loaded in the same way but that is a technical detail, you don't care about it!

If I understand correctly from your explanation above, the standard load mechanism and prioritization are in effect when the plugin is checked but the BSA is not: The BSA is loaded with the plugin, and the BSA assets override other plugin-loaded BSAs loaded previously (as well as registered BSAs), but loose assets still override the assets within this BSA, regardless of the install prioritization of the loose asets (this is the standard behavior outside of MO). Is that correct (if it is, I will propose a better info text to avert confusion).

Yes it is correct, no it's NOT a better info text because it explains how MO isn't supposed to work! Why would I document inside MO how MO doesn't work?

This is another big point of confusion for me. Are you saying that MO adds an INI tweak to Skyrim.ini to register the BSA? I assume NO. I assume that MO loads this BSA according to the install prioritization as described above and that BSA registration is not even involved ... ?

What I'm saying is: that is a technical detail, you don't care about it!

OK, so NONE of the Skyrim BSAs' assets (including the official DLC) are exposed within the conflict resolution of the mod Information dialog box.

And why would they? IF the vanilla BSAs were exposed then every single asset that replaces something in the game would be in conflict! And, since you can't modify the "installation order" of the original data directory you couldn't do anything about it.

But removing elements of control punnishes those that understand the functionality (or those that want to, are trying to, and are wise enough not to bother mod authors for their own lack of understanding).

While true, I do this in my spare time, I don't get paid for my work on MO. Satisfying the users, while important to me it is NOT my primary concern. And while user groups usually find reasons why they should be more important to the dev than others, they aren't right. If a feature is mildly useful for user A but a major annoyance for user B I'll remove/replace it, no matter how much user A thinks he is more important.

Certainly, your testers (the MO and STEP staff among them) need to remain wary of what happens if things are not working correctly and to recognize any signs of problems. And we need to boldly emphasize certain talking points that address anything controvercial or not well understood.

"not working correctly" means "working different from how it was designed" not "working different from how someone expected it to work".Testers, like regular users primarily need to understand how MO is supposed to behave so they can recognize a deviation but they don't need to know how it is implemented.

[Tannin]

The "argument" still has merit, compression adds another layer of work for the CPU to deal with, even if it is a relatively small work load by modern standards. The same principle is involved with the much discussed EnableCompression setting in the ENB config file; the consensus is that compression can cause stuttering/slowdown and performance penalties for some computer systems.

compression adds work to the cpu but lessens the work on the disc. But CPU speed has increased much much faster in the last couple of years than disc speed. Therefore compression on an even remotely modern system, basically anything able to run skyrim, compressed BSAs are way more likely to reduce stuttering than increase it.

 

The enb topic is completely unrelated. BSA data is compressed on disk and uncompressed very rarely (i.e. on startup, when switching zones).

ENB data, if I understood the point of that setting correctly is about data compressed in memory and uncompressed every frame.

[fireundubh]

While somewhat OT, the only real way to determine whether loose files load faster than a compressed BSA on a SSD is to run that test.

 

I have an Intel Core i5-3570k @ 3.4Ghz, 16GB DDR3-1600, and a Samsung 840 EVO SSD.

 

The performance gain, if any, from loose files is probably negligible, but the potential placebo effect is to-die-for!

[GSDFan]

@z929669

 

 

One point though is that all of the Skyrim - * BSAs are greyed out (untoggleable) and checked (these are registered in the Skyrim.ini), but official DLC BSAs are not grayed out and behave like any other add-on BSA (these have plugin loaders and are NOT registered in Skyrim.ini, nor should they be). A brief word about the greyed out registered Skyrim - * BSAs would be helpful.

This is controlled in the settings under Wordarounds, Force-enable game files. Removing the check will set them be able to be toggled in the data tab.

[TechAngel85]

[snip] but this is a technical detail, you don't care about it! [snip]

This statement... It's a bit unrealistic to think that some users (however small a group they are) aren't going to "care about" how MO works on some of the more "technical details". These are the "power users" and technical minded individuals which make up the majority of the STEP Admin/Staff/Moderators as well as the "old school" modders. S4N and Z are two of the most logical and technical minded people I've ever known. This small group of people are going to want the documentation and are going to want to know the technical details because it's in their very natural to do so and you can't change human nature.

 

I understand MO is designed in a way to make it super simple to mod for the majority of users without having to know a lot of technical aspects of modding. This is the reason it has been a more popular platform for new modders while many of the old modders tend to want to stick with WB (even though its develop has gone six feet under). You've done a brilliant job making MO simple for users with the black magic you coded into it! Well done on that!

 

However, the majority of the "old school" modders are going to have all the knowledge and "old ways" instilled into them from years and years of modding games. Asking this group to "not care about the technical details" is akin to "teaching an old dog a new trick"...it's nearly impossible, if not completely impossible. (You have no idea how long it took the whole staff to convince Z to swtich from WB to MO... ). Because of these old-way-modders and the logical and technical minded people, it will make it much harder for them to simply use it "because it works" without knowing the details behind why and how it's working compared to new users who are just going to use it...because it works.

 

I hope that sheds some light on the "whys" and "hows" that you are getting from Z and other modders that fit into that group (btw, the Unofficial Patch teams fit into that group as well which is likely why they have some negativity towards MO...most of the "power house authors" are "old school modders").

[Tannin]

This statement... It's a bit unrealistic to think that some users (however small a group they are) aren't going to "care about" how MO works on some of the more "technical details". These are the "power users" and technical minded individuals which make up the majority of the STEP Admin/Staff/Moderators as well as the "old school" modders. S4N and Z are two of the most logical and technical minded people I've ever known. This small group of people are going to want the documentation and are going to want to know the technical details because it's in their very natural to do so and you can't change human nature.

Well, maybe, I can't keep you from looking into the details, but if you're going to start documenting stuff that isn't relevant to the average users and may be confusing as hell then at least put a f***ing big note at the very top saying: "If you're a regular user you don't need to know this and unless you have a CS degree or an equivalent amount of computer experience you're not going to understand it".I don't want the average user to think about this kind of stuff because it's me who'll get all the bothersome questions.

I understand MO is designed in a way to make it super simple to mod for the majority of users without having to know a lot of technical aspects of modding. This is the reason it has been a more popular platform for new modders while many of the old modders tend to want to stick with WB (even though its develop has gone six feet under). You've done a brilliant job making MO simple for users with the black magic you coded into it! Well done on that!

thanks :)

However, the majority of the "old school" modders are going to have all the knowledge and "old ways" instilled into them from years and years of modding games. Asking this group to "not care about the technical details" is akin to "teaching an old dog a new trick"...it's nearly impossible, if not completely impossible. (You have no idea how long it took the whole staff to convince Z to swtich from WB to MO... ). Because of these old-way-modders and the logical and technical minded people, it will make it much harder for them to simply use it "because it works" without knowing the details behind why and how it's working compared to new users who are just going to use it...because it works.

I can understand that but I develop MO for anyone who wants to do modding and needs to have more control. What we actually need is several documentations:- If you're new to modding, here is what you have to know- If you're an experienced modder who hasn't used a manager before, here is what you have to know- If you're a converting NMM user, here is what you have to know- If you're a converting Wrye Bash user, here is what you have to know 

I hope that sheds some light on the "whys" and "hows" that you are getting from Z and other modders that fit into that group (btw, the Unofficial Patch teams fit into that group as well which is likely why they have some negativity towards MO...most of the "power house authors" are "old school modders").

Sure, but my expectation is that someone who is into modding and spends a considerable amount of his time on the topic is going to read the documentation available whereas someone who only cares about higher-res textures and more bad-ass dragons is not going to read a lot because his prime interest is playing the game not tinkering with it.Hence I try to optimize my UI for the second group and expect the former group will find their information in "what's this"s and the wiki. I'm still convinced that everything discussed in this thread has already been sufficiently explained inside MO and outside as long as you trust that my documentation doesn't lie to you.However if you go

but I heard somewhere else that skyrim works like this and I'll assume that the information I got when I was younger is more trustworthy and therefore the MO documentation must be wrong or mean something else than what the words say

I really can't help you.