# Theorycraft 101: How to Compute Uptime of a Proc-based Buff

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:

## 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 \cdot H \cdot T / 60$

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

$PPM \cdot D \cdot H / 60$

(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$ (lambda) times in a certain time interval, then the chance of having it happen zero times in that interval is

$e^{-\lambda}$

(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:

$1 - e^{-\lambda}$

$1 - e^{-PPM \cdot H \cdot D / 60}$

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

$(1 - (1 - P)^N)$

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

$1 - (1 - px)^{\frac{t}{x}}$

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:

$\lim_{x \to \infty} (1 + \frac{y}{x})^x = e^y$

So rearranging very slightly and applying to the above:

$\lim_{x \to 0} (1 - px)^{\frac{t}{x}} = e^{-tp}$

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 $\lambda$.

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

$1 - e^{-tp}$

$1 - e^{-\lambda}$

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

## 22 thoughts on “Theorycraft 101: How to Compute Uptime of a Proc-based Buff”

1. It shows how much you’re used to imaginary exponents that you associate e more closely with trigonometry than with calculus.

2. Great post. Is there any change to the RealPPM basic estimation calculation if there is an ICD involved? Most ofthe 5.2 trinkets have ICDs listed.

• For trinkets, there are only a few with both RPPM and and ICD (the auto-stacking 20 second buffs, and Re-Origination). Those are pretty straightforward to work out since there’s no overlap issue–the expected proc time when not on ICD is 60/(PPM*H), and so the mean actual delay between procs is (60/(PPM*H) + ICD).

The ones that are messy are the RPPM trinkets that can stack up if they re-proc. An estimate of those is a lot more complicated; I might do one in a future post.

• The question is, does proc chance accumulate when on ICD, or does it only start going after ICD is over? If it accumulates, you delay between procs is not (60/(PPM*H) + ICD), but (60/(PPM*H) + ICD-10) actually, since time in RealPPM calculations is capped at 10 seconds.

3. Pingback: Monday Roundup – February 19th, 2013

4. Excuse me，I found your simplification method in an artical about RPPM proc models called Random Proc Math ,a pdf file. I want to quote something from it but don’t know the author/source. And there is an “@HamletEJ” in the artical so I think you may know about it.
Do you know the author/source of the artical?
Thanks.