Mechanics And Game Information Compendium

Wizard
Prev 1 8 9 10 37 Next
Hmm, for RoF, 60 tics per second*0.333 coef*0.5 CC = 10x CM procs expected, but you're only seeing ~2, so it's still 1/5th of what we expect from the crit mechanics. At least it's consistent with what we know from WW but it seems CM is the last mystery standing now.

3 procs per second at 75% CC scales correctly at least (1.5x the crit with 50% and you get 1.5x the CM procs).

I had a thought that maybe there was a bug with CM and SA where instead of testing crit it tests spell coefficient, so basically it does 2 coefficient checks instead of 1 coef, 1 CM test. That seems to work out for WW but not RoF since we're seeing the same 1/5th expected procs for both. Maybe there's just a flat 20% proc chance in addition to the crit and spell coefficient, or something like that.
What programs do you use to search through the file frame by frame? I normally use VLC for everything however I can't seem to find an option to do that.

Also if there was a program that could number the frame you're looking at that would be awesome. I wanna start looking at energy twister more closely (hence all the ET crit gear in profile, and holy hell crit maras with ET are expensive)
@Loroese:
The assumption is that there's one crit roll for every LoH tick (which translates to a certain number of damage ticks).
In addition and mostly unrelated there's a periodic roll for CM that occurs every 3 or maybe 6 frames and can only succeeed if the frame it hits already is a crit.
As Nubtro put it:
So to simplify the result, at 1.50 aps the game performs the following actions each 30/aps = 20 frames:

1. LoH recovery, which means you get a health globe/bar response
2. AP cost, which means you get a AP globe response
3. rolls its RNG for a critical hit and if you crit
-> you gain resource from APoC
-> all 19 subsequent frames until the next "check" will crit

In case of CM, the game checks each 3 frames for a crit. This means that if you didn´t roll a crit on the determining AP response frame, you would get zero CM procs during the subsequent 19 frames (20 total) but if you did roll a crit, you might get 6-7 CM procs withing those 20 critting frames (very unlikely because of the proc coefficient).


But that doesn't fit 100% either ;)

@BDF: View -> Extended Control (or something like that) makes 4 additional buttons pop up. The last of those is "one frame forward". Don't click too fast, or it will skip frames.
Thanks apo. That's mostly what I thought, except the CM checking more often than the crit roll. Does that mean every crit tic rolls against the spell coefficient to proc CM, or is it one roll for each crit for the next few frames?

In the end that part should average out though so it's really the same as just checking on a tic by tic basis, I think. I suppose if I had time I could write a short monte-carlo type code to analyze the expected CM proc rate for a lot of WW casts.

