Jump to content
Bopper

Interface Procs are Bugged...my Test Results might show why

Recommended Posts

This bug has been brought up numerous times over the last year. You can check that out here, here, and here. I have not seen much discussion on this by the devs, with the only mention of looking into it came from @Captain Powerhouse where he stated this. However, I have no idea if he actually looked into it. Nonetheless, I decided to look into it by creating large sample sizes of data and hopefully identify a trend (for those who don't like lots of numbers, feel free to scroll down to my conclusion, which is in big-bold letters at the bottom).

 

Here is what we think we know. The DoT does its proc check after each tick and will cancel all subsequent ticks if there is a miss. This means we have the following expected performance numbers for a DoT that has a 75% chance of “ticking”.


Probability of 0 ticks: 25% (25% to miss on first tick attempt)
Probability of at least 1 tick: 75% (75% to hit on first tick attempt)
Probability of at least 2 ticks: 56.25% (75% x 75%)
Probability of at least 3 ticks: 42.19% (75% x 75% x 75%)
Probability of at least 4 ticks: 31.64% (75% x 75% x 75% x 75%)
Probability of all 5 ticks: 23.73% (75% x 75% x 75% x 75% x 75%)

 

This also translates to the following expected performance:


Probability of exactly 0 ticks: 25% 
Probability of exactly 1 tick: 18.75% (75% x 25%: hit on 1st, then miss on 2nd)
Probability of exactly 2 ticks: 14.06% (75% x 75% x 25%)
Probability of exactly 3 ticks: 10.55% (75% x 75% x 75% x 25%)
Probability of exactly 4 ticks: 7.91% (75% x 75% x 75% x 75% x 25%)
Probability of all 5 ticks: 23.73%

 

This tells us that on average, for every successful attack we hit, we can expect 2.288 DoT ticks. (0*25% + 1*18.75% + 2*14.06% + 3*10.55% + 4*7.91% + 5*23.73% = 2.288).

 

Now that we know all the math for the expected performance (which was suggested/verified to us by Captain PowerHouse in the similar Bug Report last year), let’s look at the results we get from testing.


For this test, I removed all recharge bonuses for my build and used auto-Kick repeatedly. I did this because it would create a 5 second cycle between Kicks, which make all potential DoT ticks play out before I could perform the next Kick attack. This made it much easier for me to parse my combat log to measure the number of ticks generated from each attack (which I will compare to the probability of EXACT results I just provided). Finally, I removed all results where my final Kick attack resulted in the defeat of the enemy. I did this because we could never be sure of how many ticks of damage the target could have had if they remained alive (once they're dead, the ticks stopped). This includes removing results where the death occurred on the 5th tick. Even though we know exactly how many ticks happened, it is unfair to cherry pick (please don't make me explain the math). So those were my test conditions. Now, onto the results.


Test 1 (10 Feb 2020): T3 Degenerative Radial (+75% chance DoT only)

313 Successful Kicks. 
No Ticks: 149 (47.60%)
1 Tick: 29 (9.27%)
2 Ticks: 34 (10.86%)
3 Ticks: 20 (6.39%)
4 Ticks: 22 (7.03%)
5 Ticks: 59 (18.85%)
Average: 1.7252 Ticks per Successful Kick 

 

Test 2 (11 Feb 2020): T3 Degenerative Radial (+75% chance DoT only)

1192 Successful Kicks.
No Ticks: 522 (43.79%)
1 Tick: 178 (14.93%)
2 Ticks: 109 (9.14%)
3 Ticks: 82 (6.88%)
4 Ticks: 86 (7.21%)
5 Ticks: 215 (18.04%)
Average: 1.7290 Ticks per Successful Kick

 

Test 1 and 2 combined:

1505 Successful Kicks
No Ticks: 671 (44.58%)
1 Tick: 207 (13.75%)
2 Ticks: 143 (9.50%)
3 Ticks: 102 (6.78%)
4 Ticks: 108 (7.18%)
5 Ticks: 274 (18.21%)
Average: 1.7282 Ticks per Successful Kick

 

These results show that the actual performance is nothing close to the expected performance. So, what’s going on here, exactly? First, let’s look at the ratio of the test results with the expected results.

1 Tick: 13.75%/18.75% = 0.7335
2 Ticks: 9.50%/14.06% = 0.6757
3 Ticks: 6.78%/10.55% = 0.6426
4 Ticks: 7.18%/7.91% = 0.9072
5 Ticks: 18.21%/23.73% = 0.7672
Average: 1.728/2.288 = 0.7553

 

There’s a little bit of variance still happening, but it seems there is a pattern, which is the probability of X Ticks are all being weighted by approximately 0.75 (75%). I suspect an extra 75% probability to proc is being applied in the front end and it carries itself through the rest of the ticks. I notice similar behavior with the 25% proc as I performed a small test (using a T4 Reactive Core) of 172 samples and only saw 9 ticks (5.23%, when I expected 25%). I don’t have enough samples with the 25% proc yet, but it wouldn’t surprise me if it is also having the 25% probability to proc applied an extra time on the front, which cascades down to the probability of the subsequent ticks.

 

If my hunch is correct, then the probability of X ticks to occur would no longer be:

X: Current Expected | Actual?
0: 25% | 43.75%
1: 18.75% | 14.06%
2: 14.06% | 10.55%
3: 10.55% | 7.91%
4: 7.91% | 5.93%
5: 23.73% | 17.80%

 

And for completion, here are the numbers for the 25% DoT (needs more testing)

X: Current Expected | Actual?
0: 75% | 93.75%
1: 18.75% | 4.69%
2: 4.69% | 1.17%
3: 1.17% | 0.29%
4: 0.29% | 0.07%
5: 0.10% | 0.02%
 

As for continuing testing, I'll do so when incarnates become free again on Beta. As of now, I'm limited to the 75% T3 Degenerative and the 25% T4 Reactive.

 

Edit: To be clear with my phrasing. I suspect only the first tick is having an extra 75% (or 25%) check applied to its proc. All subsequent ticks should be working as expected (with just the single 75% proc checked).

Edited by Bopper
Edit for clarity.
  • Like 4
  • Thanks 4

Share this post


Link to post
Share on other sites

Update:

I have ran a new test using a 50% Spectral Interface DoT Proc (w/ 10% chance to Immobilize). If we were to assume the DoTs are working as intended (they're not), we would expect the following results:

 

Probability of 0 ticks: 50% (50% to miss on first tick attempt)
Probability of at least 1 tick: 50% (50% to hit on first tick attempt)
Probability of at least 2 ticks: 25% (50% x 50%)
Probability of at least 3 ticks: 12.5% (50% x 50% x 50%)
Probability of at least 4 ticks: 6.25% (50% x 50% x 50% x 50%)
Probability of all 5 ticks: 3.125% (50% x 50% x 50% x 50% x 50%)

 

This also translates to the following expected performance:


Probability of exactly 0 ticks: 50% 
Probability of exactly 1 tick: 25% (50% x 50%: hit on 1st, then miss on 2nd)
Probability of exactly 2 ticks: 12.5% (50% x 50% x 50%)
Probability of exactly 3 ticks:  6.25% (50% x 50% x 50% x 50%)
Probability of exactly 4 ticks: 3.125% (50% x 50% x 50% x 50% x 50%)
Probability of all 5 ticks: 3.125%

 

HOWEVER, it is my hypothesis that the first tick in the DoT proc is getting checked twice, thus resulting is a NEW expected performance:

 

Probability of exactly 0 ticks: 75% (100% - 50% x 50%: doesn't hit twice on first)
Probability of exactly 1 tick: 12.5% (50% x 50% x 50%: hit twice on 1st, then miss on 2nd)
Probability of exactly 2 ticks: 6.25% (50% x 50% x 50% x 50%: hit twice on 1st, hit on 2nd, then miss on 3rd)
Probability of exactly 3 ticks:  3.125% (50% x 50% x 50% x 50% x 50%)
Probability of exactly 4 ticks: 1.5625% (50% x 50% x 50% x 50% x 50% x 50%)
Probability of all 5 ticks: 1.5625% (50% x 50% x 50% x 50% x 50% x 50%)

 

So I ran a new test, and here are the results:

 

2,096 Successful Kicks

No Ticks: 1,479  (70.56%)

1 Tick: 317  (15.12%)

2 Ticks: 147  (7.01%)

3 Ticks: 83  (3.96%)

4 Ticks: 42  (2.00%)

5 Ticks: 22  (1.05%)

 

Conclusion: Interface DoT Procs are bugged on their first DoT tick, as they are being rolled twice. This requires the first tick to be successful both times in order for the tick to fire, greatly reducing the intended DoT Proc performance.

 

Also, thanks to @Gulbasaur for first noticing this behavior in his original Bug Report last summer. His testing should have been recognized sooner.

  • Like 1
  • Thanks 3

Share this post


Link to post
Share on other sites

That makes a lot of sense and explains so much about what has been talked about before.

 

Thanks to you (and Gulbasaur, too) for examining this.

  • Like 1

Share this post


Link to post
Share on other sites

This seems like it's an error in maths, as though a perenthesis was used improperly, or not at all.

 

For example in the formula above we see

 

100%-50%•50%. GERMDAS stipulates that order would be multiplication first, followed by subtraction, in this case. Hence, the 75%.

 

If we modify the equation as such,

 

(100%-0%)•50% our result is then 50%. Just a simple example.

 

Perhaps a Dev can post the line code that includes the formula to eliminate simple errors in order, just to eliminate the easy stuff?

Edited by SwitchFade

Share this post


Link to post
Share on other sites

@Bopper Nice work!

 

Can confirm, there's an extra roll for the mod to attach. I didn't catch it when I checked this out last time (was assuming it was a duplicated Chance but didn't find one), but the numbers clearly indicate that's what's happening so I looked again, and found it hidden in the Requires.

Requires target.isFriend? ! @ToHitRoll @ToHit / @ChanceMods < &&

That @ToHitRoll @ToHit / @ChanceMods < is the hacky way the Paragon devs used to get a consistent roll in order to tie multiple attribmods together.

 

In this case it shouldn't even be there at all, since the DoT attribmod is CancelOnMiss and has a TickChance of 0 (which gets increased by global chance mods based on which ability you have slotted). So the chance is being applied twice, once for the mod to attach, and then again on the first tick.

 

My guess is this was probably copied and pasted from the Reactive -Res debuff -- that effect had an attribmod for each damage type, and would have needed the hacky workaround to consistently apply them instead of doing a separate 75% chance roll for each type. We don't actually need the hack anymore since the I25+ engine has effect groups, but that's a whole different discussion.

 

I'll ping @Captain Powerhouseto remove the unnecessary part of the Requires and get that change in the pipeline.

  • Like 3
  • Thanks 3

Share this post


Link to post
Share on other sites
4 minutes ago, Number Six said:

@Bopper Nice work!

 

Can confirm, there's an extra roll for the mod to attach. I didn't catch it when I checked this out last time (was assuming it was a duplicated Chance but didn't find one), but the numbers clearly indicate that's what's happening so I looked again, and found it hidden in the Requires.


Requires target.isFriend? ! @ToHitRoll @ToHit / @ChanceMods < &&

That @ToHitRoll @ToHit / @ChanceMods < is the hacky way the Paragon devs used to get a consistent roll in order to tie multiple attribmods together.

 

In this case it shouldn't even be there at all, since the DoT attribmod is CancelOnMiss and has a TickChance of 0 (which gets increased by global chance mods based on which ability you have slotted). So the chance is being applied twice, once for the mod to attach, and then again on the first tick.

 

My guess is this was probably copied and pasted from the Reactive -Res debuff -- that effect had an attribmod for each damage type, and would have needed the hacky workaround to consistently apply them instead of doing a separate 75% chance roll for each type. We don't actually need the hack anymore since the I25+ engine has effect groups, but that's a whole different discussion.

 

I'll ping @Captain Powerhouseto remove the unnecessary part of the Requires and get that change in the pipeline.

This is fantastic to hear. Thank you Number Six.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

And THIS is why it's never too late to go check on things that everyone "KNOWS" is working right, just to make sure it is.  After all, it's this kind of work that made @arcanaville mildly famous for a while (still...!) in figuring out how Defense ACTUALLY worked.

 

Good job @Bopper.


IifneyR.gif

Verbogeny is one of many pleasurettes afforded a creatific thinkerizer.

Share this post


Link to post
Share on other sites
Just now, Redlynne said:

And THIS is why it's never too late to go check on things that everyone "KNOWS" is working right, just to make sure it is.  After all, it's this kind of work that made @arcanaville mildly famous for a while (still...!) in figuring out how Defense ACTUALLY worked.

 

Good job @Bopper.

Thank you. It's funny, I was actually going to test a different cause of the bug, but while Beta isn't allowing free incarnates I decided I'd atleast build up a base set of numbers to later compare to. But once I noticed problems with my "good data", I went back and did more thorough tests and research to identify the root cause. Gotta love it when math finds the answer.

  • Haha 1

Share this post


Link to post
Share on other sites
Just now, Bopper said:

Gotta love it when math finds the answer.

Spoken like a true @arcanaville accolyte!

  • Like 2

IifneyR.gif

Verbogeny is one of many pleasurettes afforded a creatific thinkerizer.

Share this post


Link to post
Share on other sites

*Mutters gently under his breath, gesticulating vaguely at the post he did in the bug report forum six months ago*

 

Amazing work as always Bopper. It's been a pleasure collaborating with you on this and glad it's been picked up by the dev team this time.

 

  • Like 1

Doctor Fortune  Soulwright Mother Blight Storm Lantern Corona Borealis
Blood Fortunado Dark/Dark Corruptor Rad/Rad Brute Storm/Sploosh Defender Dark/Dark Tanker

 

Blueside Story Arc Levelling Guide 

Share this post


Link to post
Share on other sites

I nominate you both (@Gulbasaur and @Bopper) for Bug Smasher and perma titles “Proc Smasher” "Proc-tologist"

Edited by Anubys
Proc-tologist is better in every way
  • Haha 2

Share this post


Link to post
Share on other sites
4 hours ago, Bopper said:

Lol, that may or may not have been intentional.

Honestly, it worked. I will remember it.

 

"I tested this bug and YOU'LL NEVER GUESS WHAT I FOUND"

  • Haha 2

Doctor Fortune  Soulwright Mother Blight Storm Lantern Corona Borealis
Blood Fortunado Dark/Dark Corruptor Rad/Rad Brute Storm/Sploosh Defender Dark/Dark Tanker

 

Blueside Story Arc Levelling Guide 

Share this post


Link to post
Share on other sites

I learn so much more than how to kill Skulls when reading these forums.  Great job @Bopper, @Gulbasaur and all the others who have worked so hard to figure out how Procs really work.  I’ve actually been only slotting my Interface powers to T3 until this got fixed as I wasn’t sure if it was WAI or truly bugged.  Sounds like I can safely T4 out the ones I want now, knowing even if they aren’t functioning properly right now, they will at some point “Real Soon Now.”

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...