Emailed this to Eralun over the weekend but just don't want it to get lost.
I have spent the morning trying to figure out what is wrong with the values outputted by the Sim when I compare them to my actual combat parses. I was thinking it had to do with haste (and there may still be a haste component to it) but actually it's Armor Penetration that is causing the discrepancy.
There are two things wrong with how we have Armor Penetration coded. Both lines are in EnhSim.cpp
acmax_ = static_cast<int>(400.0 + (85.0 * ATTACKER_LEVEL) + (4.5 * 85.0 * (ATTACKER_LEVEL - 59.0)));
The code should be going off TARGET_LEVEL not ATTACKER_LEVEL since the actual formula is
The other issue is
acdebuff_ = (float)armor_base_ * (1.0f - armor_debuff_major_) * (1.0f - armor_debuff_minor_);
Which has the two debuffs stacking multiplicatively, except according to the wiki they stack additively.
[quote from wowwiki]
Calculating the ARP it's done in 2 parts:
First up - the debuffs. These reduce your target's initial armor. For example, if your target has 10k armor and it gets 20% sunder, its armor would be 8k. The debuffs stack additively, so Faerie_Fire will stack with sunder, totaling a 25% reduction on the target, taking it to 7.5k armor.
Second, comes the formula GC provided, you grab the armor after the debuff calculation and to that armor you apply the formula (armor + C)/3. Using the same example as before, lets say the target is level 80, so C=15232.5, now calculate (7500 + 15232.5)/3 = 7577.5. This makes the target's armor lower than the result, meaning that each 1% removes 750 armor and you are hitting a 0 armor target on the 100% ARP get. The ArP "buffs" (items, stances and such) stack additively too, meaning that 90% ARP on battle stance for a warrior would mean a 100% ARP final.[/quote]
At least it should be pretty easy to fix, just change attacker to target and then make the major and minor debuffs additive with each other.