z929669

Indeed: Without this logic, I would still agree that Beth messed up and did not intend to remove the pot. True, this is a presumption, but I can think of no rationale why they would exclude it. However, the observation that HF 'bugs' out the pot seems like pretty strong reasoning that it was a mistake ...

It may be just me, but I don't see Tannin's proposed method as strictly tying asset prioritization (mod pane at left) to plugin prioritization (plugin tab in right pane). maybe this is basically true with regard to mods that have plugins, but most mods do not have plugins. For those that DO have plugins, we can decouple and retain current functionality (except without the confusing mechanics of the current Archive Tab functionality) ... Am I missing something fundamental though? It would seem to me that Tannin's latest proposal would definitely make life simplest for the novice modder not following STEP or any other guide. It seems like a 'safe' approach to those that know little. Sure, LOOT or even BOSS should not be totally 'trusted' (the latter less so than the former), and I actually mentioned this a couple posts up as one potential problem; however, LOOT is under active dev and refinement, and we can expect that errors will be corrected (especially if our community gets better at submitting bug reports and change requests to BOTH USP and LOOT teams). For any inconsistencies in how we do things around here, we have classic MO functionality and a left-right pane decoupler. (oh and with WB and any other mod manager, installation prioritization is independent of plugin prioritization only with respect to loose files. BSA prioritization is still coupled to plugin priority. It's just that loose assets always win against plugin assets). Indeed. This or instruct them to copy USPs into /Data/ both seem to be the simplest solutions to the problem ... but Tannin has not cozied up to the idea and seems more intent on making fundamental changes ... so ... whatever he wants works for me as long as it works!

@Tech I think Tannin's new proposal would make MO behave more like other mod managers. There is a definitive install order (loose asset prioritization) and a plugin prioritization order, which controls associated BSA assets. With regard to textures, I see what you mean, and we can decouple those from the plugin (or extract only the textures maybe). With regard to most other assets (scripts come to mind), it would be optimal to let LOOT manage what we might otherwise break using custom asset prioritization. We should still be able to guide the user through a logistical "installation" order that makes intuitive sense (i.e., STEP Sections). As long as we still have BSA extraction and the plugin-decoupling functionality (which we may not even need .... tough to say ATM), I think we should be good. In short, as long as MO can proxy the behavior of Wrye Bash, we are good.

@Tannin That works for me (for STEP) as long as the auto-sort can be disabled and BSA extraction is still toggleable. LOOT/BOSS should never be given total control without opportunity to decouple user-specified mods. This could mess with some of our logistical mod installation order, so it would best be something that could be disabled at the mod level if at all possible (i.e., not ideal to have the all or none toggle for this behavior). I assume all other non-disputed functionality would remain (e.g., conflict resolution of all assets, including BSA assets)? Seems like a good solution and keeps the Data directory clean as always. It also, by default, removes confusion of the degrees of freedom conferred by independent asset and load priority (it can get confusing for those that know about them!). EDIT: Tannin, just saw you last post ... isn't it simpler to just think of managed BSA assets as loose files coupled to the Mod install order just as are loose files? I got confused reading that!

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

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.

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)?

I just learned that TESEdit method is the only viable one, because Wrye Bash does not support "ONAM subrecords in the TES4 file header" As to the former: Yes, I have confirmed that if a BSA is checked, it will overwrite the plugin-loaded BSA assets (confirmed also by umpacking the BSA). Uncheck and it will not (see my prev post about the details of the facegeom conflicts with the DG vampires). I agree that all issues we know of are associated with the USP false-esm flag change; however, this is theoretically an issue with any mods using BSAs that interact with other mods using BSAs. There may even be other use cases and we just don't know about them ... but this is potentially an issue with any mod interaction and not necessarily and artifact of MO BSA management practices. This was addressed in detail by Tannin and DoubleYou on this thread, and I updated the OP with the consensus info. Agree ... I wish someone on the staff contributing to this thread would help me to keep the OP updated so that all relevant info is consolidated!

