Since I’ve been away, I missed posting about the new Cataclysm changes coming for the Priests.  Not a whole lot to talk about really since it’s all subject to change anyway.

I’ve also recently (few months ago) transferred back to my original server, Azuremyst-US, to be back in the raiding scene and be with some old friends/guildies.  So far, eveything is working out great, but we are falling behind in the race to clear Icecrown Citadel Hard Modes.  Right now, our main problem is the lack of any sort of set-group of 25 people who consistently show up to raid.  We’ll get people to show up Tuesday & Wednesday (a.k.a Free Loot Night), but then people will have conflicts/connection problems/excuses for Thursday and Sunday.  The last two weeks, we’ve cleared up to Lich King, but have had (maybe) a total of 45 minutes of time on him.  Obviously that isn’t enough, but what can we do when we don’t have people show up.

Again, if your a caster and would like to blog a bit (maybe once a week or even bi-weekly is fine), let me know!

Ask the Raiders is a short article I’ll run each week, asking you (the Raiders) something that pertains to your raids/guilds/play style.  I’m looking forward to hearing some of your answers and I hope you can provide me with some valuable insight on how other players take the World we all play in.

So, there you are at the start of the raid.  You get their early.  You’ve read up on the bosses for tonights raid.  You’re ready to grab some badges and loot.  Now, did you forget anything  Think real hard…

WHERE ARE YOUR CONSUMABLES?

If there is one thing that ‘irks’ me more than anything, it’s when people come to Progression Hard Mode content, and they don’t bring food, flasks, or potions.  There is no excuse for not having them.  In 2 hours, I can do my Cooking, Jewelcrafting, and Fishing Daily along with 22 other Daily Quests in Icecrown and make ~300G.  I know some of you are saying ‘Well, I don’t have an extra 2 hours to play’, then perhaps try and make an arrangement with the Guild leader or someone else to perhaps give you a few extra Flasks/Potions/etc.  It’s not fair for 24 other people to show up with consumables and you be the only one without them.

I’m not a Guild or Raid leader, but I do like to make sure everyone is ready, so I use an nifty little addon called RaidBuffStatus.  It monitors all buffs, and determines what people are missing, and which people are capable of giving out those buffs.  My personal favorite (and my guild leader’s most hated) feature is when the RBS whispers players who are missing a food buff before the Fish Feast expires.  This let’s them know that someone is watching and trying to hold them accountable.  This addon also allows me to broadcast to the raid what players are missing which buffs.

I usually just let the slackers slip buy, unless it’s a food buff (there’s no excuse to miss that), so maybe a Mage is missing Gift of the Wild and the lead healer doesn’t have Kings, or maybe the Boomkin only popped 1 elixir instead of two.

Now, here is what I’m asking all of you.  Do you not worry about it?  Do you inform the Raid/Guild leader or officers?  Do you ask the person directly?  Are you one of those people who aren’t fully buffed and don’t worry about it?

At one point each class config file (more on those in a moment) had instructions within. However, as EventHorizon’s API grew, so did the instructions – If I were to include them within the files now, the instructions would be longer than the configs!

In today’s article we’ll be going over each available setting. A certain level of Lua knowledge will be needed for this, which we covered for the most part in the previous post. Assuming you’ve read and understand it, all that’s needed is a quick interlude to explain how the spell config works.

Lua Recap: The Spell Config

EventHorizon’s class config files are located in WoW/Interface/AddOns/EventHorizon_ClassName, where ClassName is, of course, the class you intend to change. These files are only loaded if you are playing that class, and are loaded after the general config. This can be useful later on, which I’ll cover in the next section.

The class config creates a function which is called but left undefined within EventHorizon’s core. This function, EventHorizon:InitializeClass(), is a method which assigns the spells to a given class when played.

EventHorizon:InitializeClass() calls multiple instances of another function, self:NewSpell(). NewSpell takes the table that it is given as a parameter (more on that in a moment) and uses that information to create the spell within EH.

The basics:

self is a shortcut for the table that we’re working with. In the case of the class config, self can be replaced with EventHorizon freely. There’s no real reason to use self within the class config aside from being shorter to type, but I feel that it makes it a tiny bit easier to see what’s going on from a novice perspective.

A function is, briefly, a list of instructions to perform with optional returns and parameters. Since this article’s scope is limited to the essentials for the spell config, we won’t delve into it much. It’s enough to know how a function works.

local Foobar – If a value is not specified when declaring a local, the local defaults to “nil”.

local function DoThis() – First declare the function.

local Rawr = “lol” – A local declared within a function cannot be accessed outside the current execution of the function. In other words, this line does absolutely nothing since we’re not doing anything with Rawr. If we tried to use Rawr later, Lua would spew an error.
Foobar = Rawr

end – Ending the function.

Functions can also be used as if they are variables through the use of returns. Again, not delving into the topic too much since there’s a good bit to cover here, but be aware that anything below the return line in a class config file will not be executed.

A function aspect to be aware of in this case: parameters. Those parenthesis following a function may be used to provide a function with essential data. With the spell config, we’re giving NewSpell a table which is translated into usable information for EventHorizon’s core.

To recap it all…

IntializeClass() is a function defined within the class config that, when executed, gives EH the spell information for the currently played class.

NewSpell( {table} ) is executed multiple times within InitializeClass, providing usable information to EH for each spell in order. This function uses a table as a parameter to do so.

Due to InitializeClass and NewSpell both existing within the EventHorizon global table, we can use self as a shortcut within InitializeClass for readability’s sake.

Applying Knowledge: A Few Things To Do

Knowledge is half the battle, or so they say. Now that we’ve got an understanding of how the class config works, we’ll take a deep look into what can be done with it.

Myconfig: Since we’re making changes to essential aspects of EventHorizon here, we want to make sure that we’ve got a backup and that we don’t lose those changes in an update. Myconfig is an excellent way of doing that – Just like EH’s general config, make a copy of config.lua and rename that copy to myconfig.lua. You can’t just delete the contents like last time though, since we’re not just changing fields in a table.

