创建领主单位

创建普通领主不是把英雄的main_units_tables.caste从hero改成lord。领主是军队的统帅，领主招募池、招募分类、随机姓名、技能树、战役模型和派系权限都要按领主的数据链配置；进入战斗后，它又是一个只有一名成员的陆战单位。两条数据链必须通过agent_subtypes_tables.associated_unit_override连接起来。

还要把“配置一种领主”和“让玩家能够招募这个领主”分开：RPFM 中的表单负责前者，本文新增领主的招募接入由 Lua 控制。什么时候加入哪个派系、加入多少人、是否需要解锁、后续怎样补充，不能靠勾选auto_generate或添加派系权限就当作已经完成。

本文制作的是能够反复出现在领主招募池中的普通领主，不是传奇领主、派系领袖、商队领队、城镇守军使用的领主，或由脚本临时生成的特殊人物。它们可能共用部分表单，但生成方式和战役接入方法不同。

先选择合适的原版模板

本文使用震旦的经略使（阳系）wh3_main_cth_lord_magistrate_yang作为普通领主演示模板。这个案例适合说明普通领主的基础数据链，但不是所有派系的唯一做法。法师领主、以巨兽形态参战的领主、恶魔领主、通过晋升获得的领主、数量受限的领主和带有派系专属机制的领主，都应另找更接近的模板。

选择模板时至少比较：

要比较的内容	为什么重要
相同派系或亚文化	决定派系权限、随机姓名、战役模型、语音和专属机制。
相同招募方式	普通领主招募池、晋升、事件、任务和特殊招募池使用的接入方式不同。
相同战斗形态	步行、骑乘、飞行、巨兽、战车或多个实体组成的领主使用不同的实体与动作链。
相同技能类型	近战、远程、施法和混合领主的技能树、法术和 AI 定位不同。
相同外观生成方式	一套固定外观、多套随机外观和模块化人物不能使用同一种战役外观配置。
相同派系机制	忠诚度、骑士誓言、晋升、宁和、吸血鬼伯爵的血裔、冰雪王廷训练等会增加额外数据或脚本条件。

不要只因为某个原版人物“看起来像”你的新领主就复制它。先在游戏中确认它如何招募、是否能随机生成、有没有专属机制，再到 RPFM 中追踪它的人物类型 Key。

数据与招募接入链

普通领主的战役人物身份
agent_subtypes_tables
    ├─ recruitment_category ─→ agent_recruitment_categories_tables
    ├─ faction_agent_permitted_subtypes_tables（军队领主通常使用 Agent = general）
    ├─ character_skill_node_sets_tables
    ├─ campaign_character_art_sets_tables
    │       └─ campaign_character_arts_tables
    │               └─ agent_uniforms_tables
    └─ associated_unit_override ─→ main_units_tables

进入战斗后的单人单位
main_units_tables
    └─ land_units_tables
            ├─ unit_variants_tables → variants_tables
            ├─ battle_entities_tables
            ├─ melee_weapons_tables / missile_weapons_tables
            └─ 护甲、盾牌、属性、技能、接触效果与按需分支

Lua 招募接入（必须另行配置）
目标战役与派系 → 触发和解锁条件 → 将指定人物类型加入领主招募池
    └─ 数量、后续补充、姓名、外观以及保存后重新读取的处理

表单链定义普通领主的基本身份，Lua 接入负责把这套身份变成可招募人物。坐骑、法术、物品和派系机制还会继续增加分支；不能只完成表单链就跳到“招募成功”。

需要哪些表单

普通领主的核心表单

表单	负责什么
agent_subtypes_tables	定义具体领主类型、是否自动生成、招募分类、招募成本、姓名规则及关联战斗单位。
agent_recruitment_categories_tables	定义领主招募界面中的分类名称、图标、顺序和是否显示。
faction_agent_permitted_subtypes_tables	允许指定派系生成该领主，并说明它在该系统中使用哪个内部人物大类。
main_units_tables	定义领主进入战斗时使用的主单位、人数、战斗伤势与战役人物状态的衔接、动态头像镜头和语音。
land_units_tables	定义战斗数值、实体、动作、武器、防护、属性和 AI 用法。
unit_variants_tables	把主单位与战斗模型变体连接起来。
campaign_character_art_sets_tables	把一套或多套Art Set（战役外观配置）分配给领主类型。
campaign_character_arts_tables	配置每套Art Set使用的Uniform、战役动作和条件变体。
character_skill_node_sets_tables	把技能树分配给领主类型。
character_skill_node_set_items_tables	把技能节点放进该技能树。

此外必须有本 Mod 的战役 Lua 招募入口。它不是另一张 DB 表：脚本要实际执行，并使用上面定义的派系 Key、人物类型 Key、姓名和外观数据。

只在对应目标下添加

表单或文件	什么时候需要
agents_tables	几乎不需要。普通军队领主应复用原版general，不是为每种领主新建一种内部人物大类。
agent_culture_details_tables	目标文化尚未配置general的显示名称、默认单位或图标时才考虑。现有可玩文化通常已有。
agent_uniforms_tables	使用新的战役模型，或让campaign_porthole_filename、campaign_politician_filename和战役骨骼使用不同资源时添加。复用原版Uniform时不要复制原行。
names_groups_tables、names_tables	需要独立的随机姓名池时添加。
campaign_character_art_set_porthole_overrides_tables、*portrait_settings*.bin	需要新的动态头像构图、相机或贴图时处理。
campaign_mounts_tables	新建战役地图坐骑模型与动作组合时添加。
campaign_mount_animation_set_overrides_tables	骑手在特定坐骑上需要另一套战役动作时添加。
campaign_character_uniform_ancillary_junctions_tables	装备坐骑物品后要切换战役Uniform时添加。
agent_subtype_ownership_content_pack_junctions_tables	只读核对原版内容包关系。该表存在特殊校验，不作为普通自定义表导入修改。
effects_tables及相关连接表	领主需要通过建筑、科技、资源或其他效果解锁，或提高新募领主等级、增加数量上限时添加。
campaign_to_agent_subtypes_tables	原版同类领主确实按战役过滤时才添加。它不是普通领主普遍必需的“战役开关”。

先规划全部 Key

用自己的短前缀统一命名。以下只是结构示例：

领主类型：yourmod_cth_lord
主单位：yourmod_cth_cha_lord_0
陆战单位：yourmod_cth_cha_lord_0
战斗模型变体：yourmod_cth_cha_lord
招募分类：yourmod_cth_lord_category
战役外观配置：yourmod_art_set_cth_lord_01
技能树节点集合：yourmod_skill_node_set_cth_lord

yourmod要换成自己的唯一前缀。不要使用原版的wh3_main或wh3_dlc前缀，也不要让同一概念在不同表里出现不同拼写。

