z929669

Thanks for the info. No worries, it's the season, and hobbies need to stay fun ... ;)

Uploading a small patch to fix tamriel.objects.dds and forward several USP assets that have been added to the USKP and the USHP since first release. I will shortly be overwriting the main files, but this will save those that have already downloaded v1.0 the trouble of grabbing another large file.

Yeah, I posted there ... weird behavior.

Just wild guessing, but I would double check folder permissions for MO_Mods and all of the WB folders listed in the bash.ini. Then I would configure those paths in both apps (and be sure you are running latest version of both apps). I get standard 'good' behavior, but my WB/MO folder locations are custom and not on same drive as Skyrim. My MO download directory is same as my WB package directory.

That's all true, but I am fairly confident that this will be the only error --and it is a pretty nasty one-- so I will just repack and use the patch approach going forward. I hate hotfixes cluttering up the file list.

Yeah, that one texture snuck through in my processing and 'should' be the only problematic texture. I will re-upload soon, but would like to verify that there are no more obvious issues ... and there are some USP textures that were recently added to the USP, so I need to delete those as well and update the Readme, so give me a few days to do so. in the meantime, you can manually create an MO mod with that one unoptimized texture inside and load it after the optimized textures package.

Agree about adding RAM, but we'll keep it in simple format. Memory speed is not really applicable to Skyrim though, and the CPU basically infers the RAM speed potential. Multi-monitor setups for games are not common, but we can add a variable for that too I suppose ... variable monitor res is just not practical though. The system specs template is accounting for the major hardware bottlenecks rather than variations to the general components (e.g., Mobo, RAM specs, GPU clocks, etc). Will update once I add those features. Thanks EDIT: I added System RAM (those of you that updated already may want to do so again!), but I did not upgrade for multi-monitor setups, because they are not practical from what I have learned. people use it, but we don't recommend it, due (fe.) to issues with presenting the game menus.

In my XP, MO download speed is akin to downloading any other way and thus limited by Nexus side of things. Switching preferred servers like tannin mentions can have a big impact (unless there are no choices, then try refreshing MO maybe). The other major difference is whether or not one has a Nexus Premium account or not. Any serious modder should consider forking over the $64 (maybe more now) to get lifetime Premium membership at the Nexus. I purchased this years ago, since I had been using the site for so long that it just seemed 'right' to support it. Afterwards, I noticed right away that my 1GB downloads only required a few minutes to complete. Premium servers are probably one to two orders of magnitude faster than standard servers, and you can prioritize them in MO I think.

Yes, TESEdit version has an impact, but only when updating TESEdit after already cleaning ... I am not sure what LOOT is keyed to complain about and whether it looks for a CRC change or ITM/UDR and whether or not LOOT depends upon cleaning results from a particular TESEdit version. I updated the DLC mod cleaning instructions in the guide and mod pages after I had a very different XP when following them during my validation/update Core build for 2.2.9 (files are not produced in Overwrite with new versions of MO that place all vanilla plugins and BSAs into the MO installers list as "unmanaged". In my testing of TESEdit launched via MO, the cleaned plugins were not written to Overwrite but rather back into \Data as is the default behavior when running TESEdit stand-alone. With latest versions of MO and TESEdit, the new instructions should be accurate (and simplified) Yes, TESEdit version has an impact, but only when updating TESEdit after already cleaning (I think) ... I am not sure what LOOT is keyed to complain about and whether it looks for a CRC change or ITM/UDR and whether or not LOOT depends upon cleaning results from a particular TESEdit version. I updated the DLC mod cleaning instructions in the guide and mod pages after I had a very different XP when following them during my validation/update Core build for 2.2.9 (files are not produced in Overwrite with new versions of MO that place all vanilla plugins and BSAs into the MO installers list as "unmanaged". In my testing of TESEdit launched via MO, the cleaned plugins were not written to Overwrite but rather back into \Data as is the default behavior when running TESEdit stand-alone. With latest versions of MO and TESEdit, the new instructions should be accurate (and simplified)

I am guessing because she never copied the doc files into "WB Output" in MO ... so they just kept updating Overwrite ;)

I seem to remember 'shininess' (i.e., texture brightness/contrast) being a bit much in WSCO, but I have yet to test your compilation, Tech, so cannot attest to this being a potential 'issue'.

OK, I have confirmed that this texture is the source ... and it should not have been optimized. It is OK to optimize terrain if done correctly ... but not tamriel.objects.dds It is weird though, because the compression format was not changed by DDSopt at all, so this texture should just be totally skipped (and I thought it was skipped according to my DDSopt.ini) If you are willing, please replace that one file and keep checking though and let me know if you find anything borked that is not from tamriel.objects.dds

See my previous ... Also, I guess MFG Console does not give the texture name :/

Wait ... are you using TFC in the console? If you are, then you can only evaluate textures that are in the current cell, as content outside the cell is not loaded, because your PC remains in the current cell and only the camera flies around. This will look like a bunch of LOD up close I think. EDIT: OK, that first image is the mountain behind the first windmill you pass as you go to Whiterun from Riverwood ... it looks fine in Performance version for me (less the shadow striping I see in TFC mode)

that looks like a form reference ... can you provide the texture name? Or at least a location?

MFG Console gives you the info, but you may have to activate that piece in the INI (you probably won't want the other features of the mod though).

You need to use imagur or Dropbox for posting pics. Link to them via URL instead of uploading. Can you tell me the names of the textures you are referring to and confirm that this is related to the textures provided by this package? You can use MFG Console to help identify the textures. (that first one seems like an ore texture). Are you using Performance or Standard?

Discussion thread: STEP Optimized Vanilla Textures by z929669 Wiki Link Dropped in v3.0. Now longer being maintained. This is a thread corresponding to the optimized vanilla textures for those vanilla textures not already covered by other texture replkacers in the STEP mod lineup. The mod has Standard and Performance versions available. Mod Testing Just need people to load this up in their game (see ReadMe for details). Load directly after the Unofficial High Res Patch: check as many indoor/outdoor areas as possible for any borked textures. Check FPS and VRAM consumption differences with and without this mod for both Performance and Standard versions. I have provided a patch (available on the Nexus now [Dec, 18, 2014]) to correct the original versions of the optimized textures for those of you that already downloaded the original versions. From the patch ReadMe: Patch ReadMe

Those look promising, too

Seems like a good improvement ... once all have been covered and pass muster (which they should, if all will be covered analogous to the current coverage)

Nice test run ;) I cannot attest to any of the m-thread settings, but I will check out EnableCompression enblocal setting, because I know there are variable results with that one. Agree with keith though that most of the skyrim.ini settings should be left at default unless there is some reason to change them (i.e., testing). We should continue to recommend what we always have, remaining cognizant of said changes above just in case for testing behind the scenes.

@Greg Sounds like you are familiar with wiki maintenance. Feel free to contribute to our wiki in any way you wish. We can always use more help ;) PS: We do use some extensions that allow custom CSS and the like. HTML generally works in the wiki, and we use it to some extent (complex lists are a good example). Our wiki is largely powered by Semantic MediaWiki.

Thanks for the feedback ... can you confirm what settings are key? You can do this by commenting individual changes you made to the INIs and testing on same sequence in game.

This. Thanks for finding that.

DoubleYou's work I would guess.