If you don't mind, let me see if I have it straight for how a WW cast will work out. Let's say it's 2.51 APS so 33 LoH tics per WW or 5.5 per second. That would be something like 5 LoH tics for first second, 6 for next second, repeat. That translates into 12 frames per LoH tic for the first second, 10 for next, 12 for third, 10 for 4th, 12 for 5th, and 10 for 6th. That also assumes there's no initial 6 frame duration like with RoF (if I'm remembering that correctly).

First second:
Frame 1: roll for crit, if successful then 12 frames crit and you proc APoC
roll for CM, if successful then CM rolls for procs for current and next 2 frames
Frame 4: reroll for CM if crit was successful in frame 1
Frame 7: reroll for CM if crit was successful in frame 1
Frame 10: reroll for CM if crit was successful in frame 1
Frame 13: roll for crit, if successful then 10 frames crit and you proc APoC
roll for CM, if successful then CM rolls for procs for current and next 2 frames
Frame 16: reroll for CM if crit was successful in frame 13
Frame 19: reroll for CM if crit was successful in frame 13
Frame 22: reroll for CM if crit was successful in frame 13
Frame 26: roll for crit, if successful then 12 frames crit and you proc APoC
roll for CM, if successful then CM rolls for procs for current and next 2 frames
same behavior for first 60 frames
...
Frame 61: roll for crit, if successful then 10 frames crit and you proc APoC
roll for CM, if successful then CM rolls for procs for current and next 2 frames
Frame 64: reroll for CM if crit was successful in frame 61
Frame 67: reroll for CM if crit was successful in frame 61
Frame 70: reroll for CM if crit was successful in frame 61, if successful then Frames 71 and 72 roll for CM even if Frame 71 doesn't roll a crit?
Frame 71: roll for crit, if successful then 10 frames crit and you proc APoC
roll for CM
Frame 74: reroll for CM if crit was successful in frame 71
Frame 77: reroll for CM if crit was successful in frame 61
Frame 80: reroll for CM if crit was successful in frame 61, if successful then Frames 71 and 72 roll for CM even if Frame 81 doesn't roll a crit?
repeat through Frame 120, then repeat from Frame 1 for duration of WW.

That's assuming CM rolls every 3 frames. If it's every 6 frames instead it's the same idea and the interesting points occur around Frames 71, 81, etc. Specifically they occur when the duration of the next set of crit frames is not the same as the remainder of the duration of the LoH frame. Basically you have a crit roll with just 1 LoH frame left, so what happens? Do you still roll the CM chance for the next 3 frames, or just for 1 frame? If it is the next 3 frames, do you still check if the tic crits to see if CM procs or can it then proc without a crit if that 1 previous frame was a crit?

I wonder if our answer lies in there somewhere. I think a simple monte-carlo code could determine the differences between the possibilities. It's also possible that in the end it all averages out and the real difference in CM procs vs expected lies elsewhere.
Loroese you understand the LoH and crit portion right. Game checks for LoH ticks at a (floor(30/aps)) frequency and on the same frame it determines whether it crits (you get APoC) or doesn´t. If it crits, all subsequent damage ticks will be crits until the next check.

That part is verified, but we still don´t understand the exact mechanics behind the CM proc frequency. It would be really helpful if you could run a simulation and input various CM check frame lengths/other models.

The "check each 3 frames" was my initial theory based on my first test where most CM procs at 50% CC were separated by a number of frames divisible by 3 (for example 6, 12, 18).
http://us.battle.net/d3/en/forum/topic/8770117237?page=6#104

CRITICAL MASS
+9+9+6+26(27)+55(54)+23(24)+10(9)+9+22(21)+1(3) close to CD end
and
203475 crit 112/145 AP regen CM proc(+12)
198967 crit 112/145 CM proc(+11)
196100 crit 114/145 CM proc(+7)
195280 crit 114/145 CM proc(+2)
191183 crit 116/145 CM proc(+10)
186267 crit 116/145 CM proc(+12)
183809 crit 117/145 CM proc(+6)
176434 crit 119/145 CM proc(+18)
171517 crit 120/145 CM proc(+12)
170697 crit 120/145 CM proc(+2)
166600 crit 122/145 CM proc(+10)

But if the game was really checking for CM each 3 frames, then you´d get 20 checks per second. With 75% crit chance and a 0.333 proc coefficient that would give me 4.995 CM procs per second, but the best I got was 3.6484 average CM procs per second and the worst average CM procs value was 2.7047/sec.
http://us.battle.net/d3/en/forum/topic/8770117237?page=7#138
which TekkZero confirmed to be very accurate results
http://us.battle.net/d3/en/forum/topic/8770117237?page=7#140

By reverse calcing those values (/0.75/0.333) you get 14.61 CM checks for best breakpoint and 10.83 CM checks for the undesirable breakpoint. In frame length, that is 60/14.61 = 4.11 frames per check and 60/10.83 = 5.54 frames per check.

What else we do know about the behaviour is that breakpoints that don´t give you a remainder after dividing by 6 are undersirable as they were proven to give you the least CM procs per second values. I don´t understand how exactly the frame length of LoH checks correlates with CM procs, but there seems to be some sort of connection.
So the idea would be something like this:

Test different CM frame lengths (3,4,5,6, maybe others).
At each frame length, check for a crit. If crit exists, roll against spell coefficient for CM proc.

Then look at various scenarios such as check CM for each crit over that length or check CM for each tic over that length regardless of crit or just 1 check for CM for that length.

If I have time soon I can write a quick code to test that and then compare number of CM procs per WW averaged over a large number of casts for various breakpoints.

One thing I need to know still is how do the LoH tics occur for the breakpoint I mention above (2.51). Does it alternate between 10 frames and 12 frames between LoH tics, does it instead alternate every second, or is it just 11 frames per tic and one more tic at the end since 60/11*6 = 32.7 but we know there's 33 tics. That would mean you have 32 tics of length 11 frames and 1 final tic of length 8 frames. My guess is this is the case.

I'm starting to wonder if maybe it just checks for CM every 6 frames and if a crit is there and CM passes, it just procs CM once. That would be somewhat consistent with our results that we seem to be overestimating CM procs by a factor of 4-6 if we just try to apply the damage tics to CM, so one check every 4-6 tics would work out to be about what we observe. It could also explain the differences with breakpoints since you might get "extra" CM checks when the frame lengths don't overlap with the LoH lengths.

One thing we could do is calculate the expected number of CM checks vs crit checks (i.e., LoH tics) for the breakpoints. We expect the ratio to be somewhere around 2.5 at high APS. We could check to approximate the actual ratio using the same SA tests I did before, namely fight ghom with just WW and Storm Armor with no rune and compare effective dps with a second test using WW and Storm Armor and SA. The difference in effective dps should be due to SA and you can calculate the number of WW casts by Time*APS. You can easily back calculate the average damage of SA as DPS*0.35/APS and determine the number of SA hits and then compare how many SA procs you get per WW cast. Based on the CM results we should see a noticeable difference in SA procs around the 2.31 and 2.5 breakpoints.
06/28/2013 12:08 AMPosted by Loroese
Let's say it's 2.51 APS so 33 LoH tics per WW or 5.5 per second. That would be something like 5 LoH tics for first second, 6 for next second, repeat. That translates into 12 frames per LoH tic for the first second, 10 for next, 12 for third, 10 for 4th, 12 for 5th, and 10 for 6th.

No, the other way around. LoH ticks are always 11 frames, which leads to 5.4545 ticks per second which leads to 33 ticks total (rounded up from 5.4545 * 6 = 32.7273).

And I'm pretty sure that if CM checks occur at frame 1 of channeling and then periodically after X frames, that won't fit Nubtro's test results with the significantly lower procrates at 12/18/24 frame breakpoints.
The chance of a CM check hitting a crit tick should not be affected by tick length.

If instead the checks always occur at the first frame of a group of crit frames and then periodically after X frames, that's a whole different story.
In that case, if for example checks happen every 6 frames and a LoH tick is 12 frames long: The first CM check is at frame 1, the second at frame 7 and the third... doesn't happen. If the tick was 13 frames long instead, you'd get 3 chances.
That should result in something very similar to the test results, but still not fitting 100%. If only because Nubtro has already seen two CM procs with only 3 frames between them. So it can't check every 6 frames only. But it can't check every 3 frames either, because a) that would result in far too many procs and b) we then should see drops at 9/15/21 frames breakpoints as well.

