创建英雄与事务官单位

创建英雄不是在agent_subtypes_tables里新建一行就结束。一名能够正常使用的英雄同时有两个身份：在战役地图上，它是可招募、可升级、可执行英雄行动或随军行动的人物；进入战斗后，它又是一个只有一名成员的陆战单位。两条数据链必须通过associated_unit_override正确连在一起。

《全面战争：战锤 III》的简体中文界面称这类人物为“英雄”；英雄在战役地图上独立行动时，旧教程和模组社区也常称其为“事务官”。数据库中的agent只是内部名称。本文面向玩家时统一使用“英雄”，仅在表名、字段和 Key 中保留agent。

先确定要做哪种英雄

不同英雄可能属于完全不同的内部人物大类。例如，震旦的丹鼎师能够施放法术，但原版faction_agent_permitted_subtypes_tables.Agent使用的却是engineer；司天丞使用wizard，门下督使用champion。这些 Key 是引擎内部分类，不是游戏中的职业名称，更不能按英文字面翻译。

选择模板时至少比较：

要比较的内容	为什么重要
相同派系或亚文化	决定招募权限、姓名、战役模型、语音和部分机制。
相同内部人物大类（agent）	决定英雄行动、英雄招募容量、加成和部分招募规则使用哪类内部 Key。
相同战斗形态	步行、骑乘、飞行、怪兽、战车或战争机器使用的实体、挂点和动作链不同。
相同性别与随机外观方式	影响姓名池、Art Set（战役外观配置）和招募池生成。
相同战斗职能	近战英雄、远程英雄和施法者需要不同的武器、技能和 AI 定位。
相同招募方式	建筑解锁、特殊招募池、任务奖励和脚本生成不能套用同一套步骤。

本文使用震旦的丹鼎师wh3_main_cth_alchemist演示“现有派系、建筑解锁、可以重复招募的普通英雄”。这个案例不适合直接照搬给传奇英雄、以巨兽形态参战的英雄、拥有多种形态的英雄，或不通过建筑解锁的特殊英雄。

完整数据链

战役人物身份
agent_subtypes_tables
    ├─ associated_unit_override ─→ main_units_tables
    ├─ faction_agent_permitted_subtypes_tables
    ├─ character_skill_node_sets_tables
    └─ campaign_character_art_sets_tables
            └─ campaign_character_arts_tables
                    └─ agent_uniforms_tables

战斗单位
main_units_tables
    └─ land_units_tables
            ├─ battle_entities_tables
            ├─ melee_weapons_tables / missile_weapons_tables
            ├─ unit_variants_tables → variants_tables
            └─ 护甲、盾牌、属性、技能与按需分支

招募入口（建筑解锁案例）
building_effects_junction_tables
    └─ effects_tables
            ├─ effect_bonus_value_agent_junction_tables
            └─ effect_bonus_value_agent_subtype_junctions_tables

需要哪些表单

普通英雄的核心表单

表单	负责什么
agent_subtypes_tables	定义具体英雄类型、关联的战斗单位、是否可招募、招募成本和姓名生成方式。
faction_agent_permitted_subtypes_tables	把英雄类型交给指定派系，并声明它使用哪个agent大类。
main_units_tables	定义英雄进入战斗后的主单位记录和战役属性。
land_units_tables	定义英雄的战斗数值、动作、实体、武器、防护和属性。
unit_variants_tables	连接主单位和战斗模型变体。
campaign_character_art_sets_tables	把Art Set（战役外观配置）分配给具体英雄类型。
campaign_character_arts_tables	为每套Art Set配置战役模型、陆地状态动作、海上状态模型以及等级或季节变体。
character_skill_node_sets_tables	声明哪棵技能树属于这个英雄类型。
character_skill_node_set_items_tables	把具体技能节点放入技能树。

只在对应目标下添加

表单或文件	什么时候需要
agents_tables	几乎不需要。只有真正新建一种引擎内部人物大类时才考虑，普通新英雄应复用原版大类。
agent_culture_details_tables	目标文化尚未配置该agent大类的显示名称、默认单位或小图标时才需要。
agent_recruitment_categories_tables	需要独立招募分类或模板本来使用该表时添加。很多普通英雄的recruitment_category为空。
agent_uniforms_tables	使用新战役模型、单独指定战斗模型或更换战役骨骼时需要。复用原版Uniform时不要重复复制原记录。
agent_subtype_ownership_content_pack_junctions_tables	确实需要官方 DLC 或内容包拥有条件时添加。自制英雄不要无意复制模板的 DLC 限制。
names_groups_tables、names_tables	要为普通英雄建立独立随机姓名池时添加。
effects_tables及相关Bonus Value连接表	要通过建筑、科技或其他来源解锁招募、增加英雄招募容量或提高新募英雄等级时添加。
campaign_character_art_set_porthole_overrides_tables	使用特殊动态头像场景时添加。
*portrait_settings*.bin	新的Art SetID需要独立头像构图时编辑。
campaign_to_agent_subtypes_tables	只在原版同类英雄确实按战役过滤时添加；不是所有普通英雄的必需表。

