VIII.MODlist与文件系统
接下来，我们来学习一下MO2的文件系统。
在此之前，我们先右键MODlist最上方的列标题，然后选择确保冲突，标记，版本与优先级处于选中状态，并调整一下它们各自的宽度，令其内容能够正常展现。
1.文件覆盖与排序
我们安装完skyui插件补丁之后，你可能已经发现，在MODlist中，SkyUI与skyui插件补丁这两个MOD右边出现了闪电的小标记。
将鼠标移动到这个标记上，等待一会，会弹出说明。
在MO2中，如果MODlist中的MOD在冲突这个列标题下有闪电的标志，则说明该MOD与其他MOD存在同名同路径的文件，因而具有覆盖关系。如果闪电的标志旁是
+号，则说明它覆盖了其他MOD的文件，如果闪电的标志旁是
-号 ，则说明它的文件被其他MOD覆盖了。
我们再来试试别的操作。
如果你选中
skyui插件补丁，你会发现上方的
SkyUI变成了绿色。
反过来，如果选中了
SkyUI，那么下方的
skyui插件补丁就变成了红色。
这个绿色与红色，就代表着谁覆盖了选中的MOD，或者选中的MOD覆盖了谁的文件。
在该案例中，我们可以很容易的看出来，
skyui插件补丁有文件覆盖了
SkyUI，由于
skyui插件补丁是
SkyUI的一个修复补丁，它覆盖
SkyUI是正确的，是我们想要的结果。
在MO2中，处于下方的MOD具有高优先级，它的文件会覆盖掉上方具有同名同路径文件的MOD。在日后，我们经常会遇到具有覆盖关系的MOD，而我们必须通过调整MODlist排序，来控制文件的覆盖。
现在，我们右键
SkyUI，然后选择
信息...
在弹出的MOD信息窗口中，选择
冲突选项卡。
在冲突中被覆盖的文件一栏下方，我们可以非常轻易的得知，
SkyUI的插件
SkyUI_SE.esp被
skyui插件补丁覆盖掉了。
此时，如果你在右边的loadorder中选中
SkyUI_SE.esp，你会发现左边MODlist中变成紫色的MOD不再是
SkyUI，而是
skyui插件补丁了，因为
SkyUI的插件已经被覆盖，此时插件来源是
skyui插件补丁这个MOD。
在MO2的MOD信息中，我可以像这样看到有哪些MOD的文件被覆盖，或者有哪些文件被保留。
但这里的覆盖并不是说文件就真的被覆盖了，如果你右键两个MOD在资源管理器中打开，可以看到它们的文件都还呆着好好的。
得益于MO2的虚拟文件系统，MOD的原始文件不会被改变，文件的覆盖只会发生在通过MO2启动游戏后生成的虚拟文件夹中。这意味着我们可以随意调整MOD之间的覆盖关系，也就是排序，而不必担心弄乱文件，例如你可以轻而易举的将
skyui插件补丁拖到
SkyUI的上方。
不过在乱动MOD排序之前，我们先来看看MOD上方这两个按钮。
将鼠标挪上去等待一会，可以看到说明。
左边的是
还原备份，右边的是
创建备份，这个备份备份的就是排序。
我们先点击一下
创建备份，将我们现在的排序备份好，以方便接下来还原。点击后，MO2下方最中间会弹出提示。
好了，现在我们可以随意乱动排序了，按照之前所说，我们将
skyui插件补丁拖到
SkyUI的上方。
此时，就变成了
SkyUI覆盖
skyui插件补丁，你会发现
skyui插件补丁冲突类标题下的标志变成了一个白色闪电。将鼠标挪过去，它的说明显示为
冗余。
这是因为
skyui插件补丁只有一个
esp插件文件，而这个插件被
SkyUI的插件覆盖后，它就没有任何有效文件了，它失去了意义，这个MOD变为了冗余。一般来说，不应该有任何冗余MOD出现在我们的MODlist中，一旦发生这种情况，要么是MOD排序出现问题，要么是安装了没必要安装的MOD。
现在的排序显然是错误的，那么我们要回到之前的排序，点击
还原备份按钮，会弹出一个对话框，这里会按照日期显示曾经备份的排序，我们在之前备份了一个，选择它。
排序恢复了。
以后MOD会日益增多，常备份将会是一个非常重要的习惯，这样当我们不小心弄乱排序时，还有挽回的余地。
2.虚拟文件
我们知道，MO2在游戏运行时会建立一个虚拟文件夹，那么，有没有什么方式可以预览这个由MODlist中的MOD文件最终构建出来的虚拟data目录呢？
当然有，在MO2右边窗口里，有一个数据选项卡。
切换到这里，就可以预览虚拟data最终呈现出来的文件结构。
除了名称和类型，模组这个列标题下还显示了这些文件的MOD来源，其中Creation Club指的是CC内容，即官方MOD，它和显示为DLC、<未受管理>的文件一起都属于游戏本体的文件。
向下翻，我们还可以看到一个显示为红色的MOD。将鼠标挪动到这个红色MOD上等待一会，弹出的说明中会告诉你，该文件的来源，以及这个文件还存在于哪个MOD。模组列标题下显示为红色的文件，意味着该文件存在于多个MOD中，具有覆盖关系。
如果你觉得这里的虚拟文件看的不舒服，你还可以用另一种方式来打开它。
将MO2右上角的程序选择切换为Explore Virtual Folder（浏览虚拟文件夹），然后点击运行。
此时就会打开一个文件浏览器，可以看到这个文件目录的地址正是游戏目录下的data，但这并不是真实目录，而是由MO2创建的虚拟文件夹。这里仅供浏览，你不应该在这里对文件进行任何删改，否则可能会发生错误。
3.BSA文件
了解完文件的覆盖与排序，我们再看看一个特殊的文件类型，bsa。在之前了解标准skyrimMOD的时候，我们已经知道，bsa是skyrim的打包文件，它就像是一个游戏专用压缩包，性能要比不打包的文件要好。
除了游戏本体的bsa包，在SkyUI的文件中，也有它自己的bsa包。
但事实上，在skyrim的众多MOD中，使用bsa包的MOD只占极少数。
这是为什么呢？
bsa包有一个特殊的机制，就是它会被所有的松散文件覆盖。
例如，A MOD有一个文件，B MOD也有一个同名同路径文件，但是B MOD的文件被bsa打包了。
那么即便你将B MOD在MO2的MODlist中放置在A MOD的下方，具有比A MOD更高的优先级，被覆盖的也是B MOD这个被bsa打包的文件。
因此，MOD作者在制作MOD时，只有确保自己MOD中的文件一定不会有同名同路径文件覆盖，或者可以随意被覆盖，才会将文件打包成bsa。
在右边的loadorder中，你可以看到SkyUI_SE.esp的右边，标志类标题下有一个宝箱的标志，鼠标挪过去等一会，会告诉你此插件带有封装包文件，即bsa文件，它的说明里也告诉了你bsa文件的特点。
4.MOD分类
尽管我们目前的排序没有问题，不会导致游戏出错，但并不科学。
skyui插件补丁作为SkyUI的补丁，它们之间关联紧密且存在覆盖关系，但现在在目前的排序中，它们相隔甚远，中间还搁着MCM Helper这个无关MOD。
为了方便管理与辨识，我们应该将skyui插件补丁拖到SkyUI的下方，让它们紧紧相连。
当我们在排序MOD时，不仅仅要把覆盖关系调整正确，还要考虑到是否方便对MOD进行管理与辨识，特别是日后MODlist中有成百上千个MOD时，为了自己好，一定要更加科学排列MOD。
那么在排列一个东西时，最好的方法是什么呢？没错，分类，在日后，我们会安装茫茫多的MOD，因此对MOD进行分类非常重要，而MO2也给我们提供了这个功能。
首先分析一下，就我们现在这一点MOD，要如何分类？
汉化针对游戏本体，BEES和SKSE插件地址库都是重要的前置MOD，SkyUI是界面MOD，而MCM Helper虽然也算是前置，但它属于SkyUI的下级MOD。
因此，我们现在可以这么分类，汉化在本体优化分类，BEES和SKSE插件地址库在重要前置分类，而SkyUI和MCM Helper算在界面交互分类。
分类是一个比较个性化的东西，但它整体来说遵循一定规律，分类的排序也在宏观层面上控制MOD文件覆盖关系，同时也能帮助我们对插件进行排序。这是一个重要，但又非常依赖经验的内容，因此在初学期间建议先按照指南的分类来进行。
右键排在最上面的汉化MOD，选择所有模组，然后点击在上方创建分隔符。
然后在新弹出来命名窗口中输入本体优化，点击确定。
此时，一个新的分类就出现了。
接下来是重要前置分类，在BEES上方再创建一个分隔符，命名为重要前置。
然后在SkyUI的上方添加“界面交互”。很好，现在我们已经非常科学的将这几个MOD分好类了。
但排序上还是稍微有点小问题，不知道你还记不记得，我们安装BEES的时候，SKSE插件地址库是作为它的前置要求而存在的。
我们习惯于将让一个MOD的前置MOD排在它的上方，哪怕它们并没有覆盖关系，来调整一下。
现在我们的MODlist已经非常容易辨认了，你还可以点击分类左边的向下箭头将这个类别折叠，在以后你需要在大量MOD中筛选时，你会需要用到这个功能的。重新点击箭头即可再次展开。
最后，让我们来看看我们目前的成果吧，随便选择一个MOD，然后右键在资源管理器中浏览。
然后点击资源管理器地址栏左边的上箭头，来到mods这个上级目录。
看，这就是我们当前安装的所有MOD啦，mods目录就是MO2储存MOD文件的地方，这是我们在创建MO2实例时选择的目录，还记得吗？
你可能会发现，我们刚刚创建的分类也在其中，是一个文件夹，格式为分类名称_separator。实际上，分类就是一个伪MOD，_separator是一个标记，告诉MO2这个文件夹是一个分隔符，而不是一个MOD。
IX.插件与loadorder
了解完MODlist那边的内容，我们再来看看右边的loadorder，这次的主角是插件。
1.认识插件
插件里记录了游戏的数据，并告诉游戏该如何运用包括贴图，模型，脚本在内的资产，那么它具体到底是怎么运作的呢？
SSEEdit是一个能够浏览与编辑skyrim插件数据的工具，当然，现在的你不需要学习如何使用，但我们可以用它来看看一个插件里的数据都长什么样。
那么看哪个插件呢？如果是有哪个插件最为典型，那么一定是skyrim.esm，是的，游戏本体的插件。
在skyrim.esm下，有非常多的数据，SSEEdit通过分类让我们更好的检索，我们可以看到这些类别各式各样，有装甲，有书籍，有NPC，有武器，有对话等等等等。
现在我们来看看一个具体的数据长什么样，我们点开Weapon武器分类，这下面有很多武器，随便选择一个，就可以看到该武器的具体数据。
这些数据对新手而言还是有点过于复杂，但我们可以挑点容易理解的看，例如，我们可以数据中找到武器的名称，武器用的模型（skyrim中的模型就是nif文件），武器的具体数值，例如它的价格，重量，伤害，武器类型，攻速，攻击距离等等。
用更专业的名词来说，这把武器是skyrim插件中的一条记录（Record），记录中则是它的所有属性（名称，价格等）以及对应的值（铁制剑，25等）。
在skyrim中，一把武器就是通过这些属性值组合而成，各种类型的记录，例如装甲，NPC，对话等也都是通过各种各样的属性值组合而成。
相对应的，如果我们要在游戏里添加一个新的武器，那么我们会创建一个新插件，然后在这个插件中添加一条记录，接着在这条记录中的属性里填写数值，例如武器用的模型，武器攻击造成的伤害等等。最终游戏运行时会加载这条插件中的记录，一把全新的武器就这么出现在了天际世界，一个简单的武器MOD诞生了。
2.插件排序
在之前我们说过，MO2中显示插件的列表叫做loadorder，翻译过来就是加载顺序，这个命名显然已经告诉了我们，插件也有排序，而且可能是一个非常重要的环节。
一个事物既然需要排序，那么肯定是因为它们有优先级之分，就比如覆盖关系。没错，插件之间也是有覆盖关系的，我们不妨来看看另一条记录。
火球术是skyrim中的一个法术，从图中我们可以看到，有两个插件都涉及到了这条记录，Skyrim.esm是游戏本体的插件，而Dawnguard.esm是黎明守卫这个DLC的插件。
这两个插件的火球术有一个差别，Base Cost（基础法力消耗）这个属性的值，Dawnguard.esm要比Skyrim.esm更高。
我可以认为，当B社为skyrim推出黎明守卫DLC的时候，他们认为原始版本中的火球术法力消耗太低了，因此在DLC中，他们提高了火球术的法力消耗。
如何提高呢？自然是更改黎明守卫DLC中火球术的法力消耗属性的值，然后让Dawnguard.esm中的火球术记录覆盖掉Skyrim.esm的。
在MO2的loadorder中，来自游戏本体的插件被锁定了，但我们可以看到，Dawnguard.esm排在Skyrim.esm的下方，与MODlist一样，在loadorder中排序位于下方的插件，优先级要高于上方的插件，当两个插件拥有同一条记录时，下方插件的记录数据会覆盖掉上方插件的记录。
在此之上，还有一个非常重要的概念：记录是插件覆盖中的最小单位。记录就是一个无法再拆分的整体，因此我们不能同时使用A MOD记录中的1属性值和B MOD记录中的2属性值。这个概念会在日后造成很多尴尬的MOD冲突问题，但没关系，有问题就会有解决方案，我们将会在以后进行了解。
3.Master
skyrim游戏本体的插件已经被锁定，无法进行排序，但我们还有两个自己安装的MOD有对应的插件。现在，不妨像之前调整MODlist排序一样，将MCMHelper.esp拖动到SkyUI_SE.esp的上方试试。
当然，别忘了插件排序也是有备份和恢复的。
但当你真的尝试时，很快你就会发现，拖不动。这是为什么呢？我们将鼠标移动到MCMHelper.esp上，然后等待一会。
在弹出的插件描述中，我们可以看到一个关键信息，已启用的前置插件：SkyUI_SE.esp。
这意味着，SkyUI_SE.esp是MCMHelper.esp的Master，前置插件。一个插件，永远只能处于它Master插件的下方，游戏只有在加载了Master后，才能加载将它视为Master的插件。
一个插件将另一个插件视为Master有很多原因，其中主要的是这三条：
- 该插件需要使用Master插件的数据。例如，
M插件中有一条盔甲的记录，而A插件中有一个NPC记录，其服装属性中的值有这个盔甲，因此，A插件必须依赖M插件中的数据才能成立，所以A插件将M插件标记为自己的Master。
- 该插件的记录需要覆盖Master插件中的记录。这常常出现在某个MOD的补丁插件中，如果
M插件有条记录中的属性值有问题，那么作为补丁的A插件，就会有一条修复了属性值的相同记录，通过覆盖M插件的记录来修复问题。此时A插件将M插件标记为Master，这样A插件就必定只能排序在M插件之后对M插件进行覆盖，可以防止用户胡乱排序。
- 插件之间没有任何数据关联，但
A MOD的前置MOD是M MOD，为了防止用户忘记安装M MOD，A MOD的插件将M MOD的插件标记为Master。
现在，我们来尝试一件事情，将SkyUI_SE.esp这个插件取消激活。
然后你就会发现，MCMHelper.esp的标志列标题下多了一个红色警告标志。好吧，由于MCMHelper.esp的标志比较多，因此多出来的标志太小了，但如果你将鼠标挪到MCMHelper.esp，弹出来的信息会告诉你缺少前置插件：SkyUI_SE.esp。
MO2的右上角会新增报错，其中就有缺少前置插件，并告诉你哪个插件缺了什么插件。
在任何时候，都不应该有插件缺少前置Master插件，出现这种情况一定是你在安装MOD的过程中出了差错，例如忘记安装前置MOD等等，缺失Master会导致游戏无法运行或者出现错误，因此需要优先处理修复。现在，重新将SkyUI_SE.esp激活吧。
4.插件类型
之前说过，skyrim的插件有三种类型，esm，esp，esl，它们都是插件，在我们的loadorder中也已经集齐了这三种类型的插件。
不过尽管都是插件，它们之间还是有一些区别。
ESM，全称Elder Scrolls Master，中文可以叫做主插件，看到Master你应该也能明白，ESM插件大多都是某些插件的前置插件。在插件排序中，主插件永远高于非主插件，游戏只会在将全部主插件加载完后，才会加载其他插件。这也意味着主插件有着类似于bsa包的地位，它们几乎永远是被覆盖的那个，因此只有MOD作者认为自己的插件肯定不会被覆盖，或者可以被随意覆盖，才会把自己的插件制作成主插件。
ESL，全称Elder Scrolls Light，中文可以叫做轻量插件。值得一提的是，ESL分为两种概念，一种是esl格式的插件，一种是被标记为ESL的插件。我们这里只看esl格式的插件，这种插件可以称之为轻量主插件，是的，它也是主插件，这意味它同样遵循ESM的排序规则。至于轻量，我们马上就会讲到。
ESP，全称Elder Scrolls Plugin，直接叫它插件就好，它也就是平平无奇的普通插件，会在主插件加载完后加载。
现在我们可以比较轻易的看出，插件类型主要体现在排序规则上，但还有一个问题没有得到解答，轻量插件是什么？
5. 轻量插件：ESL
对于Skyrim的引擎（Creation Engine）而言，每一条记录都有其索引，这个索引叫做FormID。
FormID是由一串8位16进制数组成的，因而它会有一个上限。如果你不理解，我们举一个简单的例子，如果一个数字只能有三位数，那么它的最大值就是999，因此，000-999，一共只能有1000个数字，这就是上限。
不过，这个上限对于skyrim而言非常大，一共能够168 = 4294967296个数字，一个数字对应一条记录索引FormID，也就是说，skyrim最多可以有4294967296条记录。
但是，我们还需要插件这个事物来表明记录的归属，记录必须分配到插件当中，那么如何表示一个记录是在哪个插件当中的呢？
B社使用了FormID开头的前两位来代表插件，这就是插件索引。
在MO2中，我们可以在loadorder中看到
插件索引，这个索引跟这些插件下记录的
FormID前两位一模一样。
于是这出现了一个问题，插件的索引只有两位数，以16进制来说，它最多只能有16
2 = 256个数字，也就是说，包括游戏本体的插件在内，我们最多只能使用256个插件，而在实际上，出于技术和引擎设计的限制，
真正能使用的插件数量只有255个。255，对于庞大的skyrimMOD社区而言，这简直是沧海一粟。
情况很尴尬。对于记录来说，哪怕把它的
FormID前两位定死，它也还有6位数字可以使用，16
6 = 16777216，这么多个数字，就算把游戏本体和DLC所有的记录加在一起都绰绰有余。可就为了区分出记录的插件归属，一个插件内那点记录把自己对应的
FormID数字用了之后，还剩下一大堆可以使用的索引数字都被浪费了。
理想情况下，skyrim一共可以使用255（
插件索引的数量）乘以16777216（定死
插件索引后记录索引
FormID的数量）个记录，但现实就是，256个
插件索引数量会被轻易用完，而每个插件内16777216个
记录索引大多都只用了1到1000个，这是大部分MOD插件里会拥有的记录数量。
在很久以前，为了解决这个问题，我们会对插件进行合并，既然一个插件中能拥有的记录数如此之多，那么干脆将多个插件中的记录合并到一个插件中，以此来节省插件位置。但这非常麻烦，既需要技术成本，也很容易出现问题。在B社发行了skyrim重制版，推出Creation Club后，他们意识到，如果不解决这个插件位限制的问题，那么skyrimMOD就永远等于是在戴着镣铐跳舞。
于是，B社想出了一个歪点子，就是轻量插件，Elder Scrolls Light，ESL。
B社的工程师并没有直接修改引擎的底层逻辑，毕竟，这么多年过去了，Skyrim 的引擎本身框架已经相当老旧，贸然更改会引发更多的兼容性问题。因此，他们想出了一个折中的办法：利用
插件索引的特殊处理机制，给 ESL 插件分配独立的“紧凑型索引空间”，从而绕开原有的 255 插件限制。
传统的插件（ESP/ESM）都需要用到一个
插件索引，占用一个完整的插件位，而 ESL 插件则通过共享索引的方式，打破了这种限制。简单来说，就是一堆ESL插件，都一起共用一个
插件索引。
这是怎么做到的呢？
16进制数是逢16进一位，用A-F表示10到15，因此，对于两位数的16进制而言，
FF就是其最后一位数，类似于二位十进制中的99。出于技术和引擎设计的限制，skyrim中，
FF这个索引被保留，并没有使用，因此，对于skyrim而言，插件的最大索引值是
FE。
回头看一眼MO2中插件的索引，你会发现，所有
esl插件的索引都是
FE开头。由于ESL插件的前两位永固为
FE，因此实际上，所有的ESL插件都被视为传统插件的最后一个，即索引为
FE的插件。
但每个ESL总不能索引都是
FE，它们总归是要有自己的索引来区分，因此，
FE固定，那么之后的后三位数就成为了它们的内部索引，ESL插件的索引由原来的2位变成了3位，16
3 = 4096，这意味着ESL插件最多能拥有4096个。对于skyrimMOD而言，4096加上原本的255-1个插件（这个1就是索引为
FE的ESL插件），这个数量基本足够了。
但这当然是有代价的，我们知道，
插件索引不过是取用了记录的
FormID的前几位，那么ESL插件的索引由原来的两位变成了2（
FE）+3（内部索引）= 5位，记录可以用的索引数自然就遭到了压缩，由原来的6位变成了3位，结果就是，ESL插件的记录数量上限变成了16
3 = 4096条。这对比传统插件的数量简直是缩水缩成了一个点，但对于记录只有1-1000条左右的绝大多数MOD而言，绝对已经足够了。
这就是ESL轻量插件，B社通过一些巧思，突破了本来的255个插件位置的限制，极大的扩展了游戏能使用的插件数量，凡是记录数小于4096条的插件，一律改为使用轻量插件即可。
但新的问题来了，B社推出了
esl格式的插件，却发现它在加载顺序上被限制了，它们必须在所有
esp插件之前加载，就跟
esm一样。这非常的不灵活，因为不是所有轻量插件都想让自己被覆盖的，很多补丁插件，它们往往记录数极少，可以作为轻量插件，但补丁又必须覆盖要修复的插件，如果这个要修复的插件是
esp怎么办？受限于排序规则，
esl只能排在
esp上面。
于是，一个新的方法诞生了。
6.ESP-FE
ESP-FE插件本身依旧一个esp格式的插件，只不过，他在文件内部被标记成了ESL。
也就是说，ESP-FE是一个披着ESL皮的esp插件，它即可以遵循esp插件的排序规则，又可以像esl插件一样使用FE插件索引，不占用255的插件位置。
还记得我们之前安装的skyui插件补丁吗？它最大的作用就是把SkyUI的插件标记成了ESL，因而我们少了一个插件位占用。
在MO2中，我们可以试着将skyui插件补丁取消激活，然后看看原本的SkyUI的插件在loadorder中的显示。SkyUI_SE.esp的索引是07，这是传统插件的索引。
我们再将skyui插件补丁激活，SkyUI_SE.esp的索引变成了FE:003，这是轻量插件的索引。
如果你观察仔细，那么你就会发现，在MO2的loadorder中，轻量插件会以斜体显示，同时在标志类标题下，还有一个黄色的圆形标志，这代表它是一个轻量插件。（MO2中将ESL称为中型插件，这翻译比较怪）
在日后，只要MOD提供了ESP-FE的轻量化插件，那么我们都应该优先选用它，以此来节省宝贵的255插件槽位。
顺便一提，esp可以被标记为ESL，其实也能被标记为ESM，被标记为ESM的esp会遵照ESM的排序规则。
X.MOD维护
最后，我们来看看MO2为我们提供的MOD维护功能。
随意在MODlist中右键一个MOD，比如SkyUI，点击在资源管理器中浏览，打开MOD文件目录，你会看到一个名叫meta的文件。
meta是ini格式的文件，ini是配置文件格式，通常用来存储配置信息或程序初始化参数，该文件是在你安装MOD时，由MO2创建的。它可以以文本格式打开，记事本，写字板都可以，你也可以下载一个更好用的文本浏览器，例如我所使用的Notepad3。
打开文件，我们可以看到很多有用的信息。
当然，实际上这里不是给我们看的，是给MO2自己看的。
而给我们看的内容在MO2中，MO2会在MODlist中显示你是否已经点赞，以及MOD当前的版本号，MO2还会对比N网版本与我们下载的版本，如果N网有新版本会提醒我们，例如此处的skyui插件补丁（这里实际上是skyui插件补丁原址的版本号没规划好，我们已经下载了最新版本）。
再次右键MOD，在弹出的菜单中，我们可以非常方便的对MOD进行维护。
我们可以检查更新或者忽略更新提示。
我们可以重新安装模组，因为MO2已经在meta.ini记录了MOD的安装文件。
我们可以直接在MO2中给MOD点赞，或者选择不想点赞以隐藏未点赞标志。
我们可以直接在MO2中关注跟踪MOD。
我们也可以直接在MO2中直接前往MOD的N网原址。
这一切都是因为MO2在meta.ini记录了该MOD的N网ID，并且直连了N网。如果你不是通过N网直连下载的MOD，那么绝大多是的功能你就无法体验。
例如，我们通过压缩包安装的汉化，能实现的功能就非常少。
因此，这里非常建议只要能通过N网直连安装的MOD，就通过N网直连安装，在维护MOD时，能够方便许多。
结语
到这里，上古卷轴天际MOD安装完全指南的第一部分就结束了。
尽管这只是第一部分，安装的MOD也寥寥无几，且几乎没有对游戏产生实质改变的MOD，但指南刻意通过这几个例子涉及到了几乎所有skyrim安装MOD的基础知识，并讲述了这之中的原理，这足够让对skyrim没有任何了解的新人进行入门了。如果你足够有悟性，那么你甚至可以现在就开始自己拓展自己的MOD，只要足够细心阅读每个MOD的说明，理解它们的用途、兼容性以及正确的安装方式，你就能够不断丰富自己的游戏体验，甚至逐步形成自己独特的MOD搭配方案，搭建自己的MOD环境。
当然，skyrimMOD相关的知识不仅仅只有这些，几乎每一个大类，无论是人物美化，还是环境美化，或是战斗，动作，装备等等，都有自己相应的难点与知识，在重MOD环境中，更复杂的安装需求，MOD之间的冲突解决、排序的优化以及MOD工具的使用都可能对你造成困扰。但只要愿意仔细阅读，多使用搜索引擎，多寻找相应的教程，那么这些问题终将会被解决，并成为你认知的一部分，积累越来越多，你也就成为了一个MOD高手。
在很多浸淫MOD多年的玩家心里，规划与安装MOD甚至是比玩游戏更有乐趣的一件事情，它甚至会提供一种我在设计一个游戏的快感，希望这样的快乐，你也能体会得到。
