Skip to content

refactor(Core/Spells): QAston proc system#24233

Merged
Nyeriah merged 121 commits into
azerothcore:masterfrom
blinkysc:feature/qaston-proc-system
Feb 18, 2026
Merged

refactor(Core/Spells): QAston proc system#24233
Nyeriah merged 121 commits into
azerothcore:masterfrom
blinkysc:feature/qaston-proc-system

Conversation

@blinkysc

@blinkysc blinkysc commented Dec 28, 2025

Copy link
Copy Markdown
Contributor

Changes Proposed:

This PR ports the QAston proc system from TrinityCore, which is a major refactor of how spell procs are handled. The key changes include:

Core Changes:

  • New spell_proc table with enhanced filtering: SpellTypeMask, SpellPhaseMask, HitMask, AttributesMask
  • Proc phase separation: CAST phase (1) vs HIT phase (2) for proper timing
  • CAST phase HitMask filtering for travel-time spells - Allows procs like Nature's Grace and Elemental Focus to trigger at cast time using pre-calculated crit results, enabling buffs to affect spells cast during projectile flight
  • Moved 4400+ lines of HandleDummyAuraProc switch statements to individual spell scripts
  • Added 174 new spell proc scripts across all classes

Benefits:

  • More accurate proc behavior matching retail WotLK
  • Easier to maintain - each spell has its own script instead of giant switch statements
  • Better proc filtering prevents incorrect triggers
  • Unit test framework for proc system validation

This PR proposes changes to:

  • Core (units, players, creatures, game systems).
  • Scripts (bosses, spell scripts, creature scripts).
  • Database (SAI, creatures, etc).

AI-assisted Pull Requests

Important

While the use of AI tools when preparing pull requests is not prohibited, contributors must clearly disclose when such tools have been used and specify the model involved.

Contributors are also expected to fully understand the changes they are submitting and must be able to explain and justify those changes when requested by maintainers.

  • AI tools (e.g. ChatGPT, Claude, or similar) were used entirely or partially in preparing this pull request. Please specify which tools were used, if any.

AI Tools Used: Claude Code (claude-opus-4-5-20251101) thinking with azerothMCP

Issues Addressed:

SOURCE:

The changes have been validated through:

  • Live research (checked on live servers, e.g Classic WotLK, Retail, etc.)
  • Sniffs (remember to share them with the open source community!)
  • Video evidence, knowledge databases or other public sources (e.g forums, Wowhead, etc.)
  • The changes promoted by this pull request come partially or entirely from another project (cherry-pick). Cherry-picks must be committed using the proper --author tag in order to be accepted, thus crediting the original authors, unless otherwise unable to be found

TrinityCore/TrinityCore@e641d0c
TrinityCore/TrinityCore@2ff8550
TrinityCore/TrinityCore@016b31a

https://github.com/TrinityCore/TrinityCore/commits/3.3.5?author=ariel-&before=d0fd8e683ca02f3d2d9ceefe55482a49aab59c6c+700&branch=3.3.5

Tests Performed:

This PR has been:

  • Tested in-game by the author.
  • Tested in-game by other community members/someone else other than the author/has been live on production servers.
  • This pull request requires further testing and may have edge cases to be tested.

Tested ~400 proc scenarios including:

  • All class talent procs (DK, Druid, Hunter, Mage, Paladin, Priest, Rogue, Shaman, Warlock, Warrior)
  • Item procs (Deathbringer's Will, Tiny Abomination in a Jar, Darkmoon Cards, etc.)
  • Set bonuses (T5, T6, T10 bonuses)
  • Enchant procs (Executioner, Mongoose, etc.)
  • Boss encounter mechanics

How to Test the Changes:

  • This pull request can be tested by following the reproduction steps provided in the linked issue
  • This pull request requires further testing. Provide steps to test your changes. If it requires any specific setup e.g multiple players please specify it as well.

Use this gist https://gist.github.com/blinkysc/b6b388a62cb88efe987833ac340215e6 it should have primary coverage as well as comprehensive (every single spell_proc spell). These tests are generated by the MCP so some of them might be a little odd but I think testers should get the point on most.

  1. Test any spell proc from the linked issues
  2. Test using the gist file guide
  3. look at the many combinations in spell_proc table to test from

Known Issues and TODO List:

  • [ ]
  • [ ]

How to Test AzerothCore PRs

When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].

You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:

http://www.azerothcore.org/wiki/How-to-test-a-PR

REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).

For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.

blinkysc and others added 19 commits December 24, 2025 00:35
Port TrinityCore's modular spell proc handling system that replaces
hardcoded proc handlers with database-driven spell_proc entries and
AuraScript hooks.

Changes:
- Add spell_proc table with 300+ proc entries
- Add DoCheckProc, PrepareProc, OnEffectProc hooks to SpellAuras
- Convert class proc handlers to AuraScripts (DK, Druid, Hunter, Mage,
  Paladin, Priest, Rogue, Shaman, Warlock, Warrior)
- Add 35+ item/trinket proc scripts
- Add pet proc scripts (Hunter)

TODO:
- Implement remaining boss scripts (spell_deathbringer_blood_beast_blood_link,
  spell_putricide_ooze_tank_protection, spell_twisted_reflection,
  spell_uk_second_wind, spell_xt002_321_boombot_aura)
- Implement misc scripts (spell_q13413_wyrmrest_skytalon_ride_periodic)
- Test the new proc system

Closes azerothcore#9177

Co-Authored-By: QAston <[email protected]>
Co-Authored-By: joschiwald <[email protected]>
- Add DisableEffectsMask to SpellProcEntry struct and spell_proc table
- Update LoadSpellProcs to load and auto-generate DisableEffectsMask
- Update GetProcEffectMask to use DisableEffectsMask for effect filtering
- Add DamageInfo constructor with SpellMissInfo for hitMask computation
- Add m_hitMask to HealInfo class with GetHitMask/AddHitMask methods
- Update spell damage, healing, and proc flows to use hitMask
- Update PROC_SPELL_PHASE_CAST and PROC_SPELL_PHASE_FINISH procs
- Remove legacy createProcExtendMask function

Based on TrinityCore commits:
- TrinityCore/TrinityCore@e641d0c
- TrinityCore/TrinityCore@2ff8550
- TrinityCore/TrinityCore@016b31a

Co-Authored-By: ariel- <[email protected]>
- Move proc checks from old system to Aura::GetProcEffectMask (returns effect mask)
- Add AuraEffect::CheckEffectProc for per-effect proc validation
- Add PROC_ATTR_REQ_SPELLMOD validation in LoadSpellProcs
- Update SPELL_PROC_FLAG_MASK to include periodic and trap activation flags
- Update DONE_HIT_PROC_FLAG_MASK to include trap activation
- Sync spell_proc table with TrinityCore (848 entries)
- Add proc cooldown on item equip (AddProcCooldown in EquipItem)
- Port missing AuraScript proc handlers for class spells
- Port boss/dungeon proc scripts (Saurfang, Putricide, XT-002, etc.)
- Remove stale SpellProcEventEntry references
- Auto-generate default proc entries for spells with proc flags

Based on TrinityCore commits:
- e641d0c7d71 Core/Spells: Implementation of QAston proc system
- 2ff8550 Core/Spells: AuraScripts coverage
- 016b31a Core/Spells: Proc cooldown on equip

Co-Authored-By: ariel- <[email protected]>
- spell_dru_eclipse: Add 30-second internal cooldown for lunar/solar procs
- spell_pri_body_and_soul: Use EFFECT_1 for Abolish Disease proc chance
- spell_pal_sheath_of_light: Use GetEffectiveHeal() and GetMaxTicks()
- spell_item_persistent_shield: Add shield strength comparison check
- Remove obsolete 'reload spell_proc_event' command from database
Add comprehensive unit test suite for the spell proc system:
- 75 SpellProc tests covering CanSpellTriggerProcOnEvent logic
- Data-driven tests validating all 869 spell_proc entries
- Integration tests for proc flag combinations and hit masks
- Mock infrastructure (UnitStub, AuraStub, SpellInfoTestHelper, etc.)

Tests cover:
- Proc flag matching (melee, spell damage, heal, periodic, kill)
- Hit mask filtering (crit, dodge, parry, block, absorb)
- Spell family name/flag matching
- Spell type and phase mask validation
- Add !IsTriggered() check in Spell::Cast() to skip CAST phase procs
  for triggered spells (e.g., periodic damage effects like Blizzard ticks)
- Add PROC_ATTR_REQ_SPELLMOD check in GetProcEffectMask() to require
  spell to be affected by aura's spellmod before proccing
- Add PROC_ATTR_REQ_MANA_COST check in CanSpellTriggerProcOnEvent()
  to filter procs based on mana cost requirement
