Diablo® III

CM Proc Rate (Testers needed)

Maybe we'd be better off sticking to reasonable APS values, like 1.4+. It's possible that the mechanics just breakdown at such low APS values but are more consistant at higher values.
Reply Quote
You might be right. We had bugs in almost every aspect of the game. Now why would the probably most complex mechanism in game be flawless?
However, the main reason I never went above 1.2APS , is because AP management is so much easier. My inventory and chest are already filled with tons of different speed weapons and a variety of IAS gear, so I was trying to avoid adding new APoC test equipment.

Things I promise I'll do eventually:
- Have a look at Disintegrate
- Check the relation between "CM crits" and "APoC crits". It should be possible to see if for each jump in my Archon cooldown I also get AP back. Gonna do this with RoF/CB at 1.0APS for a +/-0 AP baseline.
- Try to figure out if there's anything strange with RoF DPS at low attack speeds (too many ticks and too many crits, sooo... too much damage then?)
Reply Quote
I've done some thought on this, and I'm almost positive about this. When they nerfed the proc rate for WW, rltw, etc., I believe it was because LoH was a game-breaking mechanic with proc rates where they were.

Now, recall that they also nerfed cc at around the same time, so a mob's max cc with FN was 0.9 seconds or thereabouts. What this means is that for true permalock with CM/WW wizard, you would need to cast FN every 0.9 seconds. In order to do this, you also need to be casting 2 WW's per second. This would require 3.34 APS, assuming that there's no lag, rounding issues, that there is no delay between a crit and FN's cooldown being reduced, etc. Punch it into any simulator, it's almost impossible to achieve. Now add in human error, i.e. even with the best hotkey macro there's no way to avoid casting FN while mobs are still frozen, and you have that true 100% freeze is completely impossible.

Stay with me, guys. So if LoH is a gamebreaker, and they can't lower the LOH affix (due to existing gear), they need to nerf proc rates. However, they don't want to kill ww/rltw barbs and cm/ww wizards, so they add a multiplier into the proc rates for CM and Battle Rage/Into the Fray. My guess is the proc rate multiplier is 2.5x, rather than 2x, since that's the amount they reduced proc rates. TOTAL proc rate, however, is capped at 1. There's no reason whatsoever to believe that Magic Missile can proc CM twice with one hit. I also think that there's probably a tag applied from the skill. The goal was to keep procs the same, so only skills that received a proc nerf would receive the extra multiplier.
Edited by ZHENTIL#1643 on 2/6/2013 11:29 AM PST
Reply Quote
There's also a really easy way to test whether non-nerfed spells receive a multiplier. Take a skill which wasn't nerfed with a proc rate stictly between 0.5 and 1, and measure whether you ever get crits without CM procs.
Reply Quote
02/06/2013 11:32 AMPosted by ZHENTIL
There's also a really easy way to test whether non-nerfed spells receive a multiplier. Take a skill which wasn't nerfed with a proc rate stictly between 0.5 and 1, and measure whether you ever get crits without CM procs.


While your theory is interesting, the results already disproove it. We have results from a sig spell with under 1.0 proc rate and the results indicate the CM proc rate is working as previously expected for that. The low APS WW proc rates indicated more CM procs that damage tics for some scenarios, which really makes no sense. Also, the effective CM proc rate for WW seems to change depending on APS and CC%, so it's not a static number as far as we have seen.

Thanks for the idea though. I'm willing to hear any other ideas people might have since none of us can completely explain the behavior so far.
Reply Quote
I took a look at the data, and I've come up with a theory. I think it makes sense, but I don't have much theorycrafting experience so I could well have made a mistake somewhere. Here it is:

Channeled spells should "feel" like they're continously doing damage, even though internally they function as discrete ticks. To give this feel, they normalized the actual ticks/second to at least 10. So for a very slow weapon which should produce 2 ticks/s, you get 5 times as many ticks, but each for 1/5 the damage. But, this would mess with other mechanics like crit and LoH, so they made the sub-ticks clump together into one hit. Each "clump" procs LoH only once, and each clump only gets one roll to decide if it crits or not. If the clump rolls as a crit, every sub-tick in the clump crits, producing a spike in damage exactly as if the tick was never split.

