查找原版数据

制作 Mod 时常说的“代码”，通常不是一段程序，而是 DB 记录的Key、Loc 文本 Key、其他记录引用的 Key、资产路径或脚本标识。它们没有一张固定清单；更可靠的做法是从游戏里已经存在的相似内容出发，沿原版数据的连接关系找到答案。

本篇只负责查找和理解原版数据，不要求把搜索到的记录全部导入 Mod。原版单位参与的系统很多，搜索结果多不等于每一条都要复制。

先确定要找什么

搜索前先写下两个问题：

1. 想实现什么结果，例如“让单位从某座建筑招募”“给单位添加已有技能”或“换一种投射物”。
2. 游戏中哪个原版内容与目标最接近。

尽量选择两到三个对照对象，而不是只找一个模板。例如制作持盾远程步兵，可以分别查看一个同文化远程单位、一个持盾单位和一个机制相近的特殊单位。它们共同出现的数据通常是基础链路，只有某一个对象拥有的数据往往属于它的特殊设计。

先认识几种常见标识

看到的内容	示例	一般去哪里找
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 硬编码和普通文本。实际制作时经常需要两者配合。

打开全局搜索

1. 确认 RPFM 的当前游戏已经设为目标游戏。
2. 先保证目标游戏的依赖项缓存已经生成。本教程的原版 DB 示例统一选择游戏文件，打开的原版数据页签以Game-RO:开头。
3. 点击视图 → 切换全局搜索窗口，或按Ctrl+Shift+F。
4. 全局搜索默认停靠在主窗口右侧。面板过窄时可以拖动它与主表之间的分隔线。

图中四个编号分别对应：

1. 搜索词与匹配选项。
2. 搜索范围，决定检查哪些文件类型。
3. 搜索来源，决定检查哪个 Pack 或数据集。
4. 匹配结果；底部还可以对结果做第二次筛选。

这张图已经在结果底部输入/data__$，按文件路径只显示以/data__结尾的匹配，用来集中观察原版常见命名的 DB 文件。它不是上方的搜索词，也不是“只查原版”的通用开关；其他文件名的官方数据也可能因此被隐藏，继续找本地化或脚本前应清空这个筛选。

Game-RO:说明当前页面是游戏依赖项的只读视图，不单独证明每一条记录都来自 CA。若游戏目录或依赖项缓存中还包含其他 Mod，列表可能同时出现自定义表文件。核对文件来源与命名，不要把陌生 Mod 的记录当作原版模板；data__这个文件名本身也不是来源证明。

输入搜索词

默认模式是不区分大小写的“包含搜索”。例如搜索：

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 或其他获准查看的 Mod。原版 DB 教学统一使用下面的游戏文件来源。
游戏文件	当前游戏的原版 Pack	需要已经生成依赖项缓存；结果只读。
父文件	当前 Pack 声明的父 Mod	用来追踪父 Mod 提供的数据；结果只读。
Assembly Kit 数据表	AK 中的开发资料和辅助数据	仅供只读研究与交叉核对。不能从这里导入、复制或编辑表单，也不能把结果当作游戏可引用的数据。

常见选择方法：

• 查原版单位：只选游戏文件，打开结果后核对Game-RO:页签。
• 检查自己的新 Key：只选自己的 Mod Pack，避免原版结果干扰。
• 比较覆盖关系：同时选自己的 Pack、父文件和游戏文件，然后根据结果来源区分同名记录。
• 研究 AK 中的辅助说明时才额外启用Assembly Kit 数据表；制作 Mod 前仍要回到游戏文件确认正式数据，不从 AK 复制记录。

同一个 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/data__，锁定该表的原版文件。截图中这个文件有 14 个匹配项，这是本次数据中的数量，不是固定规则。双击一项后，主表会定位到对应Unit单元格；再在主表底部输入unit:wh3_main_cth_inf_jade_warriors_0并按回车，就能把同一单位的建筑关联放在一起比较。这里的主表筛选和右侧结果筛选是两个独立控件。

图中四个编号分别是：①不同的建筑及等级；②重复出现的同一个单位 Key；③全局搜索经过筛选后的匹配项；④右侧结果列表的路径筛选框。左侧记录既有常规建筑，也有其他建筑系统的关联，应逐条核对其用途，不能把“14 个匹配项”理解成“制作这个单位必须复制 14 条记录”。

