Evasive disc fix?

[gnode]

I tested my evasive disc today (releasing kunark on my server soon) and noticed evasive seems to avoid waaaaaaaay too much. If my memory is correct, it should only avoid ~50% of incoming hits, but it feels more like 80-90%. It also resets quick, but I don't recall exactly what the refresh timer is supposed to be.

I havent found any direct fixes on the forum, but saw Trevius allude to one he had fixed in the past that may have had something to do with spells file. This is what I currently have for evasive disc. If anyone could bold what I need to change, I would greatly appreciate it:

4503^Evasive Discipline^PLAYER_1^^^^You assume an evasive fighting style.^ assumes an evasive fighting style.^You return to your normal fighting style.^200^^0^0^0^0^468000^11^30^0^0^50^-33^0^0^0^0^0^0^0^0^0^0^-1^-1^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^2503 ^2119^-1^-1^-1^-1^1^1^1^1^-1^-1^-1^-1^100^100^100^100^100^100^100^100^100^100^100^100^ 0^1^0^0^172^184^254^254^254^254^254^254^254^254^25 4^254^6^0^15^-1^0^0^52^255^255^255^255^255^255^255^255^255^255^2 55^255^255^255^255^27^13^0^51^0^0^0^0^0^0^0^0^0^0^ 0^0^0^0^0^0^0^0^100^0^1^326^1^0^0^1^0^0^0^0^0^4503 ^27^117^^0^0^0^0^0^0^0^0^1^1^0^0^0^0^1^10^0^0^-47^134^-68^-99^11^30^0^1^0^1^0^0^0^0^0^0^0^0^0^0^0^0^1^1^0^0

[trevius]

Well, I have just adjusted the rate of the increase you get from using this disc in the spell file where you pointed out. Try the Ailia/Bleh spell editor from the tools section and it should be pretty straight forward on what you need to do to fix it.

Ultimately though, it seems like something probably needs to be adjusted in the source for how these percentages are handled. I know that the evasion disc is definitely not calculated correctly (even though I think it used to be months ago). I also know that some other percentages are not calculated correctly like some proc rate modifiers. I had a level 71 bard song directly from the EQLive spell list that was supposed to increase the proc rate for bard songs by only 102%, which to me means it should only be making proc rate slightly more than double what it currently is. But, this song was making bards proc almost every swing, which was extremely overpowered. I had to reduce the proc rate setting down to like 5% to get it under control.

Jonthan's Mightful Caretaker BRD/71 1: Increase Attack Speed by 70%
2: Increase All Skills Damage Modifier by 6%
4: Increase ATK by 16 (L71) to 18 (L80)
7: Increase All Skills Minimum Damage Modifier by 204%
8: Increase Proc Modifier by 102%

I can only imagine that instead of multiplying these percentage increases by X amount and then dividing by 100, it is multiplying by X amount and then not dividing at all lol. So instead of evasive increasing avoidance by 50%, it is multiplying it by 50 so you avoid 50X more often, which means you get hit maybe 2% or the time or less. And that is almost exactly what I saw from watching this evasive bug.

Hmm, maybe I can look into the source of it and just add a / 100 to the end of the calculation if I can find it. That may correct many other issues where certain things aren't balanced properly. Though, I imagine AndMetal would probably be better at finding what is going wrong here considering all of his spell and AA work lately. But, if I can find it, I think it should be a simple solution. Of course then I will need to adjust the spell values back to what they were by default to match it up with the new correction.

[gnode]

Oh I just changed the number straight up to avoid "35".

What did you find works well for:
Chance to avoid me minimum, maximum

Does defensive have this same problem?

For defensive I have melee mitigation -45, -1

[gnode]

My data agrees with Trevius.

I set evasive down to like 2, and you definitely tank better with it than without, but it is not godly in the least. It seems like you avoid twice as much.. which is pretty much the theme of evasive.

So tweak it as you want.... 1, 2, 3, 4.... dont go much higher than that I would suggest.

[trevius]

I think this is the code that evasive is using to add the bonus to avoid chance:

spell_effects.cpp
case SE_AvoidMeleeChance:
{
#ifdef SPELL_EFFECT_SPAM
snprintf(effect_desc, _EDLEN, "Avoid Melee Chance: +%+i%%", effect_value);
#endif
// handled with bonuses
break;
}

And this may be there the bard song I mentioned is adding the bonus:
case SE_ProcChance:
{
#ifdef SPELL_EFFECT_SPAM
snprintf(effect_desc, _EDLEN, "Proc Chance: +%+i%%", effect_value);
#endif
// handled with bonuses
break;
}

[AndMetal]

Here's where it's calculated w/ the bonuses (zone/bonuses.cpp):
around line 723

case SE_AvoidMeleeChance:
{
//multiplier is to be compatible with item effects
//watching for overflow too
effect_value = effect_value<3000? effect_value * 10 : 30000;
if(newbon->AvoidMeleeChance < effect_value)
newbon->AvoidMeleeChance = effect_value;
break;
}

around line 857

case SE_ProcChance:
{
//multiplier is to be compatible with item effects
//watching for overflow too
effect_value = effect_value<3000? effect_value * 10 : 30000;
if(newbon->ProcChance < effect_value)
newbon->ProcChance = effect_value;
break;
}