先规划一套唯一 Key

不要边复制边临时改名。先写好同一套前缀，再依次创建记录。以yourmod_cth_alchemist为例：

英雄类型：yourmod_cth_alchemist
主单位：yourmod_cth_cha_alchemist_0
陆战单位：yourmod_cth_cha_alchemist_0
战斗模型变体：yourmod_cth_cha_alchemist
战役外观配置：yourmod_art_set_cth_alchemist_01
技能树节点集合：yourmod_skill_node_set_cth_alchemist
招募效果：yourmod_effect_agent_enable_recruitment_cth_alchemist

yourmod必须替换为你自己的独特前缀。不要使用wh3_main、wh3_dlc或原版 Key，也不要在不同表中一会儿使用空格、一会儿使用连字符。

在 Pack 中准备表单

先在 RPFM 中选择《全面战争：战锤 III》，新建自己的 Mod Pack。原版模板从依赖项 → 游戏文件查找；打开后的页签以Game-RO:开头，表示正在只读查看游戏数据。

本文截图展示的是这一步的原版模板和连接关系，所以仍保留丹鼎师的原版 Key。它们不是“新英雄已经做好”的截图；下文要求复制、改 Key 或删除记录时，都要在自己的 Mod Pack 内操作，不能直接修改只读页签。

准备可编辑数据可以使用两种方式：

1. 在依赖项 → 游戏文件查找原版表单，打开后筛选模板 Key；在自己的 Pack 中新建同类型的 DB 表，只复制需要的模板记录进去。
2. 将游戏文件中的原版整张表导入自己的 Pack，先把导入后的data__重命名为自己的 DB 文件名，再选中需要的模板行，反选后删除其余记录。

导入的 DB 文件不得继续叫data__。这是原版数据库的默认表名，保留该名称可能让 Mod 整表覆盖原版数据。导入后应立即改名，选中需要的模板行，反选后删除其余记录，最后再复制和改 Key。

Assembly Kit 文件以及 Assembly Kit 的db.pack只用于只读研究和交叉核对，不作为本教程导入、复制、编辑或游戏引用的数据来源。这里只修改自己 Pack 内的 DB 文件名，不改agent_subtypes_tables等表类型文件夹，也不改游戏原文件。

不论用哪种方式，都只保留本 Mod 真正修改或新建的记录。不要因为“可能会用到”就把整棵原版技能树、全部姓名或整张派系权限表留在 Pack 中。

创建英雄的战斗单位

如果新英雄要完全沿用原英雄的战斗数值、模型和技能，associated_unit_override可以暂时指向原版main_units_tables.Unit。这适合快速检查战役部分，但不是制作独立英雄的最终做法：以后修改共享单位会同时影响原英雄。

要建立可独立调整的英雄，复制模板的：

1. main_units_tables。
2. land_units_tables。
3. unit_variants_tables。
4. 确实要独立修改的battle_entities_tables、武器、护甲、盾牌、属性组或部队技能连接。

不需要改的实体、武器和模型可以继续引用原版记录。“创建新英雄”不等于“复制它引用的所有数据”。

main_units_tables的英雄关键项

字段	普通英雄应如何处理
unit	新主单位唯一 Key。
land_unit	指向新建的land_units_tables.Key。
num_men	常规英雄为 1。拥有多个实体的英雄必须另找真正同类的原版模板。
caste	普通英雄通常使用hero。不要仅为了改 UI 文字而填成lord。
use_hitpoints_in_campaign	保留同类英雄模板的值，使战斗中的伤势与战役状态正确衔接。
restrict_xp_gain_in_campaign	人物经验与普通部队经验是两套系统，应沿用英雄模板，不要把普通兵种值搬过来。
porthole_camera	动态头像和战前镜头使用的相机模板。必须与英雄身高、坐骑和模型类型匹配。
audio_voiceover_culture、audio_voiceover_actor_group	英雄语音。没有自制语音时可复用兼容模板，但不要填一个不存在的 Key。
ui_unit_group_land	战斗和部分界面使用的单位分类。应参考战斗定位相同的英雄。
can_siege	是否具备独立攻城能力。不是“英雄能否参加攻城战”。

