Evade formula - Phoenix Freeshard

On Uthgard evade is hard capped at 50%, and contribution from dex and quick is not capped. So, you could have a total of 650 combined dex and Qui in theory, and this would contribute to evade chance up to the 50% cap.

Is this the same on Phoenix? Also how much oes 1 point of dex or 1 point of Qui contribute to evade %? Some sources say (((dex+Qui)/2)-100)/40 = % evade; soo after 200 combined d/q, each point of d or q adds .0125%

Exa:
200 d / 200 q = +2.5% evade
250 d / 250 q = +3.75% evade
300 d / 250 q = +4.375% evade

Is this accurate?

Does Qui over 250 contribute? Ie:

300 d / 300 q = +5% evade
350 d / 300 q = +5.625% evade

Sun 26 May 2019 1:02 PM by Ashok

Quickness is uncapped for evade calculation.

Base evade% = Evade Lvl * 5 + ((Dex + Quick) / 2 - 50) * 5%)

No clue if it hard capped at 50%, but sounds logical.
Make a duel with a lvl 1 player and check.

Tue 28 May 2019 5:08 AM by jelzinga_EU

Ashok wrote: ↑
Sun 26 May 2019 1:02 PM
Quickness is uncapped for evade calculation.

Base evade% = Evade Lvl * 5 + ((Dex + Quick) / 2 - 50) * 5%)

No clue if it hard capped at 50%, but sounds logical.
Make a duel with a lvl 1 player and check.

Bit related - but would it be possible if you added dummies to the server who actually fight back ? A bit like the dummies you have up now, so stationary, but they do hit back. Add a level 1 to it too and these things, as well as reactionaries and procs and such could be tested better too

Tue 28 May 2019 4:31 PM by Hejjin

jelzinga_EU wrote: ↑
Tue 28 May 2019 5:08 AM
Ashok wrote: ↑
Sun 26 May 2019 1:02 PM
Quickness is uncapped for evade calculation.

Base evade% = Evade Lvl * 5 + ((Dex + Quick) / 2 - 50) * 5%)

No clue if it hard capped at 50%, but sounds logical.
Make a duel with a lvl 1 player and check.

Bit related - but would it be possible if you added dummies to the server who actually fight back ? A bit like the dummies you have up now, so stationary, but they do hit back. Add a level 1 to it too and these things, as well as reactionaries and procs and such could be tested better too

I like the idea, but it is in the wrong forum, add it to suggestion and I certainly support it.