Custom Event Timer
Updated: August 20th, 2011 -- ADDED: Compatibility with new kAuction WeakAura Configurations.
This particular display has been something I've longed for for quite some time, back through the early days of Ulduar, and I'm glad to finally have the ability to get it working.
Purpose
The Custom Event Timer allows a user to generate a normal WeakAuras display with all the usual parameters, but to base it on a series of customized COMBAT_LOG events. Additionally, the display can utilize time-based information to show countdown timers, and it also allows custom messages to be displayed based on the total events that have been triggered (ideal for creating cooldown or other complex rotations).
Import
http://pastebin.com/HYfAh2A9
Usage
Upon importing, the Custom Event Skeleton will appear as a "Group" display, with three sub-displays. Due to the complexity of this system, all three sub-displays are required. However, configuration has been greatly streamlined.
Once you import a Custom Event Skeleton, I strongly suggest you right-click and rename the group and all three sub-displays to something more appropriate. If this display is for a particular event, name the group after that event, and sub-displays as EventName Config, EventName Display, and EventName Reset, for example.
CE Config
The Config display houses the majority of all configuration data, including the all-important trigger(s) that qualify as an event.
1. Under Trigger, specify the event you wish to track. This system is designed to track combat log events primarily, but you may combine a combat log event with other trigger types if you desire (such as checking for a particular aura AND then detecting a combat-log event).
2. Under Actions > Custom > Expand Text Editor you will find all the Configuration settings that should be customized to your needs. With the exception of ID, these config settings only need to be altered one time, in this section, to properly impact the rest of the display.
Below are all the configuration options and details about their usage.
-- id: Unique identifier to distinguish between other timers.
local id = "myId";
The ID should be a unique value of your choosing, that differs from other ID values you may be using in different copies of the Custom Event Skeleton. The ID is the most important setting and is the only setting that must be changed in all valid locations for the display to function properly. The actual value is irrelevant, but the ID is what ties all the sub-triggers within a single group together.
-- time: Time remaining at which to trigger (in seconds), can be
-- decimal. If checkTimeElapsed = true, this is time elapsed at
-- which to trigger instead.
config.time = 5;
The time value behaves just as it does in the DBM Displays for those familiar with that setup. Basically speaking, time is used to specify at what point the display should be triggered, either in seconds that have elapsed, or in seconds remaining before expiration.
-- checkTimeElapsed: Default checks against time remaining before the
-- timer ends. If you want to check against time elapsed instead,
-- change to "true".
config.checkTimeElapsed = false;
CheckTimeElapsed determines if the display will trigger after the specified time value has elapsed from the moment of the event OR if "false", if the display will trigger when the specified time is remaining before the event expires (before the expected cooldown of the next event).
-- duration: Duration the trigger should remain active before
-- untrigger, can be decimal. If set to default of 0 (zero), trigger
-- expires when timer expires. If set to a positive value of say 5,
-- trigger will expire 5 seconds after trigger started, as specified
-- by "time" above.
config.duration = 0;
The duration determines the length of time the display will remain active once triggered before it untriggers. The combination of time, checkTimeElapsed, and duration work together to allow a display to occur midway through what might otherwise be an event cooldown period, as illustrated below:
In the above example, we have an event setup in our Config > Trigger that has a 50 second cooldown between events we're tracking. We want our actual Display to appear 15 seconds before the event cooldown expires and to last a total of 10 seconds, which matches the timespan of the green bar above. Therefore we would specify our time as "15" to show the display 15 seconds prior to expiration, checkTimeElapsed to "false" so the time is checked against time remaining, and finally our duration as "10" to have it expire after 10 seconds, or in other words 5 seconds before the cooldown.
-- frequency: How often the event should trigger this display. If
-- set to default "1", trigger will occur for every matching event.
-- If set to "2", trigger will occur every other event, "3" will
-- trigger every third event, and so on.
config.frequency = 1;
Frequency determines how often the tracked event occurring will actually trigger a display. By default, this is set to "1" so that every occurrence of the event triggers the display, but in certain situations it may be beneficial to only trigger on every other event or every third and so on. Changing the frequency value allows just such a change, so setting it to "2" causes every two events to trigger, or a setting of "4" causes every fourth event to trigger, and so on.
-- ignoreCount: Ignore the first X occurrences without triggering
-- display. Once the specified occurrences have passed, display
-- will trigger as normal, as if the next occurrence was the first
-- instance of the event.
config.ignoreCount = 0;
IgnoreCount is a simple way to cause the system to 'delay' tracking events for a specified number of occurrences. This is useful if, for example, you only want to track an event that occurs in a particular phase of the fight. By specifying a number for ignoreCount, the first X number of events that are detected will be ignored, and only after X+1 occurs will the system begin tracking and triggering displays as it should.
-- cooldown: Estimated delay (in seconds) between cooldowns of this
-- event. This value is used to display approximate timings for the
-- next event occurrence. If left as the default of "0" or "false",
-- the trigger will approximate the cooldown by detecting the
-- shortest cooldown between events.
config.cooldown = 10;
Cooldown is useful when you know the estimated cooldown of the event you are tracking, such that the display can properly calculate duration, time remaining, elapsed values, etc. In the event you are unsure of the cooldown, or the cooldown is varied, leave the cooldown value as "false" or "0" to have the system auto-detect the cooldown. It will calculate the time between occurrences of the tracked event and remember the shortest timespan, utilizing that as the actual cooldown for display purposes. Note: Since the system cannot detect the cooldown until a second cast, no display will occur prior to the second occurrence of the tracked event if cooldown is not specified.
-- messages: Custom messages to be displayed for specified event
-- firings. Useful to create ordered lists such as cooldown rotations.
-- If no custom messages are desired, change to false or delete everything
-- between "config.messages = {" and the closing bracket "};":
config.messages = {
{ -- 1
{
recipient = "dougall",
message = "|cffff0066".."First".."|r message with some colored text for Dougall.",
},
{
recipient = "kulldon,kainhighwind",
message = "First message, displayed for two people.",
},
},
{ -- 2
{
recipient = "ALL",
message = "Second message for everyone.",
},
{
recipient = "kainhighwind",
message = "Second message for Kain is here.",
},
},
{ -- 3
{
recipient = "chukasi",
message = "This is the third message displayed for Chukasi!",
},
},
};
Messages allow for very customized displays to be rotated as the primary trigger event occurs based on the order in the messages config. Configuration of the messages data is done through specifying new entries into a table, as seen above between the opening bracket with commented number to the side, and the closing bracket and comma that follows. Thus the following is a single "entry" in the table:
{ -- 3
{
recipient = "ALL",
message = "This is the third message displayed for all players!",
},
},
The "-- 3" is not necessary, but it is suggested you add this number to each table entry you create just to help you keep track of the numerical value of that entry. Each table entry represents one valid trigger event occurrence -- thus, using the rest of the settings on the config, each event that is actually triggering the display will check for the appropriate occurrence value in the messages table. Therefore, if the third instance of your trigger event went off, it would look for the third table specified in messages (exception: If messageRepeat is true and there are only two entries in messages, the third trigger occurrence would actually repeat through messages again, thus displaying the first message).
That out of the way, the meat of the messages configuration is that the system will utilize the event occurrence info in conjunction with the recipient info for that particular occurrence in the messages table, to determine if a particular player should see the triggered display on any given occurrence. Thus this allows for powerful rotations based on the trigger event, but more importantly, now players not involved in the rotation are not bothered with the display at all. Moreover, messages can be displayed on a per-user or raid-wide basis as appropriate to the specific event occurrence.
Example: We are tracking a dragon casting Flame Breath as our trigger event. We aren't using any complex frequency or ignoreCount settings, thus our setup simply tracks every single occurrence of Flame Breath. We have messageRepeat set to "true", and we're using the three table entries seen above as our messages configuration.
Flame Breath #1: Upon the first trigger event, the system checks messages and finds entries exist, so it pulls the first entry, which is:
{ -- 1
{
recipient = "dougall",
message = "|cffff0066".."First".."|r message with some colored text for Dougall.",
},
{
recipient = "kulldon,kainhighwind",
message = "First message, displayed for two people.",
},
},
It then loops through all the sub-entries that checks if the player's name is found in the recipient field (not case sensitive). Thus, for the players Kulldon & Kainhighwind, when Flame Breath occurs for the first time, they would both receive this display and the text value (%n) would be "First message, displayed for two people." Dougall, on the other hand, would see a display but the text would be different, including some colorized text at the start: "First message with some colored text for Dougall."
No one else in the raid would see the display from that first Flame Breath, because only those three users are specified in the first entry in the messages table.
When Flame Breath is cast a second time, the system now uses the second entry (if one exists) within the messages config data:
{ -- 2
{
recipient = "ALL",
message = "Second message for everyone.",
},
{
recipient = "kainhighwind",
message = "Second message for Kain is here.",
},
},
Now, for this second Flame Breath occurrence trigger, Kainhighwind gets a display unique to him, but everyone else also sees a display with a different message.
The messages portion, in conjunction with the rest of the configuration, can be fairly complicated, but it should prove very powerful for creating quite complex rotations within the raid. This config setting is primarily meant to give on-the-fly information about certain actions the user should perform for any given event. This is also useful with the final setting.
-- messageRepeat: Boolean setting that specifies if custom messages will
-- be repeated at the end of the list. If false, trigger will display
-- default name after list has been exhausted.
config.messageRepeat = true;
MessageRepeat is a boolean value that specifies if the list of messages used above should be repeated ad naseum after it reaches the end of the list. This is great for things like cooldown rotation loops based on a particular event, such that the user can be reminded every fourth event, for example, that their own cooldown will need to be utilized.
CE Display
The Display section specifies the actual "look" of the warning. Just like any other WeakAuras display, you may freely move the position, change the display type (text, model, icon, etc), change the bar size and settings, colors, etc. within the "Display" section. You may also change the "Actions" and "Animations" settings as necessary.
For proper configuration there are four trigger sections that must have the ID value specified. Under Trigger, set the ID value to match the ID used in CE Config > Actions for the following four sections:
- Custom Trigger
- Custom Untrigger
- Duration Info
- Name Info
Once the ID values are correctly matching, that is all the configuration needed in this section.
CE Reset
Finally, the CE Reset display only requires one minor configuration, which again is to change the ID value to match the ID specified elsewhere in this display group. Once ID is set properly under "Trigger > Custom Trigger", CE Reset is fully configured.
Ready!
That's it, your Custom Event display should be ready for use!