前排占座

所以vortex呢

零、从MOD开始
你问为什么标题从零开始？因为数组下标最小值是0，这是常识啊我的朋友！
我们首先知道，所谓的“MOD”，在游戏这个特定语境下，值得是“玩家根据自己的需求对游戏内容作出的修改”，这个定义包含两个方面的意义：
第一，玩家对游戏内容的修改才是MOD，有官方对游戏内容作出的修改，那就是Update，或者DLC（收费的！）
第二，既然是玩家的修改行为，也就包含着“游戏内容可以被玩家所修改”这个前提，也就意味着，在一定程度上，游戏本身是要有一定的可修改性的（无论是否被官方所承认）。
根据这一结论，我们可以简单的根据游戏是否可以被玩家所修改，以及，哪些游戏内容可以被玩家所修改，来定义一个“可修改性”或者“可MOD性”。
那么我们根据这个标准来衡量市场中的游戏产品，会发现有的游戏可修改性很低，玩家只可以通过某些简单的文件替换操作修改游戏的部分内容，例如模型，贴图，音乐；有些游戏的可MOD性很高，官方提供MOD制作工具供玩家使用来创作内容；有的游戏更为夸张，整个游戏只是提供了一个基础的平台，玩家可以高度自定义游戏内容。
要分析这个可MOD性，我们首先来看看一个游戏主要有哪些部分构成，其中哪些部分是可以在游戏发售后由玩家来进行修改的。
首先构成游戏产品基础的是程序，游戏本质上是一种软件，一个程序，游戏的程序部分不仅承载着游戏运行的基础，同时也决定了游戏的运行逻辑和机制，也就是时下被热烈讨论是否可以被视为抄袭的“玩法”。
其次作为一种程序，游戏与其它软件产品的不同在于它非常重视UI，也就是用户界面的质量。游戏作为一种娱乐产品，其目的是为玩家带来享受的体验，因而游戏直接与玩家打交道的部分——也就是用户界面的质量，将直接影响玩家的游戏体验，一个拥有良好甚至优秀素质但因用户界面过于不友好而翻车的游戏产品在游戏史上屡见不鲜。
第三是游戏的美术资源及各种资源文件，广义一点包括了模型，贴图，动画，动作，音效，音乐，文本等等， 这些组件是游戏程序向玩家呈现的主要内容，因而显然也决定了玩家对游戏产品的感官体验评价。
（此处将UI单独拆分出来自然是为了方便分析滚5，否则的话UI本身自然也可以分为程序与美术资源两个部分。）
那么，如果对各类游戏（至少是大部分游戏产品）的MOD进行分类，我们会发现，涉及修改游戏美术资源的MOD是数量最多的，部分MOD涉及修改游戏的UI，只有极少量MOD可以修改游戏程序的运行逻辑（但很多策略性游戏就并非如此），这个现象并不奇怪，对美术资源文件进行替换和修改稍微容易一些，而修改程序逻辑显然是要求有较高的技术水平。

师匠好评

牛

前排围观支持

新人: mo大法好，大佬，求nmm教程

