用户登录
|忘记密码

新用户注册

登录

其他登陆



举报

冲突解决和3D空间修补的简要演练

冲突解决和3D空间修补的简要演练
冲突解决和3D空间修补的简要演练 冲突解决和3D空间修补的简要演练 冲突解决和3D空间修补的简要演练 冲突解决和3D空间修补的简要演练 冲突解决和3D空间修补的简要演练 冲突解决和3D空间修补的简要演练 冲突解决和3D空间修补的简要演练 冲突解决和3D空间修补的简要演练 冲突解决和3D空间修补的简要演练 冲突解决和3D空间修补的简要演练 冲突解决和3D空间修补的简要演练 冲突解决和3D空间修补的简要演练
作者:Janquel
发布:woshiqyx
发布日期:2020-06-28 15:35:06
更新时间:2020-06-28 15:35:06
这个人很懒,什么也没留下
3499 人点赞
1509 人收藏
5354
14213
1.0
标签
上古卷轴5:重置版
本地下载 高速下载 需要优先下载下载器,50%提速

因此,在发布我的各种补丁集合的过程中,有多个实例,人们问我经历了什么过程,或者我是如何制作补丁的。由于我早期的许多补丁主要是通过我自己的绊脚石(而不是任何特定的正式过程)产生的,所以我总是犹豫不决,害怕与其他方法相比,它可能“不正确”或效率低下。然而,随着时间的推移,我发现它们越来越多地被使用,在一天结束的时候,如果它起作用,它就会起作用。由于我现在准备好了我的最后一个补丁集合,并且没有立即开始另一个补丁的计划,我想我会利用这个机会输入我制作这些补丁的过程,希望其他人可能会发现它对制作自己的修补程序有用,并可能与整个社区共享它们。

所需工具

我经常使用一些工具,这些工具将作为本指南的一部分加以参考:

SSEEdit-最强大的工具之一,如果不是最强大的,在军火库中的调制解调器-这是一个宝贵的方法,用户可以通过看到他们的插件做什么,他们的冲突。YouTube和其他地方有很多很多的指南,教他们如何使用这个工具。我强烈建议研究它们:这是我自己偶然发现的一个领域,首先是通过一些修改过的安装列表来暴露出来的,最终我充分利用了它来准确地猜出不同的领域在做什么,让我的舒适度可以让我开始实验,并最终修复一些东西。考虑到有大量的教程可用,我不会重新发明车轮,但我也建议检查它们

创作工具包-绝对不能避免使用这个.这是一个非常健壮的工具,用于加载插件和在游戏中操作数据。我很犹豫是否尽早使用它,因为我担心它可能会改变什么,而我可能没有意识到,但是对于更复杂的变化,或者涉及景观或导航网的变化,这是百分之百必要的。这个链接指向一个wiki指南,它将遍历如何安装它。

SSE创建工具包修复-但说真的,不用这个就不用麻烦了.对于我们的情况来说,最重要的是“-能够编辑带有ESP文件的插件,而不会被删除。”但是这里有如此多的生活质量的变化,我甚至无法想象在没有它的情况下在创作套件中无所事事。

并非绝对必要,但强烈建议:

Mod组织者2-或者另一个包含配置文件功能的MOD管理器,允许您使用不同MODS动态启用/禁用的单独虚拟安装。这不仅对保持您的理智和您的计算机RAM,同时努力工作,而且对工作本身的质量也很重要。通过使用概要文件功能,您可以恢复一个“香草”配置文件,并只启用您想要在任何给定时间使用的MOD。即使是没有插件的MODS也可以考虑因素,我的第一个COTN Dawnstar-SFCO补丁就证明了这一点:我有一个横幅的网格/纹理替代器,它将横幅从矩形变为三角形。因此,在我的安装中,被移动的画不是用横幅剪裁的,但是对于没有替换的人来说,横幅和画是重叠的。移除。变量。如果你想上传一些东西,你想要它独立工作,让最终用户解决他们的终端上的任何怪癖。

信息更丰富的控制台-我无法开始说明这个模块在调试问题时节省了多少时间。只要打开控制台,点击任何项目,它就说明了最后要修改的是什么。它对我的调试很有用,推荐其他人安装是非常宝贵的,这样他们就可以快速地说出在遇到问题时接触对象的最后一件事情是什么。对于任何遇到问题的人来说,第一个问题是他们是否安装了这个程序,并且是否可以给出一个截图,只要它是可用的。巨大的帮助。

两个监视器。说真的,这很有帮助

权限

因此,这一部分需要正确的顶部,也有可能是最大的争论点之一。当谈到补丁时,Nexus术语是,如果您正在修改任何其他MOD正在做的事情,那么您应该在修改之前先寻求他们的许可。许多Mod作者对补丁具有开放权限,并免费允许补丁。如果请求出现,许多其他人非常乐意允许其他人进行修补。还有一些人想要确认你是否知道自己在做什么,而有些人只是不想弄脏水:最终用户经常会使用一个或另一个错误的补丁,当事情不起作用时,会向最初的Mod作者抱怨。然而,一般来说,Nexus不会删除补丁,除非父mod作者请求。

