Author Topic: FL Raid Parses - Definitions & Notes  (Read 10223 times)

Furro

  • Global Moderator
  • Pies Anonymous
  • *****
  • Posts: 6089
  • Karma: +18/-12
  • freelance raider
    • View Profile
FL Raid Parses - Definitions & Notes
« on: November 18, 2015, 01:25:08 AM »
Raid Parses

Our raids are parsed using our in-house FLBot Performance Parser module.  When attending our raids, following an event you may see parse output provided to various channels.  In-channel parses are limited in scope, which is why we're also working towards more robust parse reports. 

Currently, the short term project is to generate the reports in a forum post format which limits us to BBCode tags for our tables.  BBCode tags limits our ability to do some fancy table design, but it still allows us to organize the data and present enough of it to productively work with.  The long term goal is to generate the reports in HTML format which will allow us to greatly expand on the detail we can provide, and tie it into our existing EQDKP/FLTracker system to allow for historical tracking and referencing.

By tackling the forum report generation first, I'm able to get the information out there so that it'll hopefully benefit our raiders immediately.  Also, the hope is that it'll spur on friendly discussion for areas to improve on a class/individual performance basis.

For now, reports are divided into three sections: Overall, Summary, Breakdown.  The Summary section is currently populated with offensive oriented data of various types (damage dealt, briefly broken down into broad categories).  There are many other details being parsed, it's just I didn't create the tables to display the data yet.  For example, melee breakdown of hits, misses, types of hits and so forth.  These other details will potentially be of interest to classes such as tanks and melee primarily.

One area is of the utmost importance when reviewing the data tables these reports contain, and that is Context.  Context is extremely important, as it describes many different facets in play during an event, which can affect the overall performance of each player represented in the report.

Context areas:
  • Group makeup
  • Effects on player
  • Casts
  • Damage-over-Time (DoT)
  • Direct Damage
  • Deaths
  • Engage Start/Finish/Duration
  • Event class favors (todo)
  • Class roles/assignments (todo)

Group makeup:

Each report indicates the group makeup the player was a member of.  Some classes can provide ADPS, and certain types are only available to a group.

Effects on player:

These are effects that land on a player during the event.  Some effects are sourced back to their originating spell(s).  Some effects share the same patterns as other spells and in such cases all the spells are included within a reasonable threshold.  Excessive cases are indicated at the bottom of the Effects on Player table.

Cautionary note:

If an effect is missing in the Effects on Player table, it does not necessarily mean the effect was not available.  This is where more context is helpful, and the ability to reference other sources can lead to an explanation.  This is where Group makeup, Casts and Effects on Player help.

For example, if Soandso is a member of Group #2, and within Group #2 there is a Druid.  There may be an expectation that within the Effects on Player table, an entry exist for Group Spirit of the Black Wolf ADPS spell.  In the absence of such a spell being listed, it does not necessarily mean that the Druid did not cast the spell.  It could be the spell was cast, but that the player Soandso was out-of-range (OOR) of the effect of the spell, and therefore it will not be listed in the Effects on Player table.  Now, this could be investigated further by sourcing back to the Druid report and look at his/her Casts for the spell.  It could also be that in a large event area, the spell effect was not picked up by the parser due to range issues.  But currently, I'm being careful not to provide parses for large event areas.  The main point here is that the information is available to provide context and that tables such as Group makeup, Casts, Effects on Player and other tables or data points should not be interpreted in isolation.

Casts:

All the casts by a player.  This is not exclusive to spell bar casts, but includes AA and some innate lines.  For example, a Shadow Knight has a Shroud of x buff line, which procs a spell Shroud of x Strike.  The strike proc produces a cast message.  Most players shouldn't have difficulty sourcing back where a spell came from.  Links are provided for each cast to help in this regard.

Damage-over-Time (DoT) & Direct Damage:

Fairly self explanatory.  However, for Direct Damage, multiple spell entries correlated to a single damage entry indicates the effect and/or cast was indeterminate and therefore all possible/probable spells that share the effect message are displayed unless the list is excessive.  Excessive cases are descriptively indicated.

A Miscellaneous entry in a Direct Damage table is for damage that could not be associated with any spell and is usually a result of effects being out of sequence with the damage (some MR procs for example), and/or null effects, where the damage produced no corresponding effect message, or is indeterminate and listing all possible spells is excessive.

With the above in mind, several conditionals are attempted in order to narrow the likeliness to a single option in some of these situations.  This is a work in progress.

Deaths:

Currently, this is a single entry of the number of times an individual has died.  However, internally, we have data available and can query the bot for detailed information, such as what the player was killed by (which mob, AE/DoT/Self), how many occurrences and the exact time.  I may include this as part of the report Deaths sub-table, but for now, just a single entry should suffice.

