pasdVn

Yes, that is in fact still a problem and would require some more work :-/ (btw. I think that only delayed spells can get reflected^^). I'm also unshure about that, or if it is -maybe- really better to use the channeling target. But it is conspicous, that every of those kind of spells have a dummy aura, that get's applied to the client provided unit target...

Bug: If you cast a channeling spell, only you will see the correct casting bar. If anybody else does (other player, mob, your own pet...) you wont see the bar. Fix: MSG_CHANNEL_START, and MSG_CHANNEL_UPDATE should not only be send by- and to the casting player, but to all players in range (that means also on channeling casts from creatures). Patch: http://github.com/pasdVn/mangos/commit/1bc38f77096a4f066083026c854f4cf067db5451 pasdVn

Really great work btw!

I had the possibility to check that on an offi server: * "Last Stand" is not autocastable * "Heard of the Phoenix" is not autocastable * nothing to do with this patch, but interesting^^: there are some other spells, that can be set on autocast, but that won't get autocasted. I think they did not define any logic/event when casting them or so (e.g. like "intervene") It also seems, that they implemented a check for this bit in the client version 3.2.0. Those spellbuttons look different than the normal autocastable ones. Anyway I think server side check is a good idea!

This is in fact indirect, but anyway correct and will fix this crash. Don't have any time now to work out a patch. Maybe later.

Hmm, you mean the Replenishment procs of http://www.wowhead.com/?spell=31876? This has nothing to do with this patch. This patch will change the proc chance of debuffs, that are on your victim, like the ones when you are unleasing a seal with a judgement.

Please move to reverted. Nearly same sollution was implemented in [8362] (http://github.com/mangos/mangos/commit/99e58a0d0f444c579e2be7d8b316198a1aa0d48a). (exept the typo fix and the addition and the change in SelectAuraRankForPlayerLevel, as I just noticed. Maybe I will just provide an update...)

Updated and moved the "precastspells" to the new HandleSpellSpecificBoosts(), because additional auras should also be canceled when canceling the original player casted spell. Additionally I added a line to IsPositiveEffect(), to make dispersion appear as a positive (and so removable) buff at the client.

Interesting bug, but quite strange I'll try to figure out some more about that problem. Edit: Hmm, I can at least reproduce the crash desribed by goodbadguy. There is the following problem. Rapture Rank 2 has - whyever- some familyflags, that contain (among other bits) the one of Flash heal (rank1 and 3 don't have, so I think they simpli forgot to remove it there during the update to the new effect of rapture in 3.1.3). That is why when casting rapture rank two (that means when learning this talent) Serendipity gets triggered. The casting of the trigger spell will call ReapplyAffectedPassiveAuras() in Aura::HandleAddModifier(). The already applied aura of rapture rank two is identified as "affected" by the spellmod (because of the strange familyflags) and so gets reapplied. The new cast of rapture again triggers Serendipity that calls ReapplyAffectedPassiveAuras() - so a kind of recursive call without ending^^ Don't find out exactly why there is a crash. For me this should just be an infinite recursive loop or so. My suggestion to get rid of this "DBC bug": Don't allow passive spells casts to trigger!

Updated first post, but changed the patch as it was before, because I don't really like my current sollution with using SpellDamageBonus(). Too much exeptions, or how you like to call it... I'm thinking about not using this idea with the spellmod at all, but just searching for the dummy aura. I don't know what is the best way :-/ Anyway you should have a correct patch again, that is applying without conflicts. Edit 9.09.09: Sorry, I somehow forgot to rebase my branch, so you probably still had merging problems with the patchfile. Updated first post again.

Ah, sorry. I forgot totally about that :-( I don't have any time now and will be on holiday the next week. You have to be patient until the week after next week.

Yes, it is the correct one. I think git uses the wrong date somehow, beacuse i rebased my whole branch and just added the newe things to this patch (via git --amend). And yes, you are right. In fact an include is missing there. VC++ seems to interpret all enums as global!? Don't know. I moved the enum WeaponAttackType to SharedDefines.h. Just including Unit.h to SpellMgr.h is not the correct way, as there are no similar includes in SpellMgr.h and WeaponAttacktype is anyway used in several classes (so it is shared^^). Thank you for hint. First Post Updated.

Thank you for feedback Updated patch and description in first post with the changes I talked about.

Thank you for your interest :-) I just want to clarify some things: * project is more alive than ever :-P * this project - in fact - has nothing to do with balancing any classes, it's just a try to implement a correct math of bonus damage calculation, that should be as near as possible to the real system, that is used on official servers. The only reason, that I mostly use hunter spells as examples is, that I know this class quite well, and that there are a lot of hunter spells, that have interesting spelleffect/dmgclass/dmgschool combinations, that can be used to generalize the logic behind the calculation. (besides I don't think this patch will increase hunter dps significant, because it is more a "nerf" for all non physical dmg shots/stings) * originally, I don't wanted this patch to be fully reviewed, but in the meantime, now that I invested quite a lot of work and research, I have to admint, that I would pleased if any dev is interested in this patch^^, but not just now, because patch is still not fully correct, as I found out What is still incorrect: * I quote myself here from my first post: This is wrong in two points: * any damageSchool depending "damagedone" auras are already included in the the normal "white damage" part of effect::WeaponDamage spells (as Seal of Command) , so changing anything in MeleeDamageBonus() won't change anything at all to this (I don't know what went on in my head when writing this^^) * I think my current idea ( the school of the "damage done aura" has to fit to the spells school and the weapon's school) is anyway wrong for spells with effect::WeaponDamage, I think those spells should really deal (as a lot of tooltips of such spells say) "the weapon's damage as holy/fire... [whatever] damage". This means that my current provided patch is correct again^^ * damage done flat modifieres should be scaled in MeleeDamageBonus() (->melee/ranged spells) the same way as in SpellDamageBonus() (-> magical spells), that means for example the well known 42,86% for instant spells. I checked that myself on an offi server, so that information should be really reliable ;-) * the "petbonusdamage" is also added to melee/ranged spells of pets (hunter as well as warlock), I also checked that myself on an offi server, to convince myself of it's correctness (I admit that this will really be a huge improvement for hunter pets) I will provide an updated patch within the next days.

I worked again on that patch I decided to remove the idea with SPELL_ATTR_EX5_WEAPON_DMG_MOD_ALL_DAMAGE for now, because it has nothing to with the original idea. Updates: * crash fix (hope there won't be any problems now) * a lot of cleanup in MeleeDamageBonus(), looks better now :-) * a bit more cleanup in CalculateSpelldmage() (moved crit bonus calculation for weapon based spells to SpellCriticalDamageBonus() ) * moved some scripted effects to MeleeDamageBonus() Would be nice if some of you guys could test it again. I'm also looking forward to any kind of comment or discussion. Patch in first post. Edit: One more thing to mention: The changes/cleanup in CalculateSpellDamage() and SpellCriticalDamageBonus() also fix a wrong handling of SPELL_AURA_MOD_ATTACKER_RANGED_CRIT_DAMAGE, SPELL_AURA_MOD_ATTACKER_MELEE_CRIT_DAMAGE, SPELL_AURA_MOD_CRIT_DAMAGE_BONUS_MELEE, SPELL_AURA_MOD_CRIT_PERCENT_VERSUS. As you can see in the code, currently the whole damage (that means the damage + critbonus) is multiplied with the factors of this auras, what is incorrect, imho. Correct handling is, to multiply only the critbonus with those factors.

Thank you for reviewing :-) Typo... :-/

Ahh, allright. I somehow had this patch in my mind but, but did not find it again... I want them to stack . So from this point of view this patch is correct at least^^.

A Beastmaster Hunter Talent: http://www.wowhead.com/?search=Invigoration#talents Procs from this pet aura: http://www.wowhead.com/?spell=53397 The strange thing is, that it already has a proc chance from 100%, and triggers a spell with a script effect (!?). Don't ask me why 'they' did it this way. Maybe there are not enough free bits from the spellFamilyFlags to handle it as similr talents (by a spellmodifier that changes the proc chance, such as http://www.wowhead.com/?spell=19621 for example). Or this aura is also used to remove "Cobra Strikes" (http://www.wowhead.com/?search=cobra+strikes#talents) proc charges (or stacks in fact) form the owner on pet crit... Who knows? But does not matter now. Anyway here is a patch that makes it work, even with this quite strange construct: From 3a04ec2b34af8a1a3931e571e16919f48926a0f9 Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Wed, 5 Aug 2009 11:02:55 +0200 Subject: [PATCH] added pet talent "Invigoration" (53252 and ranks) --- src/game/SpellEffects.cpp | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/src/game/SpellEffects.cpp b/src/game/SpellEffects.cpp index dfb0c22..2f4795c 100644 --- a/src/game/SpellEffects.cpp +++ b/src/game/SpellEffects.cpp @@ -5232,6 +5232,19 @@ void Spell::EffectScriptEffect(uint32 effIndex) m_caster->CastCustomSpell(unitTarget, spellId, &basePoint, 0, 0, false); return; } + // Invigoration + case 53412: + { + Unit::AuraList const& auras = unitTarget->GetAurasByType(SPELL_AURA_DUMMY); + for(Unit::AuraList::const_iterator i = auras.begin();i != auras.end(); ++i) + if( (*i)->GetModifier()->m_miscvalue == 8 && (*i)->GetSpellProto()->SpellIconID == 3487) + if(roll_chance_i((*i)->GetModifier()->m_amount)) + { + unitTarget->CastSpell(unitTarget, 53398, true, NULL, (*i), m_caster->GetGUID()); + return; + } + return; + } default: break; } -- 1.5.5.1 gihub: http://github.com/pasdVn/mangos/commit/3a04ec2b34af8a1a3931e571e16919f48926a0f9.patch Don't forget the sql part (only on crit): DELETE FROM `spell_proc_event` WHERE `entry` IN ('53412'); INSERT INTO `spell_proc_event` (`entry` ,`SchoolMask` ,`SpellFamilyName` ,`SpellFamilyMask0` ,`SpellFamilyMask1` ,`SpellFamilyMask2` ,`procFlags` ,`procEx` ,`ppmRate` ,`CustomChance` ,`Cooldown`) VALUES ('53412', '0', '0', '0', '0', '0', '0', '2', '0', '0', '0'); pasdVn

