Files
Fractured/modules/mod-paragon
Docker Build da17074a63 Paragon: Runeforging support (panel-purchasable, no anvil required)
Lets the Paragon class buy Runeforging from the Character Advancement
panel and apply rune enchants from anywhere in the world without needing
to be near a runeforge GameObject. Three carve-outs work together:

* Spell.cpp: bypass the SpellFocusObject GO proximity check when the
  caster is a Paragon and the spell belongs to SKILL_RUNEFORGING (776).
  Stock DK behaviour is unchanged -- the bypass is gated on
  getClass() == CLASS_PARAGON, not on the IsClass() context hook.

* Player.cpp: skip the Paragon class-skill cascade block for skill 776
  so the rune-enchant SLA cascade actually fires. Without this the
  player gets the Runeforging skill but no rune options at the anvil.

* Paragon_Essence.cpp:
  - Treat SKILL_RUNEFORGING children as a meta-skill cluster: cascade
    them like passives even though they're active casts, so they stick
    as panel_spell_children and get cleaned up via the standard refund
    path.
  - Whitelist the 8 basic rune-enchants in PruneSkillLineCascadeChildren
    so they don't get evicted as "active in children = legacy garbage".
  - Force-attach them in PanelLearnSpellChain (the SLA rows ship with
    AcquireMethod=0, so the engine cascade alone won't grant them).
  - Add an OnPlayerLogin fixup so existing Paragons who bought
    Runeforging before this change get the 8 runes retro-granted.
  - Stop filtering SPELL_ATTR0_DO_NOT_DISPLAY in PushSpellSnapshot --
    Runeforging itself is hidden in the DBC but is a real panel
    purchase that must show in the Overview tab.

The two advanced runes (Stoneskin Gargoyle, Nerubian Carapace) are
intentionally excluded from the auto-grant -- retail gates them behind
heroic dungeon / raid item drops and the SLA AcquireMethod=0 honours
that gating.

No SQL migration needed; works against existing DBC + SLA data.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-05-12 04:49:38 -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.