pasdVn

Updated patches and fixed a bug in the speed adaption logic, that I realized just now :-/ , when retrying if it works correctly.

This is the part where the factor of this aura is applied to the total mod, I think Don't be that lazy^^. This would be probably the biggest peace of work in this patch :-P. Looks horrible with those icon checks. (Maybe you can find it even in the EffectSpellClassMask of the dummy aura, so you don't have to care about that but that is quite unprobable)

Added Pet Talent "Silverback".

The current system only supports ppm rates for caster auras. As there are also proc trigger auras that are casted on the victim with a wepon dependen proc rate, we need to support that in the core. Example: http://www.wowhead.com/?spell=20185, http://www.wowhead.com/?spell=20186 (Dummy procs, heal or energize effect) From 7c902ff7b37919c1dac773381c805b68cd446918 Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Sun, 7 Jun 2009 18:23:22 +0200 Subject: [PATCH] Fixed ppm handling for victim auras --- src/game/Unit.cpp | 17 +++++++++++++---- 1 files changed, 13 insertions(+), 4 deletions(-) diff --git a/src/game/Unit.cpp b/src/game/Unit.cpp index feeed7a..31ee900 100644 --- a/src/game/Unit.cpp +++ b/src/game/Unit.cpp @@ -11751,10 +11751,19 @@ bool Unit::IsTriggeredAtSpellProcEvent(Unit *pVictim, Aura* aura, SpellEntry con if(spellProcEvent && spellProcEvent->customChance) chance = spellProcEvent->customChance; // If PPM exist calculate chance from PPM - if(!isVictim && spellProcEvent && spellProcEvent->ppmRate != 0) - { - uint32 WeaponSpeed = GetAttackTime(attType); - chance = GetPPMProcChance(WeaponSpeed, spellProcEvent->ppmRate); + if(spellProcEvent && spellProcEvent->ppmRate != 0) + { + uint32 WeaponSpeed; + if(!isVictim) + { + WeaponSpeed = GetAttackTime(attType); + chance = GetPPMProcChance(WeaponSpeed, spellProcEvent->ppmRate); + } + else + { + WeaponSpeed = pVictim->GetAttackTime(attType); + chance = pVictim->GetPPMProcChance(WeaponSpeed, spellProcEvent->ppmRate); + } } // Apply chance modifer aura if(Player* modOwner = GetSpellModOwner()) -- 1.5.5.1 github: http://github.com/pasdVn/mangos/commit/7c902ff7b37919c1dac773381c805b68cd446918.patch "Judgement of Light" and "Judgement of Wisdom" nee spell_proc_event enries to use the ppm system: /*Judgement of Light/ Judgement os Wisdom*/ DELETE FROM spell_proc_event WHERE entry IN (20185, 20186); INSERT INTO `spell_proc_event` (`entry`, `SchoolMask`, `SpellFamilyName`, `SpellFamilyMask0`, `SpellFamilyMask1`, `SpellFamilyMask2`, `procFlags`, `procEx`, `ppmRate`, `CustomChance`, `Cooldown`) VALUES (20185, 0, 0, 0, 0, 0, 0, 0, 15, 0, 0), (20186, 0, 0, 0, 0, 0, 0, 0, 15, 0, 0);

Thanks! So my my provided patch is correct

Do they really stack, so that you can see two buff icons of "Divine Aegis", or is it just so, that the absorb amounts will be added, but you just have one buff?

Added github link

Updatet first post and added necromancers advises :-) I'm just not sure, where and why I need to check the guid of the caster... I kept may way for now (via dummy aura). Maybe I will try the thing with the channeling target later. Edit: Sorry, I posted wrong links yesterday. Now the patches should be the correct version.

