查找原版数据
制作 Mod 时常说的“代码”，通常不是一段程序，而是 DB 记录的Key、Loc 文本 Key、其他记录引用的 Key、资产路径或脚本标识。它们没有一张固定清单；更可靠的做法是从游戏里已经存在的相似内容出发，沿原版数据的连接关系找到答案。
本篇只负责查找和理解原版数据，不要求把搜索到的记录全部导入 Mod。原版单位参与的系统很多，搜索结果多不等于每一条都要复制。
先确定要找什么
搜索前先写下两个问题：
- 想实现什么结果，例如“让单位从某座建筑招募”“给单位添加已有技能”或“换一种投射物”。
- 游戏中哪个原版内容与目标最接近。
尽量选择两到三个对照对象，而不是只找一个模板。例如制作持盾远程步兵，可以分别查看一个同文化远程单位、一个持盾单位和一个机制相近的特殊单位。它们共同出现的数据通常是基础链路，只有某一个对象拥有的数据往往属于它的特殊设计。
先认识几种常见标识
| 看到的内容 | 示例 | 一般去哪里找 |
|---|---|---|
| DB 记录 Key | wh3_main_cth_inf_jade_warriors_0 |
全局搜索中的数据库（DB）。 |
| 游戏显示文字 | 玉勇 |
全局搜索中的文本（Loc）。 |
| Loc Key | land_units_onscreen_name_... |
Loc 搜索，再根据后缀追到 DB。 |
| 资产路径 | ui/units/icons/...png |
先用左侧 Pack 内容筛选文件名；路径被其他文件引用时再用全局搜索。 |
| Lua 标识或硬编码文本 | 脚本中的单位 Key、事件 Key | 全局搜索中的纯文本（Text），必要时查看脚本。 |
同一个词可能同时出现在多个系统里。先判断它是显示文字、DB Key、路径还是脚本内容，再决定搜索范围。
全局搜索为什么重要
RPFM 的全局搜索可以同时检查打开的 Pack、原版游戏、父 Mod 和 Assembly Kit 数据，并跨越 DB、Loc、Lua 等纯文本及多种结构化文件。它不只是“找一行数据”，还可以用来回答：
- 一个单位 Key 出现在哪些系统；
- 一段中文文本对应哪个 Loc Key；
- 某个能力、效果或建筑被哪些记录提到；
- 一个脚本是否把 Key 直接写在 Lua 中；
- 自己的 Pack 中是否还有旧 Key 没改完；
- RPFM 架构里有哪些名称相近的表和列。
它与几个容易混淆的功能作用不同：
| 功能 | 搜索范围 | 适合解决的问题 |
|---|---|---|
| 左侧 Pack 内容筛选 | 当前树中的文件路径和文件名 | 找某个.png、.lua或 DB 表文件。 |
表格底部筛选、Ctrl+F |
当前已经打开的表 | 在一张表内找行或比较数值。 |
全局搜索、Ctrl+Shift+F |
所选来源中的所有受支持文件 | 不知道数据在哪张表，或要找一个 Key 的所有文本出现位置。 |
查找引用 |
RPFM 架构声明的 DB 关系 | 精确追踪哪些字段把当前 Key 当作外键。 |
全局搜索能找到字符串相同的内容，但不判断这些结果在逻辑上是否有关；查找引用更懂 DB 关系，却看不到许多 Lua 硬编码和普通文本。实际制作时经常需要两者配合。
打开全局搜索
- 确认 RPFM 的
当前游戏已经设为目标游戏。 - 要直接搜索原版
游戏文件，先保证依赖项缓存已经生成；也可以像本例一样只读打开原版db.pack并把它作为 Pack 来源。 - 点击
视图 → 切换全局搜索窗口，或按Ctrl+Shift+F。 - 全局搜索默认停靠在主窗口右侧。面板过窄时可以拖动它与主表之间的分隔线。
图中四个编号分别对应：
- 搜索词与匹配选项。
搜索范围，决定检查哪些文件类型。搜索来源，决定检查哪个 Pack 或数据集。- 匹配结果；底部还可以对结果做第二次筛选。
输入搜索词
默认模式是不区分大小写的“包含搜索”。例如搜索：
wh3_main_cth_inf_jade_warriors_0
会匹配所有包含这段文字的受支持字段或文本。新手应先使用普通搜索，确认能找到数据后再考虑正则表达式。
区分大小写
启用区分大小写后，大小写必须完全一致。大部分 DB Key 使用小写，但文件路径、脚本变量和普通文本不一定如此。已复制完整 Key 时通常不必开启；需要区分两个只在大小写上不同的文本时再用。
使用正则表达式
启用使用正则表达式（Regex）后，搜索词会被当作模式：
| 目标 | 正则示例 |
|---|---|
| 找所有以某前缀开头的值 | ^wh3_main_cth_ |
| 同时查找震旦步兵和骑兵前缀 | `wh3_main_cth_(inf |
| 要求完整 Key 的单词边界 | \bwh3_main_cth_inf_jade_warriors_0\b |
全局搜索没有“全字匹配”开关，需要时只能用正则边界。当前 RPFM 在正则无效时会回退到普通模式搜索，因此“仍然搜到结果”不代表正则写对了；使用替换前尤其要重新核对模式。
不熟悉正则时不要用它批量替换。普通完整 Key 搜索更直观，也更容易检查范围。
选择搜索来源
每个来源都可以单独勾选，也可以组合搜索：
| 来源 | 包含什么 | 使用条件与边界 |
|---|---|---|
| 打开的 Pack | 面板中会为每个已打开 Pack 显示一个复选框 | 查自己 Mod、只读打开的db.pack或其他已打开 Pack。 |
游戏文件 |
当前游戏的原版 Pack | 需要已经生成依赖项缓存；结果只读。 |
父文件 |
当前 Pack 声明的父 Mod | 用来追踪父 Mod 提供的数据；结果只读。 |
Assembly Kit 数据表 |
AK 独有或补充的 DB、Loc 数据 | 需要正确配置 Assembly Kit 路径；结果只读。 |
常见选择方法：
- 查原版单位：只选
游戏文件，或只选已经打开的db.pack。 - 检查自己的新 Key：只选自己的 Mod Pack，避免原版结果干扰。
- 比较覆盖关系：同时选自己的 Pack、
父文件和游戏文件，然后根据结果来源区分同名记录。 - 查 AK 中才有的辅助数据：额外启用
Assembly Kit 数据表。
同一个 Key 在多个来源出现是正常现象。先看来源，再判断它是原版定义、父 Mod 定义，还是自己 Pack 中的覆盖记录。
选择搜索范围
搜索范围决定 RPFM 解码并检查哪些文件类型。范围越宽，结果越多，搜索也可能越慢。
| 选项 | 主要用途 |
|---|---|
全部（通用） |
同时搜索日常最常用的数据库（DB）、文本（Loc）和纯文本（Text）。不知道 Key 藏在哪一类文件时先用它。 |
数据库（DB） |
查表格单元格中的 Key、引用和数值文本。已知 DB Key 时优先单独勾选。 |
文本（Loc） |
查玩家看到的名称、说明和提示文字，也能反查 Loc Key。 |
纯文本（Text） |
查 Lua、XML、JSON 和其他文本文件中的硬编码内容。 |
架构（Schemas） |
查 RPFM 架构中的表名、版本、列名和列索引，结果显示在架构匹配项页。 |
单位变体（Unit Variant） |
查单位变体文件内部的结构化字段。 |
| 其他结构化类型 | 包括战斗动画片段、图集、肖像设置、刚体模型和未知文件等；只在目标确实属于该格式时启用。 |
全部 |
搜索当前 RPFM 支持的全部范围。适合最后补查，不适合每次都作为起点。 |
DB 与 Loc 的结果精确到单元格并带有行信息；纯文本结果精确到行；图集、肖像设置等结构化文件则显示匹配字段。搜索文件名或资产路径本身时，先用左侧 Pack 内容筛选；只有路径字符串被写进其他文件内容时，全局搜索才会找到那处引用。
阅读搜索结果
结果分成两个页面：
文件匹配项：显示 DB、Loc、Text 和其他文件内容的匹配。架构匹配项：显示表名、表版本、列名和列索引的匹配。
文件匹配项会按数据来源和文件路径分组。展开文件后，每条 DB 或 Loc 结果会显示匹配内容、行和列；双击或激活结果，RPFM 会打开对应文件并定位到单元格。原版、父 Mod 和 AK 结果会以只读预览打开。
结果列表底部的筛选框不会重新搜索原始数据，它只缩小当前结果列表。可以选择按文件路径、列、行或匹配内容筛选。例如搜索一个单位 Key 得到数百条结果后，在这里输入building_units_allowed，就能先只看建筑招募表。
本例先搜索玉勇 Key，再用结果筛选锁定building_units_allowed_tables。列表中的14表示这张表里有 14 个匹配项；双击其中一项后，主表定位到对应Unit单元格。接下来仍要逐条读取Building，不能把“14 条结果”误解为“需要复制 14 条记录”。
结果太多时怎么缩小
按下面的顺序逐层收窄，不要一开始就写复杂正则：
- 只保留与目标有关的数据来源。
- 已知 Key 时只勾选
数据库（DB）。 - 把部分名称换成完整 Key。
- 用结果底部筛选框限制表路径或列。
- 最后才使用正则表达式合并多个搜索条件。
搜索不到时检查什么
- 当前游戏是否选对，依赖项缓存是否可用。
- 目标 Pack 或
游戏文件是否真的勾选。 数据库（DB）、文本（Loc）或纯文本（Text）是否选对。- 是否误开了
区分大小写或写错正则。 - 搜索的是文件名还是文件内容；文件名应先用 Pack 内容筛选。
- 只知道中文名称时，当前加载的 Loc 是否包含对应语言文本。
不要因为第一次没有结果就猜一个近似 Key。先把搜索词缩短到稳定的前缀或后缀，找到候选后再恢复完整搜索进行确认。
四种常用查找路线
已知完整 Key，查它参与哪些系统
- 选择原版数据来源。
- 只启用
数据库（DB），使用普通完整 Key 搜索。 - 根据表路径给结果分类，再用底部筛选逐类查看。
- 对关键 DB 记录继续使用
转到定义或查找引用。
这条路线适合单位、建筑、效果、能力、Unit Set 和投射物等大部分 DB Key。
只知道游戏里的中文名称
- 启用
文本（Loc），搜索游戏里显示的完整名称。 - 打开匹配的 Loc 行，读取它的 Key。兵种名称常见前缀为
land_units_onscreen_name_。 - 取出前缀后面的标识，再启用
数据库（DB）搜索。 - 如果同名文本对应多个 Key，就结合派系、单位类型和 DLC 前缀逐个核对，不要只选第一条。
建筑、效果、技能和其他内容也可以先从显示文字找到 Loc Key。不同系统的 Loc 前缀并不相同，因此前缀只能作为线索，不能当成固定公式。
不知道表名，只知道大致概念
启用架构（Schemas），用英文标识片段搜索表名和列名。例如想查远程武器，可以搜索missile_weapon；想查招募建筑，可以搜索building或recruitment。在架构匹配项中先确定候选表和列，再回到数据库（DB）搜索实际记录。
架构搜索只能告诉你“可能有哪些表和字段”，不能证明某张表就是目标机制。仍要用原版实例、字段引用和游戏测试确认。
怀疑 Lua 或文本写死了 Key
启用纯文本（Text）搜索完整 Key，重点查看脚本、配置和 UI 文本。若完整 Key 没有结果，再搜索稳定的前缀或后缀。脚本可能动态拼接 Key，因此全局搜索也不一定一次找到完整字符串。
使用全局替换
全局搜索顶部还提供替换输入框，可以替换选中的匹配项，也可以全部替换当前结果。
替换只会修改可写的 Pack；游戏文件、父文件和Assembly Kit 数据表属于只读来源，会被自动跳过。这不代表全部替换没有风险：只要同时勾选了多个可写 Pack，它们都可能进入替换范围。
需要重命名自己 Mod 中的 Key 时：
- 先保存 Pack，并保留可恢复副本或确认自动保存可用。
- 搜索来源只勾选自己的目标 Pack。
- 使用完整旧 Key 搜索，逐组检查所有匹配。
- 优先选择确认过的结果再替换；只有范围完全正确时才使用
全部替换。 - 重新搜索旧 Key，确认没有遗漏；再搜索新 Key，确认没有改到无关文本。
- 运行诊断并进行游戏测试。
DB 主键与外键之间已经存在明确关系时，也可以考虑右键主键使用级联编辑；它比不加区分地替换所有同名文本更符合表结构。Lua、Loc 和资产路径仍需另行检查。
看懂“同一个 Key 出现在哪里”
全局搜索回答的是“这段文字在哪里出现”。一个单位 Key 可能同时出现在：
- 基础单位、战斗数据和模型连接；
- 自定义战斗权限；
- 建筑招募、特殊招募或脚本；
- AI 质量、Unit Set、盟友招募；
- 驻军、叛军、任务战、升级或其他专用系统。
不要把所有匹配项都视为必需表。先按目标分类：
| 分类 | 判断方法 |
|---|---|
| 当前目标必需 | 缺少后，目标功能就无法成立。 |
| 设计需要时可选 | 只有希望单位进入该系统时才添加。 |
| 原版专用或无关 | 属于剧情、DLC 所有权、特殊模式、旧数据或其他官方用途。 |
每打开一张陌生表，先阅读列名和 RPFM 的字段说明，再观察同表中相似原版记录。不要因为表名看起来相关就直接导入。
沿引用跳到定义
表中的许多列并不保存完整内容，而是引用另一张表的 Key。例如：
land_units_tables.Primary Missile Weapon
→ missile_weapons_tables.Key
→ projectiles_tables.Key
要查看一项引用具体指向什么，可以右键该单元格，选择转到... → 转到定义。如果 RPFM 的架构已经声明这项外键关系，它会直接打开目标表并定位到对应记录。
常见用法包括：
- 从
land_units_tables追到实体、武器、护甲、坐骑或战场引擎； - 从远程武器追到投射物；
- 从
land_units_to_unit_abilites_junctions_tables中的单位能力连接追到unit_abilities_tables； - 从建筑等级追到建筑链和本地化名称。
如果转到定义不可用，可能是该字段没有架构关系、目标记录不在当前数据源，或者引用藏在脚本和文本中。此时复制完整 Key，再用全局搜索查找。
反向查找谁在引用它
“转到定义”是从引用者走向目标；想知道“哪些记录正在使用这个 Key”，就在目标表的主键单元格上右键，选择查找引用。
引用面板会列出数据来源、表路径、引用列和行索引。双击结果可以回到引用它的记录。这个方法特别适合：
- 查一个单位被哪些能力连接、主单位或战役系统使用；
- 查一个投射物被哪些远程武器使用；
- 查一个 Unit Set 被哪些效果连接；
- 判断修改一条共享记录会不会连带影响其他内容。
查找引用只能发现 RPFM 架构中已经声明的关系。Lua 脚本、文本文件、拼接出来的 Key 和部分资产路径可能不会出现在引用面板里，仍要用全局搜索补查。
不同目标可能有多条路径
教程里的案例只演示一种可复现路径，不是游戏系统的唯一做法。
招募来源
普通单位常见于building_units_allowed_tables，但具体建筑可以是军事建筑、发展建筑、防御建筑、地标、资源建筑、港口或其他建筑链，也可能只在某个建筑等级和特定派系生效。游牧、营地、军团式建筑、特殊单位池、召唤、Regiment of Renown 或脚本奖励还可能使用其他表或 Lua。
自行查找时，先搜索目标原版单位 Key，筛选招募相关结果，再反查Building对应的建筑等级、建筑链和 Loc 名称。不要先认定“它一定来自兵营”。
效果来源
相似加成可能来自科技、领主技能、建筑、特性、装备、Effect Bundle、事件、困境或脚本。先在游戏里确认加成从哪里获得，再搜索对应效果 Key 和目标范围；不要只因为效果文字相同就复制第一条记录。
技能和能力
兵种自带能力、角色技能、装备能力和脚本触发能力的入口不同。制作兵种时，可以从一个确实拥有目标能力的原版兵种开始，先找到它与能力的连接，再跳转到能力定义。若只想复用现有能力，通常不需要复制整套能力定义；若要改变能力效果，则要继续追踪完整定义链。
模型和其他资产
DB Key 与实际文件路径不是一回事。找到Variant、动画表、兵牌名或投射物显示记录后，还要继续检查它们指向的 Pack 路径。RPFM 中引用有效，也不能证明模型、骨架、动画、挂点或特效在游戏里兼容。
导入前再做一次筛选
- 明确本次要实现的结果，只记录与结果直接有关的表。
- 对比两到三个原版对象，区分共同链路和特殊分支。
- 检查目标记录被谁引用，确认它是否与其他单位共享。
- 优先只导入需要的行；需要修改共享记录时，复制为自己的 Key，再让新内容引用它。
- 保存后运行 RPFM 诊断，处理与新记录有关的错误。
- 最后在游戏里单独验证目标功能。
如果先导入整张原版data__，必须立即把表文件重命名为自己的名称，再删除不需要的行。把db/表名/data__原样放进 Mod 会覆盖原版同名表，而不是安全地“追加数据”。
RPFM 搜索和诊断能证明数据存在、部分引用成立；它们不能证明招募、技能、动画或战斗效果已经在游戏中正常工作。静态检查通过后，仍要用只启用当前测试 Mod 的新存档或自定义战斗完成实际验收。