The way you are calculating the crit factor seems to be incorrect. I believe you are adding the multipliers when they should be getting multiplied together. Also, Lethality works even more strangely since it does not increase critical strike damage but instead it increases critical strike damage **bonus**. I will elaborate on this in this post.

Thanks again for the time taken to provide such great detail, especially regarding the mechanics of Murder which I never would have known about without your help.

SimulationCraft does indeed distinguish between "critical damage modifiers" and "critical damage BONUS modifiers".

My understanding of the mechanics is as follows:

crit_damage = normal_damage * ( 1.0 + crit_bonus )

Spell: crit_bonus = 0.5

Attack: crit_bonus = 1.0

The standard equation I've seen used throughout EJ is of the form:

crit_bonus = ( ( 1.0 + crit_bonus ) * ( 1.0 + crit_damage_mod ) - 1.0 ) * ( 1.0 + crit_damage_BONUS_mod )

As you point out, there may be multiple "damage_mods" and "damage_BONUS_mods" and it is important that they get combined in the right order.

In traditional spreadsheet applications, every spell/attack is usually coded to understand each and every talent, buff, debuff, and passive item effect that modifies it. Given the scope of SimulationCraft I simply could not do that. The chance for error and the difficulty it posed to maintenance made it impossible. Instead I implemented a hierarchy of modifiers:

1: mods specific to a spell/attack

2a: mods applied to all spells of a class

2b: mods applied to all attacks of a class

3a: mods applied to all spells

3b: mods applied to all attacks

4: mods applied to all actions (spells + attacks)

Unfortunately, this makes it quite difficult to model "critical damage modifiers" because of their order dependency. (The beta version of the Shaman Elemental Oath was particularly painful because it represented a dynamic critical damage modifier that forced me to defer a great deal of calculation.)

I decided to revisit the crit_bonus formula to see if there was an alternative expression that gave me more freedom in how it was combined, while still staying within the statistical margins used to confirm the original formulation. With the exception of passive talents, which first stack additively, all crit bonus modifiers are designed to stack multiplicatively. Essentially, this means that "critical damage modifiers" need to be translated into "critical damage BONUS modifiers".

This is the model that I use:

Spells:

crit_bonus = 0.5

crit_bonus *= ( 1.0 + 3 * crit_damage_mod_1 )

crit_bonus *= ( 1.0 + 3 * crit_damage_mod_2 )

etc...

crit_bonus *= ( 1.0 + crit_damage_BONUS_mod_1 )

crit_bonus *= ( 1.0 + crit_damage_BONUS_mod_2 )

etc...

crit_bonus *= ( 1.0 + ( passive_talent_crit_damage_BONUS_mod_1 + passive_talent_crit_damage_BONUS_mod_1 + ... ) )

Attacks:

crit_bonus = 1.0

crit_bonus *= ( 1.0 + 2 * crit_damage_mod_1 )

crit_bonus *= ( 1.0 + 2 * crit_damage_mod_2 )

etc...

crit_bonus *= ( 1.0 + crit_damage_BONUS_mod_1 )

crit_bonus *= ( 1.0 + crit_damage_BONUS_mod_2 )

etc...

crit_bonus *= ( 1.0 + ( passive_talent_crit_damage_BONUS_mod_1 + passive_talent_crit_damage_BONUS_mod_1 + ... ) )

For example.....

A 3% mod on total spell critical strike damage is equivalent to a 9% mod on just the critical damage portion.

A 3% mod on total attack critical strike damage is equivalent to a 6% mod on just the critical damage portion.

With this formulation, the only part that is absolutely necessary to include in the spell/attack initialization is the contribution from passive talents.

Specifically, the code initializes the following variables:

base_crit_bonus = 0.5 or 1.0 depending upon spell/attack

player_crit_bonus = 1.0

target_crit_bonus = 1.0

These are combined when an action is executed: base_crit_bonus * player_crit_bonus * target_crit_bonus

The base_crit_bonus is modified during initialization to model talents.

The player_crit_bonus is used to model the meta gems at steps 3a and 3b in the list above.

The degenerative forms of these equations, in which there is only one (or zero) "crit_damage_mod", will match exactly the formula at the top of this post. It starts to diverge when two or more "crit_damage_mod" variables come into play, as is the case apparently with RED and Murder. However, the difference in this case is quite small and well within a reasonable margin of error.

Are there any contant damage attacks that can be used to 100% confirm the way in which multiple "crit_damage_mod" variables are combined? If we are forced to rely upon min/max ranges of critical strike damage, then it is likely that both models will always fit the data since the differences are so small......

I'm certainly open to change, but sometimes I am forced to make minor modeling compromises (as all TC does) in order to reduce complexity. Sometimes that complexity is of a runtime nature and sometimes that complexity is of an engineering nature......