我个人的立场是,我们应该永远错误地实现这些愿望:我上传的每一个补丁要么是一个具有开放权限的修补程序,要么是我获得了显式上传权限的修补程序(在某些情况下,该修补程序仅以某种方式运行);b)一个简单的CR修补程序,其中我所做的只是转发最初的mod更改,确保它们在没有修改的情况下完成;(C)对一个现有修补程序的更新,该修补程序得到了该修补程序的制造者的许可,但它隐含地假设父mod作者授予了第一个人许可,在某些情况下,我没有接触我没有权限的MOD的资产/包/等等,而是修改共享资源(导航网格和景观),以确保MODS能够很好地一起运行:景观和脐网格被分割成不同的部分(即单元格),两个不同的MOD可能不会直接相互干扰,但是这些记录上会发生冲突,因为它们涵盖了一个特定的“区域”。这是我给自己的规则中唯一的回旋余地,而“老赫洛丹大村”有一个例子,就是索尔甘德的“辛克洞”:我的补丁没有碰过索尔甘德的辛克孔的物品,而是修改了景观和肚脐,让两个摩托都能和谐地工作。

现在,如果是个人使用的话,你就做了--我有很多东西是我永远不会上传的,但我是为自己做的。但我想把这个方法放在最高层:我们是一个社区的一部分,这就是目前的标准。虽然你可能渴望变革,也可以游说和鼓励变革,但在变革到位之前,保持良好关系符合每个人的最佳利益:)

我的过程

内饰

因此,有许多过程是我后来了解到的,例如方法修补。我是在做完自己的事情之后才了解到这一点的,它们基本上是重叠的--方法修补似乎更好,使用modgroup和其他类似的特性来简化事情。我建议你去看看!但我想,无论如何,我还是要克服自己的精神错乱:)

1.在xEdit中加载整个加载顺序,包括您打算为其进行修补程序的模块。打开一个文本文档,注意您想要使用的MODS。暂时忽略Cell和Worldspace,而在其他领域寻找冲突。老Hroldan的大村只有TGVoOH自己添加的物品,所以没有冲突(在我的例子中,最后一个是由DynDOLOD产生的,所以可以忽略它)。因此,不需要带有这些区域的通用CR修补程序。有大量的指南用于解决NPC上的冲突,静力学和其他各种可能需要冲突解决补丁的东西,所以我现在不想进一步详细介绍。




2.现在我们来看看世界空间和细胞。我会从细胞开始,因为他们证明,一般来说,更简单,特别是如果你最终需要处理导航网。展开每个单元格块和子块,然后高亮显示每个有颜色的单元格,记下显示在右窗格中的任何模块。例如:


所以我们先来看看老Hroldan酒店。


我们可以看到这个单元最初是由Skyrim.esm创建的,然后被USSEP,3 DNPC,LOTD,Skyrim地下,ELFX,一个USSEP-3 DNPC补丁,SFCO,一个私有的合并(我可以告诉你现在这是余烬HD),它继续滚动到一边。我记下这里的每一个模块,然后每一个有颜色的细胞的每一个模块。这并不意味着它们都需要补丁--在这个字段中,MOD的存在表明它们要么修改单元格设置,要么在单元格中操作或放置一个引用/标记/npc:这实质上是遍历整个mod列表,并突出显示任何可能需要修补程序的内容。对于重新做整个内部的MOD(COTN、TGC等是常见的例子),这通常意味着它们会这样做。通常需要修补程序有两个原因:

加载顺序相关-两个mod都移动相同的对象。一般来说,如果有东西在做一个小的调整,另一个在做一个彻底的内部大修,推进大修的变化。只用你的大脑

新添加的项目,需要移动以匹配新的内部。

3.检查其他人是否做了你认为需要的补丁。如果你不需要的话,做工作就没有意义了!

4.一旦我们知道了我们正在使用的MOD,在MO2中做一个新的简介。我有一个“香草Skyrim”的配置文件,这是我做我的测试,它只是包括清洁的原始.esms,SkyUI,SKSE脚本,和更多的信息控制台(因此,我有可用的,如果需要)。然后,我启用所有可能与补丁相关的MOD。这将减少modlist的加载速度,并减少可用作分心的项目。在这个阶段运行战利品也是一个好主意,因为这是最终用户将经常使用的东西,所以您最终会得到相同的命令。


5.现在,这并不是你想要的,但通常只显示冲突是有用的。右键单击右侧面板中的任意位置,并选择“隐藏无冲突和空行”。查看Cell本身,我们可以看到在单元设置上存在一些冲突:许多MODS将声音设置从石头更改为木头,TGVoOH将照明更改为使用孤独照明(大概是因为它使用了孤独资产)。


6.现在,动动脑筋:是的,这是一场冲突,但在这种情况下,许多MOD都是.esm,所以TGVoOH将永远获胜。因此,单独照明的补丁是不需要的,例如,天边地下。另外,想想TGVoOH如何改变建筑物:木材声学还是石头声学更有意义?如果您觉得单元格设置CR修补程序是必要的,您可以从这里开始。我有一个私人的sMash/bash/etc补丁,所以我通常不会上传这些,因为我自己处理这些事情。你可能也想做同样的事。接下来,我们开始遍历每个组成MOD所添加的内容。让我们来看看USSEP。


