Docker Build
ef02839ea0
Server side of the v0.7.10 Builds drop. Squashes a few footguns from the original Builds catalog and adds a one-click "save what I have right now" path the Overview pane can hook directly into. - HandleBuildSaveCurrent: new C BUILD SAVE_CURRENT verb. Inserts a fresh build row, snapshots the live panel into its recipe, sets it active. No AE/TE motion, no relearning -- just a named slot for whatever the player already has. - Reset abilities / Reset talents now SetActiveBuildId(0) and re-push the catalog. Without this, the next swap silently overwrote the active build's saved recipe with the (now empty/partial) post-reset state -- effectively erasing the build. - Delete of the *active* build is now a hard reset (HandleParagonResetAll): unlearn everything the panel bought, refund all AE/TE. Deleting a non-active slot still just removes the saved recipe row + parked pet. - Load of the currently-active build is now a "revert to last snapshot" instead of a no-op refresh: keeps the saved recipe authoritative, parks the pet, resets, re-applies. Useful for discarding pending edits. - After a successful Learn All while a build is active: archive the build's previous share_code + recipe into character_paragon_build_share_archive* (so codes already posted to Discord keep importing the frozen loadout), snapshot the new panel into the live build, assign a fresh share_code, push catalog. - HandleBuildImport now falls back to the archive tables when a code isn't in the live catalog -- old shared codes resurrect the recipe they pointed at when they were retired. - Imports never copy pet_number (the parked pet belongs to the source player); if the imported recipe contains Tame Beast we hint that the importer needs to tame their own pet. - BuildPanelOwnedSpellsAllowlist now walks SPELL_EFFECT_LEARN_SPELL effects on talent rank spells (Mangle, Feral Charge, Mutilate, ...) so the login cascade sweep stops revoking talent-granted active abilities. Schema: new mod-paragon migration 2026_05_10_05.sql adds character_paragon_build_share_archive (+ _spells / _talents). 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.