Evasive disc fix?

[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 in spells_us.txt) 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) vs all damage for a short duration (10000% for 2 ticks on Fortitude Discipline), 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 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/sho...353#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]

Originally Posted by trevius

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