7.看起来USSEP编辑了导航网,并触及了许多项,但没有添加任何新的引用。再来一次:动动脑筋。USSEP是一个.esm,TGVoOH放置的任何对象冲突都将永远获胜。通过这些,所有的东西都是冲突,USSEP移动了一些东西,然后TGVoOH也移动了它:补丁是不必要的,TGVoOH赢得了所有的冲突。只有一个例外:000EB5A0。


8.在这方面,USSEP将床改为儿童床,并将其缩小。TGVoOH移动它。因此,为了配合这两个MODS的视觉,串联起来,我们希望床在新的位置,与改变的类型/大小。所以我们要做的是:右击,选择“复制作为重写进入.”


9.在底部选择ESP标记为ESL(忽略我的情况,我的USSEP补丁已经在上面:P)*注意以后:只需选择<newfile>.esp,如果您希望处理Navmesor,您将自己添加引用。只是一场戏*


10.并提供你想要的名称:


11.瞧,你现在有了一个有记录的补丁。从每个要制作CR修补程序的值中拖动值,这应该是分辨率。我们想在游戏中/在CK中检查它,但这是最简单的补丁形式。但是,由于您修改了此单元格中的项,所以现在也有一个单元格条目。您将希望返回并确保修补程序具有所需的单元格设置。



12.在制作这些只涉及Skyrim.esm本身的项目的兼容性补丁时,还需要另外一个步骤:添加主程序。在左侧面板上,右键单击您创建的修补程序并选择“AddMaster”。然后,您需要选择两个MOD,这是您的“主”,这将确保补丁加载后,两个插件。


13.然后,我们继续讨论下一个接触这个细胞的模式:3 DNPC。它没有任何已经存在于单元格中的触摸,但是它有许多新的引用被添加。


14.因此,为了彻底起见,启动时最有用的事情是右击并将所有这些添加到新的修补程序中。任何不需要被触摸的东西都可以稍后删除,但是这实际上创建了一个修补程序,这是一个“最坏的情况”,您需要修改的所有内容都是这样,当您在CreationKit中加载它们时,它的好处是用星号标记它们。

15.因此,我们用每个模块完成所有这些步骤,为内部单元创建“框架”补丁--其中一些已经完成,另一些没有完成。此时,我切换到CK中,而不是重复使用WorldSpace的过程。它稍微分解了工作,内部单元格和外部Worldspace所需的任务略有不同,因此它提供了一个方便的断点。

关于持久性的快速搁置

因此,在许多解决冲突的补丁中,常见的冲突是一个模块(例如,3 DNPC是这些模块的频繁参与者)将引用标记为“持久”,而另一个模块则会移动它(例如,如果重新排列内部)。这方面的CR是转发持久化标记,一切都很好。持久化标记所暗示的是,引用被包、脚本或任务使用,或者其他类似的东西:它们通常(尽管并不总是)重要。有些只是沙箱标记,它们是可得对于一个包,而另一些则是特定的标记,这些标记是必要为了继续前进。例如,在Dawnstar,有瘦标记在各种栅栏周围,这些标记作为COTN Dawnstar的一部分被移除,因为这些栅栏已经不存在了。3 DNPC将其中一些标记标记为持久化,但与MOD的当前管理人员讨论后,它们似乎仅用作“随机机会”沙箱选项,因此保留这些标记作为删除不会产生负面影响,因此3 DNPC修补程序不会恢复它们。另一方面,Etac包含一个NPC包,其中一个特定的NPC在一天中的不同时间有特定的任务,其中一个任务是到一个特定的铁路倾斜标记,并停留在那里-没有标志,全国人大将T-姿势,所以我需要想出一个解决方案(不涉及围栏),在这种情况下恢复标记。因此,作为一个普遍的经验法则,如果您正在做一个补丁,而其中一个mod标记为持久性的东西:确保引用使它成为一个持久的引用,并试图确保它的使用相对于mod最初的意图是“有意义的”。

作为推论,对于任何碰巧读到以下内容的Mod作者:如果你想让补丁制造商更容易,请在可能的情况下重新使用参考资料。而不是禁用一张椅子和放置一个新的,重新使用现有的椅子。如果您想用不同的类型替换一个工作台,而不是禁用和放置新的工作台类型,则选择相同的引用,并将其基本引用类型更改为新的工作台。这将允许补丁制造商只需转发持久化,而不必禁用和重新启用各种对象,或编辑包/任务指向新的对象。现在,有绝对,100%这样做没什么不对的:没有任何Mod的作者有责任期望他们使用或禁用的任何特定对象都会被另一个Mod使用:这就是为什么我们有补丁制造商的原因。但这肯定会让我的生活更轻松;

16.现在我们打开CK。这就是双显示器派上用场的地方(坦率地说,3将是有用的)。对于简单的补丁,比如USSEP,我们只是换了一张床,我们可以打开一个实例。找到您正在使用的修补程序,选择它,将其标记为活动文件(这意味着您所做的任何更改都将保存在此插件中)


17.接下来,转到有问题的单元格:在单元格视图选项卡中,双击我们想要的单元格:OldHroldaninn。它应该标上星号。


18.最后,在正确的面板中找到有关的参考资料:000E5BA0。您可以按Forid进行排序并滚动到它,在顶部栏中搜索引用ID(只需输入000E5BA0),也可以按引用类型进行筛选(因此,“bed”将是可以用来缩小其范围的字符串)。我倾向于按表单和滚动排序,原因将在下一节中说明。引用本身也应标记为星号。


19.这会打开渲染窗口中的床。我们能看到.嘿。这是一张小床。看起来不错。老实说,这是我们真正需要做的,但作为一个理智检查,它可以有用的枢轴围绕它,以确保它不是浮动的或类似的东西,还可以拉起肚脐网格(我在上面的屏幕截图中用红色圈出按钮,并这样做了),以确保任何存在的标记,需要在肚脐上,为NPC使用引用,是可以访问的。在这种情况下,他们是,所以我们结束了。一切看起来都很好!

20.现在让我们考虑一下3 DNPC补丁。相对于简单的CR,这个比较复杂。它有许多新的引用,而不是修改一些已经存在的引用。所以,与其拉出一个CK的实例,不如拉出两个。其中之一,我们只加载3 DNPC:这给我们香草客栈,我们可以看到引用放在哪里相对于客栈的布局。在另一个CK中,让我们像我们在第一个示例中所做的那样加载我们的补丁,并看看标记是什么样子的。因此,我们进入同一个单元格,OldHroldaninn,在参考ID面板中,向下滚动到3 DNPC,这就是为什么我倾向于按Forid进行排序的原因。他们都会聚在一起。让我们看一看Asteria60-70Stage引用(可能是一个字段,一旦触发,就会导致Asteria从60级移动到70级),下面是这两个窗口的样子:



21..看来不对!任务阶段在墙的中间(虽然与房间重叠),也是一个附加的Xmark标题。但是事实上,如果我们稍微向一边滚动,我们会看到一组其他标记,甚至是NPC引用也会在空中浮出。NPC引用本身并不是世界末日(我相信引擎的行为是它会被弄混一秒钟,然后将放置的NPC弹出到最近的有导航网的位置),但是那些其他标记呢?他们很难接近。很多时候?别小题大作。如果需要的话?重要的事。


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之外,每个添加的标记都是一个持久的标记:它们很可能是持久的物质为了任务。但是你永远不会看到它们,因为标记是看不见的,而且很多标记都无法用新的建筑布局来访问:所有这些任务都会在没有补丁的情况下被打破,而你也不会更聪明。这就是为什么你需要对这些事情所需要的东西保持谨慎和专注。

24.这实际上涵盖了内部补丁所需的所有内容的要点,除了导航网格冲突之外:使用xEdit创建初始修补程序,使用您可能需要修改的对象。在可能的情况下在xEdit中执行CR。在CK中加载补丁,根据需要进行操作以匹配新的内部。保存,然后清理。泡沫,冲洗,重复。随着您越来越舒服,可以更快地在CK中同时加载多个不同的父MOD,移动对象,然后在xEdit中键入更改,这样就可以同时进行多个补丁。如果右键单击任何引用,则可以在3D选项卡上获取位置和旋转数据:


现在,如果您选择这样做,一个错误可以完全抛出东西,我已经做了很多次,所以要小心。此外,通过单击“初始禁用”复选框,您可以轻松地禁用此“编辑”面板。快速自动清理也将Z设置为-30000,而EnableParent设置为与播放器相反的对象,所以如果您想彻底删除对象,我建议您这样做。现在,当涉及到导航网编辑,而不是试图键入和解释它,它是更有用的检查一些YouTube上的教程。这是我第一次看这足以让我开始做实验。重要的是要记住,如果您编辑Navesh,您需要完成它,如果您希望将它标记为ESL,则可能需要使用xEdit重新压缩您的插件。同样的,照明也有点复杂,你最好看YouTube的一些教程--我不是很擅长,也可能不应该解释我的过程(摆脱闪烁需要我永远。)。我要给出的一个建议是,当鼠标左键拖动光源时,按压和按住S按钮,来缩放灯泡的大小是很有用的,因为这个“缩放”对象。任何参考都可以这样缩放,但我主要是用光半径。

25.如果两个MOD以不同的方式完全重新做一个内部(也就是说,它们都以某种方式使其独一无二),一个和谐的补丁并不总是可能的,所以有时候一个补丁会简单地从一个模块中删除所有的更改,然后从另一个模块中转发所有的更改。老实说,如果你要这么做,最好确保你藏匿作品的Mod作者对此没意见--通常,他们是一些更大系列的一部分(我碰到的独特内饰是一个常见的系列,因为它的独特之处体现了整个天边的许多内部环境,而不是专注于一个单一的地点),或许对此没什么意见,但有些人不想这样做,最好是尊重他们的愿望,不要做这样的补丁。此外,他们可能知道脚本引用的某些项目,或者其他类似的东西,为了更好的稳定性,您可以禁用除这些对象之外的所有东西,并使这一小部分正常工作。另外,如前所述:用你的头。如果某些东西是持久的,它可能是由于一个包裹或任务-你可能需要保留这些特定的项目,至少在附近。再检查一遍以确定。

为了在一个新的风格中完全重新设计内部,我将在做完Worldspace的一般补丁之后讨论这个问题。

说到这里,现在是世界太空。

世界空间