land_units_tables的英雄关键项

Num Men并不存在于land_units_tables；单位人数由main_units_tables.num_men控制。在land_units_tables中需要核对：

• man_entity：单人英雄使用的战斗实体。
• man_animation：战斗动作表。
• bonus_hit_points：在实体基础上追加的生命值。
• primary_melee_weapon、primary_missile_weapon、护甲与盾牌：战斗武器与防护。
• attribute_group：英雄使用的单位属性组。
• ai_usage_group：战斗 AI 对该英雄的定位。
• spell_mastery：法术精通。它不会自动授予任何法术。
• mount、num_mounts：战斗中直接使用坐骑的单位链。英雄通过技能解锁多种坐骑时，每种坐骑形态通常都有独立的主单位记录。

其余战斗字段请按《陆战单位详解》、《远程武器详解》和《部队技能详解》的数据链检查。

建立agent_subtypes_tables记录

复制wh3_main_cth_alchemist，把key改为自己的英雄类型 Key，然后逐列检查：

字段	作用与处理方式
auto_generate	是否生成可以反复招募的普通英雄。普通英雄通常沿用模板的开启值；唯一人物不能照搬。
onscreen_name_override	英雄职业名称。最终简体中文由本地化文本（Loc）提供，不要只依赖表内英文。
is_caster	标记施法者身份。它不会授予法术，法术仍来自技能树、部队技能、物品或脚本。
associated_unit_override	指向该英雄进入战斗时使用的main_units_tables.Unit。
audio_voiceover_actor_group	战役地图上的英雄语音组。与主单位的语音字段一并检查。
show_in_ui	该英雄类型是否允许在相关界面中显示。
cap	英雄类型自身的限制值。大量原版记录为-1；英雄招募容量通常还受效果和contributes_to_agent_cap影响，不要只改这一列。
has_female_name	姓名生成相关标记。复用同性别和同姓名结构模板，并用实际招募池验证。
can_gain_xp	英雄是否能获得人物经验。
loyalty_is_applicable	是否参与忠诚度系统。只在目标派系真正使用该机制时沿用。
contributes_to_agent_cap	该英雄是否计入相应的英雄招募容量。
names_group	可选的随机姓名组覆盖。留空时可能继承派系或文化的姓名来源，应按模板验证。
recruitment_category	招募界面分类。丹鼎师的原版记录为空，所以普通英雄不能被强制填入一个领主分类。
magic_lore	魔法之风或施法分类引用。它不会自动把整套法术放进技能树。
can_be_loaned	是否参与内部的英雄借调流程。游戏没有统一显示这一字段的名称，应沿用同派系、同招募方式的模板。
recruitable	是否允许被招募。开启它不会自动创建派系权限和解锁来源。
saving_settings	指向character_saving_settings_tables.key，控制人物能否单独保存，以及能否载入战役或自定义战斗。丹鼎师使用can_be_saved_loaded；这不是普通战役存档的总开关。
can_equip_ancillaries	是否能装备物品。
cost	英雄招募成本的基础值。实际成本还可能受效果和派系机制影响。
small_icon、recruitment_button_*	可选的英雄类型图标和招募按钮图片覆盖。原版大量记录留空，并从其他外观数据中取值。

本例直接保留以下原版值，避免逐项翻找：auto_generate、is_caster、show_in_ui、can_gain_xp、contributes_to_agent_cap、can_be_loaned、recruitable、can_equip_ancillaries为true；loyalty_is_applicable和has_female_name为false；cap = -1，cost = 800；recruitment_category、magic_lore和names_group留空。has_female_name = false是丹鼎师的实际记录，不能因为模型为女性就擅自反转。创建近战英雄时，应换用近战英雄模板，并同步处理法术和技能树，不能只关闭is_caster。

saving_settings的三个原版选项如下，按功能选择即可：

Key	可保存人物	可载入战役	可载入自定义战斗
can_be_saved_loaded	是	是	是
cannot_be_loaded_in_campaign	是	否	是
cannot_be_saved_loaded	否	否	否

① 是战役人物类型的 Key，② 是它进入战斗时使用的主单位 Key；二者属于不同的表，不要求文字完全相同。创建独立英雄时，要让新人物类型的②指向你创建的新主单位。

