[trevius]

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.