如果计划制作步行、战马和飞行坐骑三种战斗形态，还应先规划每个形态的主单位、陆战单位和战斗模型变体 Key，而不是做到技能树时才临时命名。

在 Pack 中准备数据

先新建自己的 Mod Pack，再到依赖项 → 游戏文件查找模板表。双击原版表后，页签应以Game-RO:开头，表示正在只读查看游戏文件。本文截图展示的是原版模板，不是已经改好的新领主；后文的复制、修改 Key、反选和删除都在自己的 Pack 中完成。

有两种常用方式：

1. 在自己的 Pack 中新建对应类型的 DB 表，从依赖项 → 游戏文件打开原版表，筛选模板 Key，把需要的记录复制到新表，再修改 Key。
2. 从依赖项 → 游戏文件将原版整张表导入自己的 Pack，立即把导入后的data__改成自己的 DB 文件名，选中需要保留的模板行，再反选并删除其他行。

导入后的 DB 文件不得继续使用data__。data__是原版数据库的默认名称，保留它可能让 Mod 整表覆盖原版。先重命名，再选中需要的模板记录，反选后删除其他记录。

第二种方式方便一次查看同表的完整数据，但很容易把数千条无关原版记录留进 Pack。完成一个表单后都应检查：是不是只剩本 Mod 新建或修改的行。

Assembly Kit 文件和db.pack只能作为只读研究、交叉核对资料，不作为本文导入、复制、编辑或游戏引用的来源。改名的是自己 Pack 内的 DB 文件，不是agent_subtypes_tables等表类型文件夹，也不修改原版文件。

先创建领主的战斗单位

在制作早期，可以先让新人物类型的associated_unit_override指向原版主单位，以便只验证招募和战役身份。但这会共享原版战斗单位，不适合作为需要独立数值、模型或技能的最终成品。

要建立独立战斗单位，至少复制模板的：

1. main_units_tables记录。
2. land_units_tables记录。
3. unit_variants_tables记录。
4. 确实要独立修改的实体、武器、护甲、盾牌、属性组、接触效果和部队技能连接。

不修改的原版引用可以继续复用。复制所有被引用记录不会让领主更完整，只会增加冲突、漏改 Key 和后续维护成本。

main_units_tables中的领主关键项

字段	处理原则
unit	新主单位的唯一 Key。
land_unit	指向新建的land_units_tables.Key。
num_men	普通单人领主为 1。多实体领主必须使用真正同类的原版模板。
caste	普通军队领主使用lord。这只是领主单位分类的一部分，不能代替人物类型和派系权限。
recruitment_cost、upkeep_cost	战斗单位层的招募成本和维持费基础值。领主招募界面还会读取人物类型的成本和相关效果，需进游戏确认最终数值。
campaign_cap	单位层面的战役上限。普通领主通常沿用同类模板，不要把英雄容量逻辑套进来。
audio_voiceover_culture、audio_voiceover_actor_group	战斗中的文化和演员语音。没有新语音时复用兼容模板。
ui_unit_group_land	战斗和部分界面使用的单位分组。近战领主、法师领主等可能不同。
porthole_camera	动态头像和战前镜头使用的相机模板。要与体型和坐骑匹配。
mount	主单位层的坐骑引用。多坐骑领主通常为每种战斗形态建立独立单位，不要只改这一格。
use_hitpoints_in_campaign	让战斗中的伤势与战役地图上的人物状态衔接。应沿用同类领主模板。
restrict_xp_gain_in_campaign	人物经验处理标记。不要使用普通兵种的经验设置。
melee_cp、missile_cp	自动结算或强度评估相关权重，不等同于面板近战攻击和远程威力。
can_siege	该领主单位是否具备独立攻城能力，不是“能否参加攻城战”。
is_monstrous	与巨兽体型有关的内部标记。应按体型相同的原版领主模板处理。
can_be_bribed	与特定战役机制有关，不应根据字面随意开启。

wh3_main_cth_cha_lord_magistrate_0的当前原版记录使用num_men = 1、caste = lord、use_hitpoints_in_campaign = true和restrict_xp_gain_in_campaign = true。这些值能说明普通人形领主的基本结构，但不能直接证明以巨兽形态参战的领主或其他特殊领主也使用完全相同的设置。

land_units_tables中的领主关键项

领主的单位人数不在这里设置，而在main_units_tables.num_men中。这里主要检查：

• man_entity：单个领主使用的战斗实体，决定质量、碰撞、基础生命值和体型等。
• man_animation：战斗动作表，必须与骨骼、武器姿势和坐骑形态匹配。
• bonus_hit_points：在实体基础生命值之上增加的生命值。
• primary_melee_weapon、primary_missile_weapon、armour、shield：武器与防护引用。
• attribute_group：单位属性组，例如免疫、隐藏或特殊移动能力的组合。
• ai_usage_group：战斗 AI 如何理解和使用该领主。
• spell_mastery：法术精通倍率，不会自动授予法术。
• num_mounts、mount：当前战斗单位本身的坐骑结构。
• campaign_action_points：行动点数的基础值。不要为了提高战斗速度去改它。
• is_male：战斗单位层的性别相关标记，不应单独作为姓名或战役外观的依据。

战斗数值、实体、武器、属性、部队技能和接触效果的完整含义，请结合《陆战单位详解》中的对应章节，以及《远程武器详解》和《部队技能详解》。创建领主时仍要逐条追踪引用，不能因为已有专题就跳过检查。

创建agent_subtypes_tables记录

复制最接近的普通领主人物类型记录，把key改为新 Key，再逐项检查：

字段	作用与普通领主的处理方式
auto_generate	原版人物类型的自动生成相关标记，不是新增领主的完整招募入口。原版模板勾选此项，不等于新 Key 也会按你设计的规则进入招募池；本文通过 Lua 控制新增领主的加入与补充，并避免两套生成逻辑重复工作。
onscreen_name_override	领主职业名称。最终简体中文由本地化文本（Loc）决定。
is_caster	施法者身份标记。它不会授予法术。
small_icon	可选的人物类型小图标覆盖。留空时可能从其他数据取得。
associated_unit_override	指向步行或默认形态使用的main_units_tables.Unit。这是战役人物与战斗单位的关键连接。
description_text_override	可选的职业说明覆盖。要在领主招募界面和人物详情界面确认显示位置。
audio_voiceover_actor_group	战役地图上的领主语音组。
show_in_ui	是否允许在相关界面显示。
cap	人物类型自身的限制值。普通领主常使用-1，特殊招募池或派系机制不能照搬。
has_female_name	姓名生成相关标记。需与姓名池、模型和本地化文本一起验证。
can_gain_xp	是否能获得人物经验。
loyalty_is_applicable	是否参与忠诚度系统。只在目标派系确实使用时开启。
contributes_to_agent_cap	是否计入相关内部人物大类的数量限制。普通领主与特殊机制中的领主可能不同。
names_group	可选的随机姓名组覆盖。留空可能回退到派系或文化默认姓名来源。
recruitment_category	领主招募界面分类，必须指向有效的agent_recruitment_categories_tables.Key。
magic_lore	魔法之风或施法分类引用。法术仍需通过技能、部队技能、物品或其他机制授予。
can_be_loaned	是否参与内部的人物借调流程。游戏没有统一显示这一字段的名称，应按相同派系、相同招募方式的模板处理。
recruitable	是否可招募。开启后仍需派系权限、分类和生成条件。
saving_settings	控制人物保存与导入功能，引用character_saving_settings_tables；三种值见下表，不负责战役存档保存。
audio_vo_culture_override	覆盖所用的战役语音配置。
spam_click_vo_enabled	是否启用连续点击语音。没有完整语音支持时不要随意开启。
can_equip_ancillaries	是否能装备物品。
cost	人物类型层的招募成本基础值。最终成本还会受其他数据和效果影响。
recruitment_button_active_icon_path、recruitment_button_background_icon_path	招募按钮图片覆盖，很多原版记录留空。
audio_force_contextual_vo	与军队情境语音有关，应沿用相同语音方案模板。