But there's a bug: "on crit" effects get proc'ed for each sub-tick, instead of for every clump as would have been intended.

Here's my guess at what's happening:
2 ticks/s x 5 = 10 subticks/s
3 ticks/s x 4 = 12 subticks/s
4 ticks/s x 3 = 12 subticks/s
5 ticks/s x 2 = 10 subticks/s
6 ticks/s x 2 = 12 subticks/s
7 ticks/s x 2 = 14 subticks/s

Thoughts?
Reply Quote
guys, cut it out. the last thing we need is another ww nerf. don't rock the boat.
Reply Quote
@Zevzabich: This could be fairly reasonable. We could test for the actual number of clumping at each attack speed, based on estimating how much the effective crit chance is enhanced compared to a character's paper crit chance. If there is clumping, the formula I provided earlier in the thread should hold true for a character's effective crit chance:
effective cc = 1-(1-cc)^n, where n = the number of sub-ticks in a clump.
Reply Quote
The variance is killing me.

I did 2 more tests with RoF/CB @ 41.5%CC, 0.63APS:
First took my 38s to fully refresh the cooldown. Second took me 43s.

Then I did RoF/Sleet Storm (lower proc coef):
50s and 54s.

I think that means proc coefs apply as expected and are not tampered with.

I also did 2 tests with Disintegrate, which got me to 58s and... wait for it... 44s
If I use an average value, it brings me to the conclusion that our hidden mechanic is a modifier/multiplier of the tick speed values found in LoH tests. (As opposed to just replacing the tick speed values altogether)

Unfortunately, I don't have the time or energy to do every test 10 times and get some proper average values. But that apparently is the only way to get any meaningful results. So please don't take the above values (or any I've posted before) too serious.

I tried looking at APoC crits compared to CM crits, but it's just too many crits and too much movement in the AP globe. Can't really see anything. I used 9 APoC though, so it might be worth checking again with 3 (=1 AP per crit on RoF).

Also tried a quick RoF DPS test with low APS. It looks like my DPS was a bit too high (maybe 10%), so whatever phenomenon we're seeing here could also be slightly affecting DPS.
But don't take my word for it, could have been a coincidence or math fail on my part.

So basically, I still got nothing.

@Zavzabich: Thanks for your idea. I fully agree that it probably is some kind of splitting ticks or a tick speed multiplier. Not sure about the reason though. Lifepoints decreasing smoothly is a display gimmick. I'd want to smack the developer who deliberately butchered internal mechanics for this.
I was briefly thinking that your theory of clumping doesn't fit, because we would then see for example either 5 cooldown reductions in a row or none at all, but never a single one. But of course there is still the proc coefficient. So it is possible that although all ticks of a clump are crits, they don't all proc CM.
So yeah, your theory might work. No idea how to verify it though...
Reply Quote
@Zevzabich

That's as good a theory as we have at the moment, and is similar to what I have been thinking, namely that there could be a number of "damage tics" that is different from the "LoH tics". Applying your idea would simply mean the LoH tics are just a bundle of so many damage tics.

Like say there's 20 damage tics per second, regardless of APS. The damage displays based on the WW breakpoints and the displayed damage is an average of the number of tics done over that time, so if you see 2 tics per second, say at high APS, those tics are average of 10 damage tics each. In other words displayed damage is the "clump" consisting of all the damage tics since the last displayed damage. For lower APS, you don't see a tic every 0.5s so let's say you see one tic per second. Those damage displays are then the total of 20 damage tics. Let's also say that if any of those tics crits, then you get a CM proc. From that it's clear that at lower APS you're much more likely to see a CM proc, which is consistant with results seen so far. At higher APS, you have fewer damage tics per clump, so the CM multplier would be lower, though still above 1. That would also mean some sort of CC diminishing returns for CM procs, which we also are starting to expect but still needs to be analyzed further.

The LoH would still follow the WW breakpoint tic rates and each LoH tic corresponds to a clump. The only inconsistancy in the idea is I don't think the LoH tics display at the same rate as the damage is displayed at lower APS. At high APS each display at 0.5s intervals.

Does that sound like what you're talking about?

What I'd really like to get are some "effective coefficient" or CM multiplier values for various APS and CC values, with like an average over 3-5 runs or so. Then we could try to fit some of our theories to the data and see if there's a magic number of tics that makes all the numbers line up. Unfortunatelly I have very little spare time these days so I won't be able to do any testing for like 4 months.
Reply Quote
In other words displayed damage is the "clump" consisting of all the damage tics since the last displayed damage. For lower APS, you don't see a tic every 0.5s so let's say you see one tic per second.
[...]
The LoH would still follow the WW breakpoint tic rates and each LoH tic corresponds to a clump. The only inconsistancy in the idea is I don't think the LoH tics display at the same rate as the damage is displayed at lower APS. At high APS each display at 0.5s intervals.


Displaying is a mystery in itself. Not sure if this is helping, it might just confuse us even more.
A few "fun facts":
1) LoH displays up to twice per second. BUT once you reached the max number of displays, it's going down again. For WW (6s duration) it's starting at 7 displays, slowly working it's way up to 12 @ 1APS and then starting over at 7 again. Up to 12 @ 2APS, then starting at 9.
2) Some of my low APS tests in here showed damage displays occuring twice per second, even for significantly less then 2 ticks/s. Suggesting that there must be more damage ticks than we thought.
3) When you go to normal mp0 and channel on a zombie with like 8HP, you still get a full damage tick displayed. Suggesting that there are no smaller units than the previously known ticks.
4) Other classes, namely Barbs with Whirlwind or Sprint/RltW get their damage displayed right away and not summed up. When you got 4 ticks, you get 4 ticks displayed.

