Go Back   EQEmulator Home > EQEmulator Forums > Support > Spell Support

Spell Support Broken Spells? Want them Fixed? Request it here.

Reply
 
Thread Tools Display Modes
  #1  
Old 10-05-2008, 06:50 PM
gnode
Hill Giant
 
Join Date: Aug 2008
Location: TX
Posts: 105
Default Evasive disc fix?

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
Reply With Quote
  #2  
Old 10-05-2008, 07:04 PM
trevius's Avatar
trevius
Developer
 
Join Date: Aug 2006
Location: USA
Posts: 5,946
Default

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.

Code:
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.
__________________
Trevazar/Trevius Owner of: Storm Haven
Everquest Emulator FAQ (Frequently Asked Questions) - Read It!
Reply With Quote
  #3  
Old 10-05-2008, 07:11 PM
gnode
Hill Giant
 
Join Date: Aug 2008
Location: TX
Posts: 105
Default

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
Reply With Quote
  #4  
Old 10-05-2008, 11:42 PM
gnode
Hill Giant
 
Join Date: Aug 2008
Location: TX
Posts: 105
Default

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.
Reply With Quote
  #5  
Old 10-06-2008, 01:17 AM
trevius's Avatar
trevius
Developer
 
Join Date: Aug 2006
Location: USA
Posts: 5,946
Default

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

spell_effects.cpp
Code:
			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:
Code:
			case SE_ProcChance:
			{
#ifdef SPELL_EFFECT_SPAM
				snprintf(effect_desc, _EDLEN, "Proc Chance: +%+i%%", effect_value);
#endif
				// handled with bonuses
				break;
			}
__________________
Trevazar/Trevius Owner of: Storm Haven
Everquest Emulator FAQ (Frequently Asked Questions) - Read It!
Reply With Quote
  #6  
Old 10-06-2008, 03:51 PM
AndMetal
Developer
 
Join Date: Mar 2007
Location: Ohio
Posts: 648
Default

Here's where it's calculated w/ the bonuses (zone/bonuses.cpp):
around line 723
Code:
                        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
Code:
                        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
Code:
	//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
Code:
	//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)
Code:
	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:
Code:
	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).
__________________
GM-Impossible of 'A work in progress'
A non-legit PEQ DB server
How to create your own non-legit server

My Contributions to the Wiki
Reply With Quote
  #7  
Old 10-14-2008, 05:28 AM
trevius's Avatar
trevius
Developer
 
Join Date: Aug 2006
Location: USA
Posts: 5,946
Default

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.

Code:
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
__________________
Trevazar/Trevius Owner of: Storm Haven
Everquest Emulator FAQ (Frequently Asked Questions) - Read It!

Last edited by trevius; 10-15-2008 at 04:10 AM..
Reply With Quote
  #8  
Old 10-14-2008, 11:04 PM
trevius's Avatar
trevius
Developer
 
Join Date: Aug 2006
Location: USA
Posts: 5,946
Default

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:

Code:
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);
}
__________________
Trevazar/Trevius Owner of: Storm Haven
Everquest Emulator FAQ (Frequently Asked Questions) - Read It!
Reply With Quote
  #9  
Old 10-15-2008, 06:13 AM
trevius's Avatar
trevius
Developer
 
Join Date: Aug 2006
Location: USA
Posts: 5,946
Default

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:

Code:
	bonus = defender->spellbonuses.AvoidMeleeChance + defender->itembonuses.AvoidMeleeChance;
And replace it with the line in RED here:
Code:
	//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:
Code:
	mlog(COMBAT__TOHIT, "Final hit chance: %.2f%%. Hit roll %.2f", chancetohit, tohit_roll);
	
	return(tohit_roll <= chancetohit);
Add the Lines in red:
Code:
	//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!
__________________
Trevazar/Trevius Owner of: Storm Haven
Everquest Emulator FAQ (Frequently Asked Questions) - Read It!

Last edited by trevius; 10-15-2008 at 02:19 PM..
Reply With Quote
  #10  
Old 10-16-2008, 01:43 AM
AndMetal
Developer
 
Join Date: Mar 2007
Location: Ohio
Posts: 648
Default

Quote:
Originally Posted by trevius View Post
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.
__________________
GM-Impossible of 'A work in progress'
A non-legit PEQ DB server
How to create your own non-legit server

My Contributions to the Wiki
Reply With Quote
  #11  
Old 10-16-2008, 06:13 AM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default

I changed the way evasive type effects are calculated to be like all other melee effects. Multiplicative not additive.
Reply With Quote
  #12  
Old 10-16-2008, 06:55 AM
trevius's Avatar
trevius
Developer
 
Join Date: Aug 2006
Location: USA
Posts: 5,946
Default

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:

Code:
	//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
__________________
Trevazar/Trevius Owner of: Storm Haven
Everquest Emulator FAQ (Frequently Asked Questions) - Read It!

Last edited by trevius; 10-16-2008 at 04:16 PM..
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 02:58 PM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3