godescalcus

+1 ehehe Come Aurora Village and Tel Nalta II if you like

reddvilzz, if you just select the "auto-ghost" feature in wrye bash (right click the "file" label in the mods tab in wrye bash and select from the drop-down menu) those plugins will automatically be disabled in Mod Organizer once you leave WB. If you go back to wrye bash and enable any of the ghosted plugins, Mod Organizer will have it active again. No need to move them to a special folder or even to the optional plugins tab. Just enable auto-ghost in wrye bash.

With me loot never had any trouble handling over 255 plugins. Maybe I didn't have over 255 *active* plugins, loot even sorts ghosted plugins - which I think is extraordinary. If you run into trouble with the number of plugins under wrye bash just ghost ("disable") any that you're currently not working with. In the end, after all the merges and bashed patch applied, you'll never be able to have more than 256 anyway. If you're running WB under MO, then you shouldn't exceed the active plugin limit when you run it. But bear in mind that WB deactivates a good number of plugins that get merged into the bashed patch, so you can actually have more than 255 the moment you run WB, as long as the count goes below 256 when you select the merged mods to deactivate. If using WB alone it is definitely dependent on plugin load order, just like mo or any other mod manager. Besides plugins, WB is also dependent on the priority order for installers (much like MO's left pane). Files in lower positions get copied later and overwrite any prior files with the same filename. But WB keeps track of all that and you can check each installer (=mod) for which of its files are maintained or overwritten by later mods, or which are overwriting prior mods. You have all the information to fine-tune your installation if you want to. I tend to do it while fine-tuning my texture choices Edit: on my current build I have 294 active plugins, going down to 245 with the bashed patch merge. If I have them all active when I run WB, no problem, when I build the bashed patch it asks to deactivate the ones that go into the merge and the final count is 245.

You can transfer all the content of the mods folder inside mod organizer to Wrye Bash's "Bash Installers" folder. They will be loaded as projects by wrye bash. I wouldn't even bother to repack them if you have hard drive space to spare, as unpacked folders will be installed/uninstalled much faster. But I strongly advise you against selecting all and installing in one go under wrye bash, although you can do it. I'd always install them one by one while checking the file structure and reviewing the guide for special instructions. But most of the work will be done and in most cases all you'll need to do will be to install each mod under wrye bash. Do check alt3rn1ty's pictorial guide and all the information you can get on wb. Activate the "auto-ghost" option as it will reduce the number of files inside the data folder as you install them (WB may get unstable if you go over the 325 limit of BSA's, ESP's and ESM's set by Beth). Check for mods that appear with a gray background on WB's instalers list, as they contain files or folders that won't be installed automatically. Actually, every folder coming from Mod Organizer will have a metadata file (meta.ini) that's useless and I suggest you remove it. Don't filter out document files, as some mods contain .txt files that wouldn't be copied if that were the case. Instead, manually delete from each mod the files that won't be needed. If you've already installed the full guide under MO, your folders will probably be all clean. If anything appears under gray background, it's very likely that something in the mod needs to be manyally copied. xEdit changes will be directly saved to the plugins contained in the Data folder, and wrye bash will detect the change and give an orange color to the installer, meaning that its contents differ from those of the data folder. If you like, you can re-copy the file from the data folder into the installer, if you trust the changes you've made, or just pack it as a 7zip and add it to wrye bash under the original installer, call it something like "my mod - plugin cleaned" and activate it. I myself love this intricacy as it gives me the same extra confidence as lower level programming - you just know exactly what's happening and what you're doing. General rule, WB is not ideal for people who want to quickly set up a modded game and play. It requires you to do things thoughtfully and knowing what you're doing. You need to enjoy the process of building your modded game and the detail of it. Which is why I think it fits so nicely with the STEP way.

Didn't know MO would no longer work with windows 10. Shouldn't they maintain full compatibility through a "mandatory" update? Regardless, I think WB is the right way to go. This guide needs almost no adjustment to run on pure wrye bash. Been doing it for a while and the only section that can't be performed is relinker (which is tied to MO). If you know which mods shouldn't be merged (that would require relinking) I think you can make it run 100% as well as under MO. I've also disabled the "batch copy assets" option in Merge Plugins Standalone, as I reckon Wrye Bash is pretty unambiguous as to which assets get copied to the data folder, bash tags being the subject I still don't know enough to mess with. It does require you to know each mod you're loading (at least its file structure) as wrye bash doesn't copy file types that it doesn't recognize as related to the game and those will have to be copied by hand. Example: FNIS. But isn't that in the "spirit" of this guide as well, not just cramming your mods into the mod manager but treating each one individually, conflict resolving, etc? You also need to be aware that adding Bethesda original files (which this guide doesn't require, but others do) forces Wrye Bash to recalculate CRC every time it refreshes the installers list, which can be a drag. And you need a tool like BSAOpt to manually extract bsa files, which is not that bad to be mindful of, considering the ever ongoing debate on the subject. My personal experience: I've had noticeably better performance using WB alone. Script lag was crippling from the start with MO and much less so (though still present) with WB. I wish I knew which tools to use to make this an objective claim - which I don't, yet I'm open to suggestions and might try to do some sort of benchmarking if it were useful. I theorize that the plain file system which wrye bash relies on allows for a faster execution than MO's VFS, by cutting off a step in the process, which can become noticeable in extreme load situations. But I'm not qualified to claim that as a fact and some people, Tannin included, have pointed out that issues may also derive from using a mod manager that relies on a manifest file to "know" how to reverse things, like WB does. Could be all down to "properly using" WB, though ;) In short, though I like MO and its unique features, I've been getting to like WB as a powerful mod manager you can ultimately rely on (keep it simple, sort of common-sense wisdom?). As for NMM, the current one, I've had nothing but sorrow there. I've wrecked more than one build in a single wrong click and been unable to repair it... Not in WB, though.

