tony971

Version 4.1 released: Re-based on z929669 and Kelmych's updated optimization level suggestions. The fixes from UHRP 1.1.9 were also included. Here's the current state of compatibility.

Optimized Vanilla Textures has been re-based on these suggestions. The only change is that any textures that were collapsed to 1x1 by DDSopt were replaced by ones collapsed to 16x16 or 16x4 by Optimizer Textures. This is why. The "true" unique thought of Optimized Vanilla Textures is the installation method. The conversation has changed from "loose vs BSA" to "plugin or no plugin." Both options have all other texture mods override them, including the unofficial patches. Not all tools were equipped with proper handling for the plugin-less installation method, though, so I had to campaign to add functionality. This is the current state of compatibility with the plugin-less method.

I'm not able to extract the 2.78 batch files with winrar or 7zip.Edit: One suggestion for the batch files that I've been meaning to put out: Bethesda accidentally named one of their folders incorrectly in HighResTexturePack03.bsa. What should be "textures/actors/dragon priest" is actually "textures/actors/dragonpriest" Any chance of getting 1_HRDLC_Clean.bat to fix this?

The EnableCompression sounds backwards. Disabling reduces stutter but costs VRAM, not enabling. So shouldn't it be enabled by default and then disabled in the event of stuttering?

Some of the ini section notes could probably be repeated in the troubleshooting section, i.e. the stuttering notes, etc. Also, a good resource for ENB troubleshooting would be the RealVision FAQ. SkyrimTuner's heard every single issue there is. If it's reproducible, it ends up in the FAQ.

Looks good to me :)

Fantastic work! A lot more straightforward than it was before.

I just pointed those out as notes for the Editing Enblocal INI section. The autodetect setting currently doesn't say anything about not always setting to the available amount of memory. The reserved memory doesn't mention any reason why users would want to keep the number low. In fact, it's stated that for 2GB cards, 512 is a good baseline and could be set up to 1024. There's no mention of compression and/or WaitBusyRenderer helping/hurting with stuttering issues. It might be worth noting out that the ENB vsync/frame limiter doesn't work for everyone and to check for screen tearing/FPS over 60 (which can be tested in menu screens). The main reason that I brought up the Anisotropy is because users are told to set it to 16. However, not all users can handle the small FPS hit. I have a feeling that ENBoost-only users will wander in here with mediocre computing power, looking for explanations about what the settings do.

JSYK, the AutodetectVideoMemorySize feature is often unreliable for picking out the appropriate value for VideoMemorySizeMb. Also, the ReservedMemorySizeMb setting should typically not be set higher than necessary. Part of ENBoost's optimizations includes moving processes from RAM to VRAM because VRAM is faster. ReservedMemorySizeMb is the amount of VRAM that ENBoost reserves for dynamic processes. If set unnecessarily high, then less VRAM will be available for other processes and there will be more spillover back into the RAM.Setting WaitBusyRenderer to true and/or EnableCompression to false will help with stuttering, at the cost of FPS (well, WaitBusyRenderer costs FPS directly; disabling compression costs memory). WaitBusyRenderer is significantly more costly than EnableCompression and should be used as a last resort.ENB's vsync doesn't work for me, either. Neither the vsync, nor the frame limiter. I've been disabling them both as well as iPresetInterval in the vanilla inis and using the driver vsync.I wouldn't endorse any specific value for MaxAnisotropy. Instead, have users set it to whatever their iMaxAnisotropy value in their Skyrimprefs.ini is set to and then set iMaxAnisotropy to 1 afterwards.If you really want the enblocal.ini expert, track down Keithinhanoi. He knows the settings better than anyone not named Boris.

The beta versions of Wrye Bash and TES5Edit have added the ability to read plugin-loaded ini files. This will allow them to continue loading the DLC BSA files even if users inadvertently reset the line in Skyrim.ini. That's one less notable concern to worry about. LOOT, BOSS, TES5Edit, Wrye Bash, Mod Organizer, and the Creation Kit are now fully compatible with all installation methods. The only major tool that I'm concerned about is SkyProc. Could a NMM/Wrye Bash user install the plugin-less version and see if they get missing string localization file warnings? If so, those users will have to use the plugin version unless SkyProc also updates with skyrim.ini-reading abilities.

Yea, I should have specified that when I refer to plugin-less users, I mean plugin-less NMM/Wrye Bash users. MO users don't have any issues to concern themselves with.

The installer is only for NMM/Wyre Bash users. MO users just download the BSA files and activate them with MO. And of course, they're free to use the BSA extraction tool included with MO if they prefer loose files.I don't have the files loose by default for a couple of reasons. First, it would be a load order mess for non-MO users. Half of the point of the mod was to get the textures to overwrite their original versions and nothing else. MO users benefit from the BSA files, too. I've kept the same naming conventions for the Skyrim - Textures.bsa and HighResTexturePack0X.bsa files. Leaving them as such will make MO not even load the originals. So you're not wasting time loading the original textures before loading the optimized ones.

