Advanced Event Conditions - A Visual Event Editor Add-On

Advanced Event Conditions

Build complex, dynamic conditions visually with the Visual Event Editor.

Advanced Event Conditions expands the Visual Event Editor with a node-based boolean condition system, allowing you to combine multiple conditions using AND, OR and NOT and build complex logic without turning your events into a maze of nested Conditional Branches.

Conditions are evaluated dynamically at runtime and can be used with Map Events, Troop Events, Common Events, Conditional Branches, Conditional Waits, compatible event-command inputs, and more.

Build Conditions Visually

Connect and combine condition nodes together to create exactly the logic you need, thanks to the three logical operators :

  • AND (all connected conditions must be true)
  • OR (at least one connected condition must be true)
  • NOT (inverts connected condition)

Conditions can be combined and nested freely, letting you create anything from a simple check to complex boolean expressions while keeping the logic easy to read.

Advanced Conditions also includes TRUE, FALSE, and Script nodes for debugging, special cases, and custom JavaScript conditions.

Dynamic Boolean Inputs

Advanced Conditions aren’t limited to event page conditions.

Compatible boolean inputs on event commands (conditional branch, switch, self switch…) can receive a condition graph directly. The condition is evaluated when the command executes, and its result is used as the input value.

On RPG Maker MZ, this also works automatically with compatible Plugin Commands whose arguments are declared as booleans. No special integration/actions is required from the plugin author.

Dynamic Event Conditions

Some conditions depend on values that can change without RPG Maker normally refreshing the event.

Advanced Conditions includes its own refresh system to handle these cases automatically, with controls for changing the refresh mode and interval or requesting a refresh manually when needed.

Conditional Wait

Need an event to wait until something becomes true?

Conditional Wait repeatedly evaluates any Advanced Condition, with separate outputs for:

  • While Unsatisfied
  • Satisfied
  • Timed Out

You can control the evaluation interval and optionally set a maximum number of attempts.

Free Version

The Free version contains the complete Advanced Conditions core system.

It includes :

  • AND, OR and NOT
  • TRUE and FALSE
  • Script conditions
  • Native RPG Maker conditions
  • Conditional Wait
  • Dynamic event conditions
  • Refresh controls
  • Compatible dynamic boolean command inputs
  • Automatic MZ Plugin Command boolean support

Full Version

The Full version contains everything from the Free version, plus over 120 ready-to-use condition nodes covering areas such as :

  • Actors, classes, skills, equipment, states and parameters
  • Party and inventory
  • Enemies, troops and battle state
  • Events and characters
  • Maps, regions, terrain and tiles
  • Player and vehicle state
  • Timer and system information
  • Input and screen state
  • Database data and notetags
  • Distance and position checks
  • And more

Many advanced conditions also support dynamic designations, allowing their targets or comparison values to come from direct values, game variables, or JavaScript expressions.

The goal of the Full version is simple: give you ready-made nodes for common checks instead of making you recreate them with Script conditions.

Requirements & Compatibility

Requires Visual Event Editor (last version).

Compatible with:

RPG Maker MV
RPG Maker MZ

Some features naturally depend on engine capabilities. In particular, automatic typed Plugin Command argument support is available on RPG Maker MZ.

Installation

  1. Install the latest version of the Visual Event Editor.
  2. Download the latest version of this add-on from this page.
  3. Place the downloaded archive (.zip) AT THE ROOT OF YOUR PROJECT (next to your .rpgproject or .rmmzproject
  4. Add & enable Drag_VisualEvent_AdvancedEventConditions in the Plugin Manager.
  5. Launch a playtest and open the Visual Event Editor.
  6. Check the Visual Event Editor Add-Ons menu to make sure this add-on is installed (or check if the new node commands appear in the node list).
  7. Have fun !

Download

Stay safe and happy game dev’ ! :]

4 Likes

This is a genuinely useful direction. Nested Conditional Branches are where event logic goes to die and a visual boolean graph is the right answer to it.

One thing I’d want nailed down in the docs before anyone builds a long game on this. MZ only evaluates event page conditions again when something calls requestRefresh. Core fires that on switch and variable changes and on a short list of party events. It does not fire when actor HP moves or when gold changes or when some script value your condition reads happens to change. So a graph that reads anything outside switches and variables is correct at the instant the page refreshes and then quietly stale until an unrelated switch forces the next refresh. The event sits on the wrong page and from the outside it looks like your condition is simply broken.

There are two ways out and they trade off differently. Either restrict condition nodes to the state core already invalidates on. Or track which conditions read volatile state and call requestRefresh yourself when that state moves. The second is far more powerful and it costs a refresh every time the value changes so it’s worth making it opt in per condition rather than switching it on globally.

The other one is short circuit evaluation. If AND stops at the first false node then a script node further down the chain never runs at all. That’s usually what you want for speed but it makes any script node with a side effect fire inconsistently. Whichever way you went it’s worth a line in the docs because people will absolutely put side effects in there.

Does the editor reject cycles? A graph that lets an output reconnect to an input upstream can hang the evaluator and that is a genuinely horrible thing to diagnose from inside a running game.

1 Like

Hello CSAF and thank you for your comment. :slight_smile:

To answer your questions :

  • This plugin does not call requestRefresh on every values / data states change that are part of the plugin conditions, because that would mean monkey patching a lot of different corescript functions and dramatically increase the risk of plugin conflicts or incompatibilities, especially since some values does not have getter / setter accessors natively.
    Instead, it setup a periodic requestRefresh that run every x amount of frames (30 by default). There is a command to change the frame interval amount (if one need to make this system more or less responsive). There is also a command to call for a requestRefresh directly, as well as a mode to disable this periodic requestRefresh call (and only rely on manual calls).
  • Yes, this plugin support short circuit evaluation, just like Javascript, for performance. So you are right, one should not use the script condition to anything but condition evaluation. It would be bad practice anyway.
  • Yes, the editor reject cycle for conditions. It shouldn’t be possible to make one anyway, but the editor will throw an error in the console if one manage to create a cycle with condition nodes.

All of this should already be written in the plugin help / description or on the node tooltip descriptions, unless I forgot. :slight_smile: