Bopper

This is fantastic to hear. Thank you Number Six.

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.

@underfyre, I went back and had to look over the guide. It looks like I did somewhat have clarity in the description of the MRT, but it was implicit. You'll notice the table of example Base Recharges and Enhanced Recharge (using %) with their calculated MRT. I hope that helps. Good luck with your Proc builds.

The divide by 100 actually represents a divide by 100%. That's bad form on my part as I should just write the formula as .../100%. Sorry for the confusion.

If you're looking Melee ATs, Shield is pretty offensive while also tough as nails

Zero Kelvin Iced Teabag Hard Water Mark

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

Correct, power build up. And if you use the suggested combo, remember that order matters. You will want to go Clarion, then PBU, then Farsight. Do it in that order, and the boost multiplies (+32.1265%). Do it in the other order (PBU, Clarion, Farsight) results in only added boosts (+22.2925%).

It looks like it's a good pairing. Time's only downside is its regeneration debuff is rather weak, but you can supplement it with Beam Rifle's attacks. Plus both sets offer up good proc options.

@Jimmy, will Beta get access to free incarnate/merits again? I'm trying to a potential bug(s) with Interface DoTs (not cancel-on-miss, I'm aware that's intended).

Defender's/Corruptor's Soul Drain for Dark seems thematically over powering, as its radius is larger than the Dark Melee version, while having the same recharge. I would like to see a 6th power added for each Epic/Patron pool. Two T1s available at 35, two T2s available at 41 (needing a T1 to unlock), and two T3s available at 44 (needing two sub-T3s to unlock).

Sad to say, but should this be unstickied? The tool will never return and the OP/developer hasn't been on the forums in 4 months.

After each search, I have to select the "xxx AND yyy AND zzz" to filter the results that contain all of my criteria as opposed to atleast one of my criteria.

I see what you mean now. For debuffs and buffs, I dont believe there are any limits unless otherwise stated. As for toggles with limits, those limits are likely more of a max targets limit as opposed to a stack limit.

Can you give me some examples of the five stack rule? I don't know of any. The closest I can think of is Incarnate Interface where a target can be effected by a maximum of 4 stacks (combined from all players).

It is a topic that comes up many times as there are many rules to it. Basically, All sonic attacks stack and pseudopet/patch debuffs stack from same caster as well as other casters (e.g. Sleet) Other debuffs stack from other casters only (e.g. Sonic Siphon) Procs of the same name don't stack (e.g. an enemy can only be affected by one Achilles' Heel). For procs, once an enemy is affected by it, it can only be replaced by new applications. I say replace, instead of refresh, because of the purple patch. If a lower level player replaces the same-named proc of a higher level player, the effects will be diminished.

Actually they do stack from the same user's power. I've seen it using a power analyzer. So if you only cast Shriek over and over again, however many attacks can fit in the 5 second debuff duration will add up.

I was saying 400% total, so +300% plus the base. :-).

Yes and yes... but only take weaken Resolve if it fits your build. Dont need to chase something if you have needs elsewhere.

Fair point about factoring in misses. Ultimately, instead of doing napkin math (or rather excel spreadsheet math), I should write a script that prioritizes attacks and simulates various chains while factoring in tohit mechanics and various recharge amounts. I've done similar stuff with cascading defense, I dont see why I couldnt do something for this. That being said...I probably won't lol. That's a lot of work for something that would be purely academic and not necessarily replicate real gameplay.

It is not, but it is an easily achievable chain using only sonic attacks. That chain gets you 91.5% with a total of +279% recharge in the power. If you can reach about +375% (400% is max), then Screech-Shriek-Scream-Shriek, and Screech-Scream-Shriek-Scream over takes it. But when we add Weaken Resolve, things change.

Ran some crude analysis, but it looks like you can average ~150% debuff with Screech, Shriek, Scream, Weaken Resolve (with proc), and Sleet (with procs). Throw in the occasional Dreadful Wail (with proc) and Heat Loss (with proc) for some occasionally higher numbers.

You should be able to squeeze out more -Res from your single target attack chain. I know a Screech-shriek-shout-shriek can reach 91.5% on average and only requires a little be more recharge than does having perma-Hasten (279%). There are a few other more optimal chains, but they require some crazy edge of the envelope type of recharge. I'll have to go back and look to see what can be achieved with procs and cold powers added into the chain.

Everyone needs to chill. @GM Widowercan probably go ahead and lock this thread. OP got the answer they were looking for. Now we are just diverging into pettiness over who started it. Let's all be mature and end it.