Someone reported a broken link in the memory section of the guide: https://wiki.step-project.com/Recommended_ENB_Profiles#Memory The link should be pointing to a tool: http://www.iparadigm.org/pages/pnenb/ENBoost.htmlto aid in config, but that tool is likely outdated as is other content in the ENB Guide at this point.

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)

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

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

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.

I explained in detail over in the BSA ramifications thread ... I believe that you are unpacking your official DLC, so you would not have the issue. Just pretend you know nothing and install all mods with BSA extraction (except the DLC, because they are in the data directory and you just don't care about that stuff) @Kludebar You can reset the auto-BSA-extraction feature via the GUI by using the method described in the MO Guide FAQs, which I have also placed within the OP of the BSA ramifications thread.

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.

@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.

I am sure that most mods do not follow standards, but that is a problem. The USP team basically sets the standards, since they worked directly with Bethesda point person(s) to establish modding standards for Skyrim (which never really was done for Oblivion and Morrowind). Like I said, writing up an installer is a PITA, so I'll take what I can get.

I see your points Tech, but I would mention that we are currently talking about sticking more to standards and best practice, and that multilingual mod "best practice" is to install all applicable languages for simpler user switching and simplified installation. Not that big a deal if you are already done though, but you are probably deviating to 'Tech' standards ;)

@Aiyen I see now that I did not consider that you unpacked all BSAs, including DLC? Please confirm, because this would explain it. If that is the case, then I would argue that we should NOT be unpacking BSAs except where it makes sense for conflict resolution ... and NEVER to unpack the base game BSAs, official DLCs or the USP BSAs. Even Tannin has recommended this I believe (an he goes further in stating that BSA extraction should not be default MO behavior). My point is that as a general practice applicable to all user systems and all mod management utilities (and even manual installation), we should be recommending methods (in the STEP guide) that generally apply and not just to MO users (MO users can handle things in a number of viable ways, including yours and my own variant method, which differs). We may not be doing so exactly ATM, but we are learning a few things right now. STEP should be recommending generalized and standard "best practice" wherever possible for purposes of compatibility and applicability. We are nailing down some of these best practices here in this thread, and my point is that your methods, while viable and efficient for you, are not "best practice." I am still trying to figure that out for myself ;) oh, and I agree with GSDfan that the Overwrite folder should not be used to house mods, which is clearly not MO best practice (I would never use it that way, simply because I view that location as highly volatile and a source for 'snapshots' of things that I want to create 'mods' from).

@Kludebar NP, I think everything is 'fine' on this thread, so no worries. People can get a little prickly and heated when something they are passionate about is being challenged. @Wolverine Thanks, and great points! Also, I intended the OP to be the condensation of this threads contents, so all moderators and site staff: PLEASE help me to keep it updated with relevant facts. I am writing updates in green text, and using strike-through to eliminate falsehood ;) Really ... whatever you guys think is important, and you don't have to agree with any of my own opinions! The thread should contain relevant facts that we (and Tannin) can reference. @Aiyen and SRB and Kelmych I think that proposed solutions about current workaround and pros/cons of those workarounds should go in there, so have at it if you please (but do look at my argument first, just in case it makes sense or is worth considering).

RE multilingual mods: Agree that for a mod to be multilingual, it needs to have all language strings present. This is standard behavior and so mod version A plugin should include all mod version A string files with its installation. The beauty of a multilingual mod is that it works for the supported languages out of the box. The reason we did this is to cut down on the number of plugins to manage and to make language support more convenient for the user Do yourself (and the modding community at large) a favor Tech, and avoid the piecemeal installation strategy ... I will be working on the wizard to follow that approach ... someday. Not looking forward to playing with that beast again

