Among the various bits of mechanical info that’s been revealed about Warlords is the fact DoTs and HoTs will no longer have “haste breakpoints” and will no longer “snapshot” your stats at cast time. Celestalon has mentioned this a few times on twitter and frequently responded to questions about it. Since a lot of people seem to have questions on how the math of this breakpoint-less system will work, I want to to explain some of the behavior that will result from this. First, a brief history of this whole problem.

Current System: Haste Breakpoints and Rounding

Before Cataclysm, haste generally did not affect the rate of DoT ticks. There were a few exceptions, such as the Glyph of Rapid Rejuvenation that caused the tick rate of Rejuvenation to be affected by haste. But this did so by shortening the total duration of the HoT and keeping the number of ticks constant, so it didn’t have to address the big question of DoTs and haste: what do to with the fractional ticks that appear when you do this?

When Cataclysm introduced a general mechanic whereby DoT ticks would be accelerated by haste, it handled this problem by changing the duration of the DoT, rounding it to the nearest integer number of ticks.

To work an example: say a DoT has a 12-second duration and a tick period of 3 seconds. Unhasted, when you cast the DoT, a 12-second debuff appears on the target, and the 4th tick will occur exactly as the debuff expires. If you add 25% haste, the tick period will decrease to 2.4 seconds (3/1.25). Since 5 ticks at 2.4 seconds is exactly 12, you will still get a 12-second debuff when you cast the DoT, and now it will be the 5th tick that occurs as the debuff expires. But what if you only had 20% haste? Now the tick period is 2.5 seconds (3/1.2). Since there is no system in place for handling partial ticks, the game can either give you:

• A 4-tick DoT that lasts 10 seconds, or
• A 5-tick DoT that lasts 12.5 seconds.

In fact, you get the latter. The game rounds to the closest whole number of ticks, and since in this example, the 5-tick option is closer to the default duration of 12, that’s what you get.

Finally, if you had 12.5% haste, the tick rate would be 2.667. So a 4-tick DoT would be 10.67 seconds, and a 5-tick DoT would be 13.33 seconds. These are equidistant from 12, and this is the oft-discussed “breakpoint.” At any higher amount of haste, you get 5 ticks, and at any lower amount, you get 4.

A few important results of this:

• The damage done with a single cast jumps up at the breakpoint, as you probably already understand. But hopefully this clarified why the breakpoint has to exist in the current system.
• The DoT duration went all over the place: it started at 12, then went down under 11, then up over 13, then back to 12. In fact, it follows a sawtooth pattern, as shown in the graph below.
• The tick period decreases steadily and smoothly. This does mean that if you continuously maintain a DoT, the DPS it does increases smoothly. However, the frequency with which you have to spend a GCD refreshing the DoT depends on its duration, and that behaves erratically, as discussed.

A related issue is what happens when you refresh a DoT while it’s ticking. Pre-Catalysm, you would start a fully new DoT and lose the remaining portion of the previous. Starting in Cataclysm, you get the next tick of the old DoT, and then the full duration of the new DoT. So the window to refresh a DoT with zero loss of uptime is the final tick period of each DoT. Warlocks, due to Pandemic, have a much longer window–half the length of a DoT.

Finally, since the computation of a DoT’s duration must be made at the time of cast or refresh, it has to snapshot your haste at that time. There’s no way to update the tick period on the fly when the duration is precomputed to be a whole number of ticks and there’s no system for handling a partial tick.

The Warlords System: Smooth Scaling with Haste

So the two mains goals for a revision in Warlords were:

• Eliminate haste breakpoints, because, especially with the removal of reforging, they cause a lot of gearing confusion, and
• Eliminate DoT snapshotting, which was seen as introducing too much of a skill gap in some classes, and also imposing a UI requirement.

The one new piece of tech that makes both of these possible is, as you may have guessed, partial DoT ticks. What exactly is a “partial DoT tick”?

When a DoT expires, it will do a partial tick of damage based on how much time had elapsed since the previous full tick.

So if a DoT had been ticking every 2 seconds, and it ticks with 3 seconds remaining in the duration, it will give a full tick with 1 second remaining. Then, when the debuff expires, the DoT will see that 1 second (half of a tick period) has elapsed since the previous full tick, and will give a tick of half the usual strength.

And that’s actually all. Partial ticks are simply a way of reconciling the fact that the DoT itself doesn’t necessarily end at the exact moment a tick occurs. Once there’s a way for the DoT duration to end whenever it ends, rather than ensuring it happens on a tick, there’s complete flexibility to vary DoT tick timing as needed to accomplish the goals above. To focus on one important point, even though the partial tick only happens if the DoT falls off, this does still affect you if you continuously refresh a DoT, because the initial duration of the DoT no longer changes with your haste. The example below should make this clear.