Using the class config as another general config: The class config files are loaded after EventHorizon’s core and config files. This lets you change things around in the class config without mucking with conditionals and all that. If you want to change settings or colors, just write in the appropriate code before the function call at the top of the file. You’ll notice that EH’s config is declared for your convenience.

Deleting or moving spells: Easily done. If you want a bar to appear higher or lower in the frame, just move its NewSpell function accordingly. The spells are defined in the order which they appear in EH. To remove a spell from the frame completely, delete its NewSpell entry and you’re all set. Efforts have been made to label each spell with a preceding comment so that they can be found easily. (Little note here, I’ve also tried to be as complete as possible when describing a bar. If you’re not sure why a bar is included in the first place, take a look at the config. Secondary effects have been applied to many, many otherwise pointless bars)

That’s all well and good. Let’s dig deeper and start changing things up.

Finding a Spell ID

You’ll need to know how to look up a Spell ID before adding or removing much from a bar. They can be found easily enough via WowHead. To look one up you usually only need the spell’s name.

• Know what you’re looking for. EventHorizon has the ability to look for any buff or debuff visible to you, including the effects of your equipped trinkets. The type of spell you’re looking up does matter when searching for it.
• Know that EventHorizon looks up spells by name for the most part, but does require that the Spell ID is usable by EH. Certain IDs aren’t, which will be covered here.
• If you’re looking for a usable ability or common buff/debuff, here’s how. We’ll use Rupture for this example:

1. Type rupture into the search box. You’ll be greeted with a list of search results.
2. Since we’re looking for a usable ability, head to the Abilities tab and click one of the ranks.
3. Take a look at the URL bar of your browser. If we picked Rank 1, this would be “http://www.wowhead.com/?spell=1943″.
4. The Spell ID is the number at the end.

• If you’re looking for the effect of a trinket, the process is a little more complicated. Let’s use a Fetish of Volatile Power for this, and assume we have no idea what the buff’s name is. The same can be done for talents.

1. Search for fetish of volatile power. It should bring you straight to the trinket’s page.
2. Click on the tooltip line saying “Use: …”. This should bring you to another page.
3. We’re now looking at the trigger of the effect. This isn’t quite usable – EH will show a tiny marker when you use the trinket, but because the name of the trigger isn’t the same as its effect, we still need to dig deeper. Scroll down a little and look at the Spell Details section.
4. You should see a spell name and icon somewhere in there. Click on it and we’ll have the actual buff that’s applied when the trinket is used. For reference, you should be at “http://www.wowhead.com/?spell=67743″, looking at a spell named Volatility.
5. This is the one we want. The Spell ID is the set of numbers at the end. While this didn’t take long to look up, you’ll note that the information we needed was buried fairly deep. To make this a little easier in the future, you’ll want to know the name of the buff or debuff beforehand and search for it directly.

• If you’re looking for a glyph, the process is again a little different, but also shorter as long as you know what to look for. EH looks up glyphs directly by ID instead of by name, so we need exact information here. We’ll use Glyph of Life Tap in this case.

1. Search for glyph of life tap. You should see three tabs: Items, Professions, and Uncategorized spells.
2. Head to the Uncategorized tab.
3. You should see two results there, both with the same name but different icons. One is the glyph application, one is the glyph when equipped. We want the equipped version. One way to tell is by looking at the tooltip – The glyph application has a cast time, while the equipped glyph does not. Another way is via the icon itself – Application has a unique icon, while the equipped glyph generally has a golden gear for its icon.
4. Once you’ve figured out which one the equipped glyph is, click it and find the Spell ID as normal. Again, it’s at the end of the URL.

Working With The Config: Applied Knowledge

Alright, so it’s been over 1500 words and I haven’t even started on the easy stuff. No more examples, on to the variables! Remember, these are case sensitive.

Note that if a variable is boolean, it may still act as if it were true due to how EH checks these settings, even if set to nil. This may change, but in the end it’s best to remove or comment out a line if it’s not required instead of setting its opposite.

• spellID = number - The only required line for NewSpell. This sets the spell’s icon, internal name, and Combat Log spellID to keep track of. Any time you’re adding a new spell, you’ll need to use the steps above to find its ID, which usually goes here.
• cast = boolean – If this is present, EH displays a cast bar as appropriate for the primary spellID. Spells contained within debuff and playerbuff aren’t tracked with this. If a spell is channeled, use channeled instead.
• channeled = boolean - Cannot be used with cast. Tells EH that this spell is channeled and adjusts its logic accordingly.
  • numhits = number - Optional variable for channeled, specifies the number of hits in a channeled ability. No effect if present and a spell is not tagged as channeled. If you’re trying to find the number of hits in the channeled ability, duration/interval of hits is the math to use.
