So in the course of releasing my various patch collections, there were multiple instances where people asked me what process I went through, or how I made the patches. As many of my early patches were generated largely via my own stumbling through things as opposed to any specific formal process, I was always hesitant to walk through the process in fear that it might be "incorrect" or inefficient compared to other methods. However, as time has gone on and I've found them used more and more, at the end of the day, if it works, it works. As I'm now putting up my last prepared patch collection, and have no immediate plans to start working on another, I thought I would take the opportunity of typing out the process by which I made these patches, in hopes that others might find it useful for making their own patches, and potentially sharing them with the community at large.

Tools Needed

There are a number of tools which I use regularly which will be referenced as part of this guide:

• SSEEdit - One of the most powerful tools, if not the most powerful, in the arsenal for modders - This is an invaluable method through which users can see what their plugins do, and where they conflict. There are many, many guides out there on youtube and elsewhere which teach how to use this tool. I highly recommend looking into them: this is one area that I happened to stumble through things myself, first getting exposure via some modding install lists, and eventually having used it enough to accurately guess what different fields do, allowing my comfort level to let me start experimenting, and eventually fixing things. Given there's such a large amount of tutorials available, I will not be reinventing the wheel, but I also recommend checking them out
• Creation Kit - Definitely no avoiding using this. It's a wonderfully robust tool for loading in plugins and manipulating data in-game. I was hesitant to use this early on for fear of what all it might be changing that I might not be realizing, but for more complex changes, or changes involving landscape or navmesh, it's 100% necessary. The link goes to a wiki guide that will walk through how to install it.
• SSE Creation Kit Fixes - But seriously, don't even bother without using this. Most important for our case is "- Ability to edit plugins with ESP files as masters without them being removed." but there's so so SO many quality of life changes which are present in this that I can't even imagine mucking around in the Creation Kit without it at this point.
  

Not strictly necessary, but highly recommended:


• Mod Organizer 2 - Or another mod manager which contains a profile feature, allowing you to have separate virtual installs with different mods enabled/disabled on the fly. This is important not only for maintaining your sanity and your computer's RAM while trying to work on things, but also for the quality of the work itself. By using the profiles feature, you can restore a "vanilla" profile and only enable the mods you want to be working with at any given time. Even mods without plugins can factor, as is evidenced by my first COTN Dawnstar - SFCO patch: I had a mesh/texture replacer for banners, which changed them from rectangles to triangles. As such, in MY install, the moved paintings were not clipping with banners, but for anyone who DIDN'T have that replacer, the banners were overlapping with the paintings. Remove. Variables. If you want to upload something, you want it to work in isolation, and let the end user resolve any quirks on their end.
• More Informative Console - I can't begin to state the amount of time this mod has saved me when debugging problems. Just open the console, click on any item, and it says what the last thing to modify it is. It's useful for debugging on my end, and it's INVALUABLE to recommend others install so they can quickly say what the last thing to touch an object is if they're running into problems. First question for any person running into problems is whether they have this installed and can give a screenshot with the object in question, provided it's available. Huge, huge, huge help.
• Two monitors. Seriously, it helps SO MUCH
  

Permissions

So this section needs to be right at the top, and is also liable to be one of the biggest points of contention. Nexus terms, when it comes to patches, are that if you are modifying what any other mod is doing, you should seek their permissions before doing so. Many mod authors have open permissions for patches and freely allow patches. Many others are more than happy to allow others to make patches if the request comes. Some others want to verify that you know what you're doing, and some just don't want to muddy the waters: frequently end-users will use one patch or another which were poorly constructed, and will complain to the original mod author when things don't work. Generally speaking, however, Nexus does not REMOVE patches unless requested by the parent mod author.

My personal stance is that we should always err on the side of honoring these desires: every patch that I have uploaded is either a) a patch for something which has open permissions or which I have gotten explicit permissions to upload (in some cases provided the patch behaves only in certain manners), b) a simple CR patch where all I am doing is forwarding the original mod's changes ensuring they make it through without modification, c) an update to an existing patch which I got permission from the person who MADE such patch, but which has the implicit assumption that the parent mod authors granted permission to the first person, and d) cases where I do not touch the assets/packages/etc from a mod which I do not have permissions for, but modify shared resources (navmesh and landscape) to ensure the mods play well together: landscape and navmesh are broken into discrete sections (ie, cells), and two different mods may not directly interfere with one another, but conflict on these records because they cover a specific "area." This is the only wiggle-room in my rules that I give myself, and The Great Village of Old Hroldan has an example of this case with Soljund's Sinkhole: my patch does not touch Soljund's Sinkhole's items whatsoever, but does modify landscape and navmesh to allow both mods to work harmoniously.

Now, if making for personal use, you do you - I've got plenty that I will never upload but that I've made for myself. But I wanted to put this way up at the top: we are part of a community, and this is the standards which are currently in place. While you may desire change, and can lobby and encourage for that change, until such time that the change is in place, it's in everyone's best interest to maintain good relations all around :)

My Process

Interiors

