# Thread: RPPM Analysis + Haste Benefits / 5.2 Trinket Analysis

1. Originally Posted by Conjor
If this were indeed the case, then why put an ICD on a trinket larger than the maximum time that the RPPM will count for? For example, Renataki's Soul Charm has an ICD of 22 seconds. If the RPPM counter was stuck at 10 seconds, what is the point of even having the RPPM system? Why not just have a traditional ICD trinket with the proc rate at p(10) [for whatever values Renataki's is set at].

It makes no sense to throw on all this RPPM stuff to only have it modify the chance of procing over a time where it cannot proc (because it is on ICD).

To make it simpler, between time t = 0 and t = 22, the trinket cannot possibly proc because it is on its ICD.
If p(t) was defined as follows: if t < 10, p(t) = <insert RPPM formula>. Else, p(t) = p(10).
What effect would that have? None. Why not jsut have a regular ICD trinket with ICD = p(10)?

This system only makes sense if, while in combat, t is unbounded but while in combat, t is bounded to 10.
Because as I said, the T in this situation is last CHANCE for the trinket to proc. As in, last autoattack, last special attack, last dot tick, last whatever. Take Bloodlust charm, with 3 base RPPM, and say you have 10% haste and are only autoattacking a combat dummy every 2s. The chance to proc is 3(ppm) * 1.10(haste) * 2(time since last chance) / 60 (sec per min) = 11% chance to proc on EACH hit. It does not care if it's proc'd yet (unless it's on ICD). Then, over the course of a minute, you'd attack the dummy 30 times (at one attack every 2s) and your expected number of procs is 3.3, which happens to be 3PPM + 10% extra procs from haste.

Say you're spamming AOE and hitting a bunch of targets every second, let's say 0.1 seconds in between combat events that can proc the trinket. The chance to proc is 3(ppm) * 1.10(haste) * 0.1(time since last chance) / 60 (sec per min) = 0.55% chance per hit to proc. With 0.1 seconds between attacks, you'd have 600 chances to proc the trinket per minute, and 600 * 0.55% is the expected 3.3 PPM.

The reason it caps at 10s between chances to proc is because if it wasn't, and before combat you spend say 2 minutes buffing up, the formula would be (3ppm*1.1*120s)/60 = 660% chance to proc, aka the trinket would always proc on the first hit. As it is, it's capped at 10s, which makes it (3ppm*1.1*10s)/60 = 55% chance to proc on the first hit, and then say you follow up with an instant 1s later, the chance to proc on that hit goes back down to (3ppm*1.1*1s)/60 = 5.5%.

2. Originally Posted by kindath
Because as I said, the T in this situation is last CHANCE for the trinket to proc. As in, last autoattack, last special attack, last dot tick, last whatever. Take Bloodlust charm, with 3 base RPPM, and say you have 10% haste and are only autoattacking a combat dummy every 2s. The chance to proc is 3(ppm) * 1.10(haste) * 2(time since last chance) / 60 (sec per min) = 11% chance to proc on EACH hit. It does not care if it's proc'd yet (unless it's on ICD). Then, over the course of a minute, you'd attack the dummy 30 times (at one attack every 2s) and your expected number of procs is 3.3, which happens to be 3PPM + 10% extra procs from haste.

Say you're spamming AOE and hitting a bunch of targets every second, let's say 0.1 seconds in between combat events that can proc the trinket. The chance to proc is 3(ppm) * 1.10(haste) * 0.1(time since last chance) / 60 (sec per min) = 0.55% chance per hit to proc. With 0.1 seconds between attacks, you'd have 600 chances to proc the trinket per minute, and 600 * 0.55% is the expected 3.3 PPM.

The reason it caps at 10s between chances to proc is because if it wasn't, and before combat you spend say 2 minutes buffing up, the formula would be (3ppm*1.1*120s)/60 = 660% chance to proc, aka the trinket would always proc on the first hit. As it is, it's capped at 10s, which makes it (3ppm*1.1*10s)/60 = 55% chance to proc on the first hit, and then say you follow up with an instant 1s later, the chance to proc on that hit goes back down to (3ppm*1.1*1s)/60 = 5.5%.
Hrmm. If that is true then that kind of throws my analysis out the window :O

3. lol.. but I have to go with kindath on this one.. It makes more sense for it to go by last chance rather than last proc.

4. There are a few useful references I've found on RPPM that I'm not sure if you've had a chance to review:
How Mr. Robot Handles Trinkets
Theorycraft 101: How to Compute the Uptime of a Proc-Based Buff

5. Just spent the last half hour relearning the glorious program that is Maple and can give a second(?) verification that all the maths (not the theory) here, is sound - though I doubt you really needed that, but I thought I'd throw it out there any way.

As to time since last proc being capped, I believe it is all in reference to this blue post: http://us.battle.net/wow/en/forum/topic/6893549789 the final bullet point.

EDIT: Always late to the party...

6. Originally Posted by kindath
Sorry. :x
No worries. I'm going to rework the sheet to reflect it and I'll share what comes out. If nothing else it got people thinking.

On another note, Blizzard should use my system, more dependable .

For now I've privatized the spreadsheet until I make the updates! Thanks for the feedback though.

7. I understand that you're working on updating your file now, but I'm also curious why you use a trinket quality coefficient to modify all trinket RPPMs. I understood this to apply only to the the Rune and the Unerring Vision since their procs are identical regardless of trinket version, while the other trinkets gain additional benefits within the proc. Am i misinterpreting and this is intended to apply to all RPPM values for all trinkets?

http://us.battle.net/wow/en/forum/to...61?page=48#953

8. Originally Posted by Grizzles
I understand that you're working on updating your file now, but I'm also curious why you use a trinket quality coefficient to modify all trinket RPPMs. I understood this to apply only to the the Rune and the Unerring Vision since their procs are identical regardless of trinket version, while the other trinkets gain additional benefits within the proc. Am i misinterpreting and this is intended to apply to all RPPM values for all trinkets?

http://us.battle.net/wow/en/forum/to...61?page=48#953
Nice catch. I'll fix that.

9. This is something I don't understand I spent around 1-2k gold to test it. I got the talisman of bloodlust and it has a very awkward proc rate. Basically with 3k haste I was hitting 2 stacks, rarely ever 5. But then I went all haste like 6-7k and it could manage to get to 5, but the overall dps was much lower because I sacrificed the crit. The sims and femaledwarf are showing talisman and bad juju being our BIS this tier, unless there's something with re-organization that we don't know yet.

But right now ToB doesn't feel like a bis trinket and FD is showing relic above it

10. Last I read RPPM is completely broken ingame and theorycrafting is far from the real values.

Maybe it got fixed in the last 24hours but otherwise continue using the good old ICD trinkets which might be worse in theory but are so much easier to control and also actually work ingame.

11. Be nice if someone could start picking holes in this:

BASIC CHANCE TO PROC ON EVENT
P = R*H*t / 60

where R = procs / min, H = haste factor (H>=1) and t is time since the last chance to proc in seconds (we'll call this "chance to proc" "event", which is for example as a dps the last time you did an attack)
t also caps at 10s so trinkets aren't guaranteed to proc on pull (but they still have a higher chance on first attack)

Example: If we were to execute 2 events every 1 second, trinket has 0.5 RPPM and we had 0 haste

P = 0.5*1*(1/2) / 60 = 1/240

In a fight of 6 mins we would have 360 / 0.5 = 720 events, so total amount of procs would in average be
720*P = 720*(1/240) = 3
Not surprising since the trinket was made to proc once every 2 mins.

Now, chance to not get a proc on an event is
1 - P
And thus

CHANCE TO NOT GET A PROC IN A GIVEN TIME
Pc(T) = (1 - R*H*t / 60) ^ (T / t)

where T is the amount of time events are being executed.

Example: 60 seconds of combat with the previous example values
Chance of NOT getting a proc is

Pc(T) = (1 - 0.5*1*0.5 / 60) ^ (60 / 0.5) ~ 60.6%

And the chance of getting a proc in these 60 seconds aka P(T) is naturally 1 - Pc(T) or about 39.4%.

Now, let's define X = 60 / (R*H*t) and let t approach 0, so X approaches infinity

Pc(T) = (1 - 1 / X) ^ (X*(T*R*H / 60)

Pc(T) = (1 / e) ^ (T*R*H / 60)

Pc(T) = e ^ -(T*R*H / 60)

Now we can easily calculate

CHANCE OF GETTING A PROC IN GIVEN TIME
P(T) = 1 - e ^ -(T*R*H / 60)

Let's try the previous example with this formula.

P(T) = 1 - e ^ -(60*0.5*1 / 60) ~ 39.3% (instead of 39.4% , so there is a little error compared to the real game but it should be negligible)

12. Originally Posted by Ryme
Be nice if someone could start picking holes in this:

BASIC CHANCE TO PROC ON EVENT
P = R*H*t / 60

where R = procs / min, H = haste factor (H>=1) and t is time since the last chance to proc in seconds (we'll call this "chance to proc" "event", which is for example as a dps the last time you did an attack)
t also caps at 10s so trinkets aren't guaranteed to proc on pull (but they still have a higher chance on first attack)

Example: If we were to execute 2 events every 1 second, trinket has 0.5 RPPM and we had 0 haste

P = 0.5*1*(1/2) / 60 = 1/240

In a fight of 6 mins we would have 360 / 0.5 = 720 events, so total amount of procs would in average be
720*P = 720*(1/240) = 3
Not surprising since the trinket was made to proc once every 2 mins.

Now, chance to not get a proc on an event is
1 - P
And thus

CHANCE TO NOT GET A PROC IN A GIVEN TIME
Pc(T) = (1 - R*H*t / 60) ^ (T / t)

where T is the amount of time events are being executed.

Example: 60 seconds of combat with the previous example values
Chance of NOT getting a proc is

Pc(T) = (1 - 0.5*1*0.5 / 60) ^ (60 / 0.5) ~ 60.6%

And the chance of getting a proc in these 60 seconds aka P(T) is naturally 1 - Pc(T) or about 39.4%.

Now, let's define X = 60 / (R*H*t) and let t approach 0, so X approaches infinity

Pc(T) = (1 - 1 / X) ^ (X*(T*R*H / 60)

Pc(T) = (1 / e) ^ (T*R*H / 60)

Pc(T) = e ^ -(T*R*H / 60)

Now we can easily calculate

CHANCE OF GETTING A PROC IN GIVEN TIME
P(T) = 1 - e ^ -(T*R*H / 60)

Let's try the previous example with this formula.

P(T) = 1 - e ^ -(60*0.5*1 / 60) ~ 39.3% (instead of 39.4% , so there is a little error compared to the real game but it should be negligible)
Since you asked I will give you my notes on RPPM thus far. I've gotten to the point where I have a good idea on how to model ICD trinkets in a continuous domain, but I'm not ready to show that work off yet.

This work should be correct. I have not yet applied to in any spreadsheets (been taking my time to make sure everything is correct):
Page1: http://i.imgur.com/0v77nfp.png
Page2: http://i.imgur.com/3zt5sht.png
Page3: http://i.imgur.com/NzOqMjP.png (this one is not finished).

There is another discussion going on here where they are discussing a "better" version of RPPM (which Blizzard is implementing something similar - we don't know exactly what though). Which also sucks as I'm going to have to go through all of my math again :O.

13. Great.

We also added some protection to the ToT RPPM trinkets to avoid streaks of bad luck and buffed some to boot. Details soon.

Looks like I was right about t15 trinkets being terrible, but now since they were buffed we're actually going to have to go for the trinkets.

14. Shame i gave away a 528 TF Rune last night because the fix wasn't live and i went 5mins on a dummy without a proc....I almost wanna ticket them to give me one back...

15. Originally Posted by Conjor
Since you asked I will give you my notes on RPPM thus far. I've gotten to the point where I have a good idea on how to model ICD trinkets in a continuous domain, but I'm not ready to show that work off yet.

This work should be correct. I have not yet applied to in any spreadsheets (been taking my time to make sure everything is correct):
Page1: http://i.imgur.com/0v77nfp.png
Page2: http://i.imgur.com/3zt5sht.png
Page3: http://i.imgur.com/NzOqMjP.png (this one is not finished).

There is another discussion going on here where they are discussing a "better" version of RPPM (which Blizzard is implementing something similar - we don't know exactly what though). Which also sucks as I'm going to have to go through all of my math again :O.
Much appreciated, I'll look through this all tomorrow.

16. I have a Bad Juju and last night before the raid I checked out how terrible the trinkets were and they didn't seem to proc too awefull at all. 5min on dummy auto attacking gave me a proc almost exactly every minute.
This was 6pm GMT+1 on EU server. Considering all the complaining how bad they were, maybe they allready got fixed.

So here's some practical data that you can test your theories on
3hour log, 9kills all with Bad Juju + Vicious Talisman of the Shado-Pan Assault http://www.worldoflogs.com/reports/rt-m0p8e62hgvzjazr5/
A small overview of the 9timelines on boss kills http://i.imgur.com/ri8EI3G.png

The overview shows that they proc fairly decent on the pull and that overlapping procs doesn't happen too often. It does happen that you can go a long time for 1st proc tho, for example from try4 to try7 on tortos I never had procs at the pull. And I also had procs as short as 3-5s after eachother.

I also noticed while questing with Bad Juju that internally there must be some kind of resetting mechanism for each target. When I pulled a lot of targets with arcane shot or whatever, I very often got 6-9gnomes up at once. While during a whole raid with often single target focus, I never noticed this happening. There must be some internal workings on multi-adds in the code which will make it guessing work how to simulate.
It's maybe also disabled for aoe attacks because on tortos I had to multishot the bats and I never noticed these stacked procs on any try as heavily when I did while questing.

The gnomes are pretty much useless. When trinket procs you get 3gnomes. If trink procs overlaps you gain additional gnomes (I have had 9 up at once while doing dailies, with more targets more should even work).
When they spawn they do 3possible things:
1) do their first cast where they spawned and then run towards the mob and cast from under the mob
2) run to the mob and then start casting on it
3) stand there and do nothing... this option happens a lot tbh
So if you want to add the little dps the gnomes do, you're adding even more probability whether they will function or not.

17. The gnomes are just fun, they aren't meant to increase your dmg.

18. Blizzard decided to change the RPPM formula. Once they release it I'll start another (3rd) round of analysis. For now, everything that I've posted is going to be out of date.

19. Activate Conjor, form of theorycrafter!

From the front page, re: the new mechanism for making unlucky streaks less likely. This is on top of the extra 10% proc chance on agi trinkets:

Calculate the proc frequency as normal. Based on that, you can figure out the expected average proc interval. We also now keep track of time since the last successful proc (this is different from the time since last chance to proc), capped at 1000 sec. Multiply the proc chance by MAX(1, 1+((TimeSinceLastSuccessfulProc/AverageProcInterval)-1.5)*3). For example, if a proc has an average proc interval of 45 sec, and it’s been 72 sec since your last successful proc, you’ll get a 1.3x multiplier to your proc chance. If you’ve been out of combat for a few min, and it’s been 5 min since your last successful proc, you’ll get a whopping 16.5x multiplier to your proc chance.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•