• cooldown = boolean - If present, tracks the cooldown of a spell. Same deal as cast, doesn’t track anything but the defined spell.
• requiredTalent = table = {tab, index, requiredPoints} – Tells EH to track talents for this bar. Talents may be found by your talent window or any of the talent calculators available online. The tab is a number from 1 to 3, found by counting left to right along the available talent pages for a class (For warriors, Arms = 1, Fury = 2, Protection = 3). The index can be found by counting the talents within a tab from left to right, top to bottom. Position within the tree doesn’t matter, you just need to count the icons. requiredPoints is optional, can be any number from zero to 5, and means “Only show this talent when it has this many points”. Setting the field to zero tells EH to only show a bar if the talent has no points applied to it.
• requiredGlyph = number - Can be used in combination with requiredTalent. Adds a glyph requirement to the bar using the equipped GlyphID (method to find is located above). Especially useful for Glyph of Life Tap.
• stance = number – Tells EH to only show a bar when in a specific stance or form. A Priest in Shadowform has a stance of 1. A Druid in Cat Form has a stance of 3. A Warrior in Defensive Stance has a stance of 2, so on, and so forth. At present there is no way to tell EH to not show a bar when in a specific stance, though there are plans to change that.
• auraunit = string – This field is present in every spell that EH tracks, and may be manually set. Buffs default to ‘player’, while debuffs default to ‘target’. This can be any unit able to be tracked via macros (pet, partyX, targettarget, focus, etc).
• playerbuff = boolean or number or table - Cannot be used with debuff for various reasons. Tells EH that this bar tracks buffs using the UnitBuff(auraunit) API and sets the auraunit to ‘player’ unless otherwise specified. Shares optional variables with debuff. If set to true, tracks buffs of the same name as the primary spellID. If set to a number, tracks a single buff using that spellID. See instructions in the next entry for multiple tracked buffs.
• debuff = boolean or number or table - Cannot be used with playerbuff for the same various reasons. Tells EH that this bar tracks debuffs using the UnitDebuff(auraunit) API and sets the auraunit to ‘target’ unless otherwise specified. Shares optional variables with playerbuff. If set to true, tracks debuffs of the same name as the primary spellID. If set to a number, tracks a single debuff using that spellID.
  • To track multiple buffs or debuffs on a bar, use an iterated table containing {spellID1, spellID2, etc}. Each entry in the table marks another spellID to track. Note that if multiple buffs or debuffs are tracked, only the primary spellID is capable of tracking periodic ticks (other spells listed in the debuff/playerbuff field will be ignored as far as periodic effects are concerned). You cannot combine buffs and debuffs like this, sadly.
  • dot = number – Seconds between periodic tick effects. Tells EH to watch for periodic tick events and display tick markers accordingly.
    • cleu or event = string or table – Can be used with channeled+numhits as well, or really any spell that otherwise refuses to show up. Adds (does not override) a combat log event to track for ticks on this bar. This is useful for spells no handled in a standard fashion. Penance, for example, uses SPELL_HEAL as its tick event even though it is a channeled spell and should use SPELL_PERIODIC_HEAL. Only use this if you’ve exhausted all other options for getting periodic events working on a spell – It won’t break anything, but it does have an impact on performance. Multiple events may be added via an iterated table if needed.
    • hasted = number or table = glyphID or {talentTab,talentIndex} – Added in EH v1.3, for Patch 3.3 support. Can be set to either a Glyph (using just the glyphID, no table) or a talent (using a table with the standard tab,index format). This setting adds in a little extra handling for the bar, allowing ticks to be quite a lot more accurate when they’re affected by haste.
    • refreshable = boolean – Changes the logic used for spell refreshes and stores extra information between target swaps. If this value is present, periodic tick intervals will not be reset when a spell is refreshed and no gap will be drawn in the bar showing that it was. This is mainly used when a spell can have its duration extended or refreshed by another spell (Shadow Priests with Mind Flay and SWP, Affliction Warlocks with Haunt and Corruption, Rogues with Rupture and Glyph of Backstab, Deadly Poison, etc). Note that this does not affect re-casts, so manually refreshing a spell instead of using another will reset ticks and such accordingly.
  • unique = boolean – Tells EH to track auras from other players in addition to your own. Especially useful for things like Mortal Strike/Wound Poison, Trauma/Mangle, etc. Can be used to great effect with multiple specified auras, or alone for truly unique effects such as Weakened Soul.
  • minstacks = number – Used currently in the Mage config for Arcane Blast if you’d like an example. Sets a minimum number of stacks before the aura’s bar is shown.
  • internalcooldown = number – Not all spells have cooldowns that are visible to EH. For example, if tracking a trinket or Cheat Death, there is no way to see the cooldowns involved. internalcooldown solves this by placing a cooldown line as soon as the aura is detected. While not entirely accurate, especially for multiple tracked spells, it works pretty well. Most trinkets with proc effects have an internalcooldown of 45, most usable trinkets are 120, etc. Setting this to true won’t do you any good. Requires an aura to track, and is thus unavailable for bars tracking only cooldown.
  • glyphrefresh = table = {numRefreshes, GlyphID, TriggerName}  – A complex var that adds glyph-based spell refresh tracking (Glyph of Backstab extends Rupture up to 3 times per usage). numRefreshes is the maximum number of refreshes per primary spell cast. GlyphID can be obtained using the instructions above (this will not track extensions without a glyph). TriggerName is the exact name of the spell that triggers the extension.
  • textureID = number – Displays the buff/debuff bar only if the aura’s icon matches this. When a spell has multiple effects of the same name but differing icons, this gives you the ability to choose which is shown on the bar. See the Druid config for examples (Eclipse).

Hopefully I’ve covered everything here. Happy modding, and we’ll see you next time!

Previous – EventHorizon Course 3: Pimping EH

You can download EventHorizon here.
If you enjoy the addon, remember that donations are what keeps it alive and evolving. I no longer play the game any more than necessary for testing purposes, and cannot spare the money to keep my WoW account running for that purpose alone.

Lua: Your Friendly Neighborhood Scripting Language

All of EventHorizon’s configuration is done through Lua, which is the language of WoW’s addons. Before we go rummaging through the config files, you’ll probably want to know some of Lua’s absolute basics.

I’ll skip the lengthy introductions and head straight for the relevant portions. First, some jargon.

A note on all of this: Lua is case sensitive. If you miss capitalizing a letter, Lua will spew an error at you.

A comment, signified by a double-dash ( – ), is a line or bit of text that is not executed by the interpreter (in this case, WoW). Comments give you the ability to let yourself and everyone else know what a particular chunk of code does.

Comment blocks are multiple-line comments, signified by a leading double-dash and double-bracket ( –[[ ) and ending with another set of double brackets ( ]]– ). Note that the tailing comment dashes aren’t necessary, but it’s not a bad idea to write them in.

A local is a portable, named, re-assignable chunk of information which is only used within the function or file it was created in. More on how they’re used in a second.

A single = sign sets a chunk of information to something else.
A double == sign checks if one chunk of information is an exact match to another.
A tilde followed by a single = sign ( ~= ) checks if a chunk of information does not match with another.

