创建传奇领主单位

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

先分清人物配置和招募接入

传奇领主首先是一名完整领主：需要战斗单位、人物类型、技能树、战役模型、头像、姓名和派系权限。但把这些表填好，只是定义了这名人物，不等于玩家已经能够招募它。

本文新增传奇领主的招募方式由 Lua 控制。表单配置“这个人是什么”，Lua 决定“什么时候、向哪个派系的招募池加入这个人”。固定姓名、不朽、唯一性、解锁条件和再次招募也要分别处理，不能用一个“传奇”分类代替全部逻辑。

本文不使用、导入或编辑 Assembly Kit 的开局表，也不把它们列为 RPFM 制作步骤。现有派系的可招募传奇领主是主要目标；地图上的初始人物和新战役界面的可选领袖属于另外的接入目标，不能靠增加普通 DB 行就宣称完成。

先确定玩家最终在哪里看到这名领主

目标	必须完成的接入	不应混入的内容
加入现有派系的领主招募池	Lua 判断派系与条件，再加入固定人物；检查唯一性、重载和受伤后的处理。	不需要为此增加新战役界面的领袖记录。
在战役地图上带领军队出现	Lua 创建或接入地图人物与军队；检查位置、时机、派系和原有脚本冲突。	不能把“加入招募池”误当成“已经生成一支地图军队”。
在新战役界面作为派系领袖展示并进入战役	展示资源、界面记录以及实际战役入口必须一致。本文只解释其中能在 RPFM 中配置的展示部分，不提供完整的可玩派系制作流程。	单改图片或`frontend_faction_leaders_tables`不会完成实际领袖替换。

传奇领主没有单一“传奇开关”

recruitment_category = legendary_lords是招募界面分类，不保证只出现一个人。
auto_generate是人物类型的生成相关标记，不是新增领主的完整招募入口。
不朽决定人物死亡、受伤与后续恢复相关行为；唯一性是另一件事。
派系领袖是战役中的职位，不等于“有一套专属技能”或“在界面上显示为传奇领主”。
unique_agents_tables不是所有传奇领主都要填写的通用开关。是否使用特定系统，必须看实际调用入口。

本文以『飙龙』妙影wh3_main_cth_miao_ying说明传奇领主的 DB 连接。截图是原版只读数据，用于认识字段与引用，不是“复制妙影全部记录后即可招募”的成品演示。

选择模板时要分层

传奇领主往往带有变身、专属坐骑、特殊法术、剧情、资源和派系机制，直接复制整套数据很容易把无关系统带进 Mod。最好为不同层分别选模板：

层级	模板选择依据
战斗单位	相同体型、骨骼、武器、坐骑和战斗职能。
战役人物	相同文化、语音、姓名结构和战役模型类型。
技能树	相同战斗定位、魔法之风和军队强化方向。
招募接入	相同的 Lua 触发条件、目标派系和人物加入方式。
新战役界面中的派系领袖	相同战役、同类派系选择界面和展示资源结构。
专属机制	只有设计确实需要该机制时才选对应模板。

例如，『飙龙』妙影适合演示“可选派系领袖如何接入多个战役”，但她的龙形态和震旦机制不适合作为普通人形传奇领主的战斗模板。

数据与脚本接入链

传奇领主基础数据
agent_subtypes_tables
    ├─ associated_unit_override ─→ main_units_tables → land_units_tables
    ├─ faction_agent_permitted_subtypes_tables（军队领主使用 general）
    ├─ campaign_to_agent_subtypes_tables（按实际目标战役和模板判断）
    ├─ character_skill_node_sets_tables → character_skill_node_set_items_tables
    └─ campaign_character_art_sets_tables
            └─ campaign_character_arts_tables → agent_uniforms_tables

Lua 招募接入
目标战役与派系 + 触发条件 + 防重复状态
    └─ 向领主招募池加入指定人物类型
            ├─ 固定姓名与 Art Set
            ├─ 不朽和唯一人物处理
            └─ 招募、受伤恢复、重载后的身份保持

按需配置的新战役界面展示（不是招募入口）
frontend_faction_leaders_tables
    ├─ agent_subtype_record / faction
    └─ Composite Scene、图片、文本、语音和影片

需要哪些表单

人物基础表单

表单	负责什么
`agent_subtypes_tables`	定义传奇领主类型、关联战斗单位、招募分类、招募成本、语音和生成设置。
`faction_agent_permitted_subtypes_tables`	允许目标派系使用该人物类型。作为军队领主时使用内部人物大类`general`。
`main_units_tables`	定义单人领主的主单位、人数、单位分类、战斗伤势与战役人物状态的衔接，以及动态头像镜头。
`land_units_tables`	定义战斗实体、动作、武器、防护、属性、部队技能和数值。
`unit_variants_tables`	把主单位连接到战斗模型变体。
`campaign_character_art_sets_tables`	把`Art Set`（战役外观配置）分配给传奇领主类型。
`campaign_character_arts_tables`	配置战役模型、战役动作、海上状态和条件变体。
`character_skill_node_sets_tables`	把技能树分配给该人物类型。
`character_skill_node_set_items_tables`	把具体技能节点放进技能树。
`names_tables`	提供固定姓名或称号使用的数值 ID 和本地化文本入口。

招募与其他接入需要的文件

文件或连接	负责什么
本 Mod 独立命名的战役 Lua 文件	必需。执行派系、时机、解锁条件和防重复判断，并加入新传奇领主。
姓名本地化与实际生成调用	向生成接口传入正确的姓名，而不是只改职业文字。
`frontend_faction_leaders_tables`	仅在修改新战役界面展示时处理，不负责把人物加入领主招募池。
`faction_starting_general_effects_tables`	与初始领主相关的效果包连接。脚本新建的可招募人物不能假定自动获得相同效果，需要核对实际授予入口。

