There a significant bug in Cataclysm code, concerning the absorption of damage by shields. I have observed this frequently in Beta, all in connection with Power Word: Shield, however the bugs might apply to other shield types.

1) If there is a damage event (no absorption) at about the same time as a fresh shield has been cast, there will occasionally be a matching reduction in the shield. So the damage of 1234 happened and was not reduced by absorption, yet there is a shield reduction event and the shield is reduced by 1234.

There is a second somewhat less serious bug, which affects only the attribution of shielding, not the actual absorption itself.

2) If a damage absorption event happens at about the time that the shield is due to expire, sometimes there is no corresponding shield reduction event.

There is a third bug, this one significant, though good if you are inside the shield.

3) A large number of blows that happen at the same time (blows from 5 different mobs in the sample I'm looking at) are all fully absorbed, yet the shield never had enough to absorb them all. The amount of free absorption is nearly as much as the shield was.

Hawksy

I'm playing on Beta. Recap 4.55 mostly works with one simple fix (which I haven't released yet).

In addition, for those interested, Blizzard now provides more specific information about shields and absorption.

-- Absorption and shields for patch 4.0.1 (pre-Cataclysm) as of 2010-October-01:
-- Blizzard now includes in the combat log events SPELL_AURA_APPLIED, SPELL_AURA_REFRESH, and SPELL_AURA_REMOVED the size of the shield remaining for the buff
-- The amounts of damage absorbed were already available in combat log events for damage
-- We can determine how much damage a shield absorbed if we have 'before' and 'after' aura events (why oh why, Blizzard, do you not have something easy like a SPELL_AURA_ABSORBS event with an amount absorbed plus the size of the remaining shield, a trivial number of additional bytes?)
-- Ideally the sum of damage absorbed (from single damage events) and the sum of shields consumed (from pairs of aura events) would be equal
-- If only it were that simple
-- We find that damage events or aura events might be missing entirely, whether because they take place out of range or are simply lost
-- We also have the problem that Recap does not currently record shield aura events that occur outside of combat (we might be able to partially fix this, investigating)
-- We find that damage events and the matching aura events might occur in either order, so we have to accommodate that by registering all related events to the target / aura / caster combinations
-- We can match up damage absorption events and shield aura event pairs to the best of our ability
-- We note that shield aura events can arrive at least 5 seconds after the corresponding damage absorption events, so we have to allow for an unusually generous window for the reconciliation of registrations
-- We can sometimes tell that a target has a shield aura to match a damage absorption event, but without an earlier matching shield aura event to give us an accurate delta (so we choose to assign all of the absorption to this shield, and furthermore to the first such shield aura event encountered, which might not be completely accurate)
-- We note that often, but not always, the penultimate SPELL_AURA_REFRESH event and the ultimate SPELL_AURA_REMOVED event will show the same size of shield remaining (i.e. zero absorption), and furthermore that the SPELL_AURA_REMOVED event can show a remaining size of zero if the shield has been entirely consumed
-- We find that some shield auras feature *increased* shield sizes from one aura event to the next (e.g. Illuminated Healing), so presumably something boosts the shield while it is in place (not sure of the mechanism here)
-- We speculate that this observed increase might also occur if a new shield (of the same type from the same caster) overwrites an existing shield (we have no definite sample of this happening yet)
-- We wonder whether the overwriting of an existing shield by a smaller shield could ever occur, and if so whether this would produce spurious shield reductions that we would mis-interpret as absorptions (no information on this yet)
-- We find that sometimes multiple absorption events will be covered by a single aura event pair (e.g. absorption 12 plus absorption 15 plus absorption 9 matched by a single shield change of 36)
-- We wonder whether this aggregation of shield size changes might include both shield reductions and shield increases (if so, we would lose the ability to reliably assign absorption events to shields)
-- One aura which might represent a shield also appears to contain a secondary spell ID (we have not determined what this is and how to use it)