Nrs.2 and 4: I'm definitely not the most experienced modder here but I've been playing with this guide for a while and could share some of what I MAY have learned. I'd avoid mods that add too many NPC's with their own AI. There's some heavy script usage at points here. I've used JK's skyrim because it adds almost no scripts to the main worldspace or any of the major cities, mostly aesthetics. I've seen its critics point out that it adds no new NPCs, no new shops, no new houses etc but personally I think it's a pretty sound approach. Cities are... cities, there's a lot happening there already and mods that add too many new faces and interaction are bound to break at some point (as even the vanilla game will break). JK's Skyrim is more mindful of the fact that people use a combination of mods, not just THAT mod. It actually suggests people use 3dnpc's and the such, as it leaves room for those. As does this guide, by not adding more content that would overload the engine. JK's seems pretty mild, but it does add some load on the graphics. For that reason I'm now trying this LIGHT version of it. I've also had a bad experience with auto-sorting home mods. Tend to choke those threads if you trigger the auto-sort while something else is happening in the background.

Hey! I've had a similar problem recently and asked about it in the DynDOLOD forum. Sheson replied that it's likely that there's some error or conflict in the load order that's causing it. You do have to load your entire load order in xEdit and then select all plugins and check for errors. It will probably find A WHOLE LOT, but don't worry. Most errors/conflicts will do fine with dynDOLOD, some won't. In my case I had to disable one plugin before running DynDOLOD (BSHeartland.esp, which is part of the mod BS:Bruma, which, by the way, is not listed in the guide). So I took that one out and also the bashed patch, and DynDOLOD ran fine, generating 1.9Gb worth of LODs in 12 minutes :) If you added any mods to those present in the guide, I'd look at those first. As I said, once I took out one of the mods that I added, DynDOLOD did its job very well, which means that none of the mods in this modlist nor any of its merges had any problems. That is very good, considering such an extensive list of mods. Also, regarding the bashed patch, it's not mandatory that you take it out before running DynDOLOD. Sheson says that if taking it out solves your problem, it means the bashed patch has assimilated errors from the parent mods. If you do take it out, don't forget to check if in the plugins deactivated (merged into the bashed patch) there was any that has relevant landscape information (in my case there were flora fixes, pure waters, ash rocks, sulfur rocks and so forth). You should activate those if you want their changes to the landscape to be reflected in the LOD. Then after running DynDOLOD, deactivate them and reactivate the bashed patch and any plugins you had previously deactivated.

Sorry about that, I didn't know that BCS and the Lost Library were already included in LOTD. So I went off and installed them on top of my build. Bash errors made me look better!

BCS - TCIY Patch.esp is listed in the patch central main merge, but Book Covers of Skyrim is no longer in the mod list.

When testing a new mod, do you guys scan it thoroughly with xEdit against the whole load order, or do you only go after conflicts as they show up in game?

I don't know if it's the best practice, but I always create a new mod, name it 'SKSE output' and dump everything there whenever an SKSE folder appears in the overwrites. This is because mo will store in the overwrites everything that would have been saved inside the data folder. Most likely it will be logs or config files.

Not using mo but wrye bash. The exception in windows defender seems to have worked, but I still had the atlas build problem. So I did a check for errors on my full mod list with xEdit and it was full of them... And this is the carefully built and conflict resolved SRLE:LOTD build. Turns out the only crytical was BSHeartland.esm (that I added on top of the guide) - turned it off and dyndolod generated my lods flawlessly. Best procedure, it seems, is to check your mods before blaming outside interference ;)

Sometimes my mannequins would simply forget to put on their apparel altogether. So I looked around and found a few fixes and this seemed like the best one: https://www.nexusmods.com/skyrim/mods/36301/? I haven't got around to testing yet so anybody's feedback would be really great.

Will do. I usually skim through previous threads though, to avoid repeating. Not everyone gives such a good support as you, thank you for that! I've added dyndolod.exe, dyndolodx64.exe and both texgen exes to the windows defender process exemption list, restarted windows and will check if dyndolod runs.