这里的 Lua 不是可选的“后续扩展”。没有已经接入并实际执行的招募逻辑，不能把只完成 DB 的成果称为可招募传奇领主。

只在相应功能存在时添加

表单或文件	什么时候需要
`agent_recruitment_categories_tables`	新建独立的传奇领主分类时添加；也可以复用原版`legendary_lords`。
`campaign_to_agent_subtypes_tables`	模板按战役列出人物类型时，为每个目标战役添加相应记录。可玩传奇领主中较为常见。
`agent_uniforms_tables`	使用新战役模型、动态头像模型或战役骨骼时添加。
`portrait_settings.bin`	新的`Art Set`需要动态头像构图和贴图变体时编辑。
`campaign_character_art_set_porthole_overrides_tables`	需要专用动态头像场景时添加。
`campaign_mounts_tables`及坐骑相关连接	有可切换坐骑或变体时添加。
`agent_subtype_ownership_content_pack_junctions_tables`	只读核对原版内容包关系；该表存在特殊校验，不作为普通自定义表导入修改。
`effect_bundles_tables`及相关效果表	初始领主特性、专属效果、招募条件和派系机制需要时添加。
`unique_agents_tables`	只有采用该表支持的特殊唯一人物生成系统时添加，不能把它当成所有传奇领主的必填表。

规划唯一 Key 和数值 ID

以下只是命名结构示例：

传奇领主类型：yourmod_cth_legendary_lord
主单位：yourmod_cth_cha_legendary_lord_0
陆战单位：yourmod_cth_cha_legendary_lord_0
战斗模型变体：yourmod_cth_cha_legendary_lord
战役外观配置：yourmod_art_set_cth_legendary_lord
技能树节点集合：yourmod_skill_node_set_cth_legendary_lord
新战役界面派系领袖记录：yourmod_political_party_cth_legendary_lord
初始领主特性效果包：yourmod_lord_trait_cth_legendary_lord

部分 DB 记录还需要数值 ID，例如campaign_character_arts_tables.id和姓名记录的 ID。新增记录的主键必须在对应表中唯一；先在当前 Pack 和游戏文件中搜索确认，不能复制后保留原 ID。

人物类型 Key、主单位 Key、外观 Key、姓名本地化 Key 和脚本运行时取得的人物标识不是同一类东西。Lua 参数需要哪一种，就传哪一种，不要因为都叫“ID”而混用。

在 Pack 中准备表单

先新建自己的 Mod Pack。本文 DB 截图都从依赖项 → 游戏文件打开，数据页签以Game-RO:开头；它们是原版模板，不是已编辑的新人物。

复制数据可以使用两种方式：

在游戏文件查找模板行，在自己的 Pack 新建同类型 DB 文件，再复制需要的行。
从游戏文件导入所需原版 DB 文件到自己的 Pack，先将文件名data__改成带个人前缀的名称，再选中需要的行，反选并删除其他记录。

重命名的是db/表类型/下面的 DB 文件，不是表类型文件夹。不改data__等原版文件名，可能造成同路径覆盖；即使改了文件名，保留原版记录主键仍可能覆盖原记录。新建人物要同时处理文件名和需要独立的新 Key。

不要从Assembly Kit 文件或db.pack导入模板。每处理完一个表，确认 Pack 中只留下本 Mod 新建或明确修改的记录；Lua 也使用独立文件，避免整份覆盖原版脚本。

先完成基础领主

招募池人物和地图人物都建立在一名完整领主之上。先按照《创建领主单位》完成：

单人main_units_tables记录，num_men = 1且caste = lord。
独立或复用的land_units_tables、战斗模型变体、实体、动作、武器和属性链。
agent_subtypes_tables记录及associated_unit_override。
目标派系的Agent = general权限。
Art Set、战役外观记录、Uniform和Portrait Settings。
指向新人物类型的技能树节点集合。
本地化、兵牌、头像、语音、法术和坐骑。

先用最小 Lua 测试入口加入一名人物，分开验证招募、外观和战斗。基础领主尚不能正常显示或进入战斗时，不要叠加复杂解锁和新战役界面改动，否则难以定位故障。

配置传奇领主的人物类型

从游戏文件中复制用途接近的传奇领主人物类型记录，逐列检查。『飙龙』妙影的原版记录可供比较，但不能把原版开局人物的完整运行环境理解成新人物自带的功能。尤其要将人物类型的配置与 Lua 招募调用分开核对。

字段	传奇领主的处理原则
`key`	新传奇领主唯一的人物类型 Key。
`auto_generate`	使用 Lua 控制唯一人物时通常关闭，避免额外的自动生成路径；关闭本身既不会加入人物，也不等于已经实现防重复。
`onscreen_name_override`	领主职业文字。原版传奇领主常在这里显示“传奇领主”，而非具体姓名；固定人名来自其他数据。
`is_caster`	是否标记为施法者。不会自动授予法术。
`associated_unit_override`	指向默认战斗形态的主单位。
`audio_voiceover_actor_group`	战役地图上的领主语音组。没有自制语音时复用兼容的原版语音组。
`show_in_ui`	是否在相关界面显示。
`cap`	人物类型自身的限制值，不是唯一身份开关。
`has_female_name`	姓名生成相关标记。固定姓名人物仍应使用相符模板。
`can_gain_xp`	是否获得人物经验。
`loyalty_is_applicable`	是否参与忠诚度。许多传奇领主不使用忠诚度，但应按派系机制确认。
`contributes_to_agent_cap`	是否计入相应内部人物大类的数量限制，不负责保证固定人物只出现一次。
`names_group`	传奇领主通常不用普通随机姓名池，但不要仅凭直觉填写，按同路线模板处理。
`recruitment_category`	常复用`legendary_lords`，也可以创建专用分类。分类不会保证唯一。
`magic_lore`	魔法之风或施法分类引用。实际法术来自技能、部队技能、物品或特殊机制。
`can_be_loaned`	是否参与内部的人物借调流程。游戏没有统一显示这一字段的名称，应沿用同路线模板。
`recruitable`	是否允许进入相关招募流程。战役开局已经存在的传奇领主，也可能保留开启值用于复活或其他流程。
`saving_settings`	人物保存与导入功能的权限配置，具体三项见下表；不控制战役存档读取，也不保证人物唯一。
`can_equip_ancillaries`	是否能装备物品。
`cost`	招募成本基础值。开局人物也可能在复活或特殊招募时读取。

