Skip to main content

Quest Codex Architecture

The Quest Codex extension operates on a strictly decoupled architecture. Categories, quests, and UI menus are completely separated and only linked via declarative entries.

1. The Core Relationship​

At the heart of the system is the Quest Category. Quests are never hardcoded into menus. Instead, they are assigned to a category.

  1. Quest Category: Defines the identity (e.g., "Main Quests", "Side Quests"), the icon shown in parent menus, and visibility requirements.
  2. Quest Assignment: Takes existing quests from the QuestExtension and assigns them to a specific category. It also determines the order in which they appear.
  3. Quest Lore: Optionally overrides the default lore of a quest based on its status (Not Started, In Progress, Completed).

2. Navigational Defaults & The UI​

The Quest Codex uses the GUI Extension's layout pool system to render everything.

When a player opens a category (e.g., /tw codex main_quests), the extension:

  1. Finds the category_menu linked to that category.
  2. Rewrites every QUEST_SLOT/CATEGORY_SLOT marker into indexed markers (QUEST_SLOT#0, #1, …) so they traverse layout parsing as ordinary tagged slots — this is what lets quest slots live inside scrollable/paginated/frame layouts and follow their viewports.
  3. Parses the Layout Pool and, at render time, swaps each visible marker for its n-th quest/category (icon, per-status lore, click commands). Markers without content render as empty slots.
  4. Injects the sorting button as a fixed overlay at the SORT_SLOT position (it never scrolls away).

3. BlueMap Integration​

The codex automatically syncs with BlueMap (if installed) to display markers for quests.

The integration reads the BlueMapIconEntry definitions mapped to quests and manages their visibility based on the player's progression state.