Just noticed that I didn’t use all my data points there. Here’s the graph when I use all 10 files:
Just since it’s interesting, I changed it to have time since last crit auto on the x-axis. Unfortunately, there aren’t many data points as the time increases which means that you get heavy statistical fluctations at large x. Would have to pull more data here I think.
That’s just them removing it from the tooltip.
I mean, the data suggests that it’s simply a 50% proc rate on crit, and this jives with the data I collected on my ~17% crit DK. So if they have some custom behavior, it appears to be working basically identically to simply 50% crit, and it definitely doesn’t appear to be boosting it much at low crit levels.
All RPPM effects also just say “procs per minute”, including ones known and tested as RPPM. That’s not even slightly evidence of it being PPM over RPPM.
They’ve not included that for a number of expansions now. VDH’s Gluttony, for example, has been tested as being RPPM, but was listed as Approximately 1 procs per minute in the tooltip until that line was removed during the beta. Retribution’s Art of War is also tested as RPPM (it has a substantially higher chance to proc if you’ve not auto-attacked for a while), and is listed as Approximately 4 procs per minute.
Still, it at least suggests what I was saying. When the data is graphed according to what RPPM uses for its calculations, the data diverges rather strongly, and there’s no clear fit line.
While the data I collected does not disprove time-sensitivity, it does rather distinctly disprove any association between proc chance and crit chance, haste level, or AA crits per minute, which would seem to disprove it being RPPM.
How does it do this exactly?
I’m going to get some more data so that the values at higher X become more significant
Did you even look at my data?
All of the KM : AA crit ratios in that data set are between 43% and 59%. There are low (<44%) and high (>55%) ratios that occur at both low (<30%) and high (>40%) AA crit levels.
If the KM/min proc rate is scaled to haste, the data shows RPPM values between 5.75 and 13.43, so it’s clearly not that. If scaled to haste and crit, the values still range from 4.15 to 7.69, which is also too large of a range to be reasonable.
Given the values present, the 95% confidence interval is 48.18% to 52.28% proc chance on AA crit, which is a very narrow interval. The likelihood that it’s a simple 50% proc chance on AA crit is quite high.
Edit: that 95% confidence interval is ± 4.56%. By comparison, the 95% confidence interval on the RPPM, even when using the crit and haste scaled one, is 5.7109 to 6.7691, which is ± 8.63%, quite a bit less precise and thus less likely.
Some quick questions:
How did you get the average haste?
Could you include average crit instead of actual aa crit %?
There’s something off in the data as well. Think you might be including both hits and parries in your total AA count? Think it skews your crit% used downwards. You should only use the “hits” in the logs to calculate the crit %.
Inferred from total AAs (1.3 / (Fight_Duration / Num_AAs)). Essentially, I calculated the average interval between auto-attacks, and then divided the average interval that would exist with with 0 haste by that. It’s slightly course, but every single log I used was >99% uptime, so at most this should see a ~1% deviation from actual.
Average crit is difficult, because warcraftlogs doesn’t record character stats, and their armories are likely to have changed since then. AA crit is granted somewhat less reliable for the RPPM calculation, but I don’t see a clean way to get a more accurate value for that.
So yes, both of those values are a bit course, and that could contribute, but I don’t see how that could cause such a large band of calculated RPPM values, even controlled for both haste and crit. Given how close the values are to 50%, and how narrow the confidence band is, I have little reason to doubt that it’s 50%.
That said, part of the issue here is that, in theory, a RPPM value that scales with both haste and crit should approximate a flat proc chance. What we really need is data with a slower weapon, like a 2hander, or data with extreme amounts of crit and very little haste. Since an RPPM proc rate would scale with 1+Crit, an increase from, say, 10% crit to 50% would increase an RPPM version by 36%, while it would increase a flat rate by 300%.
Auto-attack crits cannot miss, melee swings are on a single roll, not a double roll like spells. If you have 50% crit chance, on average 50% of all auto-attack events will be critical strikes, even if another 19% are missing. This means that, for melee swings, you can’t do crits / (hits + crits), you have to do crits / (hits + crits + parries + dodges + blocks + misses).
Basically, 50% crit means 50% of AA attempts will crit, not 50% of AA hits will crit (provided that the sum of miss, parry, dodge, and block do not exceed 50%, of course).
Ah okay, that makes sense. Thank you for the insight.
I’m still convinced there’s a time dependence so a simple 50% crit chance doesn’t work. Your data doesn’t point to the 4.5 value either so the 4.5 x crit x haste doesn’t seem plausible.
The time dependence was based on the data you computed using a flawed premise, that the proc rate depends on time since last proc rather than time since last proc event. RPPM definitely doesn’t work that way, at least under 150% of the average proc interval. I feel like your data is really just reflecting how a Poisson distribution works.
How’s that? If the proc chance is a constant 50%, my graph would show 50% at all points.
You’re right, I was thinking of it wrong, if this were a graph of how many took that long to trigger, it would be a Poisson, but the probability of a crit at X seconds triggering it shouldn’t show deviation. I’d have to see the size of the sample at each data point, however. The error bars could easily be large enough for this to be a valid data set even at 50%. You stated that at 7+, it was already at no more than 4 entries, so I feel like data noise due to small sample sizes may be to blame. Really, though, I’d have to see the raw data points (each AA crit timestamp, and whether it proced KM) to be able to check.
I’ll see if I can find a way to conveniently parse the data tables from warcraftlogs as well. If I can, I can feel it a bunch of logs and come up with a larger dataset for analysis.
Feel free to use the stuff I posted earlier. Here’s the number of data points used for each point in the graph:
| 0 | 640 |
|---|---|
| 1 | 1081 |
| 2 | 459 |
| 3 | 394 |
| 4 | 212 |
| 5 | 128 |
| 6 | 84 |
| 7 | 42 |
| 8 | 36 |
| 9 | 17 |
| 10 | 13 |
| 11 | 7 |
| 12 | 7 |
| 13 | 3 |
| 14 | 2 |
| 15 | 4 |
| 16 | 1 |
| 17 | 0 |
You don’t happen to have the standard deviation of the data at each data point, do you? Excel has a function for it, I would assume Python does as well.
Edit: Nevermind, just saw that you attached the raw spreadsheet data. I can process that directly, give me a couple.
Here’s the data. First is time value, second is number of entries, third is std of the mean. Data is really quite significant tbh.
0 | 640 |0.018514141554498396
1 | 1081 |0.015070047558159463
4 | 212 |0.03263360397069403
2 | 459 |0.023072796773987814
3 | 394 |0.023688049769414205
5 | 128 |0.041501033907960505
6 | 84 |0.0438372127326842
7 | 42 |0.07393559564382365
8 | 36 |0.0721687836487032
9 | 17 |0.05706720589090188
More or less replicated your work here. I used the time since last proc and the time since last crit, rounded to the nearest second, only considering AA crits and KM procs/refreshes. KM procs were associated with the auto-attack closest in time to them, unless that auto-attack already had an even closer KM proc to it.
Here’s the code I used to run the analysis, for anyone that’s curious. It’s written in Go, my home language: https://goplay.space/#xzdMrUL-Ix-
And the results:
---- By Time Since Last Proc ----
0: 44/127 (34.65%)
1: 149/370 (40.27%)
2: 173/337 (51.34%)
3: 108/181 (59.67%)
4: 78/127 (61.42%)
5: 51/76 (67.11%)
6: 34/48 (70.83%)
7: 17/23 (73.91%)
8: 9/14 (64.29%)
9: 12/12 (100.00%)
10: 4/6 (66.67%)
11: 1/1 (100.00%)
12: 2/3 (66.67%)
13: 2/2 (100.00%)
14: 1/2 (50.00%)
15: 1/1 (100.00%)
16: 1/1 (100.00%)
19: 1/1 (100.00%)
---------------------------------
---- By Time Since Last Crit ----
0: 125/238 (52.52%)
1: 292/562 (51.96%)
2: 169/330 (51.21%)
3: 50/99 (50.51%)
4: 25/56 (44.64%)
5: 11/19 (57.89%)
6: 6/11 (54.55%)
7: 3/6 (50.00%)
8: 4/6 (66.67%)
10: 0/1 (0.00%)
11: 1/1 (100.00%)
14: 0/1 (0.00%)
15: 2/2 (100.00%)
---------------------------------
So there appears to be a reasonable sensitivity to time, but I still suspect that is somehow just an artifact of the distribution. The time since last crit aligns rather well with my proposed flat 50% chance, however.
The only reasonable inference I can make from this data is that the proc chance is either a flat 50% chance on AA crit, or some mutant special snowflake system akin to how Agony’s shard generation functions, or how the Frost artifact weapon swords proc worked.
In fact, I could totally see that. The time since last proc is also proportional to the number of auto attack events since the last proc, excluding differences in haste level. They could have the system have a hidden counter, which is incremented on every AA event, possibly with a different amount added if the AA misses, hits, or crits. In addition, if it crits, it rolls for a proc based how high the counter is, and if it succeeds, procs and resets the counter.
That said, I would think such a system would also exhibit time-sensitive behavior with regards to time since last crit, since that’s also proportional to AAs, and the time since last crit data does not appear to exhibit that.
Then again, we’re at a very small data set here. Both data sets stop having a sufficient number of entries for me to trust them at about 4-5 seconds.\
Edit: Also, I threw a tweet at Ion, Holinka, and the main dev team account, in the hopes that they might be able to clarify this, and if it’s changing in SL: https://twitter.com/KaedysKor/status/1260705281216057344
I don’t think the time dependence is an artifact of the distribution. It’s the nice that your results were similar to mine.
My current best bet is that it’s RPPM but without the factor that looks at time since last proc attempt. So only some base rate and then time since last successful proc.