在 Game-RO 人物类型表中查看『飙龙』妙影的 Key、生成标记和默认战斗单位

图中分别标出人物类型 Key、Auto Generate与Is Caster、Associated Unit Override。人物类型与战斗单位的 Key 不相同；复制新人物时要把引用改到自己的主单位。其他字段位于横向滚动后的列中。

`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`

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

招募分类

可以让新传奇领主使用原版legendary_lords分类，也可以新建独立分类：

复用原分类适合希望它和其他传奇领主显示在同一分组的情况。
新分类适合需要独立名称、图标和排序的特殊领主池。

不要把“出现在传奇领主分类”误认为“已经是唯一人物”。唯一性仍要由 Lua 的实际生成、防重复和人物身份处理保证。

传奇分类和原版字段可以直接怎样核对

agent_recruitment_categories_tables.key=legendary_lords这条原版记录使用order=0、icon_file_path=UI\Common UI\unit_category_icons\commander.png，show_in_recruitment=true、counts_towards_caps_when_off_the_map=true。对应 Loc 为agent_recruitment_categories_onscreen_name_legendary_lords。如复用它，Subtype 直接填legendary_lords，不必复制分类定义。

需要其他分类时，创建领主单位已列出全部 86 项的准确 Key、官方名称、排序和显示开关。创建自己的传奇分类时，复制此记录换为yourmod_legendary_lords，添加agent_recruitment_categories_onscreen_name_yourmod_legendary_lords；Subtype 的分类引用也要同步换新 Key。

原版妙影的 Subtype wh3_main_cth_miao_ying使用associated_unit_override=wh3_main_cth_cha_storm_dragon_0、cost=2700、cap=-1、auto_generate=false、is_caster=true、has_female_name=true。show_in_ui、can_gain_xp、contributes_to_agent_cap、recruitable、can_equip_ancillaries为true；loyalty_is_applicable、can_be_loaned为false，magic_lore与names_group为空。这些值供核对模板，不会自动为新人物带来妙影的法术、固定姓名和变身能力。

军队领主的 Agent 仍填general。其他八类champion、dignitary、engineer、runesmith、spy、wizard、colonel、minister不是“传奇等级”；不要为了传奇身份另外挑一种大类。

配置战斗单位、专属部队技能和形态

传奇领主的战斗单位与普通领主使用同样的基础表，但通常更容易出现专属分支：

独立battle_entities_tables记录和更高的实体生命值。
独立近战武器、远程武器、投射物、爆炸或接触效果。
专属unit_abilities_tables部队技能及其阶段。
独立属性组、抗性、魔法攻击和战斗 AI 定位。
多种坐骑、变身或替换主单位。
战役生命值、受伤与复活的特殊规则。

不要把传奇领主较高的面板数值全部堆在land_units_tables中。先判断数值来自单位基础值、技能、物品、效果包（Effect Bundle）还是派系机制；否则新领主可能在战役开始时表现正常，升级后却发生重复叠加。

多形态和变身人物

『飙龙』妙影同时具有人形与龙形相关数据。若新传奇领主不能变身，就不要复制她的化龙诀、额外单位、专属部队技能、动作和脚本引用。若确实要制作变身人物，则至少要追踪：

每种形态的main_units_tables和land_units_tables。
每种形态的战斗模型变体、骨骼、动作、实体和武器。
触发变身的部队技能及其阶段。
变身前后的技能、法术、生命值和冷却规则。
战役地图、动态头像、战前界面和存档读取时使用的形态。

复杂变身往往不只是 DB 数据。没有找到原版完整入口前，不要把“复制两套单位”写成已经完成。

配置专属技能树

传奇领主应至少拥有一个指向新人物类型的character_skill_node_sets_tables记录。可以先复用通用领主节点，再添加专属技能，但要检查共享节点中的限制条件。

复用普通领主主干

新建独立的技能树节点集合。
agent_key使用general。
agent_subtype_key指向新传奇领主人物类型。
复制通用领主节点集合的成员记录，只修改set。
检查每个节点引用的技能是否按派系、亚文化、兵种集合或人物类型限制。

在 character_skill_node_sets_tables 中确认专属技能树集合和传奇领主人物类型

图中：① Key是技能树节点集合 Key；②传奇领主仍属于general内部人物大类；③ Agent Subtype Key把这套技能树交给具体传奇领主。传奇身份不会自动生成独立技能树，必须依靠这条连接和节点集合成员明确分配。

添加专属技能

专属技能通常需要：

character_skills_tables
    └─ character_skill_level_to_effects_junctions_tables

character_skill_nodes_tables
    ├─ character_skill_node_links_tables
    └─ character_skill_node_set_items_tables

创建传奇领主时应确认：

专属技能不会出现在其他普通领主树中。
技能效果的Scope（作用对象）确实指向人物、军队、派系或地区中的预期对象。
专属兵种强化使用正确的兵种集合，而不是模板派系的旧兵种集合。
法术节点真正授予目标法术，并包含增幅法术需要的后续节点。
坐骑节点连接到新传奇领主可用的坐骑链。
开局技能点和创建时自动获得节点符合设计。

在 character_skill_level_to_effects_junctions_tables 中查看人物技能等级实际提供的效果

图中：① Character Skill Key指向人物技能；② Effect Key指向实际效果；③ Level、Effect Scope和Value分别表示技能等级、作用对象与数值。这里筛选同一技能的两个等级，便于比较同一个效果如何分别配置；不是所有专属技能都只修改护甲，也不是所有等级都只连接一条效果。

