GalenZ

Re: Fixing Iron tempering when using CCOR and Ordinator: For people who don't have or want to use Ordinator respec potions, and are comfortable with editing things in TES5EDIT, a quick and dirty fix is to create a CR patch that alters Perk xx0566EE <ORD_Smh00_SmithingMasteryNew_Perk_20_OrdASISExclude> from Ordinator.esp, changing the EFPD Float Value at the bottom of the perk from '2.0' to '1.0'. This will prevent the double-doubling of damage values when tempering iron, but will NOT alter any already-tempered weapons, will not prevent you from taking the (now useless) second level of Smithing Mastery, and will not give you back a perk point if you've already taken that second level. I would also like to note that I discovered this bug because the Eastern Iron Wakizashi from Lore Friendly weapons was given a damage rating of 10, equivalent to an Elven sword (for a weapon that takes only iron to create and temper, and should only do dmg 6 or 7 at most). With the quadruple tempering improvement, those cheap wakizashis were totally outclassing even Legendary Daedric swords in my build, which I thought was really immersion-breaking. Looking at LWE more closely, I discovered that, in general, it creates slight overpowered +1 variants of vanilla weapons, but the Eastern Iron Wakizashi was by far the most balance-breaking. This probably ought to be addressed in the SRLEX LOTD CR.

I wouldn't delete the temper perks in CCOR - Odinator's Smithing Mastery actually redirects to vanilla Steel Smithing, and CCOR adds lots of logic to that perk to handle all the new WAFR/CCOR weapon keywords and prevent double-tempering of weapons of weapons with two keywords (e.g. as occurs in Lore Weapons Expansion), so I suspect that altering that would mess up lots of stuff. As for deleting the second level of Smithing Mastery in Ordinator, yes, IMO that's the way to go if you want both - but as I said, it needs a patch. I just wanted to make people aware of the problem.

Just a note on a bug when using both CCOR and Ordinator: if you take both levels of the base 'Smithing Mastery' perk, you will be able to temper iron/hide items twice as much as you're supposed to, which means that at 100 smithing skill, your tempered iron weapons will be better than steel, elven, and even ebony weapons. The reason for this is that both CCOR and Ordinator fix the vanilla bug of not being able to temper iron stuff, but using different perks, so you end up with 2 perks giving you 2x improvement, for a total of 4x. For more details, see: https://forums.nexusmods.com/index.php?/topic/3253679-ordinator-patch-for-weapons-and-armor-fixes-remade-and-complete-crafting-overhaul-remade/?p=43223690. Until a patch for this comes out, the 4x bug can be bypassed by chugging an Ordinator perk respec potion, and not taking the second level of Smithing Mastery. The first level will give the CCOR Steel Smithing Perk, which already fixes everything the 2nd level of Smithing Mastery also fixes.

Just this morning, I had a similar problem - coming near Whiterun caused a repeatable CTD. However, Crash Fixes caught it and pointed me to a bad LOD mesh, which I discovered was actually missing. Somehow, my DynDOLOD resources merge had vanished, along with all it's meshes and textures. Rebuilding the merge and then DynDOLOD it fixed my problem. I find it odd that Crash Fixes isn't catching anything. Have you *ever* had Crash Fixes catch a CTD? Do you have the latest version? Have you set all the right options in the ini - most notably, UseOSAllocators=1 and RecordCrashInfo=1? Keep in mind that silent CTDs are a norm when SKSE runs out of memory, or a SKSE dll is the source of the crash. If I was in your shoes (and I have been, many times), I'd make sure CF is up to date, try to repeat the CTD, and see if it gave me a clue. If still nada, then I;d go through the install guides with a fine-tooth comb, seeing if I missed anything, or have something out of date. Finally, if still nothing, I would create a new profile in MO, reinstall everything according the the guide, and test that the build works after the full SRLE build, then again as I added stuff from this guide. BTW, DynDOLOD's MCM meuu will give you up-to-date info on your position in the world, and what's loaded. If you have a repeatable CTD at a location, then go into DynDOLOD MCM just before you get to that location, and note stuff down. At the very least, that will give you (and anyone who wants to help you) a target location to reach in order to try to re-create the problem.

I'm running out of VRAM, and would like to reduce my usage. I've already installed 1K instead of 2K textures for pretty much everything I can, and am building medium DynDOLOD, but I'm concerned that the latest flora and EVT stuff is more expensive than I need. I'm not fully up to speed on the ramifications of all the EVT and DynDOLOD options in this guide, having been mostly just following directions, but I would like a better understanding. So, could anyone suggest some alternative install options for EVT and DynDOLOD that will save me RAM - and the implications of those choices? Specifically, I want to make sure I'm not using 3D LODs and other high-cost stuff. Frankly, I don't care much how trees look in the distance, so long as it's not horrible - I just want to stop stuttering every time I turn around or enter a new cell.