One other point to discuss before examples is how refreshing will work. When the “final tick” of a DoT will usually be a partial tick of any length, the system of requiring a refresh in the final tick period doesn’t work as well anymore. What Blizzard has suggested is that they will give everyone a mechanic like Pandemic, although at some percentage lower than 50% (possibly 30%). So your window to refresh a DoT without any loss of uptime will be 30% of the duration, regardless of the tick interval.

Examples

Basic example: with our 12-second DoT with a 3-second tick period from above. At 0 haste or 25% haste, the behavior will be the same as above (putting aside changing haste or clipping), since you already had a whole number of ticks. But at 20% haste (2.5 second tick time), the new system will become clear. When you cast the DoT, a 12-second debuff will appear on the target, ticking every 2.5 seconds, as opposed to the 12.5-second debuff you’d get in the current system. The 4th tick will happen after 10 seconds, and there will be 2 seconds remaining. If you do not refresh, then after those two seconds, the DoT will expire, doing a partial tick that is 80% as strong as a regular tick (2/2.5 = 0.8).

Example with added ticks: Now you’re under the effect of Bloodlust and some other procs, and are up to 60% haste. The number of ticks you’d expect for one cast, from a default of 4 ticks, is 4*1.6 = 6.4 ticks. So you will get 6 full ticks, exactly as under the current system, but now there will be a new partial tick at 40% strength as the DoT expires. Under the new system, haste does still add full DoT ticks, but it doesn’t add them all at once at certain points. More haste will add increasing fractions of the next tick, until it’s created a whole new tick, and then start adding fractions of the subsequent tick.

Example with refresh: Back to the initial example with 20% haste, say you refresh anytime in the last 3.6 seconds of the initial DoT (30% of the 12-second duration). Then the DoT will be extended by 12 seconds, so it will be set to expire 24 seconds after the initial cast. The 4th tick will happen at 10 seconds after initial cast as before. But now no partial tick will happen at 12s (since the DoT is not expiring), and the 5th tick will happen right on schedule at 12.5s. Ticks will continue to happen at 15, 17.5, 20, and 22.5. Then when the DoT expires at 24s, 1.5s after the previous full tick, you will get a tick worth 60% of full value.

Note what has happened in total: you’ve cast the DoT 2 times and spent 2 GCDs. The DoT was on the target for 24.0 seconds (twice the default duration). You got 9.6 ticks’ worth of damage. This is exactly right, as you cast a DoT with a default 4 ticks, twice, with 20% haste. 4*2*1.2 = 9.6.

Example with changing haste: Same example as the previous, but after 15 seconds, your haste decreases from 20% to 11.1%, increasing your tick interval from 2.5 to 2.7 seconds. So after the tick at 15 seconds, ticks will occur at 17.7, 20.4, and 23.1. When the HoT expires at the 24-second mark, it will have been 0.9s since the last full tick, so the partial tick upon expiration will be 1/3 of full strength (0.9/2.7).

Example with continuous refresh: Now, in a 300-second fight, you cast the DoT at the start, and always refresh in the Pandemic window after that. Because every cast of the DoT adds 12 seconds of duration, after you cast 25 times, it will expire exactly as the fight ends.  With 20% haste, it will tick every 2.5 seconds that entire time, giving a total of 120 ticks by the end of the fight. This is exactly what you would expect: without haste, the 3-second DoT would have ticked 100 times in the fight, so with 20% haste, it ticked 120 times.

If you point out that that’s the same thing that would happen in the current system, 120 ticks over the course of the encounter in that example, you’d be right. However, in the current system, each application of the DoT adds 12.5 seconds of duration, so you’d only have cast it 24 times to cover a 300-second fight. That oddity will no longer be present in Warlords.

Conclusion

In an ideal world with no tech limitations, one could imagine DoTs that do damage perfectly continuously. Then, there would be no issue of a DoT ending between “ticks,” and the damage could smoothly increase with any stat as desired. The best summary of the Warlords system is that it mirrors this result, but it buckets the damage into ticks. If you think of each tick as including the damage that occurred since the previous one, that explains the partial tick perfectly. When the DoT expires between ticks, the leftover amount of damage that the DoT should do is gathered together and put into one final tick. In the end, the total amount of damage done always corresponds to the amount of time the DoT was active, and the “ticks” are simply a way of delivering the damage in periodic clumps.

The end result is that the system is coherent from all angles. A DoT cast always adds a fixed amount of duration, and a DoT always does an amount of damage corresponding to the time it was active. Haste will smoothly increase the amount of damage a DoT does while active. If you focus on these things rather than on the partial tick, the system is easiest to understand. The partial tick is simply a mechanism to make sure that the final bit of damage is done correctly, and in general you shouldn’t worry about it. The most prominent change from the current system is that the duration of a DoT doesn’t change with haste.