Thanks Sheson. I'm not using an antivirus other than windows defender. Maybe it's protecting my firstborn? I've used DynDOLOD successfully two days ago, with the same build, the difference being that then I was using it through mod organizer while now I'm using wrye bash to install my mods, so I run DynDOLOD directly. Still, I have used DynDOLOD on this machine before, with wrye bash, without such issues. If I had a clue as to how to configure windows defender...

I was having the same problem and used this fix (with the right paths for me) and it worked. Why?

I know and agree, but it's probably down to how much importance I give to the radiant quests. If ESF were more about unique quests, then I'd be more tempted to keep it. And I ran into a problem in my last playthrough where, after becoming harbinger, I couldn't cure my own Lycanthropy, nor did any of the twins ever ask me to cure theirs, even after I did a few more boring tasks for them. It could be script lag related (it plagued me all the time) and the cure process might work after a few days, as I also often had to wait before Rikke had the dialogues to advance in the CW questline. But all things considered, I preferred to let this one fall and make room for more unique content like Bruma or Beyond Reach. As much as radiant quests sort of fill an empty space in the game, what's really unrealistic is that as you progress in a faction you keep doing the same kind of jobs, which are given to you by people to whom YOU should then be giving jobs to, not the opposite.

Great to know! I did without ESF, which you may find strange but it's about the way I play the game. I'm having as much fun collecting fossils and shells for the museum as I was getting bored with the grinding to raise in the companions. 24 quests is way too much for me in a game modded with so much additional gameplay content. The quests start repeating themselves soon enough. Maybe I could just have chosen the vanilla option in the MCM but then I thought I could lighten the load on this build and left ESF out. I added just about every mod that's currently supported in the Dragonborn Museum, so I had to make choices. And I actually added a mod to bring the total number of thieves guild quests needed from 125 to 25...

+1 You guys are great. Question: ENPCO makes a lot of changes that get undone by the npc's CR. For example, Vilkas gets 58 perks added by ENPCO while the CR sets the perk count back to 12 (and not the same perks). Is this meant for balancing the game or maybe I did something wrong with my setup? I did leave Ordinator out but I don't think it's related, there are no unresolved references, just a different set of perks. The same goes for Farkas, Aela and probably others (I'm going through them all right now).

That was me. I never even tried the main STEP. Modding for me was throwing mods at the mod manager and activating them. A friend at nexus challenged me to try out Neovalen's guide (which I did, a few months ago). Obviously, his guide was then already outdated, many files were unavailable or had been upgraded to more recent versions, so after losing a few days I googled around and found a post of yours mentioning three guides, based on Neo's, which I checked. I settled here because I read each of the fora and wiki history and thought that this was the most active one (after the trauma of trying to follow Neo's alone, that was the key thing). Good choice! And despite its advanced requirements, this guide and you people put us in the way of learning the needed new stuff, if one can take a hint and google the rest. Btw, my friend from nexus lives in the Gulf coast and I haven't got news of him since Saturday, I hope everything's ok...

I'm going with version 19.1.1, let's see what happens. Don't recomment it though, if your aim is to build and play the game. Also a lot of core mods are being updated, like CACO. In that case I stuck with version 1.2.

My friends, this forum is a treasure trove on information, as much as the guide. I was crashing at startup and it took me 2 hours to narrow the problem down to relinker (even reinstalled Legacy, as the problem was surely between the two and unchecking either would allow me to load). So I searched the forum and found the discussion on version 44 of relinker - yes, before I figured out it was written all the time in the guide. Roll-back to version 40 fixed my game :D Thanks for figuring that out, but I'm still curious about the cause and why it's not "universal". I mean, some people get away with v44, right? It's true I installed some extra mods that interact with Legacy (indeed, all of them if I didn't miss any). I'm also unsure as to whether I'm losing some functionality or not. Guess it's time to test and find out! :D In the process I also read the Legacy forum and realized that many people don't believe Legacy can be played with a 200+ mod build. ;) Way to go, guys.

Found, it's no longer included in v19 of the patch collection... Had to pick it up from v18final. Thanks berndaroy, it's good to know but now I finally managed to make my merge... Guess I'll keep the patch in it so I don't go through the trouble of merging again. I also had a hell of a time trying to work around the fact that the v19 CACO patch seems to be completely bugged (100+ unresolved references and other bugs in xEdit). I merged v18 in but I'm not sure it's compatible with v19 of Legacy... At least xEdit reports it clean, so I guess all the formids should be correct? We'll see.

I'm trying to make my own DBM patch merge and can't find DBM_Sofia_patch.esp in any of the patch archives. Can anyone help?

I've tried fireundubh's "Generate Bash Tags.pas" script from F&L New Vegas (essarbee's guide) and ran it on the merged CACO Patches.esp . Here's the output: It includes all the 4 tags suggested in the guide (which are also the 4 tags suggested if you run the native xEdit script to autodetect bash tags), DELEV, INVENT, NAMES, RELEV, but also adds ACTORS.DEATHITEM, GRAPHICS, STATS. I'm pretty ignorant of how the bash tags work, but would it be useful to accept the tags generated by the script and run it on all the other plugins before running wrye bash? The script specifically mentions it's compatibe with TES4 and TES5.