Cast on Critical Strike Trigger Rate being calculated incorrectly

[VekiaCH]

Check version

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

Check for duplicates

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

Check for support

• 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.

[FruitcakeElemental]

I also have noticed a discrepancy with CoC calculations but I think my case has more to do with dual wielding. Running 2.33.5 (Beta).

https://pobb.in/hSnDq4v4ADME

It divides the cooldown by 2 when dual wielding with ACoC, correct me if I'm wrong but it would seem that dual wielding shouldn't affect this, if it was a cospris then it would yes but not CoC.

[ConKou]

Yeah I can confirm, that shouldn't be the case.
Even with double Cospri's, only the skills socketed and triggered from Cospri's should be attacks per second / 2 and not the main skill linked to coc that is not socketed in the weapon.

[ConKou]

Coming from #6481, while talking about Vixen's trigger rate we made a weird observation, that might be wrong, but if it is correct, it probably means we have been thinking triggers the wrong way all this time.

Earlier on this discussion we concluded that attacks / casts have true cooldown and don't snap to server tick rate.
So let's take an example for Vixen's Entrapment.
Vixen's, acts as a trigger. When you cast a curse, it triggers all socketed curses with a 0.25s cooldown. Let's take some parameters:
57% cdr
214% cast speed
0% action speed
curse cast that procs Vixen's = Temporal Chains with base cast rate of 2 / sec
Vixen's cd = 0.25 / 1.57 = 1 / 6.28 = 0.159....
main curse cast time = 1 / (2 * 3.14) = 1 / 6.28 = 0.159....
Vixen's cd and main curse cast time are actually the same number.
reference pob: https://pobb.in/gF8sKhHrauwf
Our cast speed is over the cap and therefore we should be missing Vixen's trigger activations as it desyncs. According to pob Vixen's trigger rate is 5.19, instead of the theoretical maximum of 6.06 (which we could achieve with 203% cast speed). The decrease is 6.06 / 5.19 = 1.19 = 19% 1.16 = 16%.
That's how the trigger simulation calculates it currently AND is also how I thought it was supposed to work AND also how I assumed it worked after our big discussion in here.

But Silenth posted his own timeline and when I analyzed it I found something that goes against what we knew.
So as I said in the start, we concluded that attacks / casts have true cooldown and don't snap to server tick rate like triggers (coc, vixen's etc).
Let's make the timeline:
tick 0 = 0 seconds in time

1. 1st cast and 1st trigger
2. casts have true cooldown so at 0.159s we have 2nd cast, trigger is on a 0.159s cd but since it snaps to the closest tick which is 0.165, we miss an activation
3. 0.318s 3rd cast, trigger went off cd at 0.165s so it's available now and we have 2nd trigger , that trigger is processed at the next closest tick so it goes on cooldown at 0.33s
4. 0.477s 4th cast, trigger went on cd at 0.33s so it comes off cd at 0.489s BUT since it snaps to closest tick it really comes off cd at 0.495s so we miss an activation here

Here is a screenshot that shows this sequence.

So it definitelly seems like Vixen's loses half the activation rates it should have and definitely not just 16% like pob suggests and like I thought it should. Understanding of how steps 2-3 happen is the most important part I think. Does it happen like I described?

[zekeflynn]

I'm using Anomalous Impending Doom for 100% reduced curse duration.
Increasing CDR increases my "trigger rate cap" but not "skill trigger rate", and shows no change on dps. Same for cast speed.

This is a bug, right? Otherwise would anybody explain to me?

[Paliak]

@zekeflynn Post a build link. That inf looks odd.

[zekeflynn]

https://pastebin.com/iUT4Hfhe

[Paliak]

Looks like a bug. With 100% reduced curse duration the curse expires instantly after being applied. This case should be equivalent to using curse replacement mode.

[ConKou]

