Jump to content
  • 0

Ramifications of BSA Extraction in Mod Organizer


Question

Posted

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.esmUpdate.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:

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 ...  :yes:
 
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!
 

Recommended Posts

  • 0
Posted (edited)

No, sorry, this was misinformation on my part. loose files will still overwrite plugin-loaded bsas.

 

MO allows manual BSA management because there was always the fear that there might be mods that need to be loaded the traditional way.

 

Still, solution 1 I proposed above (and was planning to release) is not feasible: a MO managed BSA can not overwrite a plugin-loaded BSA while loose files do. This means that the moment you have a single BSA not ticked in MO you're in a worsened asset mess of registered bsas vs loose files vs plugin-loaded bsas vs MO managed BSAs.

Ah, okay, I see. So just to be sure -

 

If all BSAs are left managed by MO, then the assets priority load order is:

[*]Registered (official) BSAs

[*]All managed BSAs and loose files, loaded according to MO's mod priority/"install" order

and if BSA management is turned off for even one BSA, then the assets priority load order is:

[*]Registered (official) BSAs

[*]All managed (ticked/checked) BSAs, loaded according to MO's mod priority/"install" order

[*]All un-ticked/un-checked BSAs not managed by MO, loaded according to their corresponding plugin order

[*]All loose files, loaded according to MO's mod priority/"install" order

Have I got that right?

 

I'm also still curious where Update.bsa is, from MO's perspective. The .esm is listed in the plugin load order, but the .bsa doesn't show up in the assets tab.

 

 

Leaves us with the solutions

2. remove MOs BSA management

3. plugin to import dlcs as MO mods

4. hope for the unofficial patch guys to sort out the mess

5. install unofficial patches manually, outside MO

 

5 is a mess, 4 isn't going to happen, 3 goes against the paradigm that MO leaves your data directory alone.

 

"leaving the data directory alone" isn't only about keeping the game in a vanilla state, I want MO to play nice with other mod managers. But if we remove official dlcs from the data directory that effectively "breaks" the game if you run it without MO and should bethesda decide to update dlcs your imported, now-outdated variants overwrite the updated dlcs.

The DLCs are, as someone else mentioned, effectively mods. But they are steam-managed mods, not MO-managed.

 

This leaves 2 as the only feasible solution, right? Remove the archives tab and all connected functionality and MO works like other mod managers in this regard, get rid of the whole controversy.

 

So yes, my second suggestion in my above post is a bit of a hack for your number 5, but I don't see how it's a "mess" because after relocating the UP BSAs to the real /Data directory, MO allowed me to get the Official & UP BSAs in the correct load order. That's what were trying to do on this one point, correct?

 

It does require not unpacking the UP BSAs, but I haven't seen any ground shattering reasons why they would need to be unpacked, especially when any modified assets could be put in another separate mod with a higher priority value (and thus override the ones in the UPs' BSAs)

 

So - is there any way to "trick" MO into thinking the UPs - or even just their BSAs - are located in /data rather then separately, so that the UP BSA priority order can be managed among the official DLCs BSAs? Yes - I know it's a bit of a "hack", but then so was making them false .esm with all of the good reasons to do so, etc. etc.

 

Otherwise, the thing that is most worrisome about throwing out BSA management is how MO would then present conflicts. Would it still properly show conflicts for the plugin-loaded BSA assets with regards to the loose files that load afterwards?

 

Also - the ability to disable "dummy" .esp plugins and still load their BSAs would be gone, right?

Edited by keithinhanoi
  • +1 1
  • 0
Posted