- Fix Arcane Potency charges being consumed by channeled spell ticks

This fixes issues where buffs like Arcane Potency and Clearcasting
were incorrectly consumed by periodic damage effects instead of
only on player-initiated spell casts.
TAKEN procs (like Backlash, Redoubt) were being checked on the attacker
instead of the target. This caused procs that should trigger when you
get hit to not work correctly.

Changed TriggerAurasProcOnEvent to call GetProcAurasTriggeredOnEvent
and TriggerAurasProcOnEvent on actionTarget for target procs instead
of on the attacker (this).
…L procs

Direct heals like Healing Wave were incorrectly classified as
PROC_SPELL_TYPE_DAMAGE instead of PROC_SPELL_TYPE_HEAL because
the spellTypeMask calculation only checked for PROC_EX_INTERNAL_HOT
(periodic heals) but not for direct heals.

This caused procs like Tidal Force (55198) that require SpellTypeMask=2
(heal) to never trigger on direct healing spell crits.

Fix: Also check if healInfo is present to identify direct heals.
Sheath of Light was checking GetEffectiveHeal() which returns 0
when overhealing. The talent should proc on any critical heal,
using the base heal amount before overheal is calculated.

Changes:
- Use GetHeal() instead of GetEffectiveHeal() in CheckProc and HandleProc
- Update script to match TrinityCore's OnEffectProc pattern
- Add spell_proc entry for Sheath of Light from TrinityCore
The spell should heal whoever the marked enemy attacks, not the marked
enemy itself. Use eventInfo.GetActor() (marked enemy) to cast heal on
eventInfo.GetActionTarget() (attack victim).
…ration