Spell: http://www.wowhead.com/?spell=47509 From 604533a57a653a73d6d181ac065b6883af44a0da Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Fri, 24 Jul 2009 12:36:11 +0200 Subject: [PATCH] addition to dummy aura proc of 47509 and ranks * make "Divine Aegis" possible to stack --- src/game/Unit.cpp | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/src/game/Unit.cpp b/src/game/Unit.cpp index fd634da..7f9b3a5 100644 --- a/src/game/Unit.cpp +++ b/src/game/Unit.cpp @@ -5213,7 +5213,18 @@ bool Unit::HandleDummyAuraProc(Unit *pVictim, uint32 damage, Aura* triggeredByAu // Divine Aegis if (dummySpell->SpellIconID == 2820) { - basepoints0 = damage * triggerAmount/100; + if(!pVictim || !pVictim->isAlive()) + return false; + + // find Divine Aegis on the target and get absorb amount + Aura* DivineAegis = pVictim->GetAura(47753,0); + if (DivineAegis) + basepoints0 = DivineAegis->GetModifier()->m_amount; + basepoints0 += damage * triggerAmount/100; + + // limit absorb amount + if (basepoints0 > pVictim->getLevel()*125) + basepoints0 = pVictim->getLevel()*125; triggered_spell_id = 47753; break; } -- 1.6.0.2.1172.ga5ed0 I'm not sure if those procs should "stack" if the heals are casted by different casters. If anybody has more detailed information they are welcome^^

Updatet. Explanations see first post.

Ahh, thank you very much! I did not understood the whole system as I see. So patch is incorrect in the suggested way , but I'm going to post a working one soon, I hope .

Maybe you are right, and we should simply let all spells trigger... I don't know which is the more generic way. But if we would change the code, so that every spell is abled to trigger (so also dot's or any other aura applying spells), we will have to add spell_proc_event entries for other spells as well, that won't work correct with this logic.

They aren't in the in the official sql dumps anymore, so we won't need to DELETE them

Ah, yes of course. Was reduced to a 3 point talent with 3.1.3. Updated.

Thanks and sorry. Hope it is finally bug free now :-/

You are right. Thank you!

http://www.wowhead.com/?search=lock+and+load This Talent changed with game version 3.1.3. Here is the updated code: From 834e9e03ab2127ddaf023736e9e155085e265b1c Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Thu, 16 Jul 2009 15:26:27 +0200 Subject: [PATCH] Fixed hunter talent "Lock and Load" (56342 and ranks) * update for game version 3.1.3 --- src/game/Unit.cpp | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/game/Unit.cpp b/src/game/Unit.cpp index df41fba..3d07bd5 100644 --- a/src/game/Unit.cpp +++ b/src/game/Unit.cpp @@ -5440,8 +5440,9 @@ bool Unit::HandleDummyAuraProc(Unit *pVictim, uint32 damage, Aura* triggeredByAu // Lock and Load if ( dummySpell->SpellIconID == 3579 ) { - // Proc only from periodic (from trap activation proc another aura of this spell) - if (!(procFlag & PROC_FLAG_ON_DO_PERIODIC) || !roll_chance_i(triggerAmount)) + // Proc only from black arrow- and immoltaion trap ticks (from trap activation proc another aura of this spell) + if (!(procFlag & PROC_FLAG_ON_DO_PERIODIC) || !(procSpell->SpellFamilyFlags & UI64LIT(0x0800000000000000) || + procSpell->SpellFamilyFlags2 & 0x00020000) || !roll_chance_i(triggerAmount)) return false; triggered_spell_id = 56453; target = this; @@ -6834,8 +6835,8 @@ bool Unit::HandleProcTriggerSpell(Unit *pVictim, uint32 damage, Aura* triggeredB // Lock and Load case 56453: { - // Proc only from trap activation (from periodic proc another aura of this spell) - if (!(procFlags & PROC_FLAG_ON_TRAP_ACTIVATION) || !roll_chance_i(triggerAmount)) + // Proc only from trap activation of frost- and freezing trap (from periodic proc another aura of this spell) + if (!(procFlags & PROC_FLAG_ON_TRAP_ACTIVATION) || !(procSpell->SpellFamilyFlags & 0x00000018) || !roll_chance_i(triggerAmount)) return false; break; } -- 1.6.0.2.1172.ga5ed0