配置固定姓名

传奇领主的职业名、战斗单位名和个人姓名不是同一项文本：

agent_subtypes_tables.onscreen_name_override常表示“传奇领主”这一人物类型。
单位本地化负责战斗单位名称。
Lua 创建人物时使用的姓名参数负责这次创建的个人姓名。
新战役界面的介绍和加载文字还可能使用另外的本地化 Key。

先找一名采用相同生成接口的原版人物：从游戏文件中的姓名记录和 Loc 查到其姓名，再查看 Lua 调用实际传入什么。不要把要求本地化 Key 的位置填成中文姓名，也不要把数值 ID、names_name_…形式的 Key 和人物类型 Key 混用。不同函数的姓名参数不能仅因名称相似就照抄。

为新人物建立独立姓名数据和本地化文本，并把新 Key 接到实际生成调用。不要直接修改模板人物的姓名本地化，否则原人物也会一起改名。生成后分别检查领主招募界面、人物详情界面、外交和战斗界面；职业名正确不代表个人姓名正确。

如果目标接口文档与当前原版调用写法存在差异，先以当前 WH3 的实际调用核对，再进行游戏测试，不凭旧版教程补一个看似合理的参数。

配置战役模型和头像

传奇领主通常只需要一套固定的Art Set，但这不是强制规则。基础数据链为：

campaign_character_art_sets_tables.agent_subtype
    → campaign_character_art_sets_tables.art_set_id
    → campaign_character_arts_tables.art_set_id
    → campaign_character_arts_tables.uniform
    → agent_uniforms_tables

制作时检查：

campaign_character_art_sets_tables.agent_type通常为general。
art_set_id是新 Key。
campaign_character_arts_tables.id是唯一数值 ID。
uniform、land_animation和海上状态引用合法。
战役缩放和战前模型偏移适合人物体型。
新的Art Set已加入相应portrait_settings文件。
战斗兵牌、人物头像、人物信息界面和新战役界面使用的人物图片分别有正确资源。

当前『飙龙』妙影只有一套核心Art Set，而普通震旦领主模板可以有多套随机Art Set。这个差异体现的是“固定人物外观”和“随机招募人物外观”，不是传奇领主必须只有一套的硬性规则。

在 campaign_character_arts_tables 中查看传奇领主的战役外观配置

图中：① Art Set Id连接战役外观配置；② Level、Age和Season是要核对的条件，Portrait是头像相关字段，不能把它当作与等级、年龄相同的条件；③ Uniform引用实际外观资源。图片仅显示横向字段的一部分，仍需检查右侧动作、海上状态等引用。

固定外观不必从空表猜值

妙影对应art_set_id=wh3_main_art_set_cth_miao_ying。Art Set 中agent_type=general、agent_subtype=wh3_main_cth_miao_ying、is_male=true、is_custom=false、campaign_map_scale=1、prebattle_separation_offset=0，文化、亚文化和派系为空。这里的is_male=true是当前原版实际记录，不能因此把官方女性人物称为男性，也不能据姓名开关擅自“纠正”原模板；战役外观条件与姓名生成需要分别核对。

Arts 行使用level=0、age=0、season=none，uniform=wh3_main_uniform_cth_miao_ying，陆地动作cam_hu1e_mage_storm_dragon；海上与海军 Uniform 均为wh3_uniform_cth_ship_lord，动作均为cam_cathayship_01。portrait、card、info为空，三个 VFX 过滤值为0。新建独立人物时换自己的 Art Set Key 与新整数 ID，并继续复用兼容资源；原行 ID 2002987788只用来定位，不能复制为新行 ID。

只保留这一套 Art Set 还要在后文生成调用的外观参数中引用新 Key，并处理对应 Portrait Settings。改变 Uniform 或骨骼后，原动作和头像场景不保证兼容，须回到模型制作与实际界面验收。

按目标战役添加人物类型记录

当前大量可玩传奇领主出现在campaign_to_agent_subtypes_tables中。『飙龙』妙影分别有wh3_main_chaos和wh3_main_combi记录。

若新传奇领主要支持多个战役：

搜索同一模板人物类型的全部campaign_to_agent_subtypes_tables记录。
只为你实际支持的战役复制相应行。
将agent_subtype改为新人物类型 Key。
为每个战役分别检查 Lua 是否加载、目标派系是否存在，以及新人物的招募调用是否实际执行。

不要只添加campaign_to_agent_subtypes_tables就认为传奇领主已经进入战役；这张表只是战役与人物类型之间的一项连接，不能代替派系权限和 Lua 招募逻辑。

在 campaign_to_agent_subtypes_tables 中查看『飙龙』妙影分别接入两个战役

支持两个战役时的明确行值

`campaign_type`	`agent_subtype`
`wh3_main_chaos`	`yourmod_cth_legendary_lord`
`wh3_main_combi`	`yourmod_cth_legendary_lord`

这是从妙影原版两条连接替换 Subtype 后的示例。只支持超凡帝国时保留第二行即可。下面 Lua 示例检查的运行时名称是main_warhammer，不能把这一字符串填进 DB 的campaign_type列，也不能只加第一行就声称同一段示例脚本已经支持另一战役。

若仍选择卫北列省，派系权限填faction=wh3_main_cth_the_northern_provinces、agent=general、subtype=yourmod_cth_legendary_lord、mod_disabled=false；Lua 目标派系也使用同一个完整派系 Key。

用 Lua 把传奇领主加入招募池

这一步不是再填写一张 DB 表，而是让脚本向目标派系的领主招募池加入已经配置好的人物。cm:spawn_character_to_pool(...)是需要查找的接口线索；它负责加入人物，但不替你决定解锁方式和防重复规则。

先做最小接入，再增加解锁条件