4.0 has been released. This fixes everything that is in my ability to fix. All collapsed textures are now sized in powers of 2. All Creation Kit errors are fixed. The mod is now ready for STEP consideration.Advantages over the DDSopt guide:1. The textures are already pre-packaged with installers for NMM and Wrye Bash users.2. They will always overwrite their vanilla counterparts and nothing else (whether the user chooses to use plugins or not).3. All collapsed textures are sized in powers of 2.4. Can directly replace Skyrim - Textures.bsa and/or HighResTexturePack0X.bsa without causing errors in the CK.Things to be cautious of:1. Not all tools know the trick used to get the load order correct for plugin-less users (TES5Edit, Wrye Bash, and the Creation Kit all do).If a tool does not know to read the Skyrim.ini file when loading BSA files, it will not load the DLC BSA files. You'll be able to tell which tools don't know to read the Skyrim.ini because they'll have an error about missing string localization files. Users of any tools like this must use the plugin option.2. If a plugin-less user replaces their Skyrim.ini file after installing, no (known) tools know to read the backup ini files. The game will still run, but tools like TES5Edit and Wrye Bash will not load the DLC BSA files. Both tools are working on this functionality. In the mean time, users will just have to re-run the installer file after replacing their Skyrim.ini.

The vbs install script has been made to elevate UAC privileges. This has gotten rid of the need to have an executable file, thus making VirusTotal have a clean scan.The last thing that I want to do is make all planar textures 4x4 for multiple of 2 purposes. Also, any planar textures that the CK freaks out about not being their original size should be made their original size.Edit: Turns out that the CK is just throwing another one of its meaningless warnings. It can be ignored. But I still want to make planar textures a power of 2.

The forum post that alt3rn1ty linked could be considered an issue report.

I wonder if it would be worth it to tell users to re-pack their vanilla resources with BSAopt and then include a batch file that makes these changes: https://forum.step-project.com/topic/5111-bsa-archive-flags/

I've been testing on two vastly different machines with no issues.

The reason for the complex installer (complex on my end, simple on theirs) is because every texture mod that I see has one of two complaints: 1. "Why do I have to use this dummy plugin? I already have over 9000 plugins!!!" 2. "If these are loose files, won't they overwrite everything?" So I set out to fix that. Using all of my installation methods, textures will either directly replace their originals or get loaded between their originals and their unofficial patches. Always. Being able to do it without wasting a plugin slot was a fantastic bonus. As far as my reasoning to directly replace the Skyrim - Textures.bsa and/or HighResTexturePack0X.bsa files, compressed vanilla archives actually save more VRAM than their original .bsa files. Kelmych has done testing on this. It also saves me from having to do the ini trick with four more archives (which would force me to make Nitpick a requirement).

Alright, version 3.1 is live. All known issues are fixed.The only pending item on the itinerary is getting NANO-Antivirus to stop having a false positive for the installer files. I've made a sticky post on the mod's forum asking users to submit the installer file as a false positive until NANO-Antivirus updates its definitions. Other than that, the mod is ready for STEP consideration.

As for the mod's implementation, LOOT and BOSS now sort the plugins correctly. Wrye Bash and TES5Edit are working on the ability to read custom ini files. See here. Until they work it out, plugin-less users will have to edit their Skyrim.ini's sResourceArchiveList2 line to match their [DLC].ini line after installation. VirusTotal has a few false positives for the Textures Install.exe and Textures Uninstall.exe. I've submitted false flag reports to applicable antivirus companies. Three have already responded with new definitions. After these remaining issues are resolved, the mod will be ready for STEP review.

All in favor of changing the 1x1 textures to 128x128?

I've got the process as simple as it could possibly be to ensure the correct load order. MO users just have to place the BSAs wherever they want. MO handles BSA archives on its own. NMM/Wrye users are given the choice to hard-code the BSA files or load them with plugins. Hard-coding involves running a single script after installing the wizard. Plugins are to be sorted like every other plugin. Done.Also, I'm a subscriber to the "death by a million paper cuts" philosophy. If un-collapsing will help, let's do it. Are we sure it'll help?

Okay I lied. I updated again.

I've released one last silent update for the mod, adding support for Wrye Bash users. Unless further optimizations are found, the mod should be considered complete. I've also listed The STEP Team as co-authors. Would any admins like write privileges? Edit: if this ends up getting added anywhere in STEP, I'd hold off until LOOT sorts the plugins in the correct order. Also, LoJack has put in an issue for Wrye Bash to stop it from saying that the DLC have missing string localization files. See here.

Performance difference before/after this change? It seems like you and Kelmych have disagreeing opinions on the effect.