结果太多时怎么缩小

按下面的顺序逐层收窄，不要一开始就写复杂正则：

1. 只保留与目标有关的数据来源。
2. 已知 Key 时只勾选数据库（DB）。
3. 把部分名称换成完整 Key。
4. 用结果底部筛选框限制表路径或列。
5. 最后才使用正则表达式合并多个搜索条件。

搜索不到时检查什么

1. 当前游戏是否选对，依赖项缓存是否可用。
2. 目标 Pack 或游戏文件是否真的勾选。
3. 数据库（DB）、文本（Loc）或纯文本（Text）是否选对。
4. 是否误开了区分大小写或写错正则。
5. 搜索的是文件名还是文件内容；文件名应先用 Pack 内容筛选。
6. 只知道中文名称时，当前加载的 Loc 是否包含对应语言文本。

不要因为第一次没有结果就猜一个近似 Key。先把搜索词缩短到稳定的前缀或后缀，找到候选后再恢复完整搜索进行确认。

四种常用查找路线

已知完整 Key，查它参与哪些系统

1. 选择原版数据来源。
2. 只启用数据库（DB），使用普通完整 Key 搜索。
3. 根据表路径给结果分类，再用底部筛选逐类查看。
4. 对关键 DB 记录继续使用转到定义或查找引用。

这条路线适合单位、建筑、效果、技能、Unit Set 和投射物等大部分 DB Key。

只知道游戏里的中文名称

1. 启用文本（Loc），搜索游戏里显示的完整名称。
2. 打开匹配的 Loc 行，读取它的 Key。兵种名称常见前缀为land_units_onscreen_name_。
3. 取出前缀后面的标识，再启用数据库（DB）搜索。
4. 如果同名文本对应多个 Key，就结合派系、单位类型和 DLC 前缀逐个核对，不要只选第一条。

建筑、效果、技能和其他内容也可以先从显示文字找到 Loc Key。不同系统的 Loc 前缀并不相同，因此前缀只能作为线索，不能当成固定公式。

下面两条原版路线可以直接照做，不必先猜英文 Key：

想找的对象	Loc 中应核对的 Key	下一步查哪里
玉勇	land_units_onscreen_name_wh3_main_cth_inf_jade_warriors_0	去land_units_tables.key查wh3_main_cth_inf_jade_warriors_0；查谁招募它时继续追到main_units_tables.unit再查建筑权限。
丹鼎师	agent_subtypes_onscreen_name_override_wh3_main_cth_alchemist	去agent_subtypes_tables.key查wh3_main_cth_alchemist；战斗单位从associated_unit_override继续向下找。

搜索普通名称时先关闭正则、清空旧路径筛选并只选 Loc；拿到 Key 后再切换 DB。游戏的官方简中local_cn.pack中是“玉勇”“丹鼎师”，繁中local_zh.pack中分别是“翠玉勇士”“煉金術士”。不要把在另一种语言中搜索不到同名文字当成没有数据。运行中的 RPFM 应以当前加载语言及实际 Loc 内容为准。

不知道表名，只知道大致概念

启用架构（Schemas），用英文标识片段搜索表名和列名。例如想查远程武器，可以搜索missile_weapon；想查招募建筑，可以搜索building或recruitment。在架构匹配项中先确定候选表和列，再回到数据库（DB）搜索实际记录。

架构搜索只能告诉你“可能有哪些表和字段”，不能证明某张表就是目标机制。仍要用原版实例、字段引用和游戏测试确认。

常见需求可以直接从下面这些入口查，不必逐张试表：

需求	先定位的表和列	继续追踪的对象
单位人数、招募费用	main_units_tables.unit	num_men、recruitment_cost；不要在陆战表里找人数。
近战攻击、防御、领导力	land_units_tables.key	melee_attack、melee_defence、morale。
基础及破甲武器杀伤	land_units_tables.primary_melee_weapon	melee_weapons_tables中的被引用记录。
射程、弹丸伤害	land_units_tables.primary_missile_weapon	missile_weapons_tables.default_projectile再到projectiles_tables。
招募建筑	building_units_allowed_tables.unit	同行的building，再到building_levels_tables。
单位自带部队技能	land_units_to_unit_abilites_junctions_tables.land_unit	同行的ability，再到unit_abilities_tables。表名中的abilites保持原拼写。
英雄、领主的技能树	character_skill_node_sets_tables.agent_subtype_key	集合key及成员表的set。