而对应到以《上古卷轴5》为代表的贝塞斯达旗下creation引擎创作的游戏，我们可以看到，《辐射：新维加斯》、《上古卷轴4》、《上古卷轴5》这几款产品，都拥有令人惊讶的极高的“可MOD性”，玩家可以自定义游戏内容的范围从模型、贴图、UI、音效、动作到游戏的数值数据和脚本，几乎涵盖了游戏的所有内容，以至于在这些产品发售很多年后，其对应的MOD社区依然保持着强大的生命力，而由玩家所创建出来的MOD所构建的游戏内容，可能也远远超出了这些产品有原本的开发者所创作的范围，这种特性虽然不能称为“独树一帜”（其他支持高MOD扩展度的游戏也不少），但至少也是“别具一格”了。
自《上古卷轴5》发售之后的玩家可能会惊叹于滚5强大几乎无所不能的MOD扩展度，而一个略显微妙的事实是，实际上滚5的MOD发展至今日，其MOD可修改范围也基本没有超出发售于2006年的《上古卷轴4：湮灭》的MOD圈范围太多，尽管在MOD的精细程度、质量和数量上二者已不可同日而语，但仅仅就MOD能够修改的游戏内容而言，很多滚5的MOD能够做到的修改，在滚4时代就已经存在了，甚至很多滚5时代的MOD，都可以在滚4MOD中找到其前身。
而随着越来越多的游戏厂商开始认识到由玩家参与创作游戏内容这个行为对于延长游戏产品生命周期的意义之后，游戏厂商也开始纷纷改变对于MOD的态度，逐渐从无视、技术封锁到默许甚至是鼓励玩家进行MOD创作，不少厂商也如同B社一样参与到了营建官方MOD社区的行动中，开始积极探索和推动MOD社区商业化发展。
当然由于本人见识浅薄，无法对各个厂商的游戏产品对于MOD的支持情况进行对比分析， 因此对于其他类型游戏产品的MOD支持就不多赘述，我们依然是以《上古卷轴5》为对象进行讨论。

一、档案，与档案无效化
首先我们可以肯定的是，一个游戏产品，在不安装任何MOD的情况下，应该是可以正常运行，并且为玩家提供完整的游戏体验的，MOD所提供的内容，仅仅是“附加于正常游戏之外”的部分，不存在某个游戏必须依赖于某些MOD才能玩的说法，《上古卷轴5》也不例外，即便我们将《上古卷轴5》的MOD全部去除及无视，它也毫无疑问是一款质量上乘的开放世界角色扮演沙盒类游戏。
所以，在讨论一个MOD是如何在《上古卷轴5》中生效并运行之前，我们不妨先来看看，一份原生的《上古卷轴5》的结构是怎样的：

上图为一份完整的、无任何MOD的《上古卷轴5：天际》传奇版Data目录的文件结构，因为Data目录下存储了滚5全部的游戏内容，除了游戏主程序。
所以首先我们可以看到，在这个状态下，原生的滚5是不含Meshes、Textures、Scripts等这些MOD常用的存储目录的，反过来说，之所以我们会在一份安装过某些MOD的滚5的Data目录下看到meshes、texures等目录，完全是因为这些目录中存储的就是MOD文件而已，对于上古卷轴5的游戏本体而言，这些内容都是“不需要”的。
那么除了Interface（存储了一个UI词条本地化文件），Strings（存储词条，用于本地化）和Video（里面只有一个文件，那就是滚5打开后B社的LOGO动画）目录，Data目录中存储滚5资源文件的分为两类，一类是Esm文件，即Elder Scroo Master，此类文件是滚5（也包括滚4）的数据文件，游戏的全部数据（例如人物、任务、装备、技能、天赋
模型链接路径、地图等）都压缩存储于Esm中；而其余的部分，也就是美术资源和脚本（控制游戏的运行逻辑），全部储存于BSA文件中，这些BSA文件，被称为BSA Archive，也就是档案。
如果我们手头有BSA Browser这个工具的话，可以尝试浏览一下Skyrim-Meshes.bsa文件，我们会发现在这个BSA档案中存储的就是滚5本体（不含DLC）的所有模型文件，包括人物、动物、静物、武器、服装、道具、物品等，而这个BSA解压后，其存储的路径恰好就是Data\Meshes.
而如果再观察其它几个BSA档案文件我们也会发现相同的结论，Skyrim-Textures.bsa文件存储的是滚5本体的贴图文件，其存储路径是Data\Textures，其余BSA同理。
此处我们很快联想到，既然MOD所引用的资源文件也是存储于这些路径，是否可以解释为：将某些资源文件放置于Data目录的正确路径下，例如将一个男性人类的自定义身体文件命名为malebody.nif（在Skyrim-Meshes.bsa中就有这么一个文件），然后放置于Data\meshes\actors\characters\character asstes\下，就可以让游戏在运行时加载自定义的身体文件，而不是BSA档案中的那个版本，从而达到MOD的目的？
没错，上古卷轴5的MOD，也包括上古卷轴4，辐射4，辐射：新维加斯，这几款Creation引擎创作的游戏，其MOD原理正在于此，它允许玩家将自定义的游戏内容文件放置于游戏的数据目录的正确路径下，指定游戏在运行时优先加载位于Data目录下的资源文件，而非解压BSA档案文件，从而实现玩家自定义游戏内容的目的，这个功能，被称为“档案无效化”，BSA Invalidation，如果对滚4时代的OBMM还有印象的玩家可能还记得，OBMM的一个功能，以及利用OBMM加载滚4的一个重要步骤，正是“BSA档案无效化”。

