脚本目录

plugins/DungeonMaster/脚本/ 当前更适合拿来做脚本素材库。

第一次生成配置时，插件会在这里放一份 说明.yml。这份默认文件里有一句旧注释，写的是“副本配置中可通过 脚本: "文件名" 引用”。但按当前主流程源码来看，我没有看到“独立脚本文件被正式加载并按文件名统一执行”的稳定入口，所以这页文档不把它当成正式的副本执行仓库来写。

对服主来说，最稳的理解很简单：

• 这里适合存脚本模板、片段、草稿和团队备注
• 真正要跟副本一起跑的脚本，还是放回各自配置字段里

当前源码能确认的边界

目前能明确确认的只有这些：

• 插件启动时会导出 脚本/说明.yml
• /dm script 执行的是你命令里直接输入的脚本文本
• 副本运行时真正执行的脚本，主要还是来自各个 yml 配置字段

我没有在当前运行时主链里看到这些能力：

• 启动时扫描 脚本/ 目录并注册脚本 ID
• 在副本配置里写一个文件名，运行时自动到 脚本/ 目录读取再执行
• 修改 脚本/ 下文本文件后，副本运行时自动重载

这页按当前已经确认的行为来写，旧注释没有直接当成正式功能处理。

这个目录更适合干什么

• 存常用脚本片段
• 存不同玩法的模板脚本
• 存团队共用的变量命名约定
• 存开门、刷怪、发奖、状态控制这类成品范例
• 存运营期常用的人工处理脚本

如果你有多个策划或配置人员一起维护副本，这个目录会很好用。长脚本先在这里整理，再回填到正式配置，效率会高很多。

当前版本更稳的实际用法

DM 现在的脚本主要还是写在这些地方：

• main.yml 的事件绑定和通关条件
• 阶段.yml 的开始脚本、通关脚本
• 区域.yml 的进入脚本、离开脚本
• 怪物组.yml 的生成脚本、全灭脚本
• 奖励.yml 的奖励脚本
• 模块.yml 里的保护、复活、玩法模块脚本
• 交互.yml、全息.yml 的触发脚本

临时人工执行则走 /dm script。

也就是说，这个目录当前更像“脚本工作区”，不是“副本直接引用的主配置目录”。

推荐整理方式

目录不用搞得很复杂，按用途拆就够了。

plugins/DungeonMaster/脚本/
├─ 阶段模板/
├─ 奖励模板/
├─ 交互模板/
├─ 运营处理/
└─ 说明.yml

文件名尽量一眼能看懂，比如：

• Boss房开门.txt
• 通关奖励补发.txt
• 暴雪阶段循环示例.txt
• 副本失败统一清理.txt

适合放在这里的内容

长脚本草稿

有些脚本一开始会比较长，直接塞进 yml 不方便改，也不方便团队一起看。

这种脚本先在这里整理最省事。定稿以后，再回填到对应配置里。

可复用模板

比如你服里很多副本都会用到：

• 清怪后开门
• 倒计时刷 Boss
• 通关后发提示和播报
• 失败后统一清 Buff

这些都适合在这里存一份模板，后面复制改名直接用。

运营处理脚本

运营期经常会遇到一些临时处理：

• 手动补奖励
• 手动开门
• 手动推进阶段
• 手动清变量

这类脚本很适合先存在这里，再通过 /dm script 按需执行。

例如你可以在这里放一份运营脚本草稿：

副本.设置变量("Boss已开启", true)
障碍物.关闭("Boss门组")
消息.全体("&e已手动开启 Boss 房")

真正执行时，再把脚本内容整理后通过 /dm script 输入，或者回填到正式配置字段里。

不建议把它当成什么

当前版本不建议把这个目录当成：

• 独立脚本热更新系统
• 副本核心逻辑统一引用库
• 改完文件就会自动生效的正式执行入口

按现在的源码边界，副本真正执行的脚本仍然主要来自各个配置字段本身。

最省事的工作流

推荐这样用：

1. 先在 脚本/ 里写草稿和模板
2. 确认逻辑没问题后，复制回正式配置
3. 临时排查或运营处理时，再用 /dm script 手动执行

这套工作流带来的实际收益有：

• 正式副本配置仍然集中
• 团队协作时有地方沉淀脚本素材
• 排错和改版时不会到处找脚本正文

维护建议

• 长脚本旁边顺手写两行用途说明，后面回头看很值。
• 变量名、区域名、怪物组名尽量和正式副本保持一致，复制回去时不容易改漏。
• 一个文件只放一类脚本，别把十几段不相关的内容堆在一起。
• 已经废弃的脚本及时移走，不要让目录越堆越乱。

下一步阅读

• 脚本概览
• 脚本命令
• main.yml