Cast on Critical Strike Trigger Rate being calculated incorrectly

[VekiaCH]

Check version

• [X] I'm running the latest version of Path of Building and I've verified this by checking the changelog

Check for duplicates

• [X] I've checked for duplicate issues by using the search function of the issue tracker

Check for support

• [X] I've checked that the behaviour is supposed to be supported. If it isn't please open a feature request instead (Red text is a feature request).

What is the behaviour in-game?

As cast on crit is very hard to analyze in game, I'll just explain how it feels. In game I have 52% Cooldown Recovery Rate, so I should be hitting the 10.10 trigger breakpoint. When fighting a boss, it definitely feels like I'm triggering the skill about 10 times as second, but it's hard to tell.

What is the behaviour in Path of Building?

Since version 2.33.0, the trigger rate of Forbidden Rite has changed from the theoretical 10.02 in 2.32.2 to 5.35 (see screenshot or 1st PoB). The Calcs section lists the trigger cap at 10.10 as it should and it states my source rate is 10.02, but the skill trigger rate is set to 5.35. The only way I've "fixed" it, is by giving myself a custom modifier of 500% increased cooldown recovery rate (2nd PoB). This raises the trigger cap to 30.3 and now the trigger rate is fixed.

How to reproduce the issue

I've tried other spells in my setup and they all have the 5.35 trigger rate.

Character build code

https://pobb.in/kh4qpYAJDmQF (no custom CDR)

https://pobb.in/A6GJY4GoAsHG (500% custom CDR)

Screenshots

[Paliak]

The skill rotation simulation thinks you're missing a trigger window. Not sure exactly why that is the case yet.

[VekiaCH]

From this reddit post: https://www.reddit.com/r/PathOfExileBuilds/comments/160p1bm/pob_233_coc_trigger_calculations/

I have been tinkering with the POB and discovered some very weird things. Here are some screenshots with slight tweaks to the build.

https://imgur.com/a/yeiC2Sv

