[KSP] Module Manager Patch 基础教程
前言
本篇内容为 Module Manager 的基础语法教程，阅读完本篇你将学会：
认识坎巴拉太空计划中的 CFG 配置文件
Module Manager 的基础语法 - 增、删、改
如何运用 Module Manager 的机制对配置文件进行操作。
总结：你将能看懂一些简单的 MM patch 文件内容。
本教程所用的例子均在游戏版本 1.12.5，Module Manager 版本 4.2.2 的环境下进行编写。
如无说明，本文的所有给出的 Patch 示例的执行顺序按从上到下执行。
1.CFG 配置文件
CFG 配置文件，即文件名后缀为 .cfg 的文件，这是文本文件，可以使用任意的文本编辑器打开，如系统自带的记事本就能够直接打开（但一般情况下最好不要用记事本打开）。
坎巴拉使用了大量 CFG 配置文件来存储一系列由它自己定义的、统称为 ConfigNode 的一种数据结构里的信息。这些 ConfigNode 数据结构存储了大量游戏中需要用到的数据，比如部件、合同、存档、本地化文本等数据内容，这些数据内容在本文中统称为【游戏数据库】。CFG 里的内容可以看做从各种 ConfignNode 里序列化出来的内容，并且能够被反序列化读回到相应的 ConfigNode 中。在 CFG 中 ConfigNode 的一般形式如下：
其中：
NODE {} 就代表它是一个 ConfigNode，NODE 可看做为类型名，这是一个类型名为 NODE 的一个 ConfigNode
Value 表示是该 ConfigNode 里一个 Key (键)，被赋值为 value
然后，ConfigNode 中除了可以包含键之外，也可以包含 ConfigNode，像这样：
NODE {} 现在包含了另一个 ConfigNode ，即 NODE2 {}
游戏中使用 PART {} 来代表存储部件数据，比如原版游戏目录中的 GameData/Squad/Parts/Command/mk1poad_v2/mk1Pod_v2.cfg 的部件（Mk1 指令舱）文件：
在该 CFG 配置文件中：
PART {} 代表这是一个部件类型的 ConfigNode，为了方便行书，后续将用【PART 】代替。
name、module、author 正如开头例子的 Value，为 PART 下的“键”
MODEL {} 又是一个 ConfigNode ，是 PART 下的子 ConfigNode
游戏在启动时，会读取位于 GameData 下的所有文件夹和子文件夹内的 CFG 配置文件中的内容，此时将文件内容通过反序列化读入到内存中。
为了方便行书，后续出现的 ConfigNode 将用 XX 代替，如 PART {} 将用 PART 代替。
Module Manager 基础语法
Module Manager （简称 MM，下同）是一个能够在游戏载入时对 CFG 配置文件做出修改的 Mod 。MM 会读取某一类 CFG 配置文件内容，对指定的 ConfigNode 进行修改，这类 CFG 配置文件称为 MM Patch ，MM Patch 必须要在安装了 MM 才会起作用，在原版中不会认为这类 CFG 配置文件中的内容合法，也不会对里面的内容做出反应。MM Patch 需要遵守特定的语法，即 MM 语法，才能正确对相应的 ConfigNode 做出修改。
要对 ConfigNode 做出修改，无非遵循增、删、查、改 4 个方面，MM 提供了多种操作符来实现这些操作，但首先，需要认识 MM patch 的一般形式：
本篇作为基础教程，先不管后面的限定操作符是何物，只看前面内容。
[操作符]，即为要对该 ConfigNode 进行的操作，比如删除、或修改。MM 提供了下列操作符：
1. 如果留空，则为插入操作，即添加数据到游戏中
2. @ 代表修改操作，不算插入操作，这个操作符是用的最多的
3. + 或 $ 代表复制操作，实际应用中很少，但也还是很有用
4. - 或 ! 代表删除操作
5. % 是一个特殊的操作，当要查询的目标 ConfigNode 存在时进行修改，当不存在时则会创建一个新的 ConfigNode
[[ConfigNode][ConfigNode 的 name]]，要进行操作的目标 ConfigNode ，MM 会根据提供的内的 name 这个特殊"键"进行查询到该，然后根据里面的内容对当前游戏载入的数据中进行查询，支持通配符模糊查询。
下面将举例说明：
文件 TESTNODE.cfg：
游戏首先会添加 TESTNODE 到游戏数据库，该步骤在 MM 接管之前。
现有一个 MM Patch ：
文件 TESTPATCH1.cfg
此时 MM 读取到该文件时，会现在游戏数据库里筛选出类型为 TESTNODE 的，然后找出 name 的值等于 testName 的，然后根据 @ 操作符，进行编辑操作，添加 TEST2 的键到该中，此时游戏数据库中的 TESTNODE 内容会变成：
接着有第二个 MM Patch：
文件 TESTPATCH2.cfg
该 Patch 会复制一份上面 TESTNODE 的副本，然后对里面的 name 和 TEST 进行相应的修改（@ 操作符），且插入了一个 SUBNODE 类型（前面无操作符代表插入操作）的。
此时游戏数据库中会存在 2 个 TESTNODE，内容如下：
现有第三个 MM Patch：
文件 TESTPATCH3.cfg
该文件包含了 2 个 patch 操作，第一个 patch 将 name = testName 的 TESTNODE 中的 TEST2 删除；第二个 patch 将 name = copyTestNode 的 TESTNODE 中的 SUBNODE 删除。
游戏中数据库内容现在变成了：
这即是 ! 删除操作符的含义。
现在进入第 4 个patch：
文件 TESTPATCH5.cfg
和 TESTPATCH4.cfg 一样，该文件也包含了 2 个 patch 操作：
第一个 patch 将在 name = testName 的 TESTNODE 中创建一个新的键 TEST2 并赋值为 V1V
第二个 patch 则修改当前已存在的键 TEST2 的值为 V1V
即现在游戏数据库中内容为：
这就是 % 操作符的用法含义。
运用示例
场景1：对某个部件的名称改成自己想要的。以原版【PPD-12穹顶舱】部件为例，将名称改为【我的穹顶舱】。
首先打开原部件文件，获得 PART 的 name
原部件文件内容(部分摘取)
要更改名称即更改 PART 里面的 title 键，所以该 MM patch 为
文件 myPartTitlePatch.cfg
拓展场景：更改深层，如增大该部件的动量轮扭矩大小至 20，且耗电量为 0
MM patch 改写为：
场景2：更改 Mod 的设置文件，做到不直接动原文件的情况下对 Mod 进行设置
示例 Mod - KSP Community Fixes
目的：禁用掉 PAWStockGroups 的功能即取消对原版部件动作菜单(PAW)的内容进行分组
禁用前的部件动作菜单如图：
禁用功能后的部件动作菜单如图：
Mod 设置文件(GameData\KSPCommunityFixes\Settings.cfg)内容（节选）
Patch 文件内容：
patch 简单解释：
MM 首先在游戏数据库查找到 KSP_COMMUNITY_FIXES 这个 ConfigNode ，然后进行@操作，即编辑。
:AFTER[KSPCommunityFixes] 表示该 patch 将在 mod 中的所有包含的 patch （如果有的话）应用后才开始应用该 patch
将 PAWStockGroups 的值从原来的 true 改成 false，即禁用该功能
基础教程是不是非常简单呢？那么，你学废了吗？