local X = “Foo!” – Assigns X as a string
local Y = X – Assigns Y to X’s value
local Class = UnitClass(‘player’) – A WoW function that checks the class of a unit. This local will end up reading “PRIEST” if you’re playing one, “DEATHKNIGHT” if you’re on your DK, etc.
local Priest = UnitClass(‘player’) == ‘PRIEST’ – A little more complicated, checks the player’s class and assigns “Priest” as the string as “PRIEST”  if playing one.
local NotPriest = UnitClass(‘player’) ~= ‘PRIEST’ – Same thing in reverse, if you’re not playing a Priest it’ll assign NotPriest as your class’s name.

A table (Anyone who’s written in C/C++ likely prefers calling them arrays) is a list of data, declared in the same fashion as a local but using curved braces ( { and } ) to contain its information. Tables have all sorts of uses – Most of EH’s settings are stored in one giant table named EventHorizon.

Tables may be indexed or iterated. An indexed table can be described as a table that contains a bunch of locals. An iterated table is pure data, without named indexes. To clarify:

local Table = {“This”, “is”, “an”, “iterated”, “table”} – I’ll give you three guesses, first two don’t count. Note the commas separating everything.
local Table2 = { – An indexed table.
foo = 1,
bar = “String!”,
rawr = {“Another”, “table!”},
class = UnitClass(‘player’), — Yep, you can call functions in tables too.
} – The table only ends when its matching curved bracket appears.

Tables can be accessed in quite a few ways. The easiest is when using an indexed table, calling the entry by the index name. You may also call them by their iteration, which is explained below.

local Iterated = {1, 2, 3, 4, “Foo”, “Bar”}
local Indexed = {
foo = “lol”,
bar = “haithar”,
table = {“can has”, “cheezburger”}
number = 1, – Note: A number cannot be used as a table index.
number2 = 2, – This is because of table iteration. Long story.
}

– First, let’s call some stuff in the iterated table. The best way of doing this is via square braces, though there are other ways. Again, we cannot assign a number as a local, so we’ll be spelling out the numbers as we assign them.
local One = Iterated[1] – 1
local Two = Iterated[2] – 2
local Three = One + Two – Yes, you can do that, and yes, the result is 3.

– Next up we’ll call some things from the indexed table. Indexed tables are a little easier to use in some respects, and harder in others. Mix and match methods as you please, it’s flexible stuff.
local Foo = Indexed.foo – Called by name.
local FooToo = Indexed[foo] – Those square brackets really come in handy, this does the exact same thing. However, if “foo” is declared as a local…
local String = “foo”
local FooThree = Indexed[String] – …then the local will call that portion of the table.
local FooIt = Indexed[1] – Called by iteration. This isn’t generally useful for indexed tables, but can come in handy. See why a table index cannot be a number now?
local Table = Indexed.table — Our Table local now reads {“can has”, “cheezburger”}.
local TableOne = Indexed.table[1] – “can has”…
local TableTwo = Indexed.table.2 – “cheezburger”.

Using All That In EH

If you don’t already have it installed, it would be a very good idea to snag Notepad++ (NPP) and start using it from here on out. Lua is a very simple and easy to learn language, but if you’re trying to use the Windows Notepad or (*shudder*) WordPad to edit EventHorizon’s config files… it won’t be. NPP is free and open source software that uses syntax highlighting to make what you’ll be doing much, much easier, among other things.

I’ll assume from this point on that you:

• Know where WoW is installed (I have mine in D:ProgramsWoW, for example)
• Know where EventHorizon is installed (within your WoW directory, Interface/AddOns/EventHorizon).
• Know how to open a file with Notepad++ (rightclick a .lua file, you’ll see the option in there).
• Have file extensions enabled in Windows Explorer, or at least know how to see and change them.

EventHorizon comes with the following files:
EventHorizon.lua contains EH’s core code. No user should ever need to touch this file.
EventHorizon.toc tells WoW which .lua files to load and run. Again, no user should ever need to touch it.
config.lua contains EH’s default settings and comments with usage information.
changelog.txt is a running tally of the changes made to EH over its lifespan. It makes for a good read, believe it or not.
Smooth.tga is the texture used in EH by default.

There’s one extra file that EventHorizon will load, when it’s present: myconfig.lua.

Myconfig acts as a second config.lua. Anything put in here will overwrite settings in the original config. And, since it’s not included with EventHorizon’s releases, it’s safe to assume that it will never be overwritten by a new version. This is good for everyone – myconfig.lua can be shared as you please, will stick around every time you update EH to the latest version, and can have as many or as few options as you like.

So, let’s create a copy of config.lua within EH’s directory, rename the copy to myconfig.lua, and open it up in Notepad++.

The first line of any config file should be this:

local config = EventHorizon.config

This tells the file that any time you type “config” you’re actually changing EventHorizon’s internal configuration table.

Next you’ll notice a bunch of locals assigning plain-text names to class calls. We’ll cover usage of these soon.

Now, on to the settings that EH uses!

