[UPDATED] Barrage/CoC Mechanics: There Is No Optimal Attack Speed (but high attack speed is okay)
RePosting here so we can consolidate all of our information for people who want to test Barrage in the future.
The following assumes what most of the other posters in the thread have stated: that Barrage has attack speed "breakpoints." depending on attacks/second (aps), projectiles are spaced at different intervals (>.05 seconds, >.25seconds, >.16seconds). At each breakpoint you will experience a huge jump in spells cast/Barrage. In my own testing, Barrage had a "breakpoint" of 2.05 aps... I have found an old forum post by user SFTRUZE which helps us analyze how many CoC spells are procced at certain barrage projectile spacings. What you have here is a table which shows every possible permutation of CoCspell per barrage projectile. Each of these permutations has a %chance of happening (calculated with lv20 CoC gem), which is shown in the J column (it totals up to 1 and therefore must be correct). I have added in my experimental breakpoint values (2.05 aps, 4.10 aps) and you can see how many spells you are casting per second. You can input your own found breakpoint numbers instead, and find the actual optimal aps. Click here: average # of spells cast per Barrage, depending on what breakpoint you have
Spoiler
Each point in column B-I represents a barrage gmp projectile. If that projectile casts a spell, then a "1" is marked. In column K it basically adds up the number of spellcasts you get for that permutation (assuming CoC can trigger on every projectile). In column L it adds up the number of spellcasts you get if the spacing between each barrage projectile is under .05 seconds (so only every other projectile can proc a CoC spell). The numbers in column L are roughly 1/2 as large as the numbers in column K, obviously (although some of the values are less than 1/2 b/c of the way a permutation might occur) In column M you have number of spells cast if you can only proc CoC once every 3 projectiles (so each projectile hits an enemy between .025s and .016s apart). Column L and column M were not generated by formulas, someone went through by hand and counted the amount of spells possible with each permutation! From there, you multiply your APS by the average # of spells cast for the corresponding breakpoint, and you can find the optimal aps. In the top left corner I have written in yellow the average # of spells you can possibly cast with lv20 CoC if you have .05second or more spacing between each barrage projectile. And under that, the average # of spells cast with lv20 CoC with .25 seconds - .05 seconds between each barrage projectile hit. Basically you can multiply your attackspeed by the average # of spells cast, assuming you know which breakpoint bracket your attackspeed lies in. Then, that value gives you the average # of spells cast / second. In green, I have made my remarks assuming that 2.05aps is the breakpoint aps for >.05 seconds between each projectile. (a value that I tested myself) tl'dr if breakpoint system exists, then your spells cast/second will spike at different values of aps. it is not a linear progression and you benefit from having the highest attacks/second for your specific breakpoint bracket. Disclaimer: In my testing I have never been able to proc 8 SRS. According to that spreadsheet I should have a 5.7% chance of proccing 8 SRS with lvl20 CoC, as long as I'm under the "breakpoint" I claimed. Which makes me start to believe that the breakpoint system may no longer apply to barrage- but there is no reasonable explanation for how barrage works, in that case. People stick to the breakpoint explanation b/c its the only one that makes sense. Your own data reveals no breakpoint, either. If a breakpoint existed, you should see a HUGE spike in spells cast/sec at the breakpoint aps. Also, it would have to be a jump from <4 spells/cast to >5 spells/cast. But you experienced a linear increase, which is the most damning evidence against the breakpoint theory. Barrage may have some other magical mechanism of determining projectile spacing, it may be randomized, or it may increase/decrease at different aps in an unexplained way. B/c of the previous evidence, I'm thinking that Barrage projectile spacing is NOT linear (i.e. if 2.05 aps -> 0.05s projectile spacing, then 4.1 aps must have 0.025s projectile spacing). but instead the projectile spacing is exponential (i.e. if 2.05 aps -> 0.05 projectile spacing, then 4.1 aps -> some spacing other than 0.025s, maybe it's 0.03 seconds or even higher) Mirror Arrow Summoner: https://www.pathofexile.com/forum/view-thread/1422529 Teleports Behind You: https://www.pathofexile.com/forum/view-thread/2123293 Magma Orb Deadeye: https://www.pathofexile.com/forum/view-thread/2736039 Last edited by dariidar#0631 on Sep 8, 2015, 12:32:28 AM
|
![]() |
Here's some simple python simulation code:
https://gist.github.com/Fruglemonkey/66a2fb42bd527b4c654f Feel free to play/tweak with it to test your theories. (Or validate my logic) Last edited by Fruglemonkey#3216 on Sep 8, 2015, 12:51:14 AM
|
![]() |
You are doing some great work here, thank you for your effort!
|
![]() |
If you want to know the attack speed thresholds of the barrage + CoC mechanics, you should look at the max proc per crit, not the mean proc per crit: the activation threshold of CoC makes it impossible to proc twice in a row when you get above this threshold, so the max proc per crit will be the clearest way to know the thresholds. Then, you can see what happens with the mean proc per crit at these attack speed values.
My wild guess is there is a windup time of 40% of your attack time after each use of barrage, but also something close to a 1% of your attack time before the attack. In theory, passed the first threshold, a proc can't occur once after each hit that procs, so the observed max proc per crit is multiplied by 0.5, assuming you get a large enough sample. But this is also assuming the enemy is not coming to you and thus reducing the elapsed time between each hit. So, in practice, as the Barrage damage is generally low enough not to stun the enemy, the threshold is always lowered by a factor of the enemy movement speed. Maybe a knockback effect or increased projectile speed could mitigate this a tiny bit (in addition to give more survivability against melee mobs)? Now I get a question about game mechanics: does the crit evasion (the evasion test that occurs when a hit that crits has been landed successfully) procs per hit or per attack? If it procs per hit (which I assume it is, because I don't see how it would work otherwise if the hits would occur on enemies with different evasion values), then even with 95% of chance to hit, you only get around 66% of chance for all your critical attack hits to actually crit (and thus have a chance to proc CoC). So that would be less than 4% of chance to get 8 procs in a row, even before the first threshold. I also don't take into account the fact that, in practice, all Barrage projectiles need to trigger the enemy hitbox in order to have a chance to hit. PS: for clarity purpose, I need to add that my blabbering about evasion and hitbox is not about the methodology used, but about Barrage + CoC effectiveness in general matter. Last edited by Talenk#2994 on Sep 8, 2015, 5:45:23 AM
|
![]() |
" Per hit. |
![]() |
This makes me wonder if more attack speed and no GMP might be good.
I did a very brief not at all scientific test of this though, and GMP still seems to work better because of the windup. |
![]() |
Windup and average number of procs per crit are both better: with a 70% of chance to proc due to CoC, you have more than 80% of chance to get more than 4 procs per crit with GMP (most of the time, you will get 5 to 7 procs per crit). Without GMP, you have most of the time 2 to 4 procs and at most 4 procs per crit, obviously.
edit: thanks, Vipermagi. Last edited by Talenk#2994 on Sep 9, 2015, 2:31:21 AM
|
![]() |
what's the tldr version of this. having a tough time following the rational. Is there a "sweet spot"? is there a cap? is there diminishing returns?...etc
|
![]() |
Hello, I've started playing after being away for 1.5yrs and decided after coming back to try building a coc build. Since this is the most recent post about barrage-coc mechanics that shows up on google I'ma necroing it.
I did some quick excel math with the following assumptions, barrage requires a 40% windup, so it is only firing 60% of the time, and coc has a 0.05s cooldown, during which time it cannot be triggered again. What I am looking for was if there was an attack speed I would not want to go over with barrage. Here is a simplified table of my theorycrafting. aps-barrage attacks per second bps-bolts fired with barrage+gmp per second proc/8 how many times the bolts can proc per group of 8 proc/s theoretical maximum number of coc procs per second(note the numbers are slightly off from my big table to simplify the math but the difference is negligable) coc95-80%: is the expected number of coc fires based of the bps, using 95-80% accuracy and critical strike chance. (Apperently 95% is the highest achievable if your critting) Math for this was a simple per bps*accuracy*critchance*accuracy*cocchance. Max 69%coc chance was used always. ![]() ![]() Reading the graph: the grey line is your maximum coc procs you can get, the other lines depending on your setup is how many procs you can expect on average, not putting the coc cooldown into consideration. Of course being above proc/s line is ideal. (attacks per second x axis, procs per second y axis) Some takeaways. 1. The max number of coc's you can get off with barrage is going to be 12. This is because even with perfect coc/accuracy/critchance since 40%of each second you are not firing(note fire rate does not effect the 40% of each second) with a 0.05s cooldown the most bolts you can fire is 12. 2. The biggest drop in procs/s is from 1.5-1.6 aps. 3. Above 3aps, you can actually much easier get your max proc/s because every third shot can proc but at high coc% if one doesn't the next shot can still get you the 3 procs/8 bolts. So in conclusion how many attacks per second do I want? Probably as many as possible. |
![]() |