So there are many processes out there which I have since learned about, such as Method Patching. I learned about this after I was already doing my own thing, and they largely overlap - Method Patching seems better, using modgroups and other such features to simplify things. I recommend checking it out! But I figured I'd walk through my own insanity anyway :)

1. Load your entire load order in xEdit, including the mod which you intend to make patches for. Have a text document open to note which mods you will want to work with. Ignore Cell and Worldspace for now, but look for conflicts in other areas. The Great Village of Old Hroldan has only items which TGVoOH adds itself, so there are no conflicts (the last one is something generated by DynDOLOD in my case, so it can be ignored). As such, no generic CR patches with these areas are needed. There's tons of guides for resolving conflicts on NPCs, statics, and various other things which may need a Conflict Resolution patch, so I won't go into further detail for now.


2. Now we turn to look at Worldspace and Cells. I would start with Cells, as they prove to, generally, be simpler, particularly if you end up needing to deal with navmesh. Expand every Cell Block and Sub-Block, and then highlight every cell which has color, noting down any mod which appears in the right pane. For example:



So first we look at Old Hroldan Inn.



We can see here this cell was originally created by Skyrim.esm, then touched by USSEP, 3DNPC, LOTD, Skyrim Underground, ELFX, a USSEP-3DNPC patch, SFCO, a private merge (I can tell you right now this was Embers HD), and it continues to scroll off to the side. I note down every mod here, then every mod for each one of the other cells which has color. This does NOT mean that all of them need patches - what the presence of a mod in this field indicates is that they either modify the cell settings, or they either manipulate or place a reference/marker/NPC within the cell: This is essentially going through our entire mod list and highlighting anything which has the POTENTIAL to need a patch. For mod which re-do the entire interiors (COTN, TGC, etc being common examples), this will TYPICALLY mean that they do. Patches will generally be needed for two reasons:

• Load order related - two mods both move the same object. Generally speaking, if something is doing a small tweak and another is doing a complete overhaul of the interior, forward the overhaul's changes. Just use your brain
• Newly added items, which need to be moved to match the new interior.
  

3. Check to see if someone else has made any of the patches you think you might need. No point in doing work if you don't need to!

4. Once we know what mods we are working with, make a new profile in MO2. I have a "vanilla skyrim" profile which is where I do my testing, and it consists of just the cleaned original .esms, SkyUI, SKSE Scripts, and More Informative Console (just so I have them available if needed). Then, I enable all of the mods which may be relevant to making the patches. This stripped down modlist will load faster, and will also result in less items which can serve as distractions. Running LOOT at this stage is also a good idea, as that's what end users will frequently use, so you end up with the same general order.



5. Now, this isn't universally what you want, but frequently it's useful to show only conflicts. Right click anywhere in the right panel and choose "Hide No Conflict and Empty Rows." Looking at the Cell itself, we can see there's some conflicts on cell settings: many mods change the Acoustic settings from stone to wood, and TGVoOH changes the lighting to use Solitude lighting (presumably because it uses Solitude assets).



6. Now, use your head: Yes, this is a conflict, but in this case many of the mods are .esm, so TGVoOH will always win. So individual patches for the Solitude lighting isn't needed for, for example, Skyrim Underground. Additionally, think about how TGVoOH changes the buildings: does wood acoustics or stone acoustics make more sense? If you feel a cell setting CR patch is necessary you can start here. I have a private smash/bash/etc patch, so I generally don't always upload these, since I take care of these things myself. You may want to do the same. Next, we start running through what's added by each one of the constituent mods. So let's take a look at USSEP.



7. Looks like USSEP edits the navmesh, and touches a bunch of items, but does not add any new references. Once more: use your head. USSEP is an .esm, TGVoOH's placement of any object conflicts will ALWAYS win. Running through these, literally everything is a conflict where USSEP moved something, and then TGVoOH also moved it: a patch is not necessary, TGVoOH wins all conflicts. With a single exception: 000EB5A0.



8. In this, USSEP changes the bed to be a child's bed, and also shrinks it. TGVoOH moves it. So to match the vision of both mods, in tandem, we would want the bed in the new location, with the changed type/size. So what we would want to do is the following - Right click, choose "Copy as override into..."



9. Select, down at the bottom, ESP flagged as ESL (ignore my case where I have my USSEP patch already above :P) *Note for later: Just choose <new file>.esp if you're expecting to deal with navmesh or will be adding references yourself. Just an fyi*



10. And provide it the name you want:



11. Voila, you now have a patch which has that record. Drag the values from each one you want to make the CR patch, and that should be the resolution. We'll want to check it in-game/in the CK, but this is the simplest form of patch. However, because you modified an item in this cell, you now have a Cell entry too. You'll want to go back and make sure the patch has Cell settings which you want.



12. There is one additional step which is needed when making these sorts of compatibility patches which involve only items from Skyrim.esm itself: adding masters. On the left panel, right click on the patch which you have created and choose "Add Masters". You'll then want to select both mods which are the "masters" for you, which will ensure the patch gets loaded after both of the other plugins.



