兵种上限详解

“最多能有几队”在游戏里可能由多套系统决定。main_units_tables的战役上限、兵种集合的动态容量、招募池当前数量、每支军队限制和多人模式配额看起来都像“上限”，但它们限制的对象和计算时机不同。

开始修改前先写清楚目标：限制全派系现存数量、限制每支军队数量、限制某个招募池库存，还是限制多人模式选兵。不同目标不能靠同一列解决。

五类容易混淆的限制

限制	控制对象	常见入口
战役基础兵种上限	一个主单位在战役中的基础容量	main_units_tables.campaign_cap
战役动态容量	由建筑、科技、技能或机制增减的一组兵种容量	unit_sets_tables与 Effect
每军队限制	每支军队中某类来源或部队的数量	招募来源、机制或脚本数据
招募池库存	当前能从池中招募几队、如何补充	mercenary_*系列表
多人模式上限	自定义战斗、快速战斗等选兵限制	main_units多人字段和battle_unit_caps_for_team_sizes_tables

如果界面显示“0/3”，也不能只凭外观判断是哪套系统。应从一个表现相同的原版兵种反查其main_units、兵种集合、Effect 和招募池引用。

主要表单

表单	作用
main_units_tables	保存单个主单位的基础战役与多人上限字段
unit_sets_tables	定义一组可被统一匹配的兵种
unit_set_to_unit_junctions_tables	把具体单位、种类、类别或兵种级别加入或排除出集合
unit_set_to_mp_unit_caps_tables	为兵种集合设置多人模式上限
effect_bonus_value_ids_unit_sets_tables	将 Effect 的 Bonus Value 与兵种集合连接
effect_bonus_value_unit_record_junctions_tables	将 Effect 的 Bonus Value 指向具体单位记录
battle_unit_caps_for_team_sizes_tables	定义不同队伍规模下的战斗配额规则

main_units_tables中的上限

与上限直接相关的常见字段包括：

字段	作用
campaign_cap	战役中此主单位的基础容量设置
multiplayer_cap	多人模式使用的单位数量限制之一
multiplayer_qb_cap	快速战斗等多人环境使用的限制之一

campaign_cap怎么理解

当前原版数据中，常见普通部队大量使用-1，通常表示不由此字段设置有限的基础战役上限；部分依靠建筑或机制增加容量的兵种使用0作为起点；正数记录则可能直接提供基础容量。

-1、0和正数的表现应以同类原版兵种及游戏实测为准。不要把“0”简单理解成永远无法招募，也不要把-1复制成任何机制下都绝对无限；其他 Effect、招募池和脚本仍可继续限制它。

如果目标只是给一个新兵种设置固定的基础上限，优先找同机制的原版模板，比较它的campaign_cap以及是否同时被兵种集合和 Effect 引用。

兵种集合

unit_sets_tables不是部队名单本身，而是一个可复用的筛选集合。建筑、科技、角色技能和派系机制可以通过 Effect 对整个集合增加容量或施加其他加成。

图中橙色框从左到右标出集合 Key、经验等级筛选和特殊类别。当前截图来自 RPFM 5.0.6 中打开的原版数据。

unit_sets_tables

字段	作用	使用条件
key	兵种集合的唯一 Key	所有成员与 Effect 连接都引用它
use_unit_exp_level_range	是否启用经验等级范围筛选	只有需要按经验等级匹配时启用
min_unit_exp_level_inclusive	最低经验等级，包含该值	与范围开关一起使用
max_unit_exp_level_inclusive	最高经验等级，包含该值	与范围开关一起使用
special_category	特殊分类	应复制同机制模板，不要凭名称猜值

普通的“某几种兵共享容量”通常只需要集合 Key 和成员连接，不必启用经验等级范围。

unit_set_to_unit_junctions_tables

这张表决定集合匹配哪些兵种。

