fix(Core/Spells): Archimonde's Doomfire should not be subject to fire resistance#25181
fix(Core/Spells): Archimonde's Doomfire should not be subject to fire resistance#25181brighton-chi wants to merge 1 commit intoazerothcore:masterfrom
Conversation
brighton-chi
changed the title
github-actions
bot
added
CORE
There was a problem hiding this comment.
Pull request overview
Adjusts spell metadata for Battle for Mount Hyjal’s Archimonde encounter so Doomfire damage is not reduced/avoided by fire resistance, aligning in-game behavior with expected retail/TBC behavior.
Changes:
- Updates several nearby
SpellInfoCorrections.cppcomments to include the relevant NPC/boss context. - Marks Archimonde’s Doomfire spells (31944 direct damage, 31969 DoT) as not resistible via
SPELL_ATTR4_NO_CAST_LOG.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| }); | ||
|
|
||
| // Amplify Damage | ||
| // Prince Malcezaar - Amplify Damage |
There was a problem hiding this comment.
Comment misspells the boss name as "Malcezaar"; the canonical spelling is "Malchezaar" (also used elsewhere in the repo). Please fix the comment to avoid confusion when searching.
| // Prince Malcezaar - Amplify Damage | |
| // Prince Malchezaar - Amplify Damage |
|
|
||
| // Archimonde - Doomfire | ||
| ApplySpellFix({ 31944, 31969 }, [](SpellInfo* spellInfo) | ||
| { |
There was a problem hiding this comment.
SPELL_ATTR4_NO_CAST_LOG is used by the core resist logic as a "cannot be resisted" marker (see Unit.cpp resist checks), but the flag name is misleading. Consider adding an inline comment here explaining that this is intentionally set to disable resistance for Doomfire, so future maintainers don’t interpret this as only a logging change.
| { | |
| { | |
| // NOTE: SPELL_ATTR4_NO_CAST_LOG is also used by core resist logic as a "cannot be resisted" marker | |
| // (see Unit.cpp). This is intentionally set so Doomfire cannot be resisted, not just to affect logging. |
|
I would say I'm open to this PR personally; to me makes sense. However, we know TBC raids/content was HEAVILY nerfed for wotlk and could have very well been intentional in the DBC for the resist? The sparse comments seem to only be for TBC content =/ Maybe a good compare would be to look at DBC for TBC client to fill more assumptions? |
So I found this: https://youtu.be/4nmjl5aM834?si=JzbO3OpYj4vexmrS from 3.0.2. At 5:17, the player gets feared into Doomfire and starts taking damage of 2328 per tick. It looks to me like they have Greater Blessing of Sanctuary on, and 2328 is 97% of 2400, the full damage. After getting out of the fire, the damage continues to tick at a reduced amount each tick. The Doomfire dot goes down by 150 each tick, and if you watch the numbers, each time the damage taken is 97% of the full damage. 2183 is 97% of 2250, 2038 is 97% of 2100, 1892 is 97% of 1950, etc. I would have expected at least some resist during that duration with WotLK's scaling resistance, considering the player has Mark of the Wild and also for the most part the Fire Resistance Aura from another player. |
Changes Proposed:
This PR proposes changes to:
Archimonde's Doomfire can be resisted. This is not authentic behavior--fire resistance should have no effect on the spell, neither the direct damage (31944) nor the residual DoT (31969). This PR makes both spells unable to be resisted and also adds a little bit of context to a few of the nearby comments in SpellInfoCorrections.cpp.
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.
Issues Addressed:
SOURCE:
The changes have been validated through:
See:
Tests Performed:
This PR has been:
How to Test the Changes:
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.