z929669

Yes, that fixed the issue for me. Otherwise, you could also unpack the DG BSA as long as you place it after the USkP in the Mod priority (this way we are effectively moving prioritization with respect to the DLC to the Mod priority rather than the Plugin priority). That would be a good confirmation in fact.

Yes, and you can blame Bethesda for that. We are all modding around it, and it is MUCH better now than it was back in Morrowind or Oblivion days (sorry I never got into Fallout series). A standard is a standard, and MO has a way around it. I am pretty happy about that, but in the meantime, let's give credit where credit is due and acknowledge facts apart from emotions. Arthmoor was right, even if he did not know the specifics. Now we know the specifics, and MO (and its users) can benefit from that

The key point is that the unpacked and the packed BSA behave the same in MO (if it is also checked in Archives Tab); however, the DLC BSAs behave differently in MO (they are in /Data/ which Tannin and DY said is treated specially ... see OP). Under Bethsoft standards, all plugin-loaded BSAs are treated equally always. Unpacked USkP overrides DB assets in MO, but packed BSA does not, since it will follow the plugin load order (remember, DG DLC plugin loads after USkP, so it should technically override, AFAIK)... Arthmoor may not always be that helpful or even diplomatic, but he knows what he is talking about in my XP, and I would not disagree with him outside of a PM unless I was the expert in the subject matter ... anyway, water under the bridge. We all make mistakes (jeez, I had the same problem as you in my own setup!)

@Kelmych Yeah, I get it, but was pointing out the need to be semantically explicit in our postings. SRB's post could be taken a couple of ways, and it was confusing how he worded it. On another note and related to SRBs post just before this one, there is a significant issue with how MO and BSA extraction can subvert basic fixes provided by the USPs, which means that this can and likely IS happening elsewhere. This needs to be addressed and acknowledged by all that use MO. It is not really an inherent problem, but it is a reality that would not otherwise exist were it not for MO's ability to extract BSAs AND to treat DLC BSAs differently than others. I have verified the issue, and Kludebar should chime in at this point to confirm so that we can amend the misinformation floating around. EDIT: posts between Kludebar and me were moved to the thread linked above so as not to detract from the main agenda here.

Confirmed. I just loaded up my game that had USkP BSA unpacked and had the same issue with that NPC (coc halfmoonmill). I reinstalled the USkp with BSA intact, and tada! problem resolved. Arthmoor et al indeed make a valid pint, and I would point Tannin and others to this incident as an example of what can happen when MO deviates from standards. This can be avoided in two ways: Don't unpack BSAs without understanding the ramifications first ... and fixing problems yourself Allow the DLC the same prioritization as other plugins (i.e., just because they reside in the data folder does not mean they should be treated differently than other plugin-loaded BSAs ... the DLC should be treated just like the other plugin-loaded BSAs.Without conceiving every other possible use case, it is difficult to say what unique variations MO prioritization and BSA extraction can cause, so it is best for MO to stick to the Bethesda standards as default but allow users to deviate optionally.

Well, if you download the BAIN version and look at wizard.txt, it is very straingt forward. Simpler than the FOMOD even I think. No big deal, if you guys don't want to do it, I will eventually get there. Just as long as the FOMOD allows all install options and has some easy presets for STEP defaults, no big deal. Anyway, attached is the corrected update files with the German strings corrected. Please verify that I did not muck anything up. Soul Gems Differ - UPDATE v2.7z

OK, I am finished. @SRB Could you give it all a look to verify? This is my first foray into any kind of plugin and language manipulation. Once you sign off, then Tech can use these assets in place of all other plugins. The way this works is that the user installs ONE plugin only, depending on if Requiem is used and the sorting/weight settings desired. NOTE: I want to maintain WB compat, so we need to keep the BAIN format I think. If anyone wants to update the BAIN Wizard I wrote, I won't stop them!

@Kelmych NICE, you have resolved the issue I think. If one does not have the DLC, then one will get the USkP changes, regardless of using MO or not. However, if one DOES have the DLC, then the USkP verion is incorrect (it must be different than the DG fix), and it persists for MO users following the MO protocol, and you get the issue. Hiding the USkP assets allows the DLC content to shine through, right!? I am anxious for Kludebar to comment at this point. I don't have time to verify, and I think that as the issue invoker, he needs to rule out this seeming probability. Very nice. I have been looking for a good example to corroborate what Arthmoor et al have been arguing and validate the concern that there are use cases where the elegance of MO standards could break things unless we either inform the user or add in some contingencies. EDIT: I have the same issue regarding prioritization, so if someone can direct me where I can find the NPC in question, I will check.