向右滚动同一张表，可以继续检查语音组和人物显示选项。截图中的字段只是这一段可见的列，其他列仍需按上表检查，不要把“没有出现在截图中”误认为“不需要配置”。

把英雄交给派系

Agent引用agents_tables.key，Subtype引用agent_subtypes_tables.key，两者不能互换。当前原版agents_tables共有以下 9 个大类。表内中文是用途说明；同一个大类可以容纳不同文化的多个职业，并没有一套跨文化通用的职业译名。

Agent值	原版例子或用途	创建普通英雄时怎样选
champion	门下督，Subtype 为wh3_dlc24_cth_gate_master。	使用这类原版英雄的行动和招募体系时沿用。
dignitary	侍女，Subtype 为wh2_dlc10_hef_handmaiden。	也是英雄大类，不能按英文把它当成纯外交人物。
engineer	丹鼎师，Subtype 为wh3_main_cth_alchemist。	本文选择此项；会施法的英雄也可以属于它。
runesmith	符文铁匠，Subtype 为wh_main_dwf_runesmith。	复用符文铁匠等相同内部大类的体系时沿用；并非只容纳矮人。
spy	刺客，Subtype 为wh2_main_skv_assassin。	复用该类英雄体系时沿用，不以是否拥有潜行外观判断。
wizard	司天丞，Subtype 为wh3_main_cth_astromancer。	复用该类施法英雄的体系时沿用；不是所有施法者的统一选项。
general	普通领主和传奇领主使用的大类。	普通英雄不选；创建领主时使用。
colonel	原版另有该类人物权限；agent_to_agent_abilities_tables给它连接了command_force。	属于需要配合生成入口研究的特殊人物用途，不作为本文的英雄招募模板。
minister	原版保留此类文化及人物权限，agents_tables.playable = false。	不作为普通可招募英雄模板，不能因权限表里有记录就当成可招募职业。

前六项是选英雄模板时常见的大类，并不表示每个派系都已配置全部六类。本例的选择顺序是：先定丹鼎师的 Subtype，再从其原版权限记录读到engineer，最后让派系权限、Art Set.agent_type、技能树的agent_key和大类效果目标保持一致。只改权限表的一列不能完整改变英雄体系。

在faction_agent_permitted_subtypes_tables中复制模板派系的对应记录，修改：

Faction = 目标派系 Key
Agent   = 模板英雄实际使用的 agent 大类
Subtype = 新英雄类型 Key

本例的丹鼎师必须沿用Agent = engineer。不要因为它会施法就改成wizard，否则英雄行动、英雄招募容量、战役界面和其他以内部人物大类为条件的系统可能一起改变。

若目标是震旦卫北列省，可直接填写Faction = wh3_main_cth_the_northern_provinces、Agent = engineer、Subtype = yourmod_cth_alchemist；卫西列省的派系 Key 是wh3_main_cth_the_western_provinces。两个派系都要使用时分别建一行，不能在一个Faction单元格里用逗号拼接。复制的记录还要保持mod_disabled = false。

要让多个派系使用新英雄，应为每个目标派系添加记录。不要复制搜索结果中所有原版派系；叛军、任务战派系、序章派系和特殊战役派系不一定属于你的目标。

配置战役模型与动作

Art Set与战役外观记录

campaign_character_art_sets_tables负责“哪套Art Set属于哪个人物类型”，campaign_character_arts_tables负责“这套外观配置在什么条件下使用哪个模型和动作”。Art Set是数据库内部名称，不是游戏界面中的职业或外观分类。

丹鼎师原版使用 5 个Art Set，对应 5 套可随机出现的战役外观。要完整保留这种随机性，应复制 5 条Art Set记录和对应的campaign_character_arts_tables记录；如果新英雄只需要一种外观，可以只创建 1 套，不需要为了追求“数量一样”而复制全部变体。

每条campaign_character_art_sets_tables需检查：

字段	作用
art_set_id	Art Set的唯一 Key。新英雄类型不能与原版继续共用同一主键行。
agent_type	该Art Set适用的内部人物大类，应与派系权限中的Agent一致。
faction、culture、subculture	可选的适用范围。只在你确实要限制战役外观选择时填写。
agent_subtype	指向新建的英雄类型 Key。
is_male	用于选择战役外观的性别条件。原版唯一人物中存在与外观看起来的性别不一致的数据，不要把它当作玩家所见性别的唯一依据。
campaign_map_scale	战役地图模型缩放。
prebattle_separation_offset	战前界面中的模型间距偏移，应参考体型和坐骑相同的英雄。

campaign_character_arts_tables中最容易出错的字段是：