先选一个现有派系和一个目标战役，确认新人物的派系权限、职业、战斗单位、技能树、姓名和外观已经连好。
在游戏文件的全局搜索中启用文本搜索，查找spawn_character_to_pool和模板人物类型 Key，找到当前原版的调用。
顺着函数名继续搜索，确认它由哪个初始化或事件入口执行。只有函数定义、没有实际调用，不会加入任何人物。
在本 Mod 独立命名的 Lua 文件中接入逻辑，将目标派系和人物类型换成自己的数据，并按接口要求传入姓名、性别、不朽设置和外观。
先验证新战役中能加入一名、招募一名，并能带兵进入战斗；再添加任务、科技、资源、建筑、事件等正式解锁条件。

这里的条件只是可选设计，不是“只能通过任务解锁”或“只能第一回合加入”。选哪一种，取决于想让玩家怎样获得这名领主。

在当前游戏的只读 Lua 中查看科技完成事件与加入领主招募池的调用

图中是当前游戏文件中的script/campaign/wh2_campaign_tech_tree_lords.lua。文件名沿用wh2前缀，不代表这张图来自旧版 RPFM 或另一款游戏。①检查研究事件、科技 Key 与玩家派系；②将相应姓名和人物类型传给招募接口。这只是说明“条件与创建调用如何相连”的原版片段，不是让你整份导入，也不是说传奇领主只能靠科技解锁。

每个参数与状态都要区分

项目	要确认什么
目标派系	传入`factions_tables`中的派系 Key，不是文化、亚文化或战役名。
人物大类	加入军队领主时使用`general`。
人物类型	传入新的`agent_subtypes_tables.key`，不是主单位 Key。
姓名	核对当前调用要求的姓名标识形式，并确保中文本地化存在。
外观	使用属于该人物类型、条件匹配且资源完整的`Art Set`；空值是否合适按当前原版调用判断。
不朽	与唯一性分开配置，不能把“不朽”理解成“绝不会重复创建”。
执行时机	不能在战役对象尚未可用时访问它们；使用适合的初始化或事件入口。
防重复	成功加入后的状态需要随存档保持，不能每次读档再次加入同一人物。
多派系和多人	明确是每个派系一名，还是整局唯一；不能在两个玩家的入口各自创建一次。

接口签名与参数可对照WH3 人物加入招募池接口。姓名写法还要对照当前原版 Lua，不能仅凭接口里简略的“姓名 ID”说明直接填整数。

准备固定姓名和脚本文件

本例用于单人超凡帝国中一个由玩家控制的现有派系，新增一名独立人物。它不替换原派系领袖，也不把原版已经存在的妙影再创建一次。

在自己的names_tables中建立新姓名记录。保留同文化、同姓名用途模板的有效关联，只为新记录选择未被占用的数值 ID。
为这条记录建立对应的names_name_姓名ID本地化文本，填写自己设计的人名。用 RPFM 的本地化检查核对实际生成的 Key，不要改原版姓名。
确认新人物的Art Set、派系权限、招募分类、战斗单位与技能树已完成。
新建 UTF-8 文本yourmod_cth_legendary_recruitment.lua，将下面代码放入其中。
按《创建领主单位》的添加方法，将它加入自己的 Pack，最终内部路径为script/campaign/mod/yourmod_cth_legendary_recruitment.lua。不要额外套一层data或教程文件夹。

例如，你查重并建立的姓名 ID 是2070900001，对应 Key 就是names_name_2070900001。下面的数字只是演示，不是已经替你确认未占用的保留号段；必须替换为自己实际创建的记录。

一次加入与招募后设置的完整示例

local faction_key = "wh3_main_cth_the_northern_provinces"
local subtype_key = "yourmod_cth_legendary_lord"
local forename_key = "names_name_2070900001"
local art_set_key = "yourmod_art_set_cth_legendary_lord"
local created_key = "yourmod_cth_legendary_lord_created"

cm:add_first_tick_callback(function()
    if cm:get_campaign_name() ~= "main_warhammer" 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_legendary_lord_recruited",
        "CharacterRecruited",
        function(context)
            return context:character():character_subtype_key() == subtype_key
        end,
        function(context)
            local lookup = cm:char_lookup_str(context:character())
            cm:set_character_unique(lookup, true)
            cm:set_character_immortality(lookup, true)
            ModLog("[yourmod_legendary] recruited character configured")
        end,
        true
    )

    if cm:get_saved_value(created_key) then
        return
    end
    local details = cm:spawn_character_to_pool(
        faction_key, forename_key, "", "", "", 30, false,
        "general", subtype_key, true, art_set_key
    )
    if details and not details:is_null_interface() then
        cm:set_saved_value(created_key, true)
        ModLog("[yourmod_legendary] candidate added")
    else
        ModLog("[yourmod_legendary] candidate creation failed")
    end
end)

这段代码有三层，不能只复制中间那一行：

层级	具体工作	不负责什么
`add_first_tick_callback`	在战役对象可用后检查战役与目标派系。新战役和读档都能登记监听器。	不是每回合自动运行，也不等于只在新战役运行。
`created_key`与`spawn_character_to_pool`	未成功加入过时创建一次；取得有效人物资料对象后保存状态，避免读档重复加入。	不扫描整个世界，也不会自动修复其他 Mod 已造成的重复人物。
`CharacterRecruited`监听器	招募后拿到地图人物，构造人物查询字符串，再设置唯一身份和不朽。	不创建第二个人，不把招募池返回的资料对象误当成地图人物。

本例的false性别参数表示女性，true不朽参数表示创建时赋予不朽；应与自己的人物、姓名与模型匹配。Art Set必须已经属于新人物类型，不能把Uniform、主单位 Key 或图片路径填到这里。需要姓氏或称号时，按同一接口的参数顺序填写已经存在的姓名 Key。