1) is just crazy, 2) and 3) directly contradict each other and 4) shows that for whatever reason Wizards have their own version of game mechanics.

So, yeah... I'm not sure if we should factor in displaying at all.
Reply Quote
02/07/2013 10:37 PMPosted by apo
So, yeah... I'm not sure if we should factor in displaying at all.


but but but.... If breaking up the display into an even amount of 'subticks' isn't whats happening, why the hell would they even subdivide ticks to begin with? There has to be a reason to make it so convoluted.
Reply Quote
@apo, when I was playing with the numbers, worries about variance were nagging me in the back of my head the whole time. Would certain test methods make the variance better or worse? I also wonder about the quality of the random numbers - getting a large quantity of quality random numbers is surprisingly hard, and I could only imagine how quickly a D3 server goes through them.

@Loroese, slightly different details than what I was thinking, but yeah exactly the same concept.

@apo, nice collection of facts. I think the display numbers are somewhat disconnected from the internal ticking mechanism - like you say, I think factoring it in could be a mistake.

Point #1 makes me think display numbers are throttled to prevent too many from flooding the screen and making it illegible. The spikey behaviour you describe is consistent with a relationship like:
subticks/display = ceiling((subticks/s)/(max displays/s))

The only way I can think of that would make point #2 and #3 compatible is if all the subticks in a clump occur regardless of whether the monster dies partway through the clump or not. But why would they do that? At first glance anyways, it makes no sense. Is it to make LoH and other non-crit procs work as expected? If we could get two CM procs off an 8 hp zombie, it would prove a lot. I might take a shot at that tonight.

@Shandlar, my guess would be to disconnect ticks from display numbers. At 2 ticks/s, it would work but at 7 tick/s it would become an illegible fountain of numbers. More subticks would also help time the monster's death properly at slow tick rates, and help the client smooth the health bar animation. But regardless, yeah it's definitely convoluted. Like apo said, "I'd want to smack the developer who deliberately butchered internal mechanics for this" lol.

Of course all of this is just wild speculation. Unfortunately I have much more thinking/playing with numbers time than in-game time so I'm not the best tester. My lack of high-crit and high-as gear hurts too.

