Pretendeavor

Try ExpandSystemMemoryX64=false (in enblocal.ini) + DefaultHeapInitialAllocMB=1024 ScrapHeapSizeMB=256

Well if both mods modify the same town I don't think there are many people that try using both mods at the same time. You can't blame the author for not putting it in the description just because ETaC is popular, but it is interesting that no one has mentioned it yet I guess. Mostly whenever a new 'big' mod comes out one of the top 5 questions is 'is this compatible with ETaC'? :p

Hmm didn't know about the windowed vsync.. I always disable Aero hoping to get better performance

I don't think you should focus on realism so much tbh. I also don't believe that a single mod (except bug fixes) is 'vanilla-friendly' simply because.. its purpose is to change the vanilla game! As for lore-friendliness.. I don't think it applies that much to perk overhauls unless you get perks that summon guns or whatever. I've played games like Guild Wars (1) where you are limited to a set of 8 skills at a time. Builds are very important and in pvp level does not matter at all. I feel a lot of ideas in this mod are inspired by other (MMO)RPGs and don't necessarily 'make sense' from a realistic point of view, and imo they do not have to. I think the idea is to supply a number of interesting and different perks, but it is up to the player how exactly he makes his 'build' and comes up with creative ways to make perks work with each other. This mod is made with the vanilla perk gaining system in mind (he stated he doesn't like using the Uncapper) so the amount of perks you'd get is pretty limited compared to SPERG for example (which gives you a ton of 'passive' perks without spending points). The idea is not so much that you just stack perk upon perk upon perk and get severely overpowered in the process (although I assume you have to take some perks in order to gain access to others(?)). Compared to online RPGs, Skyrim can easily be 'scummed' anyway if you choose to do so (save/load pickpocketing, abusing AI etc). Basically you have the choice to be as OP as you yourself want to be. As The Wind plus Cripple for example can result in a hit and kite kind of play (with perhaps light armor perks). With Hawk's Perch plus Oath Shot you can weaken opponents before finishing them off in melee combat (so you can invest in some melee skill trees and possible in blocking/heavy armor). Powershot + Takedown seem perfect for making builds that aim for critical hits (perhaps they synergize well with perks from other trees). I have not played as an archer with this mod myself but to me it all looks very interesting. That said, I have to agree with you on the increased damage when the target is at full health. When playing as an archer without any followers, your targets have no reason not to be at full health until you shoot them.. Seems a bit too strong. Again, I have not playtested it. But I'd think a nice replacement perk would be an increased critical chance/extra damage when their hp is below 25 or 50% (some sort of finishing move). Deadeye also seems a bit weird unless maybe your previous three shots have succesfully hit a target beyond 25 feet. Perfect Draw is the only one that really doesn't make sense to me. So yeah in conclusion I love the potential of these perks compared to vanilla. There are also two options available now: version 1.04 (a general nerf because of people complaining about it being OP) and version 1.02x (not nerfed, but has the bugfixes included in 1.04). I think both will be maintained in future updates. You can pick one and try to balance your own game, be it through global difficulty, SIC, ASIS, High Level Enemies, OBIS, Combat Evolved, Deadly Combat, Action Combat etc. I understand that it is tough to recommend this for inclusion in STEP, but I can see it being a potential candidate for packs that go beyond STEP:Extended

I'd say after the ELE plugin and before the Bashed Patch. I use some custom plugins and rules, but I think enabling Global Priority and setting it to 990200 should do the job. Basically a value between 990100 (ELE) and 991000 (Bashed Patch). If you don't want to deal with Global Priority you could also just make a rule that says After ELE_Legendary_Fs_Wt_Lite.esp and hope it gets placed before the Bashed Patch :p

