z929669

If you use Recolored Basic for 181b (works fine for all Basic versions), you will overwrite the LOD as well as two snowy pines diffuse maps. I made those two diffuse maps a bit whiter and reduced the yellow tint a bit to blend better with the LOD and to look a bit 'snowier' overall. So if you overwrite Hi-Res Pines with Recolored, you will lose Hi-Res snowy pines and go back to the standard res for those. I would advise against Hi-Res Pines unless you are not installing many other mods, as this is quite taxing and largely defeats the purpose of using Basic. Alternatively, you could delete the snowy pines from Recolored, and you will get hi res versions, but they will be yellow-ish against the snowy-pine LOD (ENB will likely exacerbate). I can create the hi-res recolored as well though. Just not at the moment ;)

Terrain mods should have almost zero impact on performance (LOD depends, just avoid SFO 4k). The biggest issues are likely going to be SRO and, as already mentioned, SFO. It is imperative to install the Vano89's HRDLC optimized. Lastly, start over completely ... uninstall everything and collect a baseline benchmark according to the guide and benchmarks at each point that the benchmark tag appears in the guide. This will isolate the problem areas with regard to performance and will potentially rule out the baseline INI tweaks as being a root cause (as well as any of the sections). The most taxing section is Sec G, but F can also take a toll and so can H and K.

If someone wants to transfer this guide to the wiki, then please do (be sure to follow the format of the other guides); otherwise, it seems like this is irrelevant, and it will be discarded.

Stability issues are caused primarily by two recurring themes (after conflicts are appropriately resolved): Intensive scriptingMemory limitations... and the latter may effectively be the most ubiquitous and the only relevant one of the two. Use the link provided in Neovalen's guide to get an optimized version of SRO, dump all of the mods that dramatically increase spawning and that compete for runtime at any given moment (like during combat), and use TESEdit to resolve plugin conflicts where applicable. This is the best way to resolve CTDs and ILSs (specific reasons as yet unknown but for general observation of the above). STEP Core (in its entirety) has neatly 150 mods and is highly stable across platforms. Given that all of said mods are pretty much a given for any modded setup, it provides an ideal base upon which to test the limits. The process we are trying to advocate is to establish the Core base in its entirety and build a set of mods on top of that (i.e., a Pack). For this Pack, I would recommend beginning with a thorough test of just Requiem installed atop of Core, and add pieces bit by bit with plenty of testing in between. Continue to build only as problems are either removed or resolved. I would use this approach for any Pack that would add any type of comprehensive overhaul mod, as such mods will be the primary cause --either directly or indirectly-- of any issues.

OK, so you are saying that the texture overhauls tax the entire setup too much? I don't think this would be the case with any of the mods in STEP:Core as long as 1k or size-optimized versions are used. The HRDLC itself costs much in terms of quality (and SRO "Optimized" is not too taxing ... Neo links to this from his guide).

Those overhauls would not cause any downstream issues ... they would simply be overwritten, but I'd bet a fair sum that some of the overhaul textures would still shine through, so I can't see why one would not use them and STEP:Core in its entirety. It should be toatally feasible to present any Pack to a person the has installed STEP:Core and say: "now, install this mod list using these instructions". Why? None of the STEP:Core mods cause any unresolvable downstream conflicts. There may be a few redundancies, but Pack authors should be allowed to focus on the Pack idiosyncrasies if the user has already installed STEP:Core as we have outlined it. In fact, having a functional and complete STEP:Core base should make the Pack author's job much simpler, and any redundancy with the Core approach would be small potatoes compared to guiding the user installation from vanilla Skyrim.

Updated OP with link to Pack support thread to address any user issues.

There is really no difference. If you are trying to conserve every last drop of VRAM, go with performance ... there is really no noticeable quality difference at all.

Still recommend Basic v181b for STEP with Recolored LOD. 183 update should work, but still use the 181b LOD unless you are using the Regular 182 as a base .. then you would use the Regulare 182/3 Recolored LODGot it, thanks. And what about Renn's DTTL? Is that just a work in progress? I know Skyrim Revisited uses it.I added more reference to my prev post ... DTTL is not polished at all with regard to LOD. I know this from working with the LOD. None of them really match SFO at all (haven't checked the updates though). The 181b LOD is just a mis-recolored vanilla LOD. The noise map is good though, but it does break up the distant roads. SFO Recolored uses vanilla 1k LOD base for Basic 181b (I may look at using the SFO 2k custom versions though in next release) and SFO 4k bases for the Regular versions.

