Kelmych

By the way, in my MO load following the mods you showed in your post I have the 3 optimized HRDLC archives and then the UHRP (installed without BSA extraction for consistency). I also have the cleaned version of Update.esm in a mod that loads before the ones in your list. The inclusion of cleaned update.esm in a mod, along with the mods listed in your post, should allow verifying cache integrity without causing a problem. There are still issues on best practices with mods that have BSAs, and we might want to mention this in the guide. Tannin suggests that mods should be installed unextracted when possible. I optimize textures on all mods that I feel deserve it, especially mods with 2Kx2K exterior textures so I can reduce at least the exterior normal map sizes. Even with this I've seen GPUz report 3.8 Gb usage on my 4Gb VRAM card. I typically leave the resources as loose files when I optimize the textures in a mod, but sometimes I will rebuild the BSA if there is one (e.g., when needed for a FOMOD).

It's hard to make specific recommendations without seeing any GPUz results. When I had a 2 Gb VRAM graphics card with STEP Extended and the Explorer pack I used the high res (2Kx2K texture) versions of mods, but I either reduced to or chose 1Kx1K versions of the exterior color map and exterior normal map textures.

The specific issues that came up recently about about extraction were related to the Unofficial Skyrim patches and the Skyrim BSAs. If you follow the comments in SRB's post (make mods from the DLC, install these with MO, use the install order shown above) you should be OK. The newly created DLC mods and the various Unofficial Skyrim Patch mods should be installed without BSA extraction, the BSAs will show up in the Archives tab, and the BSAs should be checked in that tab. sigh. Ninja'd.

The author of Campsites in Skyrim commented that Arthmoor's Cutting Room Floor restored Barleydark Farm but the location chosen for the buildings is on top of one of the campsites from this mod. The buildings were not originally there since they were never added by the Skyrim developers. It doesn't appear that there was much checking (which is admittedly difficult) to avoid these issues.

That's essentially what I proposed in another thread; we're both geniuses . The new DLC mods should use the cleaned DLC ESMs, which allows the Data directory to contain the original uncleaned versions of the ESMs. That change was suggested a long time ago before the issue with the false-flagged USP plugins came up. This is just a small change so should be fairly easy for most users. EDITed to fix the comment about the location of the DLC ESMs

You didn't say anything about the capabilities of the PC you are using or what mods with significant VRAM or script use are used beyond the mods in STEP Extended and the Explorer pack. The outskirts of Whiterun use a lot of VRAM by the way and CTDs there are not unusual (depending on your system and mods included). Have you done this while using GPUz to record VRAM use? The ENBoost and Skyrim memory patch in SKSE help avoid problems with high VRAM use, but they don't eliminate them completely. Do you have at least 2 Gb or VRAM; if not you will need to make sure you are using versions of mods with lower size textures. The Explorer pack increases VRAM usage, so when using it you need to make sure that you are not exceeding the VRAM limits of your graphics card by too much.

For that example it's a much bigger improvement than the differences between some of the texture alternatives we've considered. I wonder if it also makes some of the previous cave wall texture comparisons obsolete (suppressing a loud wail of "say it isn't so").

There are several possible solutions, but all of them have at least some side effects. As you and DoubleYou mention, we could put the DLC in a new mod. Make a copy of each DLC esm plugin and BSA and put each in a new DLC mod (one for each DLC) that can then be managed by MO. It takes a little more storage space since there is an additional copy of each DLC esm and BSA. If optimized vanilla textures are used then the only way they could be installed in the correct order is to put them in a BSA and then either replace the current Skyrim - textures.bsa with this BSA or put the BSA in Data and add the new BSA name to Skyrim.ini (register the BSA) so Skyrim will use it's resources instead of the ones in Skyrim - textures.bsa.

I'm assuming your ETAC patch for EWDR is still needed, right? I didn't see anywhere in the ETAC mod description page where the issue is discussed.

The way I read Arthmoor's comment was that the USKP fixed a problem for this NPC if Dawnguard wasn't in use, but if Dawnguard is used then a different fix is needed (presumably because Dawnguard alters characteristics of vampires) and that fix is in the Dawnguard BSA.