created_key在本例中是整局唯一的状态名，不按派系分别创建人物。不要在加入第二个目标派系时简单复制一套新的状态名，否则会允许两个派系各造一个同类型人物。监听器按新人物类型判断，方便这个人物之后改变所属派系时仍识别其身份；本例没有实现跨派系获取它的条件。

这份示例以全新人物类型开始验收。如果旧版 Mod 已经创建过同类型人物，却没有这份保存状态，直接换上脚本仍可能多加一个；不要删除状态或改状态名来“刷新”已有传奇领主。迁移旧存档需要单独识别既有人物。

把无条件加入改为正式解锁

上面是在首次有效加载时加入人物，适合先验证基础数据。若设计需要科技、任务、建筑、资源或其他条件：

找到目标条件的实际事件和查询方式，例如原版科技解锁人物脚本中的ResearchCompleted。
把“检查状态 → 加入人物 → 成功后保存状态”集中成一个函数，不在多个监听器里分别复制一份创建逻辑。
在事件回调中先确认派系和目标条件，再调用该函数。
在首次加载时也核对条件是否已经完成，避免安装 Mod 前已经研究完科技的存档永远等不到相同事件。
保留招募后的人物身份设置，并逐项测试重复事件、读档和条件已经满足的情况。

只给一个事件添加监听器，不等于所有旧存档和派系都已经支持。不同条件的查询接口不同，不能把科技 Key 改成建筑 Key 就当作同一个检查。

查看运行结果

游戏运行目录中的lua_mod_log.txt应能找到本例的[yourmod_legendary] candidate added，招募后还应出现recruited character configured。前者表示加入调用返回了有效资料对象，后者表示招募监听器执行过；日志都不能代替对头像、技能、战斗和受伤恢复的实际检查。

按“首次加载 → 保存读档 → 招募 → 保存读档 → 受伤恢复 → 再次招募”测试。读档不应再写入新的加入成功记录；人物恢复时也不应通过再次调用创建接口换成一个等级、装备全新的复制品。

加载方式、函数参数、返回对象与监听事件已对照当前游戏脚本及接口说明；这份新人物示例尚未通过游戏内验收。唯一身份与不朽设置不是对所有派系机制、合邦、旧存档和多人兼容的保证。

固定姓名与不朽参数的原版调用可在当前游戏的script/campaign/wh3_main_chaos/wh3_boris.lua中核对；该文件属于它自己的战役流程，只用于对照接口，不是让超凡帝国 Mod 导入整份脚本。加载与状态保存的依据仍是前文提到的原版脚本库。

唯一性不是一个勾选框

至少要同时检查：

普通自动生成路径是否还会创建同一人物类型。
Lua 是否只在设计条件成立且尚未加入时执行。
成功加入后的记录是否会随存档保存，读档后是否还能识别。
人物已经在招募池、已经带兵、正在受伤恢复时，是否会被误判成“还没有生成”。
原人物恢复时是否被错误地再创建了一个新人物，导致等级、装备和技能丢失。

游戏还提供set_character_unique与set_character_immortality等人物处理接口，但它们不是任意招募函数返回值都能直接调用的开关。先确认当前接口返回的是哪类对象、是否已经取得可用的人物标识，再按实际流程处理；不能硬写一个假定存在的编号。

只做“打开新战役时加入一次”不等于完成受伤恢复、后续招募和多人兼容。没有相应脚本与游戏验收时，要明确这些部分尚未完成，不能仅凭 RPFM 诊断无报错宣布成功。

如果要让人物直接带兵出现

加入招募池与创建地图军队是不同接口和不同结果。需要地图人物时，可从当前原版脚本中的cm:create_force_with_general(...)追踪具体实现；确认派系、人物类型、军队单位、位置和调用时机，再处理创建成功后的技能、效果与不朽等设置。

先判断是“给现有派系额外添加一支军队”，还是“替换原派系领袖”。后者还会影响任务、镜头、外交和派系机制，不能创建新人物后就直接删除旧人物。也不能把一个战役的坐标照搬到另一个战役。

本篇不把地图生成和可玩派系入口写成几张表的填写步骤，也不在这里扩展独立的开局制作流程。需要这类结果时，要将其作为单独的脚本接入目标验收，不能与招募池版本混算完成。

新战役界面展示与实际人物不是一回事

frontend_faction_leaders_tables用于研究和配置新战役界面的领袖展示。只想增加可招募传奇领主时，跳过这一节；它不会帮你把人加入领主招募池。

如果确实需要替换现有派系的领袖展示，下面只说明可在游戏 DB 中核对的字段。界面上能看到新图片，不表示实际战役里的派系领袖已经变成了新人，完整接入必须另行验证。

创建`frontend_faction_leaders_tables`记录

该表负责新战役界面的领袖展示。复制同一目标战役中结构最接近的派系领袖记录，逐项检查：

字段	作用
`key`	新战役界面派系领袖记录的唯一 Key。新增一个 Key 本身不会建立可玩的战役入口。
`uniform`	派系选择界面使用的`Composite Scene`路径，不是战役地图上的`Uniform`。
`x_offset`、`y_offset`	派系选择界面中人物构图的偏移。
`character_image`	派系领袖静态图片。
`prelude_battle`	序章战斗引用。没有相应序章战斗时，不应复制模板中的无关值。
`localised_description`、`frontend_description`	派系选择界面的人物说明文本入口。实际使用哪一项，应按同战役模板和本地化文本验证。
`localised_action_points`	派系选择界面中说明文字使用的文本入口。
`game_expansion_key`	该记录所属游戏或扩展的分类。
`video`	派系选择界面影片。没有新影片时不能填一个不存在的路径。
`loading_screen_text`、`loading_screen_image`、`loading_screen_intro_video`	加载界面的文字、图片和影片。
`override_force_location_x`、`override_force_location_y`	派系选择界面或初始军队位置的覆盖值。应按模板处理，不能代替战役地图开局坐标。
`voiceover`	派系选择界面的人物语音。
`show_full_intro_option`	是否显示完整开场选项。需要对应内容支持。
`difficulty`	该界面记录使用的难度或模板条件。复制目标战役现有模式，不要自行生成四条难度记录。
`startpos_map`	使用哪个开局地图 Key。不同战役或派系选择模式可能不同。
`agent_subtype_record`	指向新传奇领主的人物类型 Key。
`faction`	指向目标派系的字符串 Key，不是人物类型或数值编号。