Arthmoor has told me also that NPC tint masks get mysteriously altered by the CK upon save (same for object bounds in some cases). I always assume taht the facegen data was also written by the CK. So the files could still be present ... no? (I am honestly not sure). I am reading that the USkP contains these references (and files) intentionally to fix vanilla for those not running the DLC. For those running the DLC, the DLC contains (I assume) the analog to the USkP fix. Therefore, I expect the files to be present, but they whould be from the USkP if not running the DLC or from the DLC if running it. What exactly is the install order of your mods in the left pane and the plugin load order on the right? Are BSAs checked or are they extracted? Have you played around with checking or unchecking the BSAs or forcing MO to prioritize according to the Bethesda standards to eliminate the possibility that MO is the issue?

I will comment about the facegen issue on that thread you linked. (let's keep that there for now, unless it proves to be related to this thread) RE BSAs being good or bad: I have not like them at all in the past, because I modded Oblivion and Skyrim without MO once. I want full control and ability to see conflicts, regardless of BSA. (Windows search functionality never really mattered much to me though). Consequently, I always hated BSAs and the entire practice. It only made me feel like mod authors were shoving their meds down my throat without letting me look at the active ingredients first. With MO, I no longer really find any reason to dislike BSAs, they are actually looking pretty good now from a management and a performance standpoint, especially for HDD users. Even without MO, I see the advantages that apply to Skyrim where they never applied to Oblivion (since now the Bethesda BSA standard has been fixed). Regardless, BSA extraction and other higher functionality should remain in MO, IMO, and I do not subscribe to the idea of black-boxing information and access to useful utilities based on the reasoning that "I don't need to know". Tannin's software, Tannin's call ... users will always have choice regardless. If BSA extraction were to be removed, then anyone could use MO extensibility to rebuild the lost functionality as an MO add-on. Same goes for any feature that he does not want to be responsible for maintaining (as long as he maintains his license as it currently stands ... I think). The main point is that we understand how MO functions EXACTLY. Otherwise, we can't develop STEP responsibly. I don't care (much) about the code, but I do care about all of the functionality that the code manifests and the implications/ramifications.

I wish I could get the strings to work under TESEdit, but it just does not work (for this case) using several strategies ... and if it did work, it would be convoluted. I think it has to do with the item IDs somehow. TESEdit assigns integers 1-16 to the base plugin (weight and sorting) ... I can only see these IDs in Skyrim Localizer BTW. The strings for this are new and unique, so they are not in the vanilla English strings. Skyrim Localizer does not add any IDs (ID=0 for all) unless you tell it to do so (which I have learned is a requirement for this particular job), and the IDs it assigns to each string are 6-digit integers that are consistent for each gem of each plugin. This seems also to be the only alternative to TESEdit that will actually create the localized version of the plugin (much simpler and faster to use than TESEdit). I responded to your questin in that other thread.

We are discussing this topic at length in the pinned MO support thread

WOW ... we are getting somewhere with this thread now! Don't you mean 'higher' order? This statement is confusing to me (I am easily confused I guess :P ) For the record: The 'best' mod/load order prioritization is that which results in the fewest number of conflicts needed to achieve the desired result with minimal asset-level manipulation (i.e., hiding/deleting files, extracting BSAs, repackaging archives, etc.). We need to say something about scenarios when extracting the contents of a BSA is valid and beneficial: When assets need to be modified and tested (mod creators only) When assets need to be exposed to Windows file system for search and to expose file-level metadata (mod creators only) When a BSA has lots of assets that are wanted, but has others that are not wanted but exist in lower-prioritized mods that we want to be manifest, and re-prioritizing the lower-priority mods might add even more complexity to the conflict resolution. This enables the MO 'hide asset' functionality otherwise not possible on assets within the BSA. Any others?? This is wonderful ... thank you THANK YOU! (isn't DY a nice person? no flack at all, just information all the time ) I will attempt to merge this and other info into the OP, but you should also look carefully at the OP and make edits where necessary. FYI, I recently learned that Wrye Bash indeed does allow conflict resolution to include BSA contents (I believe it is a toggleble feature though and that it is not very efficient). Ask the WB devs for more info. I am a bit skeptical that this is an issue with the USkP though and not the result of the MO-flavored asset prioritization interaction with USkP and another mod(s). If you can provide detail as to exactly how to reproduce this, I might be convinced. Isn't it true that this could be cause by a higher priority body mod or EOO or any number of other things? I have heard about this specific issue and there has been no definitive explanation as to why this is or is not an issue with MO prioritization or the USkP or both. As Tannin and Aiyen allude, the consensus is that BSA seek time (with or without compression ... not all BSAs are compressed) is negligible and that loose-asset read time is more significant (on HDDs). Also, factor in that HDD fragmentation is a very real issue with a significant effect size. Awesome info ... if this is in the MO guide, I admit that I missed it! This is a fantastic idea, and I think that we need to do exactly this: the novice modder - Core Guide (relatively new to modding and only wants to run a modded setup as quickly and efficiently as possible. Playing the game is most important.) the mod creator - Mod Author Guide (probably does not know much about mod managers or their differences but knows about Bethesda prioritization standards and such. Creating and testing mods and possibly mod interactions is most important.) Coming from NMM - NMM User Guide (this is likely a novice modder that has been modding for a while now [why else would they be using NMM?]. Playing the game is most important.) Coming from Wrye Bash - WB User Guide (this is likely an old-school modder or advanced and technically-minded modder. Tinkering is most important!) The advance modder - Advanced MO Guide (very likely an influential, old-school modder that is deeply involved in the modding community. Modding strategy and solutions are most important. Standardization and order are high priorities.)In all cases, exhaustive documentation is key! We need more and it needs to be more searchable. I think we need to get rid of Headertabs for our larger guides. TOC is very helpful for drilling down on relevant info as is careful article Heading organization. @Tech Thank you. You hit the nail on the head with regard to "need to know". Some of us just NEED to know WHY and HOW ... damn the CS degree! We just never had the time ... we want to learn and know EVERYTHING in the universe. We LOVE the Matrix movies and the concept of inserting an information-interface-jack directly into our brains and learning all there is to know about a thing at at the speed of light! Knowledge for the sake of knowledge. Obsessively. Ruthlessly.