Hope that makes sense to anyone.
06/28/2013 10:39 AMPosted by apo
No, the other way around. LoH ticks are always 11 frames, which leads to 5.4545 ticks per second which leads to 33 ticks total (rounded up from 5.4545 * 6 = 32.7273).


That's what I was thinking recently. For WW that means 32 tics of 11 frames and one last tic of only 8 frames for the 33 tic case.

06/28/2013 10:39 AMPosted by apo
And I'm pretty sure that if CM checks occur at frame 1 of channeling and then periodically after X frames, that won't fit Nubtro's test results with the significantly lower procrates at 12/18/24 frame breakpoints.


06/28/2013 10:39 AMPosted by apo
If instead the checks always occur at the first frame of a group of crit frames and then periodically after X frames, that's a whole different story.


Yeah, this second idea seems like it would better follow the results. I'm mainly throwing ideas out and not having much chance to think over them in detail as of yet. I was also thinking the same thing about the 3 frames per CM idea since you don't see the CM decrease at 15 or 9 frame lengths, or at least not as much of a difference at 15 compared to 12 or 18.

However, if he's already observed multiple CM procs inside 3 frame length then my idea above of one check and one possible proc doesn't really hold. If the CM procs are always at least 3 frame lengths apart then it still could hold but I don't see why 15 would be any different from 12 or 18. The idea of one proc per CM length is just my idea of a possible answer that could match what we've already observed and otherwise I have no idea what could be going on to cause the differences in CM procs between observed and expected. The carry over seems too minor to make a huge impact since we're observing about 20-30% of the CM procs as expected based on the crit checks and if CM checked on every frame that has a crit.
Is it so far fetched to think that we are simply uncovering the algorithms used to display in a discrete number of frames mechanics that take place under the hood that we don't have a way to directly measure?
no, actually it could be pretty much that as theyre just able to measure whats being displayed by the graphics... but there could be many more operations that dont send any info to be displayed.
06/28/2013 11:05 AMPosted by BDF
Is it so far fetched to think that we are simply uncovering the algorithms used to display in a discrete number of frames mechanics that take place under the hood that we don't have a way to directly measure?

