Nearox

As the others mantioned here, I would do a clean start and do STEP Core. Some of the mods you have in that list haven't been updated for a long time and better alternatives are there. STEP Core will guide you in detail to have a stable good-looking game.

Stuck as in, screen freezes and you cannot do anything? That could still be related to incorrect SKSE settings. Pleade do post memory blocks log so we can verify :)

Those mods are in SRLE, so yes :) I've experimented here and there with some MMO mods but haven't done a playthrough with any of them.

Well you could always just download the provided esp :)

With regards to grass, did you have the parameter iMaxGrassTypesPerTexture=7 in your .ini under Windows 8? The lack of that would explain the missing SFO flora.

I haven't examined that specific conflict but I think that Oblivion Gates should only edit the navmesh a little bit just so that NPCs wont get stuck there or try to run through it. I'd say let CRF win the conflict entirely since CRF might have new triangles in that cell needed to e.g. access buildings etc. I'd suggest to do a simple test. Go to the cell in question, spawn 1 or 2 followers and run around the Oblivion Gate for a few minutes, trying to get the followers to cover all the area. If it doesnt crash then there is most likely no problem :P Well except from the (probably minor) chance that the follower gets stuck.

No that parameter is no longer necessary since the memory patch has been integrated into SKSE. Can you install Memory Blocks Log and post the report here after stress testing the game (i.e. until it crashes)? You can find the log in MOoverwriteSKSEPlugins folder.

Thank you raulfin, greaty work you guys are doing as always.

Hmm, do you have the SKSE scripts installed that came with the SKSE zip file?

Okay, can you try with UsePatchSpeedhackWithoutGraphics=false? If it works with setting it to false, then you are probably missing some enb files and can best reinstall the enb preset plus redownload the newest version from enbdev.

Is enbhost.exe present?

Thanks for your consideration :) Now that I have thought some more on it, maybe it helps if I try to illustrate what I have in mind in more practical terms with regards to the linkage between the ToC and the wiki interface for authors. At the wiki interface (i.e. the edit with form screen) remove tabs 2, 3 and 4. Remove mod tables. Below is a list of suggestions with new tabs to be created at the wiki interface for authors. (Each tab corresponts to the number of the list below) Pack Attributes Remove required packs, compatible packs, required DLCs Author(s): Names put in here should ideally result in a link to the user's profile at the forums. Title: The title put in here should be aligned to the centre of the actual pack page, below the information box (which has author name, forum thread link etc.) Description: The text put in here should not end up in the dark box at the top of the pack's actual page. Instead it should be centered under the information box. Also rename this field to brief summary and provide a note that it is best to do keep it short (like 3-5 lines or something).Introduction The section should, when filled in by the author, automatically result in the creation of ToC chapter 1. The text and title of this section, just as any of the next sections, should be aligned at the left. A default text block suffices (basically same as you have now in the tab 'pre-installation texts').Required Tools The section should, when filled in by the author, automatically result in the creation of ToC chapter 2. Since the tools available are kind of set in stone, you could make a list of tools and make them selectable. Basically just like you can now select "Compatible packs" at the Attributes tab.Pre-Installation Setup The section should, when filled in by the author, automatically result in the creation of ToC chapter 3. A default text block sufficesMod Installation The section should, when filled in by the author, automatically result in the creation of ToC chapter 4. Each mod should have fields for name, description, author and version. These fields should be put out in proper format to the actual pack page. Filling in the name field should automatically results in the creation of ToC chapter 4.1 or 4.1.x etc. Each mod should have a blank text box, which the author can use to specify special instructions. There should be a field for filling in the mod's nexus link. At the actual pack page, clicking the mod's name at the page should result in opening a new window to the nexus mod page.BOSS/LOOT Rules The section should, when filled in by the author, automatically result in the creation of ToC chapter 5. A table format would be ideal here. Don't make it complex. Author can fill in table contents himself and also link to mods itself. Imo it is really best to have all these rules in one place instead of each individual mod.Compatibility The section should, when filled in by the author, automatically result in the creation of ToC chapter 6 A default text block should suffice.Conflict Resolution The section should, when filled in by the author, automatically result in the creation of ToC chapter 7. A default text block should suffice.Merged ESPs (or name it Other Post-Installation instructions or something like that). The section should, when filled in by the author, automatically result in the creation of ToC chapter 8. A default text block should suffice.Final Steps This section should, when filled in by the author, automatically result in the creation of ToC chapter 9. A default text block should suffice.Changelog. This section should, when filled in by the author, automatically result in the creation of ToC chapter 10. A default text block should suffice.Credits This section should, when filled in by the author, automatically result in the creation of ToC chapter 10. A default text block should suffice.Hope this provides some more concrete ideas. I guess incorporating the ones I have about the mod section would be most work, but also most important :P Oh yeah, did I mention to get rid of the mod tables? Get rid of them.