The current 1.04 version of NPC Retextures Merged needs some cleaning, as it's overriding a lot of stuff from RDO. Just a basic TES5EDIT clean took out a bunch of records, and much of the Dialog Topic section (which is not touched by TES5EDIT cleaning) is identical to Skyrim.esm, with all the rest having small changes that are carried forward by RDO. In any case, the guide should have a LOOT rule for Relationship Dialogue Overhaul.esp LOAD AFTER NPC Retextures Merged.esp.

Why does the latest 1.28 Conflict Resolution patch still have the SilverPerk zeroed out? Shouldn't that record have been removed when BYS was taken out?

Actually, the NPC makeovers pulled together in this build get pretty close to that already, IMO. I was trying to mix and merge the same sort of thing earlier this year (before being distracted by FO4) and was delighted to comone back to Skyrim and find that it had already been done for me! The trouble is, there can never be 'the One' overhaul for anything, because there is a constant tension between 'making it look great' and 'making it able to run on most people's systems'. And, of course, people's tastes differ, especially on things like NPC appearances. I think the best we can hope to do is present modular alternatives that meet different goals - e.g. the quick-and-easy NPC overhaul, vs all the Bijin pretties. And kudos to the creators of this guide, because I think they're doing a wonderful job at that!

I prefer RSChildren. IMO, the point of this guide is to make Skyrim look great, and RSC looks much better to me. Also, given that people need to do an SRLE build before adding this onto it, I think the 'simplicity' argument favors keeping RSC. I can guarantee that if you took it out, lots of people would be adding it back in on their own. Perhaps you could do much the same as you're doing for all the other beautiful NPCs - present the base install and then a variation?

Absolutely. Jorrvaskr No Silver just replaces object refs, and has no dependency on BYS. I'm certain because I just installed it and looked at it in detail before merging it, and I no longer have BYS in my build.

Is anyone else having trouble looking at www.modwat.ch? I'm tried to look at Darth's load order, and I'm getting back 'www.modwat.ch’s server DNS address could not be found. ' UPDATE - Problem solved: Old link in Darth's (and other people's) sig is the culprit. The link in Darth's sig is still 'https://www.modwat.ch/u/Darth_mathias' , which fails. Whereas, whereas the new link from the main page is 'https://modwat.ch/u/Darth_mathias' which works just fine. I must have missed the announcement about the URLs for modwat.ch changing. How did people find out?

I understand re: older patches - you wouldn't want to keep everything. But you can always create a second mod page for older things, so as not to clog up the current stuff, and you don't need to keep everything - just say, the sets of files for major 'stable' versions.

Re: The new Dreadflopp's patches, and any new non-Nexus patches that may be created. Could I request that you add either version names or dates (preferably both) to the file name of any direct-download patches you create, so that we can tell different versions apart, and be able to tell when they've changed? Also, can you keep old versions available, so those of us who want to build an older version of build (e.g. 'before the next round of landscape changes') can get the older patches? Or better yet, put them on the Nexus. Or won't Dreadflopp allow that?

Bug in merging: Putting all of Dreadflopp's patches into a merge is a bad idea, because several patches modify the same level lists, and merging does not combine level lists the way Bash does - it only uses the last one. Specifically, only the following esps contain non-level lists data, and can be merged: SRLE__MUS__CCOR New Recipes__WAA.esp SRLE__MUS__Lore Weapons Expansion__WAA.esp They need to be LOOT ordered after WAA Merged Patches.esp, no matter what. I personally would recommend putting them into their own little mod, and merging them as the last things in WAA Merged Patches. Whereas, the following esps contain ONLY level list data, and thus can be merged and disabled automatically by Bash. There is no need to use Merge Plugins on any of them, but you should set Bash DELEV and RELEV tags on them: CACO_3DNPC_Patch_lvl list.esp ----\ CACO_GrayCowl_Patch_lvl list.esp ---- these two mods edit the same leveled list, and so should not be merged together by Merged Plugins CACO_SkyTEST_lvl list.esp SRLE__Lore Weapon Expansion__aMidianBorn_ContentAddon__MUS.esp SRLE__Lore Weapon Expansion__MUS.esp I'm looking at those patches in TES5Eedit, and it looks to me like CACO_SkyTEST_lvl list.esp is totally redundant - it just duplicates the lists already in CACO, and it's removal of the 'Use All' flag on a few lists seems both wrong and useless, as Bash restores the UseAll flag from CACO on those lists. Can someone else take a look at this and make sure I'm understanding things correctly?

You're running out of memory. If you set your DefaultHeapInitialAllocMB=1024 in skse.ini, then your maximum memory size is 1024 for both heap blocks combined, and thus only 768 in heap block 1, because 256 is allocated for heap block 2, and 1024-256=768. I recommend that you use the memory tweak in Crash Fixes, as specified in the SRLE install guide, instead of tweaking skse.ini.

Just found a bug: 'Patch - Interesting NPCs - RS kids.esp' has some bad records in Odette3DNPC's packages, which can be easily found using Check for Errors in Tes5Edit. Somehow, this wasn't caught by Merge Plugins - but it caused a bad merge on that record. At least, it did for me, and I'm pretty sure I had the latest version of that patch (which is from July 2014, so I'm not surprised if it got out of date.) Could someone else verify this problem, and perhaps a note to fix that esp be put in the guide?

