兵种升级详解

兵种升级用于让一支已经存在的部队沿预先定义的路线变成另一支部队。它不是普通招募，也不是简单把旧兵种 Key 全局替换为新兵种 Key。原版的战帮升级等机制会使用这一数据链，但某个派系能否打开升级界面、资源如何支付以及 AI 是否会使用，还可能依赖派系机制和脚本。

本文介绍当前 RPFM 中可编辑的兵种升级数据库。照搬几张表并不能自动给任意派系创建一套完整的升级机制；应先选一个游戏内行为相同的原版模板，确认目标派系已经接入相应系统。

主要表单

表单	作用
unit_upgrade_groups_tables	定义兵种升级组
unit_to_unit_group_junctions_tables	把具体主单位加入升级组
unit_upgrade_to_unit_groups_tables	定义“基础组升级到目标组”的升级路线
unit_upgrade_to_building_level_requirements_tables	给升级路线添加建筑等级要求
unit_upgrade_to_tech_requirements_tables	给升级路线添加科技要求
unit_upgrade_group_ui_categories_tables	定义升级界面的分类
unit_upgrade_group_ui_infos_tables	设置升级组在界面中的位置和分类
unit_upgrade_group_ui_links_tables	绘制升级组之间的界面连接线
effect_bonus_value_unit_upgrade_to_unit_group_junctions_tables	让 Effect 影响指定升级路线

完整数据链

main_units
    ↓ unit_to_unit_group_junctions
基础 unit_upgrade_group
    ↓ unit_upgrade_to_unit_groups
目标 unit_upgrade_group
    ↓ unit_to_unit_group_junctions
目标 main_units

路线还可以继续附加：

建筑要求 + 科技要求 + 资源成本 + 最低等级
                           ↓
升级界面分类、位置和连接线
                           ↓
派系机制 / 脚本 / Effect 接入

图中橙色框标出兵种升级组的 Key 列。截图中的表从依赖项 → 游戏文件导入临时 Mod Pack 后打开；原版数据来自游戏文件，Assembly Kit 文件只用于只读查证。

unit_upgrade_groups_tables

字段	作用
unit_group	兵种升级组的唯一 Key

升级组是路线节点，不等于一个具体兵种。一个组可以包含一个或多个主单位，升级路线连接的也是“组到组”，不是直接“单位到单位”。

为什么要经过升级组

升级组可以把多个等价部队归入同一节点。例如同一层级的不同兵牌变体、派系变体或并列单位可以共享一条升级出口。是否应该这样做，要看原版模板和设计目标；单一兵种升级同样可以让每个组只包含一个单位。

unit_to_unit_group_junctions_tables

这张表是最容易漏掉的一环。它把具体主单位放进升级组：

字段	作用
unit	main_units_tables中的主单位 Key
unit_group	unit_upgrade_groups_tables中的升级组 Key

如果只定义了升级组和路线，却没有把单位连接进组，游戏无法知道现有部队属于哪个起点，也无法知道目标组应该产生哪种部队。

一个单位是否应加入多个升级组必须参照原版机制。随意重复连接可能产生多条重叠升级路线或不明确的界面节点。

unit_upgrade_to_unit_groups_tables

这张表定义实际升级路线。

字段	作用	注意事项
upgrade_key	当前升级路线的唯一 Key	建筑、科技和 Effect 要求会引用它
base_unit_group	升级前的单位组	组内单位获得这条升级出口
target_unit_group	升级后的单位组	组内单位是可能的升级结果
resource_cost	可为空的字符串 Key，引用resource_costs_tables.id	这里不填花费数字；金额在成本记录及其资源连接中设置。
required_rank	执行升级所需的最低部队等级	游戏界面是否显示需实测
subtracted_rank	升级后从原等级中扣除多少	会影响目标部队保留的等级，必须实际验证

图中只筛选了两条原版升级路线。编号①是upgrade_key，②是base_unit_group，③是target_unit_group，④依次是resource_cost、required_rank和subtracted_rank。基础组与目标组必须已经各自连接有效的main_units记录。