引用链中每一步都使用上一张表单元格里的真实值。主单位、陆战单位和武器 Key 即使看起来相似，也不要求同名。

怀疑 Lua 或文本写死了 Key

启用纯文本（Text）搜索完整 Key，重点查看脚本、配置和 UI 文本。若完整 Key 没有结果，再搜索稳定的前缀或后缀。脚本可能动态拼接 Key，因此全局搜索也不一定一次找到完整字符串。

使用全局替换

全局搜索顶部还提供替换输入框，可以替换选中的匹配项，也可以全部替换当前结果。

替换只会修改可写的 Pack；游戏文件、父文件和Assembly Kit 数据表属于只读来源，会被自动跳过。这不代表全部替换没有风险：只要同时勾选了多个可写 Pack，它们都可能进入替换范围。

需要重命名自己 Mod 中的 Key 时：

1. 先保存 Pack，并保留可恢复副本或确认自动保存可用。
2. 搜索来源只勾选自己的目标 Pack。
3. 使用完整旧 Key 搜索，逐组检查所有匹配。
4. 优先选择确认过的结果再替换；只有范围完全正确时才使用全部替换。
5. 重新搜索旧 Key，确认没有遗漏；再搜索新 Key，确认没有改到无关文本。
6. 运行诊断并进行游戏测试。

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，但具体建筑可以是军事建筑、发展建筑、防御建筑、地标、资源建筑、港口或其他建筑链，也可能只在某个建筑等级和特定派系生效。游牧、营地、军团式建筑、精英部队、佣兵池、召唤或脚本奖励还可能使用其他表或 Lua；这些入口应分别沿同类原版单位追踪，不能笼统当成同一种“特殊单位池”。

自行查找时，先搜索目标原版单位 Key，筛选招募相关结果，再反查Building对应的建筑等级、建筑链和 Loc 名称。不要先认定“它一定来自兵营”。

效果来源

相似加成可能来自科技、领主技能、建筑、特性、装备、Effect Bundle、事件、困境或脚本。先在游戏里确认加成从哪里获得，再搜索对应效果 Key 和目标范围；不要只因为效果文字相同就复制第一条记录。

部队技能、人物技能与其他授予方式

游戏界面中的部队技能包括主动技能和被动技能；它们与人物技能树、装备授予的技能和脚本临时触发的效果使用不同入口。RPFM 的相关表名和字段仍会使用abilities或Ability，这是数据库标识，不是要求正文把玩家看到的技能称为“能力”。制作兵种时，可以从一个确实拥有目标部队技能的原版兵种开始，先找到它与技能的连接，再跳转到技能定义。若只想复用现有技能，通常不需要复制整套定义；若要改变技能效果，则要继续追踪完整定义链。

模型和其他资产

DB Key 与实际文件路径不是一回事。找到Variant、动画表、兵牌名或投射物显示记录后，还要继续检查它们指向的 Pack 路径。RPFM 中引用有效，也不能证明模型、骨架、动画、挂点或特效在游戏里兼容。

导入前再做一次筛选

1. 明确本次要实现的结果，只记录与结果直接有关的表。
2. 对比两到三个原版对象，区分共同链路和特殊分支。
3. 检查目标记录被谁引用，确认它是否与其他单位共享。
4. 只把真正需要的记录放进自建 Pack：可以在同类型、同版本的自建表中粘贴原版整行，也可以先导入整表、重命名data__，再保留目标记录并删除无关行。需要修改共享记录时，复制为自己的 Key，再让新内容引用它。
5. 保存后运行 RPFM 诊断，处理与新记录有关的错误。
6. 最后在游戏里单独验证目标功能。

如果先导入整张原版data__，必须立即把表文件重命名为自己的名称，再删除不需要的行。把db/表名/data__原样放进 Mod 会覆盖原版同名表，而不是安全地“追加数据”。

RPFM 搜索和诊断能证明数据存在、部分引用成立；它们不能证明招募、技能、动画或战斗效果已经在游戏中正常工作。静态检查通过后，仍要用只启用当前测试 Mod 的新存档或自定义战斗完成实际验收。