Attack Rating Calculations

**trevius** · #1 11-12-2008, 10:03 AM

Tonight, I wrote a change for #showstats to try to make it show the correct attack rating for players. I used the exact same code that the source uses to calculate attack to factor into damage. Here is the calculation:

Code:

		if(attacker->IsClient())
			attackRating = attacker->GetATK() + ((attacker->GetSTR() + attacker->GetSkill(OFFENSE)) * 9 / 10);
		else
			attackRating = attacker->GetATK() + (attacker->GetSTR() * 9 / 10);

I found that this calculation is WAY off from what the character window shows.

After much testing of different values, I have found what I think to be very accurate numbers for the equation. We were also missing some major factors into it as well, such as skill for the item equiped.

Strength - 66 * 0.9
Attack from items * 1.342
skill in use (item type equiped in primary slot) * 2.69
offense skill * 1.342

I haven't tested this yet, but I think this may work to do the calculations above. I did the math manually a few times and it was extremely accurate within maybe 2 or 3 points off or so.

Code:

   if(this->IsClient())
      attackRating = (((GetATK() + GetSkill(OFFENSE)) * 1.342) + ((GetSTR() - 66) * .9) + (GetSkill(skillinuse) * 2.69));
   else
      attackRating = GetATK() + (GetSTR() * 9 / 10);

To test this, tomorrow night I will probably put this into #showstats like this:

Code:

void Mob::ShowStats(Client* client) {
   float attackRating = 0;
	if(this->IsClient()) {
		attackRating = (((GetATK() + GetSkill(OFFENSE)) * 1.342) + ((GetSTR() - 66) * .9) + (GetSkill(skillinuse) * 2.69));
		//Need to add a way to calculate the skill of the weapon in the primary slot instead of using skillinuse
		int32	AR_Cap = 0;  //Attack Rating Cap
		AR_Cap = (GetSkill(OFFENSE) + GetSkill(skillinuse) ) * 5;  //This isn't correct, but putting it here until I have the correct formula for caps
		if (attackRating > AR_Cap)
			attackRating = AR_Cap;

		if (attackRating < 10)
			attackRating = 10;
	}
	else
	attackRating = GetATK() + (GetSTR() * 9 / 10);

	client->Message(0, "Name: %s %s", GetName(), lastname);
	client->Message(0, "  Level: %i  MaxHP: %i  CurHP: %i  AC: %i  Class: %i", GetLevel(), GetMaxHP(), GetHP(), GetAC(), GetClass());
	client->Message(0, "  MaxMana: %i  CurMana: %i  ATK: %i  Size: %1.1f", GetMaxMana(), GetMana(), attackRating, GetSize());

If that proves to be accurate, we might want to consider altering all other parts of the code that rely on calculating attack properly.

***EDIT: Editing the code as I refine it to make it more accurate***

**KLS** · #2 11-12-2008, 02:26 PM

Attack rating isn't supposed to be what the character window shows, this is by design. Atk is composed of two parts. One that overwhelms mitigation and one that overwhelms avoidance. It would be cool for showstats but overall I'm pretty happy with the formula for the mitigation formula.

**trevius** · #3 11-12-2008, 08:02 PM

I am still working to refine the calculations to have them as accurate as possible. Currently, I still need to figure out the equation to calculate attack rating caps. I also need to write some code for it to check the skill value of the weapon type in the primary slot (using skillinuse isn't exactly how it works).

I will be pretty happy if we can just get #showstats working more accurately. But, I do think that this might be worth considering for actual mitigation calculation once the formula is all done and tested. If there was only a slight difference between the actual formula and the formula currently used in the source, then it wouldn't be a big deal. But, in some cases, the server is using half or less of what the character screen shows. It really has a huge range and doesn't scale the same as the calculations from the client at all. Plus, there currently doesn't seem to be anything that sets attack rating caps, which means that worn attack can be making a huge impact on actual mitigation. I also don't see where weapon skill is being used at all when calculating mitigation, and if that is true, you could have 1 in the skill or 300 in the skill and still hit for the same amounts (though you wouldn't land nearly as many hits). Let me show a couple of example equations.

Player A Stats:
100 STR
100 Offense Skill
100 Weapon Skill (using 1hs or whatever)
0 Worn/Spell attack

Player B Stats:
200 STR
200 Offense Skill
200 Weapon Skill
50 Worn/Spell attack

Player C Stats:
300 STR
300 Offense Skill
300 Weapon Skill
200 Worn/Spell attack

Player D Stats:
380 STR
252 Offense Skill
1 Weapon Skill (using a weapon they don't have skill in yet)
500 Worn/Spell attack

Player E Stats:
380 STR
252 Offense Skill
300 Weapon Skill
500 Worn/Spell attack

Current Formula:
Worn Attack + ((Strength + Offense) * 0.9) = Total Attack Rating

PlayerA: 0 + ((100 + 100) * 0.9) = 180
PlayerB: 50 + ((200 + 200) * 0.9) = 410
PlayerC: 200 + ((300 + 300) * 0.9) = 740
PlayerD: 500 + ((380 + 252) * 0.9) = 1068.8
PlayerE: 500 + ((380 + 252) * 0.9) = 1068.8

New Formula:
((Worn Attack + Offense) * 1.342) + ((Strength - 66) * 0.9) + (Weapon Skill * 2.69)

PlayerA: ((0 + 100) * 1.342) + ((100 - 66) * 0.9) + (100 * 2.69) = 433.8
PlayerB: ((50 + 200) * 1.342) + ((200 - 66) * 0.9) + (200 * 2.69) = 994.1
PlayerC: ((200 + 300) * 1.342) + ((300 - 66) * 0.9) + (300 * 2.69) = 1688.6
PlayerD: ((500 + 252) * 1.342) + ((380 - 66) * 0.9) + (1 * 2.69) = 1294.474
PlayerE: ((500 + 252) * 1.342) + ((380 - 66) * 0.9) + (300 * 2.69) = 2098.784

So, basically, the 2 are fairly close in scaling. For the current formula, Strength is scaling the same as the Offense skill, which isn't quite accurate since Offense should be adding more and scaling a bit faster than strength. Also, worn/spell attack is having basically double the effect that it should be, since weapon skill isn't being factored into the equation to make worn/spell attack less of a factor. Another problem is that a level 1 is starting off with way too much attack since the 66 isn't being subtracted to account for starting stats. So, a level 1 high elf wizard with 55 strength (lowest you can make) is starting out with 49.5 attack, when they should only have 10 (10 is the min value). Using the new formula, that wizard would have -9.9, which would cause them to be set to 10 attack until their attack was raised to be over 10.

In reality though, other than the lack of weapon skill check, and lack of attack caps, the current formula works fairly similar to the new one. But, I do think using the new one would make it a bit more accurate. I think it would be very simple to use the new one and have it output about the same mitigation as it does now. All we would need to do is divide the total by about 2 to 2.4 or so. That divider could be set as a rule to allow people to tune it to lower or higher end encounters/equipment. I also think that attack caps should be set as a rule to give people the option to use them or not.

Ultimately, the system works pretty well as it is. I am not complaining about that. But, if we are striving for accuracy and to emulate live as close as possible, I think this should at least be considered.

**trevius** · #4 11-13-2008, 01:36 AM

To get the skill value of the item being used in the primary spot, I am trying to write a function to handle it. I am not sure if this will work as it is, but might be worth a shot. Basically, it is supposed to get the item ID from the primary slot, and then determine the item type of that item. Finally, it checks the skill value of the player for the skill that item type uses.

I guess this could go in mob.cpp:

Code:

int Mob::GetPrimarySkillValue(SkillType &PrimarySkill, const ItemInst* Item_ID)
{
	int16 Item_ID = CastToClient()->GetItemIDAt(13);

	if (Item_ID = NULL)
		PrimarySkill = HAND_TO_HAND;

	else {
		const Item_Struct* item = Item_ID->GetItem();

		switch (item->ItemType)
		{
			case ItemType1HS: // 1H Slashing
			{
				PrimarySkill = _1H_SLASHING;
				break;
			}
			case ItemType2HS: // 2H Slashing
			{
				PrimarySkill = _2H_SLASHING;
				break;
			}
			case ItemTypePierce: // Piercing
			{
				PrimarySkill = PIERCING;
				break;
			}
			case ItemType1HB: // 1H Blunt
			{
				PrimarySkill = _1H_BLUNT;
				break;
			}
			case ItemType2HB: // 2H Blunt
			{
				PrimarySkill = _2H_BLUNT;
				break;
			}
			case ItemType2HPierce: // 2H Piercing
			{
				PrimarySkill = PIERCING;
				break;
			}
			case ItemTypeHand2Hand:
			{
				PrimarySkill = HAND_TO_HAND;
				break;
			}
			default:
			{
				PrimarySkill = NULL;
				break;
			}
		}
	}

	uint16 skill = GetSkill(PrimarySkill);

	return skill;
}

If anyone has any corrections or suggestions on how to do it better, I would be very happy to hear it. I am fairly certain that this will fail to even compile lol.

Once that function is working, all I will need to figure in is the attack rating cap formula, which should be fairly simple. And the new code for #showstats with this function would look like this:

Code:

void Mob::ShowStats(Client* client) {
	float attackRating = 0;

	if(this->IsClient()) {
		attackRating = (((GetATK() + GetSkill(OFFENSE)) * 1.342) + ((GetSTR() - 66) * .9) + (GetPrimarySkillValue() * 2.69));
		int32	AR_Cap = 0;  //Attack Rating Cap
		AR_Cap = (GetSkill(OFFENSE) + GetPrimarySkillValue() ) * 5;  //This isn't correct, but putting it here until I have the correct formula for caps
		if (attackRating > AR_Cap)
			attackRating = AR_Cap;

		if (attackRating < 10)
			attackRating = 10;
	}
	else
	attackRating = GetATK() + (GetSTR() * 9 / 10);

	client->Message(0, "Name: %s %s", GetName(), lastname);
	client->Message(0, "  Level: %i  MaxHP: %i  CurHP: %i  AC: %i  Class: %i", GetLevel(), GetMaxHP(), GetHP(), GetAC(), GetClass());
	client->Message(0, "  MaxMana: %i  CurMana: %i  ATK: %i  Size: %1.1f", GetMaxMana(), GetMana(), attackRating, GetSize());

If I get this attack rating calculation working smoothly, I may try to just make a function to handle the whole thing, so we could just use GetTotalATK() where needed instead of doing the same code over and over.

That code would be something like this:
EDIT: Change the code below for GetTotalATK() a bit.
client.cpp

Code:

uint16 Client::GetTotalATK()
{
	int16 AttackRating = 0;

	if(IsClient()) {
		AttackRating = (((GetATK() + GetSkill(OFFENSE)) * 1.342) + ((GetSTR() - 66) * 0.9) + (GetPrimarySkillValue() * 2.69));
		int16	AR_Cap = 0;  //Attack Rating Cap
		AR_Cap = (GetSkill(OFFENSE) + GetPrimarySkillValue()) * 10;  //This isn't correct, but putting it here until I have the correct formula for caps
		if (AttackRating > AR_Cap)
			attackRating = AR_Cap;

		if (AttackRating < 10)
			attackRating = 10;
	}
	else
	AttackRating = GetATK() + (GetSTR() * 9 / 10);

	return AttackRating;
}

Then, the #showstats would just need to have GetATK() replaced with GetTotalATK(), and it should show more accurate values. For the actual attack code to use this, it could just replace the current Attack Rating calculations in mitigation, and just do (GetTotalATK() / 2) instead to get it back to about the same as it is now. NPC DPS wouldn't be effected by this, just players. And by dividing it by 2, it should get them back to about the same as they are now.

Of course, again, if anyone has any corrections or suggestions on how to code this stuff properly, I would be glad to hear them. My coding skills are still really bad and there are certain things I don't understand well or at all yet. I mostly just work by examples I find elsewhere in the source.

**AndMetal** · #5 11-17-2008, 06:42 AM

Quote:

Originally Posted by trevius

mob.cpp:

Code:

int Mob::GetPrimarySkillValue(SkillType &PrimarySkill, const ItemInst* Item_ID)
{
	int16 Item_ID = CastToClient()->GetItemIDAt(13);

	if (Item_ID = NULL)
		PrimarySkill = HAND_TO_HAND;

	else {
		const Item_Struct* item = Item_ID->GetItem();

		switch (item->ItemType)
		{
			case ItemType1HS: // 1H Slashing
			{
				PrimarySkill = _1H_SLASHING;
				break;
			}
			case ItemType2HS: // 2H Slashing
			{
				PrimarySkill = _2H_SLASHING;
				break;
			}
			case ItemTypePierce: // Piercing
			{
				PrimarySkill = PIERCING;
				break;
			}
			case ItemType1HB: // 1H Blunt
			{
				PrimarySkill = _1H_BLUNT;
				break;
			}
			case ItemType2HB: // 2H Blunt
			{
				PrimarySkill = _2H_BLUNT;
				break;
			}
			case ItemType2HPierce: // 2H Piercing
			{
				PrimarySkill = PIERCING;
				break;
			}
			case ItemTypeHand2Hand:
			{
				PrimarySkill = HAND_TO_HAND;
				break;
			}
			default:
			{
				PrimarySkill = NULL;
				break;
			}
		}
	}

	uint16 skill = GetSkill(PrimarySkill);

	return skill;
}

Per trev and my collaboration, corrections to the first function:

client.cpp:

Code:

uint16 Client::GetPrimarySkillValue()
{
	uint8 type = m_inv.GetItem(13)->GetItem()->ItemType;	//is this the best way to do this?
	SkillType skill = HIGHEST_SKILL + 1;	//because NULL == 0, which is 1H Slashing, & we want it to return 0 from GetSkill

	if (!type)
		skill = HAND_TO_HAND;

	else {

		switch (type)
		{
			case ItemType1HS: // 1H Slashing
			{
				skill = _1H_SLASHING;
				break;
			}
			case ItemType2HS: // 2H Slashing
			{
				skill = _2H_SLASHING;
				break;
			}
			case ItemTypePierce: // Piercing
			{
				skill = PIERCING;
				break;
			}
			case ItemType1HB: // 1H Blunt
			{
				skill = _1H_BLUNT;
				break;
			}
			case ItemType2HB: // 2H Blunt
			{
				skill = _2H_BLUNT;
				break;
			}
			case ItemType2HPierce: // 2H Piercing
			{
				skill = PIERCING;
				break;
			}
			case ItemTypeHand2Hand:
			{
				skill = HAND_TO_HAND;
				break;
			}
		}
	}

	return GetSkill(skill);
}

One thing to note is that we'll probably want to put this in the Mob class, then create a virtual function in the NPC class to always return 0, since as far as we know, NPCs don't have "skillz", plus a virtual function (above) for the Client class.

**KLS** · #6 11-17-2008, 04:25 PM

NPCs have skills.

**trevius** · #7 11-17-2008, 05:04 PM

I think we can leave NPC Attack Rating as it is. There isn't really any reason at all I can think of to do any more work for calculating NPC Attack Rating. The only effect it would have would be changing the current DPS that they do. And, since everything is balanced in the current system all it would do would be to make everything have to be rebalanced.

But I do think we can consider changing player attack rating calculations for mitigation and such. If we use a divider after, it should get them mostly back in line with what they are now. But it will be a bit more accurate and will also account for weapon skill, which should be a huge factor in attack rating.

I will try to get the cap formulas figured out later tonight if I have time. I will also verify if there is any difference in the formula from class to class, as I have heard some classes have different worn/spell attack multipliers. Once I know the full formula, I might try to make a GetTotalATK() object that can be used where ever we want without bloating code.

Thanks again, AndMetal, for the help last night. I will give it a try tonight after I get my new VMWare test server running

**trevius** · #8 11-22-2008, 01:59 AM

The code below has been tested and works. But, there is one huge bug that still needs to be corrected before this can be added to the SVN. Currently, it works perfectly, accept if you have an empty primary slot. If the primary slot is empty and you run this command, it crashes the zone.

I will work on resolving the zone crash issue. If anyone has a suggestion, I would be willing to try it. Once I have a good solution, I will edit the code in this post to be the good code.

Also, note that I currently have 3 versions of attack showing on the command output. We can probably leave Worn Attack and Total Attack in there, but in the final version, we probably don't need the server seen attack rating. That is mostly just there for my testing purposes.

I still need to figure out the formula for attack rating caps, but I don't think that will be too hard. Once that is all done, I think this new formula should be pretty complete and fairly accurate.

EDIT: This code is now complete, tested and very accurate. All issues, including the crash and worn caps have been resolved. This has been added to the SVN in Revision. The only minor tweak left to correct is for +attack from spells that can exceed cap, such as Avatar/Champion.

mob.cpp

Code:

void Mob::ShowStats(Client* client) {

	int16 attackRating = 0;
	int16 WornCap = GetATK();

	if(IsClient())
		attackRating = GetATK() + ((GetSTR() + GetSkill(OFFENSE)) * 9 / 10);
	else
		attackRating = GetATK() + (GetSTR() * 9 / 10);

	if(WornCap > 250)
		WornCap = 250;

	client->Message(0, "Name: %s %s", GetName(), lastname);
	client->Message(0, "  Level: %i  MaxHP: %i  CurHP: %i  AC: %i  Class: %i", GetLevel(), GetMaxHP(), GetHP(), GetAC(), GetClass());
	client->Message(0, "  MaxMana: %i  CurMana: %i  Size: %1.1f", GetMaxMana(), GetMana(), GetSize());
	client->Message(0, "  Total ATK: %i  Worn ATK: %i  Worn ATK Capped: %i  Server Used ATK: %i", this->CastToClient()->GetTotalATK(), GetATK(), WornCap, attackRating);
	client->Message(0, "  STR: %i  STA: %i  DEX: %i  AGI: %i  INT: %i  WIS: %i  CHA: %i", GetSTR(), GetSTA(), GetDEX(), GetAGI(), GetINT(), GetWIS(), GetCHA());
	client->Message(0, "  MR: %i  PR: %i  FR: %i  CR: %i  DR: %i", GetMR(), GetPR(), GetFR(), GetCR(), GetDR());
	client->Message(0, "  Race: %i  BaseRace: %i  Texture: %i  HelmTexture: %i  Gender: %i  BaseGender: %i", GetRace(), GetBaseRace(), GetTexture(), GetHelmTexture(), GetGender(), GetBaseGender());
	client->Message(0, "  Last Warp Distance: %f Threshold Remaining: %f", GetLWDistance(), GetWarpThreshold());
	if (client->Admin() >= 100) {
		client->Message(0, "  EntityID: %i  PetID: %i  OwnerID: %i  AIControlled: %i", this->GetID(), this->GetPetID(), this->GetOwnerID(), this->IsAIControlled());
		if (this->IsClient()) {
			client->Message(0, "  CharID: %i  PetID: %i", this->CastToClient()->CharacterID(), this->GetPetID());
			client->Message(0, "  Endurance: %i, Max Endurance %i",client->GetEndurance(), client->GetMaxEndurance());
		}
		else if (this->IsCorpse()) {
			if (this->IsPlayerCorpse()) {
				client->Message(0, "  CharID: %i  PlayerCorpse: %i", this->CastToCorpse()->GetCharID(), this->CastToCorpse()->GetDBID());
			}
			else {
				client->Message(0, "  NPCCorpse", this->GetID());
			}
		}
		else if (this->IsNPC()) {
			int32 spawngroupid = 0;
			if(this->CastToNPC()->respawn2 != 0)
				spawngroupid = this->CastToNPC()->respawn2->SpawnGroupID();
			client->Message(0, "  NPCID: %u  SpawnGroupID: %u LootTable: %u  FactionID: %i  SpellsID: %u MerchantID: %i", this->GetNPCTypeID(),spawngroupid, this->CastToNPC()->GetLoottableID(), this->CastToNPC()->GetNPCFactionID(), this->CastToNPC()->GetNPCSpellsID(),this->CastToNPC()->MerchantType);
			client->Message(0, "  Accuracy: %i", CastToNPC()->GetAccuracyRating());
		}
		if (this->IsAIControlled()) {
			client->Message(0, "  AIControlled: AggroRange: %1.0f  AssistRange: %1.0f", this->GetAggroRange(), this->GetAssistRange());
		}
	}
}

client.cpp

Code:

uint16 Client::GetPrimarySkillValue()
{
	SkillType skill = HIGHEST_SKILL;  //because NULL == 0, which is 1H Slashing, & we want it to return 0 from GetSkill
	bool equiped = m_inv.GetItem(13);
	
	if (!equiped)
		skill = HAND_TO_HAND;

	else {

		uint8 type = m_inv.GetItem(13)->GetItem()->ItemType;  //is this the best way to do this?

		switch (type)
		{
			case ItemType1HS: // 1H Slashing
			{
				skill = _1H_SLASHING;
				break;
			}
			case ItemType2HS: // 2H Slashing
			{
				skill = _2H_SLASHING;
				break;
			}
			case ItemTypePierce: // Piercing
			{
				skill = PIERCING;
				break;
			}
			case ItemType1HB: // 1H Blunt
			{
				skill = _1H_BLUNT;
				break;
			}
			case ItemType2HB: // 2H Blunt
			{
				skill = _2H_BLUNT;
				break;
			}
			case ItemType2HPierce: // 2H Piercing
			{
				skill = PIERCING;
				break;
			}
			case ItemTypeHand2Hand: // Hand to Hand
			{
				skill = HAND_TO_HAND;
				break;
			}
			default: // All other types default to Hand to Hand
			{
				skill = HAND_TO_HAND;
				break;
			}
		}
	}

	return GetSkill(skill);
}

uint16 Client::GetTotalATK()
{
	int16 AttackRating = 0;
	int16 WornCap = GetATK();

	if(WornCap > 250)
		WornCap = 250;

	if(IsClient()) {
		AttackRating = ((WornCap * 1.342) + (GetSkill(OFFENSE) * 1.345) + ((GetSTR() - 66) * 0.9) + (GetPrimarySkillValue() * 2.69));

		if (AttackRating < 10)
			AttackRating = 10;
	}
	else
	AttackRating = GetATK() + (GetSTR() * 9 / 10);

	return AttackRating;
}

client.h - Anywhere in the file

Code:

	//This calculates total Attack Rating to match very close to what the client should show
	uint16 GetTotalATK();
	//This gets the skill value of the item type equiped in the Primary Slot
	uint16 GetPrimarySkillValue();

**trevius** · #9 11-22-2008, 07:37 AM

This code is now complete and is very accurate within about 1 point or so. All issues have been resolved. The only standing addition that needs to be made to be 100% finalized is for spell +attack that is supposed to exceed the worn cap. If there is a way to find the spell attack from spells like Avatar/Champion, it should be very easy to get it added to this code. I added this to the SVN as-is. Currently, it is only used for #showstats, but it could easily be expanded to be used for mitigation calculation. Feedback welcome

paaco · #10 11-22-2008, 10:42 AM

Nice Trev, compiling newest Rev now to check it out. Props to you and Andmetal for all the work and testing that went into this.

**KLS** · #11 11-22-2008, 07:15 PM

There's already a cap on worn atk in the code if I recall correctly so that's somewhat redundant if so.

I think it's fine staying just in showstats, the weapon skill isn't intended to be a part of the mitigation anyway.

**trevius** · #12 11-23-2008, 12:57 AM

Weapon skill makes up almost half of the Attack Rating Total. If attack rating is supposed to effect mitigation, then I don't see why weapon skill wouldn't be used for it. We don't need to emulate live, but I think if we wanted to, we would have to use the new attack formula. Then just dividing by 2 would get it very close to what it currently is. I am going to test it on my server a bit and see if it seems about the same or not. I don't mind leaving out of any combat calculations, but I am not really sure of any reason not to use it. Many MMO players care about the stats of their characters and can be pretty particular about them. I just think it might be nice if the server was using what their client says it is

As it is, you could switch between a 1hb that you have 300 skill in, and a 1hs that you have 1 skill in and you will hit for the same average hit on both (even though you will miss alot more with the 1hs with 1 skill).

I don't see any caps being used for attack currently. At least none that I could find or see in any of my testing. Using the newly adjusted #showstats command, it is easy to see what the servers sees your attack as, what the actual total attack is, what your worn attack is and what the worn attack cap is if you are being capped.

I am not trying to push the formula on anyone. Just trying to figure out why the current formula is better.

**KLS** · #13 11-23-2008, 03:31 AM

Hm maybe the ATK cap never made it in or *gasp* is broken =(

ATK is broken into 2 parts:

Avoidance ATK which bypasses a defender's avoidance AC. (We don't do this correctly at all). It is a factor of attackers weapon and offense skill versus the defender's defense skill. + whatever avoid and hit mods from gear and spells.

Mitigation attack which bypasses a defender's mitigation AC. (We do this mostly correctly tho I have a few choice tweaks I still am going to make.) This is a factor of strength and atk from mods, the strength part isn't completely proven or disproven because it affects the max hit you can do it's hard to tell without sony saying yay or nay.

AC is also broken into 2 parts. Neither of which we deal with properly tho we can calculate it almost completely we treat the lump as mitigation ac which is wrong.

Avoidance AC and mitigation AC which are basically the counterparts to the above.

ATK and AC aren't handled entirely correctly but I'd rather not replace one broken system with one equally broken... esp when the current broken system is pretty balanced until we can fix it.

**trevius** · #14 11-23-2008, 07:31 AM

I understand what you mean about replacing broken systems with other broken systems. If it isn't broken, why fix it? I don't think of the combat system as being broken, but I do think it could use some tweaks. And I am not trying to cause a headache here, so sorry if I am :P

As far as I understand it, attack rating is only supposed to effect how hard you hit for. Basically it just increases your average hit damage. I have never heard that attack actually effects your chance to hit. I think chance to hit is all based on skill levels + bonuses (and a few other things), but that is separate from attack. Anyone know this for sure either way?

I know as well as any server admin that making changes to these core systems can mean huge overhauls on content. Believe me when I say that I don't want to have to do that anymore than the next guy lol. Heck, I still change the avoidance bonus formula back to what it used to be every time I update the code on my server. But, I do think that by dividing the new code by 2 (or so), it would put things almost exactly back to what they are now, so little to no changes would be needed. And since it only effects player DPS a little, it wouldn't mean any real content changes.

Ideally I think it would be good to work towards a more refined combat system that is as close to accurate as possible. The only way that can happen is 1 step at a time. But, I definitely don't think any huge changes to combat would be taken well if things were changing more than once a year or so. So, I propose that we would try to completely fix the entire system and then add it all in 1 big change. If entire DBs need to be adjusted, at least it would only be 1 time then. I remember when the new AC system was added and that was a major nightmare, but the emu is better off for it now. I think a combat system overhaul would be useful too.

Basically, I think that it is fine to keep the new formula out of the combat system for now. If we can get enough stuff corrected and tuned with new and better systems, then we can put those in all at once when they are finalized. So, the new formula can stay on the back-burner till then (if it ever happens). I think it is good to know that it is out there and about as close to perfect as we will be able to get it. But, if any changes go in for attack rating (like caps), I think we might as well replace the whole system for it. Because, if we are going to make a big change like that, we might as well make it final and accurate.

I definitely don't plan to attempt to overhaul the combat system myself. Since most of it is just plain math formulas, I am able to figure out some of it on my own, but most of it doesn't have enough hard data to make accurate changes. Figuring out the formula for attack wasn't too bad, because I had clear numbers to work with client side. That isn't the case for most of the other systems. Most of it would be guess work, and I think most of the guess work is already pretty good.

Here is an idea; How about making a new rule (or a few rules) for enabling new combat system changes? So, we could let people decide if they want to use the current way, or try the new stuff. I think most servers would just want to use the old way until the new stuff was finalized, but newer servers might want to use the new ways, since they have less adjustments to make to current content. I know too many rules can bog down the code, so the number of rules would probably need to be limited. It is just an idea anyway. Just thinking out loud :P