What is this?

This is an elaborate napkin math machine, designed to estimate highest possible damage per second for a given adventurer. The source code can be found here: https://github.com/dl-stuff/dl

How does simulated afflictions work?

The affliction is considered [uptime]% effective for the entire duration of the simulation.

How does simulated buff/debuff work?

1 stack of the entered buff/debuff is active for the entire duration of the simulation.

Why does the result show a different wyrmprint than my inputs?

Wyrmprints with the same ability are automatically swapped for the best option in terms of stats and value, as long as any affinities are preserved.

What does the damage graph display?

For personal damage, the average DPS of a ±5s window is calculated around each time point. For team DPS, each point represents a time where the team DPS % changes.

How are the setups (Personal/Team/Affliction) created?

Whenever a simulation is ran, the server will compare the result with the highest recorded DPS/Team DPS, and store the setup if it is better. For personal/affliction, team DPS is not considered. Likewise for team DPS, only the team buff % is considered. Since these setups are crowdsourced, no guarentee is made on any one of them being optimal and you are encouraged to try for bigger numbers.

I need to speak to the manager.

Open an issue here, or ask me on discord I'm chu2.718281828459045235360287471#0110

• Each consists of an action, optionally followed by a comma and condition, e.g. s1, x=5
• Lines starting with # is considered comment and not evaluated
• ` is a decorator that is removed from each line, this behavior exists due to historical reasons.
• During the simulation, the ACL is read from top to bottom. When the action is available (e.g. skill is filled) and the specified conditions are met, the action is executed. When none of the specified actions are used, the sim will perform the next auto attack
• You can specify the same action multiple times, to cover different conditions.
• It's also possible to specify blocks of actions+subconditions under one condition, using python-like if/elif/else syntax:
  

  if <condition>
  ...
  elif <condition>
  ...
  else
  ...
  end

  Unlike python, end is required and indentation does not matter.
• You can use queue to enforce a certain sequence of actions, for example:

  queue
  `s1
  `s1
  `s2
  end

  This forces 2 s1 uses before an s2 use, even if s2 was fully charged before the second s1 is cast.
  Queue can be used with a condition like queue <condition> such that the actions in that block are only queued when the condition is true.
• The built in actions include skills (s1, s2, s3), force strike (fs), a dodge roll (dodge), and shapeshift (dragon). Force strike fail (fsf) is an action too, but it is assumed to be performed for c5 hit of blade, wand, and lance.
• Some adventurers have extra actions implemented, for example Ramona has s1a for using all hits on her s1.
• The dragon action assumes you are doing the normal full duration optimal combo, but you can change that by using dragon(act seq). The syntax is:
• Each action is separated by a hypen (-), e.g. dragon(c3-s-c3-end)
• cX (e.g. c3) means do c1 to cX of the dragon combo chain. Most dragons go up to 3 combos, some have 5 combos.
• s means use skill (if they have usage left)
• dodge means do a dodge. Dodge is implicitly added after cX if dodge is faster than recovery or if the cX is not the final combo.
• end means preemptively stop the transform, used to represent dragon tanking.
• The conditions are a limited subset of python code, some common commonly used conditions are:
  • x=n or seq=n: the previous action was combo #n in the attack chain.
  • xf=n: the previous action was the first cancelable hit in combo #n
  • fsc: the previous action was force strike
  • fscf: the previous action was the first cancelable hit in force strike
  • cancel: the previous action was a combo or a force strike, equivalent to x=1 or x=2 or x=3 or x=4 or x=5 or fsc.
  • s=n: the previous action was skill #n
  • s: the previous action was a skill
  • prep: at the start of the fight if the adventurer has skill prep
  • s1.check() signify that a skill is ready to use.
  • `buff(s3)` checks if a buff created by `s3` is currently active, works for all skills. If you need to check for buff from specific phase of skill, use `buff(s3, 1)` and so on.
  • `have_buff(buffname)` checks for presence of misc. buffs on certain character. The name of buffs is poorly documented with inconsistent naming scheme, but you can look at logs to figure out the specifics for your adventurer.
  • You can use basic arithmetic operators and most logical operations in the condition.
  • Special conditions are implemented for some adventurers but unfortunately most aren't well documented nor universal. You most likely have to look at the source code to tell.