Common pitfalls
This page catalogs the snags writers most often trip over. Each entry starts with what you may see in the editor or simulator, explains the feature producing it, and links to the page that owns the mechanics. Every entry is a feature working as designed, not a bug. For messages the panel surfaces as Errors or Warnings, see Error messages.
1. I don’t see my node as a choice
A node with an empty Visible when is always hidden. The player never sees it as a choice, and it only runs if another node jumps into it. Logic nodes are built on that rule on purpose. The pitfall shows up when a writer clears Visible when on a node they still expect players to pick, then wonders why it never appears.
Set Visible when to a condition that will be true when the node should appear. Writing true makes it always visible; writing a condition like Played(node_a) gates it on state. If the node is meant to run as an intermediate step in the flow, wire an inbound Jump from a visible node instead. See Nodes and visibility.
2. My other choices vanish after I pick one
Either Exclusive selection resolves on for the unpicked siblings, in which case each of them is consumed the moment the pick fires. Or the picked node’s events mutated state that a sibling’s Visible when reads from, and the condition is no longer true once the pick has fired.
Check Exclusive selection on the sibling that vanished, then on its scene, then at the project default; the first of those set to something other than inherit decides whether that sibling is consumed. If exclusive selection isn’t the culprit, re-read each sibling’s Visible when and think about which variables the picked node’s events touched. See Evaluation cycle: exclusive selection.
3. My scene has no visible choices
When a scene activates, the runtime evaluates every node’s Visible when and shows the ones whose condition is true. If the scene’s intro node is unset and no other node’s Visible when is true at activation, nothing appears. Same result when every node’s condition is false at the moment the player arrives: the choice panel stays empty and the scene may exhaust immediately.
Open the scene inspector and set the intro node. If an intro is already set but the panel is still empty, check each node’s Visible when against the state at activation time. When a scene exhausts, its On exhausted node fires; pointing that at a fallback node is another way to handle the empty case. See Scenes and visit state.
4. My scene’s intro keeps re-firing
Every time a scene activates, the runtime opens a fresh visit. Inside that visit, Played, Selected, and Seen reset. So an intro node gated on a check like Played reads false again when the player comes back to the scene, and the intro fires as if it were the first time. Per-visit scoping is the intended behavior; whole-run history lives in the *Ever variants.
Use PlayedEver, SelectedEver, or SeenEver for anything that should stay decided across re-entries. Those variants read from the whole-run history rather than the current visit, so an intro that has already fired once will stay gated when the scene re-activates. See Scenes and visit state.
5. I don’t see my encounter at this location
Four things gate an encounter’s appearance at a location, and all four must line up. The scene has to be listed in the location’s Encounters section. Its Trigger has to be set to something other than (none); a fresh scene starts at (none), and the runtime silently drops encounters whose scene has no trigger. The location row’s Visible at this location when has to evaluate true. And the scene’s own Visible when has to evaluate true too. The location field gates “this encounter here”; the scene field gates “this encounter everywhere.” Either one evaluating false hides the encounter.
Open the location inspector and confirm the encounter is in its Encounters section. If it’s there, jump to the scene and confirm its Trigger isn’t (none). Then check Visible at this location when on the location’s row, and Visible when on the scene inspector. One of the four is likely off. See Encounters and Locations.
6. I can’t move to a location I expected to see
Connections are directional. A connection from A to B does not create a connection from B to A. Two-way movement needs the reverse Connection added on the destination location as well. The other cause is a per-connection Visible when that evaluates false at the moment the player is at the source: the connection exists, but the runtime hides it.
Open the source location’s inspector and confirm a Connection entry lists the target as its destination. If the connection is there, read its Visible when against the current state. For two-way travel, add the matching reverse Connection on the destination location too. See Locations and World layer: moving between locations.
7. Switching locales doesn’t change my text
The runtime falls back to source text whenever a string has no override in the active locale, and it does so silently. Common shapes: the string was authored after the locale file was exported, so the key isn’t in the overlay yet. The override was saved under the wrong entity uuid. The source text was edited after the translation shipped and the overlay’s stale copy hasn’t been re-saved.
Open the localization table view to see which keys have no override in the target locale, or run the simulator against the target locale and look for the untranslated highlight on message rows. Cmd/Ctrl-click a highlighted row to jump straight to its locale entry. See Localization.