michalpolko

well, yes, but look at the Cyclone DR group - it is also None, but we have DIMINISHING_CYCLONE implemented in MaNGOS, so i suppose that we should implement charge group also. it will be noticed when a player will get charged by 2+ warriors one after another. so here's the patch with DIMINISHING_CHARGE group: http://pastebin.com/rvGmTYZR

so we should add a Warrior Specific group of DR - DIMINISHING_CHARGE? will post this case patch in a minute

hm, maybe mechanics of this talent will make it clear somehow: talent's aura has 100% proc chance, it makes the rogue cast spell=52916 at everyone in his/her group. here we the algorithm: is m_target a rogue? if it is -> check if has talent. if does-> roll chance based on EffectBasePoints. if it is a success, then make m_target cast 51699 on it's current victim. so, 52916 has 8sec duration. 51699 seems to overwrite the previous aura (because of the same icon id?) thats my interpretation of the logs should we consider it as a bug?

and how can I do that?

Revision of MaNGOS:10051 What does the patch fix? Currently the additional Lightning Bolt or Chain Lightning profits bonus damage from 100% of shaman's spell power, so the output dmg for the additional lightning is higher than 50% of the main spell. With this patch it profits bonusdmg from half of spellpower. Tested with Concussion and Shamanism talents and it gave just a little less than 50% of main spell dmg (probably because of Concussion talent). PATCH: http://pastebin.com/xz7r7vip

updated first post, patch for rev. 10051 provided, works fine for me. pls test and comment:]

oh crap, I pasted the wrong version ;/ updating in a minute, sry EDIT: ok, http://pastebin.com/zUVgWPXn for Revision 10051, also updated the first post

try this: http://pastebin.com/dTg4Qaue for Revision 10051

I have just tested it on 10020 and works fine. can anyone with rev10023 test it? I dont feel like updating my mangos now ;p

Revision of MaNGOS: 10020 Spell: Should apply: http://www.wowhead.com/spell=8179 With precast: http://www.wowhead.com/spell=8178 Currently it casts the 8178 spell and the aura isnt reapplied. Spell is cast by totem at spawning, so it needs to be fixed by UDB also like this: -- Grounding Totem. Cast periodic aura at spawn. UPDATE `creature_template` SET `spell1` = 8179, `spell2` = 0 WHERE `entry` = 5925; PATCH: http://pastebin.com/EacRskhB

Revision MaNGOS: 10020 Talents: http://www.wowhead.com/spell=16258 Aura the totem should be applying: http://www.wowhead.com/spell=8179 Regarding to players' comments on wowhead, this talent shortens the interval between reapplying the aura. in patch 3.1.3 it was confirmed that such spell (polymorph) doesnt destroy the totem and it reapplies the aura after the interval time. If I'm wrong, then pls write with some reliable info. PATCH: http://pastebin.com/armYAeqm Written by me.

what is your rev of mangos?

starts at about 7:45good example video. as soon as warrior finishes casting shattering throw, pally's bubble fades. there is also the Immune notification, but I'm not shure if it's for Throw or Charge (but pally's casting has stopped, so imho charge worked and interrupted casting while Throw resulted in Immune notification). imo this should look like: shattering throw->weapon meets the target and [(deals damage+reduces armor)OR(removes immunity)]

umm, is it possible to check before cast if the target has invulnerability aura? if it does, then switch casting to that one which removes invulnerability only. the description of spell says something like this. i'll try to implement this. something like: //somewhere case 64382: // shattering throw if (target has invulnerability aura) { caster->stopcasting; caster->castspell(64380); } I wrote a new hacky version: diff --git a/src/game/Spell.cpp b/src/game/Spell.cpp index c7d5104..efa2bbf 100644 --- a/src/game/Spell.cpp +++ b/src/game/Spell.cpp @@ -2983,7 +2983,7 @@ void Spell::cast(bool skipCheck) { // Shattering Throw if (m_spellInfo->Id == 64382) - AddTriggeredSpell(64380); // Shattering Throw + m_targets.getUnitTarget()->CastSpell(m_targets.getUnitTarget(), 64380, true); // Shattering Throw removing immunity break; } default: works faster than AddTriggeredSpell. still, has anyone any idea how to check the target's aurastate and cast 64380 instead of 64382 if the target has immunity aura? patch from KAPATEJIb for removing immunity makes it remove aura after about 0.5 sec, so it's way too slow imho. dunno why it takes so long for removing it... EDIT: oh, i get it, it doesnt have the visual effect but the removing applies after some time, based on the distance (warrior throws his weapon but client cant see it), so to improve it i swapped m_caster with the target.