But we can measure what happens on screen. And then we can deduct what happens under the hood. And then we can predict what happens on screen if we change variables.

That's what we did for LoH. First we just tried out and measured what life return we get, using different APS values. Then over time the Excel list of life return values evolved into a set of formulas that can accurately calculate the life return for any given APS and LoH value.

And that's basically what we're trying to do for CM now. Nubtro took care of the testing part, now we're looking for a formula or algorithm to match the data.
06/28/2013 10:10 AMPosted by Loroese
One thing I need to know still is how do the LoH tics occur for the breakpoint I mention above (2.51). Does it alternate between 10 frames and 12 frames between LoH tics, does it instead alternate every second, or is it just 11 frames per tic and one more tic at the end since 60/11*6 = 32.7 but we know there's 33 tics. That would mean you have 32 tics of length 11 frames and 1 final tic of length 8 frames. My guess is this is the case.

Wait I thought this was common knowledge around the Wiz forums beucase you researched Wicked Wind so much. You get the whole length of the last tick. The formula for total number of ticks is

ceil(360/(floor(30/aps)))

Basically for example if you have 17 frame long checks you´d get 22 of them, so 374 frames total. I just tested to confirm and got 373 frames total, which is pretty accurate. It´s almost impossible to get a steady 60 fps for such a long duration so the result you view ingame will be off by a couple of frames.
Thanks Nubtro. I know about the formula but I had never heard or read about how the last tic was treated. So what you're saying is we don't actually get 33 tics over 6s but over 6.05s. That's 3 extra frames which could mean some extra CM procs.

On a side note does that mean WW does 252/363 damage per frame or is it 252/360 damage per frame? It's not a lot of difference but makes me curious.
From my understanding and tests that I´ve done, damage per frame and total number of frames are two separate calcs, so it is 0.7% weapon damage each frame. In your example of >2.50 aps, you should get 363 frames each dealing 0.7% weapon damage, so 254.1% total damage.

Btw. it´s "ticks" not "tics", right? The latter is when someone is nervous/has an illness and his/her face muscles twitch ;)
06/28/2013 03:21 PMPosted by Loroese
Thanks Nubtro. I know about the formula but I had never heard or read about how the last tic was treated.
That's where the ceil() in the total ticks calculation comes from. We never looked at the implications for total damage, but for LoH procs it was always clear that there is a last tick even if it doesn't fit into the remaining frames.
And yes that does potentially mean some additional procs. I'd say that effect is noticeable only for very low attack speeds and/or low DoT/channeling duration. But WW has a relatively low duration, so it might even make a difference.

