驻军详解
游戏里的聚居地驻军通常不是“建筑直接连接某个兵种”，而是“建筑等级连接驻军单位组，单位组再连接多个部队”。这层单位组让多个建筑可以复用同一套驻军，也让游戏按优先级合并、替换或截取驻军条目。
驻军、建筑招募和驻扎在城内的军队是三件事。
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
编号①～③依次说明连接记录、建筑等级和驻军单位组。示例筛选的是wh3_main_cth_settlement_major_1，当前原版表中可见 10 条建筑连接，共享同一个驻军组。它们并非“制作驻军必须全部复制的十行”：只改一座建筑时，应先复制一个独立单位组，再让目标建筑连接新组；想统一修改这些建筑时，才考虑修改共享组。其他派系或不同等级可以沿同样的引用关系查找自己的模板。
building_level_armed_citizenry_junctions_tables
这张表决定某个具体建筑等级提供哪一个驻军单位组。
| 字段 | 作用 | 注意事项 |
|---|---|---|
id |
连接记录的唯一整数 ID | 新增连接使用新的唯一值；替换原有建筑连接时保留其 ID 并修改unit_group，详见下文。 |
building_level |
提供驻军的建筑等级 Key | 指向building_levels_tables，不是建筑链 Key |
unit_group |
被授予的驻军单位组 | 指向armed_citizenry_unit_groups_tables |
一个聚居地可能同时拥有多个提供驻军的建筑，所以最终驻军是多条建筑连接共同作用的结果。主城建筑、防御建筑、地标和其他派系建筑都可能贡献单位组，不要只检查城墙建筑。
为什么必须使用建筑等级
驻军会随建筑升级而变化，因此连接的是具体等级，而不是整条建筑链。例如同一条主城链的一级、三级和五级可以分别连接不同单位组。
如果只给高等级建筑添加连接，低等级阶段不会自动继承，除非原版链条的其他数据或运行时逻辑确实这样处理。最稳妥的做法是逐级查看原版同类建筑的连接方式。
armed_citizenry_unit_groups_tables
这张表主要定义驻军单位组的身份：
| 字段 | 作用 |
|---|---|
unit_group |
驻军单位组的唯一 Key |
编号①标出unit_group这一列。它只创建可被其他表引用的单位组身份，不包含驻军部队名单。
单位组本身通常没有名称、说明或部队列表。实际包含哪些部队，要到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 |
此单位在驻军合并或容量处理中的优先级 | 数值含义应对照同一套原版组，不要凭感觉统一填写 |
一行代表一条驻军成员记录，不是“一个兵种类别只能出现一次”。同一个unit可以重复出现在多行中，各行使用不同的id；不要按兵种 Key 去重，否则会把本来配置的多队部队删少。
编号①～④依次对应唯一 ID、优先级、部队和所属单位组。上面同一个驻军组在当前原版成员表中有 8 行：4 行玉勇、2 行役农长柄矛手、2 行役农弓手，而不是 8 种兵。这是该组自身的配置；实际聚居地还可能叠加其他建筑驻军，不能把这 8 行直接当成所有情况下的最终名单。
完整八行应怎样复制
本例组 Key 为wh3_main_cth_settlement_major_1。在成员表按unit_group精确筛选，八行可归纳如下；名称已按同一 Loc Key 对照官方三种文本。
| 部队 | unit |
行数 | 每行priority |
|---|---|---|---|
| 玉勇 | wh3_main_cth_inf_jade_warriors_0 |
4 |
500 |
| 役农长柄矛手 | wh3_main_cth_inf_peasant_spearmen_1 |
2 |
350 |
| 役农弓手 | wh3_main_cth_inf_peasant_archers_0 |
2 |
450 |
成员表没有“数量”列。要四队玉勇就保留四条记录，各用不同id；不要写成一行再把priority填4。若改成两队玉勇弩手，可以把其中两条玉勇行的unit改为wh3_main_cth_inf_jade_warrior_crossbowmen_0，再以同组远程部队的优先级作为比较入口，不把优先级当作战斗人数。
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 |
可用于叛军的主单位 |
叛军不是普通驻军。把部队加入此表不会让城市自带该部队，也不会让正常派系获得招募权限。制作叛乱相关内容时，还要检查叛乱派系、地区文化、脚本和生成逻辑。
新战役和旧存档分别检查
建筑驻军由聚居地当前实际拥有的建筑等级及其单位组共同决定。新战役与旧存档的建筑、损坏状态、派系控制权和驻军补员状态可能不同，所以要分别测试，不能仅凭其中一个存档判断 DB 修改是否正确。
本文不使用start_pos编辑开局驻军。目标是修改建筑常驻部队时，沿上面的“建筑等级 → 单位组 → 成员”链处理；目标是临时增援或特定事件驻军时，则另查对应的原版脚本或机制入口。不要把 AK 初始化表导入普通 Mod 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。 - 新增驻军时创建新的建筑连接 ID；替换已有驻军时保留目标原版连接 ID，并把
unit_group改为新组。 - 检查该建筑在目标派系、文化、聚居地类型和战役中确实可用。
- 运行 RPFM 诊断，并检查所有引用是否指向自己的 Key。
- 进入游戏分别测试仅有主城建筑、建成附加建筑和建筑升级后的驻军。
替换与追加必须使用不同的 ID 处理
要只替换建筑wh3_main_cth_settlement_major_1的这组基础驻军：
- 新建
armed_citizenry_unit_groups_tables.unit_group=yourmod_cth_garrison_1。 - 复制上面八条成员，为每条分配新的唯一整数 ID，并统一改为新
unit_group。本次两张驻军连接表的id均按有符号 32 位整数处理，不能写yourmod_001。 - 将原版建筑连接导入自己的表，保留
id=331008905与building_level=wh3_main_cth_settlement_major_1，只把unit_group改为yourmod_cth_garrison_1。这个 ID 标识你要覆盖的原有连接。
如果第三步另造一个 ID，原版331008905仍在，就变成给同一建筑追加一组驻军，可能与旧组叠加。这正是“只想换八队，却同时留下原八队”的常见原因。
本建筑按building_level精确筛选只有上述一条连接；沿原unit_group反查才会看到其他共享该组的建筑。保留原组、只覆盖目标建筑连接，可避免让全部共享建筑一起改变。给自建新建筑添加驻军时，则应使用新建筑 Key 和新的建筑连接 ID。
如何自行查找驻军数据
已知一个建筑
- 在
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 诊断不能计算一座聚居地最终合并出的驻军，也不能验证攻城地图。至少要在游戏中测试不同建筑组合、升级前后和读取存档后的结果。