Now I'm starting to wonder if the subticks/s actually sit between your aps and LoH ticks/s, and our current understanding of aps breakpoints are just a (correct) simplification of what's actually going on under the hood. I'll play with that theory a bit more and post back if it pans out at all.
Reply Quote
but but but.... If breaking up the display into an even amount of 'subticks' isn't whats happening, why the hell would they even subdivide ticks to begin with? There has to be a reason to make it so convoluted.

Well, I'm not a Blizzard insider. But designing mechanics just to fit a certain displaying form would be pretty stupid.
It is certainly possible to make health bars look like they seamlessly decrease, although damage is applied in fixed intervals. And I guess it is in Blizzard's best interest to keep the damage/health calculations (server-side (hopefully)) as simple as possible while letting the client handle any pretty GUI effects.
Actually, I'm quite sure they are doing just that. When you look at a monsters health while channeling, it changes with every frame. That would be at least 30 (my current video recording framerate), probably even 60 "ticks" per second. Much more than even the craziest tests in here suggest.

I'm pretty sure we won't find the reason for the mechanics being as they are, before figuring out how it actually works. WW breakpoints didn't make any sense either. I remember being incredibly confused. Why in god's name would anyone design such a progression system? Until people came up with the algorithm based on frame length of single ticks. And now it makes perfect sense.

02/08/2013 07:54 AMPosted by Zevzabich
Point #1 makes me think display numbers are throttled to prevent too many from flooding the screen and making it illegible.

Ever seen a Whirlwind Barb? ;-)
WW plus around 4 RltW tornados each ticking at around 3*APS in fact are flooding the screen. That's what I meant to say with #4. Apparently, preventing loads of damage numbers occuring on screen is not a universal design decision.
Edited by apo#2677 on 2/8/2013 2:39 PM PST
Reply Quote
Ever seen a Whirlwind Barb? ;-)
WW plus around 4 RltW tornados each ticking at around 3*APS in fact are flooding the screen. That's what I meant to say with #4. Apparently, preventing loads of damage numbers occuring on screen is not a universal design decision.


Not to mention shocking aspect....
Reply Quote
So... I guess we won't get any more awesome ideas or volunteers for hundreds of testing runs...

Findings summary:
1. CM sometimes procs around 1.5 to 15 times more than it should
2. The "bonus" procs probably scale down with higher attack speed and maybe crit chance

