Rules Editor

The Rules Editor draws a table’s rules as a node graph so you can see how the machine reacts to play. It shows two families of rule side by side — autofire rules (a switch driving a coil, like a flipper button firing the flipper coil) and scoring rules (a trigger awarding points and changing game state) — plus the tag groups that bundle devices together. Against the live engine you can also author scoring rules directly, with undo/redo.

The graph mirrors the table’s real rules: you don’t hand-draw connections, and the shape is derived, not free-form. See Node Editor Basics for the shared canvas gestures.

What the nodes mean

Nodes sit in two bands — sources on the left, actions on the right. The four foundational kinds:

Node	Kind	Meaning
Device trigger ⊙	source	A switch or device that fires a rule — an autofire switch (`hold`/`pulse`) or a scoring rule’s device slot.
Tag group ◈	hub	A named bundle of devices from the table’s tag groups; the subtitle counts its members.
Coil action ⊗	action	The coil an autofire rule fires (`pulse · coil` or `hold · coil`). Inspect only.
Scoring rule ◆	action	A trigger → score rule. The only editable node.

A scoring rule fired by a bare game event rather than a device — a mode starting, a timer elapsing, another rule’s emit — is still drawn as an ordinary Scoring rule node; it simply has no incoming line from a device trigger, since there’s no device to draw one from.

A tag group that no rule references is shown muted, parked in a lane below the connected graph so it’s clearly unused.

Depending on how the table’s scoring is built, the graph can also surface further node kinds drawn from the engine’s wider scoring vocabulary. All of these are inspect-only, each colored by its own category:

Node	Meaning
Module ▣	A self-contained game feature bundling mode behavior, scoring, variables, and event handling.
Mode ◑	A game-flow state nested in a module, with priority-based stacking.
Variable ≔	A declared value other rules and conditions read.
Signal ⊛	Shot/combo/sequence switch-pattern detection.
Aggregation ⊞	Burst/coincidence/rate detection over device events.
Flow ⟶	Event-flow orchestration — sequence, parallel, conditional, accumulator, timed, or state-machine.
Accumulator ⊕	Collects points toward a sequence, progressive, or threshold payout.
Score modifier ±	A conditional or timer-driven variable change — also where a scoring timer lives.
Event handler ↦	Responds to a device or signal event with actions.
Interaction context ⇄	A reusable input/output scheme remapping physical switch edges to logical actions.

View modes

The toolbar’s segmented control switches how the same rules are laid out:

◈ Tags (default) — device groups → the actions they drive; unused tag groups sit in a muted lane below.
⟶ Flow — role bands left-to-right (sources → actions); each rule reads as one horizontal line.
◎ Focus — the selected node plus only its direct neighbors. In Focus mode, clicking any node re-centers on it. Right-clicking a node and choosing Focus ◎ also enters this view, pinned on that node.

A filter box narrows the graph to nodes matching your text (pulling in their direct neighbors so edges still make sense) and shows a “N shown” count. Node positions you drag are remembered per view and per table until you choose Reset layout (from the ⚙ Options menu or the empty-canvas context menu, which also offers Fit to view ⤢).

Live vs. sample

Normally the graph reads the running table. Append ?sample to the page URL to load a fixed illustrative sample instead — useful for looking around the interface without touching a real table. Editing is live-only: in sample mode the authoring buttons don’t appear and the page is a pure viewer, which is the quickest way to tell which one you’re in.

When the Rules Editor is docked inside the 3D geometry editor, selection is two-way linked: clicking a node highlights its devices in the scene, and selecting devices in the scene lights the matching nodes. A non-dismissible amber warning appears if a rule references a device the geometry editor no longer has.

Authoring scoring rules (live)

The add-node palette lives in the editor’s left-hand drawer, and keeps its filter and expander state as you switch between the Tags, Flow, and Focus views. Beside scoring rules, it can add a device — grouped by type — or a tag member, each from its own short form.

With the live engine attached, Delete and Rename act on whichever scoring rule, device, or tag group is selected; the remaining commands are scoring-rule-specific and stay disabled otherwise:

Command	What it sets
+ Rule	Create a rule — name and trigger (e.g. `device.bumper.hit`) required, points optional.
Rename	Change the selected rule’s, device’s, or tag group’s name.
Points	The score awarded (e.g. `1000`).
Condition	A gate expression like `var.frenzy_active > 0`; blank = always fires.
Emit	An event to emit after scoring, like `event.jackpot_lit`; blank = none.
Updates	One `var = expr` per line (e.g. `combo = var.combo + 1`); blank clears all.
Delete	Remove the selected rule, device, or tag group.

Copying and duplicating (Ctrl/Cmd+C / +D) are scoped to a selected scoring rule — the one node kind with a well-defined, copyable set of fields; a device or tag group has no copy gesture yet.

With a scoring rule selected, its trigger, points, condition, emit, and updates are also editable rows in the Details rail — type into a row and the value applies a moment later, with a refusal landing on the field it belongs to rather than as one banner for the whole rule. That is what replaced the old double-click-to-re-point gesture and its Edit trigger menu entry: both opened an unthemed prompt that left the editor’s own shortcuts live underneath it, and neither is there any more.

Right-clicking any node opens a context menu with Focus ◎ (enter Focus view on it), Copy rule string ⧉, and Reset this node’s position ⤺ (disabled until you’ve moved it); right-clicking a device that carries one or more tags also adds a Remove from tag entry.

Edits are validated by the engine. A rejected edit surfaces the engine’s exact reason in a red banner and the graph re-renders from what the engine actually accepted — so the diagram never drifts from reality. Undo (Ctrl/Cmd+Z) and Redo (Ctrl/Cmd+Shift+Z) cover every edit, including add and delete.

Tip — in the Condition, Emit, and Updates forms, an empty field clears that aspect of the rule; canceling the dialog leaves the rule untouched.

The Source view

The details pane has an opt-in Source tab that shows the selected node’s actual .cade text, syntax-highlighted the same way this site renders HCL. It is scoped to what you selected: a scoring rule or device shows its own block, an autofire rule shows the device block it derives from, and a tag group shows the blocks of the devices carrying the tag. Rules authored as one long line are displayed expanded across lines so they read on the narrow pane.

Where the view is a real, contiguous block — a rule’s or device’s own — it’s editable: change the text and Save writes it back through the same engine validation as every other edit, undoable with the same Ctrl/Cmd+Z, and a rejected save reports the engine’s reason instead of corrupting the table. The derived and tag-group views are stitched together from several places, so they stay read-only and say so. The Source tab only appears against the live engine — in sample mode the details pane shows fields only.

For the full .cade rule syntax the blocks are written in, see the score primitive reference.