fix(Scripts/IcecrownCitadel): Gas Cloud detonates on contact - #27147
fix(Scripts/IcecrownCitadel): Gas Cloud detonates on contact#27147EricksOliveira wants to merge 4 commits into
Conversation
The Gas Cloud fixates a player with Gaseous Bloat and chases them, but nothing in the code or the world DB ever cast Expunged Gas, so the contact detonation never happened and the add just re-fixated on someone else. Gaseous Bloat now procs on the cloud's own melee auto attack against the player carrying it and casts Expunged Gas, with damage scaled by the stacks left at the moment of contact. The bloat is consumed by the detonation and the cloud stops and despawns instead of picking a new target, which follows the ticket rather than retail, where the add survives and the raid kills it. Expunged Gas also gets ALWAYS_HIT, since the dbc doesn't give it that attribute and the detonation could miss or be resisted in testing, unlike the equivalent Ooze Eruption on the green ooze. Immunities are unaffected. The world DB update pins the Gaseous Bloat proc flags to the melee auto attack taken flag, which is also what keeps its own damage ticks from detonating, and shares the Expunged Gas damage across everyone hit, like Ooze Eruption. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The dbc already carries ProcFlags 8 on all four Gaseous Bloat variants, and LoadSpellProcs falls back to the dbc value while the spell_proc column stays 0, so the update changed nothing at runtime. It also disagreed with the auto-generated SpellProcTestData.h snapshot, which records 0 for those ids, and undid part of the normalisation that set those columns to 0 in the first place. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Self-review — FixOozeRed → upstream/masterOutcome 3 findings — 1 fixed, 2 dismissed — 2 rounds, stopped by author before a third Caveat the fix from round 1 was re-reviewed in round 2; nothing was fixed after round 2, so no fix is left unreviewed Reviewed By Claude Code (Claude Agent SDK), claude-opus-5 — self-review v1.0, 2026-08-14 Testing in-game on 10N by the author: detonation fires on contact, damage scales with the remaining stacks, no miss, cloud despawns after. Volatile Ooze re-tested and unchanged. 25-man and heroic not tested. Build, lint and tests not run by this review; the codestyle linters cannot run on this machine (no Python interpreter), so both rounds checked the style rules by hand. Review details (2 rounds)Intent In the ICC Professor Putricide encounter, the Gas Cloud (37562) fixates a player with Gaseous Bloat (70672 and its difficulty variants) and chases them; when it catches that player it must detonate with Expunged Gas (70701), damaging the raid scaled by the stacks left at contact, then despawn. The Volatile Ooze (37697) must keep behaving as it does today. Project rules Excluded from the reviewers Round 1 —
|
github-actions
Bot
added
DB
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe update configures spell 70701 with custom attributes and the always-hit correction. Gas Cloud AI now handles Expunged Gas detonation separately, restricts proc handling to the originating cloud, calculates raid-size damage, consumes Gaseous Bloat, and despawns after detonation. Merge Risk: ⚪ Minimal · up to The PR adds the missing Gas Cloud detonation behavior and related spell/database updates; no actionable merge-blocking risk remains based on the supplied evidence. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Updated comment for clarity regarding cloud detonation behavior.
|
Testing |
|
Tested |
2 participants
In the Professor Putricide encounter the Gas Cloud fixates a player with Gaseous
Bloat and chases them, but nothing in the code or the world DB ever cast Expunged
Gas, so it never detonated: it just kept meleeing and re-fixated on someone else.
Gaseous Bloat now procs on the cloud's own auto attack against the player carrying
it and fires Expunged Gas, scaled by the stacks left at contact. The bloat is
consumed by the detonation, and the cloud stops and despawns instead of picking a
new target. Expunged Gas also gets ALWAYS_HIT, since the dbc doesn't give it that
attribute and the detonation could miss, unlike Ooze Eruption on the green ooze.
Immunities still apply. The pending SQL shares the damage across everyone hit, the
same way Ooze Eruption does.
Two things worth a maintainer's eye. The despawn follows the ticket and not retail,
where the add survives its detonation and the raid kills it, so it needs a sign off.
And heroic deals the same damage as normal, because 70701 has no difficulty variants
and the formula only separates 10 from 25; that's the upstream TrinityCore formula
and I'd rather not invent heroic values.
Changes Proposed:
This PR proposes changes to:
AI-assisted Pull Requests
Important
Using AI tools to prepare pull requests is allowed, but it must be disclosed and it must follow our AC guidelines for AI Agentic Engineering (link below).
You are expected to fully understand the changes you submit and to be able to explain and justify them when maintainers ask.
Issues Addressed:
SOURCE:
The changes have been validated through:
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.