I finally figured out the multilingual support (I think). It is NOT simple. TESVEdit does not seem to be able to do it correctly, as the names get jumbled and mis-assigned after saving. More later after I get a workflow nailed down. Sorting, weighted plugin done (7 more to go, including Requiem compatibility). Will likely finish tomorrow, as it is getting pretty late here .... at least I have figured it out I think. Needed to use Skyrim Localizer ... it is the only tool that was simple enough to use that actually worked once I figured out I needed to generate the unique IDs. Plugin attached ... @SRB, could you verify it looks right? It should just be your version of Soul Gems Differ - E.esp with localization and the four languages.

I will get the localization finished. Just finished downloading all of the foreign language strings and need to determine how to associate with the main plugin and the Requem patched version. Sorry I'm milking it. Will try to finish this evening!

I understand, believe me! No offense taken. Thanks for this confirmation. Unchecked BSA in Archives Tab = standard, checked = MO rules.One point though is that all of the Skyrim - * BSAs are greyed out (untoggleable) and checked (these are registered in the Skyrim.ini), but official DLC BSAs are not grayed out and behave like any other add-on BSA (these have plugin loaders and are NOT registered in Skyrim.ini, nor should they be). A brief word about the greyed out registered Skyrim - * BSAs would be helpful. The "expected/intuitive way" depends on the perspective of the user. That may be why I have been getting confused and seeing mixed messages. I expect the standareds of Skyrim asset prioritization. Whether that is intuitive or not depends on me. I get that you have tweaked the asset prioritization and loading mechanisms to work in a more sensible fashion that is made possible by the VFS, so messaging around this is very important (to people like me anyway). The Skyrim defaults of asset and load prioritization are only well understood by relatively few (of mod *users* anyway), so when MO's unique behavior enters into the mix it can challenge an already tenuous understanding --even if it is inherently more intuitive. We should probably explain the "MO standard behavior" as opposed to the "standard behavior". So if the plugin is only a loader, it is 100% redundant and should be tossed, but if it confers function, then there is another level of control allowed now: the plugin can invoke assets provided from any mod source, not just its own expected BSA assets (noting this as an interesting fact). This is effectively like not installing the mod; however, the BSA could still be registered in Skyrim.ini, but as I understand it, MO does not effectively register BSAs via INI tweaks, right ... ? Agree that this is a confusing case, but the actual wording for the error is:"Marked archives () are still loaded on Skyrim but the regular file override mechanism will apply: Loose files override BSAs, no matter the mod/plugin priority"... which is confusing (the link to Lojack's post is not very helpful, as that addresses several additional features. We could write up a clear summary of standards on the siki that you can link to.If I understand correctly from your explanation above, the standard load mechanism and prioritization are in effect when the plugin is checked but the BSA is not: The BSA is loaded with the plugin, and the BSA assets override other plugin-loaded BSAs loaded previously (as well as registered BSAs), but loose assets still override the assets within this BSA, regardless of the install prioritization of the loose asets (this is the standard behavior outside of MO). Is that correct (if it is, I will propose a better info text to avert confusion). This is another big point of confusion for me. Are you saying that MO adds an INI tweak to Skyrim.ini to register the BSA? I assume NO. I assume that MO loads this BSA according to the install prioritization as described above and that BSA registration is not even involved ... ? OK, so NONE of the Skyrim BSAs' assets (including the official DLC) are exposed within the conflict resolution of the mod Information dialog box. I assume that you have ... likely many times, but the information is not as clear or "up front" as it needs to be (given, the controversy of some of MO's inoovative functionality). This thread seeks to help with that EX. The following is taken from the documentation:"BSAs may also be unpacked in this tab by right-clicking the BSA and selecting Extract... This will extract the BSA's contents to any folder you choose.An accompanying ESP file to extract the BSA is not necessary in Mod Organizer. The only requirement is for the BSA to be checked here. " This is not very clear, since the ESP does not extract the BSA ... or is the BSA effectively extracted when the BSA is checked? .... I hope you see what I mean: there are ways we can be stating things that are more explicit and clear. The above leaves questions and even invokes new ones and is not isolated among the doc. But removing elements of control punnishes those that understand the functionality (or those that want to, are trying to, and are wise enough not to bother mod authors for their own lack of understanding). I don't think the solution lies in hobbling the software. A better solution is to make the most important information very relevant and right up front for all users to see (even accidentally). This still will not suffice though, because many people don't want to simply 'trust' that everything is happening the way it should be. Certainly, your testers (the MO and STEP staff among them) need to remain wary of what happens if things are not working correctly and to recognize any signs of problems. And we need to boldly emphasize certain talking points that address anything controvercial or not well understood.I am trying to condense that information here ;)If people want simplicity and opacity, Then they can use tools like NMM. MO and Wrye Bash both are more advanced tools that require more understanding to use effectively, and both expose things that arguably should not be exposed to standard users (I disagree though). MO has a more intuitive and less *scary* interface though, so it is attractive to novice users.I see MO taking over as the primary mod management utility as long as we keep things simple and clear as possible and address the concerns and controversy ... and debunk the false critiques.