You and Neo are using a valid solution it would appear, but ONLY if you are also including the BSA in Overwrite, no? From previous discussion on this thread and input from DoubleYou and Tannin, I thought that the DLC BSA assets were never treated as loose files (check or unchecked ... unless unpacked), and so would thus be overridden by USkP when both are present, unless USkP BSA is UNchecked and its plugin remains checked (then that forces USkP load by BOSS/LOOT priority, which is the only behavior allowed to official DLC). ... so either I have it wrong (in which case, correct behavior needs to be re-explained by Tannin et al, or I need to stop smoking crack), or you (and Neo) are mistaken Applying MO-specific workarounds seems less ideal to me though if we want broader acceptance of MO as a supported alternative to other mod managers. The USP team is (has been for some time now) speaking out against MO (and STEP) for not adhering to a standard that applies to other mod management utilities and more importantly: a standard that is explicitly considered in the development of the USPs and possibly other mods that conform to and are developed around Bethsoft standards. It IS a valid argument. I just think that it is worthy that Tannin consider implementing some changes that, by default, bring MO into full alignment with the Bethsoft standards, so that out of the box, mod installation instructions pertain to MO users as they do for all others. I am not saying to remove all of the advance functionality that MO has. I am only suggesting that it be optional behavior and not default behavior. Tannin can either agree or disagree, but it would be great to hear his arguments for or against that so that STEP can present messaging consistent with his own on this subject. As I said on the 2.2.9 staff dev thread, STEP provision of official content has some issues relating to Steam auto-update behavior and/or, addition of custom plugin content loaders, and/or unpacking of BSAs ... or basically treatment by MO users that differs from treatment by users of other mod managers. Just head over there and comment, because nobody has yet responded to these (I think) valid considerations that need solutions. By virtue of being in /Data/, the DLC ARE treated "specially." The statement is pure and simple fact. I agree that copying all assets in /Data/ as MO mods would resolve all Prioritization compat issues for MO users I assume you mean Tannin? FYI, this is a civil and valid thread that is broaching a valid topic that deserves consideration on the broader context. The issue is not going away. We are seeking to finally bring it out front for discussion so that --at the very least-- we can have an official position on the topic and address to the broader modding community by consensus. Tannin can do what he wants, but I think it is fallacy to avoid a subject so as not to "rock the boat". Boats need rocking, and I believe Tannin has his own opinion, and I am eager to hear it. Whatever he decides to do, it will not detract from STEP's use of MO as the default mod management utility, because it is the best and most extensible mod manager available. We just want to acknowledge the valid issue that MO subverts Bethsoft standards and does not appear to presently have a 'mode' that conforms to them. So many people are reading this thread and learning things for the first time (many of whom have been using MO and modding for quite a long time!)

I did not say anything about putting 'crap' in /Data/. I only said that the DLC assets could be treated as exceptions and excluded by MO from the rest of /Data/ such that the DLC BSAs could be decoupled from plugin prioritization like all of the other plugin-loaded BSAs. If my logic is correct, this is a more elegant solution than the proposed workarounds and makes MO methods fully compatible with Bethsoft standards.

Obviously, we are discussing a bunch of viable workarounds, but all workarounds nonetheless, so not ideal. The best solution is to request that Tannin allow DLC under /Data/ to behave as any other 'mod'. This resolves all of the issues at the source, alleviating the inconsistency whereby Official DLC are treated 'specially'. Remove this special treatment and all of the installation instructions that come with all of the mods we install will hold true ... that is key. We don't want 'special' instructions that differ for MO users. All users should be able to follow any mods instructions and trust that those instructions apply. There are probably a couple of different ways that Tannin could do this (if he so chooses), but it likely includes some alteration of Archive Tab behavior and/or exceptions applied to DLCs and USPs. Regardless, there could be many edge cases caused by uniqueness of MO prioritization intelligence that we are still not aware of. Modding in Skyrim is a complex cascade of conflict resolution that mods are built around, and obviously some mod builders are developing with the expectation that standards are not being circumvented. There is something to be said for following standards by default. The STEP team will be revising some things and doing some testing before 2.2.9 release to make changes necessary to prevent variations among users installing STEP with MO versus other mod management utilities.

If you unpack both DG DLC BSA as well as USkP BSA and prioritize both using MO (DG highest priority), then this would fix the issue. USkP could be either Packed or unpacked, but DG BSA must me unpacked. That is the key point. ... and BSAs are not always compressed. (They can be like a TAR archive).