Revils

Last time I checked it wasnt working: this type of GO with negative value despawns after first player use, no matter specified time (and for OS means only one player can enter the Twilight portal, and this is not right since it should last 30 secs) If I recall correctly data5 e data3 fields are not used in this case and while trying to figure what's wrong I got lost in: GameObject::Update // since pool system can fail to roll unspawned object, this one can remain spawned, so must set respawn nevertheless m_respawnTime = m_spawnedByDefault ? time(NULL) + m_respawnDelayTime : 0;

It isnt that ugly, cause there are already a few of them, anyway: I know, I mean that to add an hardcode value rather than a "rule" is a bit ugly but for this case an execption as you posted it's the only way I can imagine to solve this and other similar problems with other spells

* What bug does the patch fix? What features does the patch add? Fix AOE spell 61632 that should affect only friendly units (boss's adds and not players). * For which repository revision was the patch created? 10675 * Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. none that I know. * Who has been writing this patch? Please include either forum user names or email addresses. Revils diff --git a/src/game/SpellMgr.cpp b/src/game/SpellMgr.cpp index 5aa713f..5e47727 100644 --- a/src/game/SpellMgr.cpp +++ b/src/game/SpellMgr.cpp @@ -700,6 +700,7 @@ bool IsPositiveEffect(uint32 spellId, SpellEffectIndex effIndex) case SPELL_AURA_MOD_SPELL_CRIT_CHANCE: case SPELL_AURA_MOD_INCREASE_HEALTH_PERCENT: case SPELL_AURA_MOD_DAMAGE_PERCENT_DONE: + case SPELL_AURA_MOD_HASTE: if(spellproto->CalculateSimpleValue(effIndex) > 0) return true; // some expected positive spells have SPELL_ATTR_EX_NEGATIVE or unclear target modes break; @@ -782,6 +783,7 @@ bool IsPositiveEffect(uint32 spellId, SpellEffectIndex effIndex) switch(spellproto->Id) { case 802: // Mutate Bug, wrongly negative by target modes + case 61632: // Sartharion Berserk return true; case 36900: // Soul Split: Evil! case 36901: // Soul Split: Good Since it's a spell with TARGET_CASTER_COORDINATES/TARGET_AREAEFFECT_INSTANT its targets depends by IsPositiveEffect so I add an exception for SPELL_AURA_MOD_SCALE and I add a rule for SPELL_AURA_MOD_HASTE (it's similar to SPELL_AURA_MOD_SPELL_CRIT_CHANCE) to make it positive. I didn't find much info so I'm not sure if spell max affected targets must be limited (from data is 0) otherwise all mobs in instance will get the buff.

* What bug does the patch fix? What features does the patch add? Fix ACHIEVEMENT_CRITERIA_TYPE_LOOT_ITEM, ACHIEVEMENT_CRITERIA_TYPE_LOOT_TYPE and ACHIEVEMENT_CRITERIA_TYPE_LOOT_EPIC_ITEM never checked while looting items with group roll for example Sinister Calling 2nd criteria (no problem with master loot and free for all) * For which repository revision was the patch created? 10675 * Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. none that I know. * Who has been writing this patch? Please include either forum user names or email addresses. Revils diff --git a/src/game/Group.cpp b/src/game/Group.cpp index dd4b371..5d47f5f 100644 --- a/src/game/Group.cpp +++ b/src/game/Group.cpp @@ -851,6 +851,9 @@ void Group::CountTheRoll(Rolls::iterator& rollI) roll->getLoot()->NotifyItemRemoved(roll->itemSlot); --roll->getLoot()->unlootedCount; player->StoreNewItem( dest, roll->itemid, true, item->randomPropertyId); + player->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_LOOT_ITEM, roll->itemid, item->count); + player->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_LOOT_TYPE, roll->getLoot()->loot_type, item->count); + player->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_LOOT_EPIC_ITEM, roll->itemid, item->count); } else { @@ -903,6 +906,9 @@ void Group::CountTheRoll(Rolls::iterator& rollI) roll->getLoot()->NotifyItemRemoved(roll->itemSlot); --roll->getLoot()->unlootedCount; player->StoreNewItem( dest, roll->itemid, true, item->randomPropertyId); + player->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_LOOT_ITEM, roll->itemid, item->count); + player->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_LOOT_TYPE, roll->getLoot()->loot_type, item->count); + player->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_LOOT_EPIC_ITEM, roll->itemid, item->count); } else {

spell 24732 second effect uses SPELL_AURA_MOD_SILENCE that is always considered negative in IsPositiveEffect() so no other way than add a ugly exception in that function.

How sp/haste buffs from procs from different trinkets or with wrath totem or demonic aura are handled?

me too, and it totally solved the problem with combat log no more working

thanks

this happens because the model id for the flying mount for that alliance flightmaster is set to 0 on dbc so mangos will skip that taxi node.

I'm the only one with the problem that using mirror image while in raid will make everyone appear with the caster name?

Well since we have some fixed value from DBCs for some spells and also from SPELL_THREAT table it do matters where we multiply... Anyway scaling the threat value on SendThreatUpdate seems the quickiest way but, despite my initial throughs, I think that the right way should be to move the whole threat math from float to integer like it's done for damage and healing. Also there's another big issue: Mangos allows negative threat values while I'm pretty sure clients can't ever display it value less than 0 (now there's an unexpected signed to unsigned conversion on SendThreatUpdate that borks threat meters) so IHMO it's another reason to calculate threat as an pure unsigned integer. For differences between mangos and offy, as we said, surely some spells, mainly those used by tanks, should generate more threat as documented on wowwiki so something like this could be a start: - if(spellProto && IsDamageToThreatSpell(spellProto)) - pVictim->AddThreat(this, float(damage*2), (cleanDamage && cleanDamage->hitOutCome == MELEE_HIT_CRIT), damageSchoolMask, spellProto); - else - pVictim->AddThreat(this, float(damage), (cleanDamage && cleanDamage->hitOutCome == MELEE_HIT_CRIT), damageSchoolMask, spellProto); + float DtTcoef = DamageToThreatSpell(spellProto); + pVictim->AddThreat(this, float(damage*DtTcoef), (cleanDamage && cleanDamage->hitOutCome == MELEE_HIT_CRIT), damageSchoolMask, spellProto); -bool Unit::IsDamageToThreatSpell(SpellEntry const * spellInfo) const +float Unit::DamageToThreatSpell(SpellEntry const * spellInfo) const { if (!spellInfo) - return false; + return 1.0f; uint32 family = spellInfo->SpellFamilyName; uint64 flags = spellInfo->SpellFamilyFlags; if ((family == 5 && flags == 256) || //Searing Pain (family == 6 && flags == 8192) || //Mind Blast (family == 11 && flags == 1048576)) //Earth Shock - return true; + return 2.0f; - return false; + // Rune Strike return 1.75f + // Death and Decay return 1.9f + // Icy Touch return 7.0f + // Thunder Clap return 1.85f + // Swipe (Bear) return 1.5f + + return 1.0f; // default it should be completed with the usual spellfamily&spellflags switches for all the spells that doesn't scales 1:1 with damage (I'm not sure if there are also some healing spell with differenct coefficient than the default 0.5).

I confirm this fix is needed since it solves an exploit with gaining full runic power. Interesting to note that on DBC Dirge rank 2 got different procflags than rank 1 since it got also proc on periodic damage that's really a non sense.

http://www.wowwiki.com/Judgement Thatìs why I put in code that all melee spells that doesn't require a weapon equiped, like judgements, use GetMaxSkillValueForLevel(). The part about can't be dodge is handled elsewere

so also wowwiki confirms what I wrote

Mine was a replay to Darkstalker's post about why on mangos we got a lower 2 order magnitute not why tanks compared to DPS do less threat... In other words using Tonian67 example: Imagine player A with 12345.678 threat and player B with 12345.000 so for the server A > B, now they are both sent as 12346 so for the client A = B which is wrong due to the loss of precision by the uint32 conversion. Also, as the screenshot suggests, on offy OMEN should show 1234568 and not 12346. Alternatively it's possible to calculate threat as damage*100 rather then damage*1, in the end it will give the same results, the only problem could be how this ratio works with some aura/effect that add/remove an hardcode flat value For DnD, I simple gave an example of a spell, but surely there are others, where threat value is wrong and with actual revision it can not be fixed by simply updating values on DB. For Searing Pain, Mind Blast, Earth Shock, threat is calculated using an hardcoded 2x by Unit::IsDamageToThreatSpell, I think we agree that maybe a more general approch using vaules from DB would be better. About Fade and Shadowmeld spells both add a big flat negative value, I didn't test yet but I suspect there could be some signed to unsigned conversion that gives problems