• recalculate (Default = true) tells EH to adjust DoT and HoT ticks as they fire. This option will be removed with the WoW Patch 3.3 update.
• past (Default = -3) is the number of seconds to track in the past section of the window. This needs to be a negative number for technical reasons.
• future (Default = 12) is the number of seconds to track in the future section of the window. This needs to be a positive number. EH’s time scale is judged from this – A larger number will result in shorter gaps between DoT ticks, slower-moving bars, etc. If you find that the default seems to cover too short or too long of a time span, try adjusting this. I used 30 seconds for quite a while myself.
• spacing (Default = 0) is the number of pixels between bars on the EH window. This is purely cosmetic. Adjust if you’d like more room between the bars or to match your UI layout.
• scale (Default = 1) is the actual UI scale of the EH window. A value of 1.5 will enlarge the window by 50%, a value of 0.75 will shrink it by 25%.
• height (Default = 18) is the height in pixels of a single bar. EH has no limit to its size, so there is no way at present to directly set the height of the window – The actual window height is ((height + spacing) * the number of bars)*scale.
• width (Default = 150) is the width in pixels of the EH spell bars. The spell icons add the bar’s height to its width. The actual width of the frame is (width + height)*scale.
• anchor (Default = {“TOPRIGHT”, “EventHorizonHandle”, “BOTTOMRIGHT”}) is a somewhat complex field that needs a little extra explanation. WoW’s frame system is based completely on anchors, and this sets EH’s anchor accordingly.
  Valid points are LEFT, RIGHT, TOP, BOTTOM, CENTER, TOPLEFT, TOPRIGHT, BOTTOMLEFT, BOTTOMRIGHT. These points are the edges (or absolute center) of the respective frames. TOPLEFT is the absolute top left corner of the frame, for example.
  Knowing this, the syntax is {“Frame’s Point to Anchor”, “Frame to Anchor to”, “Anchor Frame’s Point”, offsetX, offsetY}. In the default, we’re anchoring the TOPRIGHT corner of EventHorizon’s frame to the BOTTOMRIGHT corner of EventHorizon’s handle with no offset.
  To keep EventHorizon movable ingame, it needs to be anchored to “EventHorizonHandle”, a little draggable button that’s created only when it’s needed.
  If you don’t feel the need to move EH, say if you’ve got a very specific UI layout, you can anchor the frame to just about anything else. Wimpface anchors his to his character’s unitframe. I anchor mine to my target’s. In these cases, the drag-handle isn’t even created and the frame is completely immobile.
  To place the frame directly at a point of the screen, use “UIParent” as the anchor. A few examples are in config.lua to give a better idea of how to do all this.
• texturedbars (Default = true) tells EH to use a given texture. If texturedbars isn’t present (or is set to nil) EH will use solid colors as its bars instead.
• texturealphamultiplier (Default = 2) Textures don’t have the contrast that solid colors do in a transparent environment. This field multiplies the opacity of any bars that use a texture. If the bars seem too dim or too bright, raise and lower this number until it feels right.
• backdrop (Default = true) tells EH to draw a background under its bars. If you don’t feel the need for a background or prefer to use something like kgPanels to set a backdrop yourself, remove the line or set it to nil.
• iconborder (Default = false/nil) tells EH whether or not to draw WoW’s built-in border around the spell icons. If you’re using the default backdrop with a little spacing between the bars, this can be a nice effect.
• castLine (Default = true) adds a line to the end of any spellcast or channeled cast over 1.5 seconds, extending vertically across the frame. This line should be as accurate as the cast bar itself and seems to help quite a bit for any cast longer than the GCD. Uses the ’sent’ indicator coloring for technical reasons. Remove or set to anything other than ‘true’ to disable if you dislike it.
• gcdstyle (Default = ‘line’) Valid options are ‘line’, ‘bar’, or false/nil. This option sets the Global Cooldown indicator accordingly: ‘line’ draws a thin line that looks like the Now Line for the GCD. ‘bar’ draws a much more visible bar vertically across the window. Setting this to nil or false will completely disable GCD tracking, saving a little CPU.

Short interlude: Coloring.

EventHorizon uses a table-based coloring system. Each color table has four values: {Red, Green, Blue, Alpha}. These entries have a minimum of 0, and a maximum of 1. These do not need to be whole numbers, you can use as many decimal places as you like. The Alpha is simply the opacity of a color, how transparent it is. A short list of common colors with alpha values omitted:

white: {1, 1, 1}
red: {1, 0, 0}
green: {0, 1, 0}
blue: {0, 0, 1}
yellow: {1, 1, 0}
orange: {1, 0.5, 0}
purple: {1, 0, 1}
pink: {1, 0, 0.5}

Math and fractions may be used as well within the table, as such:

red by 255: {255/255, 0/255, 0/255}
teal with some extra blue: {0, 199/255, 1}

Continuing on…