1.世界空间在很大程度上是一样的,只有一些额外的事情需要担心。具体而言,持久化引用、景观和导航网。和内部细胞一样,我们需要查看一个给定的细胞,看看与该区域相互作用的是什么。但是,除了单元格之外,还有一个包含所有持久引用的“持久单元”。必须手动完成这些操作,并使潜在冲突复杂化,因为在Skyrim中任何位置放置持久引用(或将引用标记为持久引用)的每个模块都会接触到这个单元格,因此我们不能使用此处列出的列。相反,我依赖其他细胞,并通过它们。真正的问题是,由于这一点,实际上有必要单独检查每个模块,查看它们的持久引用,并验证它们位于哪些区域(基于坐标),这样您就可以确保它们不发生冲突--城市大修经常会在外部放置大量的东西,因此冲突很常见。




从好的方面来说,很多时候接触到的细胞不会被其他任何东西所接触,就像上面的最后一个一样。享受那些牢房吧!他们很棒!

2.在这一点上,我们也这样做:通过任何有冲突的MODS,寻找可以解决的冲突解决方案,以及任何其他/任何增加的对象,将它们放在一个补丁中(无论是从内部存在的,还是外部的新的)来查看CK。



(上面两个中的第二个来自我已经创建的修补程序,但是在我用CK移动它之前,它是复制到修补程序中的引用)。

然而,有两种特殊的参考类型我们必须注意:景观和导航网。景观包含两大信息:景观的三维映射(形状)和景观的纹理(外观)。如果两个不同的MODS在同一个细胞里触摸景观,即使它们与它们的变化没有直接冲突,他们会发生冲突,不管最后一次“胜利”是什么。在xEdit中没有解决这些问题的简单方法,而是需要在CK中解决。这种情况在草地MODS中更加严重,因为它们经常会改变一些纹理的行为,使之具有否则就不会出现的草,这可能导致xEdit本身没有出现“冲突”,因为它们可能一开始甚至没有重新绘制景观,但是突然之间,草出现在不应该出现的地方。同样,在Navesh的情况下,即使没有冲突,有时也需要对其进行更改,以避免放置对象或匹配新的景观。因此,我将景观/导航冲突视为“独立的”,并将其最后处理。



3.在这一点上,我们回到以前在单元格中所做的工作:用香草和你正在修补的模块加载一个CK实例,另一个加载您正在修补的mod和生成补丁的基本模式,然后是真正乏味的部分:遍历所有内容。在外部,有时引用被放置,但现在它们嵌入岩石或景观。有时会添加标记,但它们在墙内或地面内。基本上,您需要查看您正在修补的模块所触及的每一个引用,并确保它们是有意义的。这太费时了!真烦人!但是,如果你想做“正确”的事情,你应该采取行动。我发现它有用的运行和标记,一个给定的单元格接触的时间提前,这样我就可以加载和运行所有的USSEP,或所有的灯笼天边,或类似的东西-所有在一次通过。正如所讨论的,景观和导航在这一阶段基本上被忽略了,但是我在脑海中记录了所有被修改的东西(或者没有被修改),因为一旦我们进入景观,可能会有更多的接触是必要的,即使只是个人使用(3,4+道路补丁)。

4.现在我们来看看景观和导航网。对于老Hroldan(至少是那些我为之做了补丁的那些),总的来说,在景观美化方面没有真正的问题.除了索尔甘德的辛克洞。是的,和Verdant(我选择的草模式)有冲突,也有草类的景观修复,但这两种方法都是为了有/没有草而画的--这是我在事后可以为自己做的清理。另一方面,我们遇到了一些问题。现在,与景观,有时它是值得尝试不同的加载命令,看看是否只有其中之一的两个MODS“赢”将解决任何问题。以下是索尔甘德·辛克洞的景观奖:


.看上去不太对,地上有那块地.浮动门也看了看,但实际上它被标记为禁用,只是没有设置为-30000的Z,所以它仍然出现在CK中。提示:总是将Z设置为-30000,这样游戏中就不会出现幻影浮动的东西;此外,它还会修改肚脐网,所以一个不同的三角形被绑在门上,这意味着门也被修改了。当我们在这里的时候,这里是导航网:


所以门没有绑在一起,但考虑到新的布局,这并不奇怪,但整个花园完全没有肚脐(即使门不在那里)。真够倒霉的。另一方面,如果老虎尔丹村赢得一切:



.这看起来也不对景观已经完全超过了门廊,而肚脐完全忽略了由索尔甘德的辛克洞增加的井和甲板的存在(这是可以理解的)。这样补丁就变得必要了。

5.我不打算详述如何做到这一点。Navesh被我已经链接过的YouTube视频所覆盖,Landscape也有类似的教程,但也很容易通过乱搞就能学到。然而,有一个问题是如何最好地处理这个问题。现在,我开始以同样的方式制作我的修补程序--将引用复制到xEdit中的补丁中(虽然在本例中,我将重新做一个很好的导航网格,但我不会立即将它标记为ESL,就像添加到Navesh/重新完成它时一样,有时CK选择的引用ID超出了ESL的界限,所以最好将它作为一个普通的ESP,然后再压缩它)。但问题是:我们从哪一个开始?在这种情况下,如果我们从Soljun的Sink孔开始,那么减少操作是非常必要的,所以这将是我的直接倾向。因此,我们把景观和肚脐,加载我们的斑块,并相应地平滑景观,并为花园添加纳网三角形,做边缘检查,最后确定肚脐,以绑在门标记,和沃伊拉:。