Blizzard’s pattern of trying to make more interesting raid trinkets in MoP has provided a lot of interesting theorycraft material. As in past Theorycraft 101 posts, the goal is here both to give theorycrafters some useful conclusions and equations to save them the trouble of reinventing them independently, and to give everyone some general information that helps them evaluate these new bonuses when selecting items.

Item Budgets

In general, the amount of any stats budgeted to a certain slot scales like:

• V is the budget value controlling how many stats that item slot gets compared to other slots.
• Q is a constant equal to the 15th root of 1.15.
• I is the item’s ilvl.

Often a more convenient way to think of this, especially when dealing with trinkets, is to use ilvl 463 as a baseline. The reason is that most trinket procs are coded into the spelldata with ilvl 463 values (which is the pre-raid baseline for MoP), and then scaled from there on any individual item based on its ilvl. The Int proc on Nazgrim’s Burnished Insignia, for example, is this this spell. So in general, since looking up the ilvl 463 value for any proc/bonus on Wowhead is easy, you can think of the value at higher ilvls as:

or

This explains, for example, how the 5084 Int on the proc linked above becomes 11761 Int (i.e. 5084*1.15^6, with a slight deviation due to rounding) when applied to an item that’s ilvl 553 (90 ilvls above 463). Sites like Wowhead will correct for those minor rounding issues so they can exactly match in-game values, but we don’t have to worry about them here.

A lot could be said about item budgets, but I wanted to give the overview here so you have the context on what you should expect from a trinket at various ilvls. A handy factoid is the amount of a passive stat a trinket has at normal budgeting: it’s 847 at ilvl 463, or 1959 at ilvl 553. In other words, the most vanilla possible ilvl 553 raid trinket would have 1959 of a primary stat and 1959 of a secondary stat (or 1959*1.5=2939 in the case of Stamina). Real trinkets will replace one or the other (or both) of those with special bonuses, but that 1959 (or whatever it is at the ilvl you’re looking at) is the basis for comparison.

To work a brief example, see Purified Bindings (553). Note that 11761 Int is just about 1959*6, so the trinket is exactly on-budget if the proc is active 1/6 of the time. Since it has a 20 second duration, you’d expect it to proc every 120 seconds. The 115 second ICD is intended to produce this result and have the trinket match the budget that a passive Int trinket would have.

But you came here to talk about more interesting bonuses than stat procs, so without further ado:

Amplification

“Amplifies your Critical Strike damage and healing, Haste, Mastery, and Spirit by X%.” (3.03% at ilvl 463, 7% at ilvl 553, 9% at ilvl 580).

At first blush, this increases the value of all your secondary stats by X%. So if you have 30,000 secondary stats on your character sheet and wore an ilvl 553 Amp trinket, it would be very similar to a trinket with 2100 passive secondary stats (placing it slightly above the par of 1959 in this example). Two quirks:

• It amplifies Spirit but not hit rating, which is a slight asymmetry across caster classes that I think is an oversight.
• It increases crit bonus rather than crit chance, which makes things slightly more complicated.

Crit bonus effects have some odd stacking properties. The easiest way to think of it is is that when you crit for 200%, there are two components: the 100% “normal damage” and then 100% “critical damage.” Other than the crit meta, which obeys an idiosyncratic rule* but is irrelevant in T16 due to legendary metas, crit bonus effects all apply multiplicatively to the “critical damage” portion only (including Amp, Skull Banner, and Elemental Fury).

Long story short, the crit bonus provided by Amp causes you to do X% more “critical damage” overall. This does in fact increase the value of your crit rating by X%. But crit chance comes from sources other than rating, and the value of that other crit is also increased by X%. So the easiest way to evaluate this bonus is to:

1. look at your total raid-buffed crit chance,
2. imagine that it all came from rating (in most cases, multiply the % by 600), and
3. take X% of that rating.

Putting it all together, say the total of my haste, mastery, and Spirit were 20,000, and my raid-buffed crit were 35% (16.7% from 10,000 crit rating, and 18.3% from other sources) and I had a 553 Amp trinket (7%). I’d evaluate this part of the trinket as being worth 1,400 stats from haste/mastery/Spirit, and 35*600*7% = 1470 from crit, for a total of 2870, significantly above the expected budget of 1959 secondary stats.

Since the other half of the Amp trinket is, in all cases, a primary stat proc that is right on budget, it is looking like a very strong trinket numerically. It will be even more so for classes with very high effective crit chances due to class mechanics, such as Elemental Shaman. The only important caveat is that is that Prismatic Prison loses a little value for healers because having all of the Int delivered as a high-value high-ICD proc is poor for healing purposes.

