In general the flow is from left to right across the main tabs at the top of the window.

• At Options you set common high-level directives.
• At Import you load your character profile from a variety of sources.
• At Simulate you make character-specific tweaks.
• At Overrides a super-user can specify custom parameters that will persist from run to run.
• At Examples you can see examples of all supported parameters including common usage.
• At Log you will find simple text reporting as well as any errors encountered.
• At Results you will find HTML output generated by the simulator.

Please note that the behavior of the command line and the buttons to either side are context-sensitive. Their function and labels may change as you navigate the main tabs.

• The label on the main button changes between Simulate!, Import! and Save! depending upon the active main tab. While a character profile is being imported or a simulation is running, the label will be set to Cancel!. Cancelling a simulation run early may still result in valuable information: The results posted are a statistical analysis of many iterations. Cancelling a simulation will simply reduce the number of iterations, increasing the reported statistical error.
• The progress bar is context-sensitive. When viewing a web page under Import or Results it will display the percent-completion of rendering the web page. Under all other tabs, the progress bar will report the percent-completion of the character import or the simulation run.
• The Back and Forward buttons to the left of the command-line allow you to cycle through the history of the main viewport. When viewing a web page under Import or Results they will cycle through the URL history. When viewing Globals, Simulate, or Overrides, these buttons will cycle through previous states. This history is persistent between runs.
• With the exception of the Import tab, pressing the Enter key while the command-line has focus is equivalent to clicking the main button.
• When the command-line has focus, the Up and Down keys cycle through the history of command-line text. This history is persistent between runs.
• The configuration script passed to the simulator is constructed by first adding the options implied by the button-settings under Options, followed by the text under Simulate, followed by the text under Overrides and finally including anything on the command line. It is important to understand that the last setting wins. Users already comfortable with earlier releases of the command-line-only application can use the the GUI command-line in the same manner. For example, one could type armory=us,llane,segv to download and simulate the Hunter Segv from server US-Llane.
• Any option that does not fit the parm=value paradigm is assumed to be the name of a script file which is subsequently loaded. For example, typing Raid_T11_372.simc on the command-line will load and simulate the shipped script that contains all supported class/spec combinations using 372 ilevel gear. While the history mechanism of the Back and Forward buttons should be sufficient for most needs, it can be convenient to save complicated parameter settings in an external file.

SimulationCraft has many, many options that can be loosely categorized into two groups, those that are applied to the active player and those that are applied globally. The Globals section of the Options tab is dedicated to the more commonly changed global parameters.

• Version: The mechanics of World of Warcraft are constantly changing. SimulationCraft endeavors to model the two most recent patch levels. This corresponds to Live and PTR. The Both option will simulate two characters at once: One character will run with Live mechanics and a second character with the name EvilTwinPTR will be run with PTR mechanics. The results will shown side-by-side for easy comparison.
• Latency: During simulation we do not attempt to model the actual latency in all internet traffic, but rather how that latency manifests itself in terms of the inevitable gaps between player actions. Rigorous testing has shown that these gaps differ greatly depending upon whether the preceding action has a cast-time (enabling queueing), is instant-cast (triggering the GCD), or is channeled (requiring extra care not to clip the last tick). SimulationCraft uses random values for these gaps, whose range is centered on user-supplied values.
• Iterations: The largest drawback of simulation is that in order to get meaningful answers, one must run the siulation many, many times to acquire a trustworthy statistical average. More iterations means better accuracy, at the cost of longer runtimes. When calculating scale factors one must iterate enough such that the simulation error margin is sufficiently smaller than the change in stat value being analyzed.
• Length(sec): It is important to understand that the length of the fight is a goal and not a hard limit. Half-way through the first iteration the health of the target (boss) is estimated based upon damage done up to that point. The simulation ends when the target dies and not when the desired fight length is reached. At the end of every proceeding iteration, the target health is re-evaluated based upon whether the fight ended early or late. The end result is that after many iterations, the average fight length matches the desired value.
• Vary Length: In order to smooth out the effects of very powerful procs and/or abilities one can tell the simulator to vary the fight length. The sim will perform an even distribution of fight lengths from length-variance to length+variance.
• Adds: While it is possible to specify raid events that spawn adds that are only temporary, this option specifies adds that are present the entire fight. It is vital to understand that SimC has not yet implemented multi-DoT support. Only abilities that affect multiple additional targets nearby the main target have been implemented, such as Cleave, Chain Lightning, and Blade Flurry. In addition, only those AoE spells occasionally used in single-target scenarios have been implemented.
• Fight Style: One of the most common criticisms of theorycrafting tools is that they only model tank-n-spank fights in which the player gets to stand perfectly still just hitting keys/buttons. SimulationCraft supports a wide array of raid events including movement, stuns, splash damage, target (in)vulnerability, etc. The Helter Skelter option throws in an interesting mix of these random events so that the user may see how badly DPS suffers under adverse conditions.
• Target Race: Some races, classes, and talents provide bonuses that are specific to the target race. One thing to consider is that this controls the race of the boss and any adds that may be present.
• Player Skill: Whenever a player is considered ready to do something the sim walks through thier prioritized list of actions and executes the very first one that is available. If a player is below 100% skill then there is a chance that it may skip an action even if it is available and make use of a lower-priority action instead. DoTs are considered available when the last tick will occur after current_time+dot_cast_time. When a player is below 100% skill there is a chance that the DoT is refreshed too early, clipping the last tick.
• Threads: The iterative nature of SimulationCraft means that parallel processing is a very effective means to increase performance. Most modern desktops have at least two CPU cores. Match the number of threads to the number of CPU cores for optimal performance.
• Smooth RNG: One of the most difficult problems associated with simulation is variance. Decreasing variance will reduce the number of iterations required to reach a confidence level in the results. Turning on smooth RNG will introduce determinism in both the cycle and the distribution of individual RNG calculations. This will increase convergence by an order of magnitude, allowing the use of far fewer iterations. However, as with formulation, introducing this kind of determinism into the RNG can intefere with the scale factor generation of non-linear stats. Use with caution.
• Armory Region: This option controls which region (US, EU, TW, CN) the Amory Import tab uses.
• Armory Spec: Players may have two talent/glyph combinations, but only one may be active at a time. When a player is downloaded from the Armory, by default the active talent/glyph setup is used. This parameter allows one to access the inactive setup during import.
• Generate Debug: This option provides a peek under the hood. Running with Log Only will force the number of iterations to just one and generate a human-readable combat log that is stored in the Log tab. Running with Gory Details dramatically increases the size of the combat log and makes it considerably less human-readable. It will also provide detailed debug output during character import. Since turning on debug allows only one iteration, scale factor and plot generation are turned off.

