Serge Camille edited this page Aug 24, 2015 · 1 revision
Clone this wiki locally

Spell Data

Broadly speaking, spells are composed of "spell data", and "effect data". Spell data contains the basic information about the spell, such as its name, cast time, resource cost, cooldown, tooltip description. Each spell data is linked to one or more effect data. Effect data describes the actual "actionable" properties of the spell, such as healing, applying an aura (buffs and debuffs), damaging, creating an object, summoning a pet, etc.

SimulationCraft extracts many aspects of spell and effect data to use in the simulator. The extracted data is used in class modules and more general features of the simulator to automate some of the workload for developers, as basic attributes of most spells can be directly gotten from the data, instead of individual developers keeping track of their values through experimentation, or by scouring forums for information. SimulationCraft also allows users to override the spell and effect data to perform simple value changes to explore "what if" scenarios, without having to perform actual code changes, and rebuild their simulator.

Spell Data Override

Overriding spell and effect data is done through the override.spell_data option. The option overrides the global spell data of the simulator; there is no way to override the spell data used by individual actors. It takes the form override.spell_data=<spell|effect>.<id>.<field>=value, where the different parts are:

  • spell or effect refers to the type of data that is to be changed
  • id is the numerical identifier of the data. The spell identifiers can be found through SpellQuery or third party websites, effect identifiers can be found through SpellQuery.
  • field is the name of the field in the data that is to be overridden with a new value. A list of valid field names for spells and effects is given below.

Some things need to be noted about the override system.

  1. It is an experimental feature, and as such is not meant to be used by typical SimulationCraft users
  2. It may have some un-intuitive results occasionally. This can be due to a multitude of things, including:
    • The class developer is not using spell data, but rather hardcoding values. This is very rare nowadays, but can still happen
    • The spell or effect that is being overridden is not the correct one. This can occasionally happen for more complex abilities. SimulationCraft tries to replicate Blizzard's way of using spells in the client as much as possible, some of which are not visible to normal users.
    • Class modules can occasionally cache spell data locally, for optimization reasons, or due to how the spell functions. Due to this, overriding spell data should always be done before the character definition in the simulator.

List of fields

The spell data can be overridden with the following fields. The list contains the name, value type, and description of the field.

  • prj_speed (float), The projectile speed of the spell in yards per second.
  • school (integer), School mask of the spell
  • scaling_class (integer), Internal value of the scaling class for the spell
  • spell_level (integer), Required level of the spell
  • max_level (integer), Maximum scaling level of the spell
  • min_range (float), Minimum range of the spell (currently unused)
  • max_range (float), Maximum range of the spell (currently unused)
  • cooldown (integer, milliseconds), The cooldown of the spell in milliseconds
  • internal_cooldown (integer, milliseconds), The internal cooldown of the spell in milliseconds
  • gcd (integer, milliseconds), The global cooldown of the spell in milliseconds
  • duration (integer, milliseconds), The duration of the aura in milliseconds
  • rune_cost (integer), The rune cost of the spell. The following values can be combined for the rune cost: 1: blood, 4: unholy, 16: frost, 64: death
  • runic_power_gain (integer), The runic power gain when the ability is used, multiplied by 10
  • max_stack (integer), The maximum stack of the aura
  • proc_charges (integer), The number of stacks per trigger for the aura
  • proc_chance (integer), The percent chance for the spell to trigger
  • cast_min (integer, milliseconds), The minimum cast time of the spell (used only for low level characters)
  • cast_max (integer, milliseconds), The maximum (normal) cast time of the spell
  • rppm (float), RPPM value of the proc. Since Simulationcraft 5.4.8 release 5

The effect data can be overridden with the following fields.

  • average (float), The average amount scaling coefficient for the effect
  • delta (float), The delta amount scaling coefficient for the effect
  • bonus (float), The bonus (in essence, per combo point) amount scaling coefficient for the effect
  • sp_coefficient (float), The spell power coefficient for the effect
  • ap_coefficient (float), The attack power coefficient for the effect
  • period (integer, milliseconds), The base tick time of the effect in milliseconds
  • base_value (integer), The base value of the effect (more discussion on this below)
  • misc_value1 (integer), The first "misc" value of the effect (use is effect type, or effect dependant)
  • misc_value2 (integer), The second "misc" value of the effect (use is effect type, or effect dependant)
  • chain_multiplier (float), The multiplier to apply spells when they jump from target to target
  • points_per_combo_points (float), "Old style" version of the bonus field. Unused
  • points_per_level (float), "Old style" version of the average field. Unused
  • die_sides (integer), "Old style" version of the delta field. Unused

The base_value field defines the "base value" of the effect in most cases, where there is no (player level, or item level) based scaling applied to it. For example with many buffs that affect the actor with a percentage modifier (This is arguably the most typical use of the value), this field specifies the percent modifier as an integer. Unfortunately, the meaning of the field is always dependant on the effect type, and ultimately, what Blizzard intended it to be. For example, it can also indicate the number of units to summon for a certain type of spell.


Below is a simple example to show how to implement one of the 1/6/2014 hot fixes for the Death Knight class. We begin by looking at the spell data of "Icy Talons", to figure out the effect that we need to change:

 $ simc spell_query=spec_spell.name=icy_talons
 Name             : Icy Talons (id=50887) [Off GCD]
 Class            : Frost Death Knight
 Spell Level      : 55
 Attributes       : ......x. x....... ........ ........   ........ ........ ........ ........ 
                  : ........ ........ ........ ........   ........ ........ ........ ..x...x. 
                  : ........ ........ ........ ........   ........ ........ ........ ........ 
                  : ........ ........ ........ ........   ........ ........ ........ ........ 
                  : ........ ........ ........ ........   ........ ........ ........ ........ 
                  : ........ ........ ........ ........   ........ ........ ........ ........ 
 Effects          :
 #1 (id=43156)    : Apply Aura (6) | Modify Melee Attack Speed% (319)
                    Base Value: 30 | Scaled Value: 30
 Description      : Your melee attack speed is increased by $s1%.

The only effect of the spell is to apply an aura that modifies the actor's melee attack speed% by 30 (the value in base_value field). We adjust the value to the new hotfixed value of 45.

 $ simc override.spell_data=effect.43156.base_value=45 spell_query=spec_spell.name=icy_talons
 Effects          :
 #1 (id=43156)    : Apply Aura (6) | Modify Melee Attack Speed% (319)
                    Base Value: 45 | Scaled Value: 45

Note that if the override had been put after the spell_query option, it would not have applied it correctly for the spell query.