Performance might be a bit bad and lods might not be top notch, but my god this mod is beautiful. I haven't become Arch Mage yet, but I couldn't resist coc-ing there to take a look. I just spent an hour making screenshots of perhaps two towns and a little of the area in between. Not sure how well it'd fit into the packs hosted here but I'd recommend just downloading it to appreciate the eye candy :p I recommend using SFO, SFO on steroids (optional) and Unbelievable Grass Two along with it, in that order. Don't let summersetisle.esp overwrite grass changes, crank up ENB and ini settings and enjoy the scenery :D

It's most likely highly compatible because it's in a new worldspace

The 'Lightning Bolt issue' is just files overwriting each other. If you look at the 'Conflicts' tab of a mod you can see what files it overwrites (+) and what files get overwritten (-). Not sure what guide you followed (I assume the latest STEP release), but if you followed the guide to the letter I assume your mods are installed in the correct order in MO's left pane, and any overwritten files are intended. In this case you can ignore the lightning bolts. Basically it provides an easy way for you to check how a newly installed mod conflicts with previously installed mods. For example, a texture replacing mod will most likely always have a 'lightning bolt' with a + sign next to it. You can then check which textures it is overwriting in the Conflicts tab. Both the overwritten file and the overwriting file still exist in their own folders, but only the overwriting one will be used by the game. I hope this made it clear :)

I just downloaded this and checked for possible conflicts. One thing that I noticed was that the BSA file contained many lod textures and meshes that overwrite Vanilla Optimized, DynDOLOD, the USKP, Vivid Landscapes and maybe other mods. I have MO manage archives as recommended in Skyrim Revisited: Legendary. For this particular mod, does that mean that you should not unpack the BSA? I already saw a comment from Sheson on the Nexus page in which he said you should not let this mod's lod files overwrite DynDOLOD, because DynDOLOD has many improved vanilla assets. It also contains what I'm assuming are vanilla lod meshes that don't directly show as conflicted in MO's Conflicts tab, because I have never unpacked vanilla Skyrim BSA files. So I fear hiding all the lod files in the Conflicts tab still doesn't solve everything. I'm unsure about priorities when it comes to this.. but if you keep this mod's BSA unpacked it should have priority over the vanilla Skyrim BSA files, but not the loose files in MO from mods like Vivid Landscapes and DyndoLOD, right? Is this the best outcome? - Also, there is another small thing. Under 'Texture Set' there are a couple of records called LandscapeCoastBeachDUPLICATE002, LandscapeFieldGrassDUPLICATE003 and a few others. If you use mods like Verdant or Unbelievable Grass Two some of their 'Landscape Texture' records conflict. It also makes some changes compared to Skyrim.esm. The author of Summerset Isle already posted a comment saying that you should load any grass mods after this one if you want to keep their settings. To me it seems like these DUPLICATE002 records don't serve much of a purpose though.. They don't seem to change anything compared to vanilla. For example in Skyrim.esm the Landscape Texture LDirt01 points to the Texture Set LandscapeDirt01. LandscapeDirt01 then points to \Landscape\Dirt01.dds and Dirt01_n.dds. This gets overwritten by summersetisles.esp: it now points to Texture Set LandscapeDirtDUPLICATE002, which also points to \Landscape\Dirt01.dds and Dirt01_n.dds. Does this serve any purpose? It seems to me that instead of bothering to mess with load order you can also delete all the records from 'Landscape Texture' EXCEPT LSummersetSand01. Or would this break all kinds of things? :s