Scale factors represent the change in DPS per change in stat value. They are helpful in evaluating incremental gear changes. They are calculated by first making a baseline simulation and then comparing it against subsequent runs in which one stat is increased or decreased. To calculate trustworthy scale factors, the simulation margin of error must be sufficiently smaller than the change in stat value. To reduce the margin of error a large number of iterations is required. Since multiple simulations must be run with a higher-than-normal number of iterations, calculating scale factors can take 50x to 100x more cputime than a standard DPS run.

ScaleFactor(Stat) = ( DPS(Baseline+StatDelta) - DPS(Baseline) ) / StatDelta

By default, SimulationCraft uses stat deltas between 50 and 150 depending upon the stat. Most stat deltas are positive, measuring the increase in DPS. However, due to the cap nature of Hit and Expertise, these stats use negative deltas, measuring the decrease in DPS. To override the default stat deltas, see the Examples tab for the appropriate parameters.

SimulationCraft will optionally generate DPS-per-stat graphs using a +/- 200 stat point range given the initial gear point. It should be noted that simulation is not well suited for plot generation. Precision is not as important so fewer iterations are required. However, the sheer number of sample points needed to generate a plot make it even more cpu-intensive than scale factor generation.

To download a character from the Armory, merely navigate the web view to a character profile page. The easiest way to do this is via the Search mechanism. The Armory Spec toggle under Options controls whether to use the active or the inactive talent/glyph setup. There is no need to wait for the web page to be fully rendered. The import process uses the URL at the command-line. Note that the URL at the command-line can be modified directly in the same manner as a normal web browswer. The Armory tab defaults to US region. See the Options tab to change the region to EU, TW, or CN.

SimulationCraft does not provide a graphical character sheet with which to experiment. Instead we have integrated with the CharDev character planner. CharDev is a powerful profiling tool that strives to be both current and accurate.

If you know the ID number of the profile you wish to simulate, one can simply type chardev=ID in the Simulate tab. If you would like to view the ID before simulating, go to the Import/CharDev tab and change the address from ?planner to ?profile=ID and hit Enter.

If you do not know the ID number of the profile, then you can use Browse under the Import/CharDev tab to search. Note that to search within your own CharDev profiles you will need to log in first.

Creating a new CharDev profile requires that you create an account at their site. This is both free and painless.

Once you log in, you can seed a CharDev profile with a character from the Armory or you can start from scratch.

Remember that you MUST save your profile after editting prior to Importing it into SimulationCraft.

Rawr character XML files can be used to generate a SimulationCraft character profile. While name, race, class, talents, glyphs, gear, and gems are all imported, buff/debuff settings and other module-specific settings that may be in the XML file are all ignored.

Support for Custom Profiles is not yet available.

To save text that may be conveniently cut-and-pasted into an email or forum, go to the Log tab and select the portion of interest. To save the entire log, specify the file name at the command line and press Save!.

To save HTML, go to the Results tab, specify the file name at the command line, and press Save!.

These HTML files are all-inclusive. The images are generate using GoogleCharts which means that the HTML cannot be viewed offline.

A key part of the simulation is the player artificial intelligence. It is important to understand that there is no rotation to specify. Instead, the player is given a priority list of actions. Whenever the player is looking for something to do (just finished an action and not waiting on the GCD), it will simply walk the list of actions and perform the first one that is ready. For example, damage-over-time actions are not ready until they are finished ticking (minus the cast-time, of course). Temporary buffs and cooldowns can also prevent certain actions from being considered ready. There are a large variety of conditionals that can be applied to each action in the priority list that can limit their execution even further. The default action list (actions+=) generated during character import will demonstrate this. For more details, see the Examples tab.