创建领主单位

创建时间：2026年9月4日最后更新：2026年9月4日

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

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

先选择合适的原版模板

本文使用震旦的经略使（阳系）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
            └─ 护甲、盾牌、属性、技能、接触效果与按需分支

这条链只表示普通领主的基本身份。坐骑、法术、物品、派系机制和特殊招募条件会在它外面继续增加分支。

需要哪些表单

普通领主的核心表单

表单	负责什么
`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`	把技能节点放进该技能树。

只在对应目标下添加

表单或文件	什么时候需要
`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`	确实需要官方 DLC 或内容包拥有条件时添加。不要无意复制模板的 DLC 限制。
`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 中准备数据

有两种常用方式：

在依赖项中搜索模板 Key，把需要的记录复制到新 Pack，再修改 Key。
将原版整张表导入新 Pack，立即把导入后的data__重命名为自己的表名，只保留模板行和实际要修改的行。

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

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

先创建领主的战斗单位

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

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

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

不修改的原版引用可以继续复用。复制所有被引用记录不会让领主更完整，只会增加冲突、漏改 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`	是否生成可以反复招募的普通领主。普通领主通常开启；唯一人物、事件人物和晋升获得的领主可能关闭。
`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`	人物的保存和读取方式。不要按英文猜测，复制同类普通可招募领主的当前值。
`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。这些值只证明该模板如何工作，不是所有普通领主的固定答案。

在 agent_subtypes_tables 中查看普通领主的战斗单位连接、语音组和人物设置

配置领主招募分类

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并显示在招募界面。若你创建的是另一种震旦普通领主，它可以共享该分类，也可以使用独立分类；选择取决于你希望玩家在招募界面如何区分，而不是技术上只能选一种。

在 agent_recruitment_categories_tables 中查看普通领主的招募分类

把领主交给派系

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

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

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

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

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

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

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

在 faction_agent_permitted_subtypes_tables 中区分普通领主的不同内部身份

配置随机姓名

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

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

复用派系姓名池

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

建立独立姓名池

需要独立姓名时：

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

不要直接复制传奇领主的固定姓名来充当普通领主随机姓名池，也不要只改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等直接图片字段是否需要沿用或覆盖。

复用还是新建`Uniform`

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

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

filename
battle_filename
campaign_porthole_filename
campaign_politician_filename
campaign_override_skeleton

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

配置头像和兵牌

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

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文件中。在 RPFM 的Portrait Settings编辑器里克隆对应条目，将art_set_id改为新 ID，再按需更换贴图、相机和战斗模型变体。

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

配置技能树

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

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

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

领主技能树通常包含：

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

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

配置法师领主

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

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

只开启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

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

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

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

让领主进入招募池

对许多现有可玩派系的普通领主，基本条件是：

agent_subtypes_tables.auto_generate = true
agent_subtypes_tables.recruitable = true
有有效的recruitment_category
目标派系在faction_agent_permitted_subtypes_tables中拥有general权限
姓名、战役外观和技能数据能够生成完整的可招募领主

普通领主通常不需要像英雄那样通过某座建筑的availability效果才会出现。不要为了模仿英雄招募，随便把普通领主绑到兵营。

但下面这些情况可能需要额外入口：

某种资源、科技或建筑解锁的领主。
晋升后替换原人物的高级领主。
任务、事件或仪式奖励的领主。
数量受限或特殊招募池中的领主。
脚本创建或由派系机制选择的领主。

遇到这些情况，应在游戏中找一个招募方式相同的原版领主，用人物类型 Key 和相关效果全局搜索它的真正生成入口，而不是把普通领主招募池步骤当成唯一方法。

派系机制和额外身份

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

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

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

内容包权限

模板如果出现在agent_subtype_ownership_content_pack_junctions_tables中，复制时必须判断是否真的需要相应的 DLC 或内容包拥有条件。

使用某个官方 DLC 独有资产或玩法并要求玩家拥有该内容包时，保留相应约束。
完全自制且不应要求某个官方 DLC 时，不要因为复制模板而保留内容包拥有条件记录。
使用官方 DLC 资产但不确定发布要求时，先按需要该 DLC 处理，不要把锁定现象误判成招募数据失效。

内容包拥有条件记录不会把领主加入招募池，它只负责判断玩家能否使用相应内容。

本地化和界面文字

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

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

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

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

怎样自行查找完整数据

在游戏中选择一个招募方式、派系机制和战斗形态最接近的普通领主。
在agent_subtypes_tables搜索其人物类型 Key，记录associated_unit_override和recruitment_category。
全局搜索人物类型 Key，把结果分成派系权限、战役外观、技能、姓名、内容包拥有条件和专属机制。
在faction_agent_permitted_subtypes_tables查看全部命中，区分general和其他机制身份。
搜索associated_unit_override，追踪主单位、陆战单位、战斗模型变体、实体、武器和部队技能。
搜索招募分类 Key，查看目标派系已有分类的图标、排序和显示方式。
搜索Art SetID，确认战役外观记录、Uniform、Portrait Settings和坐骑切换记录。
搜索技能树节点集合 Key，导出全部成员节点，再搜索技能和效果引用。
如果模板不是普通领主招募池中的领主，继续搜索它的效果、事件、晋升表或 Lua 入口。

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

完整制作顺序

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

常见错误

招募界面完全没有新领主：检查auto_generate、recruitable、recruitment_category和目标派系的general权限。
错误地新建了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 检查

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

游戏内验收

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

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