I agree with everything Tannin has stated about the USP changes trowing a wrench into things (I'd say that is the more troublesome deviation from standards at this point) and nearly all of his suggestions about potential fixes.

 

Also, I really don't think that the false-esm methodology is a MUST for the USP. It seems more like a solution to a few problems (possibly, but does not seem proven, but I could be wrong) and even more like a maintenance convenience for the USP team (again, I could be wrong). Regardless, I don't expect them to change the way they do things if it only affects MO users ... it would need to have more far-reaching implications for them to consider reverting back to 'standards'.

 

I agree with Keith though and was thinking the same thing when I read Tannin's post about the USPs 'wanting' to be elevated to vanilla Skyrim status. The only way to resolve this seems to be to grant the USPs 'vanilla' status, since that is the way they are behaving.

 

It seems intuitive to me that by adding the USPs to /Data/ all of the problems should go away, as that masks them from MO and would not really cause much of a maintenance burden for user sat all. A plugin can even be written for MO to 'manage' the USPs in this way (i.e., 'install' these mods into /Data/ for the user). What's more, all of the current MO functionality can basically remain the same.

 

Why is this an issue exactly (if it indeed does work, as I suspect it should)?

  • 0
Posted

@Tannin

I think we have other options. I suggest you allow BSAs to be dropped into the "data" BSA grouping, with a large warning prompt, and allow users to order them there, like somewhat how you did before. Hardcode the Unofficial Patch BSAs to go into the correct order, cause a warning to pop up if a user tries to arrange these in a different order. This should effectively eliminate the current problems, keep MO BSA management, and allow a workaround for later situations that might have a similar problem.

  • 0
Posted

If all BSAs are left managed by MO, then the assets priority load order is:Registered (official) BSAsAll managed BSAs and loose files, loaded according to MO's mod priority/"install" order

well actually, this can be simplified to "asset priority load order is all BSAs and loose files, loaded according to MO's mod priority order" or "asset priority order is mod priorty order"There is no need to make a distinction with registered BSAs because the actual data folder has implicitly the mod priority 0. And "managed" BSA doesn't have to be mentioned as that was part of the precondition. 

Registered (official) BSAsAll managed (ticked/checked) BSAs, loaded according to MO's mod priority/"install" orderAll un-ticked/un-checked BSAs not managed by MO, loaded according to their corresponding plugin orderAll loose files, loaded according to MO's mod priority/"install" order

No, its actually worse than that because a "managed" BSA (let's just call them that) can overwrite loose files if it has higher priority but not a priority-loaded BSA. 

I'm also still curious where Update.bsa is, from MO's perspective. The .esm is listed in the plugin load order, but the .bsa doesn't show up in the assets tab.

For some reason (one I never understood) the update.bsa appearing in the list confused some people - a lot - so I hid it. the update bsa is loaded by the engine hard-coded so it's a completely separate thing. 

So yes, my second suggestion in my above post is a bit of a hack for your number 5, but I don't see how it's a "mess" because after relocating the UP BSAs to the real /Data directory, MO allowed me to get the Official & UP BSAs in the correct load order. That's what were trying to do on this one point, correct?

It's another thing users have to know about. Something they have to do manually to get a correctly working game. These things never work out for all users (actually they usually don't work out for the majority of users), we will still have users with a broken game and they will still go to Arthmoor or me and ask why their game is broken and Arthmoor will continue to tell people MO is at fault.It allows users to fix the problem but it isn't fixed by default. Most users will probably install the unofficial patches so the installation is broken by default, this is what we have to get away from. If the user does nothing apart from installing a couple of mods and run loot the installation needs to be ok. MO may then offer features to break it again if people feel like it but that has to be a conscious decision on their part. 

Otherwise, the thing that is most worrisome about throwing out BSA management is how MO would then present conflicts. Would it still properly show conflicts for the plugin-loaded BSA assets with regards to the loose files that load afterwards?

I could still show the conflicts but it would be rather pointless because loot/boss would then be responsible for putting bsas into the right order and loose files would always overwrite bsas so you really wouldn't have to worry about conflicts with bsas (nor would you be able to do anything about it)
  • 0
Posted (edited)

So - is there any way to "trick" MO into thinking the UPs - or even just their BSAs - are located in /data rather then separately, so that the UP BSA priority order can be managed among the official DLCs BSAs?

Symbolic links. Edited by fireundubh
  • 0
Posted (edited)

My game is installed on my SSD, but STEAM still thinks it is on my larger conventional drive in the default location. Works flawlessly.

 

Posted Image

Edited by Kuldebar
  • 0
Posted (edited)

Here's what symbolic links look like for Dawnguard in the MO mods folder. Note the file sizes.

 

Posted Image

 

These links point to Dawnguard.bsa and Dawnguard.esm in the Skyrim Data directory.

 

Here's what the UDGP conflicts tab looks like.

 

Posted Image

 

If this fixes Kuldebar's issue, MO could automate the linking process.

 

C:>mklinkCreates a symbolic link.MKLINK [[/D] | [/H] | [/J]] Link Target        /D      Creates a directory symbolic link.  Default is a file                symbolic link.        /H      Creates a hard link instead of a symbolic link.        /J      Creates a Directory Junction.        Link    specifies the new symbolic link name.        Target  specifies the path (relative or absolute) that the new link                refers to.
Symbolic links are absolute or relative links to files, directories, or junctions on a single volume. They require an elevated process to create.

 

Hard links are the same as symbolic links except that they will always point to the target, even if the target is moved, on the same volume.

 

Junctions can link directories on different volumes, but they're mostly the same as hard links.

 

SSD users work with hard links and junctions to optimize performance and extend the drive life cycle.

Edited by fireundubh
  • +1 2
  • 0
Posted

I won't pretend I understand all the details being discussed. But, once I stopped extracting the Unofficial Patch BSA's the issue was resolved for me. (I no longer had to manually hide the two facegen files)

  • 0
Posted (edited)

Leaves us with the solutions

2. remove MOs BSA management

3. plugin to import dlcs as MO mods

 

...

 

3 goes against the paradigm that MO leaves your data directory alone.

 

"leaving the data directory alone" isn't only about keeping the game in a vanilla state, I want MO to play nice with other mod managers. But if we remove official dlcs from the data directory that effectively "breaks" the game if you run it without MO and should bethesda decide to update dlcs your imported, now-outdated variants overwrite the updated dlcs.

The DLCs are, as someone else mentioned, effectively mods. But they are steam-managed mods, not MO-managed.

But does MO have to touch the Data directory in order to implement 3?

 

Imagine the following:

[*]New user installs MO, on top of completely vanilla Skyrim + DLC installation

[*]When he loads, he sees the Mod list, but it is not empty as now.  Instead, MO has detected that he has a) Skyrim b) Hearthfire c) Dawnguard  (let's say this guy does not have DB), and so it has given him a mod list with the following entries:

[*]Skyrim

[*]Hearthfire

[*]Dawnguard

[*]These mods would be formatted slightly differently to indicate they are vanilla/DLC content, e.g. perhaps they are in bold.

[*]The Skyrim 'mod' would have a hardcoded priority = 0, and no activate/deactivate checkbox

[*]Hearthfire and Dawnguard have normal controls - activate checkbox, and drag/drop priority changing.

[*]Fields such as Nexus ID, rating, Endorse etc would be hardcoded to N/A or similarly disabled.

[*]What has happened behind the scenes:

[*]MO has detected the presence of Skyrim, Hearthfires and Dawnguard.  It has done this probably just with filename matching in the Data directory.

[*]It has created three default, virtual mods, which contain references to their assets.  

[*]These could be entirely 'virtual' references - i.e. no physical filesystem connection at all - or they could be implemented with filesystem soft/hard/junction links, as other posters have detailed.

[*]Either way, MO has some new code that detects certain, named files in the data directory, and has converted these into mod entries.

[*]The user now installs other mods, including the unofficial patches, as normal.

[*]He will be told by STEP guides and other collected wisdom, that in MO he should put each Unofficial Patch mod entry directly after its corresponding vanilla 'mod'.

[*]So once this user has the unofficial patches installed, his mod list with priorities would be:

[*]0 | Skyrim

1 | Unofficial Skyrim Patch

2 | Hearthfire

3 | Unofficial Hearthfire Patch

4 | Dawnguard

5 | Unofficial Dawnguard Patch

6 | .. other mods

So MO would have code to configure itself in the way that many (advanced) users are already doing by hand - treating their vanilla/DLC Data assets as mods, and allowing the DLCs to be re-prioritised.  

 

It would do that without making any physical changes to Data.  It would achieve this either in a purely internal way, or by virtue of automatically creating filesystem soft links from Data to the appropriate Skyrim/DLC mod directory within MO's normal filesystem structure.   So there would now be standard mod folders - "Mod OrganizermodsSkyrim" folder, "Mod OrganizermodsDawnguard", etc - created automatically on startup, and these could contain filesystem links to the appropriate files in Data, or MO could just handle that internally, knowing that the Skyrim mod always contains Skyrim.esm and named Skyrim*.bsa files, and populating the virtual directory and the Conflicts tab as such, without any actual filesystem reference.

 

Then MO would handle its virtual Data, and game loading, exactly as it does now - with no conflicts, because it's treating all assets as mods, with no 'unmanaged' BSAs at all.  Perhaps it would also be necessary to remove the checkboxes against the DLC BSAs in the Archive tab, such that there can't be a situation where the user has ticked, say, the Dawnguard DLC - and so has the ESP - but has for some reason unticked the Dawnguard.bsa file, which would cause that BSA to be loaded regardless because of the esp?  

 

This seems to me to maintain MO's data integrity paradigm.  It does not require removing the existing BSA management feature - which worries me (admittedly more out of principle of not losing potential features, and ignorance of the full ramifications, rather than a firm understanding of any way it would hurt me as a user who extracts 100% of BSAs, including, soon, vanilla/DLC BSAs).

 

In fact I would say it extends one of MO's core paradigms - the ability to have full control and management over a complex mod installation.  It extends it because now all DLCs are manageable just like, and as easily as mods.  If a user wants to start a game without Dawnguard running, he can do so with a single uncheck, in an obvious and logical place; exactly like how he'd disable any mod.  DLCs can now be prioritised however one wants, like mods (though users should be advised that normally, only Unofficial patches should go between vanilla/DLC entries) and can easily have their conflicts/overwrites viewed, just like any other mod.  All within the existing, familiar and effective infrastructure.

 

Have I missed anything important that would break this?   It does seem to me that if the ordering works fine when an advanced user manually makes mods out of the appropriate files, it should be perfectly possible for MO to automate that process - especially if combined with filesystem links, so that all MO's existing mod/file-management code still works unchanged.

 

 

PS.  Tannin, I just wanted to say thank you for what is I believe the most elegant, sophisticated, and simply genius solution for mod management I have seen, or can imagine.  Earlier today I posted a much longer gushing endorsement to MO's main Nexus thread, but I wanted to mention it again here as I was replying to your post, and in case you don't check that Nexus thread as regularly.  

 

And also because you've needed to post here to defend MO (not from people in this thread, thankfully.)  That completely baffles me.  MO and its virtualised system is simply superb, and I don't understand why everyone doesn't use it - let alone why anyone would use minor issues like this one against it, rather than submit problem reports/work together to get them resolved as quickly as possible.

 

I hope you're justifiably proud of your creation - it's fantastic!

Edited by TheBloke
  • 0
Posted

I just learned that Wyrmstooth will be implemented using the false-esm flag and that this phenomenon was implemented in Fallout series modding practices as standard procedure. I also learned the, NO, the USPs will not be changing anything, so it will be a matter for mod management utilities to deal with. Apparently the decision to implement the false-esm methodology was an open debate lasting between August and October, 2013, so if we weren't ready for it, it is our own fault I guess.

  • The discussion about symbolic links seems elegant and totally feasible, so what about that?
  • What about 'merging' the USPs and any other "vanilla-status" mods into /Data/ using symbolic links??
  • What about doing it without symbolic links? Why is there any problem with Keith's suggestion for his option #5??

STEP will be recommending whatever is the simplest solution for installing STEP, and I am liking "option 5" better and better, so if we had help to accomplish this or any of these tasks from MO, that would be pretty nifty.

  • 0
Posted

I could still show the conflicts but it would be rather pointless because loot/boss would then be responsible for putting bsas into the right order and loose files would always overwrite bsas so you really wouldn't have to worry about conflicts with bsas (nor would you be able to do anything about it)

 

I just want to add my two cents against this option. I used NMM before switching to MO and one of the main things I hated about Skyrim modding was the whole BSA vs Registered BSA vs Loose File overwrite scheme. I understand the desire to adhere to Bethesda standards because they're "official," but when those standards are stupid, I see no reason why you shouldn't try to improve them. MO is a massive improvement, allowing me to completely ignore that priority scheme and just order my mods as I see them.

 

It's the USKP team that has thrown a monkey wrench into all of this, not you. They could solve this themselves by doing what they probably should have been doing all along, which is make different versions of the patches for different DLC setups. Unfortunately, there's just so many bugs (just look at the recent USKP changelog), that the amount of extra work required is too much to expect. I imagine if it were within their capabilities to do, and they thought it wouldn't introduce more problems, then the USKP team would certainly make different versions of the patches.

 

In any case, I think keithinhanoi's solution is the best one, which would be improved by a more automated method using MO. Since the Unofficial Patches have been forced to elevate themselves to vanilla level, they should be treated like vanilla assets. For now, users should move the Unofficial Patch BSAs into the Data folder. MO's archive tab shows that they load correctly. An automated method where MO recognizes the Unofficial Patches and automatically treats them as vanilla assets would be ideal. Nothing else in MO would have to change.

  • +1 1
  • 0
Posted

But does MO have to touch the Data directory in order to implement 3?

 

Imagine the following:

    [*]New user installs MO, on top of completely vanilla Skyrim + DLC installation

    [*]When he loads, he sees the Mod list, but it is not empty as now.  Instead, MO has detected that he has a) Skyrim b) Hearthfire c) Dawnguard  (let's say this guy does not have DB), and so it has given him a mod list with the following entries:

      [*]Skyrim

      [*]Hearthfire

      [*]Dawnguard

    [*]These mods would be formatted slightly differently to indicate they are vanilla/DLC content, e.g. perhaps they are in bold.

      [*]The Skyrim 'mod' would have a hardcoded priority = 0, and no activate/deactivate checkbox

      [*]Hearthfire and Dawnguard have normal controls - activate checkbox, and drag/drop priority changing.

      [*]Fields such as Nexus ID, rating, Endorse etc would be hardcoded to N/A or similarly disabled.

    [*]What has happened behind the scenes:

      [*]MO has detected the presence of Skyrim, Hearthfires and Dawnguard.  It has done this probably just with filename matching in the Data directory.

      [*]It has created three default, virtual mods, which contain references to their assets.  

      [*]These could be entirely 'virtual' references - i.e. no physical filesystem connection at all - or they could be implemented with filesystem soft/hard/junction links, as other posters have detailed.

    [*]Either way, MO has some new code that detects certain, named files in the data directory, and has converted these into mod entries.

    [*]The user now installs other mods, including the unofficial patches, as normal.

    [*]He will be told by STEP guides and other collected wisdom, that in MO he should put each Unofficial Patch mod entry directly after its corresponding vanilla 'mod'.

    [*]So once this user has the unofficial patches installed, his mod list with priorities would be:

      [*]0 | Skyrim

      1 | Unofficial Skyrim Patch

      2 | Hearthfire

      3 | Unofficial Hearthfire Patch

      4 | Dawnguard

      5 | Unofficial Dawnguard Patch

      6 | .. other mods

So MO would have code to configure itself in the way that many (advanced) users are already doing by hand - treating their vanilla/DLC Data assets as mods, and allowing the DLCs to be re-prioritised.  

 

It would do that without making any physical changes to Data.  It would achieve this either in a purely internal way, or by virtue of automatically creating filesystem soft links from Data to the appropriate Skyrim/DLC mod directory within MO's normal filesystem structure.   So there would now be standard mod folders - "Mod OrganizermodsSkyrim" folder, "Mod OrganizermodsDawnguard", etc - created automatically on startup, and these could contain filesystem links to the appropriate files in Data, or MO could just handle that internally, knowing that the Skyrim mod always contains Skyrim.esm and named Skyrim*.bsa files, and populating the virtual directory and the Conflicts tab as such, without any actual filesystem reference.

 

Then MO would handle its virtual Data, and game loading, exactly as it does now - with no conflicts, because it's treating all assets as mods, with no 'unmanaged' BSAs at all.  Perhaps it would also be necessary to remove the checkboxes against the DLC BSAs in the Archive tab, such that there can't be a situation where the user has ticked, say, the Dawnguard DLC - and so has the ESP - but has for some reason unticked the Dawnguard.bsa file, which would cause that BSA to be loaded regardless because of the esp?  

 

This seems to me to maintain MO's data integrity paradigm.  It does not require removing the existing BSA management feature - which worries me (admittedly more out of principle of not losing potential features, and ignorance of the full ramifications, rather than a firm understanding of any way it would hurt me as a user who extracts 100% of BSAs, including, soon, vanilla/DLC BSAs).

 

In fact I would say it extends one of MO's core paradigms - the ability to have full control and management over a complex mod installation.  It extends it because now all DLCs are manageable just like, and as easily as mods.  If a user wants to start a game without Dawnguard running, he can do so with a single uncheck, in an obvious and logical place; exactly like how he'd disable any mod.  DLCs can now be prioritised however one wants, like mods (though users should be advised that normally, only Unofficial patches should go between vanilla/DLC entries) and can easily have their conflicts/overwrites viewed, just like any other mod.  All within the existing, familiar and effective infrastructure.

 

Have I missed anything important that would break this?   It does seem to me that if the ordering works fine when an advanced user manually makes mods out of the appropriate files, it should be perfectly possible for MO to automate that process - especially if combined with filesystem links, so that all MO's existing mod/file-management code still works unchanged.

 

 

PS.  Tannin, I just wanted to say thank you for what is I believe the most elegant, sophisticated, and simply genius solution for mod management I have seen, or can imagine.  Earlier today I posted a much longer gushing endorsement to MO's main Nexus thread, but I wanted to mention it again here as I was replying to your post, and in case you don't check that Nexus thread as regularly.  

 

And also because you've needed to post here to defend MO (not from people in this thread, thankfully.)  That completely baffles me.  MO and its virtualised system is simply superb, and I don't understand why everyone doesn't use it - let alone why anyone would use minor issues like this one against it, rather than submit problem reports/work together to get them resolved as quickly as possible.

 

I hope you're justifiably proud of your creation - it's fantastic!

 

I really like the suggested option to add official DLC as mods, that seems nifty if possible and leaves it mostly seamless to users.

  • 0
Posted

Either process:

 

A) Add DLCs as mods

 