13. So then we move on to the next mod touching this cell: 3DNPC. It has nothing which it is touching that already existed in the cell, but it has a LOT of new references which are added



14. So, in order to be thorough, the most useful thing to do when starting out is to right click and add ALL of these to a new patch. Anything which doesn't NEED to be touched can be removed later, but this effectively creates a patch which is "worst case scenario" with everything you need to modify, which has the LOVELY benefit of marking them with an asterisk when you load them in the Creation Kit.

15. So we run through all of these steps with every mod, creating "framework" patches - some of them are already complete, others are not - for internal cells. At this point, instead of repeating the process with Worldspace, I switch to work in the CK. It breaks up the work a bit, and the tasks necessary for internal cells and external worldspace are a little different, so it makes for a convenient breaking point.

A quick aside about Persistence

So in many of the conflict resolution patches you may make, a common conflict is that one mod (for example, 3DNPC is a frequent participant in these) will mark a reference as "Persistent", while another mod will move it (say, if re-arranging an interior). The CR for this is to forward the persistence marker, and everything works fine. What Persistent markers imply is that reference is used by a package or a script or a quest, or something else along those lines: they are typically (albeit not always) important. Some are simply sandbox markers which are available to a package, while others are specific markers which are necessary for a quest or other package to move forward. For example, in Dawnstar, there are lean markers which were around in various fences which are removed as part of COTN Dawnstar because those fences no longer exist. 3DNPC marks some of them as Persistent, but after discussing with the current manager of the mod, it appears they were only used as "random chance" sandbox options, so keeping those markers as removed has no negative impact, so the 3DNPC patch does not restore them. ETaC, on the other hand, contained an NPC package where a specific NPC had specific tasks at different times of day, one of which was going to a specific rail lean marker and staying there - without the marker, the NPC would T-Pose, so I needed to come up with a solution (which didn't involve the fence) which would restore that marker in that case. So as a general rule of thumb, if you're making a patch and one of the mods marked something as Persistent: ensure that reference makes it into the end patch, as a persistent reference, and try to ensure that where it's used makes "sense" relative to the initial intentions of the mod.

As a corollary, for any mod authors who happen to read this: if you want to make things easier on patch makers, please re-use references wherever possible. Instead of disabling a chair and placing a new one, re-use an existing chair. If there's a bench which you want to replace with a different type, instead of disabling and placing the new bench type, take the same reference and change its base reference type to be the new bench. That would allow the patch makers to simply need to forward the persistence, instead of having to disable and re-enable various objects, or edit packages/quests to point to new objects. As far as I'm aware, there's no easy way to do this in the CK itself, sadly, but this functionality can be done in xEdit. Now, there is absolutely, 100% nothing wrong with doing things that way: it is not any mod author's responsibility to expect that any specific object they use or disable would be utilized by another mod: that's why we've GOT patch makers in the first place. But it'd sure make my life easier ;D

16. So now we open the CK. This is where the dual monitors come in handy (frankly, 3 would be useful). For simple patches, like the USSEP one where we had simply changed one bed, we can open up a single instance. Find the patch you're working with, select it, mark it as the active file (this means that any changes you make will be saved in this plugin)



17. Next, go to the cell in question: In the Cell View tab, double click on the cell we want: OldHroldanInn. It should be marked with an asterisk.



18. Finally, find the reference in question in the right panel: 000E5BA0. You can sort by FormID and scroll to it, search for the reference ID in the top bar (so just type in 000E5BA0), or filter by reference type (so "bed" would be a string you can use to narrow it down). I tend to just sort by formID and scroll, for reasons which will be clear in the next section. The reference itself should also be marked with an asterisk



19. This brings up the bed in the render window. We can see...hey. It's a small bed. It looks fine. Honestly, that's all we really need to do, but as a sanity check it can be useful to pivot around it to make sure it's not floating or anything like that, and also to pull up the navmesh (I circled the button in red, and have done so, in the screenshot above) to make sure any markers which are present which need to be over a navmesh for an NPC to use a reference, are accessible. In this case they are, so we're done. Everything looks good!

20. Now let's consider the 3DNPC patch. As opposed to a simple CR, this one is more complex. It had a bunch of references which were NEW, as opposed to modifying some that already existed. So instead of pulling up a single instance of the CK, let's pull up two. In one of them, we load up JUST 3DNPC: this gives us the vanilla inn, and we can see where the references are placed relative to the Inn's layout. In the other CK, let's load up our patch like we did in the first example, and take a look at what the markers look like. So we go to the same cell, OldHroldanInn, and in the reference ID panel, scroll down to the 3DNPC ones - this is why I tend to sort by FormID. They'll all be grouped together. Let's look at the Asteria60to70Stage reference looks like (presumably a field used which, when triggered, causes a quest involving Asteria to move from stage 60 to 70) Here's what the two windows look like:



21. ...well THAT doesn't seem right! The quest stage is in the middle of a wall (although overlapping with a room), as is an Xmarker Heading which is also added. But in fact, if we scroll a bit to the side, we'll see a cluster of other markers, and even an NPC reference just floating out in the void. The NPC reference itself isn't the end of the world (I believe engine behavior is that it'll be confused for a second and then pop the placed NPC to the nearest location which has navmesh), but those other markers? They're inaccessible. A lot of the time? No big deal. If it's needed for a quest? Big deal.