I will probably try to build a basic simulator in Perl tomorrow.
From my understanding and tests that I´ve done, damage per frame and total number of frames are two separate calcs, so it is 0.7% weapon damage each frame. In your example of >2.50 aps, you should get 363 frames each dealing 0.7% weapon damage, so 254.1% total damage.

Btw. it´s "ticks" not "tics", right? The latter is when someone is nervous/has an illness and his/her face muscles twitch ;)


Cool, that's just what I wanted to know. It's a very minor difference but things like that always make me curious.

As for tics vs ticks, I don't know. I use tic in MATLAB all the time so that might be why I use it. tic toc tic toc...
Okay now. I did some Perl scripting.
Uploaded it to codepad.org
You can read, edit and - most importantly - run it there. Use the "fork" link, edit whatever you want and make sure the "run code" checkbox is ticked.
Don't laugh at my coding skills, I'm just a sysadmin :P

First and less promising idea was this:
http://codepad.org/gG1wLWky

It's basically filling an array with "frames" that are either normal, crit or crit+proc.
The way this first try works is that it's first building up a series of crit and non-crit frames as per the rules we already know (crits rolled once per LoH tick, duration will be extended if the last LoH tick is not finished). Then afterwards it's going through the list again, just checking for procs with a fixed interval. So if the check interval is 6 frames, it's starting at frame 1. If it's a crit, it rolls for a proc. Then it's checking at frame 7, if it's a crit, it rolls for a proc. And so on.

Sample output:
++++++*+++++------------------------*+++++++++++++++++++++++------------------------++++++++++++------------

------------++++++*+++++++++++*+++++------------------------*+++++++++++++++++*+++++------------++++++++++++

Frames (total): 216
Critframes (total): 108
Crits (total): 9
Procs (total): 6

Frames (avg): 108
Critframes (avg): 54
Crits (avg): 4.5
Procs (avg): 3

Procs / Sec (avg): 1.66666666666667

This was for 50% crit, 0.333 proc coef, 12 frames LoH tick length, 6 frames proc check interval, 100 frames of channeling and doing test 2 times.
The "graph" is not particularly useful, but it is a good quick check to see if the algorithm produces somewhat plausible results.

And here's the values I used to replicate Nubtro's testing as accurately as possible:
75%cc, RoF proc coef, 25 seconds of channeling and averaging everything over 100 iterations.
I executed this for LoH tick lengths of 8 to 25 frames.
And for CM check lengths of 3 and 6.

Here's the avg. number of procs per second for each case:
#frames <-> procs/s (3 frames check) <-> procs/s (6 frames check)
08 4.981 2.508
09 5.014 2.463
10 4.996 2.514
11 5.027 2.492
12 4.945 2.471
13 5.053 2.501
14 4.948 2.521
15 5.037 2.505
16 4.899 2.469
17 5.007 2.552
18 4.992 2.501
19 4.983 2.524
20 5.040 2.499
21 5.045 2.462
22 5.060 2.513
23 5.030 2.525
24 5.032 2.571
25 5.056 2.510


As expected this didn't work out very well. With 3 frames CM check intervals it's always ~5 procs/s, with 6 frames check interval it's 2.5 procs/s.
So LoH tick length is largely irrelevant and there is no way to explain Nubtro's "jumpy" results, except if the CM check length was variable. (Scaling with what? How? Why?)

So off to my second idea:
http://codepad.org/d7xiGVEu

The difference to the first one is that here, after rolling for a crit it will start with the first frame of that particular LoH tick and roll for a proc. Then continue to do so in fixed intervals until the LoH tick is over. Then for the next crit LoH tick it will do that again.

So again trying to get as close to Nubtro's testing as possible:
75%cc, RoF proc coef, 25 seconds of channeling and 100 iterations. LoH tick lengths of 8 to 25 frames. CM check lengths of 3 and 6.

#frames <-> procs/s (3 frames check) <-> procs/s (6 frames check)
08 5.689 3.787
09 4.946 3.354
10 6.026 2.942
11 5.458 2.730
12 5.077 2.504
13 5.775 3.495
14 5.363 3.247
15 5.006 3.001
16 5.645 2.823
17 5.297 2.680
18 5.092 2.518
19 5.532 3.229
20 5.336 2.967
21 5.054 2.859
22 5.489 2.709
23 5.213 2.634
24 5.002 2.479
25 5.475 2.971