当前经略使（阳系）wh3_main_cth_lord_magistrate_yang使用auto_generate = true、recruitable = true、recruitment_category = wh3_main_cth_lord_magistrate和saving_settings = can_be_saved_loaded。截图只证明原版记录填了哪些值，不能证明复制成新人物类型以后无需 Lua 就能招募。

图中人物类型 Key 带有_yang，关联的主单位 Key 却是wh3_main_cth_cha_lord_magistrate_0。它们是不同系统中的标识，不必同名；制作新领主时必须按实际引用连接，不能只凭名称猜测对应关系。

第二张图是同一条记录横向滚动后的字段。recruitment_category、recruitable、saving_settings等仍需继续向右检查，不能把一张截图里可见的几列当成完整配置。

saving_settings三种配置的准确含义

它引用character_saving_settings_tables，控制人物保存与导入功能，不是战役存档能否保存或读取。

Key	允许保存人物	允许导入战役	允许导入自定义战斗
can_be_saved_loaded	true	true	true
cannot_be_loaded_in_campaign	true	false	true
cannot_be_saved_loaded	false	false	false

普通经略使（阳系）使用第一项，原版妙影使用第二项。第二项不会让玩家无法读取有妙影的战役存档，第三项也不会实现传奇人物唯一性；唯一性仍看生成逻辑和存档中的防重复状态。

配置领主招募分类

agent_subtypes_tables.recruitment_category指向agent_recruitment_categories_tables。这个分类控制领主招募界面中的分组，而不是派系权限。

复用原分类

如果新领主本来就应和一种原版领主显示在同一分类中，可以直接引用原版分类 Key。适用条件是：

• 分类名称和图标也适合新领主。
• 新旧领主应在同一分组中出现。
• 你接受其他 Mod 对该原版分类的修改也可能影响新领主。

新建独立分类

需要独立名称、图标或排序时，复制模板分类并修改：

字段	作用
key	新分类唯一 Key。
onscreen_name	分类名称的文本源，最终应有对应的简体中文本地化文本。
onscreen_description	可选说明。实际界面是否显示要进游戏确认。
icon_file_path	分类图标路径。可以复用合法原版图标，也可以加入新图片。
order	同一招募界面中的排列顺序。先查看目标派系现有分类顺序再决定。
show_in_recruitment	是否在招募界面显示。
counts_towards_caps_when_off_the_map	人物不在战役地图上时是否仍计入相应上限。不要仅凭中文直觉修改，应按同类招募方式的模板处理。

原版经略使招募分类wh3_main_cth_lord_magistrate使用领主图标、order = 1并显示在招募界面。若你创建的是另一种震旦普通领主，它可以共享该分类，也可以使用独立分类；选择取决于你希望玩家在招募界面如何区分，而不是技术上只能选一种。

当前全部 86 个招募分类

下表来自agent_recruitment_categories_tables全部定义；名称已按相同 Loc Key 核对官方三种文本。“显示”是show_in_recruitment的原版值，不证明目标派系能使用该分类。经略使案例用wh3_main_cth_lord_magistrate，法师领主可先比较wh3_main_cth_dragon_blooded_shugengan，固定传奇领主通常比较legendary_lords。