• art_set_id：必须指向新的Art Set。
• level、season、age：决定条件变体。不需要条件变化时沿用模板的基础值。
• uniform：指向agent_uniforms_tables.uniform_name。
• land_animation：人物在陆地状态下使用的战役地图动作。它不是land_units_tables.man_animation。
• sea_uniform、navy_uniform、sea_animation、navy_animation：海上或运输状态。应保留同文化模板的合法记录。
• id：数值主键，每条新记录都必须唯一。不要只改art_set_id却保留模板 ID。

只保留一种丹鼎师外观时，可以从wh3_main_art_set_cth_alchemist_01这组开始。复制后将两张表中的art_set_id统一改为yourmod_art_set_cth_alchemist_01，外观集合中的agent_subtype改为yourmod_cth_alchemist。其余基础配置直接对照下表：

所在表及字段	本例保留值
campaign_character_art_sets_tables.agent_type	engineer
同表culture、subculture、faction	留空；本例由具体 Subtype 确定适用人物。
同表is_male、is_custom	均为false。
同表campaign_map_scale、prebattle_separation_offset	分别为1和0。
campaign_character_arts_tables.level、age、season	分别为0、0、none。
同表uniform	wh3_main_uniform_cth_alchemist_01
同表land_animation	cam_hu1e_hr1_mage_female_hero
同表sea_uniform、navy_uniform	均为wh3_uniform_cth_ship_agent。
同表sea_animation、navy_animation	均为cam_cathayship_01。

另外四套原版外观的集合与Uniform后缀依次为02、03、04、05；要保留它们时逐组复制和改名。新id使用未占用的正整数，例如先在原版和自己的 Pack 中精确搜索1900609001，确认该表没有占用后再填写；后续记录依次换成不同值。此列为有符号 32 位整数，正值不超过2147483647，示例数字并不保证与所有第三方 Mod 都不冲突。

复用还是新建Uniform

如果你只想让新英雄使用原版丹鼎师的战役模型，新建Art Set和对应外观记录后，uniform可以继续指向原版wh3_main_uniform_cth_alchemist_01等记录。这时不要把agent_uniforms_tables的原版行重复塞进 Mod。

只有下列情况才创建新Uniform：

• 使用新的战役地图模型文件。
• 战斗和战役需要不同的模型文件。
• campaign_porthole_filename或campaign_politician_filename需要使用另一套模型。
• 需要覆盖战役骨骼。

agent_uniforms_tables中的filename、battle_filename、campaign_porthole_filename、campaign_politician_filename和campaign_override_skeleton必须与实际资产一致。RPFM 能保存路径，但不会自动创建缺失的模型、骨骼或动作。

配置头像与招募图片

英雄在不同界面可能使用不同图片来源：

• agent_culture_details_tables.small_icon：文化和内部人物大类层面的小图标。
• agent_subtypes_tables.small_icon与recruitment_button_*：英雄类型层面的覆盖。
• unit_variants_tables.unit_card：战斗单位兵牌引用。许多英雄模板使用placeholder，不代表战役头像也使用这张图片。
• campaign_character_arts_tables.portrait、card和info：旧或特定界面的直接图片入口。
• *portrait_settings*.bin：当前大量人物头像使用的构图、相机和贴图变体。

使用新的Art SetID时，应在依赖项 → 游戏文件中搜索该模板的portrait_settings文件，将需要的文件加入自己的 Mod Pack，然后在该 Pack 的Portrait Settings编辑器中克隆模板条目，把art_set_id改为新 ID。如果引用新贴图，再逐项修改diffuse和mask路径。

仅在 DB 中新建Art Set，却没有在Portrait Settings中添加新 ID，常见结果是模型正常而头像缺失。运行 RPFM 诊断可以检查无效的Art SetID、战斗模型变体和缺失贴图。

为英雄配置技能树

新英雄类型不会自动继承模板技能树。如果想完整复用原技能树，不需要复制所有character_skills_tables和节点，可以：

1. 复制模板的character_skill_node_sets_tables记录。
2. 改成新的技能树节点集合 Key。
3. 把agent_subtype_key改成新英雄类型 Key。
4. 保留与模板一致的agent_key，并核对派系、亚文化和战役限制。
5. 复制该节点集合在character_skill_node_set_items_tables中的所有成员行，只把set改成新的节点集合 Key。

