[3.3.5][6.x] Death Grip. The pull effect shouldn't work on (raid) bosses

[chaodhib]

The pull effect of Death Grip shouldn't affect (raid) bosses while the taunt should work as a general rule (it specifically depends on the boss. some bosses are tauntable. others not).

edit: about the second point, the spell script is fine. my mistake. i didn't quite understood it.

CORE revision number: d86ff08 (branch 3.3.5a, 15/06/10)
TDB 335.58 +updates up until 2015_06_08_00_world.

Thank you in advance for your input.
Chaodhib

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Shauren]

49560 doesn't exist? Give me a break and at least look at dbc files... effects 1 & 2 you listed are actually on 49560

[chaodhib]

@Shauren You are correct actually. I messed up. My bad.

First point holds still true though.

[P-Kito]

Huh. For me it does not work for raid bosses Oo

[Killyana]

We know how the death grip should works with bosses also the 2 effects are handled by mechanic_immune_mask (32 0x0000 0020 MECHANIC_GRIP) and the extrflag (256 CREATURE_FLAG_EXTRA_NO_TAUNT).
So what's the issue here?

[Goatform]

Adding functions such as isWorldBoss, isElite and IsDungeonBoss and using return; in spell script should fix this pull effet issue. So pull effect shouldn't work on elites and bosses but taunt effet should to work on them (else if creature have CREATURE_FLAG_EXTRA_NO_TAUNT flag).

[chaodhib]

@Killyana @P-Kito I tried death gripping Gluth and Patchwork and in both cases, it worked. That's the issue.

@Goatform yeah. Remplacing https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/scripts/Spells/spell_dk.cpp#L658 by:

if (!target->HasAuraType(SPELL_AURA_DEFLECT_SPELLS) && !target->IsDungeonBoss() &&!target->isWorldBoss())

(and changing https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/scripts/Spells/spell_dk.cpp#L654 int32 damage to int32 spellID because the name is confusing)

would solve the issue I think. Not sure if that's the best way to handle this though. First of all, there would be no "immune" to the pull component message sent to the player. In retail, there are (at best) 2 immune msgs displayed: one "Immune" if the target is immune to taunt (example: a player). and another "immune" if the target is immune to the pull effect (example: a boss).

[Killyana]

I'm not sure if it's a good idea to hardcore the immunity (maybe some bosses are not immune to the gripping effect) you can just add 32 to the "mechanic_immune_mask" on creature_template.

[Goatform]

I think that all bosses are immune on that pull effect.

[chaodhib]

I never played dk in wotlk retail so I don't have first hand experience and I might be wrong but I think Goatform is right.

[Shauren]

No, this is not the case for dungeon bosses. There are a few exceptions that are grippable (using current expansion as example, http://www.wowhead.com/npc=86243 )

[chaodhib]

So I tested Death Grip on most bosses of Naxx and it worked on each one. Feels very strange to pull something 20 times bigger than yourself :x Can we agree that every raid bosses is immune at least ?

Anyway, do we have any sniff on Naxx's bosses? And what informations are given by sniffs? does it give the "mechanic_immune_mask" taken from DB or does it give every immunity, including the ones added at run time?

PS: It would make a lot more sense to make every boss immune (general case) and then for the exceptions, remove that immunity in their script. The end result is the same as the other way around (flaging in script/db every boss known to be immune) but it would be much shorter and thus easier to maintain. At this point, I don't think the question to ask ourselves is whether or not we should make every boss immune. It's a question about where.

PS2: probably not a great idea but another place to put the change could be to add this condition in the BossAI constructor https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/game/AI/ScriptedAI/ScriptedCreature.cpp#L460:

if(Is25ManRaid() || Is10ManRaid())
      me->ApplySpellImmune(0, IMMUNITY_ID, 49575, true); // jump aspect of Death Grip only

(it's pseudo code, not sure about the methods used in the if)

PS3: with the current implementation of Death Grip, using me->ApplySpellImmune(0, IMMUNITY_MECHANIC, MECHANIC_GRIP, true) (or using the mask in the DB) would make the creature immune to both effects (taunt & forced movement). The reason for this is that the initial spell used by the dks (49576) has Mechanic = 6 (MECHANIC_GRIP). I tested it.

[Goatform]

I still think that it's much better to fix it in SpellScript instead of doing that. And, @Shauren , I just gave example functions for this, I wasn't think to use all of them...

[Aokromes]

@chaodhib we have naxx sniffs, but sniffs don't contains something similar to mechanic_immune_mask, only testing with chars having the desired mechanic_immune_mask is possible to dig sniffs searching if they are immune to it.

[chaodhib]

So, how to make bosses (or any creature) immune to only the pull component of death grip?

So far, the only way found is to hard code it somewhere (either in the spell script or make the creature immune to the specific spell using its spell ID). I think we can all agree it's ugly and it will most likely have drawbacks later for some bosses scripts of some encounter.

Ideally, I think we want to be able to make a creature immune to the pull effect of the death grip using the immunity to MECHANIC_GRIP. Problem is, the spell itself has MECHANIC field set to MECHANIC_GRIP (and so, right now, if a mob has mechanic_immune_grip set to true, he is immune to the entire spell meaning both the pull and the taunt).

Could it be possible that in retail servers, the Mechanic field of the spell is not used when determining any applicable immunity and instead, only the Effect Mechanic field of each spell effects are used? Could that field be used elsewhere? or be used only outside the game to organize/classify the spells?

edit (25/08/15): Ok nevermind. The last paragraph of this post is a terrible idea.

[chaodhib]

Concrete example of what should be possible if this issue is fixed (taken from a retail 4.X video of the IC encounter https://www.youtube.com/watch?v=7cALSvQFoFI):

Notice:

• the debuff on Steelbreaker. it's the 3s taunt debuff.
• the "immune" message referring to the pull effect of the spell that has failed.

On the other hand, later in the same video, in the same encounter, we can see Stormcaller Brundir being affected by both effects (pull & taunt).

In definitive, we should have bosses that are either:

1. Immune to the pull effect. Not immune to the taunt (ex Steelbreaker. Most woltk bosses are in this category I believe)
2. Non immune to both effects. (ex Brundir)
3. immune to both (Gluth after he hard enrages for example)

and possibly:
4. immune to taunt but not the pull effect

There is not a single solution in this thread so far that allows us to put a creature in each of these 3 states.

• Setting a creature immune to MECHANIC_GRIP spells (in the db or by code) result in an immunity to both the pull & the taunt. State 1 impossible.
• me->ApplySpellImmune(0, IMMUNITY_ID, 49560, true) currently used in some scripts (Vezzax, Freya, possibly others) makes the boss immune to the entire spell -> State 1 impossible.
• Adding a condition on the spell script (such as, dungeon & raid bosses should be immune to the pull effect) is bad too since we wont be able to have exceptions. State 2 wont be possible
• Even "ugly solutions" such as me->ApplySpellImmune(0, IMMUNITY_EFFECT, SPELL_EFFECT_JUMP_DEST, true); and me->ApplySpellImmune(0, IMMUNITY_ID, 49575, true); // jump aspect of Death Grip only dont work because the spell 49575 has Triggered flag set to true uses a SelectImplicitDestDestTargets() to find its implict targets and this method never calls IsImmuneTospell() nor IsImmuneToSpellEffect() .

I tested all of this.

In definitive, it would be great if an experienced dev could take a look at this issue. Also, creatures have an extra flag for taunt. Maybe it is time we have an extra flag for Death Grip's pull effect?

[Aokromes]

still valid?

[chaodhib]

yes