The Hunter Talent "Kindred Spirit" (http://www.wowhead.com/?search=spirits#talents) makes the pet cast two auras (http://www.wowhead.com/?spell=57485 the speed part, http://www.wowhead.com/?spell=57447 the damage part, and their ranks, ofc). Those two auras are not allowed to stack currently (same icon... etc.). patch: From 9f0e82f5c0047b459fce4260b72b1824e24a10e5 Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Thu, 6 Aug 2009 11:41:00 +0200 Subject: [PATCH] Make pet auras of "Kindred Spirits" abled to stack. --- src/game/SpellMgr.cpp | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/game/SpellMgr.cpp b/src/game/SpellMgr.cpp index 7e820e4..cc695e9 100644 --- a/src/game/SpellMgr.cpp +++ b/src/game/SpellMgr.cpp @@ -1208,6 +1208,10 @@ bool SpellMgr::IsNoStackSpellDueToSpell(uint32 spellId_1, uint32 spellId_2) cons (spellInfo_2->Id == 8326 && spellInfo_1->Id == 20584) ) return false; + // Kindred Spirits + if( spellInfo_1->SpellIconID == 3559 && spellInfo_2->SpellIconID == 3559 ) + return false; + break; } case SPELLFAMILY_MAGE: -- 1.5.5.1 Gihub: http://github.com/pasdVn/mangos/commit/9f0e82f5c0047b459fce4260b72b1824e24a10e5.patch I think the iconid check is enough here. As far as I know no other spell uses this icon. Quite funny, that this second effect got an extra bufficon, while similar pet talents don't... Edit: Maybe one important thing I forgot to mention: Both pet castet spells are NOT passive(SPELL_ATTR_PASSIVE). That is why they are getting sorted out with the iconID check in IsNoStackSpellDueToSpell() and we need this special handling (in comparison to similar spells)...

The Spells: http://www.wowhead.com/?search=Feeding+Frenzy#talents Just a small error in the code with those Spells: The health of the pets victim should be at or above 35% health, not the pet itself From 045ae8af972b53251153d6d2db43a9e8789fb1f4 Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Tue, 4 Aug 2009 16:50:48 +0200 Subject: [PATCH] fixed periodic dummy procs of 53511 and ranks --- src/game/SpellAuras.cpp | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/game/SpellAuras.cpp b/src/game/SpellAuras.cpp index 9422ad3..8ce6715 100644 --- a/src/game/SpellAuras.cpp +++ b/src/game/SpellAuras.cpp @@ -7490,14 +7490,21 @@ void Aura::PeriodicDummyTick() // return; // Feeding Frenzy Rank 1 case 53511: - if ( m_target->GetHealth() * 100 < m_target->GetMaxHealth() * 35 ) + { + Unit* victim = m_target->getVictim(); + if( victim && victim->GetHealth() * 100 < victim->GetMaxHealth() * 35 ) m_target->CastSpell(m_target, 60096, true, NULL, this); return; + } + break; // Feeding Frenzy Rank 2 case 53512: - if ( m_target->GetHealth() * 100 < m_target->GetMaxHealth() * 35 ) + { + Unit* victim = m_target->getVictim(); + if( victim && victim->GetHealth() * 100 < victim->GetMaxHealth() * 35 ) m_target->CastSpell(m_target, 60097, true, NULL, this); return; + } default: break; } -- 1.6.4.3 Github: http://github.com/pasdVn/mangos/commit/045ae8af972b53251153d6d2db43a9e8789fb1f4 pasdVn

The Spell: http://www.wowhead.com/?spell=53490 One more of this "remove all movement impairing and loss of control loosing causing" effects. I wonder why blizz did not use a bitmask for this mechanic field. Would make a lot of things more easy... From 44f3632ee9ee8604464974487c5a5748f1f27234 Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Tue, 4 Aug 2009 16:25:01 +0200 Subject: [PATCH] fixed pet talent 53490 --- src/game/SpellAuras.cpp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/game/SpellAuras.cpp b/src/game/SpellAuras.cpp index 2dfb151..e8ec74b 100644 --- a/src/game/SpellAuras.cpp +++ b/src/game/SpellAuras.cpp @@ -4086,7 +4086,7 @@ void Aura::HandleModMechanicImmunity(bool apply, bool /*Real*/) uint32 mechanic = 1 << m_modifier.m_miscvalue; //immune movement impairment and loss of control - if(GetId()==42292 || GetId()==59752) + if(GetId()==42292 || GetId()==59752 || GetId()==53490) mechanic=IMMUNE_TO_MOVEMENT_IMPAIRMENT_AND_LOSS_CONTROL_MASK; Unit::AuraMap& Auras = target->GetAuras(); -- 1.5.5.1 Github: http://github.com/pasdVn/mangos/commit/44f3632ee9ee8604464974487c5a5748f1f27234.patch

Originally I just wanted to apply spellmods to creature cooldowns in this patch, but I worked out a bit more now, that should improve creature (mostly pet) cooldown handling at all. The main points: * unified creature and spell cooldown handling, setting cooldown will be done in Spell:: and not in any AI or opcode handlers, for creatures cooldowns will be stored for all directly player-controlled pets/charms, as we need it only there for the pet action bar * the original idea: apply spellmods to creature cooldowns, in connection changed the store system for category cooldowns (old system quite strange and not correct, compare to handling inPlayer::PetSpellIntialize) * improved global cooldown handling for creatures, that means, that spells without gcd can be casted while gcd is active (from ai as well as via opcode) and also dont trigger the gcd, note that this is still a simplified handling of gcd's, but should be enough for creatures in any case * added support for sending cooldownmessage after canceling aura for auras with SPELL_ATTR_DISABLED_WHILE_ACTIVE (e.g. correctly show cooldown after "Prowl" or "Phase Shift" in client) The patch: http://github.com/pasdVn/mangos/commit/b9e2f87a6814b9535f289767fa9f9995ad2348ea One thing, that I did not got working is the correct showing of the gcd in your pet actionbar. Currently things are working the following: When you have a spell on autcast, you will see the global cooldown when the casting time is over (not as we are used to it, when you start casting). Strangely, this is also the case on official servers. If you cast a spell manually, it works the same as for players (gcd starts when yo start to cast the spell), but not on mangos. The gcd starts one time when you click at the button, and a second time, when casting time is over and spell starts to go to target (best to try it with the imp's fire bolt, but you will notice the second gcd also with every instant spell). The first gcd is shown automatically by the client, the second one is somehow caused by SMSG_SPELL_GO packet, that gets builded in Spell::SendSpellGo. In fact this is a minor bug and just eycandy (the client does not check the gcd, it just shows it), but I like the details I tried different things, but don't know much about the package building. Maybe anyone of you has an idea what to change to make the client not show this second cooldown!? greetings, pasdVn