22. So then this becomes the task: move all these references to places that make "sense," matching the original behavior. So the quest field was in a room - but WHICH room? Well, the easy way to tell that is to click on the bed, and find out which reference it is: 000E59BC. Does the new inn layout have this bed? Why yes, it does! So my default expectation would be to set the quest trigger over that same box. Except....3DNPC doesn't touch that bed to make it persistent, or anything else along those lines. But TGVoOH DOES do so. It changes the ownership of the bed from OldHroldanHangedManInnFaction (which contains Leontius Salvius, Eydis, and Skuli) to be specifically Eydis. Well, that seems fine....maybe. But let's make sure. Interesting NPCs is both a pain because there's SO MUCH, and a blessing because there's so much INFORMATION on their website. We see here AsteriaQuest is The Raven of Anvil, and looking at the stages 60 and 70, it appears that the stage transition happens upon your return with a given list and that Asteria will be at the XMarkerHeading (judging from package analysis, etc) - so what's important is less the box being in a room with a specific bed, but rather that the box has the XMarkerHeading inside of it, and it's in an accessible location. So putting it by that bed should be fine: for consistency's sake, let's do so. When moving an object, hotkeys are frequently useful: Z, X, and C, if held, will ensure that you only shift on a single axis (C is Y axis), right mouse button rotates, and those same keys change which axis is rotated around. There are many other hotkeys (E, W, etc) that may also come in handy - check out the CK documentation. Similarly, the other markers (the lean, etc) are all around the fire, so let's place them by the fire:



23. And then, once we've moved and re-oriented everything, save the file, and voila: patch made. When moving references, sometimes it's useful to toggle markers (M) or Lights (L) to simplify what's visible, but remember to re-enable them so you don't miss anything. At this point, quick auto-clean the patch in xEdit, which will remove anything that WASN'T changed, and you're good to go. And yes, I used 3DNPC as an example although all credit for it should be given to cheesetoast8 for having made the 3DNPC patch, and thanks for the permission for letting me use it as an example, because it highlights exactly why you have to be careful when looking at what patches need to be made: the NPC references would cause them to spawn onto the navmesh, so you'd see the added NPCs. But literally every added marker except (amusingly enough) the quest stage 60 to 70 is a Persistent marker: they quite likely matter for the quests. But you'd never see them, as markers are invisible, and a lot of them are COMPLETELY inaccessible with the new building layout: all those quests would be broken without a patch, and you'd be none the wiser. It's why you need to be careful, and attentive, to what's needed for these things.

24. That literally covers the gist of everything that's necessary for interior patches, aside from navmesh conflicts: Use xEdit to create the initial patch with the objects you probably, or possibly, need to modify. Do CR where possible in xEdit. Load the patch up in the CK, manipulate as needed to match the new interior. Save, then clean. Lather, rinse, repeat. As you get more comfortable, it CAN be faster to load up a number of different parent mods at the same time in the CK, move the objects, then type in the changes in xEdit, so you can make multiple patches simultaneously. If you right click on any reference, you can get the location and rotation data on the 3D tab:



Now, if you choose to do so this way, a typo can completely throw things off, which I've done MANY a time, so be careful. Additionally, this "edit" panel is where you can easily disable objects, by clicking the "initially disabled" check box. Quick auto-cleaning also sets Z to -30000 and the enable parent to opposite of player, so if you want to be thorough in removing objects, that's what I'd recommend doing. Now, when it comes to navmesh editing, rather than trying to type and explain it, it's far more useful to check out some of the many youtube tutorials that are out there. This was the first one that I watched, which was more than enough to get me started experimenting. The important thing to keep in mind is that if you edit navmesh, you NEED to finalize it, and you'll likely NEED to re-compact your plugin using xEdit if you want it to be flagged as ESL. Similarly, lighting is a bit more complex, and you're better off watching some youtube tutorials - I'm not that great at it, and probably shouldn't be explaining my process (getting rid of flickering takes me FOREVER ._.). The one piece of advice I'll give is that it's useful to scale the size of light bulbs by pressing and holding the S button while left-click dragging on the light source, as that "scales" the object. Any reference can be scaled this way, but I primarily do it with light radii.

25. If two mods completely re-do an interior in different ways (ie, they both make it unique somehow), a harmonious patch isn't always possible, so sometimes a patch will simply remove all changes from one mod, and forward all changes from the other. If you're going to do this, honestly, it's best to make sure that the mod author whose work you're hiding is okay with it - usually, they're part of some larger series (Distinct Interiors is a common one I ran into, as it unique-ifies many interiors throughout Skyrim, instead of being focused on a single locale) and may be fine with it, but some folks don't want that, and it's best to honor their wishes and not make such a patch. Additionally, they might be aware of some items which are referenced by script, or something else along those lines, and for better stability you can disable everything BUT those objects, and make just that small portion work. Additionally, as noted before: use your head. If something is made persistent, it's probably due to a package or quest - you may need to keep those specific items around, at least. Double check to make sure.

