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 — in five 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.
Event trigger ⚡	source	A scoring rule fired by a bare game event (no physical device), such as a mode or lifecycle event.
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 (`coil · hold` or `coil · pulse`). Inspect only.
Scoring rule ◆	action	A trigger → score rule. The only editable node.

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

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 toolbox sits open in the canvas’s top-left corner, and keeps its filter and expander state as you switch between the Tags, Flow, and Focus views.

With the live engine attached and a scoring-rule node selected, the toolbar exposes rule-editing commands (all other node kinds are inspect-only):

Command	What it sets
+ Rule	Create a rule — name and trigger (e.g. `device.bumper.hit`) required, points optional.
Rename	Change the rule’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 rule.

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).

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.