字段	作用
unit_set	目标兵种集合
unit_record	指定一个具体main_units记录
unit_caste	按兵种阶层或 caste 匹配
unit_category	按兵种类别匹配
unit_class	按兵种级别或 class 匹配
exclude	将符合本行条件的对象排除出集合

一行不一定必须填写所有筛选字段。常见做法有：

• 只填unit_record：精确加入某一个兵种。
• 填类别或 class：批量匹配一类兵种。
• 先用宽条件加入，再用exclude排除例外。
• 建立多个小集合，让不同 Effect 分别控制。

复制模板时必须弄清它是在“精确列举”还是“按类别筛选”。否则新增兵种可能意外进入其他原版机制，或自己创建的集合匹配到过多部队。

用 Effect 增加战役容量

常见动态容量链如下：

建筑 / 科技 / 角色技能 / 特性 / 物品
    ↓ 授予 Effect
Effect + Bonus Value
    ↓ 指向 unit_set
兵种集合
    ↓ 匹配一个或多个 main_units

相关表单

表单	作用
campaign_bonus_value_ids_unit_sets_tables	定义或登记面向兵种集合的 Bonus Value Key
effect_bonus_value_ids_unit_sets_tables	把 Effect、Bonus Value 和兵种集合连接起来
effect_bonus_value_basic_junction_tables	声明 Effect 支持的基础 Bonus Value
各类*_effects_junctions_tables	由建筑、科技、技能等实际授予 Effect

Effect 自身的value通常表示增加或减少多少容量，但最终正负方向、Scope 和显示方式必须参照同类原版 Effect 验证。

为什么需要兵种集合

假设三个兵种共享一种机制容量。若 Effect 直接逐个指向三个单位，后续增加第四个兵种时容易漏改多个入口；把四个兵种放入同一集合后，所有授予该 Effect 的建筑和技能都能按统一规则生效。

但集合也会扩大影响范围。修改一个被原版广泛引用的集合，可能改变许多建筑、科技和派系。新机制通常应复制为自己的集合 Key。

直接指向单位的 Effect

effect_bonus_value_unit_record_junctions_tables可将 Effect 的 Bonus Value 与某个具体单位记录连接：

字段	作用
effect	Effect Key
bonus_value_id	Bonus Value Key
unit_record_key	目标main_units Key

它适合只针对一个明确单位的效果。是否用于容量、成本或其他单位数值，取决于 Bonus Value 本身；不能看到“unit record”就默认它一定控制兵种上限。

选择具体单位还是兵种集合时，可按以下原则：

• 只影响一个固定兵种：优先检查具体单位连接。
• 多个兵种共享机制：优先检查兵种集合。
• 需要按类别自动包含未来兵种：使用集合筛选，但要严格控制范围。
• 原版机制已有稳定模板：保持它原本的引用方式。

多人模式兵种上限

战役容量不会自动成为多人模式上限。多人模式还会读取主单位上的多人字段，以及兵种集合的多人配额。

unit_set_to_mp_unit_caps_tables

字段	作用
unit_set	参与多人限制的兵种集合
localised_name	界面显示名称
cap	此集合的上限
subculture	限定到某个亚文化

这类上限可用于“某类强力部队合计只能选择若干队”，而不是给每个单位单独设置相同数字。

battle_unit_caps_for_team_sizes_tables

该表描述不同队伍规模下的战斗配额框架：

字段	作用
team_size	队伍规模
starting_unit_cap	初始单位配额
max_unit_cap	最大单位配额
reinforcement_pool_cap	增援池配额
addition_to_max_for_first_player	首位玩家的额外最大值
domination_budget_multiplier	据点争夺模式预算倍率
survival_budget_multiplier	生存战预算倍率

这张表影响的是战斗规则框架，不是某个战役派系的兵种容量。普通单兵种 Mod 通常不需要改它。

招募池数量不是兵种上限

mercenary_unit_groups_tables中的max_count、max_replenish_per_turn和chance_to_replenish控制招募池库存。玩家可以因为池中暂时为零而无法招募，但这不代表派系现存部队已经达到兵种上限。