*The crit meta increases the “critical damage” in such a way that the total damage will have increased by 3%, before other crit bonuses. Now that every class has a 100% base crit bonus, the crit meta essentially works by increasing it to 106%.

Multistrike

“Your heals have a X% chance to trigger Multistrike, which causes instant additional healing to your target equal to 33% of the original healing done.” (6.05% at ilvl 463, 14% at ilvl 553, 18% at ilvl 580)

This is the simplest new bonus. Aside from issues like pets, it’s a straightforward X/3% increase to your damage or healing output. I want to emphasize that this is not an RPPM or ICD effect, simply a plain fixed % chance to occur on any damage/healing event.

The only issue is comparing, for example, 4.67% damage/healing (14%/3) to 1959 secondary stats. I’ll leave that up to individual class modelers, but if you note that 1959 secondaries is, for example, 3.26% crit, you can see that Multistrike is generally looking to be in a good position.

Cleave

“Your heals have a X% chance to Cleave, dealing the same healing to up to 5 other nearby targets.“ (1.34% at ilvl 463, 3.11% at ilvl 553, 4% at ilvl 580)

Exactly the same as Multistrike, with the twist that output depends on the number of nearby targets other than your main target. The only important note is that it’s tuned so that, if it hits one added target, it’s 2/3 as strong as Multistrike. For example at ilvl 553, 3.11% is 2/3 the value of the 4.67% output you’d have gotten from Multistrike.

So this trinket is dead even with Multistrike when it hits, on average, 1.5 added targets. In situations where it can regularly hit 5 targets, it is far above budget, and in situations where you are attacking a lone target it is useless. The ramifications of this are obvious, but the rule of thumb that it surpasses a “normal” trinket at around 1.5 splash targets should help you decide when to use it. For 25-man raid healers, I suspect you are very often going to be healing targets who have more than 1.5 other people nearby, except at enforced spread fights.

Cooldown Reduction

“Increases the cooldown recovery rate of six of your major abilities by X%.”

(17% at ilvl 463, 39% at ilvl 553, 50% at ilvl 580, in each case reduced by half on the tank version)

There’s not too much to say about this in terms of item budgeting, since its benefits are based on the vagaries of each particular class rotation, and I imagine the tuning was done ad hoc. Consult your class’s spreadsheet expert. I just want to correct a common misconception about how the bonus works.

50% CDR does not mean you can use the ability twice as often. It’s exactly analogous to the way haste works, it reduces the cooldown to 1/1.5 = 67% of where it started. So in the end, you can use the ability 1.5 times as often over the course of a fight, not twice as often. Since X% CDR means you can use the effect X% more times in the long run, the benefit is generally linear as the budget increases, as it should be.

This chart lists the affected abilities for each class, in case you need. The trinket doesn’t exist for Int users in this tier.

Other Tanking Effects

I’m not going to say too much about Juggernaut’s Focusing Crystal and Rook’s Unlucky Talisman. They have unique effects that can’t be compared in an apples-to-apples way against 1959 primary or secondary stats. I simply want to note that their inherent % bonuses follow the usual item budget rules just like everything else discussed here. As you upgrade through ilvls, these effects will increase in same way that any stat allocation would (because, as discussed above, all trinket procs/effects are built into the ilvl scaling mechanism now).

This does raise an interesting issue I want to touch on, but a full analysis will be for another post. For a bonus like Juggernaut’s, which is based on a flat % of your overall damage output, there’s a question of whether the overall benefit the trinket gives is actually scaling quadratically with your stat growth. Scaling is inherently confusing and I do want to make a post about it overall, but the basic thrust is that normally as you go up in ilvl, each item has more stat points, and each stat point is worth more because your totals of other stats have increased. It’s left as an exercise to the reader how this logic applies to effects that are based on a % of your other stats such as Juggernaut’s and Amplification.

RPPM

I’ve reviewed the math of RPPM in two prior posts, but this is a good time to note the updates for 5.4.

Every 5.4 RPPM trinket is 0.92 RPPM with a 10-second ICD (except that Ticking Ebon Detonator is 1.00).

Also, for reasons described by Blizzard in this post, haste no longer increases the RPPM of most trinkets, with the only T16 exception being Dysmorphic Samophlange.

A 10-second ICD produces an interesting player-favorable quirk. Since the procs are all 10 seconds long, it prevents overlaps that waste uptime. But since RPPM chance “pools” for 10 seconds (as described in earlier posts), blocking out procs for a 10 second period actually does not impair your overall proc chance in any way. In this case you do get the best of both worlds–the same number of procs you’d have normally, but arranged so that there are no overlaps.

To be on-budget, these trinkets whose procs are all 6 times the value a passive stat trinket would need to have 1/6 uptime. With a 10 second proc duration, you’d think all you need is 1.00 RPPM on all trinkets to be on par. The only quirk to this is that the “bad luck protection” system adds about 13% to proc rates in reality (as discussed in the previous post). Blizzard, slightly generously, has started discounting RPPM rates by around 9% to account for this. This results in a proc rate of 0.92 on all trinkets. Except that for some reason on Ticking Ebon Detonator, the they reduced the proc value by 9% instead (1069 per stack at ilvl 553, instead of 1176).*

Given this information–0.92 RPPM, no haste, 10s duration and no overlaps, uptime for most T16 trinkets is much simpler than it used to be. It will always be simply 1.13*0.92*10/60, or 17.33%. In the case of Samophlange, multiply further by your haste factor to get your final uptime.

Long story short, all RPPM trinkets in 5.4 have an average value that’s very close to equivalent to the passive budget. Essentially always, it’s a proc with 6 times the stats a passive trinket would have and an uptime of around 1/6. The only important exception is Samophlange, which gets a haste multiplier on top of the usual budget.**

*Note that Detonator, Samophlange, and Talisman all have per-stack values that are 1/10 of what a “big” RPPM proc values at the same ilvl would be. However, the actual mean stack height over the course of the proc is 10.5, not 10. The same is true for Black Blood, which has a mean stack of 5.5. This amounts to a free 5% added value to the first three trinkets, and 10% on Black Blood.

**I just want to note since the question is posed so often: just as Samophlange is pegged pretty close to its correct budget + haste, the same was true for Horridon’s Last Gasp. Any nontrivial ilvl jump from Horridon’s to Samophlange is likely to be a clear upgrade.

RPPM on the Pull

Starting in 5.4, for purposes of the “bad luck protection” described in earlier RPPM posts, the moment a raid encounter starts, your RPPM procs all behave as though 120 seconds have passed since the last proc.

Given the formula at the end of this post, any trinket or other RPPM effect with a mean proc time of 45 seconds or less will be guaranteed proc on the pull. This corresponds to RPPM of 1.33 or higher (including haste if it applies). Procs that are close to that value will be very likely to proc within the first few seconds.

A 0.92 RPPM trinket will begin each fight with a significant bonus (just about double it’s usual proc rate). It will have a 31%* chance to proc on your first attack, and if that fails, roughly a 35% chance to proc within the first 10 seconds of combat.

This is a continuation of my Theorycraft 101 post that introduced trinket uptimes and RPPM. I’m going to assume here that you read that post. The main audience for this post is people trying to any theorycraft work, whether making a full-blown spreadsheet or simply doing a standalone calculation about some trinket. You should be able to find the equation you need here without needing to redo a lot of work.

A bit of terminology from last time:

• PPM is the proc’s built-in PPM constant.
• H is your haste factor (1 + your average haste %)
• D (used below) will be the duration of a buff

Our first basic conclusion was that if you ignore the possibility of proc overlaps, the uptime of a proc is:

We called this value  (lambda) for any given trinket. It’s a good approximation of uptime as long as uptime is low (overlaps are unlikely), and it will also come into many later results. Conceptually,  is the ratio of the buff’s duration to its mean proc time.

The next conclusion was that if you account for the possibility of overlaps, the uptime is:

Seeing how uptime (y) relates to lambda (x) is helpful. In the low range, they’re mostly the same (the curve approximates the y=x line). As lambda increases, overlaps becomes more important and uptime starts to slow down in its asymptotic approach to 1.

Today we’re going to see how this is modified in a few different scenarios.

The “Bad Luck” Correction

In the prior post I commented that the RPPM system was not a correction to increase your proc chance. But they recently added just such a correction in the case of trinkets (for now I won’t discuss why they might have done so). It kicks in anytime you haven’t had a proc for more that 1.5 times your mean proc time, and begins to rapidly increase proc chance. Specifically, from that point on, every 1% of MPT that passes increases proc chance by 3%. I’m not going to walk through in detail a calculation of how much this increases overall proc rate–it’s somewhat tedious and the focus of this post is on the results more than the derivation (and I don’t feel like LaTeX-ing the whole thing). I’ll include my original calculation in an appendix.

Here’s a graph comparing the two:

(Wolfram link for reference)

The x-axis is time, in units of mean proc time. The y-axis is the chance that your next proc will come at a particular time after the previous proc. As you can see, the two are identical until x=1.5, and then the new system (purple line) gives a burst of added proc chance that drastically shortens the tail of the curve.