-- Mechanism: a) register each absorption amount to the target, and if there is a prior registration of a shield aura change, we can do something (see step c)
-- b) register each shield aura change (in the order encountered, not in any priority order) to the target / aura ID / caster combination, and if there is a prior registration of an absorption amount, we can do something (see step c)
-- b1) if there is a shield aura event without a prior shield aura event (so that we cannot calculate a delta), then there is an implied infinite change, and during step c) the entire registered absorption amount will be credited to this shield
-- c) if there is a match from a) or b) then reduce both registered numbers by the lesser of the two amounts (a registration that goes to zero as a result of this is removed)
-- c1) if there are multiple shields registered to the target, matching from an absorption amount is done on a first come, first served somewhat random basis (specifically, for the target we scan spell IDs in the order handed to us by LUA, and within the spell IDs we scan in the caster order handed to us by LUA) (we do not scan spell IDs in any special case order giving priority to e.g. Power Word: Shield, which had been the deal with our pre 4.60 special case code)
-- ideally at the end of a fight there will be no non-zero registrations left, and we can declare happiness, but this is often not the case (we don't yet fully understand all reasons for this)
-- unmatched absorption amounts, and unmatched shield aura changes, are currently both left un-attributed to any healer at the end of a fight (we have no feeling yet for whether or not this is a significant proportion of all absorption)
-- we expire an absorption amount registration after 10 seconds (since we have observed experimentally that it must be remembered for at least 5 seconds, so trying to be safe) if there is no matching shield aura change (could expire something that Blizzard considers still active, or fail to expire something that Blizzard considers ended)
-- we expire a shield aura change registration after 40 seconds (the longest duration shield that I know of at 30 seconds plus the same 10 second window just described) if there is no matching absorption amount (could expire something that Blizzard considers still active, or fail to expire something that Blizzard considers ended)
--
-- On the plus side, we at least have, in theory, absorption / shielding numbers that we can match up unambiguously to the healer
-- We find that in many simple situations, this works exactly as expected and desired
-- It is a general solution, so we have removed the half dozen special case code blocks for shields that Recap was hitherto processing individually
-- Recap will now be able to handle new shield types without any additional special case code
--
-- The jury is still out on whether our special case code was more or less accurate than the new code (we haven't done a direct comparison, and have our doubts (given the many complications listed above) but choose to go ahead anyway (combat log events are hit and miss for other data too, so why be more picky about shields))
-- The previous special case code included individual aura duration code, and this is no longer available, so some expired short-duration shield auras might still be credited since we can't always know that they have expired (there might be no corresponding SPELL_AURA_REMOVED event, for example)

Hawksy

Version 4.50 is now available.

This version adds optional live graphing. When enabled, it costs a bit of memory, plus additional CPU time, so make sure that your computer can handle it.

To enable live graphing, turn on "Live Data Mode" on the Options / Settings panel. Then go pick a fight.

The default will show a graph of your personal outgoing DPS. You can tab to see your incoming DPS, and your outgoing HPS (healing per second).

You can see live numbers in the form of text listings (costs very little CPU time). Click on the "Text" tab.

The "more" button allows you to turn on graphs for other people in your group. Be cautious about turning on additional graph lines until you know whether your computer can handle it.

If you are showing more than one graph line, you can highlight individual graph lines to make them stand out. Click on the name in the "more" panel.

When you are looking at a graph, it will stay there until your group gets involved in another fight that lasts at least 5 seconds. If you want to keep looking at a graph even if another fight starts, you can pause live data collection. All other Recap data tracking will continue. Resume live data collection when you have finished looking at the graph.

There are more details available in the tooltips, and in the file readme_FAQ.txt.

Hawksy

Version 4.36 is now available.

There is a new column for DPS / gear value ratio. The gear value is currently taken from the GearScore add-on. I'm aware of how superficial this ratio can be, involving as it does DPS (a matter of debate) and gear value (rather subjective).

Recap tooltips now show which special clicks apply to a field. These click hints can be turned off.

Recap can now show a single detail across multiple combatants. Double-click on any detail in the bottom half of the popup panel for Outgoing, Incoming, or Other details.

Rows in the top half of the popup panel can now be sorted alphabetically.

Healing numbers in the top half of the popup panel now show actual healing (raw healing minus overhealing).

The percentage of critical ticks is now shown on the popup panel.

On the Options / Ignores tab an Add Suggested Ignores button will add the effects that I suggest you ignore. The current list are all effects which causes a player to heal a boss, thus distorting numbers in the Heal column. If you don't use the Heal column then don't bother with the Ignores tab.

The Deaths button now summarizes all recent friendly deaths. It is also much faster.

Good news everyone! Holy priests will no longer automatically pwn the Died column. Improved code will now count death plus Spirit of Redemption death as only one death.

Hawksy

Version 4.29 is now available. Highlights are:

Per-character combatant data is now compressed on logout and on reloadui, and uncompressed again on re-entering the game. This seems to avoid the Blizzard "block too big" problem.

Improved detection of end of fight when unrelated combat is taking place nearby. It may still be necessary in a few circumstances to mark an end of fight by pausing and resuming Recap.

Synchronization has been improved to allow synchronization to complete while Recap is paused; and to allow the leader of a synchronization to pause and resume Recap.

Stored Data Sets can now be renamed.

The main Fights panel now has an extra row of buttons at the bottom, all related to Recent Events. They do their thing only if Recent Data Mode is enabled. "Events" lists *all* recent events (the various "Recent" buttons display subsets). "Dispels & Interrupts" lists all recent dispels and interrupts. With version 4.29 dispels also include dispel casts and failures (to assist in diagnosing dispel difficulties at Steelbreaker). "Deaths" lists an analysis of recent deaths.

The Recent Events panel has two more buttons. The double up arrow scrolls to the previous end of fight, and the double down arrow scrolls to the next end of fight.

Added a setting on the Options / Reports tab to post to the clipboard in tab-delimited format suitable for pasting into spreadsheets.

Support for WIM has been updated.

For further information check the Description section on this page, and check the file readme_FAQ.txt.

Hawksy

I have been stress-testing the modification that I mentioned below (June 17), and the results are looking good.

I've had my Recap up to over 300 Mbytes, with over 21,000 combatants in my active combatants set (over 14,000 in the Fights panel). That should be way more than most people will need. No "block too big" crashes. I have a mid-range machine with 2 Gbytes of memory.

Yes, that much data slows me down a bit when logging in or logging out, or when zoning into a city such as Dalaran, but I can still run instances with no problems.

Hawksy

My initial inclination is 'no', though perhaps I could be persuaded.

Geek talk alert:

It comes down to a theoretical problem that I have with LibDataBroker as currently specified.

I agree with the benefits of keeping data supply and data display separate. However, LDB does not as far as I can tell provide a declarative menu structure. Therefore in my opinion requiring the data supply to actively support a menu at the data display end violates the intended separation of supply and display.

Hawksy

I've uploaded version 4.09, and when it shows up here, version 4.09 will be available. If it doesn't show up as the default download, then grab it from the direct links just above.

This version adds "best effort" assignment of healing to the healer for five spells: Prayer of Mending, Lifebloom, Earth Shield, Improved Leader of the Pack, and Judgement of Light. Suddenly the healing that your tank does will drop to near zero.

This version removes the 'unexpected event' messages for the five new combat log events that Blizzard introduced with patch 2.4.3. This version of Recap does not yet process the new combat log events associated with breaking crowd control, so this version will no longer be tracking all breaking of crowd control. I'll address that in the next version.

According to the Blizzard patch notes the new patch should allow Recap to properly credit elementals to shamans. It seems to do so now, but I haven't had a chance to test this fully.

Hawksy

This is almost like a blog entry....

I'm now working on getting Prayer of Mending heals assigned properly. This will be the first bit of special case code in Recap. I've tried to avoid special case code in the past, and with good reason. It's never pretty, and it tends to be higher maintenance.

It is turning out to be very much trickier than it first looked, not because of Recap but because of the way that Blizzard issues (or doesn't issue) the relevant events. It is further complicated if Recap doesn't get some events because of range issues. The result will be a "best attempt" to assign the healing to the appropriate priest.

Because each copy of Recap may see events slightly differently they may get slightly different answers. This means that if multiple copies of Recap are in synchronization there may be a slight inflation of priest healing numbers on the All Fights panel. This would be due to double-counting of some Prayer of Mending procs.

I expect to run into similar issues with the other healing spells that need tweaking (Lifebloom, Earth Shield, Improved Leader of the Pack, and Judgement of Light). I may not be able to include all of them in the same release of Recap, though I'd like to.

Later note (July 14): I'm currently testing and tinkering with all five. Lifebloom and Earth Shield were the easiest, Prayer of Mending the trickiest, with Improved Leader of the Pack and Judgement of Light being of intermediate difficulty.

Does anyone know of any other healing spells that need code to re-assign the heals to the correct healer?

Hawksy