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!
 

[Kuldebar]

  If you ask me the only mods that affect the PMOP warning are game changing mods (Which have the scripts). Unless it is a game changing mod that affects textures that you need to hide for earlier texture mods I don't understand why we need to extract all of the BSAs. Now on the other hand texture mods shouldn't have scripts so they should be able to be extracted with no issues and really the only ones that would need extracted are texture mods that are later in the install order that need to have textures hidden if you want to a texture from an earlier mod.

I know you guys get tired of explaining how things work but please if my thinking is wrong explain to me why.

Outside of what I previously stated, everything else is hunky-dory with MO.

 

The issue involved users being left in the dark about how the official files/DLC's were being treated when left in their default locations and the interaction between the mods like the Unofficial Patches and relevant priorities.

[z929669]

@Aiyen
No It does not have anything to do with plugni sorting between ESP and ESM. Each USP should come directly after each of the corresponding vanilla and DLC plugins. So:

[*]Skyrim.esm + Update.esm are loaded [*]The USkP makes changes to the vanilla game. [*]Dawnguard DLC alters the game in new ways. [*]The UDgP alters Dawnguard - and if necessary forwards anything Dawnguard broke in vanilla. [*]Hearthfires DLC alters the game in new ways. [*]UHfP alters Hearthfires, and again, forwards up any vanilla stuff it broke [*]Dragonborn DLC alters the game in new ways. [*]UDbP alters Dragonborn, and again, forwards up any vanilla stuff it broke

The problem is that because MO does not treat the DLC BSAs as loose files when checking the BSAs under the Archives Tab (as it does with all other mod BSAs we (i) have learned), the DG assets do not override the USkP assets when the USkP BSA is unpacked, and since the UDgP does not override these same assets again (the DG assets are correct in the context of DG and do not need fixing), then anyone running DG and the USkP that follows the install instructions but also uses MO will get the bug, but ONLY if the USkP BSA is extracted and the DG BSA is not. This was actually something that I was doing as well as Kludebar. Once I reinstalled the USkP with BSA intact, the problem was resolved. The question is: how many similar problems exist in our setups? Who knows, but I will simply stop extracting BSAs unless I really need to, especially when it comes to mods that follow the standards set by Bethsolft under advisement of the USP team. If checking the DLC BSAs in the Archives Tab followed same treatment as other BSAs, this problem would not exist.
 
It turns out that if we want to go updating and optimizing vanilla assets, then there are some considerations relating to Steam autoupdate, BSA unpacking and relationships with prioritization standards in place.

My concern is that MO users have a unique set of installation instructions and "best practice" apart from everyone else.

[Kelmych]

@Aiyen

No It does not have anything to do with plugni sorting between ESP and ESM. Each USP should come directly after each of the corresponding vanilla and DLC plugins. So:

[*]Skyrim.esm + Update.esm are loaded

[*]The USkP makes changes to the vanilla game.

[*]Dawnguard DLC alters the game in new ways.

[*]The UDgP alters Dawnguard - and if necessary forwards anything Dawnguard broke in vanilla. It does not currently forward anything Dawnguard broke in vanilla; it assumes the Dawnguard DLC-provided change of the vanilla assets is adequate

[*]Hearthfires DLC alters the game in new ways.

[*]UHfP alters Hearthfires, and again, forwards up any vanilla stuff it broke It does not currently forward anything Hearthfires broke in vanilla; it assumes the Hearthfires DLC-provided change of the vanilla assets is adequate

[*]Dragonborn DLC alters the game in new ways.

[*]UDbP alters Dragonborn, and again, forwards up any vanilla stuff it broke It does not currently forward anything Dragonborn broke in vanilla; it assumes the Dragonborn DLC-provided change of the vanilla assets is adequate

The problem is that because MO does not treat the DLC BSAs as loose files when checking the BSAs under the Archives Tab (as it does with all other mod NSAs we (i) have learned), the DG assets do not override the USkP assets when the USkP BSA is unpacked, and since the UDgP does not override these same assets again (the DG assets are correct in the context of DG and do not need fixing), then anyone running DG and the USkP that follows the install instructions but also uses MO will get the bug, but ONLY if the USkP BSA is extracted and the DG BSA is not. This was actually something that I was doing as well as Kludebar. Once I reinstalled the USkP with BSA intact, the problem was resolved. The question is: how many similar problems exist in our setups? Who knows, but I will simply stop extracting BSAs unless I really need to, especially when it comes to mods that follow the standards set by Bethsolft under advisement of the USP team. If checking the DLC BSAs in the Archives Tab followed same treatment as other BSAs, this problem would not exist.

 

It turns out that if we want to go updating and optimizing vanilla assets, then there are some considerations relating to Steam autoupdate, BSA unpacking and relationships with prioritization standards in place.

 

