Skip to main content

Building Actions and Conditions in the UI

The Actions and Conditions sections describe the story language at the JSON level. In the editor, you don't need to write JSON by hand — there's a visual builder.

The action builder​

For each command from the actions reference, the editor shows the appropriate field type instead of a bare text field:

  • Granting an item (add/remove) — a dropdown list of items, pulled directly from the backend's (pdanetwork) catalog, plus a quantity. This means item identifiers are always current and match what actually exists in the game — a typo in an id is simply not possible.
  • Changing relations (+/-) — a slider/faction picker and an amount, instead of manually typing the string "relation_4:2".
  • Lua script (script) — a full code editor (CodeMirror) with syntax highlighting — the editor clearly marks this action as being "for advanced users," neither hiding it behind a plain text field nor giving it the same friendly UI as the other actions.
  • The remaining commands (sound, notifications, money, experience) get simple typed fields (a number, text, a track picker).

The condition builder​

Conditions are built on the same principle: a choice between "has an item/flag" (has/!has) with autocomplete from the catalog, and "compare a variable" (picking a variable name — money, xp, or your own — and an operator). This reduces the risk of typos in custom variables, which would otherwise cause a condition to silently stop working.

Why this matters for story quality​

Manually editing a story's "raw" JSON is still possible (import/export on the home page), but the recommended path is the UI builder:

  1. Item ids and the structure of actions are always valid — no need to cross-check the reference manually.
  2. Conditions are visually grouped next to the text/transfer they belong to — the graph is easier to read when you come back to a story after some time.
  3. The editor's validator (StageValidator) flags suspicious spots before you even save.

Next​