判断方法：

• 解散现有部队后仍要等待池补充：这是招募池库存。
• 建筑或科技提高“可招募数量”并改变分母：可能是动态兵种容量。
• 每支军队单独限制若干队：可能是来源或机制的每军队限制。
• 只在多人选兵界面出现：是多人配额。

创建“建筑提高兵种上限”的数据链

下面是一种常见路径，适用于建筑、科技或技能通过 Effect 增加一组兵种的战役容量。它不是所有派系机制的唯一实现。

1. 找到一个游戏内表现相同的原版兵种。
2. 搜索其main_units Key，确认基础campaign_cap。
3. 在unit_set_to_unit_junctions_tables查找它属于哪些集合。
4. 从目标集合反查effect_bonus_value_ids_unit_sets_tables。
5. 记录有效模板使用的 Effect、Bonus Value 和授予入口。
6. 复制或新建自己的unit_sets记录。
7. 在成员连接表中精确加入目标兵种；需要共享容量时加入多个成员。
8. 复制同类 Effect 并改为唯一 Key，保留正确的 Bonus Value 关系。
9. 将 Effect 到集合的连接改为自己的集合。
10. 在建筑、科技、技能或其他入口中授予该 Effect，并设置数值与 Scope。
11. 检查基础campaign_cap与动态增加值是否能形成预期的初始容量。
12. 进入游戏测试获得入口前后、多个入口叠加和失去入口后的容量。

如何自行查找数据

从受限兵种开始

1. 在main_units_tables查看四个上限和招募相关字段。
2. 全局搜索该兵种 Key。
3. 查看它是否出现在兵种集合、佣兵组、招募来源覆盖和多人权限表。
4. 从集合 Key 反查所有 Effect 连接。
5. 从 Effect Key 反查建筑、科技、技能、特性和物品的授予入口。

从界面文本开始

如果已知游戏中显示的“兵种容量 +1”等文本：

1. 在本地化文本中搜索完整或核心词语。
2. 取得命中的 Effect 或 UI 文本 Key。
3. 在全局搜索中追踪该 Key。
4. 确认 Effect 使用具体单位还是兵种集合。
5. 用实际拥有该加成的建筑或技能交叉验证。

从一个建筑或科技开始

先查它授予的 Effect，再从 Effect 的 Bonus Value 连接反查兵种集合。不要只根据 Effect 的英文 Key 猜它限制哪个兵种。

常见错误

• 设置campaign_cap后仍能超过上限：其他 Effect、脚本或机制正在增加容量。
• 把0当成彻底禁用：某些兵种以零为基础，再由建筑或机制提供动态容量。
• 建筑效果没有作用：Effect 没连接正确 Bonus Value 或兵种集合，或 Scope 不正确。
• 多个无关兵种一起获得容量：集合使用了过宽的类别筛选。
• 新兵种没有继承同类容量：原集合精确列举成员，新兵种未加入。
• 修改了原版集合导致大量连锁变化：该集合被其他 Effect 广泛复用。
• 招募按钮灰色就认定达到上限：也可能是招募池无库存、资金不足或其他招募条件未满足。
• 战役正常但多人模式异常：战役容量与多人上限是独立字段和表单。

游戏内验收

• 新战役初始容量与campaign_cap和机制设计一致。
• 获得建筑、科技或技能后，容量按预期增加或减少。
• 多个来源叠加时，数值与界面说明一致。
• 失去建筑、重置技能或移除物品后的行为符合设计。
• 达到上限后招募、合并、俘获、复活和脚本生成的处理合理。
• 招募池库存和兵种总容量分别正确。
• 多人模式上限没有被战役设置意外影响。
• 保存并读取后，容量和现存部队状态保持正确。

RPFM 诊断无法计算运行时 Effect 叠加，也不能证明不同获取方式是否绕过容量检查。至少要在游戏中测试“低于上限、刚好达到、尝试超过、增加容量、减少容量和读取存档”六种状态。