Yeah, right now for Eff Source Rate it does 1 / curse duration, but if it's 0 it goes to 1 / 0 which is infinity like the screenshot shows.
At reduced curse duration >= 100%, it should work like curse replacement mode and follow main curse cast rate, since it gets applied and taken off imediately at each cast.

[zekeflynn]

Indeed with Curse Replacement the Skill Trigger Rate mirrors Eff. Source Rate which is the Curse cast rate, makes sense. The calculation doesn't take into account 2x or 3x proc rate from Spell Cascade overlaps, and so it doesn't register CDR as a dps increase. Maybe let us manually set overlaps on Curse Replacement so it can calculate CDR?

[Paliak]

2x or 3x proc rate from Spell Cascade overlaps

@ConKou This would apply to the trigger rate like vixen's due to the charges right.

[zekeflynn]

lil update on Curse Replacement setting, even if I give myself 1000% cast speed the Skill Trigger Rate stays at the same threshold as with Curse Expiration, ignoring CDR. Unsure how to make it reach Trigger Rate Cap...

[Paliak]

Doomblast cd may be being rounded by the sim func internally. Could be a another edge case to check for. #6581 seems to have the same issue.

[ConKou]

2x or 3x proc rate from Spell Cascade overlaps

@ConKou This would apply to the trigger rate like vixen's due to the charges right.

Yeah, since main curse has 100% reduced duration, in this case overlap means another application of curse. Effectively a pure multiplier to Eff Source Rate, kinda like Vixen's.
So if duration = 100% reduced -> Eff Source Rate = main curse cast rate * Overlaps
And,
Skill Trigger Rate = min(Eff Source Rate, Doom Blast max activation rate)
We use min() function again, since no matter how fast we try to proc Doom Blast, it still has a cooldown.

lil update on Curse Replacement setting, even if I give myself 1000% cast speed the Skill Trigger Rate stays at the same threshold as with Curse Expiration, ignoring CDR. Unsure how to make it reach Trigger Rate Cap...

Yep that is happening and it shouldn't be like that. After 145% cast speed to be precise, Eff Source Rate and Skill Trigger Rate start to desync.

Doomblast cd may be being rounded by the sim func internally. Could be a another edge case to check for. #6581 seems to have the same issue.

Isn't #6581 about the new rotation only? And you have reverted the rework so that currently pob uses the old calculations.

The 146% cast speed point at which the Skill Trigger Rate starts behaving abnormally, doesn' coincide with any breakpoints as far as I see, so I have no idead what it could be. Maybe a problem in the simulation with Curse Replacement mode?
The value Skill Trigger Rate ends up sticking to is 7.58, which is also the number that the, incorectly working, Curse Expiration mode, has. Maybe there's a corelation there?

[Paliak]

Isn't #6581 about the new rotation only? And you have reverted the rework so that currently pob uses the old calculations.

POB uses the pre rework func right now.

Basically i feel like this may play into the cooldown rounding to tick issue.

>>> cd = (0.15 / 1.37)
>>> 1/ cd
9.133333333333335
>>> math.ceil(cd * ServerTickRate) / ServerTickRate
0.132
>>> 1/ (math.ceil(cd * ServerTickRate) / ServerTickRate)
7.575757575757575
>>>

I'm really starting to feel like the old simulation is not fully correct either.

[ConKou]

Ok that here is a problem

math.ceil(cd * ServerTickRate) / ServerTickRate
0.132
1/ (math.ceil(cd * ServerTickRate) / ServerTickRate)
7.575757575757575

It rounds the cooldown to nearest server tick. That shouldn't be the case for Doom Blast since it uses charges and has true cooldown that doesn't snap to tick rate.

We didn't see that problem before with the Vixen's variant because with Vixen's the simulation, simulated Vixen's trigger rate, which adheres to normal cdr rules and snaps to ticks. But now the simulation tries to calculate Doom Blast directly and it treats it like usual triggers. Even though that was not supposed to happen since you have that flag in the code.
If you do it like in the Vixen's mode and in the Skill Trigger Rate, instead of the simulation, you put it min(Eff Source Rate, Doom Blast max activation rate), then there won't be any problems.