In the case of evasive, the effect_value (base1 (http://www.eqemulator.net/wiki/wikka.php?wakka=SpellsUsTxt#effectbasevalue) in spells_us.txt (http://www.eqemulator.net/wiki/wikka.php?wakka=SpellsUsTxt)) is 50, which should equate to 50%. I would think this would mean whatever our chance was would be reduced by that much (so something like chancetohit *= (100 - mitigation) / 100). This is how it's calculated in the attack code:
zone/attack.cpp, around line 269

//subtract off avoidance by the defender
bonus = defender->spellbonuses.AvoidMeleeChance + defender->itembonuses.AvoidMeleeChance;
if(bonus > 0) {
chancetohit -= (bonus) / 10;
mlog(COMBAT__TOHIT, "Applied avoidance chance %.2f/10, yeilding %.2f", bonus, chancetohit);
}

However, it looks like item Avoidance isn't a straight percentage increase in mitigation. Since the spell effect is multiplied by 10, it looks like 1 point of Avoidance is equal to 0.1% mitigation. In addition, with the rule system, Avoidance is capped at 100, so 10% max. I'm thinking we can do something like this:
zone/attack.cpp

//subtract off avoidance by the defender
bonus = defender->spellbonuses.AvoidMeleeChance + defender->itembonuses.AvoidMeleeChance;
bonus /= 10; //Change from 10x, make it easier to read when converting to a percentage
if(bonus > 0) {
chancetohit *= (100 - bonus) / 100; //Decrease by %, so need to count down from 100, then divide by 100 to make it a percentage
mlog(COMBAT__TOHIT, "Applied avoidance chance %.2f/100, yeilding %.2f", bonus, chancetohit);
}


On a side note, I am a little confused: isn't mitigation supposed to be a decrease in damage from a swing, not a chance to completely avoid a hit? Shouldn't it only be completely avoiding a hit if we mitigate 100% (or more) of the damage? So, as a result, if a mob hit for 5000 damage max, and you had 50% mitigation, they would only hit for 2500 max? That's the way I remembered it from Live (although I never actually played a Warrior w/ Defensive), and why it was used for hard hitting mobs. It also made Warriors better tanks than other classes, because if you can mitigate 50% of the damage over a long duration (50% for 3 min w/ Defensive (http://lucy.allakhazam.com/spell.html?id=4503)) vs all damage for a short duration (10000% for 2 ticks on Fortitude Discipline (http://lucy.allakhazam.com/spell.html?id=4670)), then you don't have to be healed as much. The reason I remember this specifically is because I wasn't in a huge guild, so our MT was a Shadowknight (RIP Eldark), which made a lot of the Velious bosses almost impossible to do without a Warrior tagalong because of the additional healing needed to keep him alive, even with better equip than the warrior (I think this was around Luclin?) If that's the case, then mitigation is very broken at the moment, but shouldn't be impossible to fix (just need to change what happens when, and how).

Now, as far as ProcBonus, it ends up being calculated in the attack code also:
zone/attack.cpp, around line 3664 (in Mob::GetProcChances)

ProcBonus += float(itembonuses.ProcChance + spellbonuses.ProcChance) / 1000.0f;

ProcChance = 0.05f + float(mydex) / 9000.0f; //Base chance, based on dex + static chance to proc
ProcBonus += (ProcChance * AABonus) / 100; //AA modifier in addition to normal ProcBonus from items & spells, percentage of base chance?
ProcChance += ProcBonus; //Add the bonuses to the base chance
mlog(COMBAT__PROCS, "Proc chance %.2f (%.2f from bonuses)", ProcChance, ProcBonus);
return ProcChance;

So, if we use Jonthan's Mightful Caretaker (http://lucy.allakhazam.com/spell.html?id=11873) as our example, the effect_value is 102, which ends up being 1020. In GetProcChances, we start with 0, then the spell value gets divided to 1.02. When we try the proc in Mob::TryWeaponProc (both with & without augs), also in zone/attack.cpp (around line 3674), we generate a random float between 0 & 1. Since 1.02 is always > anything between 0 & 1, we will proc 100% of the time.

I assume this is supposed to be a multiplier (200% = 2x as likely vs base, etc) instead of a direct mod on the proc chance. We should be able to do something like this:

ProcBonus += float(itembonuses.ProcChance + spellbonuses.ProcChance) / 1000.0f;

ProcChance = 0.05f + float(mydex) / 9000.0f;
ProcBonus += (ProcChance * AABonus) / 100;
ProcChance *= ProcBonus; //Multiplier instead of flat bonus
mlog(COMBAT__PROCS, "Proc chance %.2f (%.2f from bonuses)", ProcChance, ProcBonus);
return ProcChance;

If someone wants to try this and/or commit to SVN, feel free (I'm having some issues w/ Visual Studio after the change to zone.vcproj).

[trevius]

LOL, you are right about the chance to hit. If you had max avoidance from items (100) and added evasive to that (50*10 = 500), the current code would subtract 60 from chance to hit. Even with no item avoidance, it would subract 50 from it. And according to this code here from attack.cpp, you would be getting hit at most 4% of the time down to 0 if you had just 40 avoidance lol.

bool Mob::CheckHitChance(Mob* other, SkillType skillinuse, int Hand)
{
/*
Father Nitwit:
Reworked a lot of this code to achieve better balance at higher levels.
The old code basically meant that any in high level (50+) combat,
both parties always had 95% chance to hit the other one.
*/
Mob *attacker=other;
Mob *defender=this;
float chancetohit = 54.0f;

So, your idea for avoidance sounds perfect. I will add that in right now and test it tonight. I may also try playing with the chance to hit, because I don't really like the idea that it is hard coded like that. No wonder players complain about only hitting less than 50% of the time! Shouldn't stats/AAs/items and skills be determining most of the chance to hit and not a hard coding?

I am still looking over your code for proc bonuses though. I am not sure I understand exactly what is going on there yet lol.

EDIT: I moved the Proc Chance Discussion to another thread here:

http://www.eqemulator.net/forums/showthread.php?p=158353#post158353

[trevius]

Even though I thought that code looked good, it isn't right yet. Looks like I will have to review everything that Mob::CheckHitChance is doing:

bool Mob::CheckHitChance(Mob* other, SkillType skillinuse, int Hand)
{
/*
Father Nitwit:
Reworked a lot of this code to achieve better balance at higher levels.
The old code basically meant that any in high level (50+) combat,
both parties always had 95% chance to hit the other one.
*/
Mob *attacker=other;
Mob *defender=this;
float chancetohit = 54.0f;

#if ATTACK_DEBUG>=11
LogFile->write(EQEMuLog::Debug, "CheckHitChance(%s) attacked by %s", defender->GetName(), attacker->GetName());
#endif

bool pvpmode = false;
if(IsClient() && other->IsClient())
pvpmode = true;

float bonus;

////////////////////////////////////////////////////////
// To hit calcs go here
////////////////////////////////////////////////////////

int8 attacker_level = attacker->GetLevel() ? attacker->GetLevel() : 1;
int8 defender_level = defender->GetLevel() ? defender->GetLevel() : 1;

//Calculate the level difference
sint32 level_difference = attacker_level - defender_level;
if(level_difference < -20) level_difference = -20;
if(level_difference > 20) level_difference = 20;
chancetohit += (145 * level_difference / 100);
chancetohit -= ((float)defender->GetAGI() * 0.015);

if(attacker->IsClient()){
int skilldiff = defender->GetSkill(DEFENSE) - attacker->GetSkill(skillinuse);
bonus = 0;
if(pvpmode){
if(skilldiff > 10){
bonus = -(2 + ((defender->GetSkill(DEFENSE) - attacker->GetSkill(skillinuse) - 10) / 10));
}
else if(skilldiff <= 10 && skilldiff > 0){
bonus = -(1 + ((defender->GetSkill(DEFENSE) - attacker->GetSkill(skillinuse)) / 25));
}
else{
bonus = (attacker->GetSkill(skillinuse) - defender->GetSkill(DEFENSE)) / 25;
}
}
else{
if(skilldiff > 10){
bonus = -(4 + ((defender->GetSkill(DEFENSE) - attacker->GetSkill(skillinuse) - 10) * 1 / 5));
}
else if(skilldiff <= 10 && skilldiff > 0){
bonus = -(2 + ((defender->GetSkill(DEFENSE) - attacker->GetSkill(skillinuse)) / 10));
}
else{
bonus = 1 + (((attacker->GetSkill(skillinuse) - defender->GetSkill(DEFENSE)) / 25));
}
}
chancetohit += bonus;
}
else{
//some class combos have odd caps, base our attack skill based off of a warriors 1hslash since
//it scales rather evenly across all levels for warriors, based on the defenders level so things like
//light blues can still hit their target.
uint16 atkSkill = (database.GetSkillCap(WARRIOR, (SkillType)_1H_SLASHING, defender->GetLevel()) + 5);
int skilldiff = defender->GetSkill(DEFENSE) - atkSkill;
bonus = 0;
if(skilldiff > 10){
bonus = -(4 + ((defender->GetSkill(DEFENSE) - atkSkill - 10) * 1 / 5));
}
else if(skilldiff <= 10 && skilldiff > 0){
bonus = -(2 + ((defender->GetSkill(DEFENSE) - atkSkill) / 10));
}
else{
bonus = 1 + ((atkSkill - defender->GetSkill(DEFENSE)) / 25);
}
chancetohit += bonus;
}

//I dont think this is 100% correct, but at least it does something...
if(attacker->spellbonuses.MeleeSkillCheckSkill == skillinuse || attacker->spellbonuses.MeleeSkillCheckSkill == 255) {
chancetohit += attacker->spellbonuses.MeleeSkillCheck;
mlog(COMBAT__TOHIT, "Applied spell melee skill bonus %d, yeilding %.2f", attacker->spellbonuses.MeleeSkillCheck, chancetohit);
}
if(attacker->itembonuses.MeleeSkillCheckSkill == skillinuse || attacker->itembonuses.MeleeSkillCheckSkill == 255) {
chancetohit += attacker->itembonuses.MeleeSkillCheck;
mlog(COMBAT__TOHIT, "Applied item melee skill bonus %d, yeilding %.2f", attacker->spellbonuses.MeleeSkillCheck, chancetohit);
}

//subtract off avoidance by the defender
bonus = defender->spellbonuses.AvoidMeleeChance + defender->itembonuses.AvoidMeleeChance;
if(bonus > 0) {
chancetohit -= (bonus) / 10;
mlog(COMBAT__TOHIT, "Applied avoidance chance %.2f/10, yeilding %.2f", bonus, chancetohit);
}

if(attacker->IsNPC())
chancetohit += (chancetohit * attacker->CastToNPC()->GetAccuracyRating() / 1000);

uint16 AA_mod = 0;
switch(GetAA(aaCombatAgility))
{
case 1:
AA_mod = 2;
break;
case 2:
AA_mod = 5;
break;
case 3:
AA_mod = 10;
break;
}
AA_mod += 3*GetAA(aaPhysicalEnhancement);
AA_mod += 2*GetAA(aaLightningReflexes);
AA_mod += GetAA(aaReflexiveMastery);
chancetohit -= chancetohit * AA_mod / 100;

//add in our hit chance bonuses if we are using the right skill
//does the hit chance cap apply to spell bonuses from disciplines?
if(attacker->spellbonuses.HitChanceSkill == 255 || attacker->spellbonuses.HitChanceSkill == skillinuse) {
chancetohit += (chancetohit * (attacker->spellbonuses.HitChance / 15.0f) / 100);
mlog(COMBAT__TOHIT, "Applied spell melee hit chance %d/15, yeilding %.2f", attacker->spellbonuses.HitChance, chancetohit);
}
if(attacker->itembonuses.HitChanceSkill == 255 || attacker->itembonuses.HitChanceSkill == skillinuse) {
chancetohit += (chancetohit * (attacker->itembonuses.HitChance / 15.0f) / 100);
mlog(COMBAT__TOHIT, "Applied item melee hit chance %d/15, yeilding %.2f", attacker->itembonuses.HitChance, chancetohit);
}

// Chance to hit; Max 95%, Min 30%
if(chancetohit > 1000) {
//if chance to hit is crazy high, that means a discipline is in use, and let it stay there
}
else if(chancetohit > 99) {
chancetohit = 99;
}
else if(chancetohit < 5) {
chancetohit = 5;
}

//I dont know the best way to handle a garunteed hit discipline being used
//agains a garunteed riposte (for example) discipline... for now, garunteed hit wins


#if EQDEBUG>=11
LogFile->write(EQEMuLog::Debug, "3 FINAL calculated chance to hit is: %5.2f", chancetohit);
#endif

//
// Did we hit?
//

float tohit_roll = MakeRandomFloat(0, 100);

mlog(COMBAT__TOHIT, "Final hit chance: %.2f%%. Hit roll %.2f", chancetohit, tohit_roll);

return(tohit_roll <= chancetohit);
}

[trevius]

I figured out what the problem was. There is just too much stuff being done with chancetohit at the point that the defense bonuses are calculated to actually set it with a percentage. I set the spell bonus check to do a percentage on the final value of chancetohit.

In attack.cpp remove this line:

bonus = defender->spellbonuses.AvoidMeleeChance + defender->itembonuses.AvoidMeleeChance;

And replace it with the line in RED here:
//subtract off avoidance by the defender
bonus = defender->itembonuses.AvoidMeleeChance;
if(bonus > 0) {
chancetohit -= (bonus) / 10; //
mlog(COMBAT__TOHIT, "Applied avoidance chance %.2f/10, yeilding %.2f", bonus, chancetohit);
}

And then, right above this section at the end of Mob::CheckHitChance:
mlog(COMBAT__TOHIT, "Final hit chance: %.2f%%. Hit roll %.2f", chancetohit, tohit_roll);

return(tohit_roll <= chancetohit);

Add the Lines in red:
//Reduce final chancetohit by % based on spell bonuses
bonus = (100 - (defender->spellbonuses.AvoidMeleeChance / 10)) / 100;
if(bonus > 0) {
chancetohit *= (bonus);
}

mlog(COMBAT__TOHIT, "Final hit chance: %.2f%%. Hit roll %.2f", chancetohit, tohit_roll);

return(tohit_roll <= chancetohit);

I tested this and it looks to work great. Everything works the same as before, accept now spell bonuses that are supposed to reduce hit chance are now factored into the final hit chance as a percentage.

Really, the code that AndMetal posted would probably work great as well if it was just moved to the end of Mob::CheckHitChance instead of being done in the middle of it. Doing it in the middle as a percentage really throws off the rest of the calculations.

I have no idea why "case SE_AvoidMeleeChance:" and "case SE_ProcChance:" are multiplying the spell values by 10, but if there is no other use for them, I think we could remove that multiplier and then remove the "/ 10" from the related code in Mob::CheckHitChance. No reason to do unneeded math 2 times!

[AndMetal]

I have no idea why "case SE_AvoidMeleeChance:" and "case SE_ProcChance:" are multiplying the spell values by 10, but if there is no other use for them, I think we could remove that multiplier and then remove the "/ 10" from the related code in Mob::CheckHitChance. No reason to do unneeded math 2 times!

If I had to guess, I would say it's because we're working with integers, not floats, so there's a fudge factor that we have to deal with: C++ rounds down when storing as an integer. As a result, it's better to work with larger numbers w/o decimals being rounded off, then dividing later where not as much is rounded off. Example:

Avoidance = 1 (from items)
Avoid Melee Chance = 21 (from spells)

The way is/was originally, it would end up being 1 + (20 * 10), so a bonus 211. Then we divide by 10, so 21.1, which gets rounded to 21 (this is our percentage to mitigate).

Using the new code, we would first calculate 1 / 10, which is .1, which rounds to 0. Later, we calculate (100 - (211 / 10)) / 100 which ends up being 0.789, which technically, because it's rounded, ends up providing no bonus, so nothing happens.

That's the main reason I calculated the bonus first, without dividing, then did the "conversion" to a percentage ((100 - bonus) / 100) in the chancetohit calculations, because it won't round until after it stores the result back to chancetohit.

I think what we might want to do is make bonus a float, and that should take care of most of these rounding issues, especially if you have less than 10 Avoidance (although we might have to do some casting for everything to work as expected). Since we're not talking rocket science, we shouldn't need to worry about using a double instead of a float.

However, we're still running into a much larger issue: mitigation (http://dictionary.reference.com/browse/mitigation) isn't a reduction in the chance to land a hit, it's a reduction in the amount of damage done. Unfortunately, if we change it right now, everyone who has +mitigation is going to be hit a lot more often, but for less damage, which will probably mean retuning a lot of content.

[KLS]

I changed the way evasive type effects are calculated to be like all other melee effects. Multiplicative not additive.

[trevius]

I think that is the way that they should be done. But I also think that may throw off the current combat system considerably. I was mainly just wanting to figure out how to fix the evasive disc without messing with everything else. I imagine with that change, we would probably have to rewrite alot of the chancetohit code to get things more in line with what they should be.

Though, making them multipliers instead of adding them will probably fix miss rates being so high in the high end stuff for NPCs. It also means a pretty major overhaul on all high end encounters to balance them again. I don't think NPCs get any avoidance bonuses like players, so it probably means players will still miss alot.

I will give it a try and see how it feels.

Looked at the code and I think it is missing a dividing factor of 10 for the bonus. 100 avoidance from items should only reduce hit rate by 10%. Also, since spell avoidance is multiplied by 10, Evasive Discipline would be 500. So, I think you can just add the 0 in red below to correct it:

//subtract off avoidance by the defender
bonus = defender->spellbonuses.AvoidMeleeChance + defender->itembonuses.AvoidMeleeChance;
if(bonus > 0) {
chancetohit -= ((bonus * chancetohit) / 1000);
mlog(COMBAT__TOHIT, "Applied avoidance chance %.2f/10, yeilding %.2f", bonus, chancetohit);
}

I will give this a try maybe tomorrow night. I really need to get a test server running so my players don't suffer while I am testing :)