forked from simulationcraft/simc
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathWelcome.html
243 lines (241 loc) · 20.6 KB
/
Welcome.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
<html>
<head>
<title>Welcome to SimulationCraft</title>
</head>
<body>
<br />
<center><h1>Welcome to SimulationCraft</h1></center>
<br />
<h2>Beta Release</h2>
<ul>
<li> Hunters are not yet implemented</li>
<li> Some other classes need polishing</li>
<li> Action lists and gear choices need verifying</li>
<li> Latency modeling needs updating</li>
<li> Some trinkets need their ICD checked</li>
</ul>
<h2>Table of Contents</h2>
<ul>
<li> <a href="#overview"> Overview </a> </li>
<li> <a href="#how_this_interface_works"> How This Interface Works </a> </li>
<li> <a href="#navigation"> Navigation </a> </li>
<li> <a href="#tips_and_tricks"> Tips and Tricks </a> </li>
<li> <a href="#global_parameters"> Global Parameters </a> </li>
<li> <a href="#scale_factors"> Scale Factors </a> </li>
<li> <a href="#plots"> Plots </a> </li>
<li> <a href="#importing_from_the_armory"> Importing from the Armory </a> </li>
<li> <a href="#importing_from_wowhead"> Importing from Wowhead </a> </li>
<li> <a href="#importing_from_chardev"> Importing from CharDev </a> </li>
<li> <a href="#importing_from_warcrafter"> Importing from Warcrafter </a> </li>
<li> <a href="#importing_from_rawr"> Importing from Rawr </a> </li>
<li> <a href="#saving_results"> Saving Results </a> </li>
<li> <a href="#priority_lists_not_rotations"> Priority Lists, Not Rotations </a> </li>
<li> <a href="#modeling_raid_events"> Modeling Raid Events </a> </li>
</ul>
<dl>
<dt><a name="overview" /><h2>Overview</h2></dt>
<dd>SimulationCraft is a tool to explore combat mechanics in the popular MMO RPG World of Warcraft.
It is a multi-player event-driven simulator written in C++ that models raid damage. Increasing class
synergy and the prevalence of proc-based combat modifiers have eroded the accuracy of traditional
calculators that rely upon closed-form approximations to model very complex mechanics. The goal of
this simulator is to close the accuracy gap while maintaining a performance level high enough to
calculate relative stat weights to aid gear selection.</dd>
<dt><a name="how_this_interface_works" /><h2>How This Interface Works</h2></dt>
<dd>At its core, SimulationCraft is a parameter-driven batch simulation tool. This interface is a
very light-weight wrapper that simply helps you build configuration scripts, pass them to the
simulator, and then evaluate the results. It relies upon existing character profile management
sites to provide interactive manipulation of character talents, glyphs, gear, enchants, etc.
The three key steps are:
<ol>
<li> Generate your profile. </li>
<li> Simulate your profile. </li>
<li> Evaluate your results. </li>
</ol>
</dd>
<dt><a name="navigation" /><h2>Navigation</h2></dt>
<dd>In general the flow is from left to right across the main tabs at the top of the window.
At <i>Options</i> you set common high-level directives. At <i>Import</i> you load your character
profile from a variety of sources. At <i>Simulate</i> you make character-specific tweaks.
At <i>Overrides</i> a super-user can specify custom parameters that will persist from run to run.
At <i>Examples</i> you can see examples of all supported parameters including common usage.
At <i>Log</i> you will find simple text reporting as well as any errors encountered.
At <i>Results</i> you will find HTML output generated by the simulator. <b>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.</b></dd>
<dt><a name="tips_and_tricks" /><h2>Tips and Tricks</h2></dt>
<dd>
<ul>
<li>The label on the main button changes between <i>Simulate!</i>, <i>Import!</i> and <i>Save!</i>
depnding upon the active main tab. While a character profile is being imported or a simulation
is running, the label will be set to <i>Cancel!</i>. 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.</li>
<li>The progress bar is context-sensitive. When viewing a web page under <i>Import</i> or <i>Results</i>
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.</li>
<li>The <i>Back</i> and <i>Forward</i> 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 <i>Import</i> or <i>Results</i>
they will cycle through the <i>URL</i> history. <b>When viewing <i>Globals</i>, <i>Simulate</i>, or
<i>Overrides</i>, these buttons will cycle through previous states.</b> This history is persistent
between runs.</li>
<li>With the exception of the <i>Import</i> tab, pressing the <i>Enter</i> key while the command-line
has focus is equivalent to clicking the main button.</li>
<li><b>When the command-line has focus, the <i>Up</i> and <i>Down</i> keys cycle through the history
of command-line text.</b> This history is persistent between runs.</li>
<li>The configuration script passed to the simulator is constructed by first adding the options implied
by the button-settings under <i>Options</i>, followed by the text under <i>Simulate</i>, followed
by the text under <i>Overrides</i> and finally including anything on the command line. It is important
to understand that the last setting <i>wins</i>. 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 <i>armory=us,llane,segv</i> to download and simulate the Hunter Segv from server US-Llane.</li>
<li>Any option that does not fit the <i>parm=value</i> paradigm is assumed to be the name of a script file
which is subsequently loaded. While the history mechanism of the <i>Back</i> and <i>Forward</i> buttons
should be sufficient for most needs, it can be convenient to save complicated parameter settings in
an external file.
</ul>
</dd>
<dt><a name="global_parameters" /><h2>Global Parameters</h2></dt>
<dd>SimulationCraft has many, many options that can be loosely categorized into two groups, those that are
applied to the <i>active</i> player and those that are applied globally. The <i>Globals</i> section
of the <i>Options</i> tab is dedicated to the more commonly changed global parameters.
<ul>
<li><b>Patch:</b> The mechanics of <i>World of Warcraft</i> are constantly changing. SimulationCraft
endeavors to model the two most recent patch levels. Usually, this corresponds to <i>Live</i> and <i>PTR</i>.</li>
<li><b>Latency:</b> 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 <i>GCD</i>),
or is channeled (requiring extra care not to clip the last tick). SimulationCraft uses random
values for these <i>gaps</i>, whose range is centered on user-supplied values.</li>
<li><b>Iterations:</b> 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 <i>scale factors</i>
one must iterate enough such that the simulation error margin is sufficiently smaller than the change
in stat value being analyzed.</li>
<li><b>Length(sec):</b> 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 (<i>boss</i>) is estimated
based upon damage done up to that point. The simulation ends when the target dies and <i>not</i> 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.</li>
<li><b>Vary Length:</b> 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 <i>length-variance</i> to <i>length+variance</i>.
<li><b>Adds:</b> 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 <i>Cleave</i>, <i>Chain Lightning</i>, and <i>Blade Flurry</i>.
In addition, only those AoE spells occasionally used in single-target scenarios have been implemented.
<li><b>Fight Style:</b> One of the most common criticisms of theorycrafting tools is that they only model
<i>tank-n-spank</i> fights in which the player gets to stand perfectly still just hitting keys/buttons.
SimulationCraft supports a wide array of <i>raid events</i> including movement, stuns, splash damage,
target (in)vulnerability, etc. The <i>Helter Skelter</i> option throws in an interesting mix of
these random events so that the user may see how badly DPS suffers under adverse conditions.</li>
<li><b>Target Race:</b> 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 <i>and</i> any adds that may be present.
<li><b>Player Skill:</b> Whenever a player is considered <i>ready to do something</i> 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
<i>current_time+dot_cast_time</i>. When a player is below 100% skill there is a chance that the DoT is
refreshed too early, clipping the last tick.
<li><b>Threads:</b> 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.</li>
<li><b>Smooth RNG:</b> 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 <i>smooth</i> 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.</li>
<li><b>Armory Region:</b> This option controls which region (US, EU, TW, CN) the Amory Import tab uses.
<li><b>Armory Spec:</b> 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 <i>active</i> talent/glyph
setup is used. This parameter allows one to access the <i>inactive</i> setup during import.</li>
</ul>
</dd>
<dt><a name="scale_factors" /><h2>Scale Factors</h2></dt>
<dd>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.
<p><b>ScaleFactor(Stat) = ( DPS(Baseline+StatDelta) - DPS(Baseline) ) / StatDelta<b>
<p>By default, SimulationCraft uses stat deltas between 50 and 150 depending upon the stat. Most stat deltas
are positive, measuring the <i>increase</i> in DPS. However, due to the cap nature of <i>Hit</i> and
<i>Expertise</i>, these stats use negative deltas, measuring the <i>decrease</i> in DPS. To override the
default stat deltas, see the <i>Examples</i> tab for the appropriate parameters.
</dd>
<dt><a name="plots" /><h2>Plots</h2></dt>
<dd>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.
</dd>
<dt><a name="importing_from_the_armory" /><h2>Importing from the Armory</h2></dt>
<dd>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 <i>Search</i> mechanism. The <i>Armory Spec</i> toggle under <i>Options</i> controls
whether to use the <i>active</i> or the <i>inactive</i> 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.<b>The Armory tab defaults to
US region. See the <i>Options</i> tab to change the region to EU, TW, or CN.</b>
</dd>
<dt><a name="importing_from_wowhead" /><h2>Importing from Wowhead</h2></dt>
<dd>Characters can be downloaded from the Wowhead Profiler in two ways. The first type of download is simply accessing
the Armory <i>mirror</i> that Wowhead maintains. Select the <i>region</i> and <i>server</i> and then type in the
character name of interest. Note that this mirror may not be up to date. Press the <i>Resync</i> button to request
an update.
<p>The Wowhead Profiler also allows the creation of virtual characters. These characters can be created from
scratch or they can be created from an existing profile using the <i>Save As</i> button. This function does not
become available until you have logged into the Wowhead site. Membership is free and easy to acquire.
<p>At present, Wowhead virtual characters are the only way to perform <i>what-if?</i> character analysis using a
graphic user interface. Talents, glyphs, gear, and gems can all be tweaked. Just remember to press <i>Save</i>
before importing the character into the <i>Simulate!</i> tab.</dd>
<dt><a name="importing_from_chardev" /><h2>Importing from CharDev</h2></dt>
<dd>Support for the <i>CharDev</i> site is not yet available.</dd>
<dt><a name="importing_from_warcrafter" /><h2>Importing from Warcrafter</h2></dt>
<dd>Support for the <i>Warcrafter</i> site is not yet available.</dd>
<dt><a name="importing_from_rawr" /><h2>Importing from Rawr</h2></dt>
<dd>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, <i>buff/debuff</i> settings and other module-specific settings
that may be in the XML file are all ignored. </dd>
<dt><a name="saving_results" /><h2>Saving Results</h2></dt>
<dd>To save text that may be conveniently cut-and-pasted into an email or forum, go to the <i>Log</i> tab and select
the portion of interest. To save the entire log, specify the file name at the command line and press <i>Save!</i>.
To save HTML, go to the <i>Results</i> tab, specify the file name at the command line, and press <i>Save!</i>.
These HTML files are all-inclusive. The images are generate using GoogleCharts which means that the HTML cannot
be viewed offline.</dd>
<dt><a name="priority_lists_not_rotations" /><h2>Priority Lists, Not Rotations</h2></dt>
<dd>A key part of the simulation is the player artificial intelligence. It is important to understand that there
is no <i>rotation</i> to specify. Instead, the player is given a <i>priority list</i> 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 <i>ready</i>. For example, <i>damage-over-time</i>
actions are not ready until they are finished ticking (minus the cast-time, ofc). Temporary buffs and <i>cooldowns</i>
can also prevent certain actions from being considered <i>ready</i>. 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 (<i>actions+=</i>) generated during character import will demonstrate this. For more details, see
the <i>Examples</i> tab.</dd>
<dt><a name="modeling_raid_events" /><h2>Modeling Raid Events</h2></dt>
<dd>One of the common criticisms of theorycrafting tools is that they model <i>Patchwerk</i> style fights in which
the DPS players are able to focus exclusively on generating damage without worrying about standing in molten
lava or other such trivial distractions. While truly modeling individual boss fights is a near-impossible task,
SimulationCraft does support a wide array of raid events. <p>Experimenting with these events allows one to determine
how succeptible talent/gear combinations are to adverse conditions. Supported events include movement, stuns, AoE damage,
adds spawning, boss (in)vulnerability, boss casting requiring use interrupts. The intervals and durations are user-specified,
as are the degree of randomness applied to each. <p>When a player is <i>moving</i> auto-attacks are halted and only ranged
instant-casts are allowed. To further control the actions taken while moving, there is a <i>moving=1</i> conditional
that can be specified with actions to prevent them from being used in normal circumstances. While <i>stunned</i>, even
the instant-casts are forbidden. Boss <i>vulnerability</i> is a 2x damage multiplier. Boss <i>invulnerability</i> will remove
any existing player DoTs on the target, but it does not yet remove player debuffs. The <i>casting</i> event is
used to model players changing their rotations to perform interrupts. Player interrupt actions are not considered
<i>ready</i> unless the boss is in mid-cast. This means that it is safe to give these actions a high-priority
because they will not be used unless necessary. The <i>damage</i> event is used to model splash damage from AoE,
which is helpful for talents such as <i>Incanters Absorbtion</i>. Note that multi-DoT and many true AoE abilities
are not yet supported, so some modules take more advantage of adds spawning than others. For more details, see
the <i>Examples</i> tab.
</dd>
</dl>
</body>
</html>