Could someone please answer each of these bullets explicitly? I am growing convinced that nobody other than Tannin CAN, and he is likely too frustrated with the whole issue to do so I suspect ... Documentation is VITALLY IMPORTANT. Why do you think I spent hours working on this OP and this issue? How else is anyone to know exactly how things work? See my posts quoted just previous. I STILL cannot seem to wrest the answers I need to properly communicate exactly what the bahavior is. I understand that BSAs have same priority as loose files if checked ... what about the other three cases? I understand that soooo many people don't read through documentation, and it IS frustrating, but there simply MUST be a resource for the 10% of people that will actually reference it. then they can spread the information rather than the misinformation. It only helps! It is not at all clear HOW things function with regard to the questions I pose above. There are mixed messages, and if you and others read my post with a bit of empathy from the perspective of a person that was not involved with MO since its inception, you might understand my perspective. This is why there is controversy about the BSA functionality and subversion of the standard load ordering system. Only MO does this, and I think it is very powerful, but it is junk if we cannot (or do not) know how to explain the functionality in simple terms. The *supposed* effective result is that the install order prioritization is the ONLY prioritization from the MO perspective, but I really don't believe that after reading the documentation. Plugin-loaded BSAs would seem to have prioritization in some cases (when the BSA is unchecked in Archives Tab??). Could someone PLEASE PLEASE PLEASE! thoughtfully and explicitly address the questions I am asking? I will help to disseminate the CORRECT information once I know. I challenge anyone other than Tannin himself to deliver a simple and complete explanation of MO-Skyrim asset prioritization and loading 'rules' (these are two different things BTW).

He actually does recommend (or did in that OP your are likely talking about) TESSnip ONLY for string edits. I was able to easily generate the string files for each language (currently downloading and saving every Skyrim language string set) ... what to actually do with them is another story, but I'll push on.

