Common Pitfalls

This page is a debugging checklist. If a field, behaviour, or layout isn’t working the way you expect, scan the symptoms below — chances are you’ll find your problem here.

My calculated field is empty

The most common headache. A few possible causes:

A field referenced in the formula is empty

If your formula is add(strength, intelligence) and strength is empty, the result is empty (not zero). The system treats missing values as missing, not as zero.

Fix: wrap the field with coalesce to give it a default. add(coalesce(strength, 0), coalesce(intelligence, 0)).

The formula references a renamed or deleted field

If you renamed a field after writing the formula, the old name in the formula no longer matches anything.

Fix: open the auto-calculate behaviour and update the formula. The Behaviours editor flags fields that don’t exist; the warning is easy to miss.

Division by zero (or near-zero)

divide(total, count) when count is empty or zero returns nothing.

Fix: wrap the division so it falls back to 0 when count is missing or zero:

if(coalesce(count, 0), divide(total, count), 0)

In plain English: use count (or 0 if it’s empty); if that value is non-zero, divide; otherwise, 0. This handles both the empty case and the literal-zero case in one expression.

The formula uses a function that doesn’t exist

A typo in the function name will fail validation when you save. If somehow it slipped through, the result is empty.

Fix: open the formula, look for any function that isn’t in the Formulas reference list. Use the function picker on the right of the editor to insert a known function.

My aggregation is showing the wrong number

Wrong relationship direction

If you set up “count of children” as PARENT_OF outgoing but the children’s relationship was created as PARENT_OF from the parent → child (so it’s outgoing from the parent’s perspective), this is correct. But if you set up “count of parents” with the same direction, you’d actually want incoming.

Fix: mentally re-read the direction. If your entity is at the source end of the relationship, use outgoing. If it’s at the target end, use incoming.

Relationship types differ from what you typed

The aggregation editor accepts custom rel-type names, but it validates them against your world’s relationship types. If you typed OWN instead of OWNS, the editor catches it at save time. Older saved aggregations might still reference relationships that have since been deleted — those return zero matches with no warning.

Fix: open the behaviour, check the relationship name against Management → Relationship Types. Update if needed.

Counting across the wrong direction

A symmetric relationship like ALLIED_WITH should use direction both to catch links in either direction. Using only outgoing or incoming will miss half the matches.

Fix: for symmetric relationships, use both.

The target field doesn’t exist on the related entities

If your aggregation sums value across owned items, but the Item type has no value field (or it’s named differently), the sum is empty.

Fix: check the field name on the target entity type, not on this one. The picker in the editor only shows this entity’s fields, but the validator allows any field name — be careful with custom names.

My lookup is showing my own value

You set up a lookup like “show the spouse’s location” with the relationship MARRIED_TO, and the result is your own location. What’s happened:

• MARRIED_TO is a symmetric relationship.
• A symmetric one-hop walk goes out to the spouse and the spouse’s MARRIED_TO link points back to you.
• The lookup ends up reading from yourself.

The editor flags this as an amber warning when you set up the lookup, but the warning is easy to miss.

Fix: add another hop, use a different relationship, or accept the limitation. There’s no clean way to do “spouse’s location” with a single-hop symmetric relationship.

My template shows {field_name} literally

The placeholder is appearing as the literal string instead of the field’s value.

The field doesn’t exist

If the field has been renamed or deleted since the template was written, the placeholder doesn’t resolve. The editor catches this at save time and rejects the save with a clear list of the unknown placeholders.

Fix: update the template to use the new field identifier.

The placeholder has unsupported characters

Templates only support placeholders matching the pattern {word} or {word.subword}. Things like {has-dash}, {has space}, or {0} are treated as literal text by the system, not as placeholders. They appear unchanged in the result.

Fix: rename the field to use only letters, numbers, and underscores.

You’re using an old “expression” calculation

There’s a legacy “calculation” behaviour kind that uses a different syntax. If your behaviour is using it, templates with {field} work, but other things don’t. The modern path is auto-calculate with calculation type Template.

Fix: delete the old behaviour and add an auto-calculate behaviour with calculation type Template.

My visibility rule isn’t hiding the field

The field is in a layout but the rule says hide

Layouts decide where a field goes; visibility rules decide whether it shows up. A field can be in a layout and hidden by a rule — the rule wins.

Fix: if you expect the field to be hidden, double-check the rule’s condition is actually true for your test entity.

The condition references a field with no value

A condition like subtype equals "Protagonist" returns false when the entity has no subtype set. So a “show this when subtype = Protagonist” rule won’t show the field on a fresh entity.

Fix: if the field should show by default, use a different rule shape. For instance: action Hide with condition subtype equals “NPC” hides only when subtype is NPC.

Two rules are fighting

If you have a “show when X” and a “hide when Y” on the same field, both can be triggered at once. Whichever has higher priority wins.

Fix: simplify to one rule, or set priorities explicitly. The simpler the rule layer, the easier it is to debug.

My behaviour caused a circular dependency

You set up auto-calculation for field A using a formula that includes field B. Then you set up B with a formula that includes A. The system can’t compute either — they each need the other to be done first.

Fix: break the cycle. One of the fields should be the input (typed by the user); the other should be derived from it.

My formula stopped working after I renamed a field

When you rename a field’s identifier, the rename doesn’t update any formulas, templates, or visibility rules that reference the old name. They start failing silently.

Fix: before renaming, search the type’s behaviours for the old field identifier. Update each reference, then rename the field. The editor doesn’t have a global find-and-replace yet — manual sweep is required.

My layout is showing a field twice

The layout structure shouldn’t normally allow this — the unassigned-fields panel filters out already-placed fields. But it can happen if:

• The layout was edited in a way that bypassed the panel.
• A type was customised by code or import.
• A bug introduced a duplicate.

The Layout editor flags duplicates with an amber warning when you open it. Save isn’t blocked — autosave continues — but you’ll want to clean up.

Fix: find the duplicate and remove one copy. Drag it back to the unassigned panel, then delete the empty placeholder it left behind.

I deprecated a type but the entities are still showing up in lists

Deprecated types do still show their entities in lists (they’re not deleted, just locked). They’re marked with a “Deprecated” badge.

Fix: if you want them out of lists, filter the list by type and exclude the deprecated one. Or hard-delete with the “delete all entities” strategy if you’re sure.

Where to go next

Auto-Calculated Fields Step back and pick the right calculation kind.

Visibility Rules The full reference for the conditions and combiners.

World Customisation Safe ways to change a type that's already in use.