For completely re-doing interior in a new style, I'll cover that after doing general patches in worldspace.

Speaking of which, now for Worldspace.

Worldspace

1. Worldspace largely starts the same, there's just a few extra things to have to worry about. Specifically, persistent references, landscape, and navmesh. As with interior Cells, we need to look at a given cell to see what interacts with that area. However, in addition to the cells, there is a "Persistent Cell" which contains all persistent references. These have to be gone through manually, and complicates potential conflicts, because EVERY mod which places a persistent reference anywhere in Skyrim (or marks a reference as persistent) will touch this cell, so we can't use the column listing here. Rather, I rely on the OTHER cells, and going through them. The real issue is that, due to this, it's effectively necessary to go through each mod individually, look at their persistent references and verify what areas (based off coordinates) they're placed in, so you can make sure they don't conflict - city overhauls will frequently stick a LOT of stuff in exteriors, so conflicts are common.



On the plus side, many times cells which are touched aren't touched by anything else, like the last one above. Enjoy those cells! They're great!

2. At this point, we do the same as the above: run through any of the mods with conflicts, look for conflict resolutions which can be resolved, and for anything else/any added objects, put them into a patch (whether existing from interiors, or new for exteriors) to look at in CK.



(The second of the two above is from an already-existing patch that I made, but it was a reference that was copied into the patch before I moved it in CK).

There are two special reference types we have to be aware of, however: landscape and navmesh. Landscape contains two major pieces of information: the 3d mapping (shape) of the landscape, and the texture (how it looks) of the landscape. If two different mods touch the landscape in the same cell, even if they do not directly conflict with their changes, they will conflict and whatever loads last "wins." There is no simple way to resolve these in xEdit, and instead it needs to be resolved in CK. This is exacerbated with grass mods, as they frequently will change the behavior of some textures to have grass which otherwise would not, which can lead to a "conflict" which doesn't show up in xEdit itself, because maybe they don't even re-paint the landscape in the first place, but all of a sudden grass is appearing where it shouldn't be. Similarly, in the case of navmesh, even if there is no conflict on navmesh, sometimes it needs to be changed to avoid placed objects or to match the new landscape. As such, I treat landscape/navmesh conflicts as "separate", and to be approached last.



3. So at this point, we go back to what was previously done in the cell: load up one CK instance with vanilla and the mod you're patching for, the other with the mod you're patching for and the base mod which you're generating patches, and then for the REAL tedious part: run through everything. In exteriors, sometimes references are placed but now they're embedded in rocks or landscape. Sometimes markers were added, but they're inside walls or inside the ground. Basically, you need to go through every reference touched by the mod you're patching for, and ensure that they make sense. This is time consuming! It's annoying! But if you want to do things "right", it's time you should take to do. I find it useful to run through and mark which cells a given mod touches ahead of time, so I can load up and run through everything for USSEP, or everything for Lanterns of Skyrim, or something like that - all in a single pass. As discussed, landscape and navmesh is by-and-large ignored at this stage, but I make mental notes of everything which was modified (or not modified as the case may be), because once we GET to landscape, there may be additional touches which are necessary, even if only for personal use (3, 4+ way patches).

4. So now we come to landscape and navmesh. For Old Hroldan (at least for those which I made patches for), by and large there were no real issues in landscaping...Except for Soljund's Sinkhole. Yes, there were conflicts with Verdant (my grass mod of choice), and Landscape Fixes for Grass Mods, but those are both painting the landscape to have/not have grass - that's clean-up I can do for myself after the fact. Soljund's Sinkhole, on the other hand, we run into some issues. Now, with Landscape, sometimes it's worthwhile to try out different load orders to see if just having one of the two mods "win" will resolve any issues. Here's Soljund Sinkhole's landscape winning:



...well that doesn't look quite right, with that divot in the ground. The floating door also looks off, but that's actually marked as disabled, it's just not set to Z of -30000, so it still appears in the CK. Protip: Always set the Z to -30000 so there's not phantom floating stuff that wouldn't appear in game ;) Additionally, it modifies the navmesh, so a different triangle is tying into the door, which means the door was also modified. While we're at it, here's the navmesh:



