Get an Epic Experience with Premium


Buffs & Debuffs Login to Add Favorites
  • World of Warcraft
  • 23 Monthly Downloads
  • Supports: 4.0.3a
  • 4,375 Total Downloads
  • Updated 12/25/2010
  • Created 05/11/2010
  • 22 Favorites
  • Project Site
  • Comments
  • Release Type: Inactive
  • License: GNU General Public License version 3 (GPLv3)
  • Newest File: v1.7.1
Support development! **

About AuraAlarm

AuraAlarm alerts you to buffs and debuffs by playing sounds or flashing the background a certain color. Also an icon of the buff is shown. It has two modes of operation: normal mode and light mode. Normal mode has more features.

To deal with this there are Sets, and you can change into a set through a slashcommand/macro (/auraalarm getset Default). For each set you can specify a target's name. This way you can switch into a Lich King set simply by targeting LK himself.

One of normal mode's features is collision handling. To deal with two or more alarms intersecting, the alarms' individual colors are alpha blended together. You can also prioritize alarms so that when two or more alarms intersect only the important alarm's color shows up. To set up priorities you use layers and the alarm's alpha value. By setting a layer 1 alarm red and fully opaque and a layer 2 alarm that is blue, you have caused the layer 1 alarm to cover up entirely the second layer alarm. The background is entirely red, no matter how many alarms are on layer 2 or deeper.

Normal mode's biggest difference is that it will catch every buff and debuff. Light mode may miss auras that never show up in the combat log, such as Lich King's necrotic plague. Also it doesn't have collision behavior, so if one alarm interrupts another, the behavior is undefined.

When you want alerted to a stackable buff, but don't care what stack it is, use 0 for the stack parameter. Also use 0 for non-stacking auras.

Note that when copying one alarm's properties, only these attributes are shared: color, mode, soundFile, soundPersist, soundRate, showIcon, and layer.

If you would like to help with translations, please head on over to:

r193 | starlon | 2010-12-25 22:41:56 +0000 (Sat, 25 Dec 2010) | 1 line
Changed paths:
   A /tags/v1.7.1 (from /trunk:192)

Tagging as v1.7.1
r192 | starlon | 2010-12-25 22:41:07 +0000 (Sat, 25 Dec 2010) | 1 line
Changed paths:
   M /trunk/AuraAlarm.lua

Bug fix