Still recommend Basic v181b for STEP with Recolored LOD. 183 update should work, but still use the 181b LOD unless you are using the Regular 182 as a base .. then you would use the Regulare 182/3 Recolored LOD. Also, to clarify some of the comments/questions in previous posts: Regarding distant terrain (these will NOT cause CTDs or other issues ... those have other unrelated causes): Recommend using your favorite terrain noise map (e.g., DTTL, EDT-Earth, HDET)Highly recommend EDT2, it is a great terrain improvement at no additional performance cost.CTDs could be caused by a number of LOD mods, but I suspect one of the bigest culprits is Vurts 4k LODs in his "Regular" versions of SFO. Simply use DDSopt to reduce to 2k or 1k. There is no detectable loss in quality. Don't sac Skyrim Distant Waterfalls though. Vurt's Regular versions - the diversity plugin could cause issues as could the inclusion of many custom grasses and iMaxGrassSize(?)=6+ Sticking with Basic version (with 183 patch if you don't like the brown tundra grass) will be the best performance for quality tradeoff.

Quality Snowflakes is pretty unnecessary, IMO, and it costs performance-wise.

I moved it to "Smile's Weather and Lighting", since "Pack" is redundant with the Pack namespace ;) all previous redirect to the new page @prod80 A bit blurry, but the lighting is very accurate

Since this is a WIP, I suggest creating the initial Pack page using the form ... we could use feedback on that implementation!

I suggest renaming this Pack to something more specific ... for example: "Goodness Weather & Lighting" ... but use whatever you ant "Weather" is too general ;) it looks good!

@Smile44 Are you using Firefox? I have noticed some inconsistent behavior with the popup form in Firefox. This is the form used for editing the already-created pack page (when you click the button to "Edit Modlist"). Other browsers seem to work fine. FF still works, but it is not consistent. I think it is the js. Changing the Pack name is the same as changing the page name, which is the same as moving the page. Moving any page in the wiki is as simple as using Page Tools > Move.

I'll look into it .... It could be a DDSopt issue, since I optimized all of them prior to repackaging the mod. In the meantime, you can download an older version and replace that one texture to see if it fixes.

Agree with the previous posts ... several changes this mod makes are good ones; however, my main gripe with this and many mods like it are that they are difficult to use --and more importantly for this project-- they are difficult to recommend. The changes are not consistent and it is a mosh of many different potential mods. I prefer that authors keep things separate and devote more time to the description and intent of each separate part. That makes choice and comparison much simpler for our purposes. Otherwise, I think mods like this should be served up as a modders resource so that sombody else can package the pieces with more consistency.

Sounds very interesting. I am not really a fan of most sound mods, and vanilla sound needs a lot of work ... sound is waaaay overlooked in most games. I guess most people need to be blind to see that ;)

Better idea: You and isoku team up and combine your favorite aspects of both mods to yield a single, consensus overhaul with options only where absolutely necessary Hint: this sort of thing is what the consortium is for ;) Both mods have some stronger points that the other, and the water overhaul is a giant undertaking that really deserves a specialized, team approach. You could likely spend all of your modding time on this alone with valid improvements (e.g., like Vurt and foliage) EDIT: I agree with your approach to INIs, tech. there is no other way to guarantee consistency unless it is known that certain INI settings are best and should be used by everyone.

Actually, the value corresponds to 128 KB, and I have not a clue about what it does or does not do (and I am fairly certain that nobody other than the programmers really do).

Tech fixed this This has also been fixed thanks guys!

Yep, we are switching to Google Drive, since it is 15 GB free to start. Used your other email though.

This sort of problem is a known issue, but it is more to do with the way Skyrim treats texutres that with DDSopt. DDSopt is simply maximizing efficiency by reducing the monochromatic compressed texture to 1x1 uncompressed format. Unfortunately, the game engine does not necessarily know what to do with that. I am not sure what the technical reasons are, but we can sure add this to the INI or the wiki. Kelmych has experience with this mod and DDSopt, so I'll defer to him.

Agree, good info should be written up in the wiki ... by someone. Just create it and it will be prettied up by ... someone else. ;)