So the door's not tied in, but that's not surprising given the new layout, but the entire garden is completely not navmeshed (even if the door wasn't there). That's unfortunate. On the other hand, if The Great Village of Old Hroldan wins everything:



...and that ALSO doesn't look right. Landscape has completely overtaken the porch, and the navmesh completely ignores the existence of the well and the deck added by Soljund's Sinkhole (understandably). And thus a patch becomes necessary.

5. I'm not going to talk through the details of how to do this. Navmesh is covered by that youtube video I've already linked, Landscape has similar tutorials but is also pretty easily learnable just by messing around. However, there IS the question of how best to approach it. Now, I start out by making my patch the same way - copying a reference into a patch in xEdit (although in this case, as I'm going to be re-doing a good bit of navmesh, I don't flag it as an ESL immediately, as when you add to navmesh/re-finalize it, sometimes the reference IDs that CK chooses are outside the ESL bounds, so it's better to leave it as a plain ESP and compact it afterwards). But the question becomes: which do we start with? In this case, less manipulation is strictly necessary if we started with Soljund's Sinkhole's, so that would be my immediate inclination. And thus, we take that landscape and navmesh, load up our patch, and smooth the landscape accordingly and add navmesh triangles for the garden, do the edge check, finalize the navmesh to tie in door markers, and voila:



A lot of this is artistic flair - I'm not the best at it, but I can make it functional. Others, I'm sure, are much better at making landscape work, and they have my utmost respect. :) I also sent that door down to -30000 just for my own personal convenience. A couple quick notes: make sure to rotate the camera and look at everything from different angles. Navmesh and landscape can be deceiving! It's pretty important to not simply trust that you did it right, but rather load the game up in a new save, coc to the location you've been editing, console yourself a follower, and run all over the place to find places where the navmesh doesn't behave correctly. If there's NPCs who are supposed to move in and out of houses, wait until it's time for them to do so, and verify that they do. Which, in turn, leads to YET ANOTHER conflict case, which won't show up in xEdit: what happens if two different mods, for example, add a bed for the same NPC? Well, Old Hroldan and Soljund's Sinkhole both do so for Perth. Soljund's gives him his own house, with a bed he's supposed to go sleep in. Old Hroldan adds a place for him to sleep in the Miner's Barracks. Without properly managing load order/conflicts, some things added by one mod would be completely ignored. Given the constraints that I am placing on myself re: permissions and what I can do without them, this means there must be a strict load order of TGVoOH and SS in order to get the correct behavior.

And also, just as importantly, look at the green lines in the background of the above image: that is the cell barrier. Worldspace navmesh only fills the current cell - it interfaces with the navmesh of other cells at those cell edges. Navmesh MUST be finalized in order for NPCs to be able to cross these barriers from cell to cell, and when you finalize it updates the bordering cells' navmeshes to note the edge triangles they cross over into. This has a major implication: unless you are EXCEPTIONALLY careful and manually clean things afterwards (do NOT do this unless you know what you're doing), any time you modify worldspace navmesh and save, you're actually modifying 5 cells' worth of navmesh: the current one, and each of the adjacent ones. This has the DIRECT implication of causing potential conflicts with other mods you may not expect. For example, despite not being in the same cell, or really even that near one another, The Great Village of Old Hroldan has a navmesh conflict with Apachii's Divine Elegance:



Now, this can be resolved via load order, so I didn't make a patch, but just remember: load order matters! These things are not readily apparent unless you take the extra effort to figure 'em out! All those times your followers disappeared, or there's some folks just standing in the road and you don't know why? It's something like this. You move on, but if you want a stable, complete build, you need to take the time to suss these things out. It's not always worth the extra effort! I originally planned to try and do it all, but I've hit the "screw it, we'll play it by ear" stage, so this is absolutely a case of "do as I say, not as I do." But it's good to be aware of.

Combining City Overhauls

Okay, but this is the REAL thing everyone wants. There's these five city overhauls that make Angi's Mill just look incredible in different ways and I want ALL of them even if it doesn't make sense for it to be bigger than Whiterun. How do I do that?





Don't.














....no, but seriously.

A lot of the interest in my patch collections predominantly came from when someone made a unique architecture type, and I applied those aesthetics to other city mods. They're great! I get it! They're also super time consuming, very dependent upon the quality parent mods (and in many cases making the patches will disillusion you about various other mods you currently like), and take a lot of patience. A single city overhaul patch takes about as much time as literally every other patch I make for a given city, combined. Doing multiples is....well, they scale up rather quickly.

Don't expect for your first try to work. Don't expect your SECOND try to work. I think I started, then stopped, 3 or 4 different times on the first COTN Dawnstar - Great City of Dawnstar patch, and that was explicitly having a model to work off of, where someone else had already made a COTN Dawnstar - JK - Great City patch that I was able to use as a reference. Without that guideline, I don't know whether I'd have EVER gotten comfortable enough to release anything. That being said, here's the general way I tend to tackle them.

1. Enable both mods, run around town in-game and look at them. See what is obviously clipping. Take screenshots, so you know the obvious things to look for. Any static you intend to change, open the console, click on them, get the reference ID and the base ID. Take screenshots of THAT. Once you get used to the process, you can bypass a lot of it, but for your first attempt, be THOROUGH. Here's some example shots of COTN Morthal - Great City of Morthal. Dawnstar was honestly a bit easier to work with than Morthal (less vertical navmesh changes), but I was also far less experienced and I started writing my examples using Dawnstar and ran into a bunch of "NO, I WAS STUPID WHEN I DID THIS, DON'T DO THAT" things so....we're gonna use Morthal ;D



So we've got a scaffold - COTN Morthal contains new scaffolds, so we want to replace that. We've got a farmhouse - COTN Morthal has farmhouses, so we want to replace that, too.