My concern is that MO users have a unique set of installation instructions and "best practice" apart from everyone else.

 

For some valid reasons the USP team introduced false-flagged plugins that load before some of the DLC plugins. This is a challenge for all mod managers if optimized vanilla textures are used. It's even more difficult to do this with Wrye Bash than with MO.

 

As I commented above, the USP mods provide fixes only for the associated Bethesda esm. If a DLC breaks something in vanilla then USP expects that the DLC BSA/plugin includes the fix for what was broken in vanilla; the USP DLC-specific mod does not include this. It the fix in the DLC was bad I expect the USP mod would fix it since it's part of that DLC.

[DoubleYou]

The whole problem is caused by the fact that the Unofficial Patches must have there BSAs loaded between the official DLC BSAs. Before the false-flagged plugin change, there was no issue, because no mod needed to be placed in such a position.
 
I actually had theorized this could be an issue and was going to test this awhile ago, but never got around to it, and so it now has only become apparent to us once we saw the issues. That's why initially I had a note on a place in the wiki to uncheck the Unofficial Patch BSAs, but retracted because I had not actually tested to see if this was a real problem. 
 
Currently my setup has the unofficial patches at the very top of my modlist, so it looks like this:

STD
Distant Decal Fix
Unofficial Skyrim Patch
Dawnguard DLC
Dawnguard Optimized Textures
Unofficial Dawnguard Patch
Hearthfires DLC
Hearthfires Optimized Textures
Unofficial Hearthfire Patch
Dragonborn DLC
Dragonborn Optimized Textures
Unofficial Dragonborn Patch
Cleaned Bethesda ESMs
HRDLC1
HRDLC2
HRDLC3
Unofficial High Resolution Patch
 
This fixes the following potential issues (some of which have been confirmed) with the old setup:
 
Between Unofficial Skyrim Patch and Dawnguard...

[*]textures/actors/character/facegendata/facetint/skyrim.esm/0001367c.dds (confirmed here) [*]textures/actors/character/facegendata/facetint/skyrim.esm/000132aa.dds [*]scripts/wealiasscript.pex (not a problem if the user also uses Unofficial Dawnguard Patch) [*]scripts/qf_tg05_00021551.pex (not a problem if the user also uses Unofficial Dawnguard Patch) [*]scripts/qf_da04_0002d512.pex (not a problem if the user also uses Unofficial Dawnguard Patch) [*]scripts/playerwerewolfcuresconcescript.pex (not a problem if the user also uses Unofficial Dawnguard Patch) [*]scripts/playervampirequestscript.pex (not a problem if the user also uses Unofficial Dawnguard Patch) [*]scripts/nightmothercoffinscript.pex (not a problem if the user also uses Unofficial Dawnguard Patch) [*]scripts/fxdwarvenspiderscript.pex [*]meshes/actors/character/facegendata/facegeom/skyrim.esm/0001367c.nif (confirmed here) [*]meshes/actors/character/facegendata/facegeom/skyrim.esm/000132aa.nif

Between Unofficial Skyrim Patch and Hearthfire...

[*]scripts/relationshipmarriagespousehousescript.pex (not a problem if the user also uses Unofficial Hearthfire Patch) [*]scripts/qf_relationshipmarriagefin_00021382.pex (not a problem if the user also uses Unofficial Hearthfire Patch) [*]scripts/qf_housepurchase_000a7b33.pex (not a problem if the user also uses Unofficial Hearthfire Patch) [*]scripts/playersleepquestscript.pex (not a problem if the user also uses Unofficial Hearthfire Patch) [*]scripts/mannequinactivatorscript.pex (not a problem if the user also uses Unofficial Hearthfire Patch) [*]scripts/carriagesystemscript.pex (not a problem if the user also uses Unofficial Hearthfire Patch)

Between Unofficial Skyrim Patch and Dragonborn...

[*]scripts/dunprogressivecombatscript.pex [*]scripts/dragonactorscript.pex (not a problem if the user also uses Unofficial Dragonborn Patch) [*]scripts/default2stateactivator.pex (not a problem if the user also uses Unofficial Dragonborn Patch) [*]scripts/da04questscript.pex (not a problem if the user also uses Unofficial Dragonborn Patch)

Between Unofficial Hearthfire Patch and Dragonborn...

[*]scripts/byohrelationshipadoptableaccessor.pex

Between Unofficial Dawnguard Patch and Dragonborn...

[*]scripts/da04questscript.pex (not a problem if the user also uses Unofficial Dragonborn Patch)

 

This is a seriously large number of potential problems. The ones that aren't covered by the corresponding unofficial patch are the ones most problematic.

 

One thing I wonder is: does the Unofficial Patch team know about all of these? Some of these are worth looking into for the users who are NOT subverting BSA order, and since they are doing it by hand, do they know about these file differences?