Basically` slightly under trigger cap doesn't work, but slightly exceeding it seems to fix it. From what I've read about CoC, I thought exceeding it is what's supposed to drop your dps/trigger rate.

Might be a weird case of rounding/inverted cutoff?

[Paliak]

The issue here is that i'm not 100% sure that that the activations are aligned with server tick rate.

Using the build you linked without the extra CDR as the base here.

Starting at T = 0 FR is triggered and goes on a 0.09868421052631579 long cooldown. Next attack will be at 0.0998003992015968 so FR will be off cooldown at that point so it will trigger again.

The behavior most people seem to expect is that there's no rounding to the next tick here. And T is independent from server tick rate.

Currently T is dependent on server tick rate so 0.0998003992015968 is rounded to the next server tick and that would be at T = 0.132

[VekiaCH]

So theoretically you'd want your next attack to be before 0.099 but if it's faster than the cooldown, then you'll miss the trigger all together, so what you actually want is more cooldown recovery, probably 1-2% to make sure the spell is up and your attack speed actually higher than the trigger cap, in this case 10.10?

[Paliak]

That seems correct to my understanding but please remember that i'm just an ape with a keyboard. I just implement things according to what i think is right which may not be correct.

[VekiaCH]

If that's true, then that's insane, because then all the rule of thumbs people know about CoC trigger rates would be inverted. The rule of thumb being that slightly passing the breakpoint with APS would almost half your damage and that you'd want to be exactly at the breakpoint or below it. This means anyone following this was halving their damage.

[VekiaCH]

Ignore closure, fat fingered on phone.

[VekiaCH]

The issue here is that i'm not 100% sure that that the activations are aligned with server tick rate.

Using the build you linked without the extra CDR as the base here.

Starting at T = 0 FR is triggered and goes on a 0.09868421052631579 long cooldown. Next attack will be at 0.0998003992015968 so FR will be off cooldown at that point so it will trigger again.

The behavior most people seem to expect is that there's no rounding to the next tick here. And T is independent from server tick rate.

Currently T is dependent on server tick rate so 0.0998003992015968 is rounded to the next server tick and that would be at T = 0.132

So what's changed now in PoB's math is it's accounting for server tick rounding of the attack trigger?

[Paliak]

In terms of triggers basically everything. The reduction in trigger rate is caused by the skill rotation taking server tick rate into account but it's also considering more factors than i can remember and i wrote the all of the trigger related code myself so yeah.

[VekiaCH]

So I've adjusted the PoB: https://pobb.in/5d1QydNwnFLG and now it triggers as intended with 10.12 attacks per second and 53% cooldown recovery rate.

T0 Attack: 0 FR CD: 0.09803921568627450980392156862745 T1 Attack: 0.09881422924901185770750988142292

FR is up before next attack which is before next server tick, so it works, makes sense.

Next PoB: https://pobb.in/LSgQ4sYj_mOM with 10.17 APS and 53% CDR.

T0 Attack: 0 FR CD: 0.09803921568627450980392156862745 T1 Attack: 0.09832841691248770894788593903638

FR is up before next attack which is before next server tick, so it works... No wait it doesn't my damage is almost halved again. This makes no sense.

Next PoB: https://pobb.in/WiHr9Gge8bPk with 10.13 APS and 53% CDR.

T0 Attack: 0 FR CD: 0.09803921568627450980392156862745 T1 Attack: 0.09871668311944718657453109575518

FR is up before next attack which is before next server tick 6.06 trigger rate, so faster than above, but still not right.

I'm so confused.

[Paliak]

Same here. We're wondering whether we could be running into floating point precision issues.

[Soulbinder]

Hi, not sure if this info will help, but I'll share just in case:

I stumbled upon the issue of the perceived skill trigger rate increase for my CwC build. I traced the issue to be connected to the hit chance of the triggering skill (cyclone in my case).

If I give myself -17 accuracy rating the skill trigger rate goes UP to 3.03 (from 2.71).

I do not understand the calculation that leads from eff. source rate to skill trigger rate. But getting higher skill trigger rate when decreasing accuracy seems fishy to me. In case this could be helpful for debugging, here is the link https://pobb.in/SVi45tpLjtqQ

[Paliak]

@Soulbinder Are you talking about the manabond mjonnier setup or your main CwC setup? It seems your main setup is completely broken as arc isn't even counting as being triggered. The trigger rate of the manabond setup could be a part of the problem we're discussing here as chance to hit is applied as a modifier to source rate.

[Soulbinder]

I looked at the manabond mjölner setup, indeed. The arc not being counted as triggered... seems to be something else.

[ConKou]

It doesnt seem to be dependent only with attack speed. In your pob you provide a custom one with 500% ICDR to fix the issue. I have round it down to 76% where it is you get the full value once again. You don't need to to 500%. I don't know exactly why this happens but here's the findings.

dif	cdr	trigger rate	dif
	0	5.35
53	53	5.68	0.33
4	57	5.87	0.19
4	61	6.27	0.4
5	66	6.49	0.22
5	71	6.99	0.5
5	76	10.02	3.03

[ConKou]

There's also this inaccurate / non linear representation of the CDR need to reach the next breakpoint, much like in #6481.

52% base CDR + 0% extra from custom config https://pobb.in/c9qlPrXAtEdH

52% base CDR + 75% extra from custom config https://pobb.in/1i5fnklkRhFO

52% base CDR + 76% extra from custom config (reaching the unreachable by normal in-game means 128% CDR and hitting the next breakpoint of 15.15 triggers per second) https://pobb.in/zA-XJMI_TBDx

I don't know why the skill trigger rate using the skill rotation simulation is problematic but the "next CDR breakpoint" tooltip innacuracy might be a tip to the solution?

[VekiaCH]

So, I think I have the answer, if this is how the math is programmed and if I've understood everything. Check out this giraffe based on the original PoB https://pobb.in/kh4qpYAJDmQF

https://www.desmos.com/calculator/4kvrnlifn0

Legend: Red: Server Ticks Green: Attack Hits Blue: Spell Trigger

Basically, after the first hit at 0 seconds, the next attack hit gets squished to the next server tick at 0.132 instead of 0.099 (Spell is already off cooldown), so we trigger the spell a tick late. Then the next attack in green hits at the beginning of the tick and the spell comes off cooldown (purple dashed line) at the end of the tick, both get squished to the next tick and trigger as normal. Every trigger after this one triggers exactly on the "tick-box" the attack is in. The next X triggers until the next miss will trigger as normal. X = 0.033 / (0.0998003992015968 - 0.099) which is about 41 triggers until we miss another tick, aka every ~4 seconds, we'll miss a trigger. Meaning we have perfect trigger rate 10.10 for 4 seconds, we miss 1 trigger, then it's back to perfect again. This is how I think it works.

What I believe is being calculated, is that the attack rate (not HIT) is being squished to the next tick, when it should stay like the green lines in the graph, meaning we miss a trigger every other hit (~50% damage loss).

[Paliak]

The formula for the extra ICDR needed is:

local modActionCooldown = cooldownOverride or m_max((triggeredCD or 0) / icdr + (output.addsCastTime or 0), ((triggerCD or 0) / icdr ))

local rateCapAdjusted = actor.mainSkill.skillData.ignoresTickRate and modActionCooldown or m_ceil(modActionCooldown * data.misc.ServerTickRate) / data.misc.ServerTickRate
local extraICDRNeeded = m_ceil((modActionCooldown - rateCapAdjusted + data.misc.ServerTickTime) * icdr * 1000)

[VekiaCH]

Is this correct for not perfect 10.06 aps? So does this mean that it must be only 10.10, and any other factor that will affect attack speed with reduce trigger rate from 10.10 to 5.35 or something?

It should be the other way around no? If you only attack 10.06 per second, you should be slower than the spell cooldown, meaning you'll always just be casting late. If you have over 10.10 aps, then you'll miss spells every other hit, because they're not off cooldown yet. Like the top graph looks like 10.15 aps.

[ConKou]

So, I think I have the answer, if this is how the math is programmed and if I've understood everything. Check out this giraffe based on the original PoB https://pobb.in/kh4qpYAJDmQF

https://www.desmos.com/calculator/4kvrnlifn0

Legend: Red: Server Ticks Green: Attack Hits Blue: Spell Trigger

Basically, after the first hit at 0 seconds, the next attack hit gets squished to the next server tick at 0.132 instead of 0.099 (Spell is already off cooldown), so we trigger the spell a tick late. Then the next attack in green hits at the beginning of the tick and the spell comes off cooldown (purple dashed line) at the end of the tick, both get squished to the next tick and trigger as normal. Every trigger after this one triggers exactly on the "tick-box" the attack is in. The next X triggers until the next miss will trigger as normal. X = 0.033 / (0.0998003992015968 - 0.099) which is about 41 triggers until we miss another tick, aka every ~4 seconds, we'll miss a trigger. Meaning we have perfect trigger rate 10.10 for 4 seconds, we miss 1 trigger, then it's back to perfect again. This is how I think it works.

What I believe is being calculated, is that the attack rate (not HIT) is being squished to the next tick, when it should stay like the green lines in the graph, meaning we miss a trigger every other hit (~50% damage loss).

Love the graph. Agree to your conclusions. I used a different approach. Mapped the sequence of ticks on a spreadsheet and calculated when the cooldown comes off, when attacks hit and how they both interact for the first 17 attacks. https://docs.google.com/spreadsheets/d/1OfNJKc-lAtl6FW4eKJUvDI2QHndkJxN237Vp1oVTS_4/edit?usp=sharing Here's the spreadsheet. Sorry if I represented it as shit, it works though.

My conclusion is that the first attack is delayed and hits at the 0.132 (4th) tick, but after that it works fine. The skill cdr is less than the attack rate, so it almost always comes off cooldown on the same tick as the attack cooldown is ready and again almost always refreshes the cooldown some milliseconds before the attack cooldown is ready. I don't know how PoE treats having both the attack cooldown and the trigger cooldown coming off on the same tick, I suppose there's no problem here. A final note. The reason I say almost always is because I have done a limited simulation of only 17 attacks. In the graph the other guy posted, there's some formulas and a conclusion that after some seconds that we loose a trigger at some point and then the cycle starts anew. This is kinda supported by my own limited simulation as well. Columns J or N trace the variance of the difference in time, between when an attack is ready and the tick rate. Like you said, each attack cooldown is 0.099800399201596 and that doesn't fit perfectly into eack tick. For example the second attack goes off at 0.199503... which goes into the 0.231 tick whic has a 0.031496... time difference. So these differences of tick rate - attack cooldown, are not always the same and there's some variance, as show in columns J or N. From there I assume that the conclusion the other guy, that at some point we loose a trigger, is correct.

That doesn't seem to be a big issue though. Losing 1 trigger each 4 seconds, so each 40 triggers is almost non-existent DPS loss.

All in all, that post is to approve of my fellow contributor's hypothesis about how it actually works. Now I'm gonna look into why the rotation seems to break and not work.

[PaintMasterPoE]

Is this correct for not perfect 10.06 aps? So does this mean that it must be only 10.10, and any other factor that will affect attack speed with reduce trigger rate from 10.10 to 5.35 or something?

It should be the other way around no? If you only attack 10.06, you should be slower than the spell cooldown, meaning you'll always just be casting late. If you have over 10.10 aps, then you'll miss spells every other hit, because they're not off cooldown yet.

Wait, im braindead, then its for something like 10.12 or 10.15, or just faster than 10.10, not slower. I fixed that image. So then if its a bit below 10.10 it should be fine, and definitely not 5.35 like in pob

[VekiaCH]

So, I think I have the answer, if this is how the math is programmed and if I've understood everything. Check out this giraffe based on the original PoB https://pobb.in/kh4qpYAJDmQF https://www.desmos.com/calculator/4kvrnlifn0 Legend: Red: Server Ticks Green: Attack Hits Blue: Spell Trigger Basically, after the first hit at 0 seconds, the next attack hit gets squished to the next server tick at 0.132 instead of 0.099 (Spell is already off cooldown), so we trigger the spell a tick late. Then the next attack in green hits at the beginning of the tick and the spell comes off cooldown (purple dashed line) at the end of the tick, both get squished to the next tick and trigger as normal. Every trigger after this one triggers exactly on the "tick-box" the attack is in. The next X triggers until the next miss will trigger as normal. X = 0.033 / (0.0998003992015968 - 0.099) which is about 41 triggers until we miss another tick, aka every ~4 seconds, we'll miss a trigger. Meaning we have perfect trigger rate 10.10 for 4 seconds, we miss 1 trigger, then it's back to perfect again. This is how I think it works. What I believe is being calculated, is that the attack rate (not HIT) is being squished to the next tick, when it should stay like the green lines in the graph, meaning we miss a trigger every other hit (~50% damage loss).

Love the graph. Agree to your conclusions. I used a different approach. Mapped the sequence of ticks on a spreadsheet and calculated when the cooldown comes off, when attacks hit and how they both interact for the first 17 attacks. https://docs.google.com/spreadsheets/d/1EC9773gSK0QWNTYQp89-SKXN93ZS7Ulfekip_YlYuIE/edit?usp=sharing Here's the spreadsheet. Sorry if I represented it as shit, it works though.

My conclusion is that the first attack is delayed and hits at the 0.132 (4th) tick, but after that it works fine. The skill cdr is less than the attack rate, so it almost always comes off cooldown on the same tick as the attack cooldown is ready and again almost always refreshes the cooldown some milliseconds before the attack cooldown is ready. I don't know how PoE treats having both the attack cooldown and the trigger cooldown coming off on the same tick, I suppose there's no problem here. A final note. The reason I say almost always is because I have done a limited simulation of only 17 attacks. In the graph the other guy posted, there's some formulas and a conclusion that after some seconds that we loose a trigger at some point and then the cycle starts anew. This is kinda supported by my own limited simulation as well. Columns J or N trace the variance of the difference in time, between when an attack is ready and the tick rate. Like you said, each attack cooldown is 0.099800399201596 and that doesn't fit perfectly into eack tick. For example the second attack goes off at 0.199503... which goes into the 0.231 tick whic has a 0.031496... time difference. So these differences of tick rate - attack cooldown, are not always the same and there's some variance, as show in columns J or N. From there I assume that the conclusion the other guy, that at some point we loose a trigger, is correct.

That doesn't seem to be a big issue though. Losing 1 trigger each 4 seconds, so each 40 triggers is almost non-existent DPS loss.

All in all, that post is to approve of my fellow contributor's hypothesis about how it actually works. Now I'm gonna look into why the rotation seems to break and not work.

Glad we came to the same conclusion. Our hypothesis only works though if the attack hit itself doesn't reset after being squished to the upcoming tick. If that's how it actually works, then CoC builds will have been doing a lot less DPS (unless they have perfect aps or higher within 1 tick) than they did on PoB, which I feel is highly unlikely due to how many people play CoC builds. Especially high end CoC builds like Ice Spear Occultist would definitely feel losing ~25m of their 60m dps.

[ConKou]

Glad we came to the same conclusion. Our hypothesis only works though if the attack hit itself doesn't reset after being squished to the upcoming tick. If that's how it actually works, then CoC builds will have been doing a lot less DPS (unless they have perfect aps or higher within 1 tick) than they did on PoB, which I feel is highly unlikely due to how many people play CoC builds. Especially high end CoC builds like Ice Spear Occultist would definitely feel losing ~25m of their 60m dps.

I certainly aggree that losing so much DPS is feelable but there's also confirmation bias and is not exactly like every person has a machine like understanding of the difference between 60m and 35m DPS. With cycling damage reduction and other AN mods there's a chance changes to DPS like that are not easily spotted by feeling.

But I don't quite understand why would that loss happen. Wdym "if the attack hit itself doesn't reset after being squished to the upcoming tick"?

[VekiaCH]

Glad we came to the same conclusion. Our hypothesis only works though if the attack hit itself doesn't reset after being squished to the upcoming tick. If that's how it actually works, then CoC builds will have been doing a lot less DPS (unless they have perfect aps or higher within 1 tick) than they did on PoB, which I feel is highly unlikely due to how many people play CoC builds. Especially high end CoC builds like Ice Spear Occultist would definitely feel losing ~25m of their 60m dps.

I certainly aggree that losing so much DPS is feelable but there's also confirmation bias and is not exactly like every person has a machine like understanding of the difference between 60m and 35m DPS. With cycling damage reduction and other AN mods there's a chance changes to DPS like that are not easily spotted by feeling.

But I don't quite understand why would that loss happen. Wdym "if the attack hit itself doesn't reset after being squished to the upcoming tick"?

Basically look at my graph and copy the first 4 ticks repeating. Basically 0.099 cd turns into 0.132 cd because you restart from a "0 second" trigger, but I can't fathom that attack hits would work that way, otherwise every attack would be some inverse multiple of 0.033 or attack ticks per second.

Basically the next attack hit would be 0.0998003992015968 seconds after the trigger, not 0.0998003992015968 seconds after the last attack.

[PaintMasterPoE]

Fixed image. Now it should be correct right? Anything above 10.10 will make spell trigger only every second attack, or 5.05 like it shows right now in PoB. But if its a bit lower than 10.10, then it will trigger every attack as well but at some point it will brick and then trigger every attack again. Or its more than just attack rate and it must be ONLY 10.10, and cant be a bit lower?

[ConKou]

Basically the next attack hit would be 0.0998003992015968 seconds after the trigger, not 0.0998003992015968 seconds after the last attack.

Hmm yeah ok I get it. This is bad then? According to the wiki.

It reads like the next attack cooldown would start at the 0.132 point of time.

[ConKou]

The behavior most people seem to expect is that there's no rounding to the next tick here. And T is independent from server tick rate.

Currently T is dependent on server tick rate so 0.0998003992015968 is rounded to the next server tick and that would be at T = 0.132

Kinda like Paliak said here. We came full circle, didn't we?

[VekiaCH]

Basically the next attack hit would be 0.0998003992015968 seconds after the trigger, not 0.0998003992015968 seconds after the last attack.

Hmm yeah ok I get it. This is bad then? According to the wiki.

It reads like the next attack cooldown would start at the 0.132 point of time.

Do attacks have a cooldown? I'm not sure they're treated the same as spells. Also if this ends up being the case, then we just reverse our earlier thoughts and just overcap attack speed without hitting a whole tick earlier. This behaviour isn't reflected in PoB either. So I'm still quite unsure.

If attacks are different, then the actual hit of Cyclone, for instance, can be in raw time and then it's snapped to server tick time when it comes to the damage calculation step, then we still get my original graph.

At this point, when I get off work, I'm going to load into campaign with a 0 damage cast on crit setup (probably frostbolt linked to void manipulation, slower projectiles) and count the spells per second and just see what reality looks like.

[VekiaCH]

Fixed image. Now it should be correct right? Anything above 10.10 will make spell trigger only every second attack, or 5.05 like it shows right now in PoB. But if its a bit lower than 10.10, then it will trigger every attack as well but at some point it will brick and then trigger every attack again. Or its more than just attack rate and it must be ONLY 10.10, and cant be a bit lower?

Correct, this is how (at least what we've thought up until right now) it works.

[Paliak]

Really appreciate the discussion. I'll be sure to go through all of it. My only suggestion would be to not use POB as a source of truth but merely my (Paliak's) understanding of the trigger mechanics at this point in time.

[VekiaCH]

Really appreciate the discussion. I'll be sure to go through all of it. My only suggestion would be to not use POB as a source of truth but merely my (Paliak's) understanding of the trigger mechanics at this point in time.

Yeah I believe a lot of us have gotten so used to how good PoB is at accurately predicting your character that most us stopped asking if it actually worked that way. Nothing written on PoB matters if it doesn't function that way in game. I'll definitely try to get some gameplay evidence tonight.

[ConKou]

Do attacks have a cooldown? I'm not sure they're treated the same as spells. Also if this ends up being the case, then we just reverse our earlier thoughts and just overcap attack speed without hitting a whole tick earlier. This behaviour isn't reflected in PoB either. So I'm still quite unsure.

If attacks are different, then the actual hit of Cyclone, for instance, can be in raw time and then it's snapped to server tick time when it comes to the damage calculation step, then we still get my original graph.

Yep that's the conclusion I was reaching now as well. If attacks do indeed function that way, then we just increase our attack speed so that attack time matches the server tick just below. So with numbers, we increase the pob attack speed by 2% with custom modifiers, attacks per second go from 1.43 1.84 3 1.27 = 10.02 to 1.43 1.86 3 1.27 = 10.13 and attack time goes from 1 / 10.02 = 0.099800... to 1 / 10.13 = 0.098716... which fits into the 0.099 tick and doesn't go to 0.132. Then assuming trigger cdr AND attack coming off cooldown at the same tick, are both ready to go, then we don't lose triggers.

Correct?

If it's correct then we don't loose damage, we just need to figure out how attacks ACTUALLY work and adjust our trigger rate accordingly.

Edit: pob in reference https://pobb.in/E2hdNrfFHfOb

[VekiaCH]

Yep that's the conclusion I was reaching now as well. If attacks do indeed function that way, then we just increase our attack speed so that attack time matches the server tick just below. So with numbers, we increase the pob attack speed by 2% with custom modifiers, attacks per second go from 1.43 1.84 3 1.27 = 10.02 to 1.43 1.86 3 1.27 = 10.13 and attack time goes from 1 / 10.02 = 0.099800... to 1 / 10.13 = 0.098716... which fits into the 0.099 tick and doesn't go to 0.132. Then assuming trigger cdr AND attack coming off cooldown at the same tick, are both ready to go, then we don't lose triggers.

Correct?

Exactly. Fixing it isn't a big deal, but being wrong costs a lot of DPS.

[ConKou]

So how do we get that info? Relying on real time testing is very prone to error with such small numbers. Does anyone here have any pull with GGG and can get a dev from there to answer? Or idk, link those discussions somewhere in the forums and hope for a reply?

[VekiaCH]

So how do we get that info? Relying on real time testing is very prone to error with such small numbers. Does anyone here have any pull with GGG and can get a dev from there to answer? Or idk, link those discussions somewhere in the forums and hope for a reply?

I'm sure LocalIdentity has some connections, but I actually believe we can get some good results from testing in game. Basically we just hold down cyclone on a mob in the campaign for about and minute and count every single frostbolt that was spawned. We repeat this with different attack speeds around the trigger rate (9 aps, 10.10 aps, 11 aps, etc.) and compare it with what PoB has. We just have to make sure the character has 100% critical strike chance all the time and can't deal any damage to the mob and doesn't die to it either in that time (Southbound + no elemental damage (void manip)+ frostbolt.

The worst case situation would be that nothing matches up with any assumptions or server lag invalidates the test.

[ConKou]

The worst case situation would be that nothing matches up with any assumptions or server lag invalidates the test.

That's the thing. You would need Lockstep with very low ping to be accurate, no? I think just getting a GGG answer would be the best. Also I suppose spell hits doing the triggering would be the same, right, RIGHT? For example instead of cyclone, using Lightning Ball.

[VekiaCH]

The worst case situation would be that nothing matches up with any assumptions or server lag invalidates the test.

That's the thing. You would need Lockstep with very low ping to be accurate, no? I think just getting a GGG answer would be the best. Also I suppose spell hits doing the triggering would be the same, right, RIGHT? For example instead of cyclone, using Lightning Ball.

I play on lockstep with about 20ms ping, so I don't think that's an issue. I imagine you don't mean using CoC since CoC only supports attacks as the trigger.

[ConKou]

I play on lockstep with about 20ms ping, so I don't think that's an issue. I imagine you don't mean using CoC since CoC only supports attacks as the trigger.

No I was talking about my own problem which is figuring out Impending Doom triggers, which is another separate pain in the ass. But still, the triggering there is being done a Curse being removed which is wacky to say the least. It's not a hit (attack or spell). There's another nuance there, so let's not delve in that thread here, there's another one I made #6481.

So from there I got curious, if for some other triggers, spell hits or even non-hits, are treated the same as attack hits for the purposes of snapping to tick rate or not.

[ConKou]

The formula for the extra ICDR needed is:

local modActionCooldown = cooldownOverride or m_max((triggeredCD or 0) / icdr + (output.addsCastTime or 0), ((triggerCD or 0) / icdr ))

local rateCapAdjusted = actor.mainSkill.skillData.ignoresTickRate and modActionCooldown or m_ceil(modActionCooldown * data.misc.ServerTickRate) / data.misc.ServerTickRate
local extraICDRNeeded = m_ceil((modActionCooldown - rateCapAdjusted + data.misc.ServerTickTime) * icdr * 1000)

To work on this at the same time, can I get some clarification as to what some variables do?

cooldownOverride

what is this?

triggeredCD

is the final cooldown of the trigger?

icdr

is 0.52 or 1.52 for 52% CDR?

output.addsCastTime

is what? The base cast or attack time for the skill doing the triggering?

actor.mainSkill.skillData.ignoresTickRate

what value does this have? Is it boolean or numerical?

data.misc.ServerTickRate

is 0.033?

[Paliak]

Sorry i just copied it over straight from the code.

cooldownOverride - is a hard override of cooldown. I think it's only used for https://www.poewiki.net/wiki/Endless_Misery

triggeredCD - is the cooldown of the triggered skill. For forbidden right it's nil for other skills it's their cooldown.

icdr - 1.52 for 52% . Default is 1.

output.addsCastTime - is used for Lightning Conduit and other skills which add their cast time to cooldown if triggered.

actor.mainSkill.skillData.ignoresTickRate - boolean. In lua syntax

actor.mainSkill.skillData.ignoresTickRate and modActionCooldown or ...

is a short hand for "if ignoresTickRate is true take modActionCooldown other wise take ..." used to disable tick rounding on cooldown. Basically the flag i forgot to set for Doom Blast.

data.misc.ServerTickRate - is ServerTickRate = 1 / 0.033

[ConKou]

local modActionCooldown = cooldownOverride or m_max((triggeredCD or 0) / icdr + (output.addsCastTime or 0), ((triggerCD or 0) / icdr ))

there's 2 variables here with almost same name, one on the first argument of m_max and one on the second

triggeredCD 

triggerCD 

Are those supposed to be the same? If not, what is the value of triggerCD ?

Edit: Also data.misc.ServerTickRate = 0.033 OR data.misc.ServerTickRate = 1 / 0.033 = 30.303030... ?

[Paliak]

triggeredCD is the cooldown of the triggered skill

triggerCD is the cooldown of the trigger

data.misc = {
    ServerTickTime = 0.033,
    ServerTickRate = 1 / 0.033,
}

[VekiaCH]

I have returned with gameplay tests. I have to leave in a few minutes, so I can't check the videos myself. Hopefully one of you can figure it out. I noticed that after ~18 seconds of spinning there's a gap in the frostbolts in both videos. Might be the missed tick with 10.12 aps.

PoB below has 52% cdr and 10.12 aps, according to PoB that's 5.51 trigger rate. https://pobb.in/s5RXUvefSZXo

Me testing proc rate with the above PoB. Video

PoB below has 54% cdr (swapped belt) and 10.12 aps, 10.10 trigger rate according to PoB https://pobb.in/D60JAYCvXt_a

Me testing proc rate with the above PoB. Video

[ConKou]

Edit: That's about the reamining CDR display issue. So for this example here, Forbidden Rite.

modActionCooldown = nil or m_max((nil or 0) / 1.52 + (nil or 0), (((0.15 / 1.52) or 0) / 1.52)) = m_max(0 + 0, 0.06492...) = 0.06492...

local rateCapAdjusted = FALSE and 0.06492... or m_ceil(0.06492... * (1 / 0.033)) / (1 / 0.033) = m_ceil(1.96738...) / (1 / 0.033) = 0.066

local extraICDRNeeded = m_ceil((0.06492... - 0.066 + 0.033) * 1.52 * 1000) = m_ceil(48.xxxx) = 49

So at 52% cdr, the function computes to 49% but on pob it displays 50% needed. https://pobb.in/NGJEzSGR-h_U

At 62% cdr, the function computes to 40% but on pob it displays 44% needed. https://pobb.in/FHqF8rkw9euD

I don't know if theres any more calcs involved here where the results of the function gets subtracted from another number, but anyway, pob display numbers are off compared to what the function returns.

Even so, even if the numbers displayed on pob would be the same, the result is wrong. The next breakpoint should be at 128% cdr. So:

For the case of 52% cdr the function should return 128-52 = 76 needed For the case of 52% cdr the function should return 128-62 = 66 needed

So again it seems like there's 2 issues. A display issue, which I have no idea about and a mechanical issue. This one needs testing, I'll check the formula now for a bit. Just posted to leave the data presented here.

[ConKou]

I have returned with gameplay tests. I have to leave in a few minutes, so I can't check the videos myself. Hopefully one of you can figure it out. I noticed that after ~18 seconds of spinning there's a gap in the frostbolts in both videos. Might be the missed tick with 10.12 aps.

So I plugged the pob values into my sim spreadsheet and checked the videos a bit. In both pobs you actually have more attack speed than your original at the start of your first post (from better base atsp, no action speed but a lot more % inc), so results should be taken with context in mind.

PoB below has 52% cdr and 10.12 aps, according to PoB that's 5.51 trigger rate. https://pobb.in/s5RXUvefSZXo

Me testing proc rate with the above PoB. Video

With this pob, trigger cooldown is 0.09868..., attacks per second are 10.125 and attack cooldown (or attack time) is 0.09876... Both are lower than the tick at 0.099. So wether attacks have true cooldown or they snap to the closest tick rate, the results would be almost the same. That is consistent in my spreadsheet, we never lose a trigger in the 17 hits simulation I have. (spredsheet link is just for testing purposes, the numbers need to be plugged in and checked as I test with it constantly)

In pob though the Skill Trigger Rate is 5.51, like something is broken. That's kinda weird, because the recent change in PoB assumed snapping to the closest tick rate and even if that happens, as proven above, it still wouldn't matter in this case.

The behavior most people seem to expect is that there's no rounding to the next tick here. And T is independent from server tick rate.

Currently T is dependent on server tick rate so 0.0998003992015968 is rounded to the next server tick and that would be at T = 0.132

Even if that is true, current T would be 0.09876... and rounding to the next server tick it would do to the 3rd tick at 0.099 and not the 4th tick at 0.132. So why in the pob skill trigger rate, is halved? I don't know.

PoB below has 54% cdr (swapped belt) and 10.12 aps, 10.10 trigger rate according to PoB https://pobb.in/D60JAYCvXt_a

Me testing proc rate with the above PoB. Video

With this pob, what changes is, trigger cooldown, which goes to 0.0974..., Attacks per second are the same at 10.125 and attack cooldown (or attack time) same again at 0.09876... Both are lower than the tick at 0.099. Also like the previous pob, the cooldown of the trigger, is still faster than the cooldown of the attack. Again, whether attacks have true cooldown or they snap to the closest tick rate, the results would be almost the same.

Now pob shows Skill Trigger Rate of 10.1, like it should.

Both cases have the same characteristics:

1) Trigger cooldown less than attack cooldown 2) Both trigger and attack cooldown are less than the tick rate of 0.099

We have been assuming the snapping to the closest tick rate was the problem that broke pob but here it's proven that's not the case. It's also consistent in the video from initial watching. I didn't sit and count every individual frostbolt, but in both videos, Frostbolt firing frequency seems to be the same. So why in the first case pob breaks while it doesn't in the second, while both cases are 99% the same, I don't know.

In conclusion. In the videos, with the according pobs, there's not a correct setup to differentiate between attack cooldown being lower / higher than the 0.099 tick, because in both cases it is lower. But, in the process, we found out that pob doesn't work the same for 2 seemingly same situations. Whether attack cooldown snaps to tick rate or has true cooldown, remains unknown and also pob, doesn't seem to work the same when it should.

[VekiaCH]

I have returned with gameplay tests. I have to leave in a few minutes, so I can't check the videos myself. Hopefully one of you can figure it out. I noticed that after ~18 seconds of spinning there's a gap in the frostbolts in both videos. Might be the missed tick with 10.12 aps.

So I plugged the pob values into my sim spreadsheet and checked the videos a bit. In both pobs you actually have more attack speed than your original at the start of your first post (from better base atsp, no action speed but a lot more % inc), so results should be taken with context in mind.

PoB below has 52% cdr and 10.12 aps, according to PoB that's 5.51 trigger rate. https://pobb.in/s5RXUvefSZXo Me testing proc rate with the above PoB. Video

With this pob, trigger cooldown is 0.09868..., attacks per second are 10.125 and attack cooldown (or attack time) is 0.09876... Both are lower than the tick at 0.099. So wether attacks have true cooldown or they snap to the closest tick rate, the results would be almost the same. That is consistent in my spreadsheet, we never lose a trigger in the 17 hits simulation I have. (spredsheet link is just for testing purposes, the numbers need to be plugged in and checked as I test with it constantly)

In pob though the Skill Trigger Rate is 5.51, like something is broken. That's kinda weird, because the recent change in PoB assumed snapping to the closest tick rate and even if that happens, as proven above, it still wouldn't matter in this case.

The behavior most people seem to expect is that there's no rounding to the next tick here. And T is independent from server tick rate. Currently T is dependent on server tick rate so 0.0998003992015968 is rounded to the next server tick and that would be at T = 0.132

Even if that is true, current T would be 0.09876... and rounding to the next server tick it would do to the 3rd tick at 0.099 and not the 4th tick at 0.132. So why in the pob skill trigger rate, is halved? I don't know.

PoB below has 54% cdr (swapped belt) and 10.12 aps, 10.10 trigger rate according to PoB https://pobb.in/D60JAYCvXt_a Me testing proc rate with the above PoB. Video

With this pob, what changes is, trigger cooldown, which goes to 0.0974..., Attacks per second are the same at 10.125 and attack cooldown (or attack time) same again at 0.09876... Both are lower than the tick at 0.099. Also like the previous pob, the cooldown of the trigger, is still faster than the cooldown of the attack. Again, whether attacks have true cooldown or they snap to the closest tick rate, the results would be almost the same.

Now pob shows Skill Trigger Rate of 10.1, like it should.

Both cases have the same characteristics:

1. Trigger cooldown less than attack cooldown
2. Both trigger and attack cooldown are less than the tick rate of 0.099

We have been assuming the snapping to the closest tick rate was the problem that broke pob but here it's proven that's not the case. It's also consistent in the video from initial watching. I didn't sit and count every individual frostbolt, but in both videos, Frostbolt firing frequency seems to be the same. So why in the first case pob breaks while it doesn't in the second, while both cases are 99% the same, I don't know.

In conclusion. In the videos, with the according pobs, there's not a correct setup to differentiate between attack cooldown being lower / higher than the 0.099 tick, because in both cases it is lower. But, in the process, we found out that pob doesn't work the same for 2 seemingly same situations. Whether attack cooldown snaps to tick rate or has true cooldown, remains unknown and also pob, doesn't seem to work the same when it should.

Good that we're on the same page, this test was to prove cdr wasn't the issue. I'll be home in about a half hour and my next two setups will be too slow aps and too fast aps (faster than the skill cooldown).

[ConKou]

So again it seems like there's 2 issues. A display issue, which I have no idea about and a mechanical issue. This one needs testing, I'll check the formula now for a bit. Just posted to leave the data presented here.

I have my own fix for the CDR needed for next breakpoint. This is not about the display issue, it's just a formula on how to reliably find it. I did it using my own logic. I haven't tried to understand the logic behind cooldownOverride and rateCapAdjusted. So my way uses data and variables that you already have or are easily accessible, but don't use cooldownOverride and rateCapAdjusted. If there's is a need for that, I can try to solve it, but for now here's my solution / explanation.

I use:

• triggerCD as the orignial value (base cooldown of the trigger)
• data.misc.ServerTickTime as the original value = 0.033
• icdr as the original value (for example 1.52 for 52% cdr)
• triggerCDcurrent as a new variable which is the CURRENT cooldown of the trigger
• currentTickRate as a new variable which is the tick rate breakpoint we are currently
• desiredTickRate as a new variable which is the next tick rate breakpoint we want to go to
• nextcapCDR as a new variable which is the next cdr breakpoint we want to go to
• extraCDRneeded as a new variable which is the extra cdr we currently need for the next breakpoint

I will also use different functions to show step by step how it works. We can do it all in a single big function but it would be too complicated. So:

triggerCDcurrent = triggerCD / icdr

currentTickRate = data.misc.ServerTickTime * m_ceil(triggerCDcurrent / data.misc.ServerTickTime)

desiredTickRate = currentTickRate - data.misc.ServerTickTime

nextcapCDR = m_ceil(((triggerCD / desiredTickRate) - 1) * 100)

extraCDRneeded = nextcapCDR - ((icdr - 1) * 100)

With this, I can reliably find in my spreadsheet the CDR needed for the next breakpoint, in our example. For the other discussion we had, about Vixen's, that wouldn't work I'm pretty sure, but lets focus here one problem at a time.

[VekiaCH]

So here I have 2 new tests, both with 52% cdr.

https://pobb.in/7Tp1tlBOwlt0 9.45 aps or 0.1058 hit rate (slower than 3 server ticks at 0.099)

9.45 APS

https://pobb.in/7n-kxXAxiCso 10.75 aps or 0.0930 hit rate (faster than the spell's cooldown at 0.0987)

10.75 APS

Watching them side by side, there's clearly a huge difference. Undercapping APS is clearly much better for proc rates than overcapping. What also have we learned? Attack hits (not the trigger) timing is not linked to server ticks, only the trigger and spell cooldowns are linked (see my graph further up). This means attacks run on raw time and when the server makes an action check, it checks if the hit happened between the previous and current tick and if it happened, it checks if the triggered spell is off cooldown or not. If not the trigger is skipped and nothing happens. If the trigger is off cooldown, it will trigger of course. There is no snapping of attack hits to server ticks, meaning the only relavant things when finding trigger rate are that the attack is slower than the cooldown of the spell and the cooldown of said spell is below the target breakpoint. Yes if you're under the max APS, you'll eventually miss a trigger, but that dps loss is pretty inconsequential.

[ConKou]

So here I have 2 new tests, both with 52% cdr.

https://pobb.in/7Tp1tlBOwlt0 9.45 aps or 0.1058 hit rate (slower than 3 server ticks at 0.099)

9.45 APS

https://pobb.in/7n-kxXAxiCso 10.75 aps or 0.0930 hit rate (faster than the spell's cooldown at 0.0987)

10.75 APS

Watching them side by side, there's clearly a huge difference. Undercapping APS is clearly much better for proc rates than overcapping. What also have we learned? Attack hits (not the trigger) timing is not linked to server ticks, only the trigger and spell cooldowns are linked (see my graph further up). This means attacks run on raw time and when the server makes an action check, it checks if the hit happened between the previous and current tick and if it happened, it checks if the triggered spell is off cooldown or not. If not the trigger is skipped and nothing happens. If the trigger is off cooldown, it will trigger of course. There is no snapping of attack hits to server ticks, meaning the only relavant things when finding trigger rate are that the attack is slower than the cooldown of the spell and the cooldown of said spell is below the target breakpoint. Yes if you're under the max APS, you'll eventually miss a trigger, but that dps loss is pretty inconsequential.

First pob is clearly very low atsp. According to my sim theres 2 cases:

1) If attack cooldowns are true and dont snap to tick rate

So kinda complicated. Overall we loose a trigger every X triggers. Explanation here. Every 5th attack hit, we move down another tick rate breakpoint. It would be

1st hit tick > 2 cooldown ticks > 2nd hit tick > 2 cooldown ticks > 3rd hit tick > 2 cooldown ticks > 4th hit tick > 2 cooldown ticks > 5th hit tick > 3 cooldown ticks

Meanwhile the trigger cooldown has come off already, so after that 5th attack where we have 3 ticks of waiting instead of 2, we delay our trigger by 1 tick. Depending on the trigger cooldown we loose triggers over time.

2) If attack cooldown snaps to tick rate

Then it's way worse. It's always 3 cooldown ticks between each attack tick BUT we never loose a trigger this way, since it always has time to recover.

In the video, we clearly see it has sequences of 5 frostbolts then pause then another 5 frostbolts. Every 5 or 6 waves, insread of 5 frostbolt sequence, we get a 4 frostbolt one. So according to that, the behavior is more close to the first case, where attacks have true cooldown. Otherwise, I think it would be, frostbolts continuously firing off, with a set distance between them which is slightly higher than the sequences of 5 we see in the video, that is never disrupted.

Now on the second pob the attack speed is too much. Again 2 cases

1) If attack cooldowns are true and dont snap to tick rate

We loose a trigger every 5th or 4th trigger. Or to say it better, every 5th or 4th trigger, we attack too fast, before the cooldown of the trigger is up and we need to wait for another attack to start the cycle again. Also every 5th or 4th attack hit, we go up a tick rate. It would be

1st hit tick > 2 cooldown ticks > 2nd hit tick > 2 cooldown ticks > 3rd hit tick > 2 cooldown ticks > 4th hit tick > 2 cooldown ticks > 5th hit tick > 1 cooldown tick

2) If attack cooldown snaps to tick rate

Then it syncs perfectly. Maybe after many many hits there's a miss but I don't see something like that. Trigger cdr and attack cooldown always recover on the same tick rate and always have 2 tick rates in between.

In the 2nd video, we see again clear sequences of 4 and 5 frostbolts being throw interchangably. So again, the behavior is more close to the first case, where attacks have true cooldown.

EDIT: Conclusion Funny thing is, firstly I analyzed the pobs and pushed the values in my spreadsheet. It took me 1+ hour to be meticulous and it's very satisfying to see the 2 videos after and have them both show the same thing. No confirmation / watcher bias here. That attacks have true cooldown and don't snap to closest tick rate. I really hope we are not missing anything and that result is the truth. Still I would prefer if we get info from GGG.

[VekiaCH]

EDIT: Conclusion Funny thing is, firstly I analyzed the pobs and pushed the values in my spreadsheet. It took me 1+ hour to be meticulous and it's very satisfying to see the 2 videos after and have them both show the same thing. That attacks have true cooldown and don't snap to closest tick rate. I really hope we are not missing anything and that result is the truth. Still I would prefer if we get info from GGG.

Oh that's amazing to hear that it basically happened exactly as expected.