很多这是艺术天赋-我不是最好的,但我可以使它的功能。其他人,我敢肯定,更擅长使景观工作,他们有我最大的敬意。)我也把那扇门送到了-30000,这只是为了我个人的方便。几个简短的笔记:一定要旋转相机,从不同的角度看每一件事。海军和景观可以欺骗!重要的是,不要简单地相信你做得对,而是在一个新的保存中加载游戏,把游戏加载到你一直在编辑的位置,安慰自己一个随从,然后到处跑,找出导航网不正确的地方。如果有人想搬进搬出房子,那就等到他们搬进来搬出去的时候再确认一下。这反过来又导致了另一个冲突案例,它不会出现在xEdit中:例如,如果两个不同的mods为相同的NPC添加了一张床,会发生什么?好吧,老赫洛丹和索尔甘德的辛克洞都是为珀斯做的。索尔甘德给了他自己的房子,还有一张他该睡的床。老Hroldan为他提供了一个在Miner兵营睡觉的地方。如果不正确地管理加载顺序/冲突,由一个模块添加的某些内容将被完全忽略。考虑到我对自己设置的约束--re:权限以及没有它们我可以做什么,这意味着必须有一个严格的TGVoOH和SS负载顺序,才能得到正确的行为。

同样重要的是,看看上面图片背景中的绿线:这是细胞屏障。Worldspace导航网只填充当前单元格-它与在这些单元格边缘的其他单元格的脐网接口。Navesh必须最后确定,这样NPC才能从一个单元跨越到另一个单元,并且当你最后确定它时,更新边缘细胞的肚脐,以注意它们跨越到的边缘三角形。这有一个重要的含义:除非你在事后非常小心和手动地清理东西(除非你知道你在做什么,否则不要这样做),任何时候你修改Worldspace导航网格并保存时,你实际上是在修改5个单元格的值:当前的一个,以及每一个相邻的单元格。。这有直接的含义,导致潜在的冲突与其他MOD,您可能不会预期。例如,尽管不在同一间牢房里,甚至彼此之间的距离很近,但老Hroldan的大村与阿帕奇的神圣优雅有着千丝万缕的冲突:


现在,这可以通过加载顺序解决,所以我没有做补丁,但请记住:加载顺序重要!这些事情不是显而易见的,除非你采取额外的努力来解决它们!那些时候,你的随从消失了,或者有些人只是站在路上,你不知道为什么?就像这样。你继续前进,但如果你想要一个稳定的,完整的构建,你需要花时间来解决这些问题。这并不总是值得额外的努力!我本来打算做所有的事情,但是我已经达到了“去他的,我们将用耳朵来演奏”的阶段,所以这绝对是一个“按我说的做,而不是我做的”的情况。但能意识到这是件好事。

结合城市大修

好吧,但这是每个人都想要的。有五次城市大修,使安吉磨坊在不同的方面看起来不可思议,我想要所有这些,即使它没有意义,它是比惠特伦大。我该怎么做?

别。


.不,但说真的

很多人对我的补丁收藏感兴趣主要来自于有人做了一种独特的建筑类型,我把这些美学应用到了其他城市的MODS中。他们很棒!我懂了!它们也非常耗时,非常依赖于高质量的父母MODS(在许多情况下,做补丁会使您对其他您目前喜欢的MODS失望),并且需要很大的耐心。一个单一的城市大修补丁所需的时间几乎相当于我为一个给定城市所做的每一个补丁的总和。做倍数是.嗯,他们扩大得很快。

不要指望你第一次尝试工作。别指望你第二次试着工作。我想我在第一次COTN Dawnstar-伟大的城市Dawnstar补丁上开始,然后停了3或4次,这是明确的。有一个模型,在那里,其他人已经做了一个COTN Dawnstar-JK-伟大的城市补丁,我可以使用作为一个参考。如果没有这个指导方针,我不知道我是否会有足够的舒适感来发布任何东西。话虽如此,这是我处理这些问题的一般方法。

1.启用两个MOD,在城内跑来跑去,看看它们。看什么明显是剪裁。拍下截图,这样你就知道要寻找的显而易见的东西了。任何你想改变的静态,打开控制台,点击它们,得到引用ID和基本ID。截图。一旦你习惯了这个过程,你可以绕过很多,但是对于你的第一次尝试,要彻底。以下是COTN Morthal的一些例子--莫塔尔的伟大城市。老实说,Dawnstar比Morthal更容易处理(更少的垂直导航变化),但我的经验也要少得多,我开始用Dawnstar编写我的例子,并遇到了一堆“不,我在做这件事的时候很傻,不要那么做”的事情……我们要用Morthal;D。


明显的剪裁,所以整个看台需要移动。


从屋顶出来的走道和栅栏到达守卫塔,这将需要一个不同的通道。


可以被禁用的脚手架。注意:我做了一些测试,不可能在侧面行走,所以我最终也在这里禁用了码头


脚手架,我想换它的类型


我想改变类型的建筑

所以我们有一个脚手架-COTN Morthal含有新的脚手架,所以我们想替换它。我们有一座农舍--COTN Morthal有农舍,所以我们也想更换它。

2.打开xEdit。现在我们开始做补丁。开始如何使用CR补丁,尽管没有标记为ESL:知道您想要赢得哪个补丁(通常是具有不同美学的那个),然后让它赢得一切。除了景观和肚脐,有可能。其中一些可能是内部的,尽管在这个特定的例子中,情况并非如此。这只是COTN Morthal和Morthal大城市之间的一些冲突。


