条件表达式

DM 里的 条件 本质上是一条返回真假的表达式。

它最常出现在这些地方：

• main.yml -> 进入条件
• main.yml -> 通关条件
• 阶段.yml -> 通关条件
• 阶段.yml -> 下一阶段.条件
• 交互.yml -> 条件
• 全息.yml -> 条件 / 显示条件
• 各类模块、掉落、词缀、评级里的 条件

最稳的理解方式

• 条件里优先写读取型内容
• 想改状态、发奖励、推进流程，回到脚本里做
• 一条条件只负责“过”或“不过”

最常见的写法就是一条表达式字符串：

通关条件: '阶段.全部完成()'

判定规则

源码当前按下面这套规则把结果转成真假：

• true 算通过，false 算不通过
• 数字里，0 算不通过，非 0 算通过
• 字符串里，空文本、false、0 算不通过
• null 算不通过
• 其他非空对象，按通过处理

实际写条件时，直接让表达式返回布尔值最清楚。

常见写法

直接比较

条件: '@player.level >= 30'

读副本变量

条件: '副本.读取变量("Boss房已开放") == true'

读阶段状态

通关条件: '阶段.全部完成()'

读怪物组状态

通关条件: '怪物组.全灭("Boss组")'

进入条件 怎么写

main.yml 里的 进入条件 当前最稳的写法是按名字挂多个区块：

进入条件:
  等级限制:
    条件: '@player.level >= 30'
    拒绝提示: '&c需要达到 30 级'

当前进本流程会这样处理：

• 每一项都检查
• 任意一项没过，就拦住进本
• 拒绝提示 会发给没通过的玩家

通关条件 怎么写

main.yml 和 阶段.yml 里最稳的写法，都是直接写一条表达式：

通关条件: '阶段.全部完成()'

阶段里也可以写：

通关条件: '怪物组.全灭("第一波")'

旧项目里的 完成条件 目前也还能认。

下一阶段 分支条件

分支阶段常见写法：

下一阶段:
  - 目标: 困难Boss
    条件: '副本.读取变量("困难模式") == true'
  - 目标: 普通Boss

当前处理顺序是：

• 按列表顺序检查
• 第一个成立的条件直接命中
• 都没命中时，再走无条件兜底分支

复合条件

少数模块配置额外支持“条件区块”写法，可以把多条条件合在一起：

条件:
  模式: 全部满足
  条件列表:
    - '@dungeon.alive == @dungeon.player_count'
    - '@dungeon.elapsed <= 600'

当前支持的模式有：

• 全部满足
• 任一满足
• 全不满足

英文别名也能认：

• all
• any
• none

如果你只是写 main.yml、阶段.yml、交互.yml 这些常规配置，优先还是用单条表达式，简单直接。

上下文怎么选

条件能不能用 @player.*、玩家名()、AM读取() 这类玩家相关内容，取决于当前触发点有没有玩家上下文。

可以直接按这个原则记：

• 玩家进本检查、玩家触发交互、玩家可见全息，这些通常有玩家上下文
• 副本总通关、全局阶段推进、无玩家的后台判断，这些不要强依赖玩家上下文

拿不准时，优先写副本级状态：

• 副本.读取变量(...)
• 阶段.全部完成()
• 怪物组.全灭(...)
• @dungeon.*

什么时候不要往条件里塞东西

这些内容不要放进 条件 里：

• 发奖励
• 开门
• 刷怪
• 发消息
• 改变量
• 扣物品

条件只负责判断。
真正要执行动作，回到脚本字段里写。

常见问题

条件明明写了，但就是不触发

先查这几项：

• 这条条件所在的位置，当前有没有对应上下文
• 字段名是不是写成了脚本字段
• 变量名、阶段名、怪物组名有没有写错
• 表达式结果最终是不是布尔真值

一段逻辑既要判断又要执行动作

拆开写。

• 条件里只留判断
• 脚本里再写动作

这样后面排错最快。

下一步阅读

• main.yml
• 阶段.yml
• 事件绑定
• 脚本概览