Files
Fractured/modules/mod-paragon
Docker Build 5deb9e3255 Paragon: ship class-12 starter spawn data so character creation works on fresh installs
Companion to 2026_05_09_00.sql (DBC overlay). The DBC overlay teaches
the world server that class 12 (Paragon) exists; this migration
teaches it WHERE class-12 characters spawn, what action bar they boot
with, and what per-level base stats Player::InitStatsForLevel uses.

Without these rows, contributors hit:
  - Player::Create -> "invalid race/class pair (R/12) - refusing"
    and the client shows "Error creating character".
  - WorldServer load -> "class-12 Level-L does not have stats data!"
    integrity warnings.

Tables touched (idempotent: DELETE WHERE class=12 then INSERT):
  - playercreateinfo         : 10 rows, every DK-eligible race spawning
                               in their racial newbie zone (Northshire,
                               Valley of Trials, Ammen Vale, ...).
                               NOT Acherus -- Paragon is from-level-1.
  - playercreateinfo_action  : 46 rows, default action bar layout
                               per race (attack 6603, eat 78, racial,
                               etc.).
  - player_class_stats       : 80 rows, per-level base HP/Mana/STR/AGI/
                               STA/INT/SPI. Curve mirrors Warrior to
                               level 60, Paladin-style HP inflation
                               past 60 to keep Paragon competitive
                               in Wrath content.

Tables intentionally untouched: playercreateinfo_item is empty for
class 12 (Paragon ships no per-class starting items, only racial
kit), and the mask-based playercreateinfo_skills/_cast_spell/
_spell_custom rows already cover class 12 via their classMask=0
"all classes" entries.

Verified locally: applies cleanly twice in a row (idempotent),
worldserver restart now logs `>> Loaded 72 Player Create Definitions`
(was 62 pre-Paragon = +10 races for class 12) and creates a Draenei
Paragon without rejection.

CLIENT-PATCHES.md troubleshooting block updated to merge the two
"Character Creation Failed" modes (DBC overlay missing + spawn data
missing) into a single fix recipe. Existing contributors with a
pre-built dbimport image need
`docker compose build ac-db-import ac-worldserver` before this
migration is visible to DBUpdater; fresh clones get it on first
`docker compose up`.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-05-09 13:06:39 -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.