Kelmych

A short discussion of the advantages and limitations of Optimizer Textures and DDSopt has been added to the General FAQ tab in the DDSopt guide.

A new version of the batch file has been uploaded. The changes made were to support performing the optimization without the HRDLC. I am adding a short notice to the guide for the batch processing. The batch processing uses the robocopy program which has been installed in Wndows by default since Windows Vista. It is available for Windows XP but it isn't installed by default. It is part of the free Microsoft® Windows® Server 2003 Resource Kit Tools (this url is for the english language version; it is also available for other languages). It replaced XCOPY which was not very robust, and added some useful new features. Alternatively, if Wndows XP is being used XXCOPY can be substituted for Robocopy; it is free for personal use and I'm fairly sure that it supports the same syntax. hellanios, if you are using Windows XP this might explain the problem you reported.

It only uses the texture files from the DLC and doesn't care whether the rest of the DLC bsa stuff is there, and it doesn't care which DLC are there or not. I've been making other small changes and I'll upload a new version very shortly. I don't think it will solve your problem but we'll see. It assumes you have administrative privilege.

Did the log.txt file show any errors? Did the batch file run for a long time or only briefly? The initial file copies are made to the STD folder in the Vanilla Optimized directory; were any files copied there? Roughly how large (Mb) is the Vanilla Extracted folder?

The new batch file seems to work well in my (limited) testing. The DDSopt Optimization tab of the DDSopt guide has been modified to describe the use of the batch file, which resulted in eliminating the steps where the DDSopt GUI was used to select and deselect portions of the textures. Screenshots have also been added to this section to make it easier to determine the settings to use in DDSopt while optimizing different types of textures. The Quickstart tab was also modified for consistency with this approach. One of the purposes of the simplification was to reduce the errors that were happening too frequently as users were following the at-times-intricate steps in the DDSopt guide. We would appreciate comments on whether the changes help, and what issues remain that we are capable of addressing (the just-put-the-BSAs-in-a-folder-and-push-one-button-and-poof-everything-is-optimized is still a bit out of reach). Currently the optimized output creates one archive file for each of the vanilla BSA files. Is this what DDSopt users prefer? I noticed, for example, that z's example above combined all of the HRDLC into a single file vs. 3 separate ones. Do users prefer to have some or all of the optimized normal maps in different archive files or integrated with ordinary textures (as it is in the current DDSopt guide)? I've planning to provide a small batch file that uses 7zip to separately archive each of the optimized loose file folders, but I'd prefer to wait until we have a better idea of how we want to organize the output.

It looks like the diffuse terrain didn't get remipped (5093 skipped textures), by the way. Did you manually select the different categories you used? When you finished how did you repackage the data into archive files? Are you planning to do the DLC textures also?I processed the diffuse terrain along with all the rest in my final run, so they passed the verification I assume. I forgot the PNG though, so I'll need to copy those over as well as the interface textures that make sense. It may be a good idea to put anything like these in the DDSopt INI so that you don't need to treat them in your BATs. I have yet to test everything and confirm the results I expect. I ran as many runs as you see logs using filters applied manually. Just repackaged into 7z fast/non-solid. Still have not messed with the DLC other than HRDLC. Part of the reason for the new batch file is to automatically take care of any direct copies like the .png files so it doesn't require a separate set of user steps. It also eliminates the need for special handling to eliminate any text and other non-texture files since they are never copied from the extracted BSAs to the folders that DDSopt itself uses; DDSopt runs on some temporary folders that contain only texture files and it doesn't run directly on the Vanilla Extracted folder. Which interface textures should be copied over directly, or is it best to just put them in ddsopt.ini; I expect the latter is the better approach for these if they are .dds files?

The guide is on a wiki so under Page Tools at the top select History to show when it was changed and to look at previous versions. Some of the changes are annotated. Is there a particular set of changes you were interested in? Right now we are making some changes in the vanilla texture optimization steps in the DDSopt Optimization tab. There were comments that the procedure was a bit tedious and error prone. We have also been looking at a better set of resolution/format parameters in the DDSopt Constraints tab use with for normal map texture files. This should be finished very soon.

It looks like the diffuse terrain didn't get remipped (5093 skipped textures), by the way. Did you manually select the different categories you used? When you finished how did you repackage the data into archive files? Are you planning to do the DLC textures also?

That's also what z and I concluded; any remaining fixes are replaced by other textures from a variety of mods.

The Immersive Patrols mod also adds bandits, but they are only on the roads.

Unfortunately there haven't been a lot of comparison tests reported, especially with changing formats and resolutions for normal maps, to allow making good recommendations for anything other than architectural textures and some landscape textures for large objects like mountains. You could read through the entire 100+ pages of this thread and find relatively little in definitive test results and only a few useful anecdotal findings. It's particularly hard to make any recommendations for SFO since the author has already done some optimization, and many of the textures are rectangular (which complicates optimization). As I mentioned in a recent post, I'm working on some new processing steps, initially for the vanilla textures, to greatly simplify the optimization process. The problem I have isn't on creating some batch processing steps to eliminate a number of the current tedious steps - that's fairly straightforward - but on coming up with some default parameter recommendations especially for how to handle normal maps (e.g., does it actually make sense to use additional compression/lower resolution for normal maps with the vanilla textures since so few are architectural or landscape related; and is the answer different for a system running extreme STEP vs. a lower end system).

When we include a discussion of patch and plugin merging in STEP and SR guides we will probably want to provide specific instructions on what can safely be merged.

The description section on Nexus for this utility mod is also quite useful. It covers some of the major issues involved in merging plugins. I edited the mini-guide referenced in my signature to include discussion and reference to this mod, and I added a new subsection on issues associated with changing FormIDs.