招募分类 Key	官方简中名称	order	原版显示
brt_lord	领主	1	true
brt_prophetess	女先知	2	true
bst_beastlord	兽王	1	true
bst_doombull	末日蛮牛	2	true
bst_great_bray_shaman	大嘶叫萨满	3	true
chs_daemon_princes	恶魔亲王	4	true
chs_lord	混沌领主	1	true
chs_lord_of_change	万变魔君	3	true
chs_sorcerer_lord	混沌术士领主	2	true
cst_legendary_admirals	传奇提督	3	true
cst_vampire_fleet_admiral	吸血鬼舰队司令	1	true
cst_vampire_fleet_admiral_female	吸血鬼舰队司令	2	true
def_dreadlord	恐惧领主	1	true
def_dreadlord_female	恐惧领主	2	true
def_high_beastmaster	高阶驯兽师	3	true
def_supreme_sorceress	高阶女术士	4	true
dwf_daemon_slayer	恶魔屠夫	3	true
dwf_legendary_grudge_lord	传奇仇恨领主	4	true
dwf_lord	领主	1	true
dwf_runelord	符文领主	2	true
emp_arch_lector	大诵经师	2	true
emp_general	帝国将军	1	true
emp_huntsmarshal	猎人将军	3	true
emp_master_engineer	工程大师	4	true
grn_goblin_great_shaman	地精大萨满	1	true
grn_night_goblin_war_boss	夜地精战将	2	true
grn_orc_war_boss	兽人战将	3	true
grn_savage_orc_great_shaman	蛮荒兽人萨满	4	true
grn_workshop	工坊小子	5	true
hef_archmage	大法师	1	true
hef_prince	精灵王子	2	true
hef_princess	精灵公主	3	true
hef_sea_helm	海盔	4	true
legendary_lords	传奇领主	0	true
lzd_kroxigor_ancient	远古巨蜥	1	true
lzd_red_crested_skink_chief	红冠灵蜥首领	2	true
lzd_saurus_old_blood	蜥人古血战士	3	true
lzd_slann_mage_priest	史兰魔祭司	4	true
nor_great_shaman_sorcerer_lord	大萨满术士	3	true
nor_lord_of_change	混沌诸神冠军勇士	1	true
nor_marauder_chieftain	掠夺者氏族长	3	true
nor_sorcerer_lord	混沌术士领主	2	true
skv_grey_seer	灰先知	1	true
skv_master_assassin	刺客导师	2	true
skv_warlock_master	工程大术士	3	true
skv_warlord	斯卡文军阀	4	true
teb_lord	将领	0	true
tmb_dynasties	诸王朝	1	true
tmb_tomb_king	古墓王	2	true
vmp_bloodlines	血裔	1	true
vmp_lord	吸血鬼领主	4	true
vmp_master_necromancer	亡灵法师导师	2	true
vmp_strigoi_ghoul_king	史崔格食尸鬼王	3	true
wef_ancient_treeman	远古树人	1	true
wef_glade_lord	林地领主	2	true
wef_glade_lord_female	林地领主	3	true
wef_spellweaver	织法者	1	true
wh3_cp1_cth_sawai	至伟虎人战士	5	true
wh3_cp1_cth_sawai_caravan	至伟虎人雇佣兵	4	true
wh3_dlc23_chd_lord_convoy_overseer	车队监督	3	true
wh3_dlc23_chd_overseer	监察	1	true
wh3_dlc23_chd_sorcerer_prophet	术士先知	0	true
wh3_dlc24_cth_celestial_general	昊天将军	3	true
wh3_dlc24_ksl_druzhina	近卫军	4	true
wh3_dlc26_kho_bloodspeaker	血语者	2	true
wh3_dlc26_ogr_paymaster	食人魔钱粮官	3	true
wh3_dlc27_chs_sorcerer_lord_shadows_msla	色孽混沌术士领主（阴影系）	8	true
wh3_dlc27_chs_sorcerer_lord_slaanesh_msla	色孽混沌术士领主（色孽系）	9	true
wh3_dlc27_hef_dragonships	龙舰	5	true
wh3_main_cth_dragon_blooded_shugengan	龙裔修验官	2	true
wh3_main_cth_lord_caravan_master	督运总督	4	true
wh3_main_cth_lord_magistrate	经略使	1	true
wh3_main_kho_exalted_bloodthirster	神尊嗜血狂魔	5	true
wh3_main_kho_herald_of_khorne	恐虐军锋	1	true
wh3_main_ksl_ataman	盖特曼	3	true
wh3_main_ksl_boyar	波耶	1	true
wh3_main_ksl_ice_witch	冰雪女巫	2	true
wh3_main_nur_exalted_great_unclean_one	神尊大不净者	6	true
wh3_main_nur_herald_of_nurgle	纳垢军锋	2	true
wh3_main_ogr_slaughtermaster	屠宰大师	2	true
wh3_main_ogr_tyrant	暴君	1	true
wh3_main_ogr_tyrant_camp	营地暴君	4	false
wh3_main_sla_exalted_keeper_of_secrets	神尊守密者	7	true
wh3_main_sla_herald_of_slaanesh	色孽军锋	3	true
wh3_main_tze_exalted_lord_of_change	神尊万变魔君	8	true
wh3_main_tze_herald_of_tzeentch	奸奇军锋	4	true

这些是显示分类，不能拿来填 Agent 或 Subtype。创建新分类时复制合适的原记录，换新 Key、名称与排序；图标和counts_towards_caps_when_off_the_map继续按对应记录核对。复用原分类则不必把分类定义导入自己的 Pack。

把领主交给派系

普通军队领主需要在faction_agent_permitted_subtypes_tables中获得派系权限。基本记录为：

Faction = 目标派系 Key
Agent   = general
Subtype = 新领主人物类型 Key

要让多个派系使用，应为每个目标派系添加一条经过确认的权限记录。不要一次复制同文化的所有派系，因为其中可能包含叛军、任务战、序章、测试或不可玩派系。

本例的两条明确权限

若目标是卫北列省与卫西列省，创建两行即可：faction分别为wh3_main_cth_the_northern_provinces与wh3_main_cth_the_western_provinces，agent均为general，subtype均为yourmod_cth_lord，mod_disabled=false。第三个派系必须再增加其准确 Key 的独立行。

当前 Agent 全部九类为general、champion、dignitary、engineer、runesmith、spy、wizard、colonel、minister。中间六个是普通英雄主要使用的大类；普通军队领主使用general，不能因为新领主会施法就改填wizard。施法身份通过 Subtype 和实际技能链配置。

为什么不能复制搜索到的全部权限行

同一个人物类型可能在不同系统中使用不同的内部人物大类。当前原版数据里，部分震旦领主除了general外，还可能以colonel或minister出现在特定派系权限中：

• general：作为军队领主的核心身份。
• colonel：可能服务于商队、临时军队或其他专属系统。
• minister：可能服务于职位、派系管理或其他专属系统。

制作普通军队领主时，不能因为全局搜索看见三类记录就全部复制。先确定目标领主是否真的要进入相应专属系统；只需要普通领主招募池时，先建立general权限，再单独测试派系机制。

经略使原版字段与本教程 Lua 路线的区别

在agent_subtypes_tables.key精确筛选wh3_main_cth_lord_magistrate_yang，原版associated_unit_override=wh3_main_cth_cha_lord_magistrate_0、cost=550、cap=-1；is_caster=false、has_female_name=false、loyalty_is_applicable=false，show_in_ui、can_gain_xp、contributes_to_agent_cap、can_be_loaned、recruitable、can_equip_ancillaries均为true。small_icon、magic_lore、names_group为空。

原版auto_generate=true。本教程后面的独立 Lua 已负责候选补充，因此新 Subtype 采用auto_generate=false来避免再引入另一条自动生成路径；这是自定义路线的有意改变，不能把原版勾选状态与教程脚本都照搬后不检查重复候选。其他字段先按目标职责选择，不要把550或cap=-1当成所有领主的强制值。

配置随机姓名

普通领主通常不是固定姓名，而是从派系或姓名组中生成姓名。姓名来源可能同时受以下内容影响：

• agent_subtypes_tables.names_group
• names_groups_tables
• names_tables
• 派系、文化、内部人物大类和性别条件
• 部分专属人物生成机制

复用派系姓名池

如果新领主要使用目标派系现有的普通领主姓名，可以沿用同类模板的names_group设置。模板为空不等于“没有姓名”，它可能表示使用派系或文化默认来源。

建立独立姓名池

需要独立姓名时：

1. 找一个同文化、同性别结构的原版姓名组。
2. 复制names_groups_tables记录并创建新 Key。
3. 复制或新建names_tables中的姓名记录，确保数值 ID 唯一。
4. 把新姓名组填入人物类型记录的names_group。
5. 为名、姓氏和其他称号补充简体中文本地化文本。

图中①是原版names_cth_cathay姓名组的唯一 Key；真正可抽取的名、姓氏和称号仍在names_tables等姓名数据中。创建一个空的姓名组 Key 不会自动产生任何中文姓名，也不要仅凭这个组名就断定所有震旦人物都直接填写它，应检查所选模板的实际姓名来源。