『飙龙』妙影在不同战役的新战役界面中使用不同的记录 Key，并分别连接同一个人物类型。要支持多个战役，应从每个战役对应的模板复制，而不是把一条记录同时当成所有战役入口。

在 frontend_faction_leaders_tables 中查看『飙龙』妙影在新战役界面使用的模型和头像记录

图中按the_northern_provinces筛选出两条记录。①是展示记录 Key，②是场景路径，③是静态图片路径。若只搜索miao_ying，还可能命中复用同一场景的其他人物；必须核对具体字段与所属派系，不能把所有命中都当成妙影本人的记录。

分别验收展示与实际进入战役

先检查界面中的人物、说明、图片和资源，再进入对应战役核对实际人物类型、派系、位置和军队。若只是展示改了，实际人物没变，说明缺的是战役接入，不能继续往 Pack 里补不能由 RPFM 编辑的开局表。

支持多个战役时，每个战役独立验证。不要以一个战役的展示成功推断另一个战役也完成。

配置初始领主特性

faction_starting_general_effects_tables可以把一个效果包交给特定的初始领主人物类型。当前『飙龙』妙影的记录会为她提供wh3_main_lord_trait_cth_miao_ying。

要创建独立的初始领主特性：

新建或复制effect_bundles_tables记录。
配置效果包中的实际效果。
在faction_starting_general_effects_tables.agent_subtype填写新人物类型 Key。
在effect_bundle填写新效果包 Key。
为特性名称和说明补充本地化文本。

对于 Lua 加入招募池的新人物，不要假定这张初始领主连接表会自动授予同样效果；需要核对并实现实际授予逻辑。

这张表处理的是初始领主特性，不是“击败该传奇领主后获得的特性”。游戏中这类效果会显示为“击败传奇领主特性”，通常还涉及人物特性数据和脚本授予逻辑，不能用这一行代替。

为什么通常不要添加`unique_agents_tables`

unique_agents_tables包含agent_subtype、固定姓名、agent_type、spawn_behaviour和spawn_via_ui等字段。当前原版中，它大量用于传奇英雄、任务人物和特殊生成的人物；少数记录的内部人物大类可能是general，也不能由此得出“传奇领主都要填”。

只有满足下面条件时才考虑它：

你已经找到一个生成方式与目标完全相同的原版人物。
该原版人物确实通过unique_agents_tables进入相应界面或脚本流程。
你已经追踪到读取这张表的完整入口，而不是只看到人物类型搜索命中。

本文的可招募传奇领主使用已经核对的 Lua 招募入口。不要同时用多个互不协调的系统创建同一个人物，否则可能出现重复或身份、存档状态不一致。

内容包权限

原版传奇领主可能在agent_subtype_ownership_content_pack_junctions_tables中绑定官方内容包。这里只读核对模板依赖，不将该表导入自己的 Pack 修改。

在 Game-RO 页面只读查看人物类型与官方内容包的连接及特殊校验警告

图中：① Agent Subtype是人物类型；② Ownership Content Pack是相关官方内容包。页面顶部的特殊校验警告必须保留并遵守，不能把受保护的表当成普通 DB 编辑。

使用 DLC 资源或机制时，核对并说明实际前置依赖；完全自制人物也不要无意复制模板的 DLC 条件。不要通过删除或伪造官方内容包记录来解决招募问题。内容包检查不是招募入口，也不保证人物唯一。

派系机制、剧情和脚本边界

一名原版传奇领主还可能出现在：

任务链、任务战和物品解锁。
专属资源、仪式和派系面板。
外交、合邦和击败后招募逻辑。
受伤、死亡、复活和重新进入领主招募池的逻辑。
介绍任务、镜头、语音和开场事件。
AI 个性、自动结算、派系潜力和特殊军队生成。

这些都不是“传奇领主基础身份”的通用必填项。制作时采用按需原则：设计中需要哪一种功能，就找拥有同一种功能的原版人物并追踪完整数据和 Lua；不需要就不要复制。

尤其要区分：

能在新战役界面选择不等于拥有完整的派系机制。
被击败后不朽不等于能被其他派系自动招募。
有专属技能树不等于技能实际指向了新兵种集合和新效果。
有新战役界面影片字段不等于 Pack 中已有可播放影片。

本地化与玩家界面术语

至少检查：

传奇领主姓名、称号和职业类型。
单位名称、短说明和长说明。
派系选择界面的人物简介与特色说明。
加载界面文本。
专属技能、法术、部队技能、物品和特性。
招募分类和招募成本说明。

玩家可见中文以《全面战争：战锤 III》游戏内简体中文术语为准。Schema、Assembly Kit 和表名用于检索，不能把它们的英文直译直接当成游戏术语。

固定姓名可能在战役、战斗、外交和新战役界面分别读取不同数据。只在一个界面看到正确姓名，不能证明其他界面已经完成。

怎样自行查找完整数据

先按实际招募方式找模板

在游戏中确认模板如何获得，区分招募池、地图生成和新战役界面展示。
在依赖项 → 游戏文件中查找人物类型 Key，记录主单位、分类、外观和技能树连接。
在游戏文件范围全局搜索人物类型 Key，同时启用 DB 与文本搜索，分开整理 DB 命中和 Lua 命中。
用脚本里的函数名、列表名、事件名继续搜索，找到实际传入人物类型的调用链。
记录目标派系、触发条件、加入人物的接口以及防重复状态，不把脚本中的一次命中当作完整逻辑。
只有需要新战役界面展示时才继续搜索对应的领袖记录和资源，不为招募池人物复制无关的展示配置。

