Authoring Locations Visibility

Authoring Locations — Visibility Rules

Visibility rules decide whether a section or a map placement is visible at all in the EmoTracker UI. They use the same code/rule syntax as accessibility rules, but they're evaluated differently and applied at different points.

Read Authoring Locations — Accessibility Logic first for the rule string syntax. This page only covers the visibility-specific behavior.

Why visibility rules exist

Some sections aren't meaningful until certain conditions are true. A "Glitched logic only" section shouldn't clutter the popup until the player enables glitched logic; a check that's only available with a specific game-mode setting shouldn't show up in vanilla; a hint location that only matters once a particular item is found shouldn't be in the way before then.

Rather than relying on the player to ignore irrelevant rows, you can give those sections a visibility_rules array that filters them out until the relevant codes are present.

Visibility on sections

Each section in a location can declare its own visibility_rules:

{
  "name": "Glitched chest",
  "item_count": 1,
  "access_rules": [ "moonpearl, [[fakeflippers]]" ],
  "visibility_rules": [ "setting_glitched_logic" ]
}

This section only appears in its location's popup when the code setting_glitched_logic resolves true (typically driven by a script-managed Static item or a layout option).

How section visibility is computed

Parsed in EmoTracker.Data/Locations/Section.cs:RefreshAccessibility. The runtime calls VisibilityRules.AccessibilityForVisibility and treats the section as visible only when the result is >= Normal. Two important consequences:

• Empty visibility_rules means "always visible", not "always hidden". Omit the field entirely if you don't need filtering.
• Inspect is not enough. AccessibilityForVisibility filters out Inspect-level rule results, so wrapping a visibility rule in {...} does not make a section "kind of visible" — it makes it never visible. If you want the section to show up whenever the player can see what it is, use a regular rule, not an inspect modifier.
• Sequence-break and glitch modifiers still work — a [seq-break] visibility rule will make the section appear once the seq-break code is satisfied, just like an access rule.

Invisible sections don't affect their location's accessibility

Sections whose visibility_rules evaluate to "not visible" are skipped when computing the location's overall accessibility. They contribute zero items, zero accessible sections, and zero color decisions. Hiding a section is a clean way to "turn it off" without making the location look partially-cleared.

Visibility on map locations

A location can also be filtered on a per-map-placement basis. Map placements are the entries in map_locations that put a location's icon on a specific map image — see Authoring Locations — Map Placement for the full structure.

There are three independent visibility rule arrays you can attach to a map_locations entry. They're evaluated in a specific order, and each does something different:

Field	Effect
force_invisibility_rules	If any rule passes, the map placement is hidden even if the location is otherwise reachable. Highest priority.
force_visibility_rules	If any rule passes, the map placement is shown even if the location is otherwise inaccessible. Useful for "always-show" overlays the player wants pinned.
restrict_visibility_rules	If any rule passes, the map placement is allowed to be visible. Use this when you want a location's map icon to only show under certain conditions.
visibility_rules	Deprecated. Same as restrict_visibility_rules. Use restrict_visibility_rules for new packs.

Order of evaluation: force-invisible > force-visible > restrict-visible > the location's normal accessibility.

"map_locations": [
  {
    "map": "lightworld",
    "x": 1850,
    "y": 380,
    "restrict_visibility_rules": [ "setting_show_chests" ],
    "force_visibility_rules":   [ "setting_always_show_dungeons" ]
  }
]

This makes the map placement disappear unless setting_show_chests is true, except when setting_always_show_dungeons is true, which forces it to show regardless.

The "Display All Locations" toggle in the EmoTracker main window (mapped to F11) is a global override that ignores most visibility filtering — see the Map Locations user-facing page for what that looks like.

Picking the right field

A small decision tree:

• "I want this section to disappear from the popup unless a code is true." → section visibility_rules.
• "I want this map icon to disappear from a specific map unless a code is true." → map placement restrict_visibility_rules.
• "I want this map icon to always show on a map regardless of accessibility." → force_visibility_rules.
• "I want to hide this map icon under one specific condition even if it's accessible." → force_invisibility_rules.

If a single condition needs to filter both the section and the map placement, set visibility_rules on the section. Map placements automatically disappear when the underlying location has no visible sections.

Tips and pitfalls

• Don't use inspect ({...}) in visibility rules. It's silently dropped by the visibility evaluator and your section will never be shown.
• Use restrict_visibility_rules, not visibility_rules, on map placements. The legacy visibility_rules name still works but is deprecated.
• Stage visibility off code-providing items. A static item with no codes whose codes field is updated by Lua is the cleanest way to wire a runtime "setting" into the visibility system.
• Test the empty case. Removing the visibility_rules field is the simplest way to confirm your rule is wrong vs the section having a totally different problem.
• Hidden sections are still loaded — they just don't render or contribute to logic. There's no performance penalty to filtering aggressively.

See also

• Authoring Locations — top-level format and per-section fields
• Authoring Locations — Accessibility Logic — the rule syntax visibility shares with access rules
• Authoring Locations — Map Placement — full structure of map_locations entries
• Map Locations — user-facing description of how the visibility settings affect what players see
• locations.json schema — authoritative JSON schema