Lexy's: Legacy of The Dragonborn Special Edition

[filiusDei]

One more question: the guide says for Wyre Bash: "A popup asking to deactivate mods prior to patching may appear. If a mod is marked "NoMerge", simply uncheck the box next to it then click [Ok]. This will deactivate the mod files not marked "NoMerge" and they will be merged into the bashed patch."

What does that mean? How can I find out if a mod is marked "NoMerge"? Wyre Bash is just saying that the following mods should be deactivated prior to building the patch. So I let all of them checked and also let the plugins, which are merged into the bashed patch, deactivated afterwards, right?

 

Edit: There's the following folder in the MO overwrite all the time: INI Tweaks. Anyone knows why?

Edit2: I've chosen to build the Bashed Patch without any merged stuff for now

Edited April 28, 2018 by filiusDei

[godescalcus]

One more question: the guide says for Wyre Bash: "A popup asking to deactivate mods prior to patching may appear. If a mod is marked "NoMerge", simply uncheck the box next to it then click [Ok]. This will deactivate the mod files not marked "NoMerge" and they will be merged into the bashed patch."

What does that mean? How can I find out if a mod is marked "NoMerge"? Wyre Bash is just saying that the following mods should be deactivated prior to building the patch. So I let all of them checked and also let the plugins, which are merged into the bashed patch, deactivated afterwards, right?

All mods that are tagged NoMerge show in purple on the mod list in Wrye Bash. Currently in this build there are none, unless you set the tag yourself. The normal behaviour is that Wrye Bash recognizes certain plugins that it can safely merge into the bashed patch. Those are listed in green. When you rebuild the bashed patch, it will ask you to deactivate those mods that will be merged, and this prompt does that for you automatically. Those mods will, then, be merged into the bashed patch and you won't have to reactivate them. When you quit Wrye Bash, it tells Mod Organizer about the mods you deactivated (basically because Wrye Bash manages the load order) and they'll also be deactivated in MO. No further action will be needed. But, if you had one or more mods tagged NoMerge (purple) they'll be deactivated during the bashed patch rebuilding process and you should manually reactivate them once that is finished. I'm not sure why you should deactivate those in the first place, if you want to know more about all things Wrye Bash I suggest reading the discussion at afkmods.com and posting any questions there.

[filiusDei]

I'm not sure why you should deactivate those in the first place, if you want to know more about all things Wrye Bash I suggest reading the discussion at afkmods.com and posting any questions there.

Ok, thanks. So I guess that it makes sense to create all the Merges from the Merge Page first, and then let Wyre Bash do it's job right?

[godescalcus]

Ok, thanks. So I guess that it makes sense to create all the Merges from the Merge Page first, and then let Wyre Bash do it's job right?

Short answer, yes.

 