First part: Just a cleanup. We don't need to allow trap effects explicitely to trigger, because they are not triggered by an aura (see a bit above in the code^^). Sencond part: The family flags of "immolation trap effect" and "explosive trap effect" have changed some client versions ago. Before they both had 0x4 in the first flag (and explosive trap still has it, while it was removed for immolation trap). Now they have different flags (both in the 3rd one). I also took for explosive trap the new one (both are unique so it does not matter in the end). Frost trap has a completely different maechanic: The spell that is casted triggers the real effect (the pa aura), but in addition has an own familyflag, which we should take now. A nice side effect of this is, that procs like "Entrapment" and "Lock and Load" on frost trap activation are realizable without hacks than (this spell provides a unit target and thus can trigger):-) From 4b549ea7f986a6ddc30cd0ed345642b36027a85a Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Sat, 13 Mar 2010 17:38:19 +0100 Subject: [PATCH] Updatet some procflag settings. * cleanup, trap effects don't need explicitly be allowed to trigger * update for PROC_FLAG_ON_TRAP_ACTIVATION --- src/game/Spell.cpp | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/src/game/Spell.cpp b/src/game/Spell.cpp index c7bd5cb..3682b66 100644 --- a/src/game/Spell.cpp +++ b/src/game/Spell.cpp @@ -719,8 +719,7 @@ void Spell::PrepareDataForTriggerSystem() break; case SPELLFAMILY_HUNTER: // Hunter Rapid Killing/Explosive Trap Effect/Immolation Trap Effect/Frost Trap Aura/Snake Trap Effect/Explosive Shot - if ((m_spellInfo->SpellFamilyFlags & UI64LIT(0x0100200000000214)) || - m_spellInfo->SpellFamilyFlags2 & 0x200) + if ((m_spellInfo->SpellFamilyFlags & UI64LIT(0x0100000000000000)) || m_spellInfo->SpellFamilyFlags2 & 0x200) m_canTrigger = true; break; case SPELLFAMILY_PALADIN: @@ -771,9 +770,9 @@ void Spell::PrepareDataForTriggerSystem() } break; } - // Hunter traps spells (for Entrapment trigger) - // Gives your Immolation Trap, Frost Trap, Explosive Trap, and Snake Trap .... - if (m_spellInfo->SpellFamilyName == SPELLFAMILY_HUNTER && (m_spellInfo->SpellFamilyFlags & UI64LIT(0x000020000000001C))) + // Hunter traps spells: Immolation Trap Effect, Frost Trap (triggering spell!!), + // Freezing Trap Effect(+ Freezing Arrow Effect), Explosive Trap Effect, Snake Trap Effect + if (m_spellInfo->SpellFamilyName == SPELLFAMILY_HUNTER && (m_spellInfo->SpellFamilyFlags & UI64LIT(0x0000200000002008) || m_spellInfo->SpellFamilyFlags2 & 0x00064000)) m_procAttacker |= PROC_FLAG_ON_TRAP_ACTIVATION; } -- 1.6.5.1.1367.gcd48

Added changing procflags for "Entrapment". Rest is still hot Edit: Also updated family flags for "Master Tactician" (added black arrow)

Yes, this is clear, of course^^ My question is how this is working in the code. Why should this fix change something?

Thanks for your work guys ;-) Just -out of interest- one question to the exploit: Can anybody try to explain again, how this exploit is working? All cast checks are done by the server and are not influenced by any packages, send by the client, or am I wrong? And isn't the check in the suggested fix already done in another place in the code (the generic item check in CheckItem() ). I'd like to inform myself about the that I don't understand Russian :-(.

The Bloom has "SPELL_DAMAGE_CLASS_NONE". That is why you won't get any bonus damage in spellHealingBonus(). I did it by a hack, but don't know, why blizz did not make it a normal spell... http://github.com/pasdVn/mangos/commit/0fcf1b5d69ca7b9d08b137dbac286f8be4a58257 (there is also a hack for prayer of mending in the patch...)

Very nice. I always thought this works already but never tried it. Just one idea: Aren't there also aoe spells that use effect weapon damage? Maybe yyou should add this code also to meleedamagebonus.

Would be in fact a very easy sollution. I found this unit field (UNIT_FIELD_CHANNEL_OBJECT) but it will also be problematic. This guid is always set to the target of the first spell effect (see Spell::SendChannelStart). In general this is not always the target we want (especially only Mind Flay, where the dummy, that targets the victim is the 3rd effect, maybe this is also the problem why mind flay has some other bugs "level of target tot low" or anything similar). Also possible that we change the code there a bit... I'll keep you up to date ;-)

Of course... But Dispersion has already another "precastspell" : http://www.wowhead.com/?spell=60069 They could simply add it there. But maybe they really just wanted their nice Beastial Wrath icon :-D