不要直接复制传奇领主的固定姓名来充当普通领主随机姓名池，也不要只改has_female_name就期待游戏自动生成对应性别的全部姓名。

配置战役模型与随机外观

Art Set与战役外观记录的分工

campaign_character_art_sets_tables负责把Art Set（战役外观配置）分配给人物类型；campaign_character_arts_tables负责每套外观配置具体使用哪个Uniform和哪套战役动作。Art Set是数据库内部名称，不是游戏界面中的外观分类。

当前经略使（阳系）wh3_main_cth_lord_magistrate_yang拥有 5 套Art Set，表示它可以生成多种战役外观。这不代表所有普通领主都必须创建 5 套：

• 想保留相同数量的随机外观时，复制全部相关Art Set和对应的战役外观记录。
• 只有一个固定外观时，只创建 1 套即可。
• 使用模块化或专属换装系统时，应找使用同一系统的模板，不能用固定Uniform方案代替。

每条campaign_character_art_sets_tables至少检查：

字段	作用
art_set_id	Art Set的唯一 Key。
is_custom	原版内部的外观选择标记。按模板保留，不要因为“这是自制 Mod”就按字面开启。
agent_type	普通军队领主通常为general。
faction、culture、subculture	可选适用范围。只有确实需要限制时才填写。
is_male	选择战役外观时使用的条件之一。原版存在反直觉值，不能把它当成玩家所见性别的唯一判断。
agent_subtype	指向新领主的人物类型 Key。
campaign_map_scale	战役地图模型缩放。
prebattle_separation_offset	战前界面中的模型间距偏移。

campaign_character_arts_tables至少检查：

• art_set_id是否指向新的Art Set。
• 数值id是否在整张表中唯一。
• level、season、age是否需要条件变体。
• uniform是否指向正确的agent_uniforms_tables记录。
• land_animation是否与战役模型和装备匹配。
• sea_uniform、navy_uniform、sea_animation、navy_animation是否保留了合法的海上状态。
• portrait、card、info等直接图片字段是否需要沿用或覆盖。

图中只筛选经略使（阳系）的 5 条外观记录：① Art Set Id连接campaign_character_art_sets_tables；② Level、Age和Season用于区分条件，夹在它们之间的Portrait是图片引用，不是外观选择条件；③ Uniform指向战役人物实际使用的外观资源。右侧还有海上外观、动作和其他图片列，复制时要横向检查完整记录，不能只改画面中的字段。

复用还是新建Uniform

如果新领主完整复用原版战役模型，战役外观记录可以指向原版Uniform，不要把原版agent_uniforms_tables记录重复复制进 Pack。

只有使用新模型，或下面这些内部字段需要指向新资源时，才创建新Uniform并逐项检查：

• filename
• battle_filename
• campaign_porthole_filename
• campaign_politician_filename
• campaign_override_skeleton

这些路径必须对应 Pack 或依赖项中的真实文件。DB 引用正确不代表模型资产存在。

五套随机外观的准确起点

经略使（阳系）的五套 Art Set 是wh3_main_art_set_cth_lord_magistrate_yang_01至_05。每套agent_type=general、agent_subtype=wh3_main_cth_lord_magistrate_yang，is_male=true、is_custom=false、campaign_map_scale=1、prebattle_separation_offset=0，文化、亚文化和派系为空。

第一套的campaign_character_arts_tables配置为level=0、age=0、season=none，uniform=wh3_main_uniform_cth_lord_magistrate_01、land_animation=cam_hu1e_sword_lord；海上与海军 Uniform 均为wh3_uniform_cth_ship_lord，动作均为cam_cathayship_01。portrait、card、info为空，三个 VFX 过滤值均为0。

第二至第五套按各自 Art Set 精确查找，Uniform 对应wh3_main_uniform_cth_lord_magistrate_02至_05。若只设计一个固定外观，可以只新建一套完整 Art Set 与其 Arts 行；要五种随机外观则全部保留，并分别处理 Portrait Settings。新 Arts 行使用自己的唯一整数 ID，不复用第一套原 ID 572180136。

配置头像和兵牌

领主不同界面的图片来源可能不同：

• agent_subtypes_tables.small_icon和recruitment_button_*：人物类型层的招募图标覆盖。
• agent_recruitment_categories_tables.icon_file_path：招募分类图标。
• unit_variants_tables.unit_card：战斗单位兵牌引用。
• campaign_character_arts_tables中的头像、卡片或信息图片字段。
• *portrait_settings*.bin：动态头像构图、相机、贴图和变体。
• campaign_character_art_set_porthole_overrides_tables：特定Art Set的动态头像场景覆盖。

新建Art SetID后，应在游戏文件范围全局搜索模板Art Set出现在哪些portrait_settings文件中。把需要修改的文件加入自己的 Pack 后，再在 RPFM 的Portrait Settings编辑器里克隆对应条目，将art_set_id改为新 ID，并按需更换贴图、相机和战斗模型变体；不要编辑原版文件。

只新建Art Set而不处理Portrait Settings，常见结果是战役模型正常、动态头像却为空。战斗兵牌正常也不能证明战役头像已经配置完成，因为二者不是同一数据源。

配置技能树

普通领主必须拥有指向新人物类型的技能树节点集合。若要复用模板技能树而不修改其技能内容：

1. 复制character_skill_node_sets_tables中的模板记录。
2. 修改key为新的技能树节点集合 Key。
3. 保持agent_key = general。
4. 将agent_subtype_key改为新领主人物类型 Key。
5. 根据需要保留或修改faction_key、campaign_key和subculture限制。
6. 复制模板在character_skill_node_set_items_tables中的所有成员行，只把set改为新的技能树节点集合 Key。

图中：① Key是技能树节点集合 Key；②普通军队领主的Agent Key通常为general；③ Agent Subtype Key指向具体领主人物类型。派系、战役和亚文化列是可选限制，不应因为示例留空或有值就机械照搬。

这样做会让新领主使用原版技能节点，但不会覆盖原领主。不要为了“独立”而复制所有character_skills_tables、character_skill_nodes_tables和效果记录；只有要改技能内容时才创建独立节点和技能。

领主技能树通常包含：

• 个人战斗技能。
• 军队强化技能。
• 战役行动、维持费、招募或补员技能。
• 法术和增幅法术分支。
• 坐骑解锁技能。
• 派系或领主专属技能。

复用时应检查每个共享技能是否引用模板人物类型、特定派系、特定兵种集合或专属机制。技能树能够打开，不代表所有技能都会对新领主生效。

配置法师领主

法师领主至少涉及三个彼此不同的问题：

1. agent_subtypes_tables.is_caster是否标记为施法者。
2. agent_subtypes_tables.magic_lore及相关分类是否与目标魔法之风一致。
3. 技能树、部队技能、物品或其他机制是否真正授予法术。