丹鼎师原节点集合是wh3_main_skill_node_set_cth_alchemist。在character_skill_node_sets_tables.key精确筛选它；复制后填写key = yourmod_skill_node_set_cth_alchemist、agent_key = engineer、agent_subtype_key = yourmod_cth_alchemist，faction_key、campaign_key、subculture均保留为空，for_army和for_navy均为false。再到成员表按set = wh3_main_skill_node_set_cth_alchemist筛选全部成员并复制，避免按节点名称猜测该复制哪些行。

图中：① Key是技能树节点集合自己的唯一 Key；② Agent Key是内部人物大类，本例为engineer；③ Agent Subtype Key才是这套技能树实际分配给的具体人物类型。复制模板时，把①和③换成新 Key；②以及中间的派系、战役、亚文化条件都要按目标设计检查，不能看到同为英雄就一律照抄。

这种做法是“新英雄共用原技能节点”。只要不修改共享节点和技能记录，它就不会覆盖原英雄。

要制作独立技能树，再按《人物技能详解》复制节点、技能、连线和等级奖励。如果英雄是施法者，还要按《法术详解》确认法术解锁节点。is_caster = true只是身份标记，不是法术清单。

让英雄出现在招募界面

faction_agent_permitted_subtypes_tables只是“允许派系使用该英雄”，不等于已经有招募入口。本例采用原版丹鼎师的建筑解锁路径。

独立解锁还是共享解锁

有两种合理做法：

1. 共享原招募条件：让新英雄也受原版丹鼎师招募效果影响。这适合两者本来就应一起解锁的情况，但会把新英雄类型和原效果绑定在一起。
2. 创建独立招募效果：复制原效果及其Bonus Value连接，改成新的效果 Key，再由目标建筑提供。这适合需要独立控制解锁来源的新英雄。

本文推荐第二种，因为以后更换建筑或调整条件时不会意外改变原版英雄。

复制招募效果的数据链

以wh3_main_effect_agent_enable_recruitment_cth_alchemist为模板，完整搜索它的引用，而不是只复制effects_tables一行。新的招募效果至少需要：

effects_tables.Effect
    = yourmod_effect_agent_enable_recruitment_cth_alchemist

effect_bonus_value_agent_junction_tables
    Effect         = 新效果 Key
    Bonus Value ID = availability
    Agent          = engineer

effect_bonus_value_agent_subtype_junctions_tables
    Effect         = 新效果 Key
    Bonus Value ID = availability
    Subtype        = yourmod_cth_alchemist

原版数据可能同时包含“内部人物大类”和“具体英雄类型”两种连接。复制时应保留模板结构，只替换效果 Key 和人物类型 Key；不要因为两行都写着availability就随意删掉其中一条。

然后在building_effects_junction_tables中让目标建筑等级提供新效果：

Building     = 目标 building_levels Key
Effect       = 新招募效果 Key
Value        = 1
Effect Scope = province_to_province_own_unseen

复用震旦原版解锁建筑时，Building依次可以是wh3_main_cth_artillery_1、wh3_main_cth_artillery_2、wh3_main_cth_artillery_3。三个建筑等级各加一行，value = 1、value_damaged = 1、value_ruined = 0，context_requirement留空，effect_scope都用province_to_province_own_unseen。这样不会只给第一级添加效果、升级后反而丢失入口。这里的 Scope 来自该解锁效果的原版建筑记录，不应直接套给提高容量或新募等级的效果。

共享原招募条件时，不新增建筑效果：在两类availability连接中检查原效果已有的engineer连接，保留它，并给原效果增加指向yourmod_cth_alchemist的 Subtype 连接即可。创建独立效果时才按上面的新效果 Key 另接建筑。

这里的建筑只是一种实现路径。如果你的设计是科技解锁、任务奖励、特殊招募池或脚本生成，应从同类原版英雄反查真实入口，不要为它强行加一个兵营或者随便一座建筑。

英雄招募容量和新募英雄等级

常见的Bonus Value如下。Bonus Value是数据库内部用于决定效果实际作用的类型，不是游戏界面术语：

Bonus Value	作用
availability	允许招募某个内部人物大类或具体英雄类型。
cap	增加英雄招募容量。
recruitment_level	提高新募英雄等级。

英雄招募容量在原版中经常按内部人物大类计算，而不是按具体人物类型分开。如果新英雄与丹鼎师同属engineer，两者可能共用容量。不要看到效果 Key 里写着alchemist就认定它只影响丹鼎师；必须打开Bonus Value连接，查看实际指向的Agent或Subtype。

图中：① Bonus Value Id决定这一条连接要调用哪类效果功能；② Effect指向effects_tables中的效果 Key；③ Subtype指向具体人物类型。判断“这个效果到底影响谁”时要同时读三列，不能只凭效果 Key 中的人名或派系缩写猜测。