I also wonder whether MO could achieve the same behavior as vanilla Skyrim by using the USP plugins but unchecking each associated BSA in the Archive tab. I realize that this is generally undesirable, but it might cause the USP BSAs to load the way the USP team expects (i'm not sure about this, an MO expert would need to confirm). Of course, doing this would reintroduce the problem with how optimized vanilla textures are installed and loaded .

The Mighty Magick Skyrim Artifacts Rebalance plugin also makes significant changes to many of the game's artifacts and unique items that make them more powerful. You might want look at it with TES5Edit to see the changes it makes.

I'm a little confused by this discussion. Arthmoor's comment was that if Dawnguard is present and MO isn't used, Skyrim will use the mesh (0001367c.nif) and texture (0001367c.dds) from Dawnguard.esm (and not ones from the USKP BSA) for this character since the dawnguard.esm plugin loads after the USKP plugin. Since dawnguard.esm and Dawnguard.bsa are already in the Data folder, I don't understand how MO can provide this same behavior. How does MO provide the USKP BSA to Skyrim in a way that resources in the Dawnguard (and other DLC) BSAs are used when there is a conflict with the USKP? If I understand correctly how MO works (which I certainly might not), all of the BSAs in the Data folder effectively have lower "priority" than the BSAs (and of course loose file resources) provided by MO. This thread is currently marked solved, but the solution required expanding the USKP BSA and hiding the mesh and texture. The effect of doing this is that the mesh and texture from Dawnguard.bsa is used. There doesn't seem to be any way with MO, if I understand correctly, to keep the USKP as a BSA and still get the correct mesh and texture in this particular unusual situation. If so, isn't that the point that Arthmoor is making?

No, lower priority is correct in SRB's post. The best way to show this is with an example; hopefully this example isn't too difficult to understand. The Conflicting Graphics portion of STEP has mods that add high quality textures, and we usually do not want another mod that installs later (higher priority value) overwriting some of the these textures that were chosen by STEP participants. Suppose we have a quest mod that uses a BSA which includes modified scripts that need to overwrite the vanilla ones, some modified navmeshes, and this BSA also includes some replacements for vanilla textures. Quest mods are typically installed fairly late (higher priority) because of the modified scripts and navmeshes. If the usual MO approach is used the BSA box associated with the esp plugin is checked. MO will provide the full BSA into Skyrim. When it provides individual (loose file) resources to Skyrim using the virtual file system, it will not include any conflicting resources from mods with lower priority. The scripts and navmeshes from the quest mod will install in their proper place (since none of the lower priority loose file conflicting scripts and navmeshes will be provided to Skyrim), but the loose file textures from the Conflicting Graphics mods that conflict with those from the quest mod will also not be provided to Skyrim. For this example situation, the only way to get all the resources from the quest mod installed correctly is to extract the BSA from the higher priority (later in installation order) mod. The scripts and navmeshes (which are now loose files) will be provided by MO to Skyrim as they should be. The set of textures from the quest mod that we don't want to use need to be hidden, because if they are not hidden they will be provided to Skyrim instead of the ones from Conflicting Graphics. Note that this is an unusual case; there are very few instances where this is needed. When I looked at all the mods I've installed the only ones that need to use BSA extraction with MO were quest/location mods, and even then it was only a few of these mods. By the way, now that I understand the way MO provides resources (both loose files and BSAs) to Skyrim I don't think that using optimized textures provides any significant problems. The optimized vanilla textures can be stored as archives of loose files as we are already doing; I don't see any major advantage to storing them as BSAs. These archives are installed at very low priority (very early in installation order). Even though the USP mods (as an example) use BSAs for resources MO will provide the correct resources to Skyrim. If, for example, a UHRP BSA has an improved texture then the conflicting loose file texture from the optimized vanilla textures will not be provided by MO to Skyrim.

It might be relevant to some of the mods in the " A Real Explorer's Guide to Skyrim" pack. Some of these mods have BSAs with resources that overwrite vanilla assets and some STEP mods that have low priority values, and I doubt we always want the versions of these assets in the BSAs.

The ivy textures are in Skyrim - textures. There aren't any ivy textures in the High Res DLC.

If you use percentage you need to be careful since the mod might also have some smaller size textures whose size you don't want to change. This happens to be true for the Vanilla Uncompressed textures. The tintmasks and landscape normal maps are already small enough. DDSopt will do a little collapsing, and format changing with some of the landscape normal maps but these should be OK, and it's a lot better when optimizing them with uncompressed format in the Constraints tab. For these particular landscape normal maps, if the output formats are set to compressed (DXTx) DDSopt will collapse far too many of the textures.

MO is different and more clever than I realized. BSA extraction would seem to only be needed in some unusual cases where a mod has a BSA with some resources than need to be hidden so they don't suppress those resources from another mod that is lower in the installation order.

1. As long as the resolution limit is equal to or greater than the texture size DDSopt will not change the texture size. 2. The uncompressed textures folder has tintmasks in the STD folder, normal maps in the HRDLC2 folder, and a model space normal map (MSN) in the HRDLC1 folder. The only file greater than 512x512 is a 2Kx2K MSN in HRDLC1. You can use the S3 or H3 screenshot settings. The only difference will be with the one MSN. If you want to reduce the size of the MSN use S3 as the example otherwise use H3. I used H3 myself.

If we can do this legitimately it would save a lot of work for users as well as STEP staff We could potentially even ignore the DLC BSAs since so few of these textures aren't overwritten. The STD.bsa with optimized vanilla textures is roughly 1.27 Gb, by the way. The BSA was created with Archive.exe .

a few initial comments: "How do BSAs work" misses one of the cases, namely where a mod without a plugin has a BSA. If a plugin is needed to properly handle the BSA then either we need to extract all such BSAs or add extra plugins that are only used to provide an association with a BSA. It's certainly possible to pack the uncompressed optimized vanilla textures back into BSAs using Archive.exe as mentioned in the post (I did some tests on this today). This, and steps involved in getting the BSAs to be recognized are certainly make the vanilla textures optimization process less friendly for inexperienced users. If we do create BSAs with optimized vanilla textures do we remove the original BSAs and use the original names with the revised BSAs , or come up with a non-awful solution that doesn't add any new plugins. Loose files provides some decoupling of install order and load order. There are a lot of location and quest mods (including some in the REGS pack) that include replacements for vanilla textures, meshes, and scripts. In some cases, if BSAs are used for the resources vs. loose files, there can be no load order that provides the proper overwrites.

There isn't any need typically to change or add to the four default [Papyrus] parameters in Skyrim.ini. If you want to get a log of Papyrus script activity you need to change the values of three parameters from 0 to 1 (and then back to 0 when you are finished creating logs), but otherwise there is usually no need for changing or adding more parameters. There is a lot of erroneous information at various sites and posts in the forums on these sites that suggest making significant changes to the [Papyrus] parameters section of Skyrim.ini; you will find some useful posts on the forums here about these parameters including pointers to Bethesda website information on what these Skyrim.ini parameters actually do. SkyUI 4 added a favorites menu capability, and the Categorized Favorites Mod was removed from the STEP guide since it is no longer needed.

The pre-optimization batch file is built to handle one or more of the extracted BSAs; it doesn't need all of them. For each command it tests to see if the relevant extracted textures are available.

Where does it show up in the game so I can see how it actually looks (vs. just using a texture viewer)?