只开启is_caster不会得到任何法术；只填写magic_lore也不会自动生成完整的法术技能分支。应使用《法术详解》中的方法，从使用同一魔法之风、采用同一解锁方式的原版领主追踪法术节点、技能等级和部队技能。

配置坐骑与多形态单位

坐骑不是在一个字段里写上坐骑 Key 就全部完成。常见链路包括：

技能树中的坐骑技能
    └─ 授予坐骑物品或切换条件
            ├─ 对应的坐骑形态 main_units_tables / land_units_tables
            ├─ campaign_mounts_tables
            ├─ campaign_mount_animation_set_overrides_tables
            └─ campaign_character_uniform_ancillary_junctions_tables

不同原版领主可能采用不同的坐骑实现方式。制作时逐项确认：

图中：① Model是坐骑记录的模型 Key；② Animation Set与Variant负责战役动作和显示变体；③ Scale设置缩放比例，Actor引用所用的语音配置；例如图中多数震旦坐骑引用wh3_main_vo_culture_Cathay。这里只展示坐骑链的一张表，坐骑技能、战斗形态、附件和动作覆盖仍要沿所选原版模板继续追踪。

这张图用cth筛出了几种震旦坐骑作对照，不表示它们全都属于经略使。判断某个领主实际能用什么坐骑，应从该领主的坐骑技能或物品追踪到这里；不要把搜索结果全导入，也不要只凭名称相近就替换模型。

• 每种战斗形态是否有独立主单位和陆战单位。
• 骑手、坐骑和组合后的战斗模型变体是否真实存在。
• 骨骼、骑乘动作、武器挂点和实体碰撞是否匹配。
• 战役地图是否切换到对应坐骑模型和动作。
• 动态头像相机是否适合坐骑后的高度和构图。
• 卸下坐骑后是否能正确回到步行形态。

本文不规定必须用物品、技能或脚本中的某一种方法；应选择与目标派系现有坐骑系统相同的模板。

用 Lua 控制领主招募

前面的表单提供可以被招募系统使用的领主类型，接下来必须配置实际执行的 Lua 招募逻辑。recruitable、招募分类和目标派系的general权限是要核对的数据条件，不是脚本的替代品。

先确定招募规则

要决定的内容	对脚本的要求
哪些派系可以招募	核对目标派系 Key，并明确是否支持 AI；不能只判断“当前玩家”。
什么时候加入	新战役初始化、目标派系回合开始、完成任务、研究科技或其他明确事件。
一次加入多少人	普通领主要考虑候选数量，不能每次触发都无限添加。
招募后是否补充	“开局加入一个”和“长期维持多个候选”不是同一套逻辑。
姓名与外观	使用可用的姓名来源和该人物类型的Art Set，不能让所有普通领主都套用同一传奇人物身份。
重载和重复触发	保存必要状态，避免每次读档重复加入；需要补充时又不能被永久的一次性标记挡住。

建筑、科技、资源、任务和事件都可以是设计中的条件，不是只能在兵营解锁。关键在于 Lua 是否检查了该条件，并在满足条件时执行对应的招募接入。

查找真正的执行入口

1. 在 RPFM 的全局搜索中选游戏文件，同时搜索 DB 和文本文件；只搜 DB 会漏掉 Lua。
2. 搜索模板人物类型 Key；打开命中的战役脚本，追踪调用它的函数以及注册该函数的事件或初始化入口。
3. 如果人物类型由列表或通用函数传入，继续搜索这个列表名或函数名，直到找到实际传入派系、人物类型和条件的位置。
4. 对照当前 WH3 的接口文档确认参数，不能把战锤 2 旧教程的加载方式或函数参数直接搬过来。
5. 把本 Mod 的逻辑放进自己唯一命名的 Lua 文件，接入对应战役的加载流程。不要覆盖整份原版人物脚本，也不要只定义一个从未被调用的函数。

可用的接口线索是cm:spawn_character_to_pool(...)，作用是向指定派系的招募池加入一个人物。它接收派系、姓名、年龄、性别、人物大类、人物类型、不朽设置和外观等参数；军队领主的人物大类使用general。这个调用只负责加入人物，不会替你实现持续补充、解锁条件和防重复规则。参数以WH3 人物加入招募池接口和当前原版调用为准。

把自己的 Lua 放到正确位置

当前游戏的script/_lib/lib_mod_loader.lua会加载script/campaign/mod/中的 Lua。这里是 Pack 内部路径，不是在游戏安装目录散放一个同名文件，也不是db下面的表。

图中①展示加载器查找的目录，本文选用其中的script/campaign/mod/；②说明加载文件和战役开始后执行入口不是同一个时刻。这份Game-RO:原版加载器仅用于理解机制，不要导入、编辑或覆盖它。你的招募逻辑放在自己的 Lua 文件中。

1. 用文本编辑器新建yourmod_cth_lord_recruitment.lua，以 UTF-8 保存，确认真实扩展名是.lua，不是.lua.txt。
2. 在电脑上按script/campaign/mod/建立文件夹，把 Lua 放进mod文件夹。
3. 右键自己的 Mod Pack 根节点，使用添加文件夹（部分界面显示添加多个文件夹），选择这棵script目录；检查 Pack 内最终路径恰好是script/campaign/mod/yourmod_cth_lord_recruitment.lua。
4. 双击自己的 Lua，确认 RPFM 显示脚本正文，而不是原版Game-RO:页签；保存的是自己的 Pack。
5. 启用该 Mod，进入目标战役。仅在 RPFM 中看到脚本文件不代表游戏已经执行了它。

下面使用匿名cm:add_first_tick_callback注册入口，文件加载后先登记回调，战役对象可用时再运行。不要再额外创建一个同名全局函数去重复调用它，也不要把“登记回调”的代码放到从未被调用的函数里。

main_warhammer是本例在 Lua 中检查的战役名，对应超凡帝国；前文 DB 的战役 Key 可以是wh3_main_combi。不同系统的标识不一定相同，不要把 DB 值直接替换进 Lua 的战役名判断。

一个可替换参数的普通领主招募示例

本例限于单人战役中由玩家控制的一个目标派系：首次初始化加入一个候选；每个新人物第一次被招募时补一个候选；同一个人解散后再招募不重复补人。它不是“永远保持招募池恰好有一个人”的数量上限算法。

先完成前文yourmod_cth_lord的 DB、姓名与外观。代码里的yourmod均为示例前缀，必须与自己实际填写的 Key 一致。

local faction_key = "wh3_main_cth_the_northern_provinces"
local subtype_key = "yourmod_cth_lord"
local campaign_name = "main_warhammer"
local state_prefix = "yourmod_cth_lord_recruitment_"

local function add_candidate()
    local details = cm:spawn_character_to_pool(
        faction_key, "", "", "", "", 30, true,
        "general", subtype_key, false, ""
    )
    if not details or details:is_null_interface() then
        ModLog("[yourmod_lord] candidate creation failed")
        return false
    end
    ModLog("[yourmod_lord] candidate added")
    return true