Can we get a list of the meshes that need to be healed, so we can fix just them?

https://github.com/GandaG/spluff/releases/tag/13 from https://forum.step-project.com/topic/11199-spluff/

I'm still having a CTD when fighting frostbite spiders in my test, and an suspecting a bad mesh somwhere. Looking at the Spluff forum, that led me to NifScan and Nif Healer. I've never used any of these tools before, and the documentation on them is ... eclectic, to say the least. Can anyone give me (and others) some pointers of how to use them to, say, check for and fix bad meshes?

Just started doing this myself, so I have a newbie's perspective on it: 1. The quick and easy way - use Optimizer Textures (Ordenador), with updated ini from either Ordenador.ini Optimizer Textures .ini (newer) or Texture Optimizer Modified INI and HOWTO use Guide (which is worth getting for the guide). Really simple to use - just point it at a texture folder (preferably a copy of the originals) and tell it to reduce size to 1K or whatever. Issues: Will only reduce size by 1/2, so if you want to reduce 4K textures to 1K, you have to run it twice; compression and resize algorithms are sub-optimal, which is fine for landscape and weapons and armor textures, but dicey when using them on body skins; and it's 'one size fits all' regarding textures, whether they're normals or skins or whatever, which is again suboptimal. Upshot is, it will reduce sizes, but you may not always like the results. 2. The right way: use DDSOpt, which is the tool that SRLE uses (see SRLE Guide, STEP Quick-Start Guide, and main STEP Guide). Pros: much finer control over processing, better compression and size reduction algorithms, resulting in better textures. Cons: it's a complex tool that requires you to actually read the manuals and make sure you have your settings right before you start it up. See the DDSOpt Forum for more info. Either way, the safest way to resize textures is to create a copy of a mod in Mod Organizer, then letting one of those tools go to town on its textures (RTFM first, and do it OUTSIDE of MO), activating the new reduced-textures copy of the mod instead of the original, then getting back in the game and see if you like the results. If yes, fine. If no, you can always go back to the original or try again with different settings, without having ever touched the original mod. Personally, I just used DDSOpt to reduce the 4K skins of various generic followers to 2K, and am quite pleased with the results - 1.65 Gb of data vs 3.85 GB in the original, reducing both my VRAM and SSD usage, and I can't see any visible difference in the skins. I'm *very* happy that I've learned to use the tool.

Image: https://drive.google.com/open?id=0BxGMkSglbFzAU0FXX2hYSUJETG8 I'm using DDC2 Deadly Dragons Patch v2.02, dated 26 july, on https://www.nexusmods.com/skyrim/mods/76750/? and No Dragon LODs - SRLE ExtendedLOTD v1.01, dated 16 aug, from https://www.nexusmods.com/skyrim/mods/77331/?

Really? Then why does USLEEP set them? I thought they were used for things like setting a cell's encounter levels, location name in a save, etc. As opposed to LCTN records, and their sub-records, which in fact do NOT need conflict resolution, ref https://forum.step-project.com/topic/4468-tes5edit-which-record-types-dont-need-conflict-patches/

The reason I noted all the above problems is that I was debugging an unexpected animal-related CTD in my (pretty pure) SRLEX LOTD build. Specifically, when travelling along the main road just south of Morthal, I run across a couple of Frostbite Spiders on the road - and get a repeatable CTD as soon as they enter combat with me (e.g. spitting). Has anyone else had a problem like this? Any suggestions as to where to start looking?

Looking at things in xEdit, and came across some oddities with No Dragon LODs: 1. Why do we have both 'No Dragon LODs v2 full.esp' and 'No Dragon LOD - SRLE Extended LOTD.esp'? It looks like the SRLEX LOTD version overwrites some records in the base version, but not all. Why not copy the base records into the SRLEX version, and free up a load slot? 2. In dragons defined by ogDiverseDragons2.esp, additional VMAD data is added by 'ogDiverseDragons2 - Deadly Dragons Patch.esp' (from DDC2 Deadly Dragons Patch), but these VMAD values are not carried over into 'No Dragon LOD - SRLE Extended LOTD.esp'. Why not? 3. 'No Dragon LODs v2 full.esp', 'No Dragon LOD - SRLE Extended LOTD.esp' and 'ogDiverseDragons2 - Deadly Dragons Patch.esp' are all pure patches with no new records, and so can be safely merged. Why aren't they in the 'Animals Merged' merge? 4. BTW, record 00009772 in Animals Merged.esp does not propagate the XLCN Location value from USLEEP (though SIC does), and my LOOT sorts Animals Merged last, so that data is lost. This probably ought to be addressed in the Conflict Resolution.

I just noticed that 4.8.2.14 EotW The Dawnguard Textures Remastered completely overrides 4.6.1.8 Rustic Death Hound. I suspect that this is an error.