or

 

B) Add USPs to data

 

...if automated via plugin, are both viable options that are identical in the result. In A, the DLCs are taken from data and thus alters the data folder. In B, the USPs are added to data and thus alters the data folder. Both fix the issue. Both, if automated, requires no user intervention. Both have the potential to confuse the user as to "why" this is happening (the STEP guide would explain the "why" but what about users that do not use the STEP guide?)

 

I really see these options being different but yet equal solutions with the same result regardless of which is used.

  • 0
Posted

Keith's option #5 with fireundubh's symbolic links idea, TheBloke's merging of them both and Neo's and my own very wise backing of this pretty much validates the approach, no?

 

Seriously though, the use of symbolic links to 'merge' /Data/ (or elements within) into the MO mod prioritization as 'mods' or whatever just jives with the way MO operates ... virtualization and crafty manipulation to simplify mechanics for the user.

 

It seems perfect, so anxious to see Tannin debunk :P

  • 0
Posted (edited)

Here's a simple Windows batch file (.bat) that automates the linking process.

 

@echo offREM Path to Mod Organizer modsset MO_MODS_DIR="C:GamesModOrganizermods"REM Name the subdirectories to be created in the mods directoryset DLC1_DIR_NAME="DLC1 Dawnguard"set DLC2_DIR_NAME="DLC2 Hearthfire"set DLC3_DIR_NAME="DLC3 Dragonborn"REM Find Skyrim installation path with registry keyset SKYRIM_REGKEY="HKLMSOFTWAREWow6432Nodebethesda softworksskyrim"set SKYRIM_REGVAL="installed path"set SKYRIM_DIR=	for /f "tokens=3,*" %%a in ('reg query %SKYRIM_REGKEY% /v %SKYRIM_REGVAL% ^| findstr %SKYRIM_REGVAL%') do (		set SKYRIM_DIR=%%b	)REM Change path to modscd %MO_MODS_DIR%REM Create the subdirectoriesmkdir %DLC1_DIR_NAME%mkdir %DLC2_DIR_NAME%mkdir %DLC3_DIR_NAME%REM Create the symbolic linksmklink %DLC1_DIR_NAME%Dawnguard.esm %SKYRIM_DIR%DataDawnguard.esmmklink %DLC1_DIR_NAME%Dawnguard.bsa %SKYRIM_DIR%DataDawnguard.bsamklink %DLC2_DIR_NAME%HearthFires.esm %SKYRIM_DIR%DataHearthFires.esmmklink %DLC2_DIR_NAME%HearthFires.bsa %SKYRIM_DIR%DataHearthFires.bsamklink %DLC3_DIR_NAME%Dragonborn.esm %SKYRIM_DIR%DataDragonborn.esmmklink %DLC3_DIR_NAME%Dragonborn.bsa %SKYRIM_DIR%DataDragonborn.bsaREM Finishecho Done!
Edited by fireundubh
  • +1 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.