Digression: I used to do a mix of both, in the case of merges that have mods that mainly merged into the bashed patch (examples: even better quest objectives, rs-children, most patch merges) I'd simply not make the merge and let those go into the bashed patch. It worked but I guess you lose some control over load order, since the bashed patch always gets loaded last. Even so, I think the merged plugins don't necessarily have their records carried into the bashed patch - if a later plugin that doesn't get merged has overrides, those will get carried in the usual last-to-load-wins way. Having said that, I tend to think it's best to do the merges as per the guide, especially since when using MO2 you don't use Wrye Bash's ghosting feature. That means the plugins you merge into the bashed patch will still be in the virtual data folder (but excluded from the load order because they're deactivated). Some people say the game can become unstable if you have too many plugins in your data folder, regardless of whether they're loaded or not. In that light, you should merge first, following the guide and moving the merged esp's into MO2's optionals - that way the are effectively invisible to the game, as they won't be in the root data folder, unless you want to go through the trouble of doing the same for each plugin that wrye bash deactivates.

[godescalcus]

 

What is the correct procedure to use both utilities? Run xLODGen and activate the output, run TexGen and activate the output, run DynDOLOD as instructed (objects, trees, everything)?

And here's Sheson's answer (reliable as ever):

 

"TexGen updates LOD textures for object LOD. So you run it and install its generated textures before running DynDOLOD to generate object (and tree LOD).

 

Generate terrain with xLODGen before or after as it is independent from object and tree LOD. However, if there are mods that make a lot of terrain elevation changes (like some house mods do when they flatten a corner in the mountains) it is better to generate terrain meshes (and textures) before generating object LOD, because object LOD generation uses the terrain LOD meshes to remove unseen triangles from object LOD for optimization."

[Kneph13]

Check out version 16 beta here at S.T.E.P. and read through its forum. In now generates distant terrain meshes and the result for terrain alone is way better than DynDOLOD. You still need to run the latter if you want dynamic lods and tons of extra objects. xLODGen allows for object and tree lods but what I do is to generate only terrain lods, activate and then run DynDOLOD. xLODGen offers a lot of customization. I tried first with Sheson's suggested parameters, then alt3n1ty's (3rd page in the thread) and the improvement was out of this world.

What I did was similar, first TexGEN, then xLODGen (which now generates meshes AND textures, so I'm not sure TexGEN is actually necessary), then DynDOLOD. Get ready because xLODGen with alt3rn1ty's parameters takes well over an hour in my build, twice as long as DynDOLOD. I suggest reading the thread (there aren't that many pages yet), try Sheson's suggested parameters for a quick first look, then try alt3rn1ty's for a much finer outcome.

Thank You godescalcus

[filiusDei]

Short answer, yes.

Ok, thanks. Looks like everything's running smooth and stable now. I'll build all the Merges from the Merge Page then prior to the Bashed Patch.

 

What I'm wondering is why we shuld create a New Folder in Mod Organizer\mods called Even Better Quest Objectives Patches e.g.? I'll deactivate all those plugins anyway? Does it make any difference when those plugins are still in the Even Better Quest Objectives folder but hidden?

And is there any difference between moving the merged esp into MO2's optionals or just hiding it in the Filetree tab? It's the same result, isn't it?

Edited April 28, 2018 by filiusDei

[Decopauge123]

NP. Here, a couple of screenshots with eye-candy of the far-off variety ;)

 

 

 

It's a shame the images don't open in full resolution, I'm amazed at the level of detail with xLODGen and DynDOLOD combined!

That's incredible, godescalus!  I'll be running xLODGen and DynDOLOD together, as you suggested, and see how it goes.

[godescalcus]

Ok, thanks. Looks like everything's running smooth and stable now. I'll build all the Merges from the Merge Page then prior to the Bashed Patch.

 

What I'm wondering is why we shuld create a New Folder in Mod Organizer\mods called Even Better Quest Objectives Patches e.g.? I'll deactivate all those plugins anyway? Does it make any difference when those plugins are still in the Even Better Quest Objectives folder but hidden?

And is there any difference between moving the merged esp into MO2's optionals or just hiding it in the Filetree tab? It's the same result, isn't it?

I don't move things around but, as said before, also don't have "copy general assets" active when merging. I think both options to hide the esp's are valid, or you could even manually edit their extensions to something that the game won't recognize. Using MO2's optional esp's, in my experience, makes it quicker to reverse if you want to tweak or rebuild the merge for any reason.

[sirjesto]

I don't move things around but, as said before, also don't have "copy general assets" active when merging. I think both options to hide the esp's are valid, or you could even manually edit their extensions to something that the game won't recognize. Using MO2's optional esp's, in my experience, makes it quicker to reverse if you want to tweak or rebuild the merge for any reason.

I don't move them to optional or hide them. I just leave them in my load order unchecked.

That is THE quickest way if you need to rebuild the merge.  ;)

[Decopauge123]

Unofficial Skyrim Special Edition Patch now at version

[spoiler=4.1.3b]Popped another hotfix up today to deal with an issue that cropped up with wolf sounds. Apparently those got fixed by Bethesda back in 2016 but nobody noticed until the Nix-Hound DLC was making the wrong noises for people using USSEP. If you already have 4.1.3a in hand and don't care about the CC at all, then you don't need to worry about this update. Since I'm moving soon and don't know for sure when internet will be brought up in the new place, it didn't feel right leaving an issue like this in the wild for what may be several months. We all know how stupid ISPs can get on new installs.

 

 

Skyrim Reborn - Whiterun Hold is now at version 1.0.1:  (1) Wild Riverwood door removed (2) Graywinter Watch Reborn added

 

SkyrimSE Re-Engaged ENB now at version

[spoiler=5.7a]All Presets- Updated for ENB Binary V.338. Added in EdgeAA (Although, I do not have enabled because it causes shimmering). Adds in dithering (Turned on post dithering). Adds in cloud clamp settings. Disabled ENB Rain due to amount of complaints for black rain. Could not fully remove issue so, figured best to disable and let users turn on ENB rain if they want it.

 

 

I don't move them to optional or hide them. I just leave them in my load order unchecked.

That is THE quickest way if you need to rebuild the merge.  ;)

Agreed.

Edited April 28, 2018 by Decopauge123

[filiusDei]

I don't move them to optional or hide them. I just leave them in my load order unchecked.

That is THE quickest way if you need to rebuild the merge.  ;)

Isn't that a little confusing? For me, it's already confusion with the 30 unchecked plugins because of the Bashed Patch :D

[godescalcus]

Isn't that a little confusing? For me, it's already confusion with the 30 unchecked plugins because of the Bashed Patch :D

I second your opinion... And I don't know if Skyrim SE will still glitch from having too many esp's (including those that aren't active in the load order) present in the root data folder (as with previous TES games, which led to Wrye Bash's ghosting feature).

[filiusDei]

That's weird: CTDs with Bashed Patch, no CTDs without :D

[Kneph13]

     Would someone be so kind as to link me to a copy of their zPatch.esp?  I really would like to be able to have my npc's wielding enchanted weapons against me.  

 

If I manage to get past my white screen issues in zEdit, when I try to build the zPatch I run into the error I posted earlier today: 

    

When building the zPatch.esp the bar progresses to 50.2% and throws this error Failed to add array item to Perks: Perk, 000A725C undefined, Failed to resolve element at path Perks.

 

mator provided me with a possible fix but it did not work.     Same issue persists.