基础组与目标组

• base_unit_group回答“哪些现有部队能看到这条升级”。
• target_unit_group回答“升级完成后变成哪一组部队”。
• 两组都必须已定义，并通过成员连接表包含有效main_units记录。

若目标组包含多个单位，具体如何选择结果取决于原版机制和其他数据。普通一对一升级不要无理由把多个目标塞进同一组。

required_rank

这是部队等级要求，不是人物等级，也不是建筑等级。把数值设为零或复制某个模板前，要先确认原版路线在游戏里是否允许新兵立即升级。

subtracted_rank

升级后等级是否完全保留、下降若干级或被重新计算，会显著影响玩家成本。不要只看升级按钮能否点击；升级前后记录部队等级和经验值，才能判断设置是否正确。

resource_cost

资源可能是派系专属货币、机制资源或由其他数据库定义的交易。若目标派系没有相同资源系统，复制其他机制的成本 Key 可能导致界面缺少文本、无法支付或升级永远不可用。

先全局搜索原版路线的upgrade_key及其资源引用，确认资源的定义、获得方式和 UI 已经存在。只需要普通升级且模板允许时，也应沿用同一机制中已验证的无资源写法，而不是凭空创造值。

升级成本的实际填写位置

原版成本wh3_dlc20_chs_upgrade_cost_t3在resource_costs_tables中使用treasury_cost=-500，expenditure_type=RECRUITMENT、income_type=CANCELLED_RECRUITMENT，常规收支分类分别为ARMY_UPKEEP和BACKGROUND_INCOME。这是扣减 500 的成本方向，不能为“费用应该是正数”改成500。

该成本没有resource_cost_pooled_resource_junctions_tables的附加资源行。只改自己的金币花费时，可复制为yourmod_upgrade_cost，例如treasury_cost=-300，然后把升级路线的resource_cost填为yourmod_upgrade_cost。不要直接在路线中填写300、-300或0；没有成本的路线应采用同系统允许的空引用配置，并实测按钮与支付行为。

建筑和科技要求

unit_upgrade_to_building_level_requirements_tables

字段	作用
unit_upgrade	目标upgrade_key
building_level	必须满足的building_levels Key

连接的是具体建筑等级。目标派系必须能在当前战役中拥有该建筑；若复制了其他文化专属建筑，升级条件可能永远无法满足。

unit_upgrade_to_tech_requirements_tables

字段	作用
unit_upgrade	目标upgrade_key
technology	必须研究的科技 Key

科技必须存在于目标派系实际使用的科技树中。只创建要求连接，不会把科技自动添加到该派系的科技树。

多个要求如何组合

同一路线出现多条建筑或科技要求时，究竟是同时满足还是按机制选择，不能只靠表名猜测。应找原版中存在多条要求的路线，比较游戏表现后再设计。

作为只读资料，当前 Assembly Kit 导出的technology_unit_upgrades_tables为空；不要从Assembly Kit 文件导入或引用它。制作当前版本的升级路线时，应以依赖项 → 游戏文件中实际有数据的unit_upgrade_to_tech_requirements_tables等表为依据。

升级界面

数据路线存在不代表界面会自动排成清晰的树。升级系统还有专用 UI 数据。

unit_upgrade_group_ui_categories_tables

字段	作用
category	升级界面分类 Key

分类用于组织不同路线。显示文本和图标是否来自其他表或本地化，应从目标模板 Key 全局搜索确认。

当前分类定义完整只有五项：KHORNE、NURGLE、SLAANESH、TZEENTCH、UNDIVIDED，均为大写。本例属于KHORNE。分类决定现有升级界面的归组，不能靠新造CATHAY就让震旦获得升级界面。

unit_upgrade_group_ui_infos_tables

字段	作用
unit_upgrade_group	要显示的升级组
x	节点横向位置
y	节点纵向位置
category	所属 UI 分类

坐标只控制界面布局，不决定实际升级条件。路线数据正确但节点重叠时，才应调整这里；不要用移动坐标解决数据连接错误。

unit_upgrade_group_ui_links_tables

字段	作用
parent_key	界面连接线的父节点
child_key	界面连接线的子节点
parent_link_position	连接线从父节点哪个方向出发
child_link_position	连接线从子节点哪个方向进入
parent_link_position_offset	父端位置偏移
child_link_position_offset	子端位置偏移
mid_link_offset	连接线中段偏移

UI 连接线只负责视觉关系。缺少它可能让路线难以阅读，但添加一条线不会创建真正的升级路线；真正的数据关系仍在unit_upgrade_to_unit_groups_tables。

用 Effect 影响升级

某些科技、建筑、技能或机制会改变特定升级路线。常见连接包括：

• campaign_bonus_value_ids_unit_upgrade_to_unit_groups_tables：登记面向升级路线的 Bonus Value。
• effect_bonus_value_unit_upgrade_to_unit_group_junctions_tables：把 Effect、Bonus Value 和upgrade_key连接起来。

数据链如下：

建筑 / 科技 / 技能 / 机制
    ↓ Effect
Effect + Bonus Value
    ↓ upgrade_key
指定兵种升级路线

Bonus Value 可能影响成本、等级要求或其他机制参数，具体含义必须从同一个有效原版 Effect 反查，不能只根据 Key 名称直译。

派系接入边界

建立组、路线和 UI 数据后，目标派系仍可能看不到升级入口，原因包括：

• 派系没有启用对应兵种升级机制。
• 当前人物、军队或兵种不被机制识别。
• 目标部队没有正确加入基础升级组。
• UI 分类或派系界面没有接入。
• 所需资源、建筑或科技对该派系不可用。
• 原版机制通过脚本初始化可用路线。

最稳妥的适用场景，是在已经拥有该机制的派系中增加或修改一条路线。把整套机制移植给完全不使用它的派系，属于更大的战役机制制作任务，不能只靠本篇列出的表完成。

一条原版路线的完整定位表

使用wh3_dlc20_chs_marauder_inf_kho_to_warriors作为升级机制模板，其实际连接如下。兵种名称已对照官方三种 Loc。

项目	当前原版填写内容
基础组	wh3_dlc20_chs_marauder_inf_kho。成员是wh3_dlc20_chs_inf_chaos_marauders_mkho（恐虐掠夺者）和wh3_dlc20_chs_inf_chaos_marauders_mkho_dualweapons（恐虐掠夺者（双持武器））。
目标组	wh3_dlc20_chs_warriors_kho。成员是wh3_main_kho_inf_chaos_warriors_0、_1、_2，分别为恐虐混沌勇士、长戟版和双持武器版。这里后两项是前一完整 Key 仅替换末尾数字。
路线	upgrade_key=wh3_dlc20_chs_marauder_inf_kho_to_warriors，基础组与目标组填上述 Key。
成本与等级	resource_cost=wh3_dlc20_chs_upgrade_cost_t3、required_rank=5、subtracted_rank=5。
额外要求	这条路线在建筑要求表和科技要求表都没有连接，不需凭空添加条件。
基础组 UI	x=173、y=315、category=KHORNE。
目标组 UI	x=150、y=210、category=KHORNE。
UI 连线	parent_key=基础组、child_key=目标组、parent_link_position=1、child_link_position=3，三个偏移均为0。

这个原版目标组有三个成员，不能称为严格一对一升级。制作一对一版本时，为自己的起点、终点各建一个组，每组只加入一个确定的主单位，再新建独立路线；不要删改原版组来使其只剩一个成员，否则其他引用原组的路线也会改变。

原基础组还连接了wh3_dlc20_chs_marauder_inf_kho_to_forsaken与wh3_dlc20_chs_marauder_inf_kho_to_self两条路线。只需要晋升为目标战士时，不复制这两个出口；需要多分支时分别保留不同的路线 Key、目标和成本。复制 UI 坐标只适合研究原位置，新组必须先查看目标分类现有节点，再选空位。

创建一条一对一升级路线

以下步骤适用于目标派系已经能使用兵种升级界面，并且要让兵种 A 升级为兵种 B。