end

cm:add_first_tick_callback(function()
    if cm:get_campaign_name() ~= campaign_name or cm:is_multiplayer() then
        return
    end
    local faction = cm:get_faction(faction_key)
    if not faction or faction:is_null_interface() or faction:is_dead()
        or not faction:is_human() then
        return
    end

    core:add_listener(
        "yourmod_cth_lord_first_recruit",
        "CharacterRecruited",
        function(context)
            local character = context:character()
            return character:faction():name() == faction_key
                and character:character_subtype_key() == subtype_key
        end,
        function(context)
            local member = context:character():family_member()
            local key = state_prefix .. "replaced_" .. member:command_queue_index()
            if not cm:get_saved_value(key) and add_candidate() then
                cm:set_saved_value(key, true)
            end
        end,
        true
    )

    local initial_key = state_prefix .. "seeded_" .. faction_key
    if not cm:get_saved_value(initial_key) and add_candidate() then
        cm:set_saved_value(initial_key, true)
    end
end)

代码位置	要替换或理解什么
faction_key	与派系权限行使用同一个派系 Key。本例只照顾一个派系，不是所有震旦派系。
subtype_key	新的agent_subtypes_tables.key，不是main_units_tables.unit。
campaign_name	本例只在超凡帝国工作。改战役时同时核对实际脚本战役名与该战役里的目标派系。
state_prefix和监听器名称	使用个人唯一前缀，防止和其他脚本冲突。发行后随意改状态前缀，会让旧存档被当作尚未初始化。
四个""姓名参数	依次为名、姓、家族名或称号、其他姓名。本例不强制指定固定姓名，依赖前文已经配好的姓名来源；原版普通人物调用也存在这种写法。第四项当前接口要求留空。
30和true	创建年龄与男性标记。按实际人物调整，不以它们代替姓名和模型配置。
"general"	军队领主的大类，不是英雄大类，也不是人物类型 Key。
最后的false和""	不在创建时强制赋予不朽，不指定Art Set覆盖。外观由兼容的外观记录选择；若指定外观，填campaign_character_art_sets_tables.art_set_id。
family_member()取得的编号	用来记住“这个人是否已经触发过补充”。它不是 DB 数值 ID，也不是可以事先手填的固定编号。
get_saved_value、set_saved_value	读取和保存防重复状态。普通local变量只活在本次运行里，不能替代随存档保存的状态。

本例使用 Lua 作为独立生成入口时，将新人物类型的auto_generate关闭，并保留需要的recruitable、分类和派系权限。不要改掉原版模板的生成设置。示例依赖原版姓名和外观的选择机制，必须在目标派系测试是否生成了预期姓名、性别与外观。

补充规则的适用范围

这段代码演示的是“首次加入一个，首次招募一个新人后再补一个”，不是所有普通领主系统的最终规则：

• 招募 A 后加入 B；A 解散后回来可能与 B 同时在池中。再次招募 A 不应产生 C，因为 A 已记录过补充。
• 如果另一个机制主动清空候选，单靠CharacterRecruited不会自动补回；需要为这种候选移除行为另做恢复逻辑。
• 想固定候选数量，需要能可靠统计“尚未招募、可招募、受伤、解散返回”等状态，不能拿地图上的军队数量代替候选数量。
• 想按科技、建筑、资源、任务或事件解锁，应让初始化和后续补充都经过同一套条件判断，不能只给第一次加入加锁。
• 本例主动排除多人和 AI。扩展时要核对每个目标派系、同步触发与保存状态，不能简单删除两处判断就宣布兼容。

分两步验证，别把测试入口当最终规则

先做“在一个目标派系的新战役中加入一名测试领主”，验证该人物能显示、招募、带兵并进入战斗。通过后，再完成正式的候选数量、补充频率和解锁条件。

不要为了让测试通过就每回合无条件加入一名领主；这会让招募池不断膨胀。也不要用“只在新战役执行一次”的脚本冒充能够长期补充普通领主的招募系统。

先检查游戏运行目录里的lua_mod_log.txt：本例用ModLog写入[yourmod_lord] candidate added或失败信息。日志里显示文件加载成功，只能证明加载这一层；仍须进入领主招募界面检查人物是否真的可招募。看不到日志时，先找本次启动产生的文件，不要把上一次运行的日志当成本次结果。

按“首次进入 → 招募 A → 保存读档 → 解散并再次招募 A → 招募 B”的顺序验收。预期是首次加入一次，A、B各自第一次被招募时各补一次，读档和重复招募 A 不额外补人。测试失败时先比较日志与保存状态，不要靠每回合无条件添加掩盖问题。

示例的加载方式、参数与事件接口已对照本机当前原版脚本和接口说明，但尚未完成新 Mod 的游戏内验收。它是有明确适用条件的起点，不是所有派系通用、已经实测无误的成品招募系统。

核对原版写法时，可在游戏文件中查看script/_lib/lib_mod_loader.lua的加载目录、script/_lib/lib_campaign_manager.lua的首次回调与保存状态接口，以及script/campaign/wh3_campaign_kislev_ice_court.lua中留空姓名参数的调用。这里借鉴接口用法，不复制冰雪王廷的训练规则。

派系机制和额外身份

普通领主的general权限只保证其作为军队领主的基础身份。是否能进入其他派系机制，需要额外数据：

• 忠诚度系统可能读取loyalty_is_applicable及派系规则。
• 职位系统可能需要minister身份或专用连接。
• 商队和临时远征可能使用colonel或其他内部人物大类。
• 晋升、骑士誓言、血裔、冰雪王廷训练或变身机制可能由专用表单与 Lua 共同控制。

不要把模板在这些系统里的记录全部删除，也不要无条件复制。正确做法是先写出设计目标：“新领主是否要进入这个机制”，再从同类模板追踪该机制完整的数据链。

内容包权限

模板如果出现在agent_subtype_ownership_content_pack_junctions_tables中，只读核对它关联的官方内容包。该表有特殊校验，不要导入自己的 Pack 修改，也不要通过删除、伪造记录来解除限制。

使用官方 DLC 资源或机制时，需要确认并向读者说明实际前置依赖；完全自制人物则不要无意照搬模板的 DLC 条件。不能把“给新 Key 复制一条内容包记录”写成通用的依赖配置方法。

内容包关系不是招募入口。人物被锁定时，应分开检查内容依赖和 Lua 招募条件，不要把所有锁定现象都当成招募表填错。

本地化和界面文字

至少检查以下玩家可见文本：

• 领主职业名。
• 招募分类名称和说明。
• 单位名称、短说明和长说明。
• 技能名称与说明。
• 法术、部队技能、效果和物品说明。
• 随机姓名和称号。

