WowAce

------------------------------------------------------------------------
r565 | oscarucb | 2014-06-30 03:34:59 +0000 (Mon, 30 Jun 2014) | 2 lines
Changed paths:
   M /trunk/Options.lua
   M /trunk/Skada.lua
   M /trunk/locale/enUS.lua

new option: number duplicate set names (ie pull count)

------------------------------------------------------------------------
r564 | oscarucb | 2014-06-23 02:42:02 +0000 (Mon, 23 Jun 2014) | 4 lines
Changed paths:
   M /trunk/BarDisplay.lua

fix ticket 299: window movement on reload

window position was not being correctly saved when the last window operation was a resize or a rescale

------------------------------------------------------------------------
r563 | oscarucb | 2014-06-10 07:46:33 +0000 (Tue, 10 Jun 2014) | 2 lines
Changed paths:
   M /trunk/modules/Deaths.lua

cosmetic fix to SOR immunity killing blow

------------------------------------------------------------------------
r561 | oscarucb | 2014-06-05 21:20:05 +0000 (Thu, 05 Jun 2014) | 7 lines
Changed paths:
   M /trunk/BarDisplay.lua

Fix another minor display glitch
Where under the correct conditions all the bars in a window would appear
"shortened" due to an incorrectly high .maxValue for the displayed bargroup.
bar:SetMaxValue() must be called after bar:SetValue(), otherwise the max cannot
be lowered below the "old" value (with the original ordering bar:SetMaxValue()
had no effect in that case).

------------------------------------------------------------------------
r560 | oscarucb | 2014-06-05 10:31:46 +0000 (Thu, 05 Jun 2014) | 2 lines
Changed paths:
   M /trunk/Skada.lua

fix a minor window update glitch

------------------------------------------------------------------------
r559 | oscarucb | 2014-06-03 15:41:03 +0000 (Tue, 03 Jun 2014) | 2 lines
Changed paths:
   M /trunk/Skada.lua

fix a lua erorr in last with aggressive combat detection

------------------------------------------------------------------------
r558 | oscarucb | 2014-06-03 09:13:39 +0000 (Tue, 03 Jun 2014) | 40 lines
Changed paths:
   M /trunk/Skada.lua

Stop using ENCOUNTER_START/END to delineate segments

It turns out there are several rare but serious problems with using
ENCOUNTER_START/END for segment delineation.  Most significantly, on rare
occasions during wipes in SoO the server can fire ENCOUNTER_END followed
immediately by a spurious ENCOUNTER_START (I have multiple logs and screenshots
demonstrating this). This happens most frequently on fights with adds, and is
possibly related to players using vanish-like abilities to despawn the
encounter. Worse still, the subsequent boss engage after such an occurence
usually does NOT fire ENCOUNTER_START. Since r477, the spurious ENCOUNTER_START
was suppressing combat-based Skada:Tick() end detection, and that resulted in
an "early start" segment for the second fight that inflated the segment length
to include all the out-of-combat time before the second pull (ie several
minutes of rezzing, eating, rebuffing etc). This bug is believed to be directly
responsible for multiple user reports of DPS/HPS numbers with recent Skada
releases intermittently showing as artificially low (even though the damage
done and effective healing were about right). In order to avoid this problem
and guarantee reliable segment termination we need to preserve the regular
Skada:Tick()-based end detection, which means there is no longer any benefit to
using ENCOUNTER_END for segment delineation.

Even if the Blizzard problem with the spurious ENCOUNTER_START was fixed, there
would still be cases when ENCOUNTER_START/END do not correctly delineate a raid
encounter. Most notably, there are many fights where adds can temporarily
outlive the boss and keep the raid in combat for a few seconds after
ENCOUNTER_END. Truncating the segment at ENCOUNTER_END in those cases leads to
the creation of a "trivial" segment for those adds, leaving "current fight"
windows displaying useless information after combat ends. Similarly, there are
some fights (such as Spoils) where ENCOUNTER_START arrives several seconds
before combat begins, and starting the segment at that point would result in
immediate termination via Tick (unless further measures were in place to
prevent it). The events are also "just plain wrong" when multiple bosses are
pulled together (think Earth, Wind & Fire). In those type of situations the
events might not be alternating and in fact may not even be properly nested,
making them completely inappropriate for segment delineation.

This commit removes the use of ENCOUNTER_START/END for segment delineation. They
are now only used to retrieve an encounter name for the segment.

------------------------------------------------------------------------
r557 | oscarucb | 2014-06-03 08:37:45 +0000 (Tue, 03 Jun 2014) | 4 lines
Changed paths:
   M /trunk/Skada.lua

Add a utility for debug output (off by default)
Toggled with /skada debug
Change the recently-added auto-enable/disable messages to debug output.

------------------------------------------------------------------------
r556 | oscarucb | 2014-06-02 10:26:37 +0000 (Mon, 02 Jun 2014) | 2 lines
Changed paths:
   M /trunk/BarDisplay.lua
   M /trunk/modules/TotalHealing.lua

fix ticket 365: bar resizing display glitch in Total Healing module

------------------------------------------------------------------------
r555 | oscarucb | 2014-06-02 09:45:25 +0000 (Mon, 02 Jun 2014) | 2 lines
Changed paths:
   M /trunk/lib/SpecializedLibBars-1.0/SpecializedLibBars-1.0.lua

another fix to bars sticking out past the window edge after a resize

------------------------------------------------------------------------
r554 | oscarucb | 2014-05-27 03:40:12 +0000 (Tue, 27 May 2014) | 6 lines
Changed paths:
   M /trunk/Skada.lua
   M /trunk/locale/enUS.lua

Make data collection state more transparent to users
"Disable while hidden" option now prints a console message when data collection is being automatically disabled or reenabled.
Also add a "disabled" indicator to the BarDisplay title bar when you are looking at the current or total set while collection is disabled.
Together these should hopefully reduce user confusion as to why data collection is not happening.
Fix a related bug in SetActive() where toggling the "Disable while hidden" option could fail to update data collection state.

------------------------------------------------------------------------