顺便我们再来看看，在曾经的T网，现在的N网上，有一篇关于“如何实现档案无效化”的教程

从这篇教程中可以看出，档案无效化决定着MOD所修改的资源文件是否可以生效，因而是游戏加载MOD的一个必须步骤，不过各位滚5的入坑的萌新们不用心慌，在教程上方N网已经发出了安民告示：
This article pre-dates all modern "mod managers" (such as "Wrye Flash", "Fallout Mod Manager (FOMM), "Nexus Mod Manager (NMM), and "Mod Organizer" (MO)), which incorporate BSA Redirection "ArchiveInvalidation" into their interface. Do not combine multiple methods of "ArchiveInvalidation". Choose one and get help in it's support forums.
“这篇文章提到的档案无效化方法相对于各种现代化的MOD管理工具，例如NMM，WryeBash（又一个时代的眼泪，WB），FOMM（新维加斯的管理工具，后来和OBMM合并成为了NMM），NMM，以及最新的MO相比都已经过时，因此不推荐进行手动实现档案无效化的操作”。
但不论MOD管理工具如何发展，MOD社区如何进步，到目前为止，Creation引擎的游戏实现MOD扩展的基本机制依然是档案无效化。
说完了美术资源文件的档案无效化，我们再来看看数据与数值是如何档案无效化的。由于游戏的数值数据是存储于一个单一的Esm文件中，这个Esm文件不像BSA档案文件可以进行解压从而释放出资源文件，Esm本身就是一个数据库文件，基于数据库的特点是不可能实现像文件系统那样的BSA档案无效化的，因此仿照对于数据库的修改操作，我们对于Esm的修改实际上是通过Esp(Elder Scroll Plugin）来修改的，ESP文件也就是我们常说的“插件”，在ESP文件中存储着我们对游戏内容数值和数据方面的修改记录，但，它仅仅“只”存储修改的部分而已，例如，某个ESP可能修改了一个技能的伤害值，而这个技能伤害的原值，并不存储于ESP中，这个ESP文件中除了这个修改，也不含其他内容。反过来也是一样，由于这个技能的原始伤害值必然是存储于ESM文件中的，而我们的修改是保存在ESP中，所以ESM中的数据是保持原样无修改的，那么我们的修改如何生效呢？规定必须在ESM和ESP同时激活的状态下，游戏将首先加载ESM的数据，然后加载ESP的修改记录，此时，游戏运行时的数据就变成了修改后的值。
如果有多个ESP对同一项数据进行了修改怎么办？例如令r=5，A修改r让其=3，B修改r让其=4，此时r的最终值将由最后一条修改记录决定，也就是修改顺序很重要。
此处就可以解释在游戏运行时，插件的加载排列顺序为何很重要了，以至于我们不仅需要一个MOD管理器，甚至还需要专门的MOD排序管理器。
显然ESM与ESP这种数据存储结构是使用了数据库中“事物(Transaction)的概念”，ESP可以看做是一系列对于数据库的操作（增删改），游戏在运行时依次顺序执行ESP中的操作，最后反映出数据的最终状态。
这样设计的方便之处就在于，既然可以根据事务顺序执行数据修改，反过来将这个事务从队列中去除，那么这个部分的修改也就不存在了，这样一来，来自不同事务间的操作便被隔离开来了（除非它们修改的是同一项数值），另外，只要将全部事务去除，数据又将回到原始未修改的状态。

这个吧怎么还有人发技术贴

上文打错字了， 是事务，Not 事物
那么有鉴于“档案无效化”这个原则，我们可以得出一条重要的结论，而这个结论，是很长时间以来被不少玩家所忽视的——
“任何MOD对于游戏的修改，只会生效在游戏运行时，而不会对游戏本身的档案文件造成任何修改”。
通过这条结论，我们知道了，如何还原一份安装了MOD的《上古卷轴5》，将其还原至初始状态？是将游戏目录下的所有文件全部删除然后重新安装吗？否，只需要将所有除了游戏本体所使用的档案文件之外的所有文件删除，就可以了。
（也就是说，历代以来所有“安装MOD出错不得不重装游戏”的做法是完全没有必要的）
B社的开发与设计人员非常聪明地设计了这套机制，使得玩家有充分的自主权可以自定义游戏内容，同时保证游戏产品自身的完整性，在很多游戏中，类似机制屡见不鲜。
二、NMM的时刻，Nexus崛起的时刻
从Nexus官方的资料来看，NMM，即NexusMods官方开发的MOD管理工具，其前身至少包含了FOMM与OBMM，而大部分功能也来自于二者，那么NMM的功能有哪些呢？
可以加载压缩包格式的MOD，例如rar，zip，7z，以及NMM专属格式FOMOD（实际并不是专属，FOMOD本质就是RAR压缩文件），自动解压，一键安装，并激活插件。
可以通过MOD分类管理功能，支持自定义分类。
支持在线连接N网，对于所属N网的MOD可以检查版本并自动更新（对国内玩家意义不大）。
支持MOD在安装时进行UI交互，可以提供简单的交互逻辑，让玩家可以根据自己的需求进行MOD文件的部署。
可以说最后一个功能才是现代MOD管理器的基础，因为这个功能的出现，极大地简化了复杂MOD的安装，例如，对于很多彼此存在修改冲突（试图修改同一部分内容）的MOD，玩家必须根据自己的需求进行选择性安装，而程序是无法代替玩家做出这种选择的——安装菜单的出现，才让制作整合包这种巨型MOD有了实现的可能。
但除此之外，NMM在管理MOD方面的逻辑极为简化：
首先将玩家交付的MOD压缩包存储在一个目录下，然后将其解压（解压生成的文件会存储到缓存目录上），解读安装清单，将解压后的文件复制到Data目录下，并激活插件，由于已经事先实现了档案无效化，所以这个MOD在运行时就可以被加载读取了。
对于存在写入覆盖的MOD，NMM会记录被覆盖的MOD文件列表，在覆盖者被卸载后，将被覆盖者的文件再写回Data目录，完成一次回滚。
这种简单机制带来的问题有以下：
第一，效率低下，NMM首先要解压MOD，然后记录MOD文件列表，写入Data目录，在这种过程中，一份MOD存储的空间包括了这个MOD本身的压缩包（位于NMM存储目录下），解压后的文件展开于Data目录（安装后），以及解压生成的部分缓存文件。
第二，顺序问题，NMM本质上是进行顺序式安装，安装MOD的顺序就决定了写入Data目录的顺序，假设有A和B两个MOD，正确的顺序是AB，使用NMM时不慎安装成了BA，在这种情况下，由于A的文件是后序，拥有优先权，要调整为正确的顺序不得不卸载A MOD，再卸载B MOD，然后依次安装AB，极为耗费时间，而如果遇到多个MOD需要严格安装顺序的情况更是无能为力。