1. 确认 A 和 B 的main_units记录都能正常使用。
2. 找一条同派系、相似等级和相似成本的原版升级路线作模板。
3. 记录模板的基础组、目标组、成员连接、要求、UI 分类和 Effect 引用。
4. 分别新建 A 与 B 的升级组，并使用唯一 Key。
5. 在unit_to_unit_group_junctions_tables把 A 加入基础组，把 B 加入目标组。
6. 新建unit_upgrade_to_unit_groups记录，填写唯一upgrade_key和两个组。
7. 按设计设置required_rank、subtracted_rank和resource_cost。
8. 需要建筑或科技条件时，添加对应要求连接；不需要时不要照抄模板的专属条件。
9. 在 UI 信息表中给两个组设置分类和不重叠的位置。
10. 需要连接线时，复制相同方向的 UI 连接模板并替换节点 Key。
11. 检查是否有 Effect 或脚本按upgrade_key控制该路线。
12. 运行 RPFM 诊断，并在游戏中用符合与不符合条件的部队分别测试。

分支和多级升级

一条基础路线分成两个目标

为同一个基础组建立两条不同upgrade_key，分别连接到不同目标组。两条路线可以拥有不同等级、资源、建筑或科技要求。

多级升级

让第一级目标组同时成为下一条路线的基础组：

组 A → 组 B → 组 C

每一段都需要独立upgrade_key和独立要求。UI 位置与连接线也要逐段配置。

多个单位共享一条出口

可以把多个单位加入同一基础组，但这会让它们共享该组的升级出口。只有当这些单位在机制上确实等价时才这样做。

如何自行查找数据

从能升级的原版部队开始

1. 找到其main_units Key。
2. 在unit_to_unit_group_junctions_tables搜索该 Key，取得所属升级组。
3. 在unit_upgrade_to_unit_groups_tables筛选base_unit_group和target_unit_group。
4. 记录全部upgrade_key、成本和等级字段。
5. 搜索upgrade_key，找到建筑、科技和 Effect 要求。
6. 搜索升级组 Key，找到 UI 分类、坐标和连接线。

从游戏界面的一条路线开始

先在本地化文本中查找升级前后兵种名称，再取得两个main_units Key。用两个方向交叉搜索，可以避免只找到一个同名或不可玩的记录。

从科技或建筑开始

搜索科技 Key 或建筑等级 Key，查看它是否出现在升级要求表；再由upgrade_key反查完整基础组和目标组。这样能分清“解锁升级路线”和“普通招募解锁”。

常见错误

• 路线完全不显示：单位没有加入基础组，或派系没有接入升级机制。
• 升级按钮存在但没有目标：目标组为空，或目标main_units引用错误。
• 要求永远不满足：复制了目标派系无法拥有的建筑、科技或资源。
• 等级变化异常：required_rank和subtracted_rank含义混淆。
• 界面节点重叠：UI 坐标照抄，但新分类中已有节点占位。
• 只有连线没有功能：UI 连接线不是实际升级路线。
• 功能存在但界面没有连线：路线表正确，但缺少 UI Link 或坐标不合理。
• 改一条路线影响多个兵种：多个单位共享同一个升级组。
• 把升级当作招募替换：兵种升级只处理现有部队，不会自动改变建筑招募列表。

游戏内验收

• 符合条件的基础部队能看到正确目标，其他部队不会误获。
• 等级、建筑、科技和资源要求分别能正确阻止或允许升级。
• 支付成本后资源扣除正确。
• 升级前后的部队等级、经验、人数和状态符合设计。
• 分支、多级路线和 UI 连接线清晰且可点击。
• 升级后的部队仍能补员、获得技能和参与其他派系机制。
• AI 不会因无效路线卡住或反复选择。
• 保存并读取后，已升级部队和可用路线保持正常。

RPFM 诊断不能证明派系已启用升级机制，也无法模拟资源支付和升级后的部队状态。必须在游戏中同时测试可用路线、未满足要求、分支路线和读取存档。