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 any specified condition is met, the action is executed. When none of the specified actions are used, the sim will perform the next auto attack (c1 c2 c3 c4 c5 then back to c1)
• 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 essentially python code that is evaluated so they can be just about anything, but the most commonly used ones are:
  • x=n or seq=n: the previous action was combo #n in the attack chain.
  • fsc: the previous action was 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.charged is the amount of sp charged on s1, you can combine it with s1.sp and this.sp_val to make conditions like s1.charged>=s1.sp-this.sp_val('fs'), aka "do this action when S1 is one FS away from being fully charged. This can be used with s2 and s3 as well.
  • s1.check() signify that a skill is ready to use.
  • ``this.have_buff(buffname)` checks for presence of buff 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 any python logical operators in the condition, such as and to combine 2 conditions
  • For Agito weapons, s3, not this.s3_buff means only use S3 if the buff is not on, you can also check for what type of buff is currently active, e.g. s3, this.s3_buff and this.s3_buff.mod_type = 'defense'
  • 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.