实战用法
在自定义学说系统的 mod 中,常用于检测某条学说轨道是否已被分配了子学说,从而决定是否解锁额外的决策、国策或修正。例如,当玩家已在步兵轨道上选择了任意子学说时,才允许触发相关的军事改革事件:
available = {
has_subdoctrine_in_track = infantry
}
配合关系
[has_completed_subdoctrine](/wiki/trigger/has_completed_subdoctrine):常与本 trigger 联用,先用 has_subdoctrine_in_track 确认该轨道已有分配,再用 has_completed_subdoctrine 进一步验证特定子学说是否研究完毕,形成两层条件过滤。
[has_completed_track](/wiki/trigger/has_completed_track):用于区分"已分配子学说"和"已完整完成整条轨道"的不同进度阶段,两者组合可实现阶段性奖励逻辑。
[has_doctrine](/wiki/trigger/has_doctrine):检查更上层的主学说是否已解锁,与本 trigger 搭配可确保学说体系的前置条件完整。
[add_doctrine_cost_reduction](/wiki/effect/add_doctrine_cost_reduction):在 trigger 满足后作为 effect 端奖励,给予学说费用折扣,是学说相关事件链的典型奖励输出。
常见坑
- 轨道名称拼写错误:
infantry、armor 等轨道名必须与 mod 中学说定义文件里的 track 标识符完全一致(大小写敏感),写成本地化显示名(如中文名或英文全称)会导致条件永远无法为真且不会报错,极难排查。
- 误用于子学说 key 而非轨道 key:本 trigger 的值填的是**轨道(track)**的标识符,而不是某个具体子学说的 key;若想判断某个特定子学说是否被分配,应改用
has_completed_subdoctrine,混用两者是新手最常见的逻辑错误。