这其实不是那么多直接的冲突!想想看,任何给定的单元格都需要做些什么--COTN Morthal很大程度上改变了布局,因为建筑物的足迹非常不同,而TGC增加了墙壁和其他可能有冲突的物体。把所有这些都复制到补丁中,让它成为你应该“赢”的最好机会,然后逐个检查所有这些,以确保你的选择是有意义的。对导航网和景观也是如此--在本例中,TGC对景观进行了更多的编辑,并且由于增加了墙壁等原因,做了更多的导航网格更改,我使用它作为基础:不管选择哪一个,Morthal都是一项繁重的工作,但如果您使用它作为基础,经常会有一种模式或多或少地起作用。动动脑子。

3.现在我们找到了我们想要取代的。我们的脚手架是06002138。所以我们发现,把它作为覆盖复制到补丁中。确保修补程序按讨论的方式设置了两个母版。现在我们要改变基地。


现在那个脚手架是新型的了!就这么简单!(没那么容易--我们还得移动它)。在农舍重复这个过程:


现在我们开始讲“有趣”的部分。我不会有那么多的图片通过这一节,因为我不会完全重新创建修补程序,因为我说通过这个。

4.打开CreationKit,并按当前的情况加载修补程序。已经是修补程序一部分的项目将被标记为星号。从照顾这些开始。一次只工作一个单元,但要注意,有些对象可能在单元格之间跨或移动,这是非常好的。不要担心景观或肚脐在这一点上。记住,任何你改变的基础都可能有不同的界限,不同的尺度,不同的旋转--不要害怕操纵事物,让它们看起来“正确”。在建筑物的例子中,看看它们周围是什么:你有没有意外地把一栋建筑移到了一个盖着别的东西的地方?把那些东西移开,这样它们就可以再次进入了。保持标记。它杂乱的屏幕,但他们也需要访问,如果你移动一个灯笼,你应该移动它的光锥在同一时间,所以发射保持相同的位置相对于灯笼。特别是对于农舍,看看以前的房子是怎么做的:你是否需要稍微调整一下它们,以适应新的形状?当我放置新的建筑物时,我试着让门保持不动,并将建筑物与门相匹配--这常常导致一个端点,即MODS可以加载到现有的保存上(尽管它们不应该加载,但它确实减少了对支持请求的要求;D),因为门是持久的。

5.一旦你这样做了,现在是时候开始研究那些主要的剪裁区域了。这有点困难,重要的是要记住你的最终目标是什么。如果你这么做是为了个人目的?毯子移除东西总是一个选择,它是快速和容易的。然而,如果你想上传它,重要的是要记住你想要做的事情:这不仅仅是“我希望能够使用这两个MODS”。这是“这两个Mod的作者在放置这个东西的时候有一个特定的想法。我怎样才能以最尊重这个意图的方式来改变这种冲突呢?”有时,这意味着保持一切的机智,但转移到一个稍微不同的位置,以便它可以适应。有时,这意味着禁用它的一部分,但添加一个新的访问点。有时,这意味着移动一些东西,但也增加了一些新的东西。不要害怕问父母的莫德作者他们的想法:如果我没有问过Wizchild关于在我的COTN Dawnstar-Lanterns of Skyrim II补丁中添加杆的话,我很可能最终会上传一些与MCM没有正确连接的东西,但是他很好地确保了我的修补程序有所需要的东西,这就是我是怎么学到的。得到反馈也很有用,这样你就不会做这样愚蠢的事情了;)


在一天结束的时候,你会把别人的作品放在你自己的作品上:尽可能地尊重原作者的意图。

6.一旦你的布局看起来正确,你的标记对齐了,我们就会找到有趣的部分:景观和肚脐。景观通常不是很糟糕--你已经选择了一个作为基线(不要混合和匹配,否则你可能会在单元格边缘有接缝,需要平滑这些缝),当你放置/移动物体时,你可能会注意到任何需要调整的区域。这样做。纳瓦格,另一方面.*叹息*这将是一种“尝试,再尝试”之类的事情。

7.一次只做一个细胞。选择一个单元格,从边缘开始,做你需要做的操作。尽可能使用顶点,而不是拖动整个三角形。注意高度:尽量保持在地面水平,或者一直保持在较低的水平。如果一堵墙被完全平分了一个肚脐网,确保清除三角形,这样NPC就不会试图进入它。如果墙壁被拆除,不要连接两个香草NAVMESH。通过这种方式将它们组合在一起,就可以制作出一个大的脐网格,并删除一个劣质的香草脐网格。以后的修补程序都无法恢复已删除的导航网格。如果你碰巧把一个MOD添加的脐网格和一个香草脐网格组合在一起,情况就变得更糟了,因为CK喜欢删除香草脐网格并执行mod的操作。这很糟糕。我们不想这样。让一切正常运转,没有任何删除,所有的边缘都很高兴,这将需要一些重大的努力。你不可能在一、二、五次会议上完成这件事:这可能需要好几个星期的时间。


这个“检查错误”选项对于查找导航网问题非常有用。一定要充分利用它。它还会捕捉到在压缩到ESL之后碰巧添加对象的任何时候,并且您有一个格式错误的标记ESL,所以您可以修复它。*)