Before this gets generally accepted I would like to post my results here. I actually seem to get increased instability with these settings compared to the the same settings with ExpandSystemMemoryX64=false. I have a pretty heavy mod setup so regardless of the ExpandSystemMemoryX64 setting I expect to eventually either CTD, freeze or get an ILS with DefaultHeapInitialAllocMB of 768 because Block 1 will hit 512. With ExpandSystemMemoryX64 set to true I think I DO get significantly more CTDs. I say 'significantly' here because I believe this is not coincidence anymore, although I obviously didn't use any statistical methods to completely rule out coincidence, nor did I test this 100 times in a row. I did use Memory Blocks Log and CTDs consistently happen before Block 1 reaches 512. - To confirm this I just ran a couple of tests again while writing this post, using the Alternate Start mod to start a new game and walk around in Solitude, Whiterun and the Solitude Docks. I have the SRLE and REGS packs installed, except switched out JK's Skyrim for Dawn of Skyrim. All resulted in CTDs, two of them right after a loading screen. The maximum values for Block 1 as reported by Memory Blocks Log were 472, 487 and 478 respectively. Note that none reach the maximum of 512 but are strangely close to each other. With ExpandSystemMemoryX64 set to false the CTDs occur less often. Again I started in the locations mentioned above. The first resulted eventually in a frozen screen, the second and third in a CTD, but it took a lot longer. What's more, in all three occasion the maximum values for Block 1 (512) were reached. What I'm trying to say here is that I feel that in the last three tests problems are purely caused by Block 1 hitting 512. It gets fixed by increasing DefaultHeapInitialAllocMB accordingly. In the first three tests however there seems to be something else going on, possibly the same strange interaction between the memory patch and the ExpandSystemMemoryX64 setting keith is speculating about. So his assumption that the interaction only occurs with a DefaultHeapInitialAllocMB setting > 768 might be false: to me it seems like it can also happen with a effective Block 1 allocation of 512. - Based on the info keith provided us and my own experiences, I think it is informative to include a Memory Blocks log file when reporting this. The reason that some people don't experience any trouble with ExpandSystemMemoryX64=true while others do, even if both parties have determined that a DefaultHeapInitialAllocMB of 768 should be sufficient for their setup, might be because of a difference in how high their Block 1 values reach. Lastly I also realize that I might be completely wrong on this. I would however like to see results of people that have their Block 1 values come close to 512 but not so close that they hit it, comparing ExpandSystemMemoryX64=true vs ExpandSystemMemoryX64=false.

If the wagon scene is bugging you might have your fps uncapped and vsync off. Skyrim bugs out when the fps is higher than 60. Also, don't start with setting it to 1280, more isn't always better. As I said, use Memory Blocks Log to determine the perfect value for your setup. Be sure to read its documentation. If you don't want to do that, start with 768 and increase with increments of 128 or even 64. I can't help you with the benchmarking, sorry.

Did the problem also occur with a completely new game? Starting a new game after installing so many mods is usually recommended. The next step would be adjusting the DefaultHeapInitialAllocMB value in your skse.ini. If you have followed the guides you should have this set to 768. For a setup with so many mods that might not be enough, and it results in infinite loading screens. Try setting it to 896 en leaving ScrapHeapSizeMB untouched (256). In enblocal.ini, make sure ExpandSystemMemoryX64 is set to false. Then try loading your saves. If you still get ILS, set DefaultHeapInitialAllocMB to 1024 and try again. This number can be set to anything (with a maximum of 1280 I believe) and I'd recommend looking into Memory Blocks Log to tailor it for your own setup.

You really are bored aren't you :P

In case you guys need some more user reports.. I can confirm increased instability (CTDs) with ExpandSystemMemoryX64=true and the SKSE memory patch >= 768. Because of SR:LE+REGS+Dyndolod I use higher values than 768 and keep crashing unless I set it to false.

No.. The newest SkyUI just gives an error every time you open the map. For now you can disable this error message by going to the SkyUI MCM -> Advanced -> SWF Version Checking -> disable Map Menu.

"+" is just 'plus' :P And hover over IIRC with your mouse, it will show what it stands for ;)

I don't know about the installer but you shouldn't skip over it if you have only Skyrim Revisited installed! I started this topic for people who use both SR:LE and REGS at the same time. As for how crucial it is to SR.. Well, the SR Conflict Resolution patch has it as master, so you can't use that unless you manually remove the patched records from it. Gameplay-wise, I don't know, it has only recently been added. Everyone seems to agree on the fact that this mod really enhances your Skyrim experience though. Rather than skipping over this mod I'd recommend skipping over JK's towns in favor of Dawn of Skyrim for now. I also decided to keep my ETaC (no-inns) install and live with the incompatibilities until ETaC gets a patch. Not sure how bad it clashes in game, to be honest I haven't played much since creating this topic because I grew a bit tired of all the problem solving (which is pretty much the story of my attempt to create the perfect Skyrim - sigh - )