Not our best work :(
Edited by apo#2677 on 2/11/2013 2:22 PM PST
Reply Quote
Gonna dig this up once again.
Inspired by the APoC discussion, I did another test with RoF.

Proc coef of 1/3
3 APoC = 1 AP per crit
5% crit chance
1 APS
Cold Blood rune
10 base AP reg

Channeling RoF, casting any other spell inbetween to bring down my AP pool.
This got me to a situation where my AP pool continuously went "20, 21, 22, 23, 24, 25, 20, 21, 22, ..." (mouseover tooltip)
Numbers change around once in 1/10 of a second. So the AP globes "display resolution" should be quite a bit faster than the tick rate of RoF.

So I observed my AP gains.
For the first 30 seconds or so, I got a single AP point. So I was at 21-26 AP.
Then things got weird.
The AP display jumped from 26 back down to 23. Which basically means I got 2 AP in a fraction of a second.
But there's more. One second later, My AP pool jumps from 28 (new max) down to 25. That's 2 above the previous min value, so I gained 2 AP once again.
Ten seconds later, 30 to 27
Five seconds later, 32 to 29
Two seconds later 34 to 30

Simplified timeline:
20, 21, 22, 23, 24, 25, 21, 22, 23, 24, 25, 26, 23, 24, 25, 26, 27, 28, 25, 26, 27, 28, 29, 30, 27, 28, 29, 30, 31, 32, 29, 30, 31, 32, 33, 34, 30, 31, 32, 33, 34, 35, ...

So I regularly get 2 AP, but not always. There's several problems with that...
2 crits in a row at 5% CC? Regularly? Yeah right.
So did they double APoC gains? Nope. Seen AP gains of 1, too
Is the crit RNG broken? Maybe. But still, I got 2 AP within around 3 frames of my video, while RoF should tick only twice per second.

In fact, I can see it does tick twice per second. My AP jumping up and down is actually RoF ticks. Every tick costs 5 AP, they occur every half second. That's why my regeneration (10 per second) brings me up by 5 and then I lose a chunk of 5 again.

And I can see a clear correlation between APoC gains an RoF ticks - There is never an unexpected AP gain during my AP regeneration phase. It's always directly after reaching the current max - exactly when the actual tick occurs.

I'm gonna say something is broken. It's completely insane.

[edit] Did the same test with 6 APoC and got returns of 4 AP only. I did this to verify if there is a different proc coef for APoC. Because the 3 APoC scenario could be explained by a proc coef above 1/3 and below 2/3 (i.e. calculated AP return of 1.X -> actual AP return of 1 and 2 alternating).
If this was the case, depending on the actual coef, I should see AP returns of 2+3, 3 or 3+4 at 6 APoC.
If it was unrelated to the proc coef and just randomly doubling the AP returns, I would see 2+4.
Unfortunately, I don't see any of the above -.- It's always 4 AP, no less.

I really want to talk to a dev right now.
Edited by apo#2677 on 2/27/2013 2:24 PM PST
Reply Quote
I'm trying to understand your data. Basically you broke up the time into 0.1s segments? So every 0.1s you gain 1 AP from passive regen, then every 0.5s you use 5AP from the cast, plus regain 1-2 AP, supposedly from APoC. Does that sound right? So when you go from 25 to 21 you only gain 1 AP from APoC, but when you go from 26 to 23 you gain 2?

Shoulden't it be more like 25 to 21 means 0 APoC return (-5 AP from spell, +1 from regen)? Then the 26 to 23 means you proced APoC (-5 from spell, +1 from regen, +1 from APoC)? Or am I misunderstanding the timeline?
Reply Quote
Sorry, I can see how that's confusing.
The listed values in my timeline are what I see in the mouseover tooltip of my AP globe. It's just a chronological list of AP values.
And I skipped all periods where no APoC was procced. So actually it would look more like
20, 21, 22, 23, 24, 25, 20, 21, 22, 23, 24, 25, 20, 21, 22, 23, 24, 25, 21, 22, 23, 24, 25, 26, 21, 22, 23, 24, 25, 26 etc.

So it's always +5 regen and -5 per tick during half a second. Which leads to something like you can see above - constantly going up and down between 20 and 25.
Now when I add APoC, this changes to a slow increase of AP. Whenever ApoC gets procced (an event that always occurs together with the 5 AP cost tick), I gain either 1 or 2 AP. So I don't fall down from 25 to 20 as expected, but to 21 instead (or 22, if I gain 2 AP).

Hope this clears things up a little.

PS: See my edit above, I repeated the test with 6 APoC.
Edited by apo#2677 on 2/27/2013 2:48 PM PST
Reply Quote
02/27/2013 01:52 PMPosted by apo
I really want to talk to a dev right now.


Wyatt Cheng himself is watching the class forums even posted in DH, you probably just gave him more fuel for a nerf fire! :P

Although it would be good if he commented on this. "Hey guys when I nerfed you guys, I nerfed you but didn't really nerf you"

-.-

I think this is a recent change, maybe even that they did on purpose to start testing apoc synergies. Something happened in 1.07 to make it easier on ranged wizards, but since you cannot really program what a ranged wizard and a CM wizard has for skills maybe they just changed the entire CM equation instead of messing with skill's proc co-efficient for the 100th time.
Reply Quote

Please report any Code of Conduct violations, including:

Threats of violence. We take these seriously and will alert the proper authorities.

Posts containing personal information about other players. This includes physical addresses, e-mail addresses, phone numbers, and inappropriate photos and/or videos.

Harassing or discriminatory language. This will not be tolerated.

Forums Code of Conduct

Report Post # written by

Reason
Explain (256 characters max)
Submit Cancel

Reported!

[Close]