8.当您完成每个单元格时,进行边缘检测和最后确定,然后保存。有时候,你会感到沮丧,抛掉整件事,然后重新开始:这很好。最好是慢慢地,一遍又一遍地做,直到它是正确的,而不是释放一些被破坏的东西。一旦你得到了全镇的东西,测试。把游戏装好。安慰自己一个随从。在城里到处跑,看他们的路线:有什么地方他们不去吗?纳瓦格问题。他们被困在哪里了吗?纳瓦格问题。遵循每一个全国人大的日常日程--他们是否选择了一条经过城镇的古怪路线,在一天结束时到达他们的家,而不是一条显而易见的路线?纳瓦格问题。他们只是站在周围而不是回家吗?纳瓦格问题。他们回家了,进去了,第二天就不出来了吗?纳瓦格问题。测试,测试,再测试。如果要处理的事情涉及到一项特定的任务:找到Helgi和Laelette,其中包括广泛的导航和高地大厅后面的景观,我花了几个星期的时间才能让这条山路上的路线正常工作,因为角落里有四个不同的细胞,它们都有边缘连接。“足够近”在这里不会发生,如果你想释放以供消费:最好不要释放,而不是没有得到正确的。看YouTube教程。不管怎么说,他们会给你提供比我更好的文本和截图格式的例子。

9.因此,一旦你对外表感到满意,当你在与独特的建筑打交道时,是时候转移到内部了。你想让内饰和你换的那些花哨的新外型相匹配。我倾向于做的是去CK,禁用所有的墙壁,并拉进新的结构内部,与新的外部,然后做了同样的事情,我在外面:对齐门。你会发现,很多时候,在成群结队的情况下,物品是一致的“对齐”--一组是睡眠区,一组是进食区等等。所以你把它们一齐移动,按需要旋转,直到它们在新墙的范围内。确保通过ReID面板中的每个项目(不应该太多),以确保没有丢失,嵌入在某处的墙壁,或类似的东西。

10.一旦完成了布局,现在又是导航网的时候了。一般说来,一切都是完全重新做的,旧的肚脐网几乎不适用,所以我倾向于把它修剪成一个三角形(门三角形),然后从头再做。靠近物体,但不要太近,NPC会撞到它们的。确保椅子、床、扫地等的任何标记都是可接近的。内部单元要比外部容易得多,所以它不应该花太长时间-做你的边缘标记,最后确定,保存,并在游戏中加载它。和以前一样:测试,测试,测试。确保任何一位NPC都能进出家门,我指的不是你的随从,我指的是那些在他们自己的AI包里的人。一旦你对那个细胞满意,就去下一个细胞。

我通常试着在一次坐着的时候做一个内部细胞,也许是两个。把它分成几个部分-过快会导致精疲力竭,这也会影响工作质量。

封闭思想

老实说,我不知道是什么驱使我把这整件事写出来的--我相对来说是“新”的,在这些事情发生的时候,我的第一本书已经出版了半年多了。然而,尽管有大量的兼容性补丁,但有时很难找到它们(用户特定的集合并不总是有“主题”),或者只在特定引用发生冲突时才更多地关注放置的对象匹配新的内部环境,更多地关注实际冲突的解决,所以当我决定开始使这些补丁变得像一个只被部分填充的利基--我当然没有完全填满它自己,但我希望我的经验能够帮助其他人在他们的个人负载订单上做同样的事情,如果没有其他的话。

这是一条崎岖的道路,有各种各样的麻烦(事实上,在我第一次上传的晚上,我得到消息说我的MIL的健康状况出现了转机,不得不飞到太平洋的另一边去帮助照顾她,所以我下个月没有电脑来排除我的错误。)很好的时机:P),但唯一不变的是社区的开放和帮助--几乎所有的人都能接受补丁的制作,并迅速提供帮助和建议。特别对JPSteel 2和战士们大声喊叫,因为他们不时地忍受我的PMs,因为我经常和他们的MODS一起工作,所以我对他们的困扰比其他任何人都要多。额外呼喊莱克西(氏)LOTDmodlist,它让我开始使用xEdit和CK,以及其他一些工具,这是我第一次尝试它的时候--我在这个时候已经把它扩展到了远离列表本身的地方,但是如果您正在寻找一个更有计划的地方来开始熟悉这些工具,并且您愿意花时间(认真地说:第一次安装可能是20小时左右),这是开始学习如何设置和使用这些工具的一个很好的地方。

最后,很大程度上要感谢那些不和谐的社区,当我深入讨论这些问题的时候,我发现自己只是在闲聊--前面提到的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.

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 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



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 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.

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?





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


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.

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. :)


原贴地址
1.版本号: 1.0   更新时间: 2020-06-28 15:48:41

选择快速回复类型:
  • 感谢
  • 支持
  • 疑问
  • 卖萌
  • 关心
  • 傲娇
评论


    作者精品
    logo

    冲突解决和3D空间修补的简要演练


    Mod大小:0.14KB
    上传时间:2020-06-28 15:35:07

    Mod简介:

    暂无更多介绍

    本地下载
    选择快速回复类型:
    • 感谢
    • 支持
    • 疑问
    • 卖萌
    • 关心
    • 傲娇
    回复

    这个人很懒,什么也没留下

    点击上方“关注”按钮即可收到作者的更新提醒哦~