This mod is in Skyrim Revisited with options: Vanilla + Nord Hero Arrows [No Increased Damage], +8 Units Deeper, Faster Arrows Improved +50% Faster, Faster Bolts Improved +50% Faster.

I'll try again. There are two standard uncompressed formats for textures without specularity, R8G8B8 and R5G6B5, that differ only in the level of quantization used. A texture file using R5G5B5 format is roughly 1/2 the size of one in R8G8B8. These are different only in the number of bits used to represent each of the colors (~5 vs. 8). Separately, there is an issue of what resolution (e.g., 2028x2048 vs. 1024 vs. 1024) to use for textures. A texture with 1Kx1K resolution is 1/4 the size of one with 2Kx2K resolution. Resolution is independent of the degree of quantization (~5 vs. 8 bits) used. Since the discussion in this thread is about tangent space normal maps, one of the questions that came up previously is whether it is better to save a normal map texture at: "full" resolution using DirectX compression (e.g., DXT5), oruncompressed at a lower resolution (e.g., half the resolution).Many of the texture creators said that ordinary DirectX compression works so poorly for normal maps that it is better to use a lower resolution uncompressed texture than a full resolution DirectX compressed texture. When optimizing normal maps there are many combinations of compression format (8 bit uncompressed, ~5 bit uncompressed, ordinary DirectX compression, and even a special variant of improved DirectX compression for normal maps that Ethatron developed) and resolution to choose from. If the texture creator saves the normal map texture as uncompressed, then it is desirable when optimizing to save the normal map in one of the two uncompressed formats at either full or half resolution. We would then have 4 choices for how we save the normal map texture (assuming we don't convert it to use DirectX compression). For the Terrain Bump package it was recommended that we save the normal map textures at the original resolution but use ~5 bit quantization vs. 8 bit (thus saving about 50% of the file size).

The DDSopt guide now has an updated version of the HRDLC repair procedure using improved batch files that don't use drive substitution. The revised procedure should be much more robust.

The MCM version of this mod has been updated to version 2.4, which includes some error corrections.

Wrye Bash stores information about the mods including installation (package) order in "table.dat" in the "Bash Mod Data" directory (this directory is at the same level as "Bash Installers"). If you save a copy of this directory for each set of mods you want to use, you can do what you want if the versions of the mods used have not changed (you would need to update the installation tab in WB for each mod that changed). Skyrim Installation Swapper can be used to create and switch between different profiles such as a "standard STEP" profile and a "Skyrim Revisited" profile. It automatically copies all of the non-vanilla data in the Skyrim directory as well as all the directories that Wrye Bash and BOSS use. It's a lot slower than Mod Organizer for swapping profiles. Another way to do what you want is to put all of the mods (including the standard STEP mods and the Skyrim Revisited mods) into the Bash Installers folder and using either alphabetic order (as you mention) or the numeric order column in WB setup the installation order for the combined set of mods. Although WB doesn't have named "groups" of mods that can be installed/uninstalled together, it does allow installing/uninstalling multiple mods at the same time. Using combinations of shift-click (for mods that are adjacent in installation order) and control-click (for the rest of the mods) you can highlight a large set of mods (e.g., the entire set of Skyrim Revisited mods that are not in your standard STEP set) that can then be installed or uninstalled. Right click and select install or uninstall and it will take care of the entire set, and it does so fairly quickly. This is typically how I handle sets of mods with WB. It's a lot quicker than using Skyrim Installation Swapper and there is no need to separately handle mod updates after a large mod group install or uninstall (since there is only one Bash Installers mod set and the mods are updated regularly). Each time after doing this you need to run BOSS again to set the mod load order, but this is very quick and you would need to do this no matter which approach you choose for changing the groups of mods being used. This latter approach isn't nearly as convenient as the named profiles in Mod Organizer, but it is quick enough for the changes I typically make and retains all of the power of Wrye Bash to show full details of resource installation conflicts.

For vanilla texture installation my concept is the following (some details are left out): Copy all relevant vanilla BSAs into a working folder (vanilla textures, 3 HRDLC (if being used), and any DLC BSAs).Use BSAopt (preferred) or DDSopt  to extract all into the Vanilla Extracted directory (single process step).Run the revised batch file to repair the HRDLC (if HRDLC is present)Run a new batch file (using XXcopy) moves .png files to "Vanilla Optimized" and removes all non-texture dataUse DDSopt to create optimizes the texture files putting them in "Vanilla Optimized" (single process step, no fiddling with filters)Run a new batch file (using 7z.exe with the proper command line flags) to archive the resulting folders and do any cleanup needed like moving or deleting the BSAs and moving the archived files to the top level working folder.The intent is to minimize user steps as much as possible. The batch files will run properly with all BSAs or any subset. I also have a concept for doing the STEP files, including handling the normal maps and handling the different resolution needs of different users, but I feel the vanilla textures version should be done first.

I changed the DDSopt guide to mention the version to be downloaded, and the need to run it with administrative privilege so that parameter changes are saved (to prevent yet another round of questions).

Wrye Bash will merge a few types of records across esp/esm plugins when creating a "bashed patch". TES5Edit can merge some other types of records across esp/esm plugins when creating a "Merge Patch". These merges reduce (but don't completely eliminate) the need to use TES5Edit to create manual patches for compatibility among mods that edit the same records. Individual manual patches for compatibility, such as those listed in the Skyrim Revisited guide, can potentially be manually merged with TES5Edit but care is needed because of load order concerns and since the resulting patch has many dependencies.