Edited May 26, 2014 by DoubleYou

[z929669]

Good point DY. Thanks for the specifics (if this is what Aiyen was talking about, I misunderstood in my last). I'll see about getting a response back regarding these specifics.

[EssArrBee]

The UPPs are in a current 2.0.4 cycle so lets see if these disappear after UDBP 2.0.4 lands. Though I bet that not all of those concerns will be addressed, like the DG ones.

 

Hey so does anyone know how to false flag an esp? I'm not in the know about such things.

[z929669]

OK, I have been PMing with Arthmoor about much of this stuff (as some of you may have guessed) in order to better grasp the reality and all points of view.  I am presenting some of his feedback that he gave me after lurking this thread and the most recent posts:

 

@Kelmych

Actually, the USPs do forward some things that were broken by the DLC (all three of them), but there's not that much of it. More might be forwarded, but they don't take action on anything that is not formally reported with proper detail and evidence.

 

@DoubleYou

In the load/install order you propose above, "Cleaned Bethesda ESMs" will wipe out EVERYTHING the unofficial patches have done if these are cleaned copies of the originals as supplied by Bethesda. Every single record in every unofficial DLC patch will get completely wiped out by this. Also some fixes in the vanilla patch too if that archive contains a cleaned copy of Update.esm. (I agree as well, since you are re-implementing all of the original records that the USP fix)

 

I will add more detail once I get clarification on a few things.

[DoubleYou]

@Z

The thing about Cleaned Bethesda ESMs is neither here nor there. I could put that at the bottom of my load order and I'd be fine. It only contains the cleaned Bethesda ESMs, none of the BSAs. The only conflicts they have is replacing the vanilla ESMs with the cleaned versions, and I would even be fine putting them at the very bottom of my modlist. I see what you are saying as that is confusing, however, the net effect will be zero. Probably best to have a separate mod for each cleaned ESM and put them in absolute logical order like this:

 

Cleaned Update ESM

STD
Distant Decal Fix
Unofficial Skyrim Patch
Dawnguard DLC

Cleaned Dawnguard ESM
Dawnguard Optimized Textures
Unofficial Dawnguard Patch
Hearthfires DLC

Cleaned Hearthfires ESM
Hearthfires Optimized Textures
Unofficial Hearthfire Patch
Dragonborn DLC

Cleaned Dragonborn ESM
Dragonborn Optimized Textures
Unofficial Dragonborn Patch
HRDLC1
HRDLC2
HRDLC3
Unofficial High Resolution Patch

[z929669]

If you put the cleaned Bethesda ESMs at the bottom of your ESM load order, they will cancel out all USP plugin changes (they DO conflict with all of the USPs ;) ). The BSAs are besides the point in this case. The USP plugins all would be overridden by the cleaned Bethesda plugins. However, you are likely talking about mod install order ... this is a good example of the importance of explicitly distinguishing between the two though!

 

 

On another note, I have been spouting off how MO treats the DLC BSAs differently, and I tried hard to find a reference to that on this thread .. I CANNOT FIND IT! Did I make this up? Possibly. I blame too much information and my limited brain capacity.

 

@Tannin, DoubleYou & GSDfan

FOR THE RECORD: Does MO treat the DLC BSAs differently than USP BSAs with respect to the effect of checking or not checking in the Archives Tab?

 

I think I got the idea in my head because of Kludebar's issue with the vampire tint masks that was also an issue in my own setup after further investigation. I had basically extracted all BSAs in my game (including the USkP) except for the official DLCs. Therefore, USkP assets were overwriting DG assets, because they had loose files priority and would override all assets according to the mod (installer) priority. Because DG is not in the mod (installer) list of any typical setup, it could not be properly prioritized over USkP. I fixed by reinstalling the USkP without extracting the BSA (and NOT checking it in Archives Tab either) so that the BSA assets were loaded just before the DG assets, both of which then were loaded with their respective plugins as dictated by standard plugin load order rules (BOSS/LOOT).

 

SOOO: My guess is that MO is NOT treating the DLC BSAs 'specially' and that the DLC BSAs behave 'specially' since they are not installed via any mod manager ... they are part of the vanilla game already, DUH! So please disregard this piece of all previous arguments I have been making :facepalm: I hope I did not confuse anyone who did not already know better (e.g., I think fireundubh knew better ... sorry!)

 

Aside from this blunder, the same problem still exists, but it is not caused by MO "treating DLC BSAs any differently". It IS an artifact of the Archives Tab behavior allowing BSA assets to behave as loose files and likewise BSA extraction

[EssArrBee]

Cleaned ESMs don't load in a different spot than the vanilla ones. It is just an MO mod folder that DY was listing and BOSS/LOOT will sort out the load order.

 