再追踪内容链

搜索主单位 Key，追踪陆战单位、战斗模型变体、实体、武器、部队技能和多形态单位。
搜索Art SetID，追踪战役外观记录、Uniform、Portrait Settings、动态头像和坐骑切换。
搜索技能树节点集合 Key，导出成员节点，再追踪技能、效果、法术和坐骑。
搜索固定姓名 ID，确认没有与原人物共用需要改写的本地化文本。
搜索效果包和人物特性，区分初始领主特性、技能效果和击败传奇领主特性。
搜索 Lua 中的人物类型、派系 Key、新战役界面记录 Key 和效果 Key，确认是否有脚本依赖。

搜索结果很多不代表都要复制。每一条记录都要回答两个问题：它属于哪项功能；你的新传奇领主是否真的需要这项功能。

可招募传奇领主的制作顺序

完成基础领主的战斗单位、人物类型、派系权限、战役外观、头像和技能树。
为实际支持的战役核对必要的 DB 连接，不无条件复制模板的全部战役记录。
建立独立姓名与本地化，确定脚本调用使用的姓名形式。
建立本 Mod 的 Lua 加载与招募入口，先向一个目标派系加入一名测试人物。
验证可以招募、带兵、查看技能并进入战斗。
加入正式解锁条件和防重复处理，分开配置不朽与唯一人物逻辑。
按需授予专属效果、物品或机制，检查没有沿用模板的错误对象。
新开战役验证，随后测试读档、受伤恢复与再次招募；支持多个战役或多人时分别验收。

地图生成或新战役界面展示不是上述流程的必填步骤。只有设计需要时才增加，且不能把完成招募池版本说成已经完成了另外两种结果。

常见错误

只有分类、没有领主：先检查 Lua 是否加载、招募条件是否满足、接口是否执行，再检查派系权限与人物类型引用。
把unique_agents_tables或legendary_lords分类当成完整传奇身份：这些数据不替代实际生成、防重复和身份保持。
同一人物反复出现：读档或重复事件又执行了加入逻辑，或者还存在另一条自动生成路径。
领主受伤后又多出一个新人：只检查了地图军队，没有区分招募池、受伤状态和已经存在的原人物。
进入错误派系：脚本传入了错误派系 Key，或没有限制触发对象。
固定姓名改掉原人物：修改了模板的姓名本地化，未给新人物创建独立文本。
可以招募但战斗崩溃：人物类型、主单位、陆战单位、模型、实体和动作链仍有错误。
初始领主特性没有生效：把原版初始领主的效果连接当成了脚本新人物自动拥有的效果。
击败传奇领主特性缺失：初始领主特性不是击败特性系统，需要另外的人物特性与授予逻辑。
战役模型正常但头像为空：新的Art Set没有对应的Portrait Settings或图片资源。
界面是新人物，战役还是旧人物：只完成了新战役界面展示，没有完成实际战役接入。
一个战役正常、另一个战役不出现：检查脚本加载范围、实际派系和事件条件，不只补 DB 连接。
旧存档不出现：脚本可能只在新战役执行；是否支持旧存档要另行设计并测试。

RPFM 检查

运行诊断，处理缺失引用、重复 Key、重复数值 ID、无效资源路径和缺失的本地化文本。
搜索新人物类型 Key，确认命中派系general权限、Art Set、技能树节点集合和目标战役连接。
搜索新主单位，确认人物类型、主单位、陆战单位、战斗模型变体和多形态数据链正确。
搜索每个Art Set，确认战役外观记录、Uniform、Portrait Settings和新战役界面图片各自完整。
搜索技能树节点集合，确认成员节点、技能、法术、坐骑和专属效果没有遗留模板限制。
检查 Lua 的打包路径、加载和调用入口，核对派系、人物类型、姓名、外观与状态标记。
若修改新战役界面，搜索展示记录与资源，确认对应的派系和人物类型正确；不把展示记录当成招募入口。
搜索姓名 ID，确认新本地化文本没有覆盖原人物。
搜索模板人物类型和原派系领袖，确认没有误复制无关的 DLC、任务、变身或脚本机制。
确认 Pack 中没有未改名的data__整表和无关原版记录。

游戏内验收

人物数据与招募都要检查

传奇领主姓名、称号、职业、说明和简体中文术语正确。
战役模型、人物头像、战斗兵牌、人物信息界面、战前镜头和语音正确。
技能树完整，专属技能、法术、坐骑和效果指向新传奇领主需要的数据。
手动战斗中的模型、动作、武器、部队技能、形态、生命值和受伤状态正常。
保存并重新读取后，等级、技能、物品、坐骑、军队、伤势和人物身份保持正确。

领主池路线

新传奇领主只出现一次，并进入正确派系的领主招募池。
招募成本、等级和解锁条件正确。
招募后能带领军队，死亡、不朽和重新招募行为符合设计。

地图开局路线

传奇领主在正确战役、派系和坐标生成。
初始军队全部属于该传奇领主，人数和单位类型正确。
原派系领袖、其他军队和开局脚本没有冲突。

可选派系领袖路线

新战役界面中的人物模型、图片、说明、语音、影片和加载内容正确。
选择该领袖后进入正确派系和正确战役。
实际开局人物就是新人物类型，不是只换了新战役界面图片的原领袖。
开局位置、初始军队、人物特性、外交、任务和派系机制符合设计。
每个受支持战役都单独通过一次新战役验收。

RPFM 诊断可以发现部分表结构、引用和资源错误，但无法证明 Lua 已执行、人物能够招募、唯一性、不朽、重载以及多战役接入正确。本文的原版数据截图不是新 Mod 的游戏验收截图；没有实际通过招募和游戏测试前，仍应明确标为未完成验证。