z929669

TOC layout is much beter for guides, but I do see what you mean with regard to linking to specific info ... tabbed layout parses things out nicely when provided a direct link; nevertheless, linking to a chapter or sub-chapter heading is very simple and apropos. See this rationale for the change and this Category for some compares. You should be able to fix all of your links by simply changing the portion of the link that looks like (as long as the tab-->chapter: #tab=to simply ... # Use case example: Linking a user to info about ENBSeries.ini setting "GradientIntensity" With HeaderTabs, unless each setting is under its own tab (which would be preposterous), there is no way to do this, so one sends the user to the tab itself and instructs taht user to "scroll down". http://wiki.step-project.com/ENBSeries_INI_HeaderTabs_Functionality#tab=_5BSKY_5DWith TOC, a precise link is possible: http://wiki.step-project.com/Guide:ENBseries_INI/Sky#GradientIntensity... the ENBSeries INI Guide is a bit different though since it uses subpages, so here is an example using the DDSopt Guide and pointing the user to info about supported texture 'base' types. IIn the first case, info cannot be linked directly, but in the second, it can: http://wiki.step-project.com/DDSopt_INI_HeaderTabs_Functionality#tab=DDSopt_Initialization_File http://wiki.step-project.com/Guide:DDSopt#Supported_.27Base.27_Types... furthermore, choosing the link is simpler in TOC format, because one only needs to load the page and ... (right click the chapter of interest) > "Copy Link Location" > paste > done. You should be able to easily update all of your links to point correctly, but another unfortunate aspect of Headertabs is that we cannot enforce standard wiki redirects, so once a former 'heading' (that has been linked in a forum thread) is removed or its name changed to suit the TOC layout, there is not way to redirect. Thus, updating links is a manual process. They at least should point to the guide though. Also, if you want to alter any of the guide wiki content or add to it, please do so! The suggested change seems rational, as it simplifies a common real-world use case. We could use more help on our wiki, so go for it. Changes are all reversible, and that is the beauty of the wiki ;) ALL USERS ARE WELCOME TO EDIT OUR WIKI WITHOUT WORRY OR CONCERN! If we don't like what you did, we can easily change it or revert it ... almost all edits result in an improvement, even if the edit kinda sucks

All fixed ... left to do: Look for instances of the word "tab" in the context of a chapter 'tab' (and not a MO GUI tab, which is correct). These should be replaced with the word 'chapter' or 'section' as appropriate. Feel free to take care of this piece, as that takes a bit more time than I have ATM.

All functionality is there, and the links should look like: Guide:Mod_Organizer#Chapter_NameThe longer name is a relic from the mock-up version. Since I moved the page leaving a redirect (see the top of the page when you follow that third link you posted), all links should work correctly; however, it is best to change all ... Guide:Mod_Organizer_TOC_Functionalityto ... Guide:Mod_OrganizerFeel free to do so if you want, but I will take care of it tomorrow if you don't. Actually, I will take care of the internal links, as I have some time now and can use a global replacement tool Thanks for pointing this out ... and feel free to check for any "#tab=" without the quotes. The old tab names may or may not be applicable, so you can deduce the correct chapter in the new guide and replace ... #tab=Chapterwith ... #ChapterJust be careful if you change anything so that all internal links remain functional ;) (changes can be reverted, but it could be confusing in the interim if anything gets mucked up)

Thanks! ... it is amazing what I just do not know! Sigs DO contain relevant info :D OK, sorry to digress.

At the risk of digressing, what is Modwat.ch? (just so I and everyone else knows, then back on topic :P )

NP ;) The Nexus is (again) having issues with these large files, so my updates are not available yet (Nexus virus scanner seems to be mucking up file size for large files and endlessly 'scanning' these without releasing them for download). I have updated the OP with links to my Copy share for download of the full versions.

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