Give Feedback
0 of 0
About this mod
Just a bunch of patches I've created for CptMcSplody's beloved Unique Region Names. Starting with version 5 he got many important mods already covered, this page is meant to cover the rest. On top of that you get a guide on ESL flagging and... The Method!
- Requirements
- Permissions and credits
- Changelogs
- Donations
Just a bunch of patches I've created for CptMcSplody's beloved Unique Region Names. Starting with version 5 he got many important mods already covered, this page is meant to cover the rest. On top of that you get a guide on ESL flagging and... The Method!
Be aware that all the old patches I've made for URN version 4.x won't work with version 5.x so I've moved them to old files.
The USSEP Patch for Missing Encounter Zones Fixed can be found over at my other modpage: elwaps' Patches and Fixes
This is a collection of patches for Unique Region Names by CptMcSplody.
Unique Region Names is a mod that renames exterior cells everywhere so every time you're in an interior and look at the door heading outside, instead of just 'Skyrim' it will show 'Whiterun Hold', 'The Pale', 'Eastmarch' and so on, depending on where your current interior is located.
On the one hand this is a really nice immersive addition. On the other hand it won't work for any mod out there that adds interiors such as player homes, city overhauls, sometimes even mods you wouldn't expect. If left unpatched those mods won't do anything bad to Unique Region Names but you will have an inconsistent experience as mod interiors will still show 'Skyrim' when facing a door.
This collection of patches was created in xEdit and works in a really simple way. I've filtered Unique Region Names for conflicts with all other mods I use and created patches that contain the name changes UNR makes aswell as conflicting changes those other mods make. If you know your way around in xEdit those patches aren't hard to make yourself. But chances are you don't have to go through a ton of repetitive work as I've covered a nice selection of mods already.
Hard Requirements
Soft Requirements
Recommendations
*For most of the patches USSEP isn't technically required and it isn't set as a master for any of them. On the other hand you should have it installed anyway. Also, my general practice is forwarding any USSEP changes I see as I regard this 'mod' as part of the main game so please don't complain if you should ever run into issues caused by not having the Unofficial Patch.
Compatibility
My patches shouldn't cause hard incompatibilies that could lead to crashes or anything similarly bad. But some other mods you might use could either have values overwritten by my patches or overwrite them with their own stuff, depending on load order. That's why you should always check for conflicts in xEdit, just to be sure. In some cases it might be necessary to create additional patches to get the result you desire. But don't be afraid, creating patches for URN isn't really challenging but just annoying. And if you're following The Method (more on that later) conflicts won't be an issue for your mod build anyway.
Some examples for mods that will likely overwrite most if not all Unique Region Names patches:
The easiest way to handle mods like these would be a Smashed Patch, I've already patched MEZF like that myself. The result works fine but isn't perfectly clean, that's why I haven't uploaded it yet. I'll have a look into removing unwanted edits from that patch at some point or even manually recreate it once I'm really bored but for now there's not too much I can do.
Load Order
Load order should be determined by LOOT. I've added the correct masters to every single patch so my patches should be sorted after the mods they're made for automatically. If you're OCD enough and/or strictly follow The Method (again, more propaganda following below) you probably don't use LOOT at all. If you're sorting manually you should just place my patches below the respective mods they're made for. In cases where load order might be confusing I've put it below the file download.
At this point I really want to thank ElminsterAU and his crew for helping me out whenever I looked at xEdit conflicts like a dog would look at quantum physics. For my current build I was (and am) strictly following the preachings of dramatic pause The Method. The Method is a bit less cult like than it might sound to you now but instead a fool proof method of getting huge mod lists to work flawlessly and crash free (as far as vanilla allows). Its rather hard work and discipline than magic but those using it will tell you its totally worth it. More on that later.
If you're someone like me who uses MO2, xEdit and whatnotelse on a daily base think about dropping them a few bucks on Patreon. I personally support ElminsterAU a bit but that's not because all the others wouldn't deserve it but as I tend to sometimes annoy the hell out of him with my questions.
Also, if you got any questions, want to delve into the modding community, drop some neat screenshots or just sit there quietly and stalk other peoples' conversations, check out those Discord channels
You've probably all been at a point where you've maxed out Skyrim's plugin limit or even went beyond that using MergePlugins and/or ESL flagging (see below) to stuff in all the awesome mods you've found on the Nexus (and perhaps that other site called LL too). But at some point you've encountered random crashes you couldn't fix. You've had inconsistencies like Unique Region Names only working on certain interiors. You've seen water seams, broken navmeshes, clipping and whatnotelse a heavily modded Skyrim may throw at you.
Perhaps you've given up at that point, deleted your mods, reinstalled Skyrim and started over again. Just to run into similar problems once that new modlist became bigger.
Perhaps you went back to the Nexus and finally read all the descriptions everyone told you to carefully read before. Perhaps you've spent hours and days digging out all the patches for the mods you use. And perhaps this helped. But more probably you couldn't fix every issue and just lived with what you got.
Or you asked people and read tutorials and finally loaded up your build in xEdit and checked for conflicts, looking forward to solve all of them to finally get the neat and tidy Skyrim you always wanted. Just to be shocked about a wall of red. It seemed like every single mod was conflicting with all your other mods even tho you got every single patch you've found.
This is the point where post people (including former me) just go 'Fuck this! I won't spend four hours a day for a month to fix this mess!' and forget about that wall of red. Some chosen few might have actually accepted this challenge and fixed and patched all their mods until all conflicts were resolved. Those people are my heroes.
But there's a WAY easier way to do this - The Method!
Prequisites
You either need to start over with a fresh install of Skyrim SE or take your current build and deactivate all mods so that your plugin load order, again, is vanilla. This might help you going back to vanilla SSE in an efficient way but be aware that guide was written for Oldrim. If you want to be absolutely sure and got a reasonable internet connection just uninstall Skyrim from Steam, delete the remaining folder with everything in it from \steamapps\common\, delete everything Skyrim-related from your My Documents folder and perhaps even check your AppData folders for remains of the tools you might have used in the past. Then reinstall through Steam.
Make sure to use a good mod management tool like Mod Organizer 2 (MO2) or Vortex. I would personally recommend MO2 so that'll be the mod manager I will refer to. For me its pretty self explanatory but people sometimes say it has a steep learning curve. If you're unsure about something this video by awesome channel GamerPoets might help. Or just ask me in the posts section or one of the Discords mentioned above. Nexus Mod Manager is outdated and unsupported by not only me but basically anyone and going by countless posts on the Nexus aswell as countless help requests on Discord seems to have a ton of issues. Manual mod management is even worse, don't even think about it.
Make sure you got an up to date version of xEdit installed, we will need this alot!
Before starting with The Method you should make sure to have the Unofficial Skyrim Special Edition Patch (USSEP) loaded. This isn't entirely necessary for The Method but good practice anyway.
Good Conflicts, Bad Conflicts
The Method is all about conflict resolution. A conflict is a record from one mod overwriting the same record from another mod. There are intended conflicts and problematic ones. Here's examples for both.
Just ignoring all conflicts and hoping for already available patches to fix them might work on some smaller modlists. But at some point you will encounter strange behaviour, inconsistencies or worse. This is why we're having an eye on conflicts throughout the creation of our modlist. That's the core of The Method.
The First Step
Now that we got USSEP installed, know how many aspects of the vanilla game are touched by this patch and know what a conflict is we can expect to see a ton of them between USSEP and the vanilla game files. But as USSEP is meant to overwrite alot of records in order to fix bugs we dont need to examine them and can just acknowledge all those conflicts to have them out of the way for later. This is done by creating a modgroup in xEdit.
IMPORTANT
Starting with version 4.1.7 the Unofficial Skyrim Special Edition Patch now comes with its premade modgroup so theoretically you could just skip this part and continue with 'The actual Method'. However, as rearranging the guide will take a little while I can only recommend you to actually delete the modgroup coming with USSEP (double click the mod, go to File Tree and delete the Unofficial Skyrim Special Edition Patch.modgroup file) and follow this part of the guide to create your own USSEP modgroup. Or at least read it so you know what modgroups are about.
This will launch xEdit and have it scan your current modlist for conflicts. After it finishes loading you will see your current list of plugins (Skyrim.esm, SkyrimSE.exe, Update.esm, Dawnguard.esm, HearthFires.esm, Dragonborn.esm and Unofficial Skyrim Special Edition Patch.esp) highlighted in red on the left side of xEdit. Normally we would expand the plugins in that list to see what the detected conflicts are all about but this time we just want them out of the way. If we looked at them we would see something like this:
The master records are the first versions of any record. Record A for example makes its first appearance in Skyrim.esm, Record F is first seen in HearthFires.esm. The conflict winners are the versions of any record that are loaded last and aren't overwritten by another version of the same record. Those are the values you will experience ingame. Everything inbetween are conflict losers, they are overwritten and won't make it into the game.
On the first screen you can choose which plugins will be part of that mod group. Make sure all of them are checked and hit OK. On the next page you can enter a name. Choose one that makes sense like 'USSEP' and hit OK. On the third page xEdit wants you to choose a plugin to attach that modlist to. As the modlist is needed for the conflicts caused by USSEP attach it to USSEP and hit OK. On the last page xEdit wants to know which modgroups should be active. On this page always make sure to have all modgroups active and hit OK. This is how the above situation would look after creating this first modgroup:
The modgroup hides all conflict losers of all plugins that are part of the modgroup. What's left are the masters that are always visible when there's a conflict. And the conflict winners.
This can be done by double clicking 'overwrite' and just dragging the .modgroup file into your USSEP mod. Theoretically you could put it anywhere as long as MO2 got access to it but that way we keep our modlist neat and tidy. If you would deactivate USSEP the according modlist wouldn't be needed anymore. By having it in the USSEP folder you would deactivate the modgroup at the same time you deactivate USSEP. Makes sense.
The left pane which previously showed your conflicting plugins should now be empty. This is because conflict winners overwriting their masters aren't regarded as conflicts and conflict losers in your modgroup are ignored for conflict checking.
The actual Method
Now that we got an empty conflict list you're ready to choose the first mod you want to add. Mods affecting many regions of the game are advised to be added first. Such mods would be Realistic Water Two, Unique Region Names, Missing Encounter Zones Fixed and so on. Theoretically the order of installation doesn't really matter but going from large effect on the game world to small effect on the game world will save you some trouble while resolving conflicts as something like Unique Region Names will cause conflicts with almost every single mod in your list - and that's alot when added late in the process.
What follows now should be repeated for every new mod you add and is the core of The Method:
1) Install a new mod and guess a good position in your load order
Load order guessing gets easier with time. Once you realize that every other player home will overwrite lighting values of Enhanced Lighting for ENB with vanilla Skyrim stuff you will place it before ELE. Putting my Unique Region Names - Arthmoor's Karthwasten below the two mods its made for is pretty obvious. And having a mod changing a few locations like Skyrim Bridges below a mod like Enhanced Landscapes that touches almost every region of the game is a good rule of thumb too.
After adding new plugins I usually clean them with xEdit and the argument -quickautoclean. You can do the same by creating a new xEdit executable like above but with -quickautoclean instead of -veryquickshowconflicts. While I'm at it I check it for errors by rightclicking it in xEdit and choosing 'Check for errors...'. If its full of them I usually drop it right a way and look for a better mod to add. If its just a few and I like the mod I try to fix them which can be a real hassle. Joining the xEdit Discord and asking all the great mod and tool authors in there usually helps. I'll be glad to help out too if I'm online.
2) Run xEdit with -veryquickshowconflicts
This displays all conflicts the new plugin causes. Rightclick somewhere in the right pane, where all the records are listed, and choose 'Hide no conflict and empty rows' to make things more clear and actual conflicts more visible. If we sticked to our example from above you would notice that only Dragonborn.esm, USSEP.esp and our new plugin would be listed as conflicting in xEdit. This is because all conflicts with Update.esm and Dawnguard.esm are hidden by our modgroup and as HearthFires.esm got no records conflicting with our new plugin at all.
3) Go through all the conflicts and check if changing its position in your load order could fix them
If it seems like a change in load order could fix most of them (like when a mod overwrites changes from another mod with empty values everywhere) leave xEdit, change your load order manually in the right pane of MO2 and come back to see if this fixed the issue.
4) Identify the conflicts that shouldn't be ignored.
For example, if a mod defines a water type for a certain area but this change gets overwritten by the water type of Realistic Water Two it can safely be ignored as you want RWT's water type to win. But if a plugin got new entries that overwrite other entries of another mod and the other way around you would need a patch. See an example for this in the screenshot below.
Even tho an overwritten EditorID will only bother us if we're planning to work with Limbwood Manor in Creation Kit it is still a good example what a conflict that needs to be patched looks like. Here, Unique Region Names does its thing and adds a Region record that renames the region (from the regular 'Skyrim') to 'The Rift'. As URN's EditorID line is empty Limbwood Manor's record gets overwritten with nothing. If we switched the position of those plugins in our load order Limbwood Manor's EditorID would survive but URN's region name would be overwritten. As we don't want either to happen we need a patch.
The first step is rightclicking LimbwoodManor.esp at the top and choose 'Copy as override into...'. In the new window scroll to the bottom and choose '<new file>.esp [Template] ESL', that way the patch won't count against Skyrim's regular plugin limit (see below). Then chose a reasonable name like 'Limbwood Manor Unique Region Names Patch' and that's it, now we got our new patch plugin that you can see in the screenshot on the far right side. But in this state it is nothing but an exact copy of LimbwoodManor.esp's records, in this state URN's region record gets overwritten.
For our new plugin to be a patch we should now drag the xxMapTheRift record from Unique Region Names.esp into the empty Region field of our patch. xEdit will ask if it should add Unique Region Names.esp as a master to our patch. This means that the patch can only be activated if URN is activated as it refers to a record that is only present in URN. But that's fine, without URN our patch wouldn't make sense to be active anyway so hit Yes.
This is the result. Our patch will be loaded after both mods and contains the records of both of them. Neither the EditorID from Limbwood Manor nor the Region from Unique Region Names gets overwritten anymore and everyone's happy. Conflict resolved.
As a final step click on your newly created patch in the left pane of xEdit. You should be able to see the masters of that patch which in our example should be LimbwoodManor.esp and Unique Region Names.esp. If one (or both) of them are missing right click your patch and choose 'Add Masters...'. In the new window check the mods your patch is for and hit OK. This isn't entirely necessary but good practice. If you plan to publish your patches everyone using LOOT will thank you for this. As a final touch you can add your name to the author record - congratulations, you're now officially a mod author. Wasn't that hard, was it?
This is basically how simple compatibility patches are created. I know this requires some routine and experience and I'm still unable to fix all kinds of conflicts mself. But when in doubt join the xEdit Discord and ask for help in #cathedral-of-the-method. Don't be shy, this is how I've learned it.
5) Once you've created patches for all conflicts that you think shouldn't be ignored close xEdit and save them
Make sure all your new esps are in the list and checked. Once you're back to MO2 you will find your new patches in the overwrite folder at the bottom of your modlist. Its not good practice to have plugins lying around in there so if you only create a single patch (and you're sure there's no other crap left in overwrite) you can create a new mod out of your overwrite folder via rightclick and 'Create Mod...'
If you created more than one patch the easiest way is to open your overwrite folder in Windows Explorer (rightclick, 'Open in Explorer') and create new folders for all your new plugins. Then drag your plugins into the respective folders and simply move those folders from \Mod Organizer 2\overwrite to \Mod Organizer 2\mods. Once you refresh MO2 (hit F5) your patches will show up in the left pane.
Even tho it is entirely up to you how you name and manage your mods in MO2 this almost empty modlist would be a good point to think about a proper sorting and naming scheme. You will be thankful for this once you got a few hundred mods in your left pane and need to use the search function to find them. Call me an autist but this is how I manage mine:
Once you've acivated your patches the plugins will show up at the very bottom of your load order in the right pane. Depending on lour load order and other patches you might want to change the load order spot of your patch but at least for the first one you don't need to change anything.
6) Re-open xEdit with -veryquickshowconflicts and create modgroups for all plugins with intentional conflicts
After creating all the patches we need only intentional conflicts are left now. For those we should now create modgroups to get them out of the way for conflict checking the next mod. Of course we could just create one large modgroup containing all conflicting plugins but you will realize this isnt the best approach. If we will later disable one of the mods of this combined modlist the entire modlist isnt working anymore and we will be presented with a huge amount of conflicts we will need to re-check. This will get really annoying once your modlist has grown larger.
Instead we will create one modgroup for every two plugins with intentional conflicts. The ConflictingPlugin.esp from our basic example from above got conflicts with Dragonborn.esm and USSEP.esp so we will create a modgroup for each of those conflicting plugins. As you can see, the first modgroup only hides the conflicting Record A with USSEP.esp and the same record from our ConflictingPlugin.esp is the conflict winner in the new modgroup. That way, if the next plugin you add conflicts with Record A, it will only be shown conflicting with that record from ConflictingPlugin.esp.
The same goes for Record B and D from Dragonborn.esm. ConflictingPlugin.esp is the new conflict winner in our second new modgroup and if the next plugin you add will conflict with either Record B or D the records of Dragonborn.esm will not be shown, instead xEdit will only show the conflicts with ConflictingPlugin.esp.
In general, by creating a new modgroup for every plugin our new mod is conflicting with we will hide those conflicting records and only the respective conflict winner in our modgroup will be shown once we add the next plugin that conflicts with one of these records.
Here's another practical example:
Here we can see LimbwoodManor.esp's water record is overwritten by the one from Unique Region Names - RealisticWaterTwo Patch.esp. After checking all conflicts between those two plugins (which can be easily done by checking the records of Unique Region Names - RealisticWaterTwo Patch.esp instead of the LimbwoodManor.esp ones) and realizing that they can all be ignored we're putting both mods into a new modgroup.
The process of creating that modgroup is basically the same as described above in 'The first Step'. But this time, instead of selecting all plugins on the left side and stuffing them all into a modgroup we will rightclick Unique Region Names - RealisticWaterTwo.esp in the headline top right and create a new modgroup from there. In this case only Unique Region Names - RealisticWaterTwo.esp and LimbwoodManor.esp should be eligible for our modgroup but if xEdit presents you with more than two plugins make sure you only select the two conflicting plugins. The rest is exactly the same as described above.
Once we created that modgroup the same window in xEdit should look like this:
Once you've created all modgroups needed to hide those intentional conflicts exit xEdit, sort them into their respective mods and re-open xEdit to make sure the left pane is empty. If so, all conflicts are either solved via patches or hidden by modgroups. If not you should go through the remaining conflicts and repeat steps 4 to 6.
7) Start over again
Once the next plugin is added you will realize why we went through the hassle to create modgroups. Only the conflicts created by that new plugin will be shown with all the stuff from previous plugins out of the way. In the long term this will make conflicts way easier to handle. No more staring at red walls and giving up.
A quick word about LOOT: if you're following the above guide right from the beginning you will not need LOOT. The only thing it will help with is finding the right spot for a new plugin once your modlist has grown large. On the other hand you will need to disable masterlist updates to avoid changes messing around with your manual order. You will also need a zillion of custom load order rules to ensure the right order. This is what I did and it can be a pain in the ass so the most elegant way would be to really not use LOOT at all.
Last but not least a quick word about conflicts that can't be handled in an easy way in xEdit like objects clipping into each other. After sorting and patching my newly added plugins I usually go ingame and check all the locations the new plugins are touching. You should really do this if you're using major landscape changing mods such as brilliant but super incompatible Enhanced Landscapes and try to add player homes or similar things adding stuff to the game world. If I see clipping I open the console (using the awesome More Informative Console), click the object and take a screenshot. That's what I took the screenshot below for. I then go to xEdit, search for the Ref IDs from my screenshots, copy them as override into a new patch (see above) and set their record flags to 'Initially Disabled'. That way those objects won't show up ingame anymore.
Finally a line about USSEP. While I'm checking conflicts of newly added plugins I sometimes stumble upon mods overwriting USSEP changes with stuff from Skyrim.esm. In these cases I just drag USSEP's changes directly into the plugin that does the overwrites and by that create myself an USSEP version of that mod. This is the only case where I directly edit plugins, for everything else you should really create separate patches.
How does Skyrim address plugins?
You might have already noticed FormIDs in some tutorial (for example removing cities from JK's Skyrim), while getting items via console cheat (player.additem) or somewhere else but don't know what they actually are. Here's one example:
The interesting part is on the far right side: Base Form and Ref Form.
Let's stick with the tree that I've marked in the screenshot for a moment. The Base Form (00051126) is an entry in Skyrim.esm and stands for TreePineForest05. It doesn't say anything about where the tree is located, about the size of the tree, its rotation or anything else. The entry in Skyrim.esm just defines a few basic parameters of that tree type like the type of the entry (TREE) and where the 3D model of that tree is located in the meshes folder of the game (Landscape\Trees\TreePineForest05.nif).
Now, if you got a mod (or the vanilla game) that places this kind of tree somewhere in the game world, that specific tree (like the one that is clipping through the floor in my screenshot) gets a Ref Form, which in this example is 0D00517E. For this you can define its position in the world, its size, its rotation and lots of other properties. The Ref Form is the FormID we'll be looking at. It can be divided into two parts:
[0D] [00517E]
The first part might look familiar for anyone using Mod Organizer 2 or any other mod manager that shows the load order of plugins like MO2 does. It defines where in the load order a mod is located using a two digits hexadecimal number. The mod with the lowest number gets loaded first, the higher ones are loaded later and overwrite the earlier ones. Your typical load order would look like this:
[00] Skyrim.esm
[01] Update.esm
[02] Dawnguard.esm
[03] HearthFires.esm
[04] Dragonborn.esm
[05] SomeMod.esm
[06] SomeOtherMod.esm
...
[0C] AnotherMod.esp
[0D] Enhanced Landscapes.esp (the one from our example screenshot)
...
As hexadecimal digits go from 0 to F (F stands for 15) and as we got two digits, the largest number you can put together is FF = 255, just like the largest number for the decimal system would be 99. This is where Skyrim's theoretical plugin limit of 255 comes from. Its actually a bit less than that but that shouldn't bother us here. This limit is what forces people to stop adding mods to their game or start merging them which gets trickier the more mods you want to add.
How does Skyrim address records within plugins?
Now, what about the other six digits?
Those are used as addresses for entries (records) within plugins. The tree from the screenshot got 00517E, another tree might have 00517F, some NPC added by the same mod could have 077F20 and so on. These addresses within plugins are hexadecimal too, so the last address and highest amount of objects in one plugin would be FFFFFF, which is 16,777,215 in decimal. This means that a mod author could theoretically stuff over 16 million things (TREEs, NPCs, BOOKs, ACTIvators,...) into one single esp file. More than that isn't possible as we would be running out of addresses again but who needs that many objects within one plugin anyway.
The ESL address format
So, we're maniacs who already added as many mods as possible to our game and already start to get 'Too many plugins' errors from various tools and the game itself. But, of course, there's at least twenty more immersion mods out there that NEED to be added to our mod list. And then there's those 50 patches for all our mods we forgot to install earlier.
In the past this would have been the point where we would have fired up the (undoubtedly cool) tool MergePlugins and trial-and-error our way through our modlist in order to combine as many mods as possible, just so we stay below the magical FF/255 mark. But now there's an alternative. Skyrim Special Edition does not only understand master files (those .ESM files from the main game and large mods) and regular ESP plugins (any other mod) that all count towards that 256 plugins limit but also ESL files (I believe the Creation Club mods come with these) and ESP files with the so called ESL flag. And while pure ESL files suck as they're always loaded first and can't really be sorted, those ESP files with the ESL flags are gold and exactly what we need. They behave just like regular ESP plugins and even look the same from outside but they're not loaded in a regular load order spot like [A4] or [0D] but they're all squished into the [FE] spot, which now is a whole new address space by itself.
[FE:0A8]
This is what the load order address of an ESL flagged plugin looks like. And this is what a bunch of ESL flagged plugins in your load order would look like:
...
[FB] RandomMod1.esp
[FC] RandomMod2.esp
[FD] RandomMod3.esp
[FE:000] RandomESLFlaggedMod1.esp
[FE:001] RandomESLFlaggedMod2.esp
[FE:002] RandomESLFlaggedMod3.esp
...
[FE:0C3] RandomESLFlaggedMod196.esp
[FE:0C4] RandomESLFlaggedMod197.esp
...
[FE:FA9] RandomESLFlaggedMod4009.esp
[FE:FAA] RandomESLFlaggedMod4010.esp
[FE:FAB] RandomESLFlaggedMod4011.esp
...
Wait, what? Mod 4011?
As [FE:FFF] would be the highest address for an ESL flagged plugin and as the FE-part always stays the same as that's the position of the whole bunch of ESL flagged plugins in the regular load order, FFF is the maximum amount of plugins we can have in this address space. And that's a whopping 4096 of them!
This effectively means we're not limited to 256 plugins anymore but to 254 (as the FE-slot is blocked) plus 4096 = 4351 plugins!
The Downside
As you might have guessed there has to be a downside. And of course you're right. As the address of the plugin itself in the load order now takes up five instead of just two digits, there's less digits left to address stuff within the plugin. Instead of six digits (000000-FFFFFF = over 16 million) for records we can use for NPCs, TREEs and other things inside our plugin we only got three digits (000-FFF = 4096) left. This gets clear when we compare them side to side:
Regular: [0D] [000012]
ESL-flag: [FE:00D] [012]
At a first glance this doesn't seam too bad as 4096 is still a large amount of records within a plugin. But there's a few problems that might be in the way. Let me demonstrate with three examples:
Example 1
The hypothetical plugin in position [A4] we want to flag as ESL got three records: 000001, 000002 and 000003
[A4] [000001]
[A4] [000002]
[A4] [000003]
A plugin like that can be easily flagged as ESL as there's less than 4096 records and the records would still fit well into the ESL address space. There would be no issues and apart from setting the flag nothing else would have to be done. The result would look like this:
[FE:001] [001]
[FE:001] [002]
[FE:001] [003]
As the addresses within the plugin wouldn't change, any patches or addons with that plugin as a master would still find the records inside they're trying to reference to. In case you're wondering if the game notices the missing zeros - it does not. Leading zeros are ignored. You can test this by setting the weather via the ingame console with 'fw 0010a243' and with 'fw 10a243'. The result will be the same.
Example 2
The hypothetical plugin in position [A4] we want to flag as ESL got three records: 000001, 000002 and 0FA322
[A4] [000001]
[A4] [000002]
[A4] [0FA322]
A plugin like that cannot be flagged as ESL just like that. The records 000001 and 000002 would be fine just like in Example 1 but 0FA322 does not fit into the three digits address space of an ESL flagged ESP. The consequence of this: we need to compact the plugin to be able to fit in all its records. There's a feature in xEdit that does just that. If we did that, the following would happen:
[A4] [000001] -> no further action
[A4] [000002] -> no further action
[A4] [0FA322] -> changed to [A4] [000003]
Again resulting in
[FE:001] [001]
[FE:001] [002]
[FE:001] [003]
Now all records fit into the three digits and the ESL flag would be set. You can do this to small patches and other uncomplicated mods that got no patches or addons themselves. Once such a compacted plugin got another plugin that's referencing to it we got a problem tho. Something in the other plugin could try to reference to 0FA322 but it wouldn't find anything at that address anymore as that record was changed to 003. This could lead to various annoyances or even crashes. In the end, we would have to manually edit the patch/addon and change all entries of 0FA322 inside them to 003. Which would be really annoying as even small plugins not only got 3 records but dozens or hundreds of them. Still, if we know exactly that a plugin got no patches or addons that rely on it, compacting is still a viable way.
Example 3
The hypothetical plugin in position [A4] we want to flag as ESL got more than 4096 records. This is usually the case for quest mods, large player homes and compilations like Immersive Armors. As our address space within an ESL flagged plugin is limited to 4096 entries we simply cannot set the flag or compact the plugin. Bad luck.
ESLifying plugins
Now, what do we have to do to make use of ESL flags?
First, we should ESLify all plugins that can be flagged without any further changes. For this we will need xEdit, just get the latest version from github. With xEdit there's an easy way to scan your load order for plugins that are small enough and don't need to be changed in order to get the ESL flag.
ESLifying Plugins the easy way
This can be done for all plugins that are like in our Example 1 above. You'll need to start xEdit with the arguments -PseudoESL and -autoload. PseudoESL will display all flaggable plugins, no matter if they already got the flag or not, with [FE:XXX] load order numbers. This will be useful in a minute. Autoload skips the initial dialogue where xEdit asks you which plugins to load.
In Mod Organizer 2 you would go to the executables menu (the gear icon top left) and add SSEEdit.exe as a new executable like displayed on the left hand side. In Vortex it would look like on the right side.
Now start xEdit with those arguments. For MO2 this works by starting QuickESLCheck from the dropdown menu, in the Vortex example it would be named SSEEdit-eslcheck but its really up to you how you name the link. After loading has finished we're presented with our load order. We will now see three types of plugins:
We will change that. Click on Higher Bounty Rewards.esp (or whatever plugins like that show up for you). On the right side of xEdit you will now see some properties of that plugin like the Form Version, Version and Author. What we're looking for is the Record Flag line. The one of Higher Bounty Rewards is currently empty. Right click the empty space and choose Edit. xEdit will present you with a couple of record flags you can set. Of course we will choose the ESL flag and hit OK.
You can now do this to all plugins that got [FE:XXX] load order numbers but no <ESL> flag yet. If you got a large mod list already type '[FE' into the search bar at the bottom to hide all the regular non flaggable plugins like [86] CFTO-Lanterns.esp, then you'll just need to look for lines without the <ESL> flag.
Once you're done simply close xEdit. It will show a window with all plugins you've changed. Make sure all of them are checked and hit OK.
That's really it, there's nothing more to it.
I re-do this check once in a while after adding a bunch of new mods to keep my modlist as ESLified as possible.
Compacting plugins
Once you've flagged all possible plugins with the easy method above you should be fine for a while. But at some point further down the road you might run into Skyrim's plugin limit again. What you can do now is a bit more dangerous so really think about the plugins you do this to. This is what I've explained in Example 2 above.
Just start xEdit the regular way, rightclick any plugin and choose 'Compact FormIDs for ESL'. Now three things can happen:
If you get this you've found a plugin that can be compacted. The first line just tells you how many records will be changed. However, you should pay close attention to the second line of that warning. This tells you what kind of records will be changed and that's really important as some kinds of records will somehow break if you try to compact them. According to ElminsterAU you should really avoid compacting plugins when one of the following record types would be touched:
If that's not the case for your plugin make sure there are no patches or addons that got it as a master as after compacting those patches and addons wouldn't find records they're looking for anymore.
If you're sure about this too hit 'yes'. xEdit now compacts the plugin and lists all changes in the right side of the window, looking like this:
...
[00:02] Changing FormID [3300B865] in file "JKs Whiterun exterior.esp" to [33000CA3]
[00:02] Changing FormID [3300B867] in file "JKs Whiterun exterior.esp" to [33000CA4]
[00:02] Changing FormID [3300B868] in file "JKs Whiterun exterior.esp" to [33000CA5]
...
Now, if you're REALLY hardcore you could theoretically write down ALL the changes that had been made. Then you could compact plugins that are referenced to as a master too. Then you could check all patches and addons for that plugin for the original FormIDs like 00B868 in this example. And then you could manually change them to the according new FormIDs like CA5 in this example. That way you could basically compact ALL plugins with few enough records and save even more space in your load order.
But be aware that every update of the compacted plugin would break everything.
I've already proposed ElminsterAU with an automated way of keeping track of changed records of compacted plugins and apply them to all plugins referencing to those records but I wouldn't expect the release of such a feature anytime soon. Still, I hope you could save a ton of space in your load order even without compacting everything.
Be aware that all the old patches I've made for URN version 4.x won't work with version 5.x so I've moved them to old files.
The USSEP Patch for Missing Encounter Zones Fixed can be found over at my other modpage: elwaps' Patches and Fixes
Updates
- 2020-05-22 Files Added: Bluecreek Estate Patch
- 2020-05-22 Files Added: Blackthorn - A Buildable Town in The Rift Patch
- 2020-05-21 Files Added: Aurora Village Patch
- 2020-05-21 Files Added: Inigo Patch
- 2020-05-20 Files Added: Anna's RIverwood Cabin Patch
- 2020-04-13 Moved all old patches to old files, uploaded new patches for MESZ - Missing Encounter Zones FIXED
- 2019-05-04 Files Added: Mammoth Manor Patch
- 2019-05-04 Files Added: Aurora Village Patch
- 2019-05-03 Files Added: Added a patch for Hammet's Dungeon Packs 1.92 ESM Version
- 2019-05-03 Files Added: Added patches for Shimmerfall Springs, New Lore-Friendly Dungeons and Jornheim
- 2019-05-03 Files Added: Added a patch for Skyrim Underground
- 2019-05-01 Files Added: Added a patch for Enhanced Landscapes and Aurora Village
- 2019-05-01 Files Updated: Updated Forgotten Dungeons Patch with new records, should be complete now
- 2019-04-30 Files Added: Added a patch for Forgotten Dungeons
- 2019-04-30 Files Added: Added patches for Hammet's Dungeon Packs and Ravengrave
- 2019-04-28 The Method: Added a warning for everyone using the Unofficial Skyrim Special Edition Patch 4.1.7 or later
- 2019-04-27 The Method: Complete rework of The Method guide - now with more pictures and even more noob proof than before
Content
- Description
- Requirements, Compatibility, Load Order
- Credits
- The Method or how to create the most clean and stable mod build you've ever had
- The ESL Flag or how to ignore Skyrim's plugin limit without merging
Description
This is a collection of patches for Unique Region Names by CptMcSplody.
Unique Region Names is a mod that renames exterior cells everywhere so every time you're in an interior and look at the door heading outside, instead of just 'Skyrim' it will show 'Whiterun Hold', 'The Pale', 'Eastmarch' and so on, depending on where your current interior is located.
On the one hand this is a really nice immersive addition. On the other hand it won't work for any mod out there that adds interiors such as player homes, city overhauls, sometimes even mods you wouldn't expect. If left unpatched those mods won't do anything bad to Unique Region Names but you will have an inconsistent experience as mod interiors will still show 'Skyrim' when facing a door.
This collection of patches was created in xEdit and works in a really simple way. I've filtered Unique Region Names for conflicts with all other mods I use and created patches that contain the name changes UNR makes aswell as conflicting changes those other mods make. If you know your way around in xEdit those patches aren't hard to make yourself. But chances are you don't have to go through a ton of repetitive work as I've covered a nice selection of mods already.
Requirements, Compatibility, Load Order
Hard Requirements
- Skyrim Special Edition
- Unique Region Names
- The other mod the respective patch was made for
Soft Requirements
- The Unofficial Skyrim Special Edition Patch (USSEP)*
Recommendations
- Mod Organizer 2 to manage your modlist in the most clean way and keep your Data folder tidy
- xEdit to find and resolve conflicts between mods, clean mods, fix errors and whatnotelse
- LOOT to automatically sort your load order and create custom rules if needed
*For most of the patches USSEP isn't technically required and it isn't set as a master for any of them. On the other hand you should have it installed anyway. Also, my general practice is forwarding any USSEP changes I see as I regard this 'mod' as part of the main game so please don't complain if you should ever run into issues caused by not having the Unofficial Patch.
Compatibility
My patches shouldn't cause hard incompatibilies that could lead to crashes or anything similarly bad. But some other mods you might use could either have values overwritten by my patches or overwrite them with their own stuff, depending on load order. That's why you should always check for conflicts in xEdit, just to be sure. In some cases it might be necessary to create additional patches to get the result you desire. But don't be afraid, creating patches for URN isn't really challenging but just annoying. And if you're following The Method (more on that later) conflicts won't be an issue for your mod build anyway.
Some examples for mods that will likely overwrite most if not all Unique Region Names patches:
The easiest way to handle mods like these would be a Smashed Patch, I've already patched MEZF like that myself. The result works fine but isn't perfectly clean, that's why I haven't uploaded it yet. I'll have a look into removing unwanted edits from that patch at some point or even manually recreate it once I'm really bored but for now there's not too much I can do.
Load Order
Load order should be determined by LOOT. I've added the correct masters to every single patch so my patches should be sorted after the mods they're made for automatically. If you're OCD enough and/or strictly follow The Method (again, more propaganda following below) you probably don't use LOOT at all. If you're sorting manually you should just place my patches below the respective mods they're made for. In cases where load order might be confusing I've put it below the file download.
Credits
At this point I really want to thank ElminsterAU and his crew for helping me out whenever I looked at xEdit conflicts like a dog would look at quantum physics. For my current build I was (and am) strictly following the preachings of dramatic pause The Method. The Method is a bit less cult like than it might sound to you now but instead a fool proof method of getting huge mod lists to work flawlessly and crash free (as far as vanilla allows). Its rather hard work and discipline than magic but those using it will tell you its totally worth it. More on that later.
- Bethesda for somehow creating a mess of a game that resulted in the planet's most awesome modding community
- Nexusmods for providing a huge, professional, clean and well supported place for every mod lover
- ElminsterAU for xEdit, for inventing and teaching me The Method and for being patient with me even after the most moronic of questions
- Everyone else in the xEdit Discord for being awesome and extremely helpful, greetings to sheson, Teabag86, yggdrasil75, Chef93, fureundubh and all the others I didn't mention
- CptMcSplody for Unique Region Names, a now must have mod I wouldn't even have had thought I needed until I had it installed
- Arthmoor for USSEP, CRF and a ton of mods you use for every playthrough but never realized they were from him, also for opening my eyes about Papyrus logs
- LostDragonist for always showing up in the right Discord channels when I need help
- hype1 for being the best door creator out there
- me for annoying hype1 long enough to have him upload 8K versions of his doors
- All the people I hate myself for not having mentioned
If you're someone like me who uses MO2, xEdit and whatnotelse on a daily base think about dropping them a few bucks on Patreon. I personally support ElminsterAU a bit but that's not because all the others wouldn't deserve it but as I tend to sometimes annoy the hell out of him with my questions.
Also, if you got any questions, want to delve into the modding community, drop some neat screenshots or just sit there quietly and stalk other peoples' conversations, check out those Discord channels
- Nexus Mods
- xEdit
- Mod Organizer 2 Dev
- Icecreamassassin Mods (that's the people behind Legacy of the Dragonborn and a pretty comfy Discord)
The Method
You've probably all been at a point where you've maxed out Skyrim's plugin limit or even went beyond that using MergePlugins and/or ESL flagging (see below) to stuff in all the awesome mods you've found on the Nexus (and perhaps that other site called LL too). But at some point you've encountered random crashes you couldn't fix. You've had inconsistencies like Unique Region Names only working on certain interiors. You've seen water seams, broken navmeshes, clipping and whatnotelse a heavily modded Skyrim may throw at you.
Perhaps you've given up at that point, deleted your mods, reinstalled Skyrim and started over again. Just to run into similar problems once that new modlist became bigger.
Perhaps you went back to the Nexus and finally read all the descriptions everyone told you to carefully read before. Perhaps you've spent hours and days digging out all the patches for the mods you use. And perhaps this helped. But more probably you couldn't fix every issue and just lived with what you got.
Or you asked people and read tutorials and finally loaded up your build in xEdit and checked for conflicts, looking forward to solve all of them to finally get the neat and tidy Skyrim you always wanted. Just to be shocked about a wall of red. It seemed like every single mod was conflicting with all your other mods even tho you got every single patch you've found.
This is the point where post people (including former me) just go 'Fuck this! I won't spend four hours a day for a month to fix this mess!' and forget about that wall of red. Some chosen few might have actually accepted this challenge and fixed and patched all their mods until all conflicts were resolved. Those people are my heroes.
But there's a WAY easier way to do this - The Method!
Prequisites
- A clean installation of Skyrim Special Edition
You either need to start over with a fresh install of Skyrim SE or take your current build and deactivate all mods so that your plugin load order, again, is vanilla. This might help you going back to vanilla SSE in an efficient way but be aware that guide was written for Oldrim. If you want to be absolutely sure and got a reasonable internet connection just uninstall Skyrim from Steam, delete the remaining folder with everything in it from \steamapps\common\, delete everything Skyrim-related from your My Documents folder and perhaps even check your AppData folders for remains of the tools you might have used in the past. Then reinstall through Steam.
- A proper mod manager
Make sure to use a good mod management tool like Mod Organizer 2 (MO2) or Vortex. I would personally recommend MO2 so that'll be the mod manager I will refer to. For me its pretty self explanatory but people sometimes say it has a steep learning curve. If you're unsure about something this video by awesome channel GamerPoets might help. Or just ask me in the posts section or one of the Discords mentioned above. Nexus Mod Manager is outdated and unsupported by not only me but basically anyone and going by countless posts on the Nexus aswell as countless help requests on Discord seems to have a ton of issues. Manual mod management is even worse, don't even think about it.
- xEdit
Make sure you got an up to date version of xEdit installed, we will need this alot!
- The Unofficial Skyrim Special Edition Patch
Before starting with The Method you should make sure to have the Unofficial Skyrim Special Edition Patch (USSEP) loaded. This isn't entirely necessary for The Method but good practice anyway.
Good Conflicts, Bad Conflicts
The Method is all about conflict resolution. A conflict is a record from one mod overwriting the same record from another mod. There are intended conflicts and problematic ones. Here's examples for both.
- A certain tree might have a size (scale) of 1.0 in vanilla Skyrim. Enhanced Landscapes, which is loaded after Skyrim.esm, might scale the same tree bigger and give it a value of 1.2. As EL is loaded after Skyrim.esm the value of EL wins and the tree will have a scale of 1.2 ingame. This is a desired conflict such as almost all cases where mods overwrite values from the vanilla game, we don't need to fix that.
- When you're facing a door leading to the wilds in an English version of Skyrim the door will always show 'Skyrim'. But if a mod author got a localized version of the game and does his or her magic in the Creation Kit the region records in the resulting mod might be called 'Himmelsrand' or 'Borderciel'. If that mod is the last plugin that changes a record it will overwrite 'Skyrim' with the localized name and you will get those translated names in some locations ingame. That's a conflict we need to fix.
- You're using Realistic Water Two, a mod that changes the water type of alot of rivers and lakes. Let's say you have Arthmoor's Cutting Room Floor loaded after Realistic Water Two. Now, if RWT defines a certain body of water as DefaultMarshWater but gets overwritten by CRF, which might use RiverWaterFlow, the desired value from RWT gets overwritten and you might have a water seam ingame. That's a conflict we need to fix too.
- You have a mod that adds an awesome looking weapon that got totally ridiculous stats. Someone else made an addon for that mod with more reasonable values and that addon is loaded after your weapon mod. In that case the damage values of the addon would overwrite the ones from the weapon mod thus creating a conflict. But as you've installed the addon to do exactly that we got a desired conflict we don't need to fix.
Just ignoring all conflicts and hoping for already available patches to fix them might work on some smaller modlists. But at some point you will encounter strange behaviour, inconsistencies or worse. This is why we're having an eye on conflicts throughout the creation of our modlist. That's the core of The Method.
The First Step
Now that we got USSEP installed, know how many aspects of the vanilla game are touched by this patch and know what a conflict is we can expect to see a ton of them between USSEP and the vanilla game files. But as USSEP is meant to overwrite alot of records in order to fix bugs we dont need to examine them and can just acknowledge all those conflicts to have them out of the way for later. This is done by creating a modgroup in xEdit.
IMPORTANT
Starting with version 4.1.7 the Unofficial Skyrim Special Edition Patch now comes with its premade modgroup so theoretically you could just skip this part and continue with 'The actual Method'. However, as rearranging the guide will take a little while I can only recommend you to actually delete the modgroup coming with USSEP (double click the mod, go to File Tree and delete the Unofficial Skyrim Special Edition Patch.modgroup file) and follow this part of the guide to create your own USSEP modgroup. Or at least read it so you know what modgroups are about.
- Create a new executable in MO2 using the gears icon top left that looks like the one in the screenshot
- Launch the new executable through the dropdown menu on the right side of MO2
This will launch xEdit and have it scan your current modlist for conflicts. After it finishes loading you will see your current list of plugins (Skyrim.esm, SkyrimSE.exe, Update.esm, Dawnguard.esm, HearthFires.esm, Dragonborn.esm and Unofficial Skyrim Special Edition Patch.esp) highlighted in red on the left side of xEdit. Normally we would expand the plugins in that list to see what the detected conflicts are all about but this time we just want them out of the way. If we looked at them we would see something like this:
The master records are the first versions of any record. Record A for example makes its first appearance in Skyrim.esm, Record F is first seen in HearthFires.esm. The conflict winners are the versions of any record that are loaded last and aren't overwritten by another version of the same record. Those are the values you will experience ingame. Everything inbetween are conflict losers, they are overwritten and won't make it into the game.
- Select all plugins. Then rightclick one of the plugins and choose and choose 'Create ModGroup...'
On the first screen you can choose which plugins will be part of that mod group. Make sure all of them are checked and hit OK. On the next page you can enter a name. Choose one that makes sense like 'USSEP' and hit OK. On the third page xEdit wants you to choose a plugin to attach that modlist to. As the modlist is needed for the conflicts caused by USSEP attach it to USSEP and hit OK. On the last page xEdit wants to know which modgroups should be active. On this page always make sure to have all modgroups active and hit OK. This is how the above situation would look after creating this first modgroup:
The modgroup hides all conflict losers of all plugins that are part of the modgroup. What's left are the masters that are always visible when there's a conflict. And the conflict winners.
- Close xEdit and move the new modgroup from your overwrite folder to your Unofficial Skyrim Special Edition mod in the left pane of MO2
This can be done by double clicking 'overwrite' and just dragging the .modgroup file into your USSEP mod. Theoretically you could put it anywhere as long as MO2 got access to it but that way we keep our modlist neat and tidy. If you would deactivate USSEP the according modlist wouldn't be needed anymore. By having it in the USSEP folder you would deactivate the modgroup at the same time you deactivate USSEP. Makes sense.
- Re-open xEdit from your newly created executable again and make sure there are no conflicts left
The left pane which previously showed your conflicting plugins should now be empty. This is because conflict winners overwriting their masters aren't regarded as conflicts and conflict losers in your modgroup are ignored for conflict checking.
The actual Method
Now that we got an empty conflict list you're ready to choose the first mod you want to add. Mods affecting many regions of the game are advised to be added first. Such mods would be Realistic Water Two, Unique Region Names, Missing Encounter Zones Fixed and so on. Theoretically the order of installation doesn't really matter but going from large effect on the game world to small effect on the game world will save you some trouble while resolving conflicts as something like Unique Region Names will cause conflicts with almost every single mod in your list - and that's alot when added late in the process.
What follows now should be repeated for every new mod you add and is the core of The Method:
1) Install a new mod and guess a good position in your load order
Load order guessing gets easier with time. Once you realize that every other player home will overwrite lighting values of Enhanced Lighting for ENB with vanilla Skyrim stuff you will place it before ELE. Putting my Unique Region Names - Arthmoor's Karthwasten below the two mods its made for is pretty obvious. And having a mod changing a few locations like Skyrim Bridges below a mod like Enhanced Landscapes that touches almost every region of the game is a good rule of thumb too.
After adding new plugins I usually clean them with xEdit and the argument -quickautoclean. You can do the same by creating a new xEdit executable like above but with -quickautoclean instead of -veryquickshowconflicts. While I'm at it I check it for errors by rightclicking it in xEdit and choosing 'Check for errors...'. If its full of them I usually drop it right a way and look for a better mod to add. If its just a few and I like the mod I try to fix them which can be a real hassle. Joining the xEdit Discord and asking all the great mod and tool authors in there usually helps. I'll be glad to help out too if I'm online.
2) Run xEdit with -veryquickshowconflicts
This displays all conflicts the new plugin causes. Rightclick somewhere in the right pane, where all the records are listed, and choose 'Hide no conflict and empty rows' to make things more clear and actual conflicts more visible. If we sticked to our example from above you would notice that only Dragonborn.esm, USSEP.esp and our new plugin would be listed as conflicting in xEdit. This is because all conflicts with Update.esm and Dawnguard.esm are hidden by our modgroup and as HearthFires.esm got no records conflicting with our new plugin at all.
3) Go through all the conflicts and check if changing its position in your load order could fix them
If it seems like a change in load order could fix most of them (like when a mod overwrites changes from another mod with empty values everywhere) leave xEdit, change your load order manually in the right pane of MO2 and come back to see if this fixed the issue.
4) Identify the conflicts that shouldn't be ignored.
For example, if a mod defines a water type for a certain area but this change gets overwritten by the water type of Realistic Water Two it can safely be ignored as you want RWT's water type to win. But if a plugin got new entries that overwrite other entries of another mod and the other way around you would need a patch. See an example for this in the screenshot below.
Even tho an overwritten EditorID will only bother us if we're planning to work with Limbwood Manor in Creation Kit it is still a good example what a conflict that needs to be patched looks like. Here, Unique Region Names does its thing and adds a Region record that renames the region (from the regular 'Skyrim') to 'The Rift'. As URN's EditorID line is empty Limbwood Manor's record gets overwritten with nothing. If we switched the position of those plugins in our load order Limbwood Manor's EditorID would survive but URN's region name would be overwritten. As we don't want either to happen we need a patch.
The first step is rightclicking LimbwoodManor.esp at the top and choose 'Copy as override into...'. In the new window scroll to the bottom and choose '<new file>.esp [Template] ESL', that way the patch won't count against Skyrim's regular plugin limit (see below). Then chose a reasonable name like 'Limbwood Manor Unique Region Names Patch' and that's it, now we got our new patch plugin that you can see in the screenshot on the far right side. But in this state it is nothing but an exact copy of LimbwoodManor.esp's records, in this state URN's region record gets overwritten.
For our new plugin to be a patch we should now drag the xxMapTheRift record from Unique Region Names.esp into the empty Region field of our patch. xEdit will ask if it should add Unique Region Names.esp as a master to our patch. This means that the patch can only be activated if URN is activated as it refers to a record that is only present in URN. But that's fine, without URN our patch wouldn't make sense to be active anyway so hit Yes.
This is the result. Our patch will be loaded after both mods and contains the records of both of them. Neither the EditorID from Limbwood Manor nor the Region from Unique Region Names gets overwritten anymore and everyone's happy. Conflict resolved.
As a final step click on your newly created patch in the left pane of xEdit. You should be able to see the masters of that patch which in our example should be LimbwoodManor.esp and Unique Region Names.esp. If one (or both) of them are missing right click your patch and choose 'Add Masters...'. In the new window check the mods your patch is for and hit OK. This isn't entirely necessary but good practice. If you plan to publish your patches everyone using LOOT will thank you for this. As a final touch you can add your name to the author record - congratulations, you're now officially a mod author. Wasn't that hard, was it?
This is basically how simple compatibility patches are created. I know this requires some routine and experience and I'm still unable to fix all kinds of conflicts mself. But when in doubt join the xEdit Discord and ask for help in #cathedral-of-the-method. Don't be shy, this is how I've learned it.
5) Once you've created patches for all conflicts that you think shouldn't be ignored close xEdit and save them
Make sure all your new esps are in the list and checked. Once you're back to MO2 you will find your new patches in the overwrite folder at the bottom of your modlist. Its not good practice to have plugins lying around in there so if you only create a single patch (and you're sure there's no other crap left in overwrite) you can create a new mod out of your overwrite folder via rightclick and 'Create Mod...'
If you created more than one patch the easiest way is to open your overwrite folder in Windows Explorer (rightclick, 'Open in Explorer') and create new folders for all your new plugins. Then drag your plugins into the respective folders and simply move those folders from \Mod Organizer 2\overwrite to \Mod Organizer 2\mods. Once you refresh MO2 (hit F5) your patches will show up in the left pane.
Even tho it is entirely up to you how you name and manage your mods in MO2 this almost empty modlist would be a good point to think about a proper sorting and naming scheme. You will be thankful for this once you got a few hundred mods in your left pane and need to use the search function to find them. Call me an autist but this is how I manage mine:
Once you've acivated your patches the plugins will show up at the very bottom of your load order in the right pane. Depending on lour load order and other patches you might want to change the load order spot of your patch but at least for the first one you don't need to change anything.
6) Re-open xEdit with -veryquickshowconflicts and create modgroups for all plugins with intentional conflicts
After creating all the patches we need only intentional conflicts are left now. For those we should now create modgroups to get them out of the way for conflict checking the next mod. Of course we could just create one large modgroup containing all conflicting plugins but you will realize this isnt the best approach. If we will later disable one of the mods of this combined modlist the entire modlist isnt working anymore and we will be presented with a huge amount of conflicts we will need to re-check. This will get really annoying once your modlist has grown larger.
Instead we will create one modgroup for every two plugins with intentional conflicts. The ConflictingPlugin.esp from our basic example from above got conflicts with Dragonborn.esm and USSEP.esp so we will create a modgroup for each of those conflicting plugins. As you can see, the first modgroup only hides the conflicting Record A with USSEP.esp and the same record from our ConflictingPlugin.esp is the conflict winner in the new modgroup. That way, if the next plugin you add conflicts with Record A, it will only be shown conflicting with that record from ConflictingPlugin.esp.
The same goes for Record B and D from Dragonborn.esm. ConflictingPlugin.esp is the new conflict winner in our second new modgroup and if the next plugin you add will conflict with either Record B or D the records of Dragonborn.esm will not be shown, instead xEdit will only show the conflicts with ConflictingPlugin.esp.
In general, by creating a new modgroup for every plugin our new mod is conflicting with we will hide those conflicting records and only the respective conflict winner in our modgroup will be shown once we add the next plugin that conflicts with one of these records.
Here's another practical example:
Here we can see LimbwoodManor.esp's water record is overwritten by the one from Unique Region Names - RealisticWaterTwo Patch.esp. After checking all conflicts between those two plugins (which can be easily done by checking the records of Unique Region Names - RealisticWaterTwo Patch.esp instead of the LimbwoodManor.esp ones) and realizing that they can all be ignored we're putting both mods into a new modgroup.
The process of creating that modgroup is basically the same as described above in 'The first Step'. But this time, instead of selecting all plugins on the left side and stuffing them all into a modgroup we will rightclick Unique Region Names - RealisticWaterTwo.esp in the headline top right and create a new modgroup from there. In this case only Unique Region Names - RealisticWaterTwo.esp and LimbwoodManor.esp should be eligible for our modgroup but if xEdit presents you with more than two plugins make sure you only select the two conflicting plugins. The rest is exactly the same as described above.
Once we created that modgroup the same window in xEdit should look like this:
Once you've created all modgroups needed to hide those intentional conflicts exit xEdit, sort them into their respective mods and re-open xEdit to make sure the left pane is empty. If so, all conflicts are either solved via patches or hidden by modgroups. If not you should go through the remaining conflicts and repeat steps 4 to 6.
7) Start over again
Once the next plugin is added you will realize why we went through the hassle to create modgroups. Only the conflicts created by that new plugin will be shown with all the stuff from previous plugins out of the way. In the long term this will make conflicts way easier to handle. No more staring at red walls and giving up.
A quick word about LOOT: if you're following the above guide right from the beginning you will not need LOOT. The only thing it will help with is finding the right spot for a new plugin once your modlist has grown large. On the other hand you will need to disable masterlist updates to avoid changes messing around with your manual order. You will also need a zillion of custom load order rules to ensure the right order. This is what I did and it can be a pain in the ass so the most elegant way would be to really not use LOOT at all.
Last but not least a quick word about conflicts that can't be handled in an easy way in xEdit like objects clipping into each other. After sorting and patching my newly added plugins I usually go ingame and check all the locations the new plugins are touching. You should really do this if you're using major landscape changing mods such as brilliant but super incompatible Enhanced Landscapes and try to add player homes or similar things adding stuff to the game world. If I see clipping I open the console (using the awesome More Informative Console), click the object and take a screenshot. That's what I took the screenshot below for. I then go to xEdit, search for the Ref IDs from my screenshots, copy them as override into a new patch (see above) and set their record flags to 'Initially Disabled'. That way those objects won't show up ingame anymore.
Finally a line about USSEP. While I'm checking conflicts of newly added plugins I sometimes stumble upon mods overwriting USSEP changes with stuff from Skyrim.esm. In these cases I just drag USSEP's changes directly into the plugin that does the overwrites and by that create myself an USSEP version of that mod. This is the only case where I directly edit plugins, for everything else you should really create separate patches.
The ESL Flag
How does Skyrim address plugins?
You might have already noticed FormIDs in some tutorial (for example removing cities from JK's Skyrim), while getting items via console cheat (player.additem) or somewhere else but don't know what they actually are. Here's one example:
The interesting part is on the far right side: Base Form and Ref Form.
Let's stick with the tree that I've marked in the screenshot for a moment. The Base Form (00051126) is an entry in Skyrim.esm and stands for TreePineForest05. It doesn't say anything about where the tree is located, about the size of the tree, its rotation or anything else. The entry in Skyrim.esm just defines a few basic parameters of that tree type like the type of the entry (TREE) and where the 3D model of that tree is located in the meshes folder of the game (Landscape\Trees\TreePineForest05.nif).
Now, if you got a mod (or the vanilla game) that places this kind of tree somewhere in the game world, that specific tree (like the one that is clipping through the floor in my screenshot) gets a Ref Form, which in this example is 0D00517E. For this you can define its position in the world, its size, its rotation and lots of other properties. The Ref Form is the FormID we'll be looking at. It can be divided into two parts:
[0D] [00517E]
The first part might look familiar for anyone using Mod Organizer 2 or any other mod manager that shows the load order of plugins like MO2 does. It defines where in the load order a mod is located using a two digits hexadecimal number. The mod with the lowest number gets loaded first, the higher ones are loaded later and overwrite the earlier ones. Your typical load order would look like this:
[00] Skyrim.esm
[01] Update.esm
[02] Dawnguard.esm
[03] HearthFires.esm
[04] Dragonborn.esm
[05] SomeMod.esm
[06] SomeOtherMod.esm
...
[0C] AnotherMod.esp
[0D] Enhanced Landscapes.esp (the one from our example screenshot)
...
As hexadecimal digits go from 0 to F (F stands for 15) and as we got two digits, the largest number you can put together is FF = 255, just like the largest number for the decimal system would be 99. This is where Skyrim's theoretical plugin limit of 255 comes from. Its actually a bit less than that but that shouldn't bother us here. This limit is what forces people to stop adding mods to their game or start merging them which gets trickier the more mods you want to add.
How does Skyrim address records within plugins?
Now, what about the other six digits?
Those are used as addresses for entries (records) within plugins. The tree from the screenshot got 00517E, another tree might have 00517F, some NPC added by the same mod could have 077F20 and so on. These addresses within plugins are hexadecimal too, so the last address and highest amount of objects in one plugin would be FFFFFF, which is 16,777,215 in decimal. This means that a mod author could theoretically stuff over 16 million things (TREEs, NPCs, BOOKs, ACTIvators,...) into one single esp file. More than that isn't possible as we would be running out of addresses again but who needs that many objects within one plugin anyway.
The ESL address format
So, we're maniacs who already added as many mods as possible to our game and already start to get 'Too many plugins' errors from various tools and the game itself. But, of course, there's at least twenty more immersion mods out there that NEED to be added to our mod list. And then there's those 50 patches for all our mods we forgot to install earlier.
In the past this would have been the point where we would have fired up the (undoubtedly cool) tool MergePlugins and trial-and-error our way through our modlist in order to combine as many mods as possible, just so we stay below the magical FF/255 mark. But now there's an alternative. Skyrim Special Edition does not only understand master files (those .ESM files from the main game and large mods) and regular ESP plugins (any other mod) that all count towards that 256 plugins limit but also ESL files (I believe the Creation Club mods come with these) and ESP files with the so called ESL flag. And while pure ESL files suck as they're always loaded first and can't really be sorted, those ESP files with the ESL flags are gold and exactly what we need. They behave just like regular ESP plugins and even look the same from outside but they're not loaded in a regular load order spot like [A4] or [0D] but they're all squished into the [FE] spot, which now is a whole new address space by itself.
[FE:0A8]
This is what the load order address of an ESL flagged plugin looks like. And this is what a bunch of ESL flagged plugins in your load order would look like:
...
[FB] RandomMod1.esp
[FC] RandomMod2.esp
[FD] RandomMod3.esp
[FE:000] RandomESLFlaggedMod1.esp
[FE:001] RandomESLFlaggedMod2.esp
[FE:002] RandomESLFlaggedMod3.esp
...
[FE:0C3] RandomESLFlaggedMod196.esp
[FE:0C4] RandomESLFlaggedMod197.esp
...
[FE:FA9] RandomESLFlaggedMod4009.esp
[FE:FAA] RandomESLFlaggedMod4010.esp
[FE:FAB] RandomESLFlaggedMod4011.esp
...
Wait, what? Mod 4011?
As [FE:FFF] would be the highest address for an ESL flagged plugin and as the FE-part always stays the same as that's the position of the whole bunch of ESL flagged plugins in the regular load order, FFF is the maximum amount of plugins we can have in this address space. And that's a whopping 4096 of them!
This effectively means we're not limited to 256 plugins anymore but to 254 (as the FE-slot is blocked) plus 4096 = 4351 plugins!
The Downside
As you might have guessed there has to be a downside. And of course you're right. As the address of the plugin itself in the load order now takes up five instead of just two digits, there's less digits left to address stuff within the plugin. Instead of six digits (000000-FFFFFF = over 16 million) for records we can use for NPCs, TREEs and other things inside our plugin we only got three digits (000-FFF = 4096) left. This gets clear when we compare them side to side:
Regular: [0D] [000012]
ESL-flag: [FE:00D] [012]
At a first glance this doesn't seam too bad as 4096 is still a large amount of records within a plugin. But there's a few problems that might be in the way. Let me demonstrate with three examples:
Example 1
The hypothetical plugin in position [A4] we want to flag as ESL got three records: 000001, 000002 and 000003
[A4] [000001]
[A4] [000002]
[A4] [000003]
A plugin like that can be easily flagged as ESL as there's less than 4096 records and the records would still fit well into the ESL address space. There would be no issues and apart from setting the flag nothing else would have to be done. The result would look like this:
[FE:001] [001]
[FE:001] [002]
[FE:001] [003]
As the addresses within the plugin wouldn't change, any patches or addons with that plugin as a master would still find the records inside they're trying to reference to. In case you're wondering if the game notices the missing zeros - it does not. Leading zeros are ignored. You can test this by setting the weather via the ingame console with 'fw 0010a243' and with 'fw 10a243'. The result will be the same.
Example 2
The hypothetical plugin in position [A4] we want to flag as ESL got three records: 000001, 000002 and 0FA322
[A4] [000001]
[A4] [000002]
[A4] [0FA322]
A plugin like that cannot be flagged as ESL just like that. The records 000001 and 000002 would be fine just like in Example 1 but 0FA322 does not fit into the three digits address space of an ESL flagged ESP. The consequence of this: we need to compact the plugin to be able to fit in all its records. There's a feature in xEdit that does just that. If we did that, the following would happen:
[A4] [000001] -> no further action
[A4] [000002] -> no further action
[A4] [0FA322] -> changed to [A4] [000003]
Again resulting in
[FE:001] [001]
[FE:001] [002]
[FE:001] [003]
Now all records fit into the three digits and the ESL flag would be set. You can do this to small patches and other uncomplicated mods that got no patches or addons themselves. Once such a compacted plugin got another plugin that's referencing to it we got a problem tho. Something in the other plugin could try to reference to 0FA322 but it wouldn't find anything at that address anymore as that record was changed to 003. This could lead to various annoyances or even crashes. In the end, we would have to manually edit the patch/addon and change all entries of 0FA322 inside them to 003. Which would be really annoying as even small plugins not only got 3 records but dozens or hundreds of them. Still, if we know exactly that a plugin got no patches or addons that rely on it, compacting is still a viable way.
Example 3
The hypothetical plugin in position [A4] we want to flag as ESL got more than 4096 records. This is usually the case for quest mods, large player homes and compilations like Immersive Armors. As our address space within an ESL flagged plugin is limited to 4096 entries we simply cannot set the flag or compact the plugin. Bad luck.
ESLifying plugins
Now, what do we have to do to make use of ESL flags?
First, we should ESLify all plugins that can be flagged without any further changes. For this we will need xEdit, just get the latest version from github. With xEdit there's an easy way to scan your load order for plugins that are small enough and don't need to be changed in order to get the ESL flag.
ESLifying Plugins the easy way
This can be done for all plugins that are like in our Example 1 above. You'll need to start xEdit with the arguments -PseudoESL and -autoload. PseudoESL will display all flaggable plugins, no matter if they already got the flag or not, with [FE:XXX] load order numbers. This will be useful in a minute. Autoload skips the initial dialogue where xEdit asks you which plugins to load.
In Mod Organizer 2 you would go to the executables menu (the gear icon top left) and add SSEEdit.exe as a new executable like displayed on the left hand side. In Vortex it would look like on the right side.
Now start xEdit with those arguments. For MO2 this works by starting QuickESLCheck from the dropdown menu, in the Vortex example it would be named SSEEdit-eslcheck but its really up to you how you name the link. After loading has finished we're presented with our load order. We will now see three types of plugins:
- Plugins like CFTO-Lanterns.esp aren't interesting to us as -PseudoESL didn't give them a [FE:XXX] load order number. This means they can't be just flagged as ESL.
- Plugins like JKs Windhelm Relighting Skyrim Patch.esp got an [FE:XXX] load order number but they also got the <ESL> tag. This means they're already flagged as ESL.
- Plugins like Higher Bounty Rewards are what we need. They got the [FE:XXX] load order number thanks to -PseudoESL but don't have the actual ESL flag yet.
We will change that. Click on Higher Bounty Rewards.esp (or whatever plugins like that show up for you). On the right side of xEdit you will now see some properties of that plugin like the Form Version, Version and Author. What we're looking for is the Record Flag line. The one of Higher Bounty Rewards is currently empty. Right click the empty space and choose Edit. xEdit will present you with a couple of record flags you can set. Of course we will choose the ESL flag and hit OK.
You can now do this to all plugins that got [FE:XXX] load order numbers but no <ESL> flag yet. If you got a large mod list already type '[FE' into the search bar at the bottom to hide all the regular non flaggable plugins like [86] CFTO-Lanterns.esp, then you'll just need to look for lines without the <ESL> flag.
Once you're done simply close xEdit. It will show a window with all plugins you've changed. Make sure all of them are checked and hit OK.
That's really it, there's nothing more to it.
I re-do this check once in a while after adding a bunch of new mods to keep my modlist as ESLified as possible.
Compacting plugins
Once you've flagged all possible plugins with the easy method above you should be fine for a while. But at some point further down the road you might run into Skyrim's plugin limit again. What you can do now is a bit more dangerous so really think about the plugins you do this to. This is what I've explained in Example 2 above.
Just start xEdit the regular way, rightclick any plugin and choose 'Compact FormIDs for ESL'. Now three things can happen:
- If you try to do this to a plugin that already got the ESL flag the option won't even show up
- If you try to do this to a plugin too large to be flagged as ESL you'll get an error saying 'The file contains too many new records for this operation' and nothing happens
- If you try to do this to a plugin with few enough records you'll get a warning
If you get this you've found a plugin that can be compacted. The first line just tells you how many records will be changed. However, you should pay close attention to the second line of that warning. This tells you what kind of records will be changed and that's really important as some kinds of records will somehow break if you try to compact them. According to ElminsterAU you should really avoid compacting plugins when one of the following record types would be touched:
- INFO
- NPC_
If that's not the case for your plugin make sure there are no patches or addons that got it as a master as after compacting those patches and addons wouldn't find records they're looking for anymore.
If you're sure about this too hit 'yes'. xEdit now compacts the plugin and lists all changes in the right side of the window, looking like this:
...
[00:02] Changing FormID [3300B865] in file "JKs Whiterun exterior.esp" to [33000CA3]
[00:02] Changing FormID [3300B867] in file "JKs Whiterun exterior.esp" to [33000CA4]
[00:02] Changing FormID [3300B868] in file "JKs Whiterun exterior.esp" to [33000CA5]
...
Now, if you're REALLY hardcore you could theoretically write down ALL the changes that had been made. Then you could compact plugins that are referenced to as a master too. Then you could check all patches and addons for that plugin for the original FormIDs like 00B868 in this example. And then you could manually change them to the according new FormIDs like CA5 in this example. That way you could basically compact ALL plugins with few enough records and save even more space in your load order.
But be aware that every update of the compacted plugin would break everything.
I've already proposed ElminsterAU with an automated way of keeping track of changed records of compacted plugins and apply them to all plugins referencing to those records but I wouldn't expect the release of such a feature anytime soon. Still, I hope you could save a ton of space in your load order even without compacting everything.