Estimating the new MPT requires finding an equation for the new probability curve and integrating it (see appendix).  In general, what I computed is that, once the boost kicks in, the expected proc time is roughly half (48%) of what it would have been otherwise. Since you only reach that point 22.3% (e^(-1.5)) of the time all in all the average wait for each proc is reduced to 88.4% of what it was, or 13.1% more procs over a given time.

The Effect on Uptime

In the low-uptime case, where we can approximate uptime with  , then we would now simply take it to be  . Unfortunately, to account for overlaps, we can’t simply multiply  by 1.13 in the above formula. This implicitly assumes two events are independent (overlaps, and activation of the boost) when they’re definitely not. In fact, application of the boost can never cause an overlap unless  

If the equation bothers you because it’s not manifestly limited to 1 as an uptime should be, remember that it’s expressly valid only for   (and in that range it reaches roughly 88%). Essentially, what this is model is saying is that everything is happening as it was before, including overlaps, but total proc events are going to happen 13% more often.

Stacking Trinkets

Trinkets like Talisman of Bloodlust and Horridon’s Last Gasp have an added twist–on a repeat proc, they don’t simply overlap and refresh the prior buff, but also add another stack (up to 5). This makes the math more complex but still manageable.

Recall the logic of the main uptime formula from the prior post. In a Poisson or similar process, at any given moment, the chance of not having had an event in the past unit time is  .

But now in the  case where our buff us up because we have had a recent proc, we need further information: was the buff already up when this proc started? Well, the answer is the same–it was up  of the time. The memory-less nature of Poisson processes is key here–the answer to that question is the same no matter when you ask it (we’ve not accounted for the boost yet, but remember that it cannnot affect stacks or overlaps as long as ).

So at any given moment, the chance that we have at least one stack is , same as always. The chance that we’ll have at least two stacks is:

From here it’s easy to see the chance of having at least k stacks at a given moment. To find the overall average stack height (which gives our actual buff contribution), we need to sum all those components up to the maximum number of stacks, N:

Recalling the partial sum of a geometric series:

In our case:

This should be a clean formula you can use to find your average weighted uptime on a stacking trinket. As in the non-stacking case, to account for the bad-luck boost, simply multiply the entire thing by 1.13.

A complication not addressed here is that Talisman of Bloodlust itself adds haste, which changes the proc frequency slightly at each iteration. This is better handled in a simulation, but if you wanted to write it down as formula you could break the sum back out into 5 individual terms and independently compute lambda for all of them.

ICD trinkets

A lot of people ask how to correctly model trinkets like Wushoolay’s Final Choice (22 second ICD). This family of trinkets uses RPPM, but has an ICD anyway because their mechanics would be too messy if they allowed overlap procs. In this case, the mean proc time, instead of simply being 60/(PPM*H), should be:

The -10 is due to the fact that the RPPM system accumulates proc chance for up to 10 seconds. So on your first attack after the ICD runs, you get the benefit of 10 seconds worth of stored-up proc chance.

Since these trinkets do not allow overlaps, the uptime is simply the duration over the MPT:

Finally, the boost. Though there’s no firm confirmation on this, I’ll assume here that the time during the ICD does count as a time of no procs for purposes of the boost (this would be consistent with the treatment of the usual 10-second RPPM pool). In that case, you can simply increase overall mean uptime by 1.13 as usual:

Unerring Vision

A note on Unerring Vision of Lei Shen. Even though the nominal uptime of this proc is 4 seconds, the actual benefit lies in a set of DoTs with 100% crit rate that lasts long after the proc is over (it has little use unless you make use of this DoT effect). If it reprocs while the previous set of buffeds DoTs is still up, you’re going to clip them with new buffed DoTs. So for overlap purposes, the “duration” and “uptime” of UVLS are really analyzed with reference to the DoTs it produces, not the 4s proc itself. Keep this in mind when theorycrafting the trinket.

Beginning of an Encounter

Finally, one less technical discussion, about the beginning of a fight. When the RPPM system was first introduced, one important ramification of its time-independent nature was that you no longer got the reliable fast proc that ICD-based trinkets produced at the beginning of every encounter. But the “boost” reverts this change for most part, since you’ve necessarily been out of combat and not gotten a proc for a few minutes.