Anyways, MO treats the grayed out BSAs differently not the DLC ones. I think it has to do with the registered BSAs.

[z929669]

Thanks for confirming SRB :P ... and yes, I did modify my post about DY's list.
 
On another note, I have some info from Arthmoor that may shed some light on this entire issue and provide some rationale into the false-esm flagging decision:
 

 

So, where Kelmych states:

It does not currently forward anything Dawnguard broke in vanilla; it assumes the Dawnguard DLC-provided change of the vanilla assets is adequate

 

... you can attest the first part is actually not true and the last is true for each of the DLC ISPs?

 

Yes, I can attest to that, as my previous example with the apothecary improvement in Breezehome indicates.

Also, yes, I can attest to the fact that if the DLC is changing something in the vanilla game, we do not assume it to be broken without evidence to the contrary, even if the USKP fixed it prior.

You guys are spending a bunch of time on needing evidence, I'd appreciate the same consideration on our side. We're not just doing things willy-nilly.

DoubleYou lists a bunch of "potential" problems, then goes on to say that they are not actually problems if the user is using the corresponding patch. This should be obvious though.

You've got Bethesda to thank for that one. Pretty much every one of those that he's got a parenthetical reference in italics for is something that required a fix to be merged into the DLC patch because DG's edits would otherwise break vanilla fixes from the USKP. If he's suggesting there's more than just these, we don't know about them.

So seriously, if there is something we're missing that you, him, or anyone else there thinks we need to fix - tell us! Contrary to some users' beliefs, we're not actually ascended divines (yet) :tongue:

That vampire facegen thing? I grow tired of explaining it, but I'll give you one last shot at it:

Hert & Hern had the grey face bug with vanilla Skyrim. The USKP fixes this. Hence, the inclusion of the facegen files for them.

Dawnguard modified a bunch of vampires, and generated new facegen.

Originally, because of where the USKP loaded, the UDGP had to clone Dawnguard's facegen. All was well with the world.

With the switch to false-esm files, DG's own assets provide the winning files. The UDGP no longer contains the facegen files. We're kind of OCD about keeping the archives clear of unnecessary files.

It would appear you guys have drilled down into why, something I obviously could not tell Kuldebar at the time because I don't use MO. Frankly I'm not sure I could have even if I did ... I should not have to tell people to move the DLC into mods to let MO manage it - that would simply confuse people.

 

The false-esm decision is laid out here: https://afkmods.iguan...esm-conversion/

 

So hopefully this explains a but of the mystery as to the point of view of the USkP team and some of the decisions they make. They operate with quite a bit more formality than we do around here, so I can understand how issues caused by our practices might create waves of support non-issues that they have to deal with.

All in good fun I hope!

[fireundubh]

Hey so does anyone know how to false flag an esp? I'm not in the know about such things.

Wrye Bash:

 

TES5Edit:

[Kuldebar]

It would appear you guys have drilled down into why, something I obviously could not tell Kuldebar at the time because I don't use MO. Frankly I'm not sure I could have even if I did ... I should not have to tell people to move the DLC into mods to let MO manage it - that would simply confuse people.

 

If he had said that to me it would have saved me a lot trouble and it would not have been all that confusing.

 

 

So the new standard will have us all placing the Official DLC's in the MO's folder system?

Edited May 26, 2014 by Kuldebar

[z929669]

So the new standard will have us all placing the Official DLC's in the MO's folder system?

I don't like the idea of doing that, since it differs for MO versus all other users, but we'll figure it out and put it in the guide once we have a consensus. That is viable though for MO users (of all others, just install your mods in order and let LOOT manage)

[fireundubh]

I don't like the idea of doing that, since it differs for MO versus all other users, but we'll figure it out and put it in the guide once we have a consensus. That is viable though for MO users (of all others, just install your mods in order and let LOOT manage)

You can move the DLC to save disk space. Problems: MO would be required to play the DLC unless you moved the DLC back. Steam may also redownload the DLC if you didn't disable autoupdate.You can copy the DLC to preserve the originals in the Data folder. Problems: You'd have two copies of each DLC taking up disk space and changes to either copy wouldn't be mirrored.You can also try creating symbolic links to the DLC. I don't know if this works, but this method would avoid all problems at the expense of learning your OS.For the latter:1. Create mod folders for each DLC.2. Open a command prompt.3. Type: cd "C:GamesMod OrganizermodsDLC 01 - Dawnguard"4. Type: mklink Dawnguard.bsa "C:SteamSteamAppscommonSkyrimDataDawnguard.bsa"This creates a symbolic link in the Dawnguard mod folder to the real Dawnguard.bsa. MO will treat the symbolic link as the real deal.Repeat for each DLC. Obviously, change the paths to your own. Edited May 26, 2014 by fireundubh