I'm often wondering about this too when manually trying to patch things. I mostly ignore it.. (out of ignorance) I noticed the creator of WAF is relatively active on these forums, perhaps they can chime in here.

I think the reason that the ETaC patches needed their masters 'esmified' is because the CK doesn't accept esps as master files. You circumvent this problem by temporarily converting them to esms. If your files have no esp as master I'd assume you can simply open the merged patch in the CK and save it. That's how I understood it anyway

I'm not sure what to call it. The method ENB uses to avoid hitting Skyrim's memory cap. I think you can notice the difference if you set EnableSpeedHacks to True. With this enabled you will notice it will be much smoother but at a certain point it'll just crash because I believe there are no enbhost.exe processes 'spawned'.

Might it just be that Vividian has pretty low quality settings in enbseries.ini compared to a lot of other presets out there? I think its SSAO settings in enbseries.ini are set lower than any Grim and Somber performance preset for example. I don't much about the code behind it though x] Also, are you sure it isn't just Enboost's data migration causing stutters?

No, also the placement of a couple of objects and markers

It depends on their timings, 1866 isn't per definition faster than 1600. My personal experiences led me to believe faster RAM will help in Skyrim with CPU heavy tasks like drawing shadows in cluttered areas. I noticed an increase of about 2-3 FPS max in 'problematic' areas in JK's Cities after OC'ing my RAM from 1600 CAS 9(-9-9-24) to 1866 CAS 9(-10-9-27). In other games it might be negligible. At least, that's what 80% of the internet seems to agree on. I've had it at 1866/10 before but the difference between that and 1600/9 was not very noticeable and not worth the OC imo. I feel that the comparison between 1600/8 and 1866/9 in your case might be similar to this. You could do some more research and compare (gaming) benchmarks.. Or you could just base it on the reviews (5/5 (67) for the 1866 set vs 4/5 (20) for the 1600 set) and go for the 1866. Orrrr get the 1600 and save yourself just enough for a 6-inch chicken & bacon ranch melt at Subway! Anyway.. As for compatibility, you could search for a RAM compatibility list for your motherboard. However if the motherboard is fairly old, it might be that the list hasn't been updated in recent years and therefore doesn't include the two sets listed here.. I'd google the model names of your motherboard + these sets and see if any other people have tried this combo. I have no experience myself with installing RAM on a motherboard that doesn't officially have it listed as supported so I don't know how much of a risk it carries. If any. Same goes for GPU compatibility. I recommend searching for and reading about these kind of things for yourself, even if you are a novice. Especially if you are a novice AND plan on building/replacing it all yourself. I've only built one system before in my life and replaced things only once or twice but I spent hours of reading before doing it and I'm glad I did!

I noticed this a couple of times too, I'm suspecting this might not be a DynDOLOD issue but rather some form of optimization of the first couple of minutes of the game? This is because I feel that stuttering/FPS drops are minimal or even nonexistent during the whole carriage ride and dragon attack even with a lot of high res texture replacers, while in any other exterior area I get slight stutters when resources load. I can't remember if I had DynDOLOD active the last time I did the intro though

Good to hear you figured it out :D And yeah that might prove useful for the next guy that comes across this problem. Your experiences might help them out :) EDIT: Didn't see your most recent post when I wrote this. About the renumber FormID issues, I think this was mainly a problem with the older Merge Plugin Scripts. The latest versions shouldn't have issues as long as you have set your options like this: https://wiki.step-project.com/User:Neovalen/Skyrim_Revisited_-_Legendary_Edition/Mod_Merging This makes sure it only renumbers conflicting FormIDs I know SR:LE doesn't include ETaC but I have merged a lot of ETaC plugins with these settings (all up to date) and the game starts just fine