As a whole, we do find it helpful to know what most players are being killed by, and that's one of the main reasons I wrote in a hook to access the data in-game.

Engage Start/Finish/Duration:

This section of the summary table provides information as to when the PC engaged in offensive action.

Engage (offensive action) entries for Start/Finish/Duration: Duration is based on the difference between Start/Finish values.  The start value is any initial offensive damage action, and the finish value is the last recorded offensive damage action.  This is why Event Duration will almost always differ from the Engage Duration value.  Event Duration is derived from the difference between Start/Finish values that are determined from a trigger based on event lore and/or a customized /rs call.  It's also important to realize that any actions before the Event Start timestamp is not recorded by the FLBot parser.



The remaining table fields of a report should be self explanatory.  However, there is one more area which is important to mention, and that is Named Pets.

Named Pets:

These are pets that have a name, and are not swarm pets, nor familiars.

It's important to associate named pet(s) with their owners, so that the damage can be correctly tied to the player.  The FLBot can track named pets, providing their owners issue the pet leader command after the event has started: /pet who leader

Using the pet leader command will produce a response indicating the pet and owner associated with it.  For example: Sinner says 'My leader is Soandso.

Tip:

You can place the pet leader command in a hotkey that you're sure to use during an event; such as a burn hotkey or something similar.  This way you never have to remember to issue the command.  Issuing the command multiple times is harmless.  It also does not matter when you issue the command during the event, as long as it is done after the event has started and before the event finishes.


Changelog

12-09-2015 - Adjusted for an edge case whereby beneficial type spells could end up being tied to damage due to eqlog range/inconsistencies in the order of events.
12-14-2015 - Fixed a bug in the Breakdown section for DoT damage which resulted in the totals being incomplete.  These changes will only be reflected in posted reports going forward.  Past posts will not be updated to reflect this change due to time constraints.
« Last Edit: December 14, 2015, 07:10:03 PM by Furro »

Furro

  • Global Moderator
  • Pies Anonymous
  • *****
  • Posts: 6089
  • Karma: +18/-12
  • freelance raider
    • View Profile
Re: FL Raid Parses - Definitions & Notes
« Reply #1 on: December 14, 2015, 07:09:38 PM »
Changelog

12-09-2015 - Adjusted for an edge case whereby beneficial type spells could end up being tied to damage due to eqlog range/inconsistencies in the order of events.
12-14-2015 - Fixed a bug in the Breakdown section for DoT damage which resulted in the totals being incomplete.  These changes will only be reflected in posted reports going forward.  Past posts will not be updated to reflect this change due to time constraints.

Furro

  • Global Moderator
  • Pies Anonymous
  • *****
  • Posts: 6089
  • Karma: +18/-12
  • freelance raider
    • View Profile
Re: FL Raid Parses - Definitions & Notes
« Reply #2 on: March 14, 2016, 11:50:42 PM »
Raid Parses

Named Pets:

These are pets that have a name, and are not swarm pets, nor familiars.

It's important to associate named pet(s) with their owners, so that the damage can be correctly tied to the player.  The FLBot can track named pets, providing their owners issue the pet leader command after the event has started: /pet who leader

Using the pet leader command will produce a response indicating the pet and owner associated with it.  For example: Sinner says 'My leader is Soandso.

Tip:

You can place the pet leader command in a hotkey that you're sure to use during an event; such as a burn hotkey or something similar.  This way you never have to remember to issue the command.  Issuing the command multiple times is harmless.  It also does not matter when you issue the command during the event, as long as it is done after the event has started and before the event finishes.



Ok, so Scornfire mentioned that in order to use /pet who leader, you have to target your pet.  I didn't know this!  I guess pet owners are going to have to figure out another way to reliably identify your pets.  If anyone adds some methods, I'll edit them into the post.

-F

Raccoo

  • Pie Hoarder
  • ***
  • Posts: 160
  • Karma: +5/-0
    • View Profile
Re: FL Raid Parses - Definitions & Notes
« Reply #3 on: March 14, 2016, 11:54:28 PM »
You can also target yourself, or nothing at all, I think.

Furro

  • Global Moderator
  • Pies Anonymous
  • *****
  • Posts: 6089
  • Karma: +18/-12
  • freelance raider
    • View Profile
Re: FL Raid Parses - Definitions & Notes
« Reply #4 on: June 19, 2018, 05:06:46 PM »
Changelog:

- 06-18-2018: Corrected a bug whereby pet leader was not associating pets with their owners -- because pets are people too!

This was working previously, but I believe it broke with an EQ patch sometime around 01-20-2017.  At the time, I made changes to adjust for the patch, but didn't realize the EQ patch ended up affecting another area of the code which caused the pet leader phrase to never reach the pattern matching condition.

I ran last weeks raid event logs through the parsing server again, so that the reports generated will reflect the change.