Move CAST phase proc to after handle_immediate() so spell mods
(like Missile Barrage's duration reduction) are applied before the
aura is consumed by the proc. Previously, the proc was firing before
handle_immediate(), causing the aura to be removed and its spell mods
deleted before the duration modification could be applied.
Core changes:
- Fix TAKEN procs being checked on wrong unit
- Fix direct heals not triggering PROC_SPELL_TYPE_HEAL procs
- Fix Sheath of Light proc to use base heal amount
- Fix Mark of Blood healing wrong target
- Fix Missile Barrage not reducing Arcane Missiles duration

Spell script fixes:
- Paladin: Refactor proc handlers for Sheath of Light, Sacred Shield
- Priest: Fix Vampiric Embrace proc handling
- DK: Fix Mark of Blood target selection
- Rogue: Fix Cut to the Chase spell registration

SQL fixes:
- Fix Cut to the Chase registered to wrong spell (-35541 -> -51664)
- Fix Decimation DisableEffectsMask to disable EFFECT_1

TODO: Backlash (34936) buff not consumed on Shadow Bolt cast despite
correct spell_proc entry (Charges=1, AttributesMask=8). Needs C++
investigation of PROC_ATTR_REQ_SPELLMOD charge consumption path.
At CAST phase, spellTypeMask was calculated from damage/heal info,
but no damage has occurred yet. This caused procs like Backlash to
fail validation because they expect SpellTypeMask=DAMAGE but received
SpellTypeMask=NO_DMG_HEAL.

Use PROC_SPELL_TYPE_MASK_ALL for CAST phase procs to allow validation
based on spell info rather than actual damage/heal values.

Fixes Backlash (34936) and similar spellmod-based procs not consuming
charges on spell cast.
Remove redundant positive spell ID entries (18094, 18095) for Nightfall
that were conflicting with the negative ID entry (-18094). The negative
ID already covers all ranks via spell_warl_glyph_of_corruption_nightfall.

This fixes Shadow Trance not proccing from Corruption ticks.
… Anger

The proc handler only added a Mote of Anger stack on first application,
but did nothing when the aura already existed with fewer than max stacks.

Changes:
- Always cast Mote of Anger to add/stack on each proc
- Check stack count after adding, consume at 8 (normal) or 7 (heroic)
- Add 50% chance for off-hand attack when dual wielding
- Clear motes when trinket aura is removed
Several proc scripts were accessing eventInfo.GetDamageInfo()->GetDamage()
without verifying that GetDamageInfo() returns a valid pointer, which
could cause crashes.

- spell_dk_necrosis: Add CheckProc for damage validation
- spell_dk_unholy_blight: Add CheckProc for damage validation
- spell_dru_t10_balance_4p_bonus: Add damageInfo null check in HandleProc
Core changes:
- Change AuraScript::Remove() default from AURA_REMOVE_NONE to AURA_REMOVE_BY_DEFAULT
- Fix proc system phase/type mask handling in SpellAuras

Proc scripts added/fixed:
- spell_sha_lightning_shield (Static Shock now works)
- spell_dk proc scripts refactored
- spell_hun proc scripts updated
- spell_rog proc scripts (Turn the Tables, Master of Subtlety)

Tested and verified fixes for GitHub issues:
- azerothcore#5967 Tiny Abomination in a Jar
- azerothcore#16062 Turn the Tables buff targeting
- azerothcore#13330 Ignite extending combat
- azerothcore#21401 Druid shapeshifting proccing Omen of Clarity
- azerothcore#19709 Blazing Speed proc rate
- azerothcore#11462 Arcane Concentration/Blizzard ticks
- azerothcore#23326 Thunderstorm Clearcasting
- azerothcore#22279 Righteous Weapon Coating ranged
- azerothcore#9400 Blade of Eternal Darkness crit
- azerothcore#19793 Darkmoon Card: Crusade stacking
- azerothcore#24146 Seal of Command + Ravager
- azerothcore#12115 Replenishment threat
- azerothcore#24116 Flametongue rank stacking
- azerothcore#22427 Cleave + Sweeping Strikes
- azerothcore#17564 T5 Crystalforge 4-set
- azerothcore#10993 Dislodged Foreign Object
- azerothcore#19807 Priest T5 Sadist buff
…ory safety

- Add 3 new SchoolMask filter tests to SpellProcIntegrationTest
- Fix ProcScenarioBuilder to use shared_ptr instead of raw pointers
  to prevent double-free issues when builder objects are copied
@github-actions github-actions Bot added DB related to the SQL database CORE Related to the core Script Refers to C++ Scripts for the Core UnitTests file-cpp Used to trigger the matrix build labels Dec 28, 2025
@blinkysc blinkysc added the Requires WIKI Update Wiki sources will need to be updated after merging this PR. label Dec 28, 2025
@nixiun

nixiun commented Feb 13, 2026

Copy link
Copy Markdown

Does this PR also correctly fix the Rogue T5 set bonus (4-piece: “Your attacks have a chance to make your next finishing move cost no energy”)?
In WotLK at level 80 I’ve still seen Rogues using T5 because of this very frequent proc. Thanks!

@blinkysc

Copy link
Copy Markdown
Contributor Author

Does this PR also correctly fix the Rogue T5 set bonus (4-piece: “Your attacks have a chance to make your next finishing move cost no energy”)? In WotLK at level 80 I’ve still seen Rogues using T5 because of this very frequent proc. Thanks!

This system does handle the proc for it. Configured for 1ppm

blinkysc and others added 4 commits February 13, 2026 22:15
… ICD

ApplyEquipCooldown was using procEntry->Cooldown (the trinket's own ICD)
instead of the standard 30s equip cooldown, causing trinkets like Greatness
(45s) and Mirror of Truth (50s) to take longer than expected before first proc.
The cheat cooldown flag only bypassed regular spell cooldowns and GCD
but not proc internal cooldowns on the Aura system. Trinket procs and
equip cooldowns now respect the CHEAT_COOLDOWN player flag.
@Kitzunu
Kitzunu requested a review from Copilot February 15, 2026 12:07

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

@Kitzunu
Kitzunu requested a review from Copilot February 15, 2026 22:54

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

@sudlud
sudlud requested a review from Copilot February 16, 2026 18:57

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

@hennors

hennors commented Feb 17, 2026

Copy link
Copy Markdown

While I was testing this PR, I noticed a discrepancy in the PPM calculation in Player::CastItemCombatSpell for Druids and other shapeshifters. Replacing proto->Delay with GetAttackTime(attType) should fix this, since GetAttackTime returns the base attack speed of the form (e.g., 1000ms for Cat) and is independent of Haste.

https://github.com/azerothcore/azerothcore-wotlk/blob/9a17604b0388502edb72cd347bd8588ec8facace/src/server/game/Entities/Player/Player.cpp#L7375

Currently, the code uses proto->Delay from the ItemTemplate, which reflects the static weapon speed (e.g., 3.6s). For Feral Druids, this leads to incorrect scaling as their proc rates should be based on their form's base speed, as confirmed by WarcraftLogs and WoWSims models.

Proposed Code Refactor:

if (entry->PPMChance)
{
    uint32 baseAttackTime = GetAttackTime(attType);
    chance = GetPPMProcChance(baseAttackTime, entry->PPMChance, spellInfo);
}

By implementing this change, the behavior for weapon enchantments will be aligned with the rest of the proc system refactored in this PR, ensuring that PPM is handled consistently across all types of procs.

Note:
This issue already exists in the current master branch and is not caused by the PR itself, but it became apparent during my tests of this refactor. While the logic seems sound based on simulation data and class mechanics, I would appreciate it if someone with more experience in the core's spell/proc system could double-check this change to ensure there are no unforeseen side effects for other classes or specific item enchants.

@blinkysc

Copy link
Copy Markdown
Contributor Author

if (entry->PPMChance)
{
uint32 baseAttackTime = GetAttackTime(attType);
chance = GetPPMProcChance(baseAttackTime, entry->PPMChance, spellInfo);
}

This does seem to line up with WoWsims. It would be divergent from TC as well. Let me research just a bit more, but do think this would be correct if so. If you have more links or research please share.

Overall the unit test still will show the same PPM though, this simply would change the "nuances" of how it procs and seems would only specifically affect feral likely.

@hennors

hennors commented Feb 17, 2026

Copy link
Copy Markdown

To be honest, I'm basing this on my analysis of my own WotLK Classic logs and simulation models, as they are the most accurate data we have today.
I also mained a Feral DPS back in 2008 during the original WotLK expansion. From my experience and testing, both the proc frequency and the resulting DPS feel too high with the current scaling. It doesn't align with how the class performed back then. Of course, these are very old memories and memories can be deceptive. However, I would be very surprised if the normalization of attack speed for PPM didn't play a role here of all places.
My main concern is the mathematical discrepancy: if we use a e.g. 3.6s weapon delay to calculate the proc chance for a unit that actually swings at a 1.0s base speed, the resulting proc rate would be significantly higher than anything seen on retail.
If my assumption about how GetAttackTime interacts with the PPM formula is wrong, I'm happy to be corrected! I just want to ensure that Ferals don't end up with unintended 'inflated' proc rates due to the weapon's static delay. I'm glad you're looking into this further!

Edit:
My concern was indeed focused on weapon enchantments (Mongoose/Berserking/Executioner), which are handled in CastItemCombatSpell.
I found the following video uploaded on May 2010, which I believe is from late WotLK with the ICC buff. The combat phase lasts 157 seconds, and I counted 5 Berserking procs. This results in an uptime of (5×15)/157, or roughly 48%.
While the player's specific weapon cannot be identified in the video, we can safely assume a slow 2-hand weapon with a delay of over 3 seconds
If attack speeds for Ferals were not normalized, the uptime would be significantly higher nearly 90%.
https://www.youtube.com/watch?v=kKBUJj8FdiI
I am aware that a 157 second window is a relatively small sample size, which slightly limits the statistical significance.
However, the discrepancy between the observed 48% and the theoretical 90% is so massive that it strongly suggests normalization is active.

@Tereneckla

Copy link
Copy Markdown
Contributor

GetAttackTime is the correct way to get the basespeed of the attack. However, that spot manages the proc chance of item combat spells so it will have no impact on omen.

Most procs go through Aura::CalcProcChance
https://github.com/azerothcore/azerothcore-wotlk/pull/24233/changes#diff-f3fb604c220161af7953902aecc9586825b8193413ab94fdeea4de5665d7a393R2289

…mbatSpell

Enchant PPM in CastItemCombatSpell used proto->Delay (static weapon
speed) instead of GetAttackTime(attType). For shapeshifted druids this
used the weapon delay (e.g. 3.6s staff) instead of the form speed
(1.0s Cat, 2.5s Bear), inflating enchant proc rates by up to 3.6x.

The item spell PPM path already used GetAttackTime correctly. This
aligns the enchant path to match. No behavior change for non-
shapeshifted players since GetAttackTime returns proto->Delay for them.
@blinkysc

Copy link
Copy Markdown
Contributor Author

@hennors yes you're correct =D thank you for your input!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

BREAKING CHANGE Change that will require data re-extraction or major DB table alterations CORE Related to the core DB related to the SQL database Documentation file-cpp Used to trigger the matrix build QAston Ready to be Reviewed Requires WIKI Update Wiki sources will need to be updated after merging this PR. Script Refers to C++ Scripts for the Core UnitTests Waiting to be Tested

Projects

None yet