驻军详解
游戏里的聚居地驻军通常不是“建筑直接连接某个兵种”，而是“建筑等级连接驻军单位组，单位组再连接多个部队”。这层单位组让多个建筑可以复用同一套驻军，也让游戏按优先级合并、替换或截取驻军条目。
驻军、建筑招募和驻扎在城内的军队是三件事。
building_units_allowed_tables控制建筑招募，不控制建筑自带驻军；玩家军队进入聚居地也不会改写驻军数据库。
主要表单
| 表单 | 作用 |
|---|---|
building_level_armed_citizenry_junctions_tables |
把建筑等级连接到驻军单位组 |
armed_citizenry_unit_groups_tables |
定义驻军单位组 Key |
armed_citizenry_units_to_unit_groups_junctions_tables |
把具体部队加入驻军单位组，并设置优先级 |
building_levels_tables |
定义提供驻军的具体建筑等级 |
main_units_tables |
提供驻军使用的主单位记录 |
faction_rebellion_units_junctions_tables |
控制派系叛军可使用的部队，不是普通城镇驻军 |
建筑驻军的数据链
building_levels
↓ building_level
building_level_armed_citizenry_junctions
↓ unit_group
armed_citizenry_unit_groups
↓ unit_group
armed_citizenry_units_to_unit_groups_junctions
↓ unit
main_units
图中橙色框从左到右标出连接记录、建筑等级和驻军单位组。当前截图来自 RPFM 5.0.6 中打开的原版数据。
building_level_armed_citizenry_junctions_tables
这张表决定某个具体建筑等级提供哪一个驻军单位组。
| 字段 | 作用 | 注意事项 |
|---|---|---|
id |
连接记录的唯一编号或 Key | 复制原版行后必须改成唯一值 |
building_level |
提供驻军的建筑等级 Key | 指向building_levels_tables，不是建筑链 Key |
unit_group |
被授予的驻军单位组 | 指向armed_citizenry_unit_groups_tables |
一个聚居地可能同时拥有多个提供驻军的建筑，所以最终驻军是多条建筑连接共同作用的结果。主城建筑、防御建筑、地标和其他派系建筑都可能贡献单位组，不要只检查城墙建筑。
为什么必须使用建筑等级
驻军会随建筑升级而变化，因此连接的是具体等级，而不是整条建筑链。例如同一条主城链的一级、三级和五级可以分别连接不同单位组。
如果只给高等级建筑添加连接，低等级阶段不会自动继承，除非原版链条的其他数据或运行时逻辑确实这样处理。最稳妥的做法是逐级查看原版同类建筑的连接方式。
armed_citizenry_unit_groups_tables
这张表主要定义驻军单位组的身份：
| 字段 | 作用 |
|---|---|
unit_group |
驻军单位组的唯一 Key |
单位组本身通常没有名称、说明或部队列表。实际包含哪些部队，要到armed_citizenry_units_to_unit_groups_junctions_tables查看。
何时新建单位组
以下情况适合新建：
- 新建筑需要一套独立驻军，不应影响所有引用原组的建筑。
- 原版组的部队构成与目标差异很大。
- 需要清晰区分不同等级、派系或机制的驻军。
如果直接修改原版组，所有引用它的建筑都可能同时改变。教程示例应优先复制为新 Key，再修改自己的连接。
armed_citizenry_units_to_unit_groups_junctions_tables
这张表组成实际驻军名单。
| 字段 | 作用 | 注意事项 |
|---|---|---|
id |
当前成员连接的唯一编号或 Key | 每一行必须唯一 |
unit_group |
所属驻军单位组 | 必须与单位组定义和建筑连接一致 |
unit |
驻军使用的main_units Key |
不能填land_units Key |
priority |
此单位在驻军合并或容量处理中的优先级 | 数值含义应对照同一套原版组，不要凭感觉统一填写 |
一行只连接一个部队。一个单位组需要几种部队，就建立几条成员记录。
priority不是阵型顺序
priority用于驻军系统在合并和处理条目时判断优先关系，不等于战斗部署界面的固定站位，也不保证列表会按你填写的顺序显示。
不同建筑同时提供驻军时，最终可用部队还会受到驻军规模、合并规则和游戏运行时逻辑影响。修改优先级后，必须在实际聚居地中检查最终名单，不能只看表格推断。
主单位记录的影响
驻军成员引用main_units_tables，因此它会继承对应主单位的：
- 显示名称和兵牌。
land_units战斗属性。- 人数、成本类别及其他主单位设置。
- 模型、动画、武器和远程武器数据。
- 可用内容包和部分权限限制。
这不意味着驻军必须同时拥有常规招募入口。一个兵种可以只出现在驻军中，也可以既能招募又能作为驻军。两条数据链需要分别配置。
建筑、派系和文化范围
驻军连接只回答“这个建筑等级提供哪个单位组”。哪些派系能得到这个建筑，还要继续检查：
building_chains_tables：建筑链定义。building_levels_tables：具体等级。building_culture_variants_tables：文化、亚文化或派系的显示变体。building_chain_availabilities_tables：建筑链的派系和战役可用性。settlement_type_to_building_chains_junctions_tables：聚居地类型是否允许该建筑链。slot_template_permitted_building_chains_tables：特定槽位是否允许该建筑链。
如果多个派系共享建筑等级，它们也会共享该等级连接的驻军组。想要派系专属驻军时，往往需要派系专属建筑等级或其他已存在的限定路径，而不是在驻军成员表中期待一个不存在的派系字段。
主城驻军与附加驻军
最终驻军可能由多部分叠加：
主城建筑驻军
+ 防御建筑驻军
+ 地标或特殊建筑驻军
+ 战役机制临时增援
= 玩家实际看到的聚居地驻军
制作时要先决定自己的目标：
- 替换主城基础驻军：修改或复制主城等级对应的单位组。
- 让某个建筑额外提供部队：为该建筑等级连接新的附加单位组。
- 让升级后的建筑换一套驻军：分别处理每个建筑等级的连接。
- 临时或条件性增援：优先寻找相同原版机制的 Effect、脚本或战役系统，静态建筑连接未必合适。
示例里的防御建筑只是其中一种路径，不能推导出所有驻军都来自城墙。
城墙、攻城战地图与驻军不是同一系统
给建筑增加驻军部队，不会自动：
- 让聚居地获得城墙。
- 改变聚居地使用的战斗地图。
- 设置攻城器械、城门或胜利点。
- 改变守军部署区域。
- 让野外建筑变成可围攻聚居地。
这些结果涉及聚居地、战斗地图、槽位、建筑 Effect 或战役逻辑。驻军表只负责单位构成。
叛军部队
faction_rebellion_units_junctions_tables把派系与可用于叛乱的部队连接起来：
| 字段 | 作用 |
|---|---|
faction_key |
叛军所属或参照的派系 |
unit_key |
可用于叛军的主单位 |
叛军不是普通驻军。把部队加入此表不会让城市自带该部队，也不会让正常派系获得招募权限。制作叛乱相关内容时，还要检查叛乱派系、地区文化、脚本和生成逻辑。
战役开局驻军
开局地图上的特定聚居地可能还受 Start Pos 数据影响。当前 Assembly Kit 原始表中并没有一条适合当作所有普通建筑驻军默认做法的通用“开局聚居地驻军”路径。
不要因为旧教程提到某个 Start Pos 表，就把它当成当前版本的常规驻军入口。先在当前 RPFM Schema、Assembly Kit 和原版 Pack 中确认该表存在并有实际数据；若目标只是建筑常驻部队，应优先使用上面的建筑—单位组数据链。
制作一套独立建筑驻军
- 明确驻军由哪个具体建筑等级提供。
- 在原版数据中找一个规模和用途相近的驻军模板。
- 从
building_level_armed_citizenry_junctions_tables反查模板单位组。 - 在
armed_citizenry_units_to_unit_groups_junctions_tables查看完整成员和优先级。 - 将单位组定义复制到自己的 Pack，并改为唯一 Key。
- 复制需要的成员行，给每行设置唯一
id。 - 将
unit_group全部改为新单位组 Key。 - 将
unit替换为目标main_unitsKey，并按模板关系设置priority。 - 新建建筑等级到新单位组的连接。
- 检查该建筑在目标派系、文化、聚居地类型和战役中确实可用。
- 运行 RPFM 诊断，并检查所有引用是否指向自己的 Key。
- 进入游戏分别测试仅有主城建筑、建成附加建筑和建筑升级后的驻军。
如何自行查找驻军数据
已知一个建筑
- 在
building_levels_tables找到具体等级 Key。 - 在
building_level_armed_citizenry_junctions_tables筛选building_level。 - 记录命中的
unit_group。 - 在驻军成员连接表中筛选该组，得到全部部队和优先级。
已知一个驻军部队
- 取得它的
main_unitsKey。 - 在
armed_citizenry_units_to_unit_groups_junctions_tables搜索该 Key。 - 记录所有命中的单位组。
- 反查哪些建筑等级连接了这些组。
- 继续检查建筑链的派系和文化可用性。
只知道游戏里的聚居地
先确认该聚居地当前拥有的建筑和等级，再逐个反查对应单位组。不要看到最终驻军有十队，就假定十队全部来自一座建筑。
常见错误
- 建筑能招募部队但没有驻军：把记录加到了
building_units_allowed_tables，没有建立驻军单位组连接。 - 驻军中完全不出现新部队：成员表填了
land_unitsKey，或单位组没有连接到实际建筑等级。 - 多个无关建筑一起改变：直接修改了被它们共同引用的原版单位组。
- 升级建筑后驻军退回旧配置：只处理了一个等级，没有检查整条建筑链。
- 目标派系没有变化：派系使用的是另一个建筑等级、文化变体或专属建筑链。
- 部队被其他驻军挤掉：多个单位组合并后受规模和
priority影响。 - 新增驻军后仍没有城墙：驻军数据不负责聚居地防御地图。
- 把叛军表当成驻军表：叛乱生成和建筑驻军是独立系统。
游戏内验收
- 正确建筑等级提供正确单位组，升级前后变化符合设计。
- 目标派系和聚居地能获得驻军，其他派系不会被共享记录误改。
- 多个建筑同时存在时，最终驻军人数、兵种和优先级合理。
- 部队兵牌、人数、武器和战斗属性正常。
- 拆除、损坏、修复或升级建筑后，驻军能够正确刷新。
- 保存并读取战役后，驻军名单保持一致。
RPFM 诊断不能计算一座聚居地最终合并出的驻军，也不能验证攻城地图。至少要在游戏中测试不同建筑组合、升级前后和读取存档后的结果。