With high-frequency trinkets like the 3.3 RPPM melee trinkets, mean proc time may be 15 seconds or lower with some haste. At that frequency (say it’s exactly 15 seconds), after only 25 seconds out of combat, you’re guaranteed a proc on the first swing of the fight. (You’d normally have a 2/3 chance to proc on that swing, since you’ve pooled 10 seconds out of an MPT of 15, and having “failed” to proc for 1.67 MPT’s gives a further 50% boost.

On the flip side, if you’re a UVLS user with an MPT of 2 minutes, then after a typical 2-minute runback and reset the boost will not have kicked in at all. The 2 minutes still matter because you’ll start getting a boost if you fail to proc by one minute into the fight, but that doesn’t help you get a proc during your initial timer stack. Even if you’ve been out of combat (or not had a proc) for 5 minutes (2.5 MPTs), the 4x increase to proc rate as you start the fight still only means you start the fight with an effect MPT of 30 seconds, which is not a crisp start you can plan on. Only after you’ve been out of combat for roughly 10 minutes (5 MPTs) does the whopping 11.5x increase in proc rate mean that you can expect a proc in the first 10 seconds (which is great benefit, as you can now save timers for it). Now, this is a worst case–most people even with trinkets in the 0.5 RPPM range (say Breath of the Hydra) will have an MPT somewhat under 2 minutes due to haste. But point still remains that people with low-frequency trinkets can get a marginal benefit by avoiding using them for up to many minutes before an important pull.

As a general matter, the amount of time you need to have spent without a proc in order to guarantee a proc on the first hit of a fight is:

Where MPT is your usual mean proc time in seconds (60/PPM*H), so this could be also be written as:

Remember that H should be your haste with no procs or temp buffs active, as it will be on the first attack of a fight. Note that the result is quadratic in MPT, which explains why some trinkets get it so easily and some have to wait so much longer.

Appendix

This is where I first worked out the effect of the boost. I added a few notes at the bottom to try to make it understandable. Time is measured using the variable tau, which is a dimensionless time variable scaled so that MPT=1. The first task was writing the probability function P(tau) when the boost is present (for now assuming that it starts at tau=0), which was done with the differential equation involving Q(tau) (the cumulative chance of not having a proc by time tau). Then I integrate that new probability function to finds its mean (the 0.48 I mentioned earlier). All that’s left is to account for the fact that the boost doesn’t kick in until tau=1.5 by properly averaging the old and new functions together.

Update: There is now a continuation of this post here, which gets into some more detail and trickier topics.

About a year ago I did a few posts in a series I called “Theorycraft 101″.  The basic point is to have post outlining basic computations/formulas I use in making spreadsheets and like, so other people who do these things don’t have to reinvent the wheel.  I think there’s often not a lot of communication across classes on these things, so I want to make non class-specific references for things that come up a lot.

For reference, here are the past ones:

• Mana Regen formulas (out of date)
• Basic Regen vs. Throughput analysis (still relevant, and probably a good read for people who were interested in the recent Spirit post)
• Haste breakpoints, simple version (still valid if you use the new haste constant of 42,500.0)
• Haste breakpoints, advanced (with update) (still all correct, but EJ seems to be having a problem with its LaTeX plugin so you might not be able to read. Binkenstein has recently posted a similar explanation)

Today’s Topic: Proc Uptime

Blizzard recently posted a description of a new system for procs, used for Windsong and presumably other similar new enchants.  We’re going get to the details of the new Windsong at the end.  For now, some short background.

Effect that have a % chance to proc on each attack/heal have one main issue.  Different classes have wildly varying amounts of combat events, so they are hard to balance cleanly.  There are two main types of solutions:

1) Put a long cooldown on the proc (such as the typical 45-60 seconds found on trinkets), and make the expected proc time very low.  That way even if it varies wildly (2 seconds for one class and 5 seconds for another), the actual average time between procs might 62 seconds for one person and 65 for another–close enough to avoid balance problems.

2) Use a system that scales the proc chance based on how often a class has attacks or other combat events.  This is where the “PPM” (procs per minute) concept comes from–procs whose actual % chance to fire varies based on attack speed.  But this is very hard do in practice since classes have so many mechanics other than autoattacks/nukes that weapon speed and/or cast time are not good estimates of how often you get a chance to proc.  This is where the new system comes into play.

I’ll address each in turn below.

ICD-Style Procs

These are very easy to work with if you’re making a spreadsheet.  Since the cooldown is dominated by a large constant (the ICD) all you have to do for a very good estimate is find that constant.  This is done quickly in one of two ways:

1) Check Wowhead since someone’s probably done it already (e.g. Zen Alchemist Stone–55 seconds)

2) Go to a target dummy, use /sw to open the stopwatch, and just check the time between procs a few times.  Remember, you don’t need a large data set and an average.  You just need to find the minimum time to within about 5 seconds, and a few trials usually makes it clear.

Then, your uptime is simply Duration/Cooldown.

For a slightly better estimate, add a short delay to the ICD representing the time it takes to get an actual proc.  You’ll need to find the proc chance (often the wowhead spell database entry for the actual buff effect will have it), and roughly estimate how often you attack.