姓名、职业名和说明

这三类文字不是同一个数据：

• 职业名：通常来自agent_subtypes_tables.onscreen_name_override或agent_culture_details_tables.onscreen_name。
• 具体人名：普通英雄从派系或names_group对应的names_tables中抽取。
• 英雄职业说明：可来自agent_subtypes_tables.description_text_override、agent_culture_details_tables.description_text或关联单位说明，具体以目标界面为准。

本例的新职业名 Loc Key 是agent_subtypes_onscreen_name_override_yourmod_cth_alchemist，职业说明 Key 是agent_subtypes_description_text_override_yourmod_cth_alchemist，其Text填写自己设计的简体中文名称和说明。这些前缀由表名及本地化列决定，末尾接新 Subtype，不接engineer。需要独立战斗单位名称时，另建land_units_onscreen_name_yourmod_cth_cha_alchemist_0。只改职业名时可以保留原随机姓名池；需要新姓名时，在names_groups_tables建唯一姓名组，再把names_tables中的目标姓名记录复制到该组，最后将新组 Key 填入names_group，不能直接把中文姓名写进这个引用列。

不要只写一条“丹鼎师”本地化文本，就假定所有界面都会同时更新。按《本地化详解》使用 RPFM 的“生成缺失本地化文本”（Generate Missing Loc Data）检查英雄类型、单位、技能和效果文本，再到招募英雄界面、人物详情界面和战斗中分别核对。

英雄行动和默认属性

英雄可以执行哪些英雄行动，通常与内部人物大类及以下数据有关：

• agent_to_agent_abilities_tables
• agent_to_agent_attributes_tables
• agent_actions_tables
• agent_conditions_tables
• 人物技能提供的英雄行动效果

图中：① Attribute是英雄行动系统使用的内部属性标识；② Agent是获得该默认值的内部人物大类；③ Default Value是基础值。它描述的是内部行动判定数据，不是让玩家在人物面板中直接分配的属性点。

本文复用丹鼎师已有的engineer内部人物大类，因此不另外新建人物大类或英雄行动。但“同属engineer”也意味着它可能继承该大类的默认行动和加成。如果你想让新英雄拥有不同的英雄行动，应先查找一个真正使用同类行动的原版英雄，再按后续的英雄行动教程单独处理，不要在创建英雄时猜测行动 Key。

图中：① Unique Id是行动记录自己的 Key；② Ability、Agent和Attribute共同说明行动类型、执行者大类和所用内部属性；③ Cannot Fail等结果列继续引用行动结果记录，它不是一个勾选框。新建行动前必须沿着同类原版记录把成功、失败与后续结果一起追完，不能只复制当前这一行。

这张图用wh3_cp1_agent_action_alchemist筛出两条丹鼎师相关记录，目的是展示连接结构，不代表该英雄全部可用的行动。换模板时，先查Agent和agent_to_agent_abilities_tables等连接，再检查行动的条件与效果；不要只按 Key 中的职业名筛选，就认定已经找到完整数据。

内容包权限和特殊机制

原版英雄常在agent_subtype_ownership_content_pack_junctions_tables中设置官方内容包拥有条件。将这行原样复制给新英雄，可能导致玩家未拥有相应 DLC 时无法使用它。

处理原则是：

1. 复用官方 DLC 独有资产和规则时，保留必要的所有权约束。
2. 完全自制且不应要求某个 DLC 时，不要因为复制模板就自动保留内容包拥有条件记录。
3. 无法确定资产授权范围时，先保留必需的 DLC 条件并在文档中说明，不要把“未拥有 DLC 因而无法使用”误写成 RPFM 故障。

宁和、骑士誓言、职位、吸血鬼伯爵的血裔、冰雪王廷训练等都是额外机制。看到模板人物类型 Key 在某个专用表或 Lua 中出现，不代表新英雄必须照搬；只有设计目标确实需要该机制时才添加。

怎样自行查找需要的数据

1. 在游戏中选一名招募方式和功能最接近的原版英雄。
2. 从依赖项 → 游戏文件打开agent_subtypes_tables，搜索它的人物类型 Key，记下associated_unit_override。
3. 将全局搜索范围设为游戏文件，搜索人物类型 Key，按派系权限、战役外观、技能树、内容包拥有条件和特殊机制分类结果。
4. 全局搜索associated_unit_override，追踪主单位、陆战单位、战斗模型变体和部队技能。
5. 在faction_agent_permitted_subtypes_tables查看模板实际使用的内部人物大类和全部派系记录。
6. 搜索招募效果，从Bonus Value连接反查真正的建筑、科技或其他来源。
7. 用Art SetID搜索 DB 和portrait_settings文件，确认战役模型、头像和动作是否完整。
8. 用技能树节点集合 Key 导出成员节点，检查默认技能、法术、英雄行动加成和坐骑分支。