Both are bitmasks. You just have to combine those two wit a logical OR (bitwise), to make m_spellInfo->SpellFamilyFlags 0x'whatever' return true for both spells. That means: 0x8000000000000 OR 0x0000008000200 ------------------------- 0x8000008000200 = So if you use the result with this bitwise AND operation, it will always return true if one (or more) bits of m_spellInfo->SpellFamilyFlags fit to this bitmask. Just note, that two bit's in one SpellFamilyFlag (like in 0x8000200 for your scourge strike) are not that often and eventually have any special reason. Maybe you should check out other flags of the dead knights spells and find out if any other spells share one of those two bits. You should only take the unique one this spell in this case.

Hmm, I talked to an offi player just now. He said "Last Stand" is definitely not autocastable, but he also was the oppinion, that the most other pet spells with "long" cooldown (talent spells) are not autocastable such as http://www.wowhead.com/?spell=53476 wich also make sense, because you need to choose a spicific friendly target for that spell. But this spell has not got this flag. If there was a specific flag for autocastable/not autocastable, the client would also check that itslef, I think.

With this hack this patch has no chances to get into the official repo Leav it as it was. This was a correct fix for this dummy proc. The issue with spell damage bonus is a completely other thing. OT: Maybe we should use the level of the triggering aura but not level of the spell itself. Would just require to give the pointer of the triggering aura to SpellBonusDamage() as argument...