[NOTE: The information below is based on version 1.0, released on Curse on 10/7/08.]
I figured out the fixes for v3.0.2. For criticals being reported as normal hits, the default code doesn't take into consideration the new overkill/overhealing variables put out by COMBAT_LOG_EVENT_UNFILTERED, so the variable being passed as "critical" is actually the "absorbed" variable. To correct it, edit TopScoreFu.lua, changing lines 254 to 286 (beginning and end of "function TopScoreFu:COMBAT_LOG_EVENT_UNFILTERED") to:
[code]function TopScoreFu:COMBAT_LOG_EVENT_UNFILTERED(timestamp, eventtype, srcGUID, srcName, srcFlags, dstGUID, dstName, dstFlags, ...)
<br /> if bit_band(srcFlags, COMBATLOG_FILTER_ME) == COMBATLOG_FILTER_ME then
<br /> local spellId, spellName, spellSchool, amount, overkill, overhealing, school, resisted, blocked, absorbed, critical, glancing, crushing
<br /> local unitid, heal
<br /> if eventtype == "SWING_DAMAGE" then
<br /> amount, overkill, school, resisted, blocked, absorbed, critical, glancing, crushing = ...
<br /> heal = false
<br /> elseif eventtype == "RANGE_DAMAGE" or eventtype == "SPELL_DAMAGE" or eventtype == "SPELL_PERIODIC_DAMAGE" then
<br /> spellId, spellName, spellSchool, amount, overkill, school, resisted, blocked, absorbed, critical, glancing, crushing = ...
<br /> heal = false
<br /> elseif eventtype == "SPELL_HEAL" or eventtype == "SPELL_PERIODIC_HEAL" then
<br /> spellId, spellName, spellSchool, amount, overhealing, critical = ...
<br /> heal = true
<br /> else
<br /> return
<br /> end
<br /> -- Quickly check if this is a vulnerable NPC. No point continuing if it is.
<br /> if bit_band(dstFlags, COMBATLOG_FILTER_NPC) == COMBATLOG_FILTER_NPC then
<br /> if self:IsIgnoringVulnerable() and self:IsVulnerable(getNPCID(dstGUID)) then
<br /> return
<br /> end
<br /> end
<br /> --
<br /> if UnitExists(dstName) then
<br /> unitid = dstName
<br /> elseif bit_band(dstFlags, COMBATLOG_OBJECT_TARGET) == COMBATLOG_OBJECT_TARGET then
<br /> unitid = "target"
<br /> elseif bit_band(dstFlags, COMBATLOG_OBJECT_FOCUS) == COMBATLOG_OBJECT_FOCUS then
<br /> unitid = "focus"
<br /> end
<br /> self:RecordHit(spellName or spelldata["attack"], amount, dstName, unitid, critical, heal, bit_band(dstFlags, COMBATLOG_FILTER_PVP) == COMBATLOG_FILTER_PVP)
<br /> end
<br />end[/code]
This adds in the overkill/overhealing variables, pushing "critical" to the proper column, allowing the mod to recognize the difference between crit and non-crit. A quick test (running out of Crossroads with my lowbie Priest and firing Smite until I got a crit) confirmed this, as it registered the non-crits as regular and the crit as a critical.
Also, I would suggest commenting out (put "--", without quotes, in front of) lines 21-33 and lines 398-404. The spell numbers were changed for the Paladin, Warlock, and Shaman spells that these bits of code were meant to handle, so it's no longer viable.
-
View User Profile
-
Send Message
Posted Oct 23, 2008-
View User Profile
-
Send Message
Posted Oct 23, 2008I too would love to see this updated! :)
-
View User Profile
-
Send Message
Posted Oct 21, 2008-
View User Profile
-
Send Message
Posted Oct 20, 2008Works nice
-
View User Profile
-
Send Message
Posted Oct 19, 2008-
View User Profile
-
Send Message
Posted Oct 19, 2008-
View User Profile
-
Send Message
Posted Oct 19, 2008I figured out the fixes for v3.0.2. For criticals being reported as normal hits, the default code doesn't take into consideration the new overkill/overhealing variables put out by COMBAT_LOG_EVENT_UNFILTERED, so the variable being passed as "critical" is actually the "absorbed" variable. To correct it, edit TopScoreFu.lua, changing lines 254 to 286 (beginning and end of "function TopScoreFu:COMBAT_LOG_EVENT_UNFILTERED") to:
[code]function TopScoreFu:COMBAT_LOG_EVENT_UNFILTERED(timestamp, eventtype, srcGUID, srcName, srcFlags, dstGUID, dstName, dstFlags, ...) <br /> if bit_band(srcFlags, COMBATLOG_FILTER_ME) == COMBATLOG_FILTER_ME then <br /> local spellId, spellName, spellSchool, amount, overkill, overhealing, school, resisted, blocked, absorbed, critical, glancing, crushing <br /> local unitid, heal <br /> if eventtype == "SWING_DAMAGE" then <br /> amount, overkill, school, resisted, blocked, absorbed, critical, glancing, crushing = ... <br /> heal = false <br /> elseif eventtype == "RANGE_DAMAGE" or eventtype == "SPELL_DAMAGE" or eventtype == "SPELL_PERIODIC_DAMAGE" then <br /> spellId, spellName, spellSchool, amount, overkill, school, resisted, blocked, absorbed, critical, glancing, crushing = ... <br /> heal = false <br /> elseif eventtype == "SPELL_HEAL" or eventtype == "SPELL_PERIODIC_HEAL" then <br /> spellId, spellName, spellSchool, amount, overhealing, critical = ... <br /> heal = true <br /> else <br /> return <br /> end <br /> -- Quickly check if this is a vulnerable NPC. No point continuing if it is. <br /> if bit_band(dstFlags, COMBATLOG_FILTER_NPC) == COMBATLOG_FILTER_NPC then <br /> if self:IsIgnoringVulnerable() and self:IsVulnerable(getNPCID(dstGUID)) then <br /> return <br /> end <br /> end <br /> -- <br /> if UnitExists(dstName) then <br /> unitid = dstName <br /> elseif bit_band(dstFlags, COMBATLOG_OBJECT_TARGET) == COMBATLOG_OBJECT_TARGET then <br /> unitid = "target" <br /> elseif bit_band(dstFlags, COMBATLOG_OBJECT_FOCUS) == COMBATLOG_OBJECT_FOCUS then <br /> unitid = "focus" <br /> end <br /> self:RecordHit(spellName or spelldata["attack"], amount, dstName, unitid, critical, heal, bit_band(dstFlags, COMBATLOG_FILTER_PVP) == COMBATLOG_FILTER_PVP) <br /> end <br />end[/code]
This adds in the overkill/overhealing variables, pushing "critical" to the proper column, allowing the mod to recognize the difference between crit and non-crit. A quick test (running out of Crossroads with my lowbie Priest and firing Smite until I got a crit) confirmed this, as it registered the non-crits as regular and the crit as a critical.
Also, I would suggest commenting out (put "--", without quotes, in front of) lines 21-33 and lines 398-404. The spell numbers were changed for the Paladin, Warlock, and Shaman spells that these bits of code were meant to handle, so it's no longer viable.
-
View User Profile
-
Send Message
Posted Oct 21, 2008It works.
Thanks to you.
-
View User Profile
-
Send Message
Posted Nov 1, 2008-
View User Profile
-
Send Message
Posted Oct 19, 2008/bump for an update :)
-
View User Profile
-
Send Message
Posted Oct 18, 2008-
View User Profile
-
Send Message
Posted Oct 17, 2008---
-
View User Profile
-
Send Message
Posted Oct 15, 2008