PPM-Style Procs

The new system outlined in the blue post above is basically an attempt to normalize the proc rate of an ability no matter what the user’s distribution of attacks over time is.

The chance of an attack (or heal) to trigger the proc is equal to

• PPM is the buff’s built-in PPM constant.
• H is your haste factor (1 + your average haste %)
• T is the time since the last attack that gave a chance to proc.
• D (used below) will be the duration of a buff

I’ve seen people misread this.  The system is not based on the time since your last actual proc (i.e. this is not a corrective effect that makes you more likely to get a proc if you haven’t had one recently).  It simply takes into account, every single time you attack/heal, how long it’s been since the last time you had a combat event that gave a chance to proc.

Here’s the concept they’re getting at.  You have 1 PPM proc and 0 haste.  If you attacked once per second exactly, each attack would have a 1/60 chance to proc.  But if your attacks are distributed irregularly over time, it does something fancier.  Say one second goes by without you attacking.  Then during that one second, you “bank” 1/60 chance to proc.  That chance will be “used” whenever you next attack.  So if another second goes by and then you attack, you’ll have 2/60 proc chance “stored” and that will be the proc chance on that hit.  Basically, proc chance accrues at the correct rate with each passing moment and every time you attack, the correct chance is assigned based on how much you’ve built up since the last time.

The end result of all this?  If you want a solid estimate that ignores the one little quirk of no-cooldown procs (the chance of an overlap), it’s perfectly simple, since the game accounts for all the variation already:

(I didn’t discuss above why H is there, but basically, PPM-based procs are meant to improve if your haste increases.  Since otherwise, this system would completely cancel out the benefit of added haste as you attack more quickly, they build H right into the proc chance).

More Elaborate PPM: Overlaps and Poisson

Let’s say you want to elaborate a bit.  The only real problem with the above estimate is that a PPM-style proc can fire twice in a row and waste part of the first buff.  If the proc rate is relatively small, this won’t happen often enough to disturb the above approximation.  But, since the result is pretty interesting mathmatically, and easy enough to throw into a spreadsheet if you’re making one, I’ll outline it here.

The underlying assumption here is that the new PPM system turns procs into a Poisson process.  Poisson processes are events that happen at a certain average rate, with each event being independent of the last (an example is nuclear decays), and their statistics are well-understood.  This is a good model for WoW procs as long as the attack rate is very high compared to the time intervals being examined (see appendix for more on this).  So in the case of Resto Druids who spam out combat events constantly, it’s almost perfect, but even slow attack classes fire off a number of combat events during, for example, the 12 second duration of Windsong.

I’m not going to get into details here, just one key fact.  If a Poisson process occurs, on average,  (lambda) times in a certain time interval, then the chance of having it happen zero times in that interval is

(This is for all those of you who learned about e in high school trigonometry and wondered what you’d ever use it for)

But wait–that’s all we need.  At any time, the chance of Windsong being up is simply one minus the chance that it has not fired in the past 12 seconds.  But since we know that the mean procs per minute is PPM*H, the means procs in a 12 second interval is PPM*H*(12/60).  Therefore, Poisson gives us our uptime:

Basically, in any spreadsheet or other model you’re doing for any class, as long as you know your haste, just drop in that formula for Windsong or any similar buff and you’re good to go.

P.S. Windsong itself has one unique quirk.  It’s actually 3 separate procs (crit, haste, or mastery).  So even though the post describes it as having PPM = 2, what you really want to model it as is 3 procs each with PPM = 2/3.  This will account for the fact that each of the 3 Windsong buffs can stack with each other, but only overwrite if you re-proc the same one.

Appendix

Here’s just one pretty interesting aside for the math-inclined.

Let’s say you did have a constant attack rate, or are modeling something like Flurry that lasts for a fixed number of hits rather than a fixed time.  Then, your logic might be that you have the buff unless none of your past N hits procced it (with proc chance P).  Therefore your uptime is

A formula that’s been used in various classes’ spreadsheets for a long time.

Let’s do something interesting.  Assume that your attack speed (x) changes, but with proc chance per hit and number of hits during the relevant duration adjusted accordingly.  Basically, vary the attack rate while holding constant the mean procs per second (p) and the time window of interest (t) Then we might have something that looks like

Since the proc chance per hit is px, and the number of attacks in the time window is t/x.

Now what happens if your attack rate goes to infinity (i.e. time between attacks goes to 0). Well, if you remember your calculus, you may recall that:

So rearranging very slightly and applying to the above:

But tp is the procs per second times the time window of interest, which is the expected number of procs in the time window, which is .

So, as attack rate approaches infinity, our proc uptime is:

Which is the same as what we got from the Poisson model above.  Pretty nifty.