[Paliak]

Even though that was not supposed to happen since you have that flag in the code.

That flag currently only affects trigger rate cap. I'll change it so that instead of running the simulation func it does a min.

[ConKou]

Checked your pr, seems ok, apart from one problem.
When reduced curse duration goes beyond 100% (101% +), then curse duration becomes negative.

That shouldn't be the case, seems like a small bug. And this negative duration in turn affects Doom Blast Eff Source Rate.

It's quite probable, the alt qual impending doom build to reach values below 100% reduced curse duration.

POB: https://pobb.in/RElzV5J2L8pO

[ConKou]

@Paliak
I have been re-reading this whole thread again with a clear mind to try and make sense of this and I have found something in the start of the whole post that is very interesting.

Here you are talking about the logic the new simulation uses.

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

On your last sentence you say Currently T is dependent on server tick rate so 0.0998003992015968 is rounded.... That 0.0998003992015968 number represents that cooldown of the attack. We started from that and extended all the way to kinda prove that attacks have true cooldown and don't snap to server tick. But we didn't realise the important part.

This last sentence was wrong in the logic. It should have been Currently T is dependent on server tick rate so 0.09868421052631579 is rounded.... The change is, you should have used the number 0.09868421052631579 which is the trigger's cooldown and NOT the attack cooldown. This is very important because that, sticks to nearest server tick.

From the wiki

So I'm taking your post and changing the relevant bits to what I think should be the correct approach:

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.09868421052631579 is rounded to the next server tick and that would be at T = 0.132

The attack goes independently of server ticks but the trigger snaps to them. Technically 0.09868421052631579 + 0.09868421052631579 = 0.197368 which snaps to 0.198 tick. BUT it probably doesn't work like that. Imagine the sequence below:

The second attack hits at 0.0998003992015968 which is AFTER the 0.099 tick. That means, at the 0.099 tick the trigger is off cooldown. just after this at 0.0998003992015968 the attack hits, the trigger is off cd so it triggers but since the status of cooldowns is only updated once on each server tick the trigger goes on cd at the 0.132 tick. So it comes off cd at 0.132 + 0.09868421052631579 = 0.2306842. Third attack hits at 0.0998003992015968 + 0.0998003992015968 = 0.1984126 at which point in time the trigger is still on cooldown. So here we have our first missed activation. If you follow this logic we are missing an activation every second attack.

If this is true, then what @VekiaCH said here still stands true even though he said it for the wrong reason. The attack cooldown doesn't snap to server tick but the trigger does. We were focused on proving the attack doesn't snap to tick that we missed checking the correct sequence.

[Paliak]

The negative trigger rate should be fixed.

Would make sense then why doom blast was only losing 16% or whatever it was instead of halving.

[ConKou]

The negative trigger rate should be fixed.

Would make sense then why doom blast was only losing 16% or whatever it was instead of halving.

Oh cool.
I was talking about the general problem with how triggers work and the new simulation but it's good to know the other doom blast thing is getting fixed as well.

[mpmapes]

ConKou

Thank you for explaining this. For a build like coc cyclone, is the effective skill trigger rate in POB roughly accurate in the current release? For example with a cyclone attack rate of 10.25 and a trigger rate cap of 10.1, I'm getting a skill trigger rate of 9.81 in the calcs tab. If I increase the cyclone attack speed further, the trigger rate goes lower.

[ConKou]

ConKou

Thank you for explaining this. For a build like coc cyclone, is the effective skill trigger rate in POB roughly accurate in the current release? For example with a cyclone attack rate of 10.25 and a trigger rate cap of 10.1, I'm getting a skill trigger rate of 9.81 in the calcs tab. If I increase the cyclone attack speed further, the trigger rate goes lower.

Yes currently the effective skill trigger rate on PoB displays what we thing is the traditional way of calculating this, as it has been for the past years. There was a change recently but was reverted so we can look more into it. What I'm describing is kinda like research for the next version and trying to understand how it works exactly. Right now, with traditional understanding, pob displays correctly that your skill trigger rate is lower than maximum, since your attack rate exceeds the trigger rate cap and that makes you loose activations. Your attack rate should be 10.1 or lower. See here:
https://www.poewiki.net/wiki/Cast_On_Critical_Strike_Support#Effective_cooldown_&_cooldown_thresholds

[pnmueller]

I've just seen this discussion referenced on the /r/pathofexilebuilds subreddit and wanted to hopefully clarify some things. All of this is based on some comments from Mark_GGG on Reddit and my own testing a few years ago, so I'm fairly confident in this but obviously it should be checked whether it's still consistent with observations.

There's an important distinction to be made between attacks and hits that seems to have been neglected here. An attack (just like a cast) is the activation of a skill and only happens once per click or trigger of the skill. For channeled skills, in particular, that is only once when you start channeling.

Any such use of a skill indeed happens at the time of the tick with a matching cooldown (= you cannot start the cooldown between ticks).

Meanwhile, hits can also occur between ticks, i.e., during each tick, all hits that would've occurred since the last tick are calculated and, for channeled skills, the time of the next hit is calculated based on when it would've occurred, not based on the time of the current tick.

Using the terminology I've seen here, this means that triggered skills always 'snap' to server ticks. Meanwhile, attacks snap to server ticks, but their hits do not. As a result, Cyclone only snaps its activation to server ticks, but not its hits. On the other hand, skills that only produce a single hit per attack like Flicker Strike effectively also snap their hits to server ticks because each hit is the result of an individual attack that snaps to server ticks.

The fact that attacks snap to server ticks should be well known for anybody who's experimented with heavy divergent trauma stacking; if you don't have enough sustain, you may die the moment you go from the 66ms to the 33ms breakpoint. If you look at some extreme attack and cast speed testing, you'll also observe that both are limited to ~30/s thanks to the 33ms server tick delay.

Edit: It's probably worth mentioning that the above only applies as long as there's only a single hit per attack. If e.g. you use Multistrike, you now produce 3 hits per attack which allows you to get up to ~91 hits/second when at the ~30 attacks/second cap.

Meanwhile, trigger testing such as done in this topic consistently shows that spells skip an attack once every n ticks when the hit rate exceeds the potential trigger rate, which is only possible if the hit isn't calculated on equidistant ticks, something that naturally occurs when hits are calculated based on when they should've occurred exactly, not based on the current server tick.

All of this gets fairly complicated once you include triggers with inconsistent hit intervals, such as Barrage or Blast Rain, and CoC setups with multiple spells, which is why I've been using Python scripts simulating their behavior for my bow CoC builds for a few years now. Finding a mathematical representation taking into account all relevant variables for these cases might prove difficult even when knowing the actual mechanics.

[ConKou]

There's an important distinction to be made between attacks and hits that seems to have been neglected here. An attack (just like a cast) is the activation of a skill and only happens once per click or trigger of the skill. For channeled skills, in particular, that is only once when you start channeling.

That's very interesting, I haven't considered it before.
Do you have any comment on this?
To reiterate the point made in a simpler manner.
Imagine the below:

hit with 0.1s cd
trigger with 0.095s cd

1. hit and trigger at 0s
2. trigger recovers at 0.095s which snaps to 0.099 tick
3. hit again at 0.1s, which is after the 0.099 tick so trigger is off cd and triggers
4. hit recovers from cooldown at 0.1 + 0.1 = 0.2s
5. trigger got triggered form the hit at 0.1s which belongs at the 0.132 tick. So cooldown recovers at 0.132 + 0.095 = 0.227s which snaps to 0.231s tick
6. Hit at 0.2s
   Now for the mechanical part which is the big question of this thread more or less, what happens next?
   7a) since trigger comes off cooldown at the 0.231s tick, the hit at 0.2s is a missed trigger activation
   7b) the attack that triggered the hit at 0.2s belongs in the 0.231s tick. Both attack and trigger come off cooldown at the same tick, so we have a trigger.