面向玩家的中文应以《全面战争：战锤 III》游戏内简体中文术语为准。数据库表名、字段名和 Key 保留英文以便检索，不要把 Schema 或 Assembly Kit 中的英文术语直接机械翻译成玩家名称。

使用 RPFM 的缺失本地化文本检查生成候选项后，仍要在领主招募界面、人物详情界面、技能树、战前界面和战斗兵牌中逐处确认。不同界面可能读取不同文本 Key。

怎样自行查找完整数据

1. 在游戏中选择一个招募方式、派系机制和战斗形态最接近的普通领主。
2. 从依赖项 → 游戏文件打开agent_subtypes_tables，搜索其人物类型 Key，记录associated_unit_override和recruitment_category。
3. 在游戏文件范围全局搜索人物类型 Key，把结果分成派系权限、战役外观、技能、姓名、内容包拥有条件和专属机制。
4. 在faction_agent_permitted_subtypes_tables查看全部命中，区分general和其他机制身份。
5. 搜索associated_unit_override，追踪主单位、陆战单位、战斗模型变体、实体、武器和部队技能。
6. 搜索招募分类 Key，查看目标派系已有分类的图标、排序和显示方式。
7. 搜索Art SetID，确认战役外观记录、Uniform、Portrait Settings和坐骑切换记录。
8. 搜索技能树节点集合 Key，导出全部成员节点，再搜索技能和效果引用。
9. 不论是否采用普通领主招募池，都继续追踪 Lua 的实际加载和招募入口；需要特殊条件时再追踪效果、事件或晋升机制。

全局搜索出现大量结果时，不要把所有命中都导入 Pack。先判断每条结果属于基础身份、战斗单位、战役外观、技能、招募、姓名、内容包还是专属机制，再决定是否需要。

完整制作顺序

1. 选定同派系、同招募方式、同战斗形态的普通领主模板。
2. 写好人物类型、主单位、陆战单位、招募分类、Art Set和技能树节点集合 Key。
3. 创建主单位、陆战单位和战斗模型变体，先完成单人战斗单位链。
4. 新建agent_subtypes_tables记录，将associated_unit_override指向新主单位。
5. 复用或新建招募分类，并把recruitment_category指向正确 Key。
6. 为真正的目标派系添加Agent = general权限。
7. 配置随机姓名或独立姓名组。
8. 创建Art Set和对应的战役外观记录，复用或新建Uniform，并处理Portrait Settings。
9. 创建指向新人物类型的技能树节点集合，按需复用或新建技能节点。
10. 配置法术、坐骑、物品和派系专属机制。
11. 补齐本地化文本、图标、语音和必要的内容包拥有条件。
12. 接入 Lua 招募逻辑，配置目标派系、触发条件、候选数量、后续补充和重载处理。
13. 运行 RPFM 诊断和全局搜索复查，同时检查 Lua 是否有真实调用入口。
14. 新开战役验收领主生成、招募、候选补充、带兵、升级、战斗以及保存后重新读取的结果。

常见错误

• 招募界面完全没有新领主：先检查 Lua 是否加载、条件是否满足、加入招募池的调用是否执行；再检查人物类型 Key、recruitable、招募分类和目标派系的general权限。不要只反复切换auto_generate。
• 错误地新建了agents_tables：普通领主应复用general，新建内部人物大类不会自动得到一个领主。
• 把colonel或minister当作必需项：它们可能属于派系专属机制，不是军队领主的通用权限。
• 领主只显示一个空白分类：分类的本地化文本、图标或show_in_recruitment配置不完整。
• 可招募领主没有姓名：检查names_group、姓名表、性别条件和本地化文本，不要只看人物类型的职业名。
• 可以招募但进入战斗崩溃：检查associated_unit_override、主单位、陆战单位、战斗模型变体、实体、动作、武器和模型。
• 战役地图隐形或动作错误：检查Art Set、战役外观记录、Uniform和land_animation。
• 动态头像缺失：新的Art SetID没有加入正确的Portrait Settings，或贴图路径无效。
• 技能树为空：没有指向新人物类型的技能树节点集合，或该集合没有成员记录。
• 施法者没有法术：只开启了is_caster或填写了magic_lore，没有真正授予法术。
• 骑乘后模型或动作错位：只创建了战斗坐骑单位，没有补齐战役坐骑、动作覆盖和Uniform切换。
• 意外要求某个 DLC：复制了模板的内容包拥有条件记录。
• 旧存档不出现新领主：先确认脚本是否只在新战役执行；若要支持旧存档，需单独设计初始化和防重复处理，不能期待新战役入口在旧存档再次运行。

RPFM 检查

1. 运行诊断，处理缺失引用、重复 Key、无效资源路径和缺失的本地化文本。
2. 搜索新人物类型 Key，确认至少命中目标派系的general权限、Art Set和技能树节点集合。
3. 搜索新主单位，确认人物类型、主单位、陆战单位和战斗模型变体相互指向正确。
4. 搜索招募分类，确认分类存在、显示且没有误用无关派系的专属分类。
5. 搜索每个Art SetID，确认战役外观记录、Uniform和Portrait Settings一致。
6. 搜索技能树节点集合 Key，确认成员节点数量与预期一致，并检查共享技能的限制条件。
7. 如果有坐骑，逐个搜索坐骑物品、战斗单位、campaign_mounts_tables记录、动作覆盖和Uniform切换。
8. 确认 Pack 中没有留下未改名的data__整表，也没有无关原版记录。
9. 核对 Lua 的打包路径、加载入口、派系与人物类型 Key。RPFM 的 DB 诊断通过不代表脚本已经运行。

游戏内验收

• 新领主只出现在预期派系和预期招募分类中。
• Lua 的加入条件实际生效，招募后按设计补充候选；反复读档不会重复加入，也不会永久停止正常补充。
• 领主招募池能正常生成多个可招募领主，姓名、性别、外观、等级和招募成本符合设计。
• 招募后能建立军队、增减部队、移动、驻扎、围城和进入海上状态。
• 领主职业名、单位名称、说明、头像、招募图标、兵牌和语音正确。
• 战役模型的待机、移动、转身、登船和战前表现正常。
• 技能树完整，升级、重置或特殊机制不会出现空节点和无效技能。
• 法师领主拥有预期法术，魔法之风耗费、增幅法术和冷却时间均符合设计。
• 每种坐骑都能装备、卸下并在战役与战斗中使用正确模型和动作。
• 手动战斗中的模型、动作、武器、技能、生命值、伤势和撤退表现正常。
• 保存并重新读取后，领主、军队、技能、装备、坐骑、伤势和等级保持正确。

RPFM 诊断只能发现部分表结构、引用和资源问题，不能证明招募池生成、战役模型、技能生效、派系机制或战斗动作正确。最终必须使用新开战役完成实际验收。