Now that looks a bit better.
It's easier when looking at the graph:
http://i.imgur.com/GK9k1Ko.png
Red is the first algorithm with 3 frames check length, green with 6 frames check length. Those are flat lines -> not interesting.
Purple is the second algorithm with 3 frames check length, light blue with 6 frames.
Dark blue is Nubtro's data.

So my second try with 6 frames check length is already pretty damn close I'd say. But there's one thing that still doesn't quite fit: In the test data there's a very distinct local max at 17 and 11 frames which I can't explain.

Thoughts? Any ideas on what to add or change? Any mistakes in the code?
loh was easier to model because we got more procs every breakpoint.

This is an entirely different beast, we are actually getting less procs on some breakpoint transitions.

1.50001 - 1.57894 19 3.5018 CM procs
1.57895 - 1.66666 18 2.6667 CM procs
For example, having the tick cycle end on frame 19 is producing a +31.1% rate of cm procs. This is a frame that occurs 3.157 times a sec; a frame number shared by 5.526% of frames. That would mean 19 is giving us a 0.264 proc every time we land on it.

So converting 5.526% of frames from 'bad divisible by 6 frames' to 'good' is yielding +31.1%. hmmm

2.14286 - 2.30769 13 3.5811 CM procs
2.30770 - 2.50000 12 2.7883 CM procs
For example, having the tick cycle end on frame 13 is producing a +28.4% rate of cm procs. This is a frame that occurs 4.615 times a sec; a frame number shared by 7.692% of frames. That would mean 13 is giving us a 0.171 proc every time we land on it.

If 12 and 18 were just 'dead' frames then we would expect to see cm procs increase every additional frame until the dead one then a huge fall then a rebuild. Also if 1 in 6 frames were 'dead' then we should only see a drop of 20% at frame 6 then like 9% at frame 12, 5.8% at frame 18, 4.3% at frame 24...
Great stuff apo, I understood most of it although I have no clue about coding.

Today I bought a 9/7 mara and a 6/5 helm which brought me to supposedly 86%. There is something suspicious that I´ll try to confirm tomorrow if I win a 4.5/7 skull grasp that is bid only. 90.5% crit chance is as high as I can get. I´ve never put >40m into research gear before ._.

Anyway, here´s some of the data from today´s tests. I tried to work on some theories but simulations will probably be better.

86% crit chance RoF Cold Blood 1.69 aps Archon 120 second cooldown
(63+67) 54:28 80:22 25:54 1487 3.7996 procs/sec
(82) 22:33 48:37 26:04 1564 92.57/26:04 3.5512 procs/sec

CM procs frame difference (visual CD reduction procs on Diamond Skin icon)
frames between CM procs <-> total frames/number of procs <-> average frame difference
45-40-17-64-1-6-10-2-15-5 <-> 205/10 <-> 20.50
42-3-3-12-3-22-47-16-39-33 <-> 220/10 <-> 22.00
28-12-12-6-19-8-9-25-5-6-6-6 <-> 142/12 <-> 11.83
12-30-12-18-41-38-23-6-5 <-> 185/9 <-> 20.56
35-12-16-3-6-77-18-18-6-7-11 <-> 209/11 <-> 19.00
7-11-6-18-18-6-55-36-18-35-5 <-> 215/11 <-> 19.55
9-9-6-2-18-24-(28)-8-6 <-> 110/9 <-> 12.22
1286/72

Note that I mostly had a 58-59 fps framerate during that test.
3.7996 / .86 4.41813953488
3.5512 / .86 4.12930232558
4.12930232558 avg

less then original data:

75% >30/18 1.66800 aps 3.5018 CM procs 17 14.0320 4.2760
3.5018 / .75
4.66906666667 avg

Join the Conversation

Return to Forum