Which is correct? 7a or 7b?
7b is what pob has been calculating for the past and what seems to happen on videos.
7a is the new proposed theory and what should be correct imo. But with that logic, we miss half our triggers compared to the current understanding.

[VekiaCH]

All of this gets fairly complicated once you include triggers with inconsistent hit intervals, such as Barrage or Blast Rain, and CoC setups with multiple spells, which is why I've been using Python scripts simulating their behavior for my bow CoC builds for a few years now. Finding a mathematical representation taking into account all relevant variables for these cases might prove difficult even when knowing the actual mechanics.

My question would be if skills like Barrage or Blast Rain which have multiple hits per cast, do these individual hits of the skill snap to ticks or do they behave like cyclone, in that the individual arrows hit in exact time. Legit no idea here. Everything would be so much easier if nothing snapped to server ticks.

[pnmueller]

hit with 0.1s cd trigger with 0.095s cd

1. hit and trigger at 0s
2. trigger recovers at 0.095s which snaps to 0.099 tick
3. hit again at 0.1s, which is after the 0.099 tick so trigger is off cd and triggers
4. hit recovers from cooldown at 0.1 + 0.1 = 0.2s
5. trigger got triggered form the hit at 0.1s which belongs at the 0.132 tick. So cooldown recovers at 0.132 + 0.095 = 0.227s which snaps to 0.231s tick
6. Hit at 0.2s
   Now for the mechanical part which is the big question of this thread more or less, what happens next?
   7a) since trigger comes off cooldown at the 0.231s tick, the hit at 0.2s is a missed trigger activation
   7b) the attack that triggered the hit at 0.2s belongs in the 0.231s tick. Both attack and trigger come off cooldown at the same tick, so we have a trigger.

Which is correct? 7a or 7b? 7b is what pob has been calculating for the past and what seems to happen on videos. 7a is the new proposed theory and what should be correct imo. But with that logic, we miss half our triggers compared to the current understanding.

As far as I'm aware, 7b would be correct, and PoE only checks whether a cooldown is up at the current tick, not whether it would've been up when the hit theoretically landed. As you mentioned, 7a cannot be correct as it'd cause behavior that you don't observe in-game.

By the way, even if it worked as you described in 7a, we have no evidence that the game would use 0.231s as the cooldown. It'd most likely be using the actual cooldown of 0.227s. This whole idea of the cooldown 'snapping' is a direct result of assumption 7b that the cooldown always starts at the time of a tick, and thus the effective cooldown is equivalent to the cooldown rounded to the next tick.

My question would be if skills like Barrage or Blast Rain which have multiple hits per cast, do these individual hits of the skill snap to ticks or do they behave like cyclone, in that the individual arrows hit in exact time. Legit no idea here. Everything would be so much easier if nothing snapped to server ticks.

I don't think GGG has explicitly stated this, but there's no reason to believe that channeled skills have a separate hit handling from non-channeled skills. According to statements such as the one by Mark here, tick-based limitations only apply to actions, not to hits.

With respect to barrage, there's still something I haven't found an answer to yet and both options are feasible: The projectiles are divided throughout 0.6 of the animation, but does that mean you get the first projectile at 0.4 and the last projectile at 1.0 (=0.6/(n-1) per projectile) or does that mean you get the first projectile at 0.4+0.6/n (=0.6/n per projectile). All topics I've seen assume that the time between projectiles is 0.6/n but that'd imply that the first projectile adds 0.6/n to the wind-up time of 0.4 as it doesn't add up otherwise.