Get an Epic Experience with Premium


Mage Login to Add Favorites
  • World of Warcraft
  • 1,536 Monthly Downloads
  • Supports: 6.0.2
  • 217,766 Total Downloads
  • Updated 10/17/2014
  • Created 03/27/2011
  • 102 Favorites
  • Project Site
  • Comments
  • Release Type: Release
  • License: GNU General Public License version 3 (GPLv3)
  • Newest File: 3.6.0
Support development! **

About myBigIgnite


myBigIgnite has been designed to allow fire mages to quickly decide whether it is worth to trigger their Combustion spell.

To achieve this, the addon display is centered on the amount of damage done by Ignite and provides additional informations around. Addon colour and size is adjusted depending on whether a threshold of Ignite damage is reach and Combustion is available.
Together with this central function, myBigIgnite comes with other features such as a specific timer for Ignite as well as an automatized power bar, a entire module dedicated to providing informations about Combustion, etc.
The addon has a modular structure: every feature can be seperatly activated. It means that it can virtually fit any player preference whether a full or a minimalistic set of information is wanted.


  • Clear display of Ignite damage
  • Ignite timer bar
  • Ignite power bar
  • Combustion module
  • Heating up module
  • Statistics record
  • In game help
  • Autohiding following different conditions
  • Configurable layout that supports sharedmedia
  • Addon activation only in fire spec (and only if you're a mage)

More precisely:

Ignite damages:
Blizzard now transmits tick values through the aura of dots. This allow to fetch the value of Ignite damage even before the tick. The downside is that it is inaccurate when several spells hit the target in a short period of time: all the spells will be incorporated in the calculation for the next tick but the value transmitted by the Ignite aura changes as fast as a new spell lands on the target. To avoid too much confusion, myBigIgnite incorporate a timer that delays slightly the refreshing of damage display, so most of these fast landing spells are absorbed and never reflected in the display. You can turn off this option if you will, but the damage display will consequently be more prompt to change and inaccurate (not badly as this shoudn't lead to an overprediction of the next tick, only a downprediction). You can also keep with the former way of fetching Ignite damage by looking at the combat log, but you loose in this case the advantage of being able to see Ignite damage before the tick happens.

Ignite power bar:
A bar indicating the power of current Ignite tick. This is done by real-time computing your damages. Briefly, it calculates the average and standard deviation of your Ignite damages over a certain amount of ticks. It makes the limits of the bar flexible but still relatively stables and should help you to spot exceptionnal ticks more quickly.

Combustion module:
It is entirely dedicated to Combustion. The module pops each time Combustion is available and Ignite damages are above a threshold. It then shows a predicted amount of total damages for Combustion as well as the number of ticks. If Combustion is triggered it will show its timer, CD and tick damages. The last scrolling information corresponds to the total damage done and shows you the deviation compared to the prediction.

Heating up module:
This module shows when you get Heating up and Pyroblast! buffs. By default, Heating up icon is hidden when Inferno Blast is in CD.


Type /mbi config to access configuration tab or use the Interface button in game options. Type /mbi threshold [value] to set your optimal threshold without using the config panel.
Type /mbi help to access in game help. Type /mbi stats to access your records.


English, French

tag 3.6.0
globule <>
2014-10-18 02:03:06 +0100

- WoD compatible
- new option to show threshold as combustion tick damages


    - -removed irrelevant stuff for wod:
    smooth dmg
        show ignite tick as dps
    - changed way combu tick is calculated to reflect wod changes to Combustion
    - new option to show threashold as combu tick damage
    - help updated
    - new option to display ignite dmg number : auto
    - corrected bug to auto enable addon because of blizz removing ignite as a spell
    - toc to 60000


First Previous Page 3 of 11 Next Last
  • #133

    Instead of using a flat amount as an ignite threshold, I'd like it to be calculated dynamically, taking into account my current stats at any given time. In particular, here's the formula which SimC uses:

    Ignite tick threshold = (Fireball crit dmg + Inferno Blast crit dmg + Pyroblast hit dmg) * Mastery * 0.5

    Would it be possible to implement something like this?

  • #134


    SimC seems to simply take any value of Ignite generated by our classic fire mage combo "crit fb -> IB -> pyro" as a threshold for Ignite which is far from being optimal (or you wouldn't need to use an addon to pull nice Combustion, would you?^^).

    Implementing an automatic thresold reacting real time to changes in procs/buffs and character stats would be quite cumbersome (and still inaccurate if the damage changes occures via a debuff on the target) and would require anyway that you feed the addon with a reference threshold.

    The Ignite power bar is an attempt to dynamically reflect changes in Ignite output


  • #140

    I can see your point but let me explain mine ( and yes of course the tick strength directly depends on the spells that recently hit the target):

    I'm not saying it's not doable but it would require more work than you imagine:

    - everybody will not be happy with a one combination of spells, so I would have to offer the choice of the combination (ex: fb crit + ib + pyro crit, or whatever other combination one could like). I didn't do the maths here, but it is likely that the available combination will also be influenced by your current gcd so by haste value which can greatly vary (bl/heroism) which make the whole thing difficult to properly predict. And it's still something the player using mBI will have to decide.

    - for the base spell dmg I can probably make a database for each level (something you forget in your reasonning is that mBI works not only at 90) , tiedous work but I cannot reasonnably ask every user to enter himself the base spell dmg correspondig to his level.

    Now, imagine that we have a dynamic threshold that depends on spell sequence and changes upon spell power and crit/haste/mastery ratings (because basically you would have to take into account all of them to properly predict the expected output of your sequence). What is the point to have the addon reacting when your are in your lower range of dmg because at this time you have no proc, no fight mechanics that buffs you, etc...? That situation would happen often with such a dynamic thresold because the sequence of spells previously choosen would happen anyway (that reasonning is behind my criticism of the simC lower threshold previously mentionned). If you combust at this time, it's likely to be just a waste that you'll regret especially if you're glyphed.

    To avoid that, the only solution is to implement a static value at some point. You could say that you don't want the addon to react if your spell power is bellow a given number for instance. But in the end you need to restrict the way the addon is going to react and that can only be achieved by the user entering a number.

    Finally I don't think an addon should replace player decisions, it's only here to help you to maximise your output. What I mean here is that you should know the different phases of an encounter or when your procs or intel potion is up and plan your decisions consequently. I can give you my own exemple: at the moment I set up my threshold at 45k. Since I do not run anymore N or heroic raids, I do only lfr and I found 45k being a good base value for my level of gear. But for encounters like jin'rokh, I keep my combu for the conductive water because I know I can easily reach 100k+ for a tick of ignite in this case. A dynamic threshold wouldn't change anything here as it could be reacting once you passed 100k if standing in the buff but also once you passed 45k if not standing in the buff.

    Another problem is debuffs that increase dmg on the target (typically horridon). This cannot be solved by a dynamic threshold only based on player's stats; it would require an entire database of the possible debuffs/target couple of the game (or at the least of the current raids/dungeon with the possible difficulty level changes...). Just not doable.

    So in the end, I think the static value is the easiest and cleanest solution, for the developer and for the user. it's one number, that can be easily changed upon gear improvement or type of content. On that last point I'm planning to add a feature that will help to adapt the threshold to the type of content, though it will still require tweaking from the user. The threshold needs to be properly set up, taking into account your potential procs, etc. but I already provide tools to help people to adjust it.

    I don't know if I have been always clear or maybe I missed something in your reasonning so do not hesitate to continue the discussion here or in pm ^^

    Last edited by Istaran on 7/4/2013 4:16:21 PM
  • #138

    I think this topic is maybe worth a little more thought and consideration.

    The tick strength is not a magic random number.  It comes directly from the combination of spells that recently hit and whether they hit or crit.  These various spells are have known relationships to each other.  That's why simcraft specifies the threshold values (it uses two) in terms of the underlying spells. So, for example, it has a rule that the tick strength equal to 3 pyroblast crits should always indicate an immediate combustion, as it represents the "royal flush" -- its generally not beatable.  Similarly, the simcraft threshold cited above is its lesser priority threshold that was chosen presumably because the sim author felt that on average the cost in cooldown time wasted waiting to beat it would not justify the increased return.

    I think specifying the threshold in terms of a combination of spell results actually makes a lot more sense than specificying a static number.  For one, the static number is obsolete the second the player changes gear.  It also really should change when trinkets or other powerful buffs proc, the result of which can be substantial.  If you choose a threshold based on your unbuffed stats, you may end up throwing away a combustion on virtually nothing just because the buffed stats are so much better.

    If you feel the simcraft combustion threshold is wrong (expressed either in terms of spells or a static number), I'm sure that team would love to know what the better threshold is.  You can download the simulator and experiment with your own thresholds in just a few minutes -- its just a text change and won't take you long to figure out at all.

    If you decide to experiment with a spell-based threshold, I can promise you that implementing it is not terribly complicated, I've done it my own custom UI.  You can look at the current value of spellpower at any time through an API; you will need to define the base damage of each spell and its spell power coefficient in your code but you can get those values from Wowhead or elsewhere.

  • #132
    What number should be in my Threshold value?
  • #130

    Would really love an update for 5.2 as this addon is very good to have. So any news on when it will be updated?

    Thanks in advance.

  • #131

    Sorry, I'm very short for coding wow addons atm... Apart the wrong prediction if you're glyphed for Combustion, and small changes/minor improvements I'd like to add, the addon is pretty fine.

    Is there any particular change or new features you would like to see in myBigIgnite?

  • #128

    Any update for 5.2 comming?

  • #129

    yes but I have no time atm to code for wow. However it's on the top of my todo list so an update will eventually be released in a few days

  • #126

    The Combustion Module display a wrong number of tick if we use glyph of combustion. With the Glyph of Combustion we have at least 20 tick (with my haste i am on 23 tick), but the module predict 11 tick as i am w/o glyph of combustion.

  • #127


    indeed! The combu module needs some work anyway so I'll correct this with a future release. Until then, you know you need to multiply the prediction by roughly 2^^

    Last edited by Istaran on 2/26/2013 12:55:39 PM
  • #123

    ok Silly question, but when I loaded this addon last night it was asking me for a "Threshold" value. Where do i find that? Is it just an random number or something a little bit more scientific? I'm a noob mage so my apologies in advance.

    Last edited by Womphler on 2/12/2013 8:48:44 PM
  • #124

    That's simply a value of Ignite tick above which you want all the addon to react. As a fire mage you're fishing for big Ignites in order to trigger Combu at the right time (as Combu output is directly linked to Ignite damage). So you need to figure out first your Ignite output and then choose an appropriate number (near the maximum Ignite value you'll get in whatever usual content you run, raid, etc...). To do so, just choose a random number at the begining (say 15000) and look how the addon reacts. You can use the stat report and the power bar to help you adjusting your threshold.

  • #125

    Brilliant, thank you for the insight. Will have a dabble next time I go raiding.

  • #120

    Updated version is tossing out this error while playing as frost w/living bomb.

    56x myBigIgnite\myBigIgnite-3.2.1.lua:437: attempt to index field "spellID" (a nil value)
    myBigIgnite\myBigIgnite-3.2.1.lua:437: in function "?"
    Libs\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:147: in function <Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
    <string>:"safecall Dispatcher[1]":4: in function <string>:"safecall Dispatcher[1]":4
    <in C code>
    <string>:"safecall Dispatcher[1]":13: in function "?"
    Libs\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:92: in function "Fire"
    libs\AceEvent-3.0\AceEvent-3.0-3.lua:120: in function <libs\AceEvent-3.0\AceEvent-3.0.lua:119>

  • 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 »

Darkest Dungeon Wiki Editing Contest