高级事件条件——可视化事件编辑器插件

RPG 制作大师 插件
, , ,
1

高级条件

通过可视化事件编辑器，以可视化的方式构建复杂、动态的条件。

高级事件条件 为 可视化事件编辑器 增加了基于节点的布尔条件系统，允许你使用 与 (AND)、或 (OR) 和非 (NOT) 组合多个条件，从而构建复杂的逻辑，而无需将事件变成嵌套条件分支的迷宫。

条件在运行时动态求值，可与 地图事件、 troop 事件、公共事件、条件分支、条件等待、兼容的事件命令输入 等配合使用。

可视化构建条件

借助三种逻辑运算符，连接并组合条件节点，创建你所需的精确逻辑：

  • 与 (AND)（所有连接的条件必须为真）
  • 或 (OR)（至少一个连接的条件为真）
  • 非 (NOT)（反转连接的条件）

条件可以自由组合和嵌套，让你既能创建简单的检查，也能创建复杂的布尔表达式，同时保持逻辑易于阅读。

高级条件还包括 真 (TRUE)、假 (FALSE) 和 脚本 (Script) 节点，用于调试、特殊情况以及自定义 JavaScript 条件。

1801×1145 159 KB

动态布尔输入

高级条件不仅限于事件页条件。

兼容事件命令中的布尔输入（条件分支、开关、自开关等）可以直接接收条件图。条件在命令执行时求值，其结果作为输入值使用。

1407×1217 202 KB

在 RPG Maker MZ 上，这也自动适用于参数声明为布尔值的 兼容插件命令。插件作者无需进行特殊的集成或操作。

动态事件条件

某些条件依赖于那些 RPG Maker 通常不会自动刷新事件的值。

高级条件包含自己的刷新系统，以自动处理这些情况，并提供控制以更改刷新模式和间隔，或在需要时手动请求刷新。

条件等待

需要事件等待直到某事变为真吗？

条件等待 会反复求值任何高级条件，并提供以下单独的输出：

  • 未满足时 (While Unsatisfied)
  • 已满足 (Satisfied)
  • 超时 (Timed Out)

你可以控制求值间隔，并可选地设置最大尝试次数。

968×607 51.5 KB

免费版

免费版包含 完整的高级条件核心系统。

其中包括：

  • 与 (AND)、或 (OR) 和非 (NOT)
  • 真 (TRUE) 和 假 (FALSE)
  • 脚本条件
  • 原生 RPG Maker 条件
  • 条件等待
  • 动态事件条件
  • 刷新控制
  • 兼容的动态布尔命令输入
  • 自动 MZ 插件命令布尔支持

完整版

完整版包含 免费版的所有内容，以及超过 120 个即插即用的条件节点，涵盖以下领域：

  • 角色、职业、技能、装备、状态和参数
  • 队伍和物品栏
  • 敌人、部队和战斗状态
  • 事件和角色
  • 地图、区域、地形和图块
  • 玩家和载具状态
  • 计时器和系统信息
  • 输入和屏幕状态
  • 数据库数据和备注标签
  • 距离和位置检查
  • 以及更多

许多高级条件还支持 动态指定，允许其目标或比较值来自直接值、游戏变量或 JavaScript 表达式。

完整版的宗旨很简单：**为你提供现成的节点用于常见检查，而不是让你用脚本条件重新创建它们。

1390×990 94.4 KB
**

要求与兼容性

需要 可视化事件编辑器（最新版本）。

兼容：

RPG Maker MV
RPG Maker MZ

某些功能自然依赖于引擎能力。特别是，自动类型的插件命令参数支持仅在 RPG Maker MZ 上可用。

安装

  1. 安装最新版本的 可视化事件编辑器。
  2. 从 此页面 下载此插件的最新版本。
  3. 将下载的压缩包 (.zip) 放在 项目根目录（与 .rpgproject 或 .rmmzproject 同级）。
  4. 在插件管理器中添加并启用 Drag_VisualEvent_AdvancedEventConditions。
  5. 启动测试运行并打开可视化事件编辑器。
  6. 检查可视化事件编辑器插件菜单，确保此插件已安装（或检查新节点命令是否出现在节点列表中）。
  7. 玩得开心！

下载

注意安全，享受游戏开发！ :]

4 个赞
2

这是一个真正有用的方向。嵌套的条件分支是事件逻辑的“坟墓”，而可视化的布尔图才是解决这一问题的正确方案。

在任何人基于此构建大型游戏之前，我希望文档中能明确以下几点。MZ 仅在调用 requestRefresh 时才会重新评估事件页的条件。核心系统会在开关（switch）和变量（variable）发生变化，以及某些特定的队伍事件发生时触发该刷新。但是，当角色生命值（HP）变化、金币数量变化，或者条件所读取的某个脚本值发生变化时，它并不会触发刷新。因此，一个读取了开关和变量之外状态的图，仅在页面刷新的瞬间是正确的，随后就会静默地变得过时，直到某个无关的开关强制触发下一次刷新。此时，事件会停留在错误的页面上，从外部看来，就像是你的条件判断完全失效了。

有两种解决方案，它们各有利弊。一种是限制条件节点仅使用核心系统已在触发刷新时失效的状态。另一种是追踪哪些条件读取了易变状态，并在该状态发生变化时手动调用 requestRefresh。第二种方式功能更强大，但每次值变化都会触发一次刷新，因此值得将其设计为按条件单独启用，而不是全局开启。

另一种情况是短路求值。如果 AND 运算在遇到第一个 false 节点时就停止，那么链中更靠后的脚本节点将完全不会运行。这通常有利于提升速度，但会导致具有副作用的脚本节点以不一致的方式触发。无论你选择哪种方式，都建议在文档中添加一行说明，因为人们肯定会把副作用代码放进去。

编辑器会拒绝循环吗？如果一个图允许输出重新连接到上游的输入，可能会导致评估器挂起，而在运行中的游戏内部排查这个问题是一件非常糟糕的事情。

2 个赞
3

你好，CSAF，感谢你的评论。:slight_smile:

回答你的问题：

  • 该插件不会在插件条件相关的每个值/数据状态变化时调用 requestRefresh，因为这意味着需要 大量 地 monkey patch（猴子补丁）不同的核心脚本函数，并且会显著增加插件冲突或不兼容的风险，尤其是因为某些值原生并没有 getter/setter 访问器。
    取而代之的是，它设置了一个周期性的 requestRefresh，每 x 帧运行一次（默认为 30 帧）。有一个命令可以更改帧间隔（如果需要让这个系统更灵敏或更迟钝）。还有一个命令可以直接调用 requestRefresh，以及一个禁用周期性 requestRefresh 调用的模式（仅依赖手动调用）。
  • 是的，为了性能考虑，该插件支持短路求值，就像 JavaScript 一样。所以你说得对，脚本条件只应用于条件评估，而不应用于其他用途。从最佳实践的角度来看，这也是不恰当的。
  • 是的，编辑器会拒绝条件的循环。无论如何，本就不应该出现循环，但如果有人设法用条件节点创建了一个循环，编辑器会在控制台中抛出错误。

以上所有内容应该都已经写在插件的帮助/描述或节点的工具提示描述中了，除非我忘了。:slight_smile:

1 个赞