I'm happy this thread has been opened. I'll also share some of my thoughts on the subject to brainstorm some ideas. I have this thing of wishing to much once someone throws a bone, but here is my write up of things I have had in my mind since I started working on packs 8 months ago: Mod Tables Mod tables are not really useful for pack authors and users alike. They are often more of a hindrance than a convenience. Smile44 already mentions one point, namely that the table format just does not allow to provide sufficient space. Cramming the space with information will quickly lead to a loss of overview for the user. Most packs will be relatively small, so there is no need to compress the information via mod tables as all the information is just a few mouse scrolls away anyways. Descriptions and instructions under the mod's name suffice for both authors and users. Whereas STEP can put detailed instructions at the mod wiki page, packs often do not have that luxury due to having one or more mods included in the pack that are already in STEP. The reason those mods are included in the pack is usually because they need different instructions or additional patches specific to the context of the pack. Not to mention multiple packs can use the same mod, which means instructions just cannot be put at the mod's step-wiki page. Which also brings me to my next point. Having to add mods to STEP wiki (in order to be even able to add them to the mod table) is time consuming and basically a waste of time. I can understand the need for this for STEP mods, but it feels like a huge redundancy. Instead, make a 'mod installation' section as part of the table of contents (see next point) and standardize it. Each mod should at least have a description, author's name, version number at the top by default. Rest is up to author to fill in. Would be even greater if there are togglable options for mod cleaning/special instructions as many mods tend to require one of them. Table of Contents & General Pack Lay-out Table of Contents should be the foundation for every pack, and ideally be generated automatically. The wiki interface for authors should be built around this. I would argue this is the most crucial improvement necessary. It provides guidance to both authors and users. Without a table of contents, REGS or MMO (or also e.g. SRLE) would be a mess to navigate. Even smaller packs benefit greatly from this. The way I see it, every one of the more popular packs has basically mostly the same elements that make it a success for end-users: Brief summary. Introduction (explanation of pack concept). Required tools (like tes5edit, ddsopt etc.). Required pre-installation setup. Mod installation (largest section). BOSS/LOOT sorting order rules. Compatibility (this section usually mentions specific mod incompatibilites and potential solutions). Conflict resolution. Merging ESPs. Final steps. Changelog. Credits/thanks.My suggestion is to include a default table of contents so that every pack has a more or less uniform look. At the moment, everyone seems to use a different format/layout which means that when the user is starting to look for a pack to install, he or she can get easily confused and/or overwhelmed. Importantly, this also provides guidance for would-be pack authors and it might get more people to consider developing their own pack. It forces pack authors to think about the total package of things necessary to have a succesful end-result (like conflict resolution and compatibility). Table of contents does not need to be limited, of course. The more advanced pack author can still add another section, when needed, by simply copying the code. If/when you have decided on a default table of contents, you can design the wiki interface around it. Almost all of the elements (or call them 'chapters') can simply have a blank box to fill in (just like it is now with some current sections like pre-installation setup) except for Mod Installation (see point 4 of Mod Tables above). BOSS/LOOT rules could however be nice to have in table format. The end result should IMHO be a page layout that looks somewhat like SRLE/REGS. Easy and quick to navigate. Nothing difficult or complicated. Colorization and Font size One thing that really breaks a pack overview, or any webpage really, is the lack of visual distinction. Having to mess around with colors and fonts via BBCode is a chore for pack authors, and I guess the main reason why hardly anyone does it. CJ and I did it for REGS, but it was a hell lot of work - at least until CJ's CSS but after that some BBCode was still necessary. I'd suggest: Combined with a Table of Contents should come a uniform default color and font setup for colors and font sizes for chapter/subchapter headings, paragraphs, mod links, mod descriptions (e.g. bold, italized), author (bold/italized), version (bold/italized). Basically, a pallette baked into every pack page. Make lines under each heading, and have the line be a matching color for the heading but not the same color. The info section at the top left Remove Required pack, compatible packs and DLCs required . This is not necessary as it is usually explained by the author in the compatibiltiy section. Keep the forum thread link. Instead of one of the aforementioned, add a last updated notification in that box instead, showing when last edit was made. Also add option to list pack authors and provide direct links to their profile at STEP and/or Nexus. The description at the top Currently if you use the wiki interface and add in a description for the pack, it ends up in a box at the top (see e.g. Requiem pack). Personally I prefer it much more to be under the info section, but centered in middle just like REGS has it. You could instruct pack authors to try to limit this to 3 lines or so. When I go to the requieme pack, I basically skip over the description in the dark box because it is too much at the top and the contrast in colors between text and box is not nice. I have no idea if you have the time to develop anything like this, but my personal view is that this would greatly benefit both pack authors and end-users. The user wants simplicity and a clear overview, and the pack author does not want to waste time on layout, colors, fonts, bbcode, adding mods to STEP wiki, clunky mod tables and whatnot. That stuff is just distracting from development of the pack content itself. My 2 cents...