First Previous Page 1 of 2 Next Last
  • #16
    First of all, great addon!

    3 Things I have problems with:

    When I change the opacity of the color of the screenflash it seems not to have any effect. But I would prefer to customize that because in the current state it takes away slightly to much vision when it appears.

    Then the SpellID entry seems not to work. For example "Tricks of the Trade" If I use this by the name only I get a alert whenever I tricks someone and same if someone does it on me. It would be nice if I could enter only the spell ID so i get different alerts for both events. But this is not working atm. Or I cant get it to work.

    When I change profiles, I need to do a /reload ui or it wont be recognized.
  • #15
    Pure awesomeness! Now im never gona miss crucial debuff. Thanks!
  • #12
    After a few very busy weeks (job-wise), I finally got the time to put the the improved normal mode to the test. With 174 alarms and a refresh-rate of 1 ms (latter was unintentional) I threw myself in a battleground as a stress-test. As far as I can tell, I suffered no noticeable decrease in game-performance and all alarms where triggered instantly.

    I tried different refresh-rates with a character with only 2 alarms and to delays or fade-time set in the options. 100 ms is too slow, causing delays of up to a third of a second before an alarm is triggered.
    With 10-30 ms, the alarms are triggered in a timely manner, although the difference to a 1 ms setting is still noticeable in direct comparison.

    However, I noticed quite a few strange things/problems with layers and collision-handling.

    If I understand the concept correctly, alarms of layer 1 have higher priority then alarms of layer 2+. I a layer1-alarm is active, no alarms of layers 2+ can become active. Not until all layer1-alarms are inactive, alarms of layers 2+ can even be triggered.

    I tested this with only 2 alarms. One in layer 1 and the other one in layer 2.

    I noticed the following things, that strike me as strange or buggy:
    1) When an alarm1 (layer 1) is currently active, the sound of an alarm2 (layer 2) is still played and the icon is shown, although an alarm of layer 1 is currently shown. It seems that more alarms are checked than necessary.
    2) Recasting a buff re-triggers an alarm with persistent mode. This causes the screen-colouring to briefly disappear and reappear and also plays the sound.
    3) Having an layer2-alarm first (in the list of alarms), then a layer1-alarm causes the layer-collision-handling to fail. The colours of the alarms mix, although they have different layers. If I reverse the order (Layer1-alarm first, then Layer2-alarm second), the colours correctly no longer mix. Probably some issue of checking the alarms not in order of their layer.
    4) When an alarm ends, it always briefly removes all colours instead of only it's own colour.
    5) In the options you can/must state the number of layers. If you set it too low, then the screen colouring just becomes dark (ignoring colours) for alarms of too high layers, but sound and icon are still shown. Also you can set it to 0 or negative numbers as you can do with alarms, but causes screen colouring to fail. I don't see what this setting does for the user. The addon can surely determine the highest used layer on it's own at the time a layer is changed.

    I would kindly request a minimap-button for this addon. Testing without a fast way to open the addon-GUI has proven to be a quite a hassle.

    A way to move alarms in the list of alarms would also be greatly appreciated. Having alarms for similar auras in the same aura together would make managing them easier.

    If you remember, I suggested some sort of categories for similar alarms. Maybe I thought a lot too complex. To a allow one alarm to contain multiple buff-names/spell-ids would do the same and maybe even improve performance. Food for thought.
  • #14
    Oh and I'll look into allowing you to change alarm ordering. Shouldn't be too hard.
  • #13
    Layering priority only effects alpha blending the background. That could possibly change, but I've become busy lately, and school's about to start, so it may have to wait for a while.

    I'll have to look into number 3.

    As far as the reflash when an alarm finishes, that's because the algorithm refreshes all alarms when one finishes, so they can sort of start over their values. This way finishing alarms don't leave other alarms dangling so to speak.

    I'm not sure about # 5. I'll look into this.
  • #10
    Is it just me or the individual transparency(alpha) settings for each aura do not work instead it applies the general one for everyone?
  • #11
    That's correct. The individual alpha value is only used in alpha blending. The main purpose of this value is to prioritize an alarm, so only that one shows when two or more are active, i.e. alarm 1 is on layer 1 and is fully opaque -- it would cover up any alarms on deeper layers. This value can also effect the background's color a bit when two or more alarms are active. The alpha value of the color key under AuraAlarm's global settings effects the actual transparency of the background.
  • #9
    I finally configured AuraAlarm for all debuffs relevant to me in PvP, dungeons and raids and ended up with about 140 alarms. Most of them are PvP-relevant and thus cannot be distributed amongst sets. The copy-feature helped a lot there. A feature to move a specific aura up or down in the list of alarms would have tremendoulsy helped to arrange the alarms in groups.

    To my dismay, i now have delays for showing and hiding triggered alarms in determined mode of up to 5 seconds. This pretty much makes the alarms worthless. I have set the delay to show/hide to 0 and the refresh-rate for determined mode set to 1. When I switch to normal mode, the alarms trigger without delay. Also when I try out a different profile with only a few alarms, the determined mode is fast again. Thus I conclude, that the large number of alarms slows things down.

    Can you look into that issure? I will have to use the light mode and would have to miss out on determined mode-features such as collision handling.
  • #8
    Screenshots please
  • #4
    The problem with the colours of different alarms not mixing was indeed a too high opacity-setting. My bad.

    I was wondering, why the addon-texts are shown in english on my german client, although the addon includes localization-files. I personally don't care about localization, but if it is bug, you might want to know.

    Thanks for the spellID-feature. That will significantly reduce false alarms. Also thanks that adding a captured aura also automatically adds the spellID. A real time-saver when configuring.

    By reducing the Determined Mode rate (in ms) to 3-4 the countdown became fluently again, but I am not sure if such a low rate will have negative impact on something. Are such concerns valid and what settings do you suggest?

    I would definitely like the option to hide the tenths of a second on all durations. To me this does not carry vital information and is more distracting than useful.

    Also what are the garbage-collector settings all about? I guess this will improve memory usage on cost of performance. How can I determine the correct settings for me? Perhaps you can elaborate this a bit.

    Specifying a debuff-type dosn't seem very useful to me, but perhaps I am missing something. I colour-code the alarms to quickly recognize what ability I could/should use to counter that. One colour that alarms of debuffs that can be removed with warriors anti-fear, one colour for alarms that can be removed with gnomish root-removal, etc. As fear, stuns, snares, etc can be physical, poison or magic, the debuff-type seems irrelevant most of the time.

    Perhaps the categories can still be somehow implemented as a slightly watered-down feature with a different approach and without coding a database. As I don't know anything about lua-language I am perhaps speculating too much, but here goes nothing...

    Maybe alarms could inherit their settings for colour, mode, sound, enabled, etc from one other alarm that can be selected for that aura. Maybe even user-created dummy-alarms created especially for that purpose. Eg: Alarm “spell lock” inherits settings from dummy-alarm “silence”. When that alarm triggers, the function that looks up what colour and sound to use, can then call the settings of the dummy-alarm.

    The look and feel of categories could be perhaps implemented by sorting the list of alarms, so that dummy-alarms and the alarms that inherit from those dummy-alarms are grouped together. Such an approach would probably not allow enhanced collision handling (muliple alarms of the same category show only the alarm with the longest duration), but still might be something to consider.

    With the spellid-Feature and some sort of category-feature (to deactivate a whole category with one click) the option to share sets with friends would become viable. I used to share the old debuffalarm.lua files with my fellow raiders, but they complained, that many of the alarms where not interesting to their classes/specs and the could not easily deactivate the alarms they didn't want. That was a real shame, as those alarms vastly improve reaction time and can make anybody a better player.

    Also, if I may be so bold, I would like to request a minimap-button that can be moved everywhere that opens the AuraAlarm-GUI.

    Could you also explain the practical use of sets? I would think, that one generic set with all alarms would be best as long as performance is not an issue (or do a lot of alarms that will never trigger eat up a lot of performance?) and there are no mix-ups of spells (the spellids should take care of that). I could perhaps see some some value of using different sets for different specs (eg. silence of you are cat-druid). Or if in combat or not. Or naturally different characters.

    Thanks again, for that wonderful addon.
  • #7
    Actually, if you wanted to help with the translations you can do so by heading over to the development site. There's a link to that up above AuraAlarm's description.
  • #6
    Oh and the reason the German localization wasn't working is the file was incomplete. That file was simply copied as-is from DebuffAlarm when I renamed it AuraAlarm. I've deleted the incomplete localization files so they don't confuse people.
  • #5
    Yeah, determined rate with make the duration more accurate. There's not much that can be done about this other than modify determined rate, which increases CPU usage, but honestly not by much. I chose a very conservative default. Personally I use a determined rate of 1.

    The reason for Sets is that the more alarms you have enabled, the slower AuraAlarm is in detecting any given aura. Determined rate helps this as well, but can only go so far.

    I might create the ability to copy from a specific alarm, which could be a compromise to your description of categories. :)

    Also, the latest update implements profiles, so you can share alarms between toons.
  • #1
    Absolutely great addon.

    If I understand correctly, then if multiple persistent alarms with the same layer are shown at the same time, the colours should be are mixed. Eg red+blue = violet.
    That doesn't seem to work. I get only the colour of the alarm that was triggered last. But personally, I am not sure, if this new colour would carry the correct information. The mixed colour could be the same as a colour of a different alarm and that would be confusing.

    If I may be so bold, I would like to request some new features.

    remaining duration
    Diminishing returns modifying the duration of a debuff make it sometimes difficult to determine the seriousness of this debuff. If AuraAlarm would show the remaining duration in seconds on the icon, it would be easier to make the right choice to either use a counter-ability or not. A 2 second stun might not valid the use of the PvP-trinket, a 6 second stun might.

    If I want to use AuraAlarm for PvP, you have to create a lot of alarms. It would be great, if the user can create categories (eg. stuns, silences, fears, AoE-zones) and move alarms in one of those categories. The individual alarms then could inherit colour, sound, mode and layer from their category. This would make it a lot faster to create and change similar alarms. It would also be useful, that a category has a option, that multiple alarms of this category show only the icon of the one alarm with the longest remaining duration. This would help to reduce then number of redundant icons shown.

    support of Blizzard spellIDs
    Sometimes the spellname is not sufficient to find exactly the spell you want for your alarm and using the spellname will give you “false” alarms. This is especially true for german clients where eg. some stuns share the same name with harmless debuffs.
  • #3
    Durations now show.

    You can now specify the aura's ID. Note that this will override the name, so you can name the alarm whatever you want once you've provided an ID. This should help organize two or more auras with the same name, e.g. Stun1 and Stun2

    As for categories, the best thing I can do is allow one to specify what debuff type, such as magic, disease, poison, or curse. Going any further than this would require keeping a local database of all known auras, and I'm not going down that road.
  • To post a comment, please login or register a new account.
Login to Curse

Don't have an account? Create One.

Get an epic experience with Curse Premium
  • Faster addon downloads
  • Premium-Only Beta Giveaways
  • Ad-Free Curse experience
  • Premium Curse Client
  • and many More Features
  • Learn More »

Leaguepedia PAX Skin Giveaway