MaNGOS Revision: 10459 What does it fix: with Warbringer talent Intervene ability should remove movement impairing effects. Up till now it has been written in Unit::HandleOverrideClassScriptAuraProc(): case 6953: // Warbringer RemoveAurasAtMechanicImmunity(IMMUNE_TO_ROOT_AND_SNARE_MASK,0,true); break; but the problem was, that this part of code could work only when Intervene was cast. if warrior was held by roots, then Intervene couldnt be cast so HandleOverrideClassScriptAuraProc wasnt even executed. from wowhead comments: the most important part is: "-Click same ability twice and it will remove the impairing effect then charge, intercept, or intervene." this is about the old version of talent (before blizz nerfed it) but the part about double using the skill is still valid. I wrote the patch for removing roots by intervene if warrior has the Warbringer talent with the first click (as written above) and then the second click would cast the Intervene spell. Patch: http://pastebin.com/Crr8H6pg here is a video from tests: it was also tested with mage's frost nova. pls test, comment, accept EDIT: still browsing youtube and wow sites for more info about this roots breaking. with this we could spam intervene without losing rage or getting CD on it, it just requires the target in range. Im gonna need info directly from some wow player. EDIT2: ok I think it can be confirmed by this video: at 4:30 the warrior says that he uses Charge (it was before nerf) to break the frost nova, then he uses charge to get to the mage, a few seconds later he uses intercept, so there is no way that after breaking the frost nova he used intercept.

bumping ;p

I found something similiar in Unit.cpp: switch(modifierType) { case BASE_VALUE: case TOTAL_VALUE: m_auraModifiersGroup[unitMod][modifierType] += apply ? amount : -amount; break; case BASE_PCT: case TOTAL_PCT: if(amount <= -100.0f) //small hack-fix for -100% modifiers amount = -200.0f; val = (100.0f + amount) / 100.0f; m_auraModifiersGroup[unitMod][modifierType] *= apply ? val : (1.0f/val); break; default: break; } It looks like BASE_PCT is what i call an additive percent modifier, and TOTAL_PCT is the multiplicative one. So it seems to me that this system is actually declared in MaNGOS but not defined (it's the same as multiplicative) and it is only for basic statistics' (strength, stamina etc.) calculations and not for shield block value.

On wowhead there are only PCT_MOD and FLAT_MOD modifiers. There's no information if this is additive or multiplicative, currently it's implemented as multiplicative, but as I've shown, there is at least one case where a statistic should be calculated in additive way. I dunno much about other classes so I'm counting on users' help. If there are more modifiers that should be additive then this should be implemented ASAP. This patch consists of 2 parts: 1) the general implementation of the additive calc. sys. 2) patch for Shield Block Value which uses this calculating. Update: i divided the patch in the first post. Now I will show You an example of using the additive calculating next to multiplicative depending on the aura ID: void Aura::HandleShieldBlockValue(bool apply, bool /*Real*/)//ppp { BaseModType modType = FLAT_MOD; if(m_modifier.m_auraname == SPELL_AURA_MOD_SHIELD_BLOCKVALUE_PCT) { switch(GetId()) { case 2565: //Shield Block modType = PCT_ADD_MOD; break; case 29598: case 29599: //Shield Mastery modType = PCT_ADD_MOD; break; default: modType = PCT_MOD; break; } } if(m_target->GetTypeId() == TYPEID_PLAYER) ((Player*)m_target)->HandleBaseModValue(SHIELD_BLOCK_VALUE, modType, float(m_modifier.m_amount), apply); } As You can see it gives you full control over applying modifiers depending on ID of the auras.

PATCH: http://pastebin.com/HPFuwu5z - What bug does the patch fix? What features does the patch add? - adds triggering of Mana Detionation by Detonate Mana, damage dealt, deleting the detonating player from victims list, mana consumption. - For which repository revision was the patch created? - 9763 - Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. - i didnt find any - Who has been writing this patch? Please include either forum user names or email addresses. - only me it's a small patch for boss Kel'Thuzad of Naxxramas Update: I've rewriten the patch, now it also fixes the bug with the spell dealing dmg to the target of Detonate Mana. I'm not sure how mana should be consumed, by spell (didnt find the proper one) or like this, by setting it? On yt movies I didn't notice any notification about consuming mana, only about dealing dmg to nearby players, so i suppose this way is fine. Also made some code optimalization. Someone pls test it.

so we could fix ShoR in the same way if this will be accepted then i'll write it for ShoR

here You can read about the cap, it was also confirmed by WoW players a few days ago.

Ad.1 double calculation is when warrior uses Shield Block, which doubles the cap, thats why i add doubled cap to the output damage. If you dont use Shield Block - the cap is 34.5*level If you use Shield Block - the cap is 69*level So in other words, there are 2 caps, which depend on Shield Block skill. Ad.2 30*level is the value where Diminishing Returns start to occur, every next SSlam would hit for lower dmg. This patch fixes Hard Cap for additional dmg from Block Value. Maybe I will also check the diminishing returns and the formula for counting BV from bonuses/talents (which is absolutely wrong right now), but right now its only the cap patch. Helpful links: http://forums.worldofwarcraft.com/thread.html?topicId=19110027997&sid=1 http://www.tankspot.com/showthread.php?45247-shield-slam-damage-formula EDIT: I did some tests and it looks like Block Value is counted properly, sorry for that accusation Testers say that Shield Slam dmg is far too high, so I am trying to find the issue, but now it looks like the cap is the only one... Maybe % bonuses to the output dmg are wrong? EDIT2: (I found out that Shield Mastery and Shield Block should both modify the base SBV only, but now Shield Block multiplies SBV already modified by Shield MAstery and this is the issue.)

this patch looks simple and good to me i bet that author and committer have tested it ;p

hi, it's my first post here my fix: UPDATE `spell_proc_event` SET `procEx` = `procEx`|3 WHERE `entry` IN (58872, 58874); now it will proc when taking any melee dmg or blocking.