Docker Build
8363b1b6c8
Companion to 2026_05_09_00.sql (DBC overlay for chrclasses + srci) and
2026_05_10_01.sql (proficiency skill rows in playercreateinfo_skills).
Those two grant the SKILL (Maces, Shield, Cloth, ...) to Paragon at
character creation; this one opens the SkillLineAbility rows that
CASCADE skill -> passive spell, so when a fresh Paragon is created
AC's `Player::LearnDefaultSkill` actually grants the proficiency
passives:
Block (107), Parry (3127), Dual Wield (674), Defense, weapon Shoot,
racial Mace/Sword Specialization, ...
Without this overlay, a class-12 Paragon spawns with the right skill
rows but a near-empty spellbook past the racials and class defaults
that come from playercreateinfo_action.
How it works
------------
AC's DBCStores.cpp::LoadDBC loads each store from the on-disk .dbc
file first, then merges <table>_dbc world-DB rows on top. Our patched
client SkillLineAbility.dbc (in patch-enUS-4.MPQ) OR's the class-12
bit (0x800) into ClassMask on 3,314 rows -- the same rows the server
needs for the cascade to fire on Paragon. Stock Docker installs use
the upstream `ac-wotlk-client-data` image which fills data/dbc/ from
a vanilla 3.3.5a extract, so without this SQL overlay the server
runs against an unmodified SkillLineAbility.dbc and the cascade
never fires.
Generation
----------
Auto-generated end-to-end by
`fractured-tooling/from-workspace-root/_gen_paragon_dbc_overlay_sql.py`,
extended in this commit to handle SkillLineAbility.dbc (14-int
WotLK layout, 56 bytes per record). The script diffs patched vs
stock by ID, keeps only rows whose stock ClassMask did NOT include
the class-12 bit but whose patched ClassMask does, and emits the
3,314 REPLACE INTO rows. Re-running with the same inputs is byte-
stable.
Verified locally
----------------
- Migration applies twice in a row at exactly 3,314 SQL overlay rows
(idempotent: DELETE WHERE ID IN (...) before INSERT).
- ac-worldserver restart logs:
>> Loaded 10219 SkillLineAbility MultiMap Data
-- the same total as stock (10,219 rows), confirming our overlay
REPLACES existing rows by ID rather than appending duplicates.
- Spot-checked spell IDs: 107 (Block, ClassMask 2115 = warrior +
paladin + dk + Paragon), 3127 (Parry, 2063), 674 (Dual Wield,
2157), 75 (Auto Shoot, 2052) all carry the 0x800 bit.
Existing characters
-------------------
The cascade fires inside Player::Create and Player::LearnDefaultSkill
at character spawn, so existing class-12 characters created before
this migration keep their broken state. Delete and re-roll, or hand-
grant the missing spells via .learn for individual existing chars.
CLIENT-PATCHES.md updated to add the third symptom ("proficiency
skills exist but passive spells don't auto-learn") and document
this migration as the fourth piece of the class-12 bootstrap.
Co-authored-by: Cursor <cursoragent@cursor.com>
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_RUNEScast flags, combat exit grace reset. - DK ability scripts:
spell_dk_*,MUST_BE_DEATH_KNIGHTcast 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.