@Tannin Thanks for clarifying. I too am beginning to think that the functionality that you built into MO, while very clever as Kelmych states, it is also very confusing and contrary to standards. I like the idea of having this functionality as an option but maybe not as default behavior ... and even more importantly, we need to get the exact functionality documented, as I still have many questions (see my last post). What seems clearer now is that MO effectively treats BSAs as loose files that are either prioritized by the plugin (Archive Tab BSA unchecked) or by the install position (Archive Tab BSA checked) ... is this correct? What about when the plugin AND the BSA are unchecked (warning triangle). Does MO read the BSA content and show the conflicts with loose files? If so, does the conflict resolution change if the BSA is checke or unchecked in the Archives Tab? I think that this subversion could be very powerful, as no other tool can do this, but perhaps it should also be moved to plugin status (and definitely the documentation needs to be much clearer, which I and others can help with, given that we understand fully). Please feel free to correct any inconsistencies in the OP! As a moderator of these forums, you should be able to edit that to correct any fiction that I have written and turn it into fact. Otherwise, if I am confident I understand, I will do it myself. @Kalmych & SRB Vano89 set the precedence (as well as others like alt3rn1ty's vanilla reduced textures) by altering the vanilla assets and distributing them on the Nexus. What I am proposing is no different, and after all this time, it would seem that Bethesda and Dark0ne are OK with this, probably because the textures are altered and not digitally identical. Many of the assets used by Nexus mods are alterations of the originals. As long as we only include changed textures, I think we are at least in compliance with many other Nexus mod practices. Let's do it eh?

Just as Vano89 provides the optimized HRDLC, we could provide just our DDSoptimized vanilla textures (including HRDLC textures) packed within a BSA and including a plugin loader. Or we could use an INI tweak to add it to the end of the BSA reg list in Skyrim.INI ... ? It is about time somebody provided a comprehensive set of vanilla optimized textures anyway.

@DoubleYou (and Tannin or whomever) I am afraid that I am still not clear on how MO handles BSAs. If I take the explanation about BSA priorities in the MO guide, then It would seem that MO can prioritize BSA content (as a solid block of assets) according to the install prioritization rather than the plugin prioritization, thus, decoupling a BSA from its plugin. When a BSA in the Archives Tab is checked, it allegedly loads according to install prioritization, but if it is unchecked, it is loaded according to its plugin prioritization ... this does not jive at all with the caption on the bottom of the Archives Tab window ("Marked archives ( ) are still loaded on Skyrim but the regular file override mechanism will apply: Loose files override BSAs, no matter the mod/plugin priority"); I only get the symbol if the BSA is unchecked and has a plugin that is checked in the Plugins Tab. Otherwise, the BSA is either checked or unchecked. Furthermore, right clicking the BSA provides an option to extract. Finally, dummy plugins used only to load a BSA are potentially redundant, but otherwise not. This is all very confusing, so we need a very clear explanation of the four scenarios and if any of the four scenarios following do or do not apply if extract is/is not used AND/OR if the plugin is a dummy or not: Plugin checked, BSA checked - ? Plugin checked, BSA unchecked - ... ? Plugin unchecked, BSA checked - ? Plugin unchecked, BSA unchecked - ?Is checking/unchecking in the Archives Tab an alternative to BSA registration or is this effectively accomplished by registering the BSA in Skyrim.ini? Does MO scan BSA archives and include the asset conflict information in Mod-Right-Click > Information > Conflicts?

Arthmoor just told me that the CK automatically edits certain things for no known reason. One is object bounds and another is tint layers for NPCs. They did not make those edits, and probably nobody does, so you will see different values sometimes. He said the changes are probably so minute that it does not matter unless they are all zero. I will assume that it should be ignored. I will also mess around with those damn strings. It still does not make any sense to me, but if I screw with it enough, it should finally become clear as mud. What about this tool?

I am not aware of any mods that do not have a plugin along with the BSA ... that is kind of a no-no isn't it? Best practice for vanilla texture optimization (or any texture optimization) is to extract the BSA, delete all non texture folders and continue using the default BSAs. The loose vanilla textures can then be loaded up near the top of the install priority where they will overwrite the original within the BSA and be overwritten by all other downstream mods. The exception is when there are other BSA downstream textures that should overwrite vanilla. These would then need to be extracted ... or, we could recommend repackaging all vanilla textures into a custom BSA and provide a special loading plugin ourselves. Once STEP is fully installed (especially with the Vano89 optimized vanilla HRDLC) there is not that much gain from vanilla texture optimization anyway. OP updated

That actually looks pretty damn good

@SRB OK, that is what I was thinking too. thanks for confirming @WI OK, so I can delocalize without having to start over with fresh plugins? What does "localize plugin" do anyway? Lastly, how in the heck do I save a plugin as a different name from TESEdit?