我们可以看到这个单元最初是由Skyrim.esm创建的，然后被USSEP，3 DNPC，LOTD，Skyrim地下，ELFX，一个USSEP-3 DNPC补丁，SFCO，一个私有的合并(我可以告诉你现在这是余烬HD)，它继续滚动到一边。我记下这里的每一个模块，然后每一个有颜色的细胞的每一个模块。这并不意味着它们都需要补丁--在这个字段中，MOD的存在表明它们要么修改单元格设置，要么在单元格中操作或放置一个引用/标记/npc：这实质上是遍历整个mod列表，并突出显示任何可能需要修补程序的内容。对于重新做整个内部的MOD(COTN、TGC等是常见的例子)，这通常意味着它们会这样做。通常需要修补程序有两个原因：
因此，在许多解决冲突的补丁中，常见的冲突是一个模块(例如，3 DNPC是这些模块的频繁参与者)将引用标记为“持久”，而另一个模块则会移动它(例如，如果重新排列内部)。这方面的CR是转发持久化标记，一切都很好。持久化标记所暗示的是，引用被包、脚本或任务使用，或者其他类似的东西：它们通常(尽管并不总是)重要。有些只是沙箱标记，它们是可得对于一个包，而另一些则是特定的标记，这些标记是必要为了继续前进。例如，在Dawnstar，有瘦标记在各种栅栏周围，这些标记作为COTN Dawnstar的一部分被移除，因为这些栅栏已经不存在了。3 DNPC将其中一些标记标记为持久化，但与MOD的当前管理人员讨论后，它们似乎仅用作“随机机会”沙箱选项，因此保留这些标记作为删除不会产生负面影响，因此3 DNPC修补程序不会恢复它们。另一方面，Etac包含一个NPC包，其中一个特定的NPC在一天中的不同时间有特定的任务，其中一个任务是到一个特定的铁路倾斜标记，并停留在那里-没有标志，全国人大将T-姿势，所以我需要想出一个解决方案(不涉及围栏)，在这种情况下恢复标记。因此，作为一个普遍的经验法则，如果您正在做一个补丁，而其中一个mod标记为持久性的东西：确保引用使它成为一个持久的引用，并试图确保它的使用相对于mod最初的意图是“有意义的”。
20.现在让我们考虑一下3 DNPC补丁。相对于简单的CR，这个比较复杂。它有许多新的引用，而不是修改一些已经存在的引用。所以，与其拉出一个CK的实例，不如拉出两个。其中之一，我们只加载3 DNPC：这给我们香草客栈，我们可以看到引用放在哪里相对于客栈的布局。在另一个CK中，让我们像我们在第一个示例中所做的那样加载我们的补丁，并看看标记是什么样子的。因此，我们进入同一个单元格，OldHroldaninn，在参考ID面板中，向下滚动到3 DNPC，这就是为什么我倾向于按Forid进行排序的原因。他们都会聚在一起。让我们看一看Asteria60-70Stage引用(可能是一个字段，一旦触发，就会导致Asteria从60级移动到70级)，下面是这两个窗口的样子：
22.因此，这就变成了一项任务：将所有这些引用移到具有“意义”的地方，与原始行为相匹配。所以任务场在一个房间里-但是哪个房间？那么，简单的方法是点击床，找出它的引用是：000E59BC。新客栈的布局有这张床吗？为什么，是的！所以我的默认期望是在同一个盒子上设置任务触发器。除了.3 DNPC不会触摸那张床来使它持久，或者其他类似的东西。但TGVoOH确实这么做了。它将床的所有权从OldHroldanHangedManInnFaction(其中包含Leontius Salvius、Eydis和Skuli)具体更改为Eydis。嗯，那似乎很好.也许吧。但我们要确保。有趣的NPC既是痛苦，因为有那么多，而祝福，因为有这么多的信息他们的网站。我们在这里看到AsteriaQuest是Anvil的乌鸦，看看第60和第70阶段，阶段转换似乎发生在您带着给定列表返回的时候，而Asteria将在XMarkerHeding(从包装分析等判断)--所以重要的不是盒子在一个有特定床的房间里，而是盒子里面有XMarkerHeding，而且它在一个可访问的位置。所以把它放在床边应该可以：为了一致性起见，让我们这样做。移动对象时，热键通常是有用的：Z、X和C，如果持有，将确保您只在单个轴上移动(C是Y轴)，鼠标右键旋转，而这些键改变哪个轴是旋转的。还有许多其他热键(E、W等)也可能派上用场--查看CK文档。同样，其他的标记(瘦身等)都在火的周围，所以让我们把它们放在火旁：
23.然后，一旦我们移动和重新定位一切，保存文件，瞧：补丁制作。在移动引用时，有时切换标记(M)或灯光(L)可以简化可见的内容，但请记住重新启用它们，这样您就不会错过任何东西。此时，快速自动清除xEdit中的修补程序，这将删除任何未更改的内容，您可以开始了。是的，我以3 DNPC为例，尽管它的所有功劳都应该归功于奶酪吐司8制作了3 DNPC贴片谢谢你允许我把它作为一个例子，因为它强调了为什么你在看需要做什么补丁时要小心：NPC引用会导致它们在导航网上产生，所以你会看到添加的NPC。但是从字面上看，除了(有趣的是)任务阶段60到70之外，每个添加的标记都是一个持久的标记：它们很可能是持久的物质为了任务。但是你永远不会看到它们，因为标记是看不见的，而且很多标记都无法用新的建筑布局来访问：所有这些任务都会在没有补丁的情况下被打破，而你也不会更聪明。这就是为什么你需要对这些事情所需要的东西保持谨慎和专注。
不要指望你第一次尝试工作。别指望你第二次试着工作。我想我在第一次COTN Dawnstar-伟大的城市Dawnstar补丁上开始，然后停了3或4次，这是明确的。有一个模型，在那里，其他人已经做了一个COTN Dawnstar-JK-伟大的城市补丁，我可以使用作为一个参考。如果没有这个指导方针，我不知道我是否会有足够的舒适感来发布任何东西。话虽如此，这是我处理这些问题的一般方法。
所以我们有一个脚手架-COTN Morthal含有新的脚手架，所以我们想替换它。我们有一座农舍--COTN Morthal有农舍，所以我们也想更换它。
5.一旦你这样做了，现在是时候开始研究那些主要的剪裁区域了。这有点困难，重要的是要记住你的最终目标是什么。如果你这么做是为了个人目的？毯子移除东西总是一个选择，它是快速和容易的。然而，如果你想上传它，重要的是要记住你想要做的事情：这不仅仅是“我希望能够使用这两个MODS”。这是“这两个Mod的作者在放置这个东西的时候有一个特定的想法。我怎样才能以最尊重这个意图的方式来改变这种冲突呢？”有时，这意味着保持一切的机智，但转移到一个稍微不同的位置，以便它可以适应。有时，这意味着禁用它的一部分，但添加一个新的访问点。有时，这意味着移动一些东西，但也增加了一些新的东西。不要害怕问父母的莫德作者他们的想法：如果我没有问过Wizchild关于在我的COTN Dawnstar-Lanterns of Skyrim II补丁中添加杆的话，我很可能最终会上传一些与MCM没有正确连接的东西，但是他很好地确保了我的修补程序有所需要的东西，这就是我是怎么学到的。得到反馈也很有用，这样你就不会做这样愚蠢的事情了；)
最后，很大程度上要感谢那些不和谐的社区，当我深入讨论这些问题的时候，我发现自己只是在闲聊--前面提到的Lexy‘s和太多的点名社区--他们测试了一些东西，并提供了一些修复，具体情况可能是(特别是对ra2phoenix的特别呼喊--Out to ra2phoenix)。你做了令人震惊的工作，并且应该开始上传你自己的东西，伙计)；某个网站的频道，它现在是互联网上最积极的地方之一，当它出现的时候，我一直很欣赏它；联合项目(Project United)，这是大城市频道所在的地方，讨论那里发生了什么；奇奇频道(Wizky‘s Channel)正在演变成一个非常棒的社区，让人们分享他们自己的私人作品；虽然对话基本上已经干涸了，但Etac的MJB Mods服务器，在我刚开始进行城市改革的时候，人们非常乐意测试一下。如果没有你的帮助，我就不会有那么多的成就，而正是像你们这样的人让这个社区变成了现在的样子。
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.
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 in 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
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 :)
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 Persistency
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 persistency 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 persistency, instead of having to disable and re-enable various objects, or edit packages/quests to point to new objects. 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.
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 was 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 existance 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?
....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
Obvious clipping, so the stand as a whole needs to be moved
Walkway and fence coming out of a roof to get to a guard tower, which will need a different access
Scaffold that can be disabled. Note: I did some testing, it's not possible to walk under the side, so I also disabled the dock here eventually
Scaffold whose type I want to change
Building whose type I want to change
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.
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. :)