Files
Fractured/modules/mod-paragon
Docker Build fae3ff5028 Paragon: ship server-side DBC overlay as SQL so fresh installs can roll class 12
Stock Docker installs fill data/dbc/ from the vanilla 3.3.5a extract
in `ac-wotlk-client-data`, which has no class 12 in ChrClasses.dbc and
no class-12 bit on SkillRaceClassInfo.dbc. CharacterHandler.cpp's
sChrClassesStore.LookupEntry(12) returns null and the create fails
with CHAR_CREATE_FAILED ("Class (12) not found in DBC ...") before the
contributor ever sees the panel. Fixing it required hand-copying the
patched DBCs onto the named volume — undocumented, fragile, and not
portable to native installs.

DBCStores.cpp::LoadDBC merges every <table>_dbc world-DB row on top of
the on-disk DBC store (storage.LoadFromDB after storage.Load). We use
that merge layer to ship Paragon's class-12 deltas as SQL:

- chrclasses_dbc: 1 row defining class 12 (Paragon, power=Mana,
  family=Warrior, expansion=2). Resolves CHAR_CREATE_FAILED.
- skillraceclassinfo_dbc: 235 rows REPLACEing stock entries with the
  patched ClassMask (class-12 bit OR'd in) so baseline skills (defense,
  weapon skills, etc.) are available to Paragon characters.

The new `modules/mod-paragon/data/sql/db-world/updates/2026_05_09_00.sql`
is applied automatically by AC's DBUpdater on every fresh `ac-db-import`
run (Docker) or first worldserver boot (native). End-to-end verified
locally: truncate -> docker compose up ac-db-import -> rows reappear
with hash 33B1A05 recorded in updates table.

The migration is auto-generated by
fractured-tooling/from-workspace-root/_gen_paragon_dbc_overlay_sql.py
(outside this repo per the repo-tidy policy). Re-run it whenever the
DBC bake changes.

CLIENT-PATCHES.md is rewritten so contributors no longer need the
manual DBC sync section as their primary install path. Manual overlay
is preserved as a labelled fallback for tools that read data/dbc/
directly.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-05-09 12:19:59 -04:00
..

mod-paragon

Server-side support module for the custom CLASS_PARAGON (id 12).

What it does today

Hooks Player::IsClass / Player::HasActivePowerType so Paragon inherits Death Knight ability mechanics where it matters:

  • Rune system: InitRunes, rune cooldown tick, runic power regen, Spell::CheckRuneCost / Spell::TakeRunePower, SMSG_RESYNC_RUNES cast flags, combat exit grace reset.
  • DK ability scripts: spell_dk_*, MUST_BE_DEATH_KNIGHT cast result, DK aura effects.

It is intentionally narrow: the hook only fires for (realClass == PARAGON, queriedClass == DEATH_KNIGHT, context == CLASS_CONTEXT_ABILITY). Other DK-flavored contexts (Ebon Hold teleport gating, heroic start level, DK-only taxi mount, talent point math on Ebon Hold, etc.) keep their normal behavior for Paragon.

HasActivePowerType additionally claims POWER_RUNIC_POWER and POWER_RUNE for Paragon, which keeps the rune pool sized correctly in Player::InitStatsForLevel even if Paragon's primary power type is later switched away from runic power.

Building

Auto-detected by modules/CMakeLists.txt (GetModuleSourceList globs every subdirectory). No additional CMake plumbing is needed; rebuild the worldserver image and the loader symbol Addmod_paragonScripts gets linked into the static modules target.

SQL layout

SQL files live under data/sql/db-world/base/ and data/sql/db-characters/base/ — the standard AzerothCore module path that the built-in DBUpdater scans (see src/server/database/Updater/UpdateFetcher.cpp). Files placed there are applied automatically by worldserver / dbimport on startup and recorded by hash in the updates table of the target database, so re-runs are idempotent. Any new SQL added under those directories will be picked up on the next container/server start without manual import.