Kelmych

If the patches you are creating are mod patches and don't necessarily load at the end, then the patch I suggest should probably be a separate small patch that loads at the end. It likely would include patches that affect Skyrim and DLC compatibility (like Neo's general patch records) vs. mod-specific patches except perhaps for forwarding some USKP patch subrecords that otherwise get added to many mods when creating mod-specific patches. Its masters would thus only include Skyrim, DLCs, and perhaps USKP plugins. The records would include copies of subrecords from the master files that are often overwritten unintentionally by mods that are changing different subrecords, especially on some of the records with many subrecords.

I disagree. This is a problem that Hearthfires introduced and IMO should be fixed if Hearthfires is installed at all. Adding the patch records doesn't create problems for any mod that is added, and eliminates any future incompatibilities. I also feel that the idea that Neo introduced in Skyrim Revisited of a small set of general patch records makes a lot of sense. These were added to take care of some common subrecord forwarding problems that would otherwise eventually lead to some frustrating and unnecessary incompatibilities. These 3 additions fit into that category. I hadn't previously looked carefully at the plugins kryptopyr mentioned, but I agree it's an excellent idea to include these in a patch thus eliminating some plugins.

The problem with the house not building is due to a mod overwriting 3 records that include some subrecords that Hearthfires added. It's a Hearthfires problem (IMO it shouldn't have implemented house building with a dependency on a record that was already used by mods before Hearthfires wa released and would almost certainly be overwritten if it wasn't already), but fixing it requires either a patch or elimination of the mods that happened to overwrite the record. It was previously discussed in this thread, and I provided the patch changes needed in this post. The thread discusses Unique Region Names, but there are other mods that edit the same cell record. Using TES5Edit to create such a patch or identify the mods that overwrite the cell records unfortunately requires some background in using TES5Edit. I've asked that the patch needed for this problem be included in an overall patch that STEP is creating. If you are able to patch it or remove the mods overwriting the cell record, you should be able to continue the game vs. having to restart it.

The cell values are in this post I entered a while ago.Â

One of the most common problems for Hearthfire users is that mods can overwrite the 3 subrecords that have the name of each of the 3 Hearthfire houses. The patch I build for myself to load near the end of the load order includes these 3 subrecords so that Hearthfire works properly. I read the Readme.txt at GitHub and I don't see any mention of a patch for this. Does the compatibility patch include this, and if not should it? We frequently get questions about the Hearthfire house problem on STEP forums (including one today), and it would be great if we could mention that a STEP patch fixes the problem without requiring the user to remove mods (non-STEP mods, but nontheless useful mods). IMO it's really a Hearthfire problem, not a mod problem, but not something that a USKP patch can fix since it needs to be in a patch that loads near the end of the load order.

Is this specifically a problem with using DDSopt; if not I'll move your post to a thread where you will get more response.

[Edited] 4_Mod_Sorting&Pre-optimization-beta.bat is the correct batch file, and the guide has been updated to show that file name until more testing is done).Version 2.57 of the batch file was uploaded later this evening and fixes some previous problems. 1. No 2. In some cases it is. Some small uncompressed textures are put directly into Mod Optimized so their format isn't changed in DDSopt while optimizing large uncompressed textures (1Kx1K or greater). 3. Currently it is; this part of the batch file is being tested and improved. This is an interface texture, and there isn't a lot of value (VRAM reduction) in optimizing interface textures.

I'm adding some words to the command line to mention that any level 2 errors (The system cannot find the file specified.) should be ignored. There isn't any straightforward way to suppress these errors indications without losing the ability to get actual errors noted. These "errors" occur when there aren't any files of the type that the robust copy (robocopy) executable is looking for in a particular line. This didn't happen with the vanilla textures since the structure of these textures was known beforehand and there weren't any commands that couldn't find files.

I added material to the Quick Start portion of the guide that includes a brief overview of using the new batch files for optimizing mods (vs. vanilla textures). To make it easier to understand how to use the batch files, I'm working on an example case to show how they can be used to optimize a set of STEP mods.

The space core mod comes as a Steam Workshop mod with two files, portal.esp and portal.bsa. What was the structure of the folder you created for it; for example, did you extract the files from the BSA? The 5 textures in the BSA are all ordinary color map textures.

It's now fixed in the guide (16 vs. 17). As you mentioned, it doesn't matter whether the HRDLC are combined after optimization or not; it's up to you.

Ignore the difference. Some empty folders were not being removed by the batch file and a small change was made to the batch file to fix this. It didn't affect any later steps (the empty folders weren't copied) or the final result; what really matters is the number of files after the HRDLC cleanup. We'll upload a new version of the directory tree picture.

