| Instructions: |
************
DamageMeters - A user-interface modification for World of Warcraft.
************
Author - Patrick Cyr (damagemeters at yahoo dot com) (Dandelion on
Whisperwind)
- v5.1.0 has been modified by Karl Isenberg (karlkfi at cosmosui dot org)
(AnduinLothar or Wraithhammer on Kil'Jaeden)
Permissions - Do anything you want with it except take credit for it or make
money from it.
Additional Credit To -
SeraphTC for the TitanPanel plugin.
Zoldan and Chakotay1357 for the German translation.
Kurty and eXess for the French translation.
Author(s) of DPSPlus and CombatStats for the parsing technique.
Authors of Sky (for their assert function).
Zaxa (Author of Spellometer), whose code I blatantly stole.
Thanks To - Tagamogi, Rancor, Cyntax, Kixxs, Gileran, Dex, Zurai, Kotor, Sensi,
Kon, Sterne, Pharaoh, and especially everyone in the Wanderers raid group for
downloading the multitudes of beta versions and dealing with all their bugs.
************
**Contents**
************
I. Summary
II. How It Works
III. Features
1) Interface
2) Bar Counts
3) Quantities
4) Players
5) Event Data
6) Reporting
a) DMReporter.exe
7) Synchronization
a) Event Synchronization
b) The Ready Command
c) Session Labels
8) Memory Register
9) Overhealing
IV. Version History
-------------------------------------------------------------------------------
***********
I. Summary:
***********
DamageMeters keeps track of the damage you and nearby players does and shows
the total damage as meters in a window on the screen. It makes it easy to
compare the relative damage/healing output of members of a party or raid. At
any time you can have the mod output the resulting information as text "say"s or
to a channel of your choice.
*****************
II. How It Works:
*****************
DM works by analyzing (parsing) text messages of the sort you see in your
"Combat Log" chat window. An example would be "You hit Onyxia for 10." This is
the only way a mod can know what damage/healing anyone is doing/taking, which is
unfortunate because parsing strings isn't terribly fast or easy.
There is a VERY important limitation to DM: a player only receives combat text
messages for those players that are near him. The distance varies quite a bit
but it doesn't seem to ever be any higher than 45 yards or so. You are not
guaranteed to get messages even for members of your own party if they are not
near you. DM's Synchronization system provides something of a work-around for
this problem.
Also: it is a common misconception that you need to have messages turned on in
your chat window in order for DM to work. This is not the case: they are
entirely independent of each other.
**************
III. Features:
**************
-------------
1) Interface:
-------------
DM appears as a frame (window) with a vertical stack of horizontal meters
(bars). Each bar represents a value for a single player. Bars can be sorted in
increasing or decreasing order, though almost always in the latter. The bar for
the player with the highest value of a given quantity will always be at full
length. Everyone else's bar will be some shorter length in proportion
to the lead player's value. In addition to the bar itself, various text can be
specified to be drawn over each bar, including the player name, the value, etc.
Moving the mouse over a given person's bar brings up a tooltip which shows
detailed information for a given player.
There are two interfaces for setting program options: menus and console
commands. There are two menus. The main menu is reached by right clicking on
the title of the DM window. There is also a player menu which is reached by
right clicking on a particular player's bar. Console commands all start with
/dm and are entered like chat commands. Use /dm help to get a full list.
The window can be moved by click-and-dragging on the title button. Clicking on
a player's bar will attempt to target them. The window can be resized by
dragging the sides or corners, similar to the chat frames. You can also scroll
through the bars (when "Self Always Visible" is disabled) with the mouse wheel.
--------------
2) Bar Counts:
--------------
When a player is detected doing something we are interested in, DM
automatically adds it to its internal list. The internal list can have at most
50 entries, at which point it is full and NO new players will be added. The
number of players in the list, though, is independant of the number of bars
visible on the screen. Generally, there are two ways you can specify the
number of bars: 1) as a hard number, or 2) as an up-to number. The latter is
called the "auto-count" number, and it basically means "show as many bars as I
have player information for, up to this number."
Again, though, it is important to note: the internal player list is NOT limited
by the number of visible bars.
There are two options which override bar counts. The first is "Minimize",
which causes only the player's bar to be visible. (If there is no player entry
one is automatically created.) The second is "Show Max", which causes the
maximum number of bars (40) to be shown. You can set up key bindings to toggle
either of these options quickly.
The visible bars by default start at the first one in the list (for example,
the player with the most damage done). The "Self Always Visible" option can be
set which makes it so the players shown is adjusted such that the player (self)
is always visible in the list.
--------------
3) Quantities:
--------------
DM monitors the following quantities:
- Damage Done: The amount of damage done by a player.
- Healing Done: The amount of healing done by a player.
- Damage Taken: The amount of damage taken by a player.
- Healing Taken: The amount of healing taken by a player.
- Curing Done: The amount of cures/decurses/etc done by a player.
- Idle Time: The amount of time that has passed since the player has last done
something (either done damage or done healing). This is useful for detecting
when someone has gone ninja-afk.
In addition, there are 4 pseudo-quantities which display the same info as the
first 4, but only for the current Fight. These quantities can be shown as
totals or as the total divided by the current Fight time, thus providing a type
of Damage-Per-Second meter.
DamageMeters has two ways of determining when a Fight starts and stops. They
are quite a bit different and can greatly effect what your personal DPS value
is. The default is "Group DPS Mode" ON. In this mode, a Fight starts when
anyone you are monitoring (for instance, a party member) does damage. Fights
end in that mode when you leave combat. The advantage of this mode is that it
provides a good comparison of the contributions of everyone of a group.
When "Group DPS Mode" is OFF, a Fight is determined by whether or not a mob is
aggro vs. you. This mode is not very useful for comparing DPS with other group
members, but can provide better personal numbers.
--------------
4) Players:
--------------
DM, by default, monitors yourself, your pet, your party/raid members, any
nearby friendly players, and miscellaneous things like totems. There is a menu
option, "Only Monitor Group Members", which tells DM to reject nearby friendlies
and miscellaneous things. There are valid reasons for having both options
available. For example, in a pvp environment data from friendlys can quickly
bury your own, and so you'd want to turn that option on. However, if you are a
soloing shaman you could be interested in how much healing your totems are
doing, for instance, so you'd want the option off.
Note: there is no easy way to distinguish totems from players, and there is no
way at all to determine who dropped a particular totem.
Pets present challenges for DM which require some understanding on the users
part for best results. DM CANNOT distinguish someone else's pet from a random
friendly player. If "Only Monitor Group Members" is on you will not see other
players's pets. DM CAN tell if something is YOUR pet. Your pet is always
shown.
The "Treat Pet Data As Your Data" option is meant to help people determine what
their total (themselves plus their pets) contributions are. When this option is
on, any data that registers for your pet is treated as if it came from yourself.
If you accumulate data from one or more pets with this option off, then turn
the option on, the pet(s) data will be AUTOMATICALLY merged into your own.
--------------
5) Event Data.
--------------
DamageMeters can be configured to record stats on an event-by-event basis. [I'm
using the term event to refer to a specific damage/healing source, such as a
melee attack or spell.] While the information displayed isn't terribly
in-depth, it can still be handy for quickly determining how much various
abilities are contributing to someone's totals. Event data for a player is
displayed in their bar tooltip.
The downside to event data is that it takes up quite a bit of memory to store,
so by default DM only saves event data for one's self. It also makes sync'ing
take a *lot* longer (see the section on synchronization).
Here is an example of some DamageTaken events:
Fireball = 300 (75%) 0/2 0% 150 (0 Fire)
[Melee] = 100 (25%) 1/2 50% 50
The entries are:
"Fireball" - Event name
"300" - Total from this event (in this case, total damage taken)
"(75%)" - Percent that this event contributes to this quantity
"0/2" - Crits/hits
"0%" - Crit percentage
"150" - Average
"(0 Fire)" - The magic type and your average resistance (only if applicable)
--------------
6) Reporting.
--------------
DM has a system for reporting its data to other people. It is accessible using
the "Report" menu or via the /dm report command. The former is quicker, but the
latter is much more flexible.
The basic syntax for the /dm report command is:
/dm report [X[#]] [tell target|channel]
X is the report destination, and can be one of the following:
c - Console: Chat messages that you only can see. This is the default.
s - Say
p - Party
r - Raid
g - Guild
w - Whisper - For example, /dm report w dandelion
h - cHannel - Use the channel name, or number: /dm report h mychannel
f - Frame - Shows results in a frame (window), which you can use to copy the
text to the clipboard.
# is optional. If specified, it limits the number of people reported to the
top #, otherwise only the currently visible bars are reported. For example, to
output the top 10 to raid, use:
/dm report r10
As far as doing reports via the menu: it works the same as the console
command.
a) DMReporter.exe
DMReporter.exe is a stand-alone application that generates reports without
having to cut-and-pase from the report frame. To use, just run it: the first
time it runs it will ask you where your SavedVariables.lua file is. After that,
it uses the scripts in DMReporter.lua.default to generate report files for you.
If you want to change the options or even try generating your own
reports, you can copy DMReporter.lua.default to DMReporter.lua. The program
will always load the latter file if it exists.
A note about virus safety: the ONLY approved versions of DamageMeters come from
www.curse-gaming.com and www.wowinterface.com. If you get it from somewhere
else I cannot vouch for the safety of DMReporter.exe.
-------------------
7) Synchronization:
-------------------
The Sync system is an attempt to work around the fundamental problem of people
not receiving messages from people who are too far away from them. It was made
with raid groups in mind, and so this discussion will focus on how raid groups
can best use it.
Here's how it works: in principle, the only source of errors in DM are from
someone being outside of your range and so you miss their messages. For
example, a raid that is attacking a mob normally has a melee guys close to the
mob and casters standing back. A caster is very likely to miss messages from
melee guys, and a melee guy is very likely to miss messages from a caster.
However, if you took the melee guys' numbers for the melee players, and the
caster's numbers for the other casters, you'd likely have a very good set of
data.
Thats basically what synchronizing does. The actual mechanism is very simple:
everyone transmits all their numbers, and then people just take whatever numbers
are HIGHEST. In theory, each player has perfect data for himself, so if
everyone was involved in the sync'ing you would have a perfect picture. In
practice, thats probably overkill...a handful of people who play different
positions should be fine--maybe a healer, a melee'er, and a hunter.
Sync Quick-Start Guide:
1) Someone in the raid chooses a session name--for example, "Onyxia"-- then
call syncstart with that name. "/dm syncstart Onyxia". This will clear
everyone's data and ready them, as well as mark them with this label.
2) Play! Collect data!
3) Call "/dm sync" whenever you wants the raid to share data. Since it can
cause a little slowdown it is best to do this between fights (though not
necessarily between every fight). If event data is desired, call "/dm sync e",
though it takes a lot longer to sync.
Note: It doesn't matter who starts the session as long as everyone has the same
session id, this will auto-clear any previous data.
Late-joiners: If you've joined a group late and don't have the current session
id then you can request the popular session id by using "/dm syncrequest". This
will 'ping' for the most popular (most users) session id, and then assume that
id and call a sync, thus updating you with the raid's previous data. You can
also manually "/dm syncping" to get an idea of if there's a current session or
not.
IMPORTANT: Calling "/dm sync" when you don't have the current session id will
force others to use your session id and your data.
In addition to the above steps, I'd recommend that everyone doing sync'ing use
the following settings:
* "Only Monitor Group Members" ON: Totems, pets, and such can make the internal
tables reach their limit, potentially preventing actual raid members from having
their data recorded.
* "Treat Pet Data As Your Data" ON: If you are a pet using class, this is the
best (only) way to make sure your total contribution is counted.
a) Event Synchonization
The "Event Data" menu options allow you to specify how much event data you
record. It defaults to self data only because event data can take up a lot of
space. This option also controls how what data you'll transmit and parse when
sync'ing.
Event syncs take much longer than normal ones...up to 90 seconds or so...and
can bog down some people's machines.
b) The Ready Command
To avoid parsing healing done while not in combat, /dm syncready has been
added. Basically, /dm syncready tells everyone to pause, but unpause immediately
as soon as any damage (done or received) is detected. In addition, the
person(s) who detects the damage will broadcast an unpause event. The idea is
to "ready" after a wipe so that none of the healing done while recovering will
count. Ready will make it so you don't have to remember to unpause once you
start combat.
c) Session Labels
You can apply a text label to a session. This serves two purposes. First, it
names the sesssion to you can see what data it refers to, such as "Onyxia" or
"MC". Second, it provides a mechanism for keeping unwanted data our of syncs.
The system works as follows. When someone does a /dm syncclear, the session
label and an index is transmitted. Everyone who receives the clear saves the
label and index. Later, when a sync request is broadcast, the request contains
the same label and index. If anyone who receives the request has a different
label and index it means that they weren't around for the original clear and
could have bad data, so they automatically clear their own data and save the
label and index. The index itself is just a number that increments each time a
clear happens. Its only purpose is to make it so you don't have to think of a
new label each time you want to clear.
-------------------
8) Memory Register:
-------------------
DamageMeters has a second table of information, the Memory Register. It
functions pretty much exactly like a memory button on a calculator. Its purpose
is to have a place for you to save a set of information (for example, the data
from your last raid).
There is a menu option, "Accumulate Data", which makes it so whenever data is
added to the main table (ie. when it appears in your bars), it is also added to
the MR. One possible use of this is in conjunction with the "Reset Data When
Combat Starts" option. If both options were on, for example, you could do an
instance run and see what the data is for each fight
individually, and then at the end look at the memory data to see what the
totals are.
-------------------
9) Overhealing:
-------------------
DamageMeters tracks overhealing to a certain degree. Basically, it tracks
overhealing from direct heals or from individual HOT ticks, but it does NOT
track overhealing from HOT ticks which are entirely lost to overhealing. This
is because WoW doesn't actually send a message when a HOT tick is 100%
overhealing, and it would be incredibly difficult to keep track of how many HOT
ticks are expected to tick for a various player. First, it would be very
difficult to figure out how much a HOT should tick for. In some cases a
person's gear can even change the number of ticks a given HOT has. (8 piece
Stormrage, for example.) Second, a second player can cast the same HOT on
someone and totally bump off the first player's HOT. In addition to the
difficulty in tracking this it also raises the question, "Who should be charged
for this overhealing?"
However, things aren't really as bad as they sound. Basically, because of the
missing HOT messages HOT overhealing has already been excluded from the "Healing
Done" quantity. Now that overhealing from direct heals is also included this
means that "Healing Done" is actually a pretty good measure of the actual
healing done. What -isn't- really a fair comparison is the "Overhealing"
quantity. Someone who heals almost exclusively through HOTs will generally have
a much lower Overheal quantity than someone who heals through direct heals.
Still, Overheal is handy at least for checking out which of your heal spells is
doing the most overhealing, etc, via the event information.
Lastly, the overhealing measurement depends upon WoW sending us exact numbers
for a player's health and max health, and WoW only does this for party/raid
members. Thus, if you play with the "Monitor Group Members Only" option off
(say, for example, in a PVP environment) you're not likely to get any meaningful
overheal information from those players you're picking up from outside your
group.
********************
IV. Version History:
********************
5.7.0 - 10-1-07
*Updated Toc to 20200
*Fixed heal tracking (left over bug from removing Dragon's Breath and Julie's
Blessing regex)
*Renamed Quantity Filters to Quantity Cycling for more clarity
*Added a cycle button for manual cycling, same as the binding. Specify
quantities in the Quantity Cycling menu. This made the top bar a little wider.
*Added X-Localizations and X-CompatibleLocales toc entries
5.6.1 - 5-29-07
*Updated Toc to 20100
*Updated ChatThrottleLib to v16
*Removed english cases for Dragon's Breath and Julie's Blessing (they should be
caught by the normal regex)
*Added Mass Dispell to the english cures list
*string.find replaced with strfind
*Changed DM_Spellometer_Patterns regex to match casters with spaces
5.6.0 - 1-11-07
*Updated Toc to 20003
*Updated Titan Plugin by Seraph
*Increased max combat log range to 2000
*No longer prints range setting on login
5.5.5 - 12-20-06
*Temporarily disabled targeting. It is inflicted by a Blizzard bug that spams
ADDON_ACTION_BLOCKED. It should be fixed for WoW 2.0.2
5.5.4 - 12-20-06
*Fixed bug with show/hiding Status Bars causing lag because of protected
children being blocked.
*Moved Titan plugin to a sub folder
5.5.3 - 12-16-06
*Fixed bug with menus going offscreen. (DropDownList1
|