2. Open up xEdit. Now we start making our patch. Start how you would any CR patch, albeit not flagged as ESL: know which one you want to win (typically the one with different aesthetics), and let it win EVERYTHING. Except landscape and navmesh, potentially. Some of that may be interior, although in this specific example that's not the case. This is just SOME of the conflicts between COTN Morthal and The Great City of Morthal



This is actually not that many direct conflicts! Think about what needs to be done for any given cell - COTN Morthal alters the layout quite a lot, since the footprint of the buildings is quite different, while TGC adds walls and other objects which may have conflicts. Copy all of these into the patch, give it your best shot at which should "win", and then go through all of them, one by one, to make sure your choices make sense. Do the same with navmesh and landscape - in this case, TGC did far more editing of landscape, and far more navmesh changes due to added walls, etc, that I used it as the base: Morthal was a TON of work no matter which is chosen, but frequently there will be one mod which will be more or less work if you use it as a base. Use your head.

3. Now we find the ones we want to replace. So our scaffold was 06002138. So we find that, copy it as override into the patch. Make sure the patch has both masters set in the way discussed. And now we're going to change the base.



And now that scaffold is the new type! It's that easy! (It's not that easy - we still have to move it). Repeat the process with the farmhouse:



And now we get to the "fun" part. I won't have as many pictures through this section, as I'm not going to completely re-create the patch as I talk through this.

4. Open the Creation Kit, and load your patch as it currently exists. Items which are already part of the patch will be marked with asterisks. Start by taking care of those. Work one cell at a time, but be aware that some objects may straddle or move between cells and that's perfectly fine. Don't worry about landscape or navmesh at this point. Keep in mind that any bases you changed may have different bounds than their previous ones, different scales, and different rotations - don't be afraid to manipulate things to get them looking "right." In the case of buildings, check out what's around them: did you accidentally shift a building to a place that's covering something else up? Move those things so they're accessible again. KEEP MARKERS ON. It clutters the screen, but they need to be accessible too, and if you move a lantern, you should move its light cone at the same time so the emittance stays the same position relative to the lantern. For farmhouses in particular, look at how doors are done in the previous houses: do you need to scale them slightly to fit the new shape? When placing new buildings, I try to keep doors stationary and match the building to the door - this frequently results in an end-point where the mods can be loaded on existing saves (although they shouldn't, but it sure does cut down on requests for support ;D), because doors are persistent.

5. Once you've done that, it's time to start looking at those major clipping areas. These are a bit harder, and it's important to keep in mind what your end goal is. If you're doing it for personal use? Blanket removing things is always an option and it's quick and easy. However, if you want to upload it, it's important to keep in mind what you're trying to do: this is not just "I would like to be able to use these two mods." It's "these two mod authors had a specific idea in mind when they placed this thing. How can I modify this conflict in such a way that best respects that intent?" Sometimes that means keeping everything in-tact, but shifting to a slightly different location so it can fit. Sometimes that means disabling part of it, but adding a new access point. Sometimes that means moving something, but ALSO adding something new. Don't be afraid to ask the parent mod author for their thoughts: If I hadn't asked wizkid about adding poles for my COTN Dawnstar - Lanterns of Skyrim II patch back in the day, I likely would have ended up uploading something which didn't properly hook into the MCM, but he was kind enough to ensure that my patch had what was needed, and that's how I learned. It's also useful to get feedback so you don't end up doing something silly like this ;)



At the end of the day, you're taking someone else's work and putting your own spin on it: try to be respectful of original author intent, wherever possible.

6. Once you've got the layout looking right, and you've got your markers aligned, we get to the fun part: landscape and navmesh. Landscape is often not TOO bad - you've chosen one as the baseline (DON'T mix-and-match, or you'll probably have seams at the cell edges and need to smooth those out), and as you were placing/moving objects you likely noticed any areas that need some tweaking. Do so. Navmesh, on the other hand....*sigh* This will be a "try, try again" sort of thing.

7. Do it one cell at a time. Pick a cell, start at an edge, and do what manipulation you need to. Work with vertices wherever possible, instead of dragging entire triangles. Pay attention to height: try to keep at ground level, or ever so slightly under. If a wall is put in which completely bisects a navmesh, make sure to clean out triangles so NPCs don't try to walk into it. If a wall is removed, DON'T CONNECT TWO VANILLA NAVMESH. Combining them in this way will make one large navmesh, and delete a vanilla navmesh which is BAD. No later patch can restore a navmesh that is deleted. This is made all the worse if you happen to combine a navmesh added by one of the mods with a vanilla navmesh, because the CK likes to delete the vanilla navmesh and carry through the mod's. This is BAD. We don't want this. Getting everything working right, with nothing deleted, and all edges happy, is going to take some significant effort. You won't get this done in one, or two, or five sittings: it will likely take multiple weeks.



This "Check for Errors" option is really useful for finding navmesh problems as you go. Definitely make liberal use of it. It'll also catch any times you happened to add objects after compressing to ESL and you have an ill-formed flagged ESL, so you can fix that. :)