• gcdcolor (Default = {1,1,1,0.5}) sets the color of the GCD bar or line. Use the information just above to see how this works.
• bartexture (Default = “InterfaceAddonsEventHorizonSmooth”) sets the texture used for all of EH’s graphics. Note that SharedMedia is loaded as an optional dependency of EH, meaning that its textures will be available to use as long as you know their paths. Better SharedMedia support is planned sometime for a future release, which would allow you to simply provide the texture’s name.
• barbgcolor (Default = {1,1,1,0}) Note: The default has a color, but it’s completely transparent. EH creates a background for each bar (using the same texture as the bar) using this color. If you decide not to use a backdrop for EH at all, it may be a good idea to adjust this as well.
• bg (Default = “InterfaceChatFrameChatFrameBackground”) sets the texture used for EH’s backdrop frame.
• border (Default = “InterfaceTooltipsUI-Tooltip-Border”) sets the texture used for the backdrop frame’s border. SharedMedia includes a couple on its own, I also have a few that I can send at request. Note that this does not affect the spell icon borders.
• bgcolor (Default = {0,0,0,0.6}) sets the color of the backdrop.
• bordercolor (Default = {1,1,1,1}) sets the color of the border.
• inset (Default = {top = 2, bottom = 2, left = 2, right = 2}) is an advanced setting that adjusts how many pixels the backdrop’s texture is adjusted by to account for its border. Tweak as needed if you change your backdrop.
• padding (Default = 3) allows the backdrop to grow beyond EH’s actual frame size in pixels. The default extends 3 pixels past EH’s edges, for example. Adjust as you see fit if you change your backdrop and border.
• edgesize (Default = sets the thickness of the backdrop’s border. The optimal value for this depends on the border you choose and your UI in general.

That covers the standard settings. Notice that I’ve been pretty much following the layout of config.lua. If you scroll down a bit in the file you’ll see the color settings.

EH handles coloring for bars and bar segments on an individual basis, allowing you to set different colors for each type of information shown. Aside from setting the coloring manually via RGB values, you may also class-color any or all of these.

To do this, EventHorizon uses two extra config values not normally listed in config.lua (You knew I was gonna leave something out in the config, right?):

• classburn (Default = 0.7) is the degree of which a class’s color is automatically darkened. Within the defaults, this setting is not used at all and is basically a failsafe (you’ll see why in a moment). It may still be manually set, and can be a value over 1 if desired.
• classalpha (Default = 0.3) is the default opacity of a class-colored bar. Again, this isn’t used within the default config and is there mainly as a failsafe.

EH assigns each shown graphic a type. The types are:

• sent is the marker lines drawn when a skill usage has been attempted and sent to the server. This does not mark the actual start of a cast or skill usage. This value is also used for the vertical casting line, marking the finish of casts over 1.5 seconds. (Default is class colored)
• tick is the color of the little lines drawn indicating when a DoT or HoT spell will heal or do damage. (Default is class colored)
• casting is the color of the cast and channel bars. (Default is green)
• cooldown is the color of any cooldown lines. (Default is white)
• debuffmine is the color of the debuffs that you have personally cast. (Default is class colored)
• playerbuff is the color of the buffs that you have personally cast. (Default is class colored)
• debuff is the color of anything that is tracked but not cast by you. For example, if playing as a Feral Druid with an Arms Warrior in the group, your Mangle bar may display the Warrior’s Trauma debuff as well. (Default is your class color, darkened by 50%)
• default is unlisted in config.lua but may still be modified. This color is a fallback that is used in any case where EH can’t decide what’s going on. It isn’t seen in normal gameplay and its usage rests in debugging. (Default is pure white at 100% alpha)

Now that we know what can be colored, how do we do it?

The color table is stored outside of EventHorizon’s standard config: EventHorizon.colors. This table can be changed as a whole or piece by piece. Config.lua prefers piece by piece, and the defaults may be found at the bottom of the file.

Coloring may be done manually via {Red, Green, Blue, Alpha} or automatically via class coloring. The method of class coloring a bar is simple enough: Tell EH the bar is colored, and optionally add in burn and alpha.

local c = EventHorizon.colors
c.casting = {0,1,0,0.3}
c.debuff = {true,0.5,0.3}

The casting color is manually set to green, 30% opacity (since the opacity is multiplied if using textured bars, this is usually 60% opacity).

The debuff line reads exactly like this: Class colored (true instead of a number), 50% burn (the class’s color values are multiplied by 0.5), 0.3 alpha (30% opacity, again modified for textured bars).

If c.debuff is set simply to {true}, it will be class colored and use config.classburn and config.classalpha to fill in the blanks.

But wait. The default values for the other fields are a lot more complicated!

c.debuffmine = {true, Priest and 0.7 or 1, 0.3}

Remember those locals that were declared at the top of config.lua? This is where they really shine. The debuffmine entry reads literally as: “Class colored, burn to 0.7 if playing a Priest or 1 otherwise, 0.3 alpha”. This can be wrapped in parenthesis and even expanded if we like, as such:

c.debuffmine = {true, (Priest and 0.7) or 1, 0.3}
c.debuffmine = {true, (UnitClass(‘player’) == Priest and 0.7) or 1, 0.3}

c.debuffmine = {true, 1, 0.3}
if UnitClass(‘player’) == “PRIEST” then
c.debuffmine[2] = 0.7
end

There’s a lot of ways to do it. Since the Priest color is pure white, it’s darkened a bit to give cooldowns some contrast from buffs and debuffs. If you want to make Priests not use class coloring at all, you can do that in a few ways as well:

– Using inline conditions as before:
c.debuffmine = {(Priest and 0) or true, (Priest and 0.3) or 1, (Priest and 1) or 0.3, Priest and 0.3} – Reads {true, 1, 0.3} for everyone else, but Priests read it as {0, 0.3, 1, 0.3}.

– Or we can overwrite it using an if/then statement.
c.debuffmine = {true, 1, 0.3}

if Priest then – We’ll use our locals this time, this reads as “if UnitClass(‘player’) == ‘PRIEST’ then”
c.debuffmine = {0, 0.3, 1, 0.3}
end

In Closing

EventHorizon has many ways that you can customize it. This course has only scratched the surface – Using the config/myconfig system, you can turn EH into everything from a combat monitor to a buff watcher to a pure cooldown tracker. In the next course we’ll be covering everything related to spell configuration. Stay tuned.

Previous – EventHorizon Course 2: What EH Is Not
Next – EventHorizon Course 4: Mucking With the Class Config

You can download EventHorizon here.
If you enjoy the addon, remember that donations are what keeps it alive and evolving. I no longer play the game any more than necessary for testing purposes, and cannot spare the money to keep my WoW account running for that purpose alone.

Scoping: What Programs Do and Don’t Do

While I love to add new features and strive to make EH the best possible solution for combat awareness, I’ve had to learn over the last year to say no quite a lot. Before getting started on what EH doesn’t do (or doesn’t do well), let’s cover that touchy subject: Scoping, feature creep, and bloat.

The scope of any program is, in a nutshell, what it does. The phrase out of scope generally refers to a feature that the program does not and may never cover.

A good example is Notepad++. I swear by it. When I’m using Linux instead of Windows, I find myself missing it dearly. However, I would never expect NPP to be a full-featured rich text editor and the thought of it handling presentations and blogging is simply laughable. Those features are simply out of NPP’s scope and I wouldn’t want them there in the first place.

Feature creep is a situation that programmers everywhere deal with on a continual basis. Users regularly request changes to a program. Some changes are simple tweaks, some are brand new features. While it’s all well and good to see a program evolve into something truly great, a line needs to be drawn at some point to keep the program easy to use and configure. EventHorizon is quite guilty of feature creep and proud to admit it, but on the same token I make every attempt to keep it from becoming bloated.

Bloat. It’s a dirty word in the programming world, referring to the point at which too many features are present in a single program. A bloated program is too big for its own good – It’s reached a level of complexity that can, at times, render it completely useless. You’ve run into this before, and its name is Windows. In WoW, it’s known as Carbonite or Pitbull.

Bloat isn’t necessarily a bad thing. A program with too few features can be just as large a liability as the insanely bloated program beside it. Sometimes that bloated program is the only available means of doing something, or is the only holder of a key feature that enables a personal godmode in everything you do with it.

Carbonite is an excellent addon in many regards, but most people download it simply for its questing features. It’s bloated beyond belief though, extending its features far beyond that of a quest helper. It modifies your social and guild windows, it tracks everything you do in combat whether you like it or not – It’s bloated.

Pitbull is bloated in a completely different manner. While it restrains itself to only changing your unitframes, it has far too many options for its own good. This is excellent for a user that can never seem to find the perfect unitframe layout, but all those options take a heavy toll on its performance. Last I checked, Pitbull used more CPU and memory than all of my other addons combined. And this was with every feature I didn’t use completely deactivated or deleted.

I certainly hope this section has helped someone, because next we turn to how it all affects EventHorizon.

EventHorizon: What It Doesn’t Do

EH is a unique addon however you look at it. Even the name is unique, as you don’t see very many addons make a reference to general relativity. As I’ve shown in my previous article, EH is a combat monitor that tracks time itself, giving an entirely different view on your abilities.

Large strides have been made in turning EH into what it is today. New features turn up with almost every release, making it easier to see what’s going on and providing even more information about your spells.

Lines must be drawn for everyone’s sake though. EventHorizon does not and likely will never…

Tell you what to cast. For one, this is self-evident with many specs when you’re looking at EH’s little window. The goal is to have as many full bars as possible with as few gaps in between as possible. Aside from that, there are other addons that have been written for this exact purpose. Hi, Faceroller. Adding this functionality to EH would involve hundreds of lines of code that would only be useful for a specific minority.

Have clickable buttons. To an addon author, this may be obvious. Secure templates are a bitch to deal with, and EventHorizon’s fluid nature clashes with them badly. I’ll leave it at that – It’s much more pain than it will ever be worth, trust me. Many action bar addons have the ability to create a bar that matches EH’s window nearly perfectly, and they do the job much, much better.

Track long cooldowns. EH has one goal: Watch everything that affects your standard rotation. Hi, Shamans. Elemental Mastery does not affect your rotation, you continue with the same spells whether or not it’s used.
However, events are in motion that will eventually allow for a second EH window containing those long situational cooldowns.

Show your mana, rage, energy, runes, etc. EventHorizon_Vitals does this quite well and was made exactly for this purpose. EH will never track your power levels on its own, you have unitframes and Vitals for that.

Have ingame configuration options. Ingame configs are nice, I won’t deny it. However, once you have it to your liking, EH is an extremely low maintenance addon. A config window would not only multiply EH’s CPU and memory usage, but would also make sharing configurations much more complex.
Wimpface is working on a minimal in-game config window to adjust EH’s appearance in a roundabout way. I have no timeline for its release, but it’s likely to be released as an optional module when it’s ready.

Have nifty flash and pulse effects. This has been attempted and has been found to be extremely distracting. The effects may be added in the future as an optional module, but at present I have no plans to write it.

Show Totems. Sorry to pick on all the Shammies around, but EH will never track totems. Yes, it’s possible. No, it’s definitely not easy. You’re much better off using a dedicated totem management addon or Blizzard’s provided utilities.

Track pet cooldowns. Apologies to Hunters and Warlocks, but there are no plans to support tracking abilities used by pets. Abilities affecting pets are another matter of course. EH can track literally any buff or debuff as long as you have the spellID for it. I’ll cover some tricks on this in Course 4: Customizing EH’s Bars.

I’ve received all of these as requests over the past year, and more. It’s never easy to say no to a user, and to tell the truth some of these would be very easy for me to implement. However, I always have to keep a watch out for bloat – If I’m adding something to EventHorizon’s core, I need to make sure it’s something everyone can use equally. And then, I need to make sure that there isn’t another addon or solution that negates the purpose.

Staying in scope: EH watches everything that affects your rotation on a constant basis, no more, no less.

Keeping feature creep to a minimum: EH uses less CPU and far less memory than many other (far less useful) DPS addons. It could very easily use more, but what’s the point of an addon if it forces your computer to a grinding halt? What’s the point of a simple Lua-based config if there are too many options to possibly keep track of? How many bars do you really need to effectively kill something?

Steering clear of bloat: EH does its singular job very, very well. It will never choose your abilities for you, it will never openly suggest what to cast, it will never do things to any other frame but its own. It will always be accurate, it will always show the information you need – What more could anyone want?

Happy hunting!

Previous – EventHorizon Course 1: A Brief Introduction
Next – EventHorizon Course 3: Pimping EH

You can download EventHorizon here.
If you enjoy the addon, remember that donations are what keeps it alive and evolving. I no longer play the game any more than necessary for testing purposes, and cannot spare the money to keep my WoW account running for that purpose alone.

In this blog, I’ll be going over everything EH – How to use it for maximum effect, customize it beyond your wildest dreams, and even use it for things that you had no idea it could ever do.

But first…

What the heck is EventHorizon?

EH is, in short, a combat monitor. It shows casts, cooldowns, buffs, and debuffs. Rather than needing to look at 3 things at once (cast bar, cooldown monitor, and buff/debuff indicators), EH allows you to see every bit of relevant information about a spell in a single, simple bar.

Most addons use percentages to show what’s going on. This means that the following happens:

Spell #1 has a 30 second duration. When it’s first cast, its bar reads full. When it has 15 seconds remaining, the bar reads half. Easy enough.
Spell #2 has a 6 second duration. When it’s first cast, its bar reads full. When it has 3 seconds remaining, the bar reads half. Wait a second… This means that the only way to tell which will expire first if we freeze with both spells at 50% is by looking at the number of seconds remaining (if they’re even displayed) or by resuming and watching which one moves faster.

Enter EventHorizon, stage left. EH tracks time itself. All the information it shows is overlaid on a common time scale, meaning you see everything in relation to everything else. The difference is incredible:

Spell #1 has a 30 second duration. When it’s first cast, its bar ends at 30 seconds. When it has 15 seconds remaining, the bar ends at 15 seconds.
Spell #2 has a 6 second duration. When it’s first cast, its bar ends at 6 seconds. When it has 3 seconds remaining, the bar ends at, you guessed it, 3 seconds.

This needs a picture or two to really show what I mean. Here’s an example showing the essentials on a Resto Druid.

As I mentioned previously, every bit of information about a spell is relayed on a single bar. Notice that everything is neatly aligned – I have one second remaining on Lifebloom. A little under 12 seconds remain on my Swiftmend’s cooldown. Rejuvenation still has about 6 seconds (two ticks) remaining. I just finished casting Nourish.

Wow. That was easy.

Let’s take it by the numbers.

1. Past: EH shows casts, expired spells and cooldowns, and ticks that have already happened here. The default is 3 seconds, plenty of time for most anyone. I use one second, personally.

2. Present: Otherwise known as the “Now Line”, the current point in time. An EH newbie will stare here – Anyone who is used to EH, though, looks at…

3. Future: What will happen. Contained here is the core of EventHorizon – Everything in relation to everything. Predicted spell ticks, cooldowns, buff and debuff durations, you name it. If you’ve ever had trouble deciding what to cast and when, read on. The default is 12 seconds from now.

4. Skill Icons: A simple show of what the bar is tracking.

5. Stack Count: Overlaid on the icon is a traditional stack counter. It shows – surprise – how many stacks of the spell are currently active.

6. Duration: The time left on a buff or debuff. EH directly watches your spells, so this will always be accurate to the millisecond. If a spell is dispelled or the target dies, the bar goes poof. If a spell is extended or refreshed (even via another spell) the bar will do likewise.

7. Tick Markers: Any DoT or HoT spell may have its ticks predicted in an easily readable fashion. EH tries its best to keep these predicted ticks accurate, catching when a tick happens and doing a little math to make sure the others line up. When Patch 3.3 hits, it will even track the effects of haste to make sure you have the most accurate possible information.

8. Cast Timers: EH keeps track of everything related to a spell, including its cast time. Again, this uses actual game information – Casting times use the game’s API to make sure they’re accurate.

9. The Recast Line: Another unique feature of EH is that it lets you know the best time to refresh an aura that has a casting time. The last known cast time of the spell is remembered and subtracted from the bulk of the bar, letting you keep a spell’s uptime near 100%.

10. Cooldowns: A good combat monitor isn’t complete without good cooldown tracking. Again, the game’s API is used to provide the most accurate information. In addition, if an effect’s cooldown isn’t provided by the game (How’s that Grim Toll looking?) EH will do a pretty good job of tracking it anyway.

Not shown in the shot:
Supports every class and spec out of the .zip: EH has been custom-tailored over the past year to let you use it on both your Survival Hunter and Disc Priest without skipping a beat. It does this by watching your class, spec, and glyphs – No setup required.
Global Cooldown: A line, not unlike the Now Line, that moves with your GCD. Unobtrusive and natural are the names of the game.
Channeled Spells: EH tracks channeled spells quite accurately – Including tick markers. Warlocks, Drain Soul was never this easy to use.
Internal Cooldowns: Yep, EH tracks those too. The hidden cooldowns on trinkets and certain talents/spells can be tracked accurately.
Glyph Refreshes: A very unique example of how EH helps in every possible way. If you’re using certain glyphs (Backstab [Rogue/Rupture], Shred [Druid/Rake], Starfire [Druid/Moonfire], etc) EH will show the remaining number of glyph-based extensions a spell has remaining via the stack counter. This information is always accurate, even when you’re switching targets constantly.
Unique Buffs and Debuffs: If a spell is unique per target and you happen to use it as part of your rotation (Feral Druids, I’m looking at you and your designated Mangle/Trauma bots), EH will show a faded bar letting you know when someone else has supplied it already.
Related Spells and Secondary Effects: Not every spell has its own buff or debuff. For example, Nourish in the example above also tracks Nature’s Grace. A Holy Priest’s Lesser Heal tracks Inspiration (and Ancestral Fortitude), while Disc gets Grace tracked via Penance.
EventHorizon_Vitals: Vitals is a little plugin for EventHorizon that tracks some other useful information next to EH’s frame. It shows your current power (mana, rage, energy, vehicle power, what have ye), weapon enchant durations, combo points, runes, and a few other niceties. Vitals isn’t bundled with EH itself because it is not universally useful, but is definitely worth checking out.
Endless Customization: EH has no in-game configuration, and for very good reason – If it were offered, it wouldn’t be anywhere near as flexible as it is now. It would also be nearly impossible to set up… and if you’ve never lost your settings because of a nasty crash or game-breaking bug, you’ll thank me later. Settings can be handled via a simple configuration file contained in the EventHorizon directory, and trust me when I say there are quite a few to tweak at your leisure. The defaults are quite satisfactory for most anyone if you dislike dealing with text.

Update 11/06/09: Here’s another shot, from Wimpface.

Wimpface's EH setup. Shows off all the major elements, and a lovely color scheme and layout to go along with it.

That’s all for now. Stay tuned for the next episode of Taroven’s EventHorizon insights.

Next – EventHorizon Course 2: What EH Is Not

You can download EventHorizon here.
If you enjoy the addon, remember that donations are what keeps it alive and evolving. I no longer play the game any more than necessary for testing purposes, and cannot spare the money to keep my WoW account running for that purpose alone.

As you can probably tell, the site is still under construction, so bear with us while we get everything set up and situated.

Also, if you’re interested in contributing to the site, find me on Twitter or shoot me an E-mail!

Obviously, I’m looking for any and all types of spellcasters.  That includes the following:

• Warlocks (All specs)
• Mages (All Specs)
• Elemental Shamans
• Balance Druids
• Shadow Priests 

No previous blogging experience is required!