一次全局搜索出现几十张表很正常。不要把“搜索命中”直接等同于“本 Mod 必须复制”；先按核心身份、战斗、战役外观、技能、招募和可选机制分类。

完整制作顺序

1. 选择同文化、同内部人物大类、同战斗形态和同招募方式的原版模板。
2. 规划全部新 Key，创建或导入本文需要的表单。
3. 复制主单位、陆战单位和战斗模型变体，先让英雄成为可用的单人战斗单位。
4. 新建agent_subtypes_tables记录，将associated_unit_override指向新主单位。
5. 在faction_agent_permitted_subtypes_tables中为真正的目标派系添加权限。
6. 建立Art Set和对应的外观记录，复用或新建Uniform，并处理Portrait Settings。
7. 新建技能树节点集合，把共享或独立技能节点放入新技能树。
8. 按设计选择建筑、科技、特殊池或其他招募入口。
9. 处理本地化文本、图标、姓名、语音和必要的内容包拥有条件。
10. 运行 RPFM 诊断，按数据链从人物类型向战斗单位、战役外观、技能树和招募效果逐项检查。
11. 新开战役存档进行验收。旧存档可能已经缓存招募池、容量和技能树。

常见错误

• 新建了agents_tables却没有英雄：你只建了内部人物大类，没有具体人物类型。普通情况下根本不应新建人物大类。
• 英雄在招募列表中消失：检查recruitable、show_in_ui、派系权限、招募效果和英雄招募容量。
• 可以招募但进入战斗崩溃：检查associated_unit_override、主单位、陆战单位、战斗模型变体、实体、动作和武器引用。
• 战役地图上隐形或红白模：检查Art Set、战役外观记录、Uniform和实际模型文件。
• 有模型但没有头像：搜索新的Art SetID是否存在于Portrait Settings，并检查贴图路径。
• 技能界面为空：缺少指向新人物类型的技能树节点集合，或该集合没有成员。
• 会施法但没有法术：is_caster已开启，但没有技能或其他系统授予法术。
• 建筑出现英雄图标却无法招募：检查效果是否通过Bonus Value连接到正确的Agent或Subtype，并核对数值与Scope（作用对象），不要只看建筑说明。
• 容量加给了其他英雄：该容量效果可能指向内部人物大类，而不是具体人物类型。
• 满足内容包拥有条件但没有英雄：内容包拥有条件不是招募入口。
• 只在旧存档失败：使用新开战役测试，再单独判断存档兼容。

RPFM 检查

1. 运行诊断，清理缺失引用、重复 Key、错误的资源路径和缺失的本地化文本。
2. 用全局搜索检查新人物类型 Key，确认至少命中派系权限、Art Set和技能树节点集合。
3. 用全局搜索检查新主单位 Key，确认人物类型、陆战单位和战斗模型变体都指向正确。
4. 搜索新效果，确认它有正确的Bonus Value目标，并且真正由建筑或其他来源提供。
5. 搜索新的Art SetID，确认 DB 记录和Portrait Settings内部条目一致。
6. 确认 Pack 中没有留下未改名的data__整表。

游戏内验收

• 建筑、科技或目标机制在正确条件下解锁英雄。
• 英雄只出现在预期派系，英雄招募容量和新募英雄等级正确。
• 招募英雄界面中各候选英雄的职业名、随机姓名、说明、图标和招募成本正确。
• 英雄能加入军队，能离开军队，能升级并打开完整技能树。
• 英雄在战役地图上的模型、步行、转身、待机和海上状态正常。
• 人物头像、人物信息界面、战斗兵牌和战前镜头均正常。
• 英雄能进入手动战斗，且模型、动作、武器、技能、法术和生命值正常，受伤状态也能被正确保存。
• 英雄完成一次战役行动，成功、失败、受伤和动画都没有异常。
• 保存后重新读取，英雄、技能、物品、等级和伤势状态保留正确。

RPFM 诊断只能确认部分引用、资源和格式问题，不能证明招募池生成、战役动作、技能树布局和战斗动作完全正常。这些都必须使用新开战役和手动战斗验收。