8. As you finish each cell, do the edge-detection and finalization, then save. Sometimes you'll get frustrated and chuck the whole thing and start over: that's fine. Better to do it slowly, over and over, until it's right than to release something which is broken. Once you've got something which looks right over the entire town, test, test, test. Load up the game. Console yourself a follower. Run all over town and watch their routing: any spots they won't go to? Navmesh problem. Any places they get stuck? Navmesh problem. Follow each and every NPC on their daily schedule - do they choose some weird-ass route through town to get to their home at the end of the day instead of the obvious route? Navmesh problem. Do they just stand around instead of going home? Navmesh problem. Do they MAKE it home, go inside, then not come out the next day? Navmesh problem. Test, test, and test again. This is compounded if dealing with something which involves a specific pathing for a quest: Finding Helgi and Laelette, which involved extensive navmeshing and landscape working behind Highmoon Hall, took me literal weeks to get the routing on that mountain path to work right, as the corner involved four different cells all having edge-connections in the corner. "Close enough" doesn't happen here if you want to release for consumption: better to not release than to not get it right. Watch youtube tutorials. They'll give you much better examples than I could in text and screenshot format, regardless.

9. So once you're satisfied with the exteriors, it's time to move to the interiors, when you're dealing with unique architecture. You want the interiors to match those fancy new exteriors whose bases you changed. What I tended to do was go in CK, disable all the walls, and pull in the new structure interior which matched the new exterior, then do the same thing I did on the outside: align to the door. What you'll find is that much of the time, there's actually a consistent "alignment" of items, in clusters - one group is the sleeping area, one group is the eating area, etc. So you move them en masse, rotating as need be, until they're within the bounds of the new walls. Make sure to run through every item in the refID panel (there shouldn't be TOO too many of them) to make sure nothing is lost, embedded in a wall somewhere, or something like that.

10. Once you've got the layout done, it's time to navmesh again. Generally speaking, everything is so completely re-done that the old navmesh barely applies, so I tend to trim it down to a single triangle (the door triangle), and re-do it from scratch. Get close to objects but not so close NPCs would bump into them. Make sure that any marker for a chair, bed, sweep, etc is accessible. Interior cells are much easier than exterior, so it shouldn't take too long - do your edge markers, finalize, save, and load it up in-game. Same deal as before: test, test, test. Make sure any NPC can get into and out of the house, and I don't mean your followers, I mean ones on their own package AI. Once you're satisfied with that cell, move on to the next one.

I generally try to get a single interior cell done in a single sitting, maybe two. Break it up into segments - too much too fast will lead to burnout, which also has an impact on quality of work.

Closing Thoughts

Truthfully, I'm not sure what drove me to write this whole thing up - I'm relatively "new" to the scene of making mods, as these things go, with my first published one being a bit over half a year ago. However, while there's plenty of compatibility patches out there, they can sometimes be difficult to find (user-specific collections which don't always have "theme"ing), or are focused less on making placed objects match new interiors and more on actual conflict resolution only when specific references collide, so when I decided to start making these it felt like something of a niche which was only partially getting filled - I certainly didn't come anywhere close to completely filling it myself, but I hope my experiences help others to be able to do the same for their personal load orders, if nothing else.

It's been a bit of a bumpy road, with various troubles (literally the evening of my first upload, I got news that my MIL's health took a bad turn and had to fly to the other side of the Pacific Ocean to help care for her, so I was without computer access to troubleshoot my bugs for the next month. Great timing :P ), but the one constant has been how open and helpful the community has been - almost universally folks were okay with patches being made, and were quick to offer help and advice. Special shout-out to JPSteel2 and soldierofwar for putting up with my PMs now and again, as I tended to bug them more than anyone else since I was frequently working with their mods. Additional shout-out to Lexy's LOTD modlist, which got me started using xEdit and CK and a few of these other tools a year or two ago when I first tried it out - I've branched FAR afield from the list itself at this point, but if you're looking for a more curated place to start familiarizing yourself with the tools, and you're willing to take the time (seriously: first install will probably be 20-ish hours), it's an excellent place to start learning how to set up and use the tools.

Finally, huge thanks to the discord communities which I found myself hanging out in just for discussion as I got further into these things - the aforementioned Lexy's and the too-many-to-mention-by-name community who tested things out and supplied some fixes, as the case may be (special shout-out to ra2phoenix, in particular. You do astonishing work, and should start uploading your own stuff, man :P ); somethingobscure's channel which is one of the most generally positive places on the Internet right now and which I always appreciate conversation when it comes up; Project United, which is where The Great Cities channel is located at, for discussion of what's going on there; wizkid's channel which is evolving into a pretty amazing community for people to share their own private work; and while the conversation has largely dried up, the MJB Mods server for ETaC, where folks were more than happy to test things out when I was just getting started on city overhauls. I wouldn't have gotten remotely as much accomplished as I have without your help, and it's folks like all of you which make this community what it is.

So with that, I hope this helps some folks out there. I'm not done making patches, but you can think of me as taking a vacation/sabbatical for a bit: I'm sure I'll get dragged back in at some point. :)