I haven't seen any errors with LOD textures with DDSopt and the vanilla textures; there is always the issue with LODs on whether they should be optimized at all, especially for the ones provided in mods.

Portions of what is found in \textures\actors\character .

For me the issue is less about whether Texture Optimizer can resize them, and more about whether if it does how much graphic quality is lost.

You might want to read the threads on "3.1 Gb limit" on problems users have even with high end systems without at least doing some selective texture size reduction. There are different sets of constraints in the DDSopt guide to reduce the size of selected textures (to allow more textures to be used), and to select different texture formats (to eliminate some of the graphic quality problems that choosing a single set of constraints and using it for all textures can cause). That's why I asked about your style of modding; for some users these quality losses aren't very noticeable and not worth the extra effort to prevent them. We don't have any particular recommendations for a "one size fits all" set of constraint values. You could use the first set of constraint values you listed (created by one of the STEP staff) and make the resolution limit sufficiently high that DDSopt replaces mipmaps but doesn't change any texture formats. The ones in "Optimizing the STEP Mods" assume you are using different constraints tab parameters for different texture types; no individual constraint set in that part of the guide is intended for use with all texture types. Most of the textures in Skyrim have DirectX compression, thus the Dxtx default for many texture types.

I'm not sure why DDSopt can't resize some rectangular textures, but it can't. We asked Ethatron but it was around the time he took a new job and hasn't had time to work on DDSopt. It's one of the reasons I don't try to optimize Skyrim Flora Overhaul. I'm not sure it matters a lot; large textures only affect VRAM load if they are accessed frequently. I tried to optimize Mature Skin and Body, but concluded to leave the uncompressed body and face normals(_msn.dds) untouched.Going from X8 to R5 for the _msn* degraded the quality considerably, giving me some artifacts(in the compressonator) and less contrasted(warm) skin look in-game. We'll note this in the guide or you can if you prefer. It's always helpful to add comments based on actual tests. I've been doing some precision reduction for tangent space normal maps (*_n.dds) but I've been leaving the model space normal maps and face textures alone.

There have been very few posts on the appropriate DDSopt parameters for optimizing uncompressed textures. The majority of the uncompressed textures in mods (vs. vanilla) are in body-related textures. * The comments that have been posted are almost all about using the DDSopt preset that changes numerical precision, and all the posts so far have said using this change does not seem to noticeably reduce graphic quality for color maps or normal maps. * The other major comment is that uncompressed normal maps are noticeably better than compressed ones, so if the author provides uncompressed normal maps (e.g., *_msn.dds) it is best to keep these textures as uncompressed. * If the uncompressed textures are 512x512 or less there isn't much value in changing them. Recently I've been using the reduced precision uncompressed preset in DDSopt with mods for both color maps and normal maps (this requires sorting or filtering the uncompressed textures and doing a separate DDSopt processing step), but I haven't done much comparison yet with the unaltered textures in game. The hardest part of creating the new batch file for sorting mod textures prior to DDSopt optimization has been in finding a way to automatically identify uncompressed color map and normal map textures so these textures can be optimized separately with potentially different resolutions and preset values. I'm currently using texture size which works in a almost all cases but isn't 100% accurate.

Yes at least for now. With SRO in STEP again, it was felt that its farmhouses were closer to being HQ versions of the vanilla farmhouses.

answered in the DDSopt guide thread. It's only necessary to post questions in one thread.

A while ago in the batch file versions the "Vanilla Uncompressed Normal Maps" folder was changed to "Vanilla Uncompressed Textures", and uncompressed tint/tone textures in STD were added to the folder. It doesn't affect the results in "Vanilla Optimized", but it is more consistent with the strategy for handling uncompressed textures that is now also used in the batch files for STEP mods. I'm not sure why there would be one additional file, but I don't think it will cause any problems.

What kind of system are you using? It's hard to comment on settings without knowing a little about the system and how you plan to mod Skyrim. Are you going to try and add mods until the game no longer work well then eliminate some mods so it is somewhat stable. Are you going to be fairly conservative about adding mods to try and ensure stability? How much does graphic quality matter to you; as you read the STEP forums you will find users who want the best possible rendering of objects and others who are willing to accept a little less quality in order to be able to get some other capability (e.g., more mods used, game stability, or a more immersive experience)?

The original SRO had some files from the HRDLC that were unchanged duplicates of HRDLC textures. These duplicates were removed in the "optimized" version.