Yeah that's the one. Sometimes the shadow striping is caused by land shadows. Especially without ENB it becomes mroe noticable, so try it with that setting to =0 and see if it makes a difference.

The issue is actually described at the UDP nexus mod page. Basically you have a mod installed that modifies dragonactorscript.pex and/or mqkilldragonscript.pex. UDP is not to blame :) Edit: Did you also install the SkyRe patchs from here: https://www.nexusmods.com/skyrim/mods/48629/? They are an absolute necessity and include an updated version of the unofficial skyrim redone patch.

Have you already tried disabling land shadows?

Can you make some screenshots or a short video? It is hard to determine the issue based on your description.

Yep that's how you do it. Do note that the ENB you use might have an update to incorporate any new effects. By the way I don't think anything changed for enblocal.ini so you can keep the old one.

I can confirm this.

Oh gawd, you're right. Damn, second error I made in the guide :P And here I thought I was finished, hah. texturesactorscharactermaleoldmalebody_1_msn.dds >>> I actually have that DDSopted, just made a mistake and did not mention it in the instructions.DDSopt to Uncompressed (i.e. untick everything) 1024 x 1024​ texturesactorscharactermaleoldmalehead_msn.ddsDo not DDSopt this, texture size is already small​I'll update the guide now. Thanks for the report. ​

The problem with Dawn of Whiterun is that it is a bit more performance intensive, which is also the reason it got taken out of REGS some time ago as users were reporting issues. JK's Whiterun only seems to cost 1-3 fps, and then only in certain areas.

So I know you guys were talking about it some time ago, now I finally had a chance to do a decent try on JK's Whiterun and... holy **** this is it, the whiterun overhaul I have been looking for! One that is actually thought through and still sticks close to the original. Master piece of work. Not using Dawn of Whiterun anymore.

Are you on drugs?

@darkside: Not sure which area you are talking about now. But since ELFX 2.0, the start cave of LAL has a flickering light, so if that's what you are seeing, no worries as the rest of Skyrim shouldn't have it. @ everyone: I consider the main work done on this guide. If anyone has some suggestions or criticism please let me know. Would especially be glad to get some more feedback on the ENB settings. Doesn't mean I won't ever update it again by the way, but most of the tweaks related to mods are kind of set in stone and at the moment it doesn't look like SRLE will have a big texture mod added anymore (I included Stunning Statues in the previous update) as most areas of the game are covered. Also none of the REGS mods can be significantly optimized (apart from not installing them :p). Moreover, after following this guide you should be pretty well set to deal with optimizations by yourself :) In short, no longer a WIP but I will still provide support, of course.

You need to determine which esp is causing the CTD. To do that, open up all your esps from your load order in tes5edit. It should give an error message at the esp that is missing a master. MO tells you this too, by the way, via the red triangle with exclamation mark in it next to the esp name. ETaC by itself has virtually zero chance of causing such a crash as it should only have vanilla master dependencies, if memory serves me right.