Cataclysm Fire Mage Compendium - Page 16

Tyrian · 01/28/11, 2:58 PM

Ignite Munching has long been an important topic for Fire. Many Mages have heard of the term over the years, but it's probably still not fully understood by as many as it should be.

With the latest SimC updates again reminding us just how influential Ignite Munching can be - the OP now has a dedicated section which will explain and discuss several key questions: What is Ignite Munching? Why does it happen? How can it happen? Thanks to mysteltainn - who kindly agreed to write this conclusive summary - which can be found now in the OP and below. If there are errors, mistakes, or items you recommend should be added - please mention them. I want this section to be the authoritative resource to refer to when people want to learn about - or talk about - Ignite Munching: What exactly is it? Why does it happen? How can it happen?

People will soon start to read/learn that "SimC has implemented support for Ignite Munching". People will notice that surprisingly large shifts might occur with how Crit is valued. A better understanding of Ignite Munching itself will help alleviate some of the confusion that follows when interpreting these results.

The oft-referred to "ignite munching" is a phenomenon that results in less (or in rare cases, more) ignite damage than would be otherwise predicted. There are three reasons for its occurance: simultaneous criticals, criticals that occur shortly before an ignite tick, and criticals that occur when the ignite debuff's remaining duration is greater than four seconds. The two former causes are caused by old, nigh-unfixable limitations within the game engine, and the latter is to do with a recent change in how DoT effects are refreshed.

As the name states, simultaneous criticals is when two spells crit simultaneously on a given target - usually, these times are logged as the same to a thousanth of a second. Most commonly, the spells responsible are either a fireball with a queued hot streak, or a scorch with a queued fire blast. The result is that only the second logged spell's damage being considered for ignite - the first spell's damage is completely ignored with respect to ignite. In a log, this might look like:

[00:16.414] Spell Crit #1 on Target
[00:16.414] Spell Crit #2 on Target

Here, ignite would be calculated only considering Spell Crit #2's damage.

An obvious solution would be to prefer against queuing spells with identical travel times, but since a fire mage's myriad of DoTs can crit, it will still happen. Indeed, with relatively low crit rates (compared to late-WotLK where this munching was the majority of lost ignite damage) this is not as prominent as it was - but it is still a hefty chunk of damage lost.

As long as simultaneous events are problematic in the game as a whole, this type of munching will always occur. However, it could be alleviated by changing the travel time on certain spells - if pyroblast was slightly slower or faster than a fireball, for example.

The next cause of munching is based on ignite's 'talent delay' - a small delay between a given spell critical and the actual ignite application. In a log, ignite applying might look something like this:

[00:23.409] Spell Crit on Target
[00:24.158] Ignite Refreshed on Target

The time between the actual crit and the ignite applying is the server verifying that, yes, your character has the talent necessary before actually applying the debuff. Proc-based talents from all classes suffer this ~0.5s delay. This delay isn't a huge problem for other class-based procs, but strange things with ignite happen with certain sequences of events:

[00:13.872] Spell Crit on Target
[00:14.381] Ignite Tick
[00:14.461] Ignite refreshed on Target

In this situation, the Ignite Tick is a 'free' tick - since it falls between a valid crit refreshing the ignite (verifying that the mage has the ignite talent and then calculating its damage pool) and the actual refresh event, the damage it deals isn't subtracted from the total - or, more accurately, the total is 'rolled back' to when the crit occured.

There is a rarer variation of this where the following happens:

[00:30.064] Spell Crit #1 on Target
[00:30.097] Spell Crit #2 on Target
[00:30.512] Ignite refreshed on Target (from Spell Crit #1)
[00:30.902] Ignite Tick
[00:30.902] Ignite refreshed on Target (from Spell Crit #2)

The difference in this situation is that there's a crit and refresh sandwiching the crit in the last example. The result is that the Ignite Tick does damage as calculated considering Spell Crit #1 - then 'rolls back' the total to before either crit occured, and adds Spell Crit #2 instead.

Both of these scenarios are unavoidable, especially with DoTs ticking. I believe the first bug adds a non-trivial amount of damage, but I can't say much for the second - it is quite rare, and a favorable outcome when the alternative would be the next type of munching.

The last type of munching is a side-effect of the new Cataclysm DoT system.

Ignite extends past four seconds because of the new DoT refresh mechanic. This mechanic is present on other player-cast DoTs like living bomb and corruption, and was implemented to make clipping the DoT impossible. For example, if, before 4.0.1, if you were to refresh living bomb right before it was about to tick, perhaps at 3.1s, living bomb would refresh to 12s, and would tick 3s later at 9s - the time between those two ticks was effectively 5.9s; after 4.0.1, the duration of living bomb would refresh to 12.1s, tick at 12s, and continue to tick as normal.

Following this new system, ignite's behavior is as follows:
- Ignite's initial application will be 4s in duration: 2 ticks, one at 2s, one at 0s. Ignite's total damage pool is divided between these two ticks.
- Any refreshes at any time will refresh ignite to 6s in (max) duration (current duration is ignite's current duration mod 2 plus 4s): 3 ticks, one at 4s, one at 2s, one at 0s. Ignite's damage pool is divided evenly between these three ticks.
- Ignite must be below 4s in current duration to accept any new refresh events.

To Illustrate:

[00:54.436] Spell Crit #1 on Target
[00:54.819] Ignite Refreshed on Target
[00:55.163] Spell Crit #2 on Target
[00:56.354] Ignite Tick on Target

Spell Crit #2 is munched in this situation.

This means that ignite will, on average, accept only one crit every two seconds. This is the other major source of ignite munching - DoTs critting at inopportune times and multiple crits in a small time-frame.

It is possible to diminish this effect by attempting to space spells out, but DoTs will make this form of munching inevitable.

This 'limitation,' while seemingly arbitrary, is more about how ignite evenly splits its damage between its ticks and how the new system requires a DoT tick every period without interruption. To further refresh ignite would require that either the duration be set to 6s or the duration to arbitrarily lengthen as crits occured.

Two possible solutions might be to only add the new damage to ignite without affecting its duration when the current duration is over 4s, or to have its ticks not spread evenly, but each one representing only crits that happened in the past four seconds. As most other systematic problems in WoW, I'm keen to believe this is either old and hard-to-update, or not a high priority (or more likely, both).

There is one final anomaly. When spells simultaneously crit on a target without ignite present:

[00:16.414] Spell Crit #1 on Target
[00:16.414] Spell Crit #2 on Target
[00:16.938] Ignite #1 Applied to Target
[00:16.938] Ignite #2 Applied to Target

The resulting ignite, as expected, only considers Spell Crit #2. However, because of the simultaneous ignite application events, it ticks as hard as a 4s ignite would (damage pool/2) over 6s - an extra tick - 50% more damage than expected.

Do note that this is still a damage loss so long as Spell Crit #1 is more than 50% of Spell Crit #2.

nagrad · 01/28/11, 3:55 PM

This is some very useful info on ignite munching - it shows just how much more RNG can impact Fire's dps even beyond just the RNG of scoring two crits to get a hotstreak, especially when it all rolls into our combustion further impacting our dps. It also becomes really hard to plan for appropriate combustion use when the dot ticks proc an ignite that munches a fireball or Pyroblast! ignite just as you're trying to combust.

It would certainly level out and normalize mage damage if they could correct these issues (and most likely nerf damage appropriately, as Blizzard is clearly currently balancing around this bug rather than resolving it).

In the meantime... It also seems that haste is being valued much more highly than it was previously given the data on ignite munching, which is a major change, and means back to reforging.

Zaldinar · 01/28/11, 4:14 PM

Tyrian, I have rewritten my old ignite monitoring addon with Catas mechanics in mind and have yet to observe a significant overance of damage produced by the old 'hiccuping' bug you are describing (in fact, none at all unfortunately), I have only observed a significant amount of lost damage as a result of simultaneous crits and a few others.

Do you have combat log snippets showing more than the expected damage being present so I can check my conditions and see what is missing?

Valindil · 01/29/11, 7:38 AM

Originally Posted by Silverwind

The latest Simulationcraft Results now include correct ignite munching. Combined with the additional mana cost reduction on Fireball on the PTR, this results in a huge shift in stat priorities:

Intellect=3.1468
SpellDamage=2.4011
HitRating=2.2689
HasteRating=1.6104
CritRating=1.2664
MasteryRating=1.1239

Int lost some value (because Scorch weaving will no longer be necessary), and if we can trust Simcraft, Haste is now our best stat. What are your thoughts?

There seem to be some inconsistencies with your post here Silver. The simc results you linked show...

Crit = 1.2625 Haste = 1.4039 Mastery = 1.1214

... not the values you posted there. Although haste is still dominant in that parse there margin is not quite as profound.

Secondly I would like to point out that the gearset currently used by mage_fire_t11_3721_ptr pushes fireball under 2.0 seconds. Assuming ignite munching is modeled correctly this would reduce the value of crit as consecutive fireball crits would cause ignite munching on themselves. To test this I reduced the amount of haste so that fireballs would be cast in just over 2.0 seconds and ended up with these results (100,000 iterations)..

Normal Profile
Crit = 1.3089 Haste = 1.3945 Mastery = 1.1259

Reduced Haste Profile
Crit = 1.2957 Haste = 1.5772 Mastery = 1.0890

So much to my dismay crit didn't change at all in its value which didn't seem to make sense but haste jumped right up. The haste jump can be explained somewhat by the crossing of the haste breakpoints which resulted in a very skewed haste value due to the way simc calculates state values.

It would be interesting to see if someone can re-do my test but instead of reducing haste sub out one of the teir pieces so it doesn't have the reduced cast time for fireball. This would keep fireballs slightly above 2.0 seconds without blowing haste way out of proportion due to crossing the breakpoints.

The reason I'm so interested in this is because if fireball has a slightly higher cast time than the ignite "deadzone" not only would consecutive fireball crits have more chance to apply their ignite, but if the ignite buff is every refreshed by fireball during a fight, a consecutive fireball would have a very high chance of applying its crit to the ignite bank because it should land only a fraction of a second after the ignite duration has fallen sub 4 seconds. Casting chain fireballs with this phenomena with high crit would not only help to generate big ignites for combustion but give the best chance at not munching those important fireball ignites.

This of course is just what makes sense to me right now, maybe in reality it wouldn't make much of a difference especially to overcome a 10% haste gain from the tier bonus. I'll see if I can remove the bonus but I'm pretty noob at simc

EDIT:

I managed to turn off the T114Pc bonus and ended up with:
Haste = 1.3605, Crit = 1.2985, Mastery = 1.1433 ~ 23964dps
T114Pc on:
Haste = 1.3896, Crit = 1.3338, Mastery = 1.1017 ~ 23960dps (actually did less dps :/ )

Conclusion

So pretty much trying to manipulate haste in order to get good ignites is pretty pointless, it doesn't seem to make your crit any more valuable (or at least not enough to warrant dropping the tier bonus) and haste still trumps it slightly. Also on that note our 4pc bonus is only worth about 100dps, pretty shit by any standards.

Pent · 01/29/11, 1:49 PM

Originally Posted by Valindil

EDIT:

I managed to turn off the T114Pc bonus and ended up with:
Haste = 1.3605, Crit = 1.2985, Mastery = 1.1433 ~ 23964dps
T114Pc on:
Haste = 1.3896, Crit = 1.3338, Mastery = 1.1017 ~ 23960dps (actually did less dps :/ )

Conclusion

So pretty much trying to manipulate haste in order to get good ignites is pretty pointless, it doesn't seem to make your crit any more valuable (or at least not enough to warrant dropping the tier bonus) and haste still trumps it slightly. Also on that note our 4pc bonus is only worth about 100dps, pretty shit by any standards.

Well I don't have 4t11 myself yet, and turning it on in simc (tier11_4pc_caster=1, that's the one right?) boosts me from 17.8k to 18.4k. Something I didn't understand though, was that the set bonus devalued haste by a large amount.

4 set off:
crit = 0.8781, haste = 1.2030, mastery = 0.7157
4 set on:
crit = 0.9068, haste = 0.7991, mastery = 0.8086

Why does haste drop that much suddenly? I'm currently just over the softcap at 527 rating. I'd expect haste to get slightly lower with the set bonus considering more haste means the bonus will remove less casting time, but not that much?

edit: Now I'm really puzzled, it seems to be the other way around if I take the default 359 Fire template, and turn the 4 set off...

Tyrian · 01/29/11, 3:22 PM

Edit - Zaldinar, that section was entirely written by mysteltainn. A link to his profile is several posts up, he should be able to better answer or address your question.

The Haste section was rewritten and expanded, given the increasing recent exposure (and perhaps importance) of Haste. The goal with my OP writing style is not to simply throw numbers and concepts at people and say, "You need X of Y rating to achieve Z".

The goal is to provide tools for a wide range of readers - who might not fully understand the finer aspects of Mage Gearing and Mechanics - to educate the community at large, and raise the collective standard of understanding and play from the community.

Many generous, gifted players in their respective areas contribute to make these compilations possible. I'm excited to note that this "Cataclysm Fire Mage Compendium" is on track to reach 1 million views soon, and the previous "Fire updated for OP" thread itself already had nearly 700k views.

(I've still been getting occasionaly PM's ingame asking me, "Why don't the Haste values stipulated add up to 12.5%?"). Not enough Mages in the community have a strong enough grasp on Haste mechanics - similar to Ignite Munching - and the Fire Compendium can be used to help change that, for the benefit of the community at large.

The updated section is below. If there any errors, or glaring omissions that should be included, please PM me.

--

Thanks to Roywyn for writing much of the section below.

Many Spell DOT's gain additional ticks at specific levels of Haste. For Fire Mages, the levels of Haste required are:

Spell	+1 Tick	+2 Tick	+3 Tick	+4 Tick	Notes
Living Bomb	12.5%	37.5%	62.5%	87.5%
Pyroblast (Dot)	12.5%	37.5%	62.5%	87.5%
Frostfire Bolt (Dot from Glyph)	12.5%	37.5%	62.5%	87.5%
Combustion	5%	15%	25%	35%
Ignite					Ignite does not gain any additional ticks from Haste

DoT spells get their first extra tick when you have an amount of haste that would theoretically grant you only half an extra tick. For every extra tick after the first, you need the additional amount of haste which would grant you an extra DoT tick. As an example: Living Bomb and Pyroblast each tick 4 times. That means they require 12.5% for their first additional tick. For the 2nd, 3rd and 4th additional ticks they require: 37.5%, 62.5% and 87.5% haste respectively.

The first additional tick of Living Bomb, Pyroblast (Dot) and Frostfire Bolt (Dot) requires 516 Haste Rating. This is ~4.022% from gear. You might be thinking, "You just said we need 12.5% Raid Buffed. So why do we only need ~4.022% from gear?" The answer is two-fold:

1: Haste Raid Buffs and Haste Talents: During raids, you'll have 5% extra haste from any caster hybrid and 3% haste from the Netherwind Presence talent.

2: Haste is Multiplicative: You might be thinking, "The numbers don't add up. If you need 12.5% Haste Raid Buffed for an additional tick - why isn't the calculation simply 5% from Raid Buffs + 3% from Talents + 4.5% from Gear = 12.5% Raid Buffed?" The answer is: You cant simply add Haste together liks this, because Haste is not additive. This is how the value for Haste Required from Gear is derived:

Haste is is multiplicative. To solve for how much Haste Rating is needed from Gear to reach 12.5% Raid Buffed:

1.03 (Netherwind Presence Talent) x 1.05 (Hybrid Haste Raid Buff) x 1.xx (Haste Required from Gear) = 1.125

Gear = 1.040221914008322

1% Haste = 128.057 Rating required

4.0221914008322 x 128.057 = 515.06976 or 516 rating required

Due to Haste being multiplicative, we only need ~4.022% from gear, not 4.5% (such as if it were additive).

The table below displays the Haste values required for additional ticks of Living Bomb, Frostfire Bolt (Glyphed) and Pyroblast (Dot) in a variety of Scenarios:

LB, Pyro, FFB Dot	Notes
Additional Ticks	+1 Tick	+2 Ticks	+3 Ticks	+ 4 Ticks	Notes:
Default Haste %	12.5%	37.5%	62.5%	87.5%	NP = Netherwind Presence (3/3)
+Nothing	1601 Haste	4802 Haste	8004 Haste	11205 Haste	Troll BS = Troll Berseking Racial
+NP	1181 Haste	4289 Haste	7397 Haste	10506 Haste	Goblin = Goblin 1% Haste Racial
+NP + Raid	516 Haste	3476 Haste	6436 Haste	9396 Haste	Raid = Standard 5% Haste Buff
+NP + Raid + Heroism	-	-	1996 Haste	4283 Haste	Heroism = Heroism / Timewarp / Bloodlust

+Goblin	1458 Haste	4628 Haste	7798 Haste	10967 Haste
+Goblin + NP	1043 Haste	4120 Haste	7197 Haste	10275 Haste
+Goblin + NP + Raid	383 Haste	3314 Haste	6245 Haste	9176 Haste
+Goblin + NP + Heroism	-	-	1849 Haste	4103 Haste

+Troll BS	-	1867 Haste	4535 Haste	7203 Haste
+Troll BS + NP	-	1440 Haste	4030 Haste	6620 Haste
+Troll BS + NP + Raid	-	762 Haste	3229 Haste	5695 Haste
+Troll BS + NP + Raid + Heroism	-	-	-	1425 Haste

The table below displays the Haste values required for additional ticks of Combustion using the most common scenario only:

Combustion	+1 tick	+2 tick	+3 tick	+4 tick
+3/3 Netherwind Presence and 5% Raid Buff	-	812	1996	3180

The "Soft Haste Cap" is a term thrown around often that Fire Mages should be aware of. The "Soft Haste Cap" most commonly refers to the value of Haste required to reach +12.5% Haste raid buffed in the most common scenario: With 3/3 Netherwind Presence and the 5% Raid Haste Buff. This value is 516.

Reaching the soft-haste cap breakpoint will result in a DPS increase. The value of haste before and after the breakpoint is very similar. It's just the breakpoint itself that gives an extra value.

---

The "Mana Management" section will soon need an overhaul. I think it will be wise to keep the actual text there though, as the concepts of Weaving and Control/Management still may apply during several situations:

- If Evocation is interrupted
- Fights with Mana Drains
- Fights with unusually heavy AOE
- Fights that are unusually long

Although we may no longer need to Scorch Weave or pay much attention to Mana Management after the next patch, strong knowledge of Mana Mangement techniques will still reward Mages who have a good understanding of what to do in the aforementioned situations.

dedmonwakeen · 01/29/11, 5:08 PM

I would like to remind people that Simulation is not efficient at calculating scale factors (stat weights, equivalence points, whatever). It requires a large number of iterations to get trustworthy values. When reporting any analysis using SimC please include the version number and the number of iterations used.

Pent · 01/29/11, 5:52 PM

Oh right, that makes sense, well I've ran with 10k iterations this time, and found (everything run with my current gear, Pent @ Kul Tiras - Game - World of Warcraft):

Current gear, live:
Int:2.5091, SP:1.8382, Hit:1.7964, Crit:0.8824, Haste:1.1894, Mastery:0.6909

Current gear + 4T11 bonus added, live:
Int:2.7962, SP:1.9565, Hit:1.8911, Crit:0.9781, Haste:0.9472, Mastery:0.7379

Current gear, PTR:
Int:2.7011, SP:2.0129, Hit:1.8121, Crit:1.0008, Haste:1.4225, Mastery:0.8973

Current gear + 4T11, PTR:
Int:2.9818, SP:2.1352, Hit:1.9721, Crit:1.1224, Haste:0.8766, Mastery:0.9449

On live the value change in haste gets a bit less with the set, and as expected, it becomes much more valuable on the PTR with the decrease of FB's cost, but then loses a massive amount of value under the set bonus? Other stats aren't nearly as affected, is there any kind of explanation for this?

Mordot · 01/30/11, 2:49 AM

From what I have gathered from sifting through this thread, it would seem to me that the reason haste is losing so much value under the effect of 4pcT11 would be that if you have multiple fireball criticals back to back, with a cast time under two seconds, the ignites will begin to munch and there will be a significant amount of damage lost.

Edit: Valindil spoke about this in his post a little bit up the page.

Pent · 01/30/11, 12:10 PM

Well after doing some more sims, it turns out that pushing the cast time under 2 seconds doesn't really change anything. I turned off the set bonus for the default 359 gear, meaning the cast time would be 2.17 seconds, at 1363 haste rating. However, increasing the haste rating to 2177 (for 17%), lowering the cast time to 1.975 seconds only increased the value of haste rating from 0.8 to 1.0. Similar behavior occurred on the same sims with 4T11 enabled.

Other than that, I don't really understand how the stat value of haste rises as you have more haste rating. I would think it only lowers, due to the following example:
Imagine a spell with 2 second cast time, while having 5% haste. This would reduce the casting time to ~1.905 seconds. Then the haste rating is doubled, meaning 10% due to the linear scaling. The cast time becomes ~1.818 seconds. Now, the first 5% haste reduced the casting time by 0.095 seconds, while the second 5% haste only reduced the time by an additional 0.087 seconds. Why does simc still increase the weight despite the diminished amount of time gained?

Oh and all simulations were done with 10k iterations.

• ash2ash · 01/30/11, 12:40 PM

Absolute dps values for some combat ratings will increase with increased values of that stat. In the case of haste, haste rating is *VERY* roughly a function of your dps since it enables you to do most things more frequently. When you gain more haste, it increases your dps, thereby increasing the marginal value of haste.

It's more important to consider the relative dps values of stats rather than their absolute values when making gearing decisions.

Hotcooler · 01/31/11, 3:09 AM

I'd say that everything is much worse with ignite that expected.. here's a small part of log from yday. (there might be some spelling errors, it was in Russian)

23:10:46.374 Hotcooler hits Rohash with Flame Orb for 4425 Fire damage (critical)
23:10:46.689 Hotcooler hits Rohash with Living Bomb for 7832 Fire damage (critical)
23:10:47.164 Hotcooler hits Rohash with Fireball for 31039 Fire damage (critical)
23:10:47.176 Rohash gains Ignite from Hotcooler
23:10:47.199 Hotcooler hits Rohash with Flame Orb for 2175 Fire damage
23:10:47.199 Hotcooler gains Impact from Hotcooler
23:10:47.608 Hotcooler gains 21 Mana from Hotcooler through Master of Elements
23:10:47.898 Hotcooler starts to cast Fireball
23:10:47.978 Hotcooler gains 627 Mana from Hotcooler through Master of Elements
23:10:47.978 Hotcooler hits Rohash with Flame Orb for 4437 Fire damage (critical)
23:10:49.011 Hotcooler hits Rohash with Fireball for 30540 Fire damage (critical)
23:10:49.180 Hotcooler gains 21 Mana from Hotcooler through Master of Elements
23:10:49.214 Hotcooler hits Rohash with Flame Orb for 2242 Fire damage
23:10:49.226 Hotcooler gains Hot Streak from Hotcooler
23:10:49.226 Hotcooler gains Clearcasting from Hotcooler
23:10:49.255 Hotcooler hits Rohash with Ignite for 2086 Fire damage
23:10:49.452 Hotcooler hits Rohash with Living Bomb for 7832 Fire damage (critical)
23:10:49.452 Living Bomb from Hotcooler fades from Rohash
23:10:49.744 Clearcasting from Hotcooler fades from Hotcooler
23:10:49.744 Hotcooler starts to cast Fireball
23:10:49.986 Hotcooler gains 627 Mana from Hotcooler through Master of Elements
23:10:49.986 Hotcooler hits Rohash with Living Bomb for 3751 Fire damage
23:10:49.986 Hotcooler hits Rohash with Flame Orb for 2156 Fire damage
23:10:50.098 Berserking from Hotcooler fades from Hotcooler
23:10:50.898 Hotcooler hits Rohash with Fireball for 29747 Fire damage (critical)
23:10:51.193 Hotcooler hits Rohash with Flame Orb for 4375 Fire damage (critical)
23:10:51.237 Hotcooler hits Rohash with Ignite for 6814 Fire damage
23:10:51.642 Hotcooler successfully cast Living Bomb
23:10:51.979 Hotcooler gains 627 Mana from Hotcooler through Master of Elements
23:10:51.995 Hotcooler hits Rohash with Flame Orb for 4343 Fire damage (critical)
23:10:51.995 Rohash gains Living Bomb from Hotcooler
23:10:52.395 Hotcooler gains 21 Mana from Hotcooler through Master of Elements
23:10:52.794 Hotcooler hits Rohash with Fireball for 30335 Fire damage (critical)
23:10:52.816 Hotcooler gains Lightweave from Hotcooler
23:10:52.970 Hot Streak from Hotcooler fades from Hotcooler
23:10:52.970 Hotcooler successfully cast Pyroblast!
23:10:53.183 Hotcooler hits Rohash with Ignite for 5321 Fire damage

You can see the problem even on the first tick of ignite. It should've been at least 15K, instead it's a mesely 2K. That's a loss of ~26K of damage in 3 seconds!

Maje · 01/31/11, 5:26 AM

I found an interesting bug with Combustion yesterday, if a boss has a damage increasing debuff Living Bomb and Pyroblast! ticks that are calculated for the Combustion effect don't take it into consideration.

Eg.

[22:55:14.733] X's Ignite fades from Exposed Head of Magmaw
[22:55:14.875] X Pyroblast! Exposed Head of Magmaw 3546
[22:55:15.213] X Combustion Exposed Head of Magmaw 12670
[22:55:15.325] X Living Bomb Exposed Head of Magmaw 9366
[22:55:15.993] Exposed Head of Magmaw afflicted by Ignite from X
[22:55:16.850] X Combustion Exposed Head of Magmaw *4754*
[22:55:17.375] X Pyroblast! Exposed Head of Magmaw 3546
[22:55:17.661] X Combustion Exposed Head of Magmaw *4753*
[22:55:17.806] X Living Bomb Exposed Head of Magmaw *19247*
[22:55:18.003] X Ignite Exposed Head of Magmaw 7732
[22:55:18.515] X Combustion Exposed Head of Magmaw 2313

As you can see in the above example Ignite just faded before Combustion was applied, Living Bomb was ticking for 9366 and P! for 3546 the Combustion tick from those effects should have been around 12912/3 = 4304 instead it was ticking for 2313 which is the expected value if Exposed Head of Magmaw didn't have the permanent 100% damage debuff. I haven't checked the logs for Halfus yet but it should be bugged in the same way.

The bug is obviously due to the 'dry' calculations blizzard performs for LB and P! ie. instead of taking the last tick of each, it actually checks if the effects are on the target and then calculates (approximately) how much it should do, I'm not certain about CoE; ie. does the effect apply to Combustion damage or is it summed in the dry calculations of LB and P! ticks.

To sum it up, given the sorry state Ignite is at and due to the buggy calculations on LB and P! for Combustion's effect, the general rule of thumb of when to Combustion on shouldn't include P! dot, what I mean is that one good crit and Ignite that didn't bug plus the Living Bomb (that should be always up) is enough of a reason to use Combustion without waiting for P! dot.

In the best of conditions with good gear all you gain from P! dot is about 600 damage per tick times 10 or 6k damage per activation on the other hand the difference between a 7k and 10k ignite is 1.5k damage per tick.

talchas · 01/31/11, 11:06 AM

Originally Posted by Maje

I found an interesting bug with Combustion yesterday, if a boss has a damage increasing debuff Living Bomb and Pyroblast! ticks that are calculated for the Combustion effect don't take it into consideration.

Yeah, I'm not surprised, while I didn't explicitly check this sort of thing with the rest over here, it was clear that Pyro/LB only check for the existence of the debuff and then add a (not quite correct) base damage and coefficient to the combustion. Ignite is actually checked, and while I didn't test a 6s ignite, I would assume it would still just add tick_size/2. Note however that having both LB and pyro up seems to add about 3% extra damage to both LB and pyro's contribution to combust, although that probably is still not enough to wait on.

Muphrid · 01/31/11, 2:20 PM

Originally Posted by ash2ash

Absolute dps values for some combat ratings will increase with increased values of that stat. In the case of haste, haste rating is *VERY* roughly a function of your dps since it enables you to do most things more frequently. When you gain more haste, it increases your dps, thereby increasing the marginal value of haste.

It's more important to consider the relative dps values of stats rather than their absolute values when making gearing decisions.

Without considering the exotic effects of haste against DoTs, the absolute marginal value of haste is proportional to non-hastened DPS, isn't it? I mean, that's straightforward enough to verify for single spell spam:

$D = \frac{hq(m+rd)(1+bc)}{t/(1+z)} \implies \frac{\partial D}{\partial z} = hq(m+rd)(1+bc)/t$

D is real DPS and z is haste (the other stuff are hit, multipliers, a base damage/spellpower factor, and a crit multiplier factor). Ignoring particular funny dot mechanics and such, haste is linear, and its marginal DPS value is constant when all other stats are constant. I know there are more effects at play (the way DoTs scale down until they get enough haste for an extra half-tick), but for a very small change, this is a valid first-order approximation.