APL Deconstruction: Arcane

[Komma]

Arcane SimulationCraft APL

To understand the intentions of this thread, please read this thread.

This thread was last updated on 2015-10-19, based on the Arcane Mage APL from SimulationCraft 6.2.0 Release 3 (Developer), Commit Hash: b72801540019cc4f3a3e97ba1c7110e381510953


Overview

The primary strength of Arcane has always been single target damage, and as such, most of the optimization efforts have been put into making sure single target performs well. In other words, not as much effort has been put into AOE and cleave.

At a meta level, the name of the game for Arcane APL optimization is "usage". Maximizing usage of high priority spells while minimizing downtime/low-throughput-time is the number 1 factor. It is far more important than little tricks such as gaming Incanter's Flow or trinket procs with Supernova or Arcane Missiles. Here are some goals that consistently correlate with throughput:
- Maximize uptime/usage of cooldowns (Arcane Power/Prismatic Crystal) and talents (Supernova/Nether Tempest/Rune of Power/Mirror Images)
- Avoid capping mana, and get as close to converting 100% of excess mana into Arcane Blasts and Missiles casted at maximum Arcane Charges
- Stay as close to full mana as possible otherwise (while avoiding mana cap), to maximize benefits from Mana Adept

Under SimulationCraft, many of these metrics are easily trackable. For the default 450(+-20%) second simulation, we can expect a theoretical maximum of <=20.0 Supernova casts on average, <=5.0 Prismatic Crystal casts and unglyphed Arcane Power casts (3.0 glyphed) and so on. Nether Tempest and Rune of Power should come very close to 100% uptime. Recorded excess mana overflow should be as close to <0.2% as possible; an unavoidable amount of loss happens on the pull and due to Evocations. The mana level graph, which is averaged across all iterations, should be well above 93% at any point not indicative of a burn phase. These numbers are early health indicators for any APL change, telling us if Robomage is missing usages on high priority spells due to errors in the APL.

The Arcane APL is structured into a number of separate subaction-lists, which indicate the actions an Arcane Mage uses in different conditions. It is important to note that APLs are by default, stateless. That means without extra help, Robomage does not have "modes", nor does he remember which subaction-list he was previously using an action from. Each time Robomage chooses an action, he always starts from the very top of the master list, and then traverses through all individual lists.

Arcane APL is structured into a number of separate subaction-lists, which correspond the actions an Arcane Mage uses in specific scenarios. It is important to note that SimulationCraft APL by default is stateless. That means that without external help, Robomage does not have "modes", nor does he remember which subaction-list he was previously using, nor does he consult previous actions performed by default. Choosing an action always starts at the very top of the master list, and then traverses through individual lists to search for suitable candidates. As it turns out, this has important consequences on how the Arcane APL burn phase is implemented.

With all that out of the way, let's dive into the actual APL of Arcane.


Master List

The master list within the Arcane APL consists of 12 lines. I have bolded the ones with significant DPS performance impact, which I will elaborate on. The others are still significant, but involve complicated simulation mechanics (enemy casting, raid-wide AOE damage, raid-wide Bloodlust override flags, movement events) that are beyond the scope of this thread and cannot be covered in detail.

actions=counterspell,if=target.debuff.casting.react
actions+=/stop_burn_phase,if=prev_gcd.evocation&burn_phase_duration>gcd.max
actions+=/cold_snap,if=health.pct<30
actions+=/time_warp,if=target.health.pct<25|time>5
actions+=/call_action_list,name=movement,if=raid_event.movement.exists
actions+=/rune_of_power,if=buff.rune_of_power.remains<2*spell_haste
actions+=/mirror_image
actions+=/cold_snap,if=buff.presence_of_mind.down&cooldown.presence_of_mind.remains>75
actions+=/call_action_list,name=aoe,if=active_enemies>=5
actions+=/call_action_list,name=init_burn,if=!burn_phase
actions+=/call_action_list,name=burn,if=burn_phase
actions+=/call_action_list,name=conserve

actions+=/stop_burn_phase,if=prev_gcd.evocation&burn_phase_duration>gcd.max

At the top of list we see a weirdly named action: stop_burn_phase. As the name suggests, this is a custom made action that indicates the the mage the end of a burn phase, and the line is skipped when a burn phase is not currently under way. To avoid confusing you with a longwinded sidetrack right now, I will leave the full explanation of this system later. However, it is important to note the position of the line near the top of the list; It is there for a reason.

actions+=/rune_of_power,if=buff.rune_of_power.remains<2*spell_haste
actions+=/mirror_image

Following that we have usage of Rune of Power and Mirror Image. They are only placed this highly to ensure they have near maximum uptime. The condition "rune of power remaining duration < 2 * spell_haste seconds" has a small catch to it; spell_haste as a SimulationCraft variable is a misnomer, and in fact indicates spell_speed. This is the ratio of a spell's cast time to its base cast time, ie. cast_time = spell_speed * base_cast_time.

The value "2 * spell_haste" is in fact the channel duration of Arcane Missiles, which is the longest duration cast for Arcane Mages aside from Arcane Blasts casted at low Arcane Charges. Therefore, this statement can actually be understood as "recast RoP if an important cast time spell cannot be fully benefit from it". The reason that we must hardcode 2.0 seconds instead of accessing Arcane Missile's channel duration directly, is because SimualtionCraft regards all channeled attacks as DOTs that prevent casting, and therefore Arcane Missiles has an official "cast time" of 0 seconds. As you'll soon notice, this pattern will appear multiple times within the Arcane APL.

actions+=/cold_snap,if=buff.presence_of_mind.down&cooldown.presence_of_mind.remains>75

Some of you might be wondering what the line is doing here. You've probably forgotten that Cold Snap has the side effect of also resetting the CD on PoM. By using Cold Snap as soon as Presence of Mind is consumed (note: you need to cast a spell to consume it AFTER using PoM!), you are able to gain an extra charge of PoM every 3 minutes.

actions+=/call_action_list,name=aoe,if=active_enemies>=5
actions+=/call_action_list,name=init_burn,if=!burn_phase
actions+=/call_action_list,name=burn,if=burn_phase
actions+=/call_action_list,name=conserve

Here we have the 4 core sections of Arcane's execution listed in order:
1. If you have lots of enemies, prioritize AOE spells.
2. If you're not in burn phase, check if you should be preparing for a burn phase
3. If you are current in a burn phase, execute an action from the burn phase subaction-list
4. Otherwise, execute conserve phase actions.

The ordering of this list has an unfortunate consequence: during heavy cleave fights, Robomage will give up single target boss damage, and use AOE spells to pad the meters instead. Often, this is not what we do in raids. However, this design is a necessary evil. The alternative would have been Robomage merrily spamming his Arcane Blasts into murloc #151 out of 200, even if he isn't talented for Unstable Magic. AOE simulations would be a complete disaster.


Burn Phase Implementation
As mentioned in the overview, SimulationCraft action list traversal by the actor is by default, stateless. Without custom tools, there is no simple way to force Robomage into a subset of actions at specific times. This creates issues for implementing the burn phase. Say we decided to implement burn phases as follow:

actions+=/do_burn_phase_stuff,if=mana_will_last_until_evocation_is_back
actions+=/do_conserve_phase_stuff

Such a list would have the following happen: Robomage will spam a bunch of Arcane Blasts, suddenly realize that his poor Arcane Missiles RNG means his mana won't last until Evocation is back, and therefore skip the do_burn_phase_stuff line and opt to do_conserve_phase_stuff instead - most likely using Arcane Barrage to drop Arcane Charges at 60% mana. Then, he will realize that because Evocation is almost up, he should go back to burning again, and waste his time building 4 Arcane Charges again before restarting his burn and finally Evocating. For any reader that has reached this point in the thread, I shouldn't have to explain to you why interrupting your burn with an Arcane Barrage is a terrible idea.

The solution we opted for, was to introduce 2 custom actions and a boolean flag: start_burn_phase, stop_burn_phase, and burn_phase. Simply put, start_burn_phase sets the value of burn_phase to true, while stop_burn_phase sets it to false. There is also a custom expression called burn_phase_duration that returns the amount of time spent in a burn phase.

With these custom actions and flags, we can now control burn phase logic by toggling burn_phase to true and false, and use it to drive Robomage into burn phases and conserve phases. After start_burn_phase, Robomage will stubbornly execute burn_phase gated actions regardless of mana, until we tell it to stop_burn_phase. Right now, burn phases are ended with the execution of Evocation. By putting stop_burn_phase at the top of the master list and setting a condition of "if=prev_gcd.evocation&burn_phase_duration>gcd.max", Robomage is automatically returned to conserve phase each time Evocation is casted as the previous action.

So what is burn_phase_duration>gcd.max doing there? The burn_phase_duration check is meant as a safeguard against an infinite loop. Near the end of a fight, Robomage will attempt to start_burn_phase to burn mana before the boss is dead. Sometimes, this coincides with the time when Robomage has just ended a burn phase. However, since the previous casted spell is still Evocation, this ends in Robomage infinitely calling start_burn_phase and stop_burn_phase, resulting in a SimulationCraft crash. By requiring a burn phase to have a non-zero duration before calling stop_burn_phase, we avoid this problem.

[Komma]

Initializing a Burn

For most of WoD, one of the biggest challenges as an Arcane Mage is to judge when to start the burn phase. While the recent addition of the Legendary Ring has simplified this by forcing us to wait well past Evocation's CD, APLs need to cater to all raiding players. It is therefore our responsibility to approximate this human-like decision with robot logic. The result is...not pretty.

# Regular burn with evocation
actions.init_burn=start_burn_phase,if=buff.arcane_charge.stack>=4&(legendary_ring.cooldown.up|legendary_ring.cooldown.remains>target.time_to_die+15|!legendary_ring.has_cooldown)&(cooldown.prismatic_crystal.up|!talent.prismatic_crystal.enabled)&(cooldown.arcane_power.up|(glyph.arcane_power.enabled&cooldown.arcane_power.remains>60))&(cooldown.evocation.remains-2*buff.arcane_missiles.stack*spell_haste-gcd.max*talent.prismatic_crystal.enabled)*0.75*(1-0.1*(cooldown.arcane_power.remains<5))*(1-0.1*(talent.nether_tempest.enabled|talent.supernova.enabled))*(10%action.arcane_blast.execute_time)<mana.pct-20-2.5*active_enemies*(9-active_enemies)+(cooldown.evocation.remains*1.8%spell_haste)
# End of fight burn
actions.init_burn+=/start_burn_phase,if=target.time_to_die*0.75*(1-0.1*(talent.nether_tempest.enabled|talent.supernova.enabled))*(10%action.arcane_blast.execute_time)*1.1<mana.pct-10+(target.time_to_die*1.8%spell_haste)

These two start_burn_phase lines might be the most convoluted pieces of APL logic in the history of SimulationCraft APLs. Usually, I'd combine lines that have the same action with an "OR" operator, for better simulation performance. Here I chose to avoid that, because I felt it was already too confusing. Let me try to explain some of the voodoo behind this.

In WoD, there are 2 cases in which we would start burning mana: when we feel that Evocation will be available at the end of burn, or when we believe the target will die before getting really low or out of mana. These two conditions correspond to the two lines; the first line is for opening and mid-fight burn, while the second line is for end-of-fight burns.

The key factor in burn estimation is Mana. As such, the only way to tackle the problem directly is to perform estimations on Mana levels. We start with a basic accounting formula, no different from how we'd calculate dollars:

Code: Select all

current_mana + mana_gained - mana_spent == result_mana

A slight reorganization of the terms, and we get this:

Code: Select all

mana_spent == current_mana - result_mana + mana_gained

This gives us a starting point, from which we start adding Arcane Mage mechanics. In both cases, result_mana is a somewhat known value. For regular burns, it's the mana level at which we want to use Evocation. Without the class trinket, we're talking about 40-50% on a single target fight. It's a bit more complicated than that due to target numbers, but let's call that value target_mana for now.

As of WoD, mana_gained is a very predictable value. All Mages regenerate mana at a rate of (1.8% * (1 + haste)) per second, or 1.8 % spell_haste when using SimC expressions, where "%" denotes division. Assuming we want to use Evocation as soon as it is available, we can use the remaining cooldown on it as the mana regen time. This gives us mana_gained = cooldown.evocation.remains * 1.8 % spell_haste. Substituting the above and using SimC syntax, we have the following:

Code: Select all

mana_spent < mana.pct - target_mana + (cooldown.evocation.remains * 1.8 % spell_haste)

Our goal is to start the burn phase as soon as we can afford to, which is why we use "less than" instead of "equals".

So how do we estimate mana expenditure? First we must examine the mana costs of spells:

Code: Select all

Arcane Blast (4 charge): 10.0% Arcane Barrage : 1.0% Arcane Orb: 0.8% Nether Tempest: 1.5% Everything else: 0.0% (Free)

As it turns out, the only real mana expenditure we need to consider is AB4, which costs 10.0% per cast, much more than all other spells. This makes things simple, because we can approximate mana spent by figuring out how many AB4s we'll be casting. The number of AB4s we cast is roughly equal to the amount of time we'll spend casting it, divided by the cast time. The cast time is fairly straight forward, because SimC gives us a handy expression for use: action.arcane_blast.execute_time. The rate at which AB4 drains mana is therefore 10%action.arcane_blast.execute_time
Substituting all this into the expression, and we now have:

Code: Select all

time_spent_casting_ab4 * (10%action.arcane_blast.execute_time) < mana.pct - target_mana + (cooldown.evocation.remains * 1.8 % spell_haste)

Next is the hard part: How do we estimate the amount of time spent casting AB4s? Using the same assumption as the mana regen, we can use Evocation's remaining cooldown as the total time remaining. Afterwards we must adjust for other factors with the following:
1. Subtract 2 * spell_haste for every AM proc currently held by the Mage. This is time spent on currently available AMs, which are mana-free.
2. If the player has PC selected, subtract 1 GCD that will be used to place PC.
3. Supernova has a CD of 25 seconds, and we can assume the Mage will have 2 charges ready (more on that later). That rounds down to 1 GCD per 12 seconds, which is roughly ~10% of casting time. Coincidentally, this is the same as the casting time required to keep up Nether Tempest during the burn. Therefore, if the Mage has either SN or NT, multiply remaining time by 0.9.
4. Arcane Missiles has a 30% proc rate. That is to say, for every 1.8 seconds spent casting AB4, expect to proc around 2.0 * 30% = 0.6 seconds worth of AM. With a linear assumption, we can claim that (1.8 / (1.8 + 0.6)) = 75% of remaining time is expected to be spent on AB4s.
5. Arcane Power has a perk effect that reduces mana costs by 10%. If Arcane Power is available (ie. not glyphed and on CD), multiply mana expenditure by 0.9.
6. A 10% safety factor, just to avoid running OOM when AM proc rate is not our friend.
Putting this all into the formula, we get the following:

Code: Select all

(cooldown.evocation.remains - buff.arcane_missiles.stack * 2 * spell_haste - gcd.max * talent.prismatic_crystal.enabled) * (1 - 0.1 * (talent.nether_tempest.enabled|talent.supernova.enabled)) * (10%action.arcane_blast.execute_time) * 1.1 < mana.pct - target_mana + (cooldown.evocation.remains * 1.8 % spell_haste)

We now have the beginnings of a mana estimation, and can start looking at the other requirements. Maybe you noticed something missing from the picture. Where does the class trinket, Tome of Shifting Words, come into play? Unfortunately, the answer is that it doesn't. This mana estimation has not taken into account ToSW's cast time reduction, which is unfortunately dependent on a few more factors. Luckily, most players with ToSW at this point have also gotten their legendary ring, which means that Evocation estimation is no longer a thing for them. There are also other lower priority concerns, such as NT, ABar and AO generating AM charges and costing mana, along with AP not covering the whole burn duration. Since there is no way to accurately model all these exceptions and edge cases with a simple heuristic, they are discarded.

With mana out of the picture, we start looking at the other conditions.

# Regular burn with evocation
actions.init_burn=start_burn_phase,if=buff.arcane_charge.stack>=4&(legendary_ring.cooldown.up|legendary_ring.cooldown.remains>target.time_to_die+15|!legendary_ring.has_cooldown)&(cooldown.prismatic_crystal.up|!talent.prismatic_crystal.enabled)&(cooldown.arcane_power.up|(glyph.arcane_power.enabled&cooldown.arcane_power.remains>60))&(cooldown.evocation.remains-2*buff.arcane_missiles.stack*spell_haste-gcd.max*talent.prismatic_crystal.enabled)*0.75*(1-0.1*(cooldown.arcane_power.remains<5))*(1-0.1*(talent.nether_tempest.enabled|talent.supernova.enabled))*(10%action.arcane_blast.execute_time)<mana.pct-20-2.5*active_enemies*(9-active_enemies)+(cooldown.evocation.remains*1.8%spell_haste)
# End of fight burn
actions.init_burn+=/start_burn_phase,if=target.time_to_die*0.75*(1-0.1*(talent.nether_tempest.enabled|talent.supernova.enabled))*(10%action.arcane_blast.execute_time)*1.1<mana.pct-10+(target.time_to_die*1.8%spell_haste)

With a better idea of what the mana mumbo-jumbo is, we take another look at the initiation code. The second line for end-of-fight burns is now fairly understandable, since it is just a variation of the regular burn condition. We focus on the other conditions, which is bolded below::

actions.init_burn=start_burn_phase,if=buff.arcane_charge.stack>=4&(legendary_ring.cooldown.up|legendary_ring.cooldown.remains>target.time_to_die+15|!legendary_ring.has_cooldown)&(cooldown.prismatic_crystal.up|!talent.prismatic_crystal.enabled)&(cooldown.arcane_power.up|(glyph.arcane_power.enabled&cooldown.arcane_power.remains>60))&(cooldown.evocation.remains-2*buff.arcane_missiles.stack*spell_haste-gcd.max*talent.prismatic_crystal.enabled)*0.75*(1-0.1*(cooldown.arcane_power.remains<5))*(1-0.1*(talent.nether_tempest.enabled|talent.supernova.enabled))*(10%action.arcane_blast.execute_time)<mana.pct-20-2.5*active_enemies*(9-active_enemies)+(cooldown.evocation.remains*1.8%spell_haste)

There are several conditions are chained in with AND operators, which we'll cover one by one.

"(cooldown.prismatic_crystal.up|!talent.prismatic_crystal.enabled)" is a PC talent check; if PC is chosen as a talent, always wait for PC to be available before burning. This "talent.blah.not_selected OR cooldown.blah.up" pattern occurs a lot, to cover different talent choices by the player.

"(cooldown.arcane_power.up|(glyph.arcane_power.enabled&cooldown.arcane_power.remains>60))" functions similarly to the PC condition, except it needs to take into account Glyph of Arcane Power. When Arcane Power is glyphed, it has a 180 second CD. 60 seconds is a suitable threshold with a 30 second safety margin, to make sure that Robomage will initiate burns even though glyphed AP is on CD.

"(legendary_ring.cooldown.up|legendary_ring.cooldown.remains>target.time_to_die+15|!legendary_ring.has_cooldown)" was a relatively recent addition. The second condition makes sure that the 2 minute CD on the ring doesn't stop Robomage from using unglyphed 90 second CD Arcane Power when the enemy is about to die. The third one is a generic condition that covers the case when the player does not own a legendary ring. If the third condition was omitted, all players without rings would have their simulations broken, because burn phases would be locked behind a legendary ring that they do not own.

Last of all is the innocent looking first part: "buff.arcane_charge.stack>=4". A lot of players would challenge the accuracy of this condition by claiming that burn phases can start even though the player does not have 4 Arcane Charges yet. This is where subtle APL conditions can get really complicated: the way "burn_phase" is defined in the APL does not correlate 1-to-1 to our in-game understanding of the term.

As mentioned above, the entire mana estimation system for initiating burn phases is based on the assumption that Arcane Blasts are cast almost exclusively at 4 charges. This would fail completely if we allowed players to build Arcane Charges during it. On top of that, by deferring stack building and initiation to action lists outside of the burn phase, we can let other action lists handle special cases such as Arcane Orb, reacting to Prophecy of Fear, or other exception cases that create problems. This means we can avoid duplicating the "build Arcane Charges" process both inside and outside the burn phase action list, bringing down the complexity significantly.

The unfortunate side effect of this is that changing the Arcane Charge requirement does not work as most players assume it would. When you reduce the charge stack requirement, it means that Robomage has weaker handling of trinket procs and talent usage before reaching 4 charges. Mark of Doom procs may be ignored, usage of certain talents may suffer, and many other side effects may occur. Many of these consequences will depend on specific implementations in other lists and how they work with Arcane Charges. Without looking at a large sample size of outputs, there is no way to tell what exactly will happen.

[Komma]

The Burn Phase

In the previous post, we explained how the Arcane mage burn phase only begins after start_burn_phase has been triggered from within the init_burn action list. The burn phase actions are as follow:

# High mana usage, "Burn" sequence
actions.burn=call_action_list,name=init_crystal,if=talent.prismatic_crystal.enabled&cooldown.prismatic_crystal.up
actions.burn+=/call_action_list,name=crystal_sequence,if=talent.prismatic_crystal.enabled&pet.prismatic_crystal.active
actions.burn+=/call_action_list,name=cooldowns
actions.burn+=/arcane_missiles,if=buff.arcane_missiles.react=3
actions.burn+=/arcane_missiles,if=set_bonus.tier17_4pc&buff.arcane_instability.react&buff.arcane_instability.remains<action.arcane_blast.execute_time
actions.burn+=/supernova,if=target.time_to_die<8|charges=2
actions.burn+=/nether_tempest,cycle_targets=1,if=target!=pet.prismatic_crystal&buff.arcane_charge.stack=4&(active_dot.nether_tempest=0|(ticking&remains<3.6))
actions.burn+=/arcane_orb,if=buff.arcane_charge.stack<4
actions.burn+=/arcane_barrage,if=talent.arcane_orb.enabled&active_enemies>=3&buff.arcane_charge.stack=4&(cooldown.arcane_orb.remains<gcd.max|prev_gcd.arcane_orb)
actions.burn+=/presence_of_mind,if=mana.pct>96&(!talent.prismatic_crystal.enabled|!cooldown.prismatic_crystal.up)
actions.burn+=/arcane_blast,if=buff.arcane_charge.stack=4&mana.pct>93
actions.burn+=/arcane_missiles,if=buff.arcane_charge.stack=4&(mana.pct>70|!cooldown.evocation.up|target.time_to_die<15)
actions.burn+=/supernova,if=mana.pct>70&mana.pct<96
actions.burn+=/evocation,interrupt_if=mana.pct>100-10%spell_haste,if=target.time_to_die>10&mana.pct<30+2.5*active_enemies*(9-active_enemies)-(40*(t18_class_trinket&buff.arcane_power.up))
actions.burn+=/presence_of_mind,if=!talent.prismatic_crystal.enabled|!cooldown.prismatic_crystal.up
actions.burn+=/arcane_blast
actions.burn+=/evocation

At the top of the burn list are references to init_crystal, crystal_sequence, and cooldowns. They are pretty much as their names imply: "What to do before dropping PC", "What to do when PC is dropped", and "arcane power, racials, potions, clickable items". To focus on the burn phase itself simple, let's skip Prismatic Crystal and cover that later.

# Consolidated damage cooldown abilities
actions.cooldowns=arcane_power
actions.cooldowns+=/blood_fury
actions.cooldowns+=/berserking
actions.cooldowns+=/arcane_torrent
actions.cooldowns+=/potion,name=draenic_intellect,if=buff.arcane_power.up&(!talent.prismatic_crystal.enabled|pet.prismatic_crystal.active)
actions.cooldowns+=/use_item,slot=finger2

The cooldowns action list serves as a shorthand for "use all power-ups that aren't on CD". This saves us from repeating the same lines in other lists. Since potions require syncing with AP and PC for synergy, there is an additional condition placed on it, which usually only applies when AP is glyphed. Unfortunately, due to how cooldown usage is grouped together, this creates problems with desynced cooldowns such as 2-minute CD clickable trinkets, which end up getting used every ~3 minutes due to Prismatic Crystal and Arcane Power. Without custom modifications, the legendary ring would have suffered from the same issue.

Continuing with the rest of actions.burn:

actions.burn+=/arcane_missiles,if=buff.arcane_missiles.react=3
actions.burn+=/arcane_missiles,if=set_bonus.tier17_4pc&buff.arcane_instability.react&buff.arcane_instability.remains<action.arcane_blast.execute_time

All burn phases start with popping all cooldowns. After that, it's some safeguards for spending Arcane Missiles when at 3-stack cap, or when 4T17 buff is about to run out.

actions.burn+=/supernova,if=target.time_to_die<8|charges=2
actions.burn+=/nether_tempest,cycle_targets=1,if=target!=pet.prismatic_crystal&buff.arcane_charge.stack=4&(active_dot.nether_tempest=0|(ticking&remains<3.6))

The next two lines focus on T75 talents. Supernova needs to be used ASAP when capped at 2 charges, or when the target is about to die. This maximizes the number of charges used over a fight.

Nether Tempest attempts to keep near 100% uptime with 4 stack applications. The main challenge with implementing that happens when a fight has multiple targets, because Nether Tempest has a 1-target limit. You can't just look at whether your current target has a ticking NT, because it can be ticking on another target. By using cycle_targets=1, Robomage will seek through enemies to search for the active Nether Tempest. The condition (active_dot.nether_tempest=0|(ticking&remains<3.6)) means "Use NT only when there is NO active NT on any target, OR the current enemy has an active NT AND it has less than 3.6 seconds remaining". Missing either part of this condition would result in Robomage spamming NT endlessly, breaking the simulation completely. The safeguard target!=pet.prismatic_crystal is not strictly necessary, but reduces the chance of APL error making Robomage apply NT on a PC with only a few seconds remaining.

actions.burn+=/arcane_orb,if=buff.arcane_charge.stack<4
actions.burn+=/arcane_barrage,if=talent.arcane_orb.enabled&active_enemies>=3&buff.arcane_charge.stack=4&(cooldown.arcane_orb.remains<gcd.max|prev_gcd.arcane_orb)

These two lines really only apply to AO-cleave simulations. Arcane Barrage is used during the burn phase only if Arcane Orb can instantly regenerate 4 Arcane Charges. Due to travel time on AO, ABar is often used after AO is cast, but before it impacts. The net result of these two lines is a major gain in cleave damage, but a slight decrease on priority target (boss) damage.

actions.burn+=/presence_of_mind,if=mana.pct>96&(!talent.prismatic_crystal.enabled|!cooldown.prismatic_crystal.up)
actions.burn+=/arcane_blast,if=buff.arcane_charge.stack=4&mana.pct>93
actions.burn+=/arcane_missiles,if=buff.arcane_charge.stack=4&(mana.pct>70|!cooldown.evocation.up|target.time_to_die<15)
actions.burn+=/supernova,if=mana.pct>70&mana.pct<96

Using Presence of Mind is part of a non-PC burn, but also added here as a safeguard in case it wasn't used during Prismatic Crystal for whatever reason. There is no need for it to have any higher priority, because it only applies to Arcane Blast and has no effect on instant spells or AM. The 96% mana threshold is because this usage of POM is mainly to avoid mana overflow, which happens when you begin casting AB at too high a level of mana.
The second line uses AB in the same way it is done during conserve phase; cast it over AM if the player is going to mana cap. If you don't understand why that is the case, read this: http://altered-time.com/forum/viewtopic.php?f=3&t=972" target="_blank
The remaining lines tell Robomage to use AM and SN if mana levels are high, or if evocation is still on CD, or if the enemy is about to die. AM and SN are higher DPET than AB and regenerate mana, so you always want to use it early if possible. The problem we want to avoid though, is getting stuck in burn phase for too long at a low mana level, and delaying cooldown timers in the future. By limiting AMs to >70% mana, we can avoid this problem.

70% was chosen from a mix of trial and error and common sense. Each AB4 consume ~6.8% mana after regen is accounted for. Going from 70% mana to 50% is around 3 casts, which means you can generate a maximum of 3 AM charges. Therefore, by staying at 0 AM charges until after hitting <70% mana, you can usually avoid AM charge overflow from the remaining spells until you Evocate.

actions.burn+=/evocation,interrupt_if=mana.pct>100-10%spell_haste,if=target.time_to_die>10&mana.pct<30+2.5*active_enemies*(9-active_enemies)-(40*(t18_class_trinket&buff.arcane_power.up))
actions.burn+=/presence_of_mind,if=!talent.prismatic_crystal.enabled|!cooldown.prismatic_crystal.up
actions.burn+=/arcane_blast
actions.burn+=/evocation

The final few lines of the burn action list starts with Evocation, which signals the end of a burn phase. Usually the first Evocation line is the one used. It sets a mana level that depends on number of enemies (since you burn less deep for more enemies), and whether the player is using the class trinket. The second one at the very end is a failsafe, in case Robomage runs OOM spamming Arcane Blasts with the class trinket.

In between the two Evocation lines is regular PoM usage, and AB. AB is casted with basically no conditions, which means it will be used whenever Robomage has the mana to do so. This gives the "when nothing else applies, spam AB" effect of the burn phase, until conditions are met for Evocation.

[Komma]

Prismatic Crystal

Going into WoD, the number one troublemaker for SimulationCraft devs was Prismatic Crystal. Prismatic Crystal is the first player-summoned entity that is both a minion and an attackable entity, but isn't an enemy. In an attempt to make things work, entirely new targeting systems needed to be created. This required a lot of code hacks just to get it working, and we still run into more problems with it than any other ability. Interestingly, this mirrors what we see in game, where PC keeps getting involved in weird bugs.

Prismatic Crystal is handled by two action lists init_crystal and crystal_sequence, which are called with top priority from within the burn action list.

actions.burn=call_action_list,name=init_crystal,if=talent.prismatic_crystal.enabled&cooldown.prismatic_crystal.up
actions.burn+=/call_action_list,name=crystal_sequence,if=talent.prismatic_crystal.enabled&pet.prismatic_crystal.active

The two calls are straight forward: "init_crystal if PC isn't used yet, crystal_sequence if PC is alive".

# Conditions for initiating Prismatic Crystal
actions.init_crystal=call_action_list,name=conserve,if=buff.arcane_charge.stack<4|(buff.arcane_missiles.react&debuff.
mark_of_doom.remains>2*spell_haste+(target.distance%20))
actions.init_crystal+=/arcane_missiles,if=buff.arcane_missiles.react&t18_class_trinket
actions.init_crystal+=/prismatic_crystal

init_crystal is a fairly short action list. The first line is a failsafe for handling Prophecy of Fear, or when init_crystal is called under 4 Arcane Charges for some reason. It defers back to the conserve list, which contains logic for handling Mark of Doom and building Arcane Charges with talents such as Arcane Orb. This is a shortcut to avoid duplicating code to handle these effects.

The second line is a recent addition to handle the class trinket, spending all Arcane Missiles charges before Prismatic Crystal is used. It is partially based on thoughts from this thread: http://altered-time.com/forum/viewtopic.php?f=3&t=1906" target="_blank . Due to limited testing, I'm not sure it's optimal if the player does not have 4T18. It probably needs some fine tuning.

The list terminates with summoning Prismatic Crystal, which starts a chain of actions to be chosen from the crystal_sequence action list instead, until Prismatic Crystal despawns.

Of note is the "(target.distance%20)" expression, which shows up a lot within the two lists. This is because Arcane Missiles has a 20 yard/sec velocity, which means that "target.distance%20" effectively means "action.arcane_missiles.travel_time". As mentioned in a previous post, channelled spells such as Arcane Missiles are implemented as pseudo-DoTs, which means that "action.arcane_missiles.travel_time" does not give a proper value. Due to Prismatic Crystal and Mark of Doom's limited lifespan, this forces us to give AM's travel time special treatment.

# Actions while Prismatic Crystal is active
actions.crystal_sequence=call_action_list,name=cooldowns
actions.crystal_sequence+=/nether_tempest,if=buff.arcane_charge.stack=4&!ticking&pet.prismatic_crystal.remains>8
actions.crystal_sequence+=/supernova,if=mana.pct<96
actions.crystal_sequence+=/presence_of_mind,if=cooldown.cold_snap.up|pet.prismatic_crystal.remains<2*spell_haste
actions.crystal_sequence+=/arcane_blast,if=buff.arcane_charge.stack=4&mana.pct>93&pet.prismatic_crystal.remains>cast_
time
actions.crystal_sequence+=/arcane_missiles,if=pet.prismatic_crystal.remains>2*spell_haste+(target.distance%20)
actions.crystal_sequence+=/supernova,if=pet.prismatic_crystal.remains<2*spell_haste+(target.distance%20)
actions.crystal_sequence+=/choose_target,if=pet.prismatic_crystal.remains<action.arcane_blast.cast_time&buff.presence
_of_mind.down
actions.crystal_sequence+=/arcane_blast

Similar to the burn action list, crystal_sequence begins by making sure that all cooldowns (Arcane Power, potions, racials) are used in synergy with the dropped crystal. By putting init_crystal first, we avoid the issue of wasting precious CD time on the GCD for summoning PC.

actions.crystal_sequence+=/nether_tempest,if=buff.arcane_charge.stack=4&!ticking&pet.prismatic_crystal.remains>8
actions.crystal_sequence+=/supernova,if=mana.pct<96

The first two lines of crystal_sequence are focused on T75 talents, SN and NT. NT is casted on PC as soon as it is summoned. By setting "!ticking&pet.prismatic_crystal.remains>8" as a condition, it will not be refreshed. This works well because both NT and PC have 12 second durations. SN is used as soon as mana levels are below 96%, which is almost always the case at the start, due to building 4 Arcane Charges before placing PC. The threshold 96% was chosen, since it is the point at which you can cast an Arcane Blast without mana capping.

actions.crystal_sequence+=/presence_of_mind,if=cooldown.cold_snap.up|pet.prismatic_crystal.remains<2*spell_haste
actions.crystal_sequence+=/arcane_blast,if=buff.arcane_charge.stack=4&mana.pct>93&pet.prismatic_crystal.remains>cast_time
actions.crystal_sequence+=/arcane_missiles,if=pet.prismatic_crystal.remains>2*spell_haste+(target.distance%20)

Using Presence of Mind allows you to "cheat" an extra AB onto PC, if you use it near the very end. "pet.prismatic_crystal.remains<2*spell_haste" denotes this, by checking the remaining time against the duration of Arcane Missiles. The catch is when you are specced into Cold Snap, which means you may want to use a charge early. By connecting the two cases with an OR operator, we get both within a single action.

The next two lines handle high mana AB and AM in a similar way to burn or conserve phases - AB when >93% mana, AM otherwise. The only added check is to make sure that the spell can be completed before PC expires.

actions.crystal_sequence+=/supernova,if=pet.prismatic_crystal.remains<2*spell_haste+(target.distance%20)

In this line, Supernova is casted as long as Prismatic Crystal has less time remaining than it would take to land Arcane Missiles on it. This is to guarantee that crazy AM luck streaks will not lead to an unused SN charge during PC. This is very important, because SN's cleave nature gives it an 80% damage bonus on PC, as opposed to a 30% damage bonus for most spells. The problem gets more complicated when you take into account travel time. If AM can be cast with enough time to impact PC, then SN can easily be used right after it during the travel time, while the reverse may not be true. This forces you to use AM as early as possible. On the other hand, AB has no impact on this, because it has no travel time, and would lead to a mana deficit below 96%. On the next spell selection, the first SN would then have the "mana.pct<96" condition fulfilled, and be executed.

actions.crystal_sequence+=/choose_target,if=pet.prismatic_crystal.remains<action.arcane_blast.cast_time&buff.presence_of_mind.down
actions.crystal_sequence+=/arcane_blast

The last two lines make sure that Robomage will spam AB on PC when there is nothing else to do, while making sure that he won't be interrupted mid cast by PC running out of time. Due to Presence of Mind making the spell instant, we need to include checking the buff as an exception case.

At this point it is worth mentioning that the Prismatic Crystal APL doesn't go out of its way to accommodate Prophecy of Fear or the class trinket. The key difficulty with Prophecy of Fear is due to Prismatic Crystal, Mark of Doom and Arcane Missiles' hackish nature, which meant that many intuitive simc statements could not work correctly. For example, "target_if=max:debuff.mark_of_doom.remains" would not work directly with Arcane Missiles, due to Arcane Missiles being a two-part spell within SimulationCraft, and the bolts not necessarily impacting the target designated by target_if. This is an additional aspect of APL development often not considered by the community; not only do we need to verify that the Robomage is playing as we would like him to, but we also need to verify that when using newer tools, the simulation is behaving correctly. To verify that a complicated Mark of Doom-optimized APL is working perfectly would require dedicating a painstaking amount of time just to comb through disorganized debug logs, which I cannot commit to at the moment.

For the class trinket, experimentation has been done with shifting around Arcane Missiles and Arcane Blast priority (with t18_class_trinket as a condition), but I couldn't find any statement that would work as a general purpose improvement across the board. Part of this might be due to the analysis shown in another thread (http://altered-time.com/forum/viewtopic.php?f=3&t=1906" target="_blank), which explains how AB spam during AP does not necessarily lead to better results (even if it provides higher damage throughput during Arcane Power). The gains are lost due to extra time spent on Evocation afterwards. Once again, this is a very complicated problem that needs to take into consideration a large variety of variables (Ring level, trinket level, Unstable Magic, Prismatic Crystal, glyphed vs unglyphed AP, haste levels), adding considerably to the difficulty of finding an all-round solution, if it even exists.

[Komma]

Conserve Phase

The conserve action list is where Robomage ends up spending most (>70%) of his time. It is also the final list by default, which is executed when no other conditions apply. As the last catch-all before Robomage runs out of actions to choose from, it is important to consider all possible scenarios and handle them correctly.

# Low mana usage, "Conserve" sequence
actions.conserve=call_action_list,name=cooldowns,if=target.time_to_die<15
actions.conserve+=/arcane_missiles,if=buff.arcane_missiles.react=3|(talent.overpowered.enabled&buff.arcane_power.up&buff.arcane_power.remains<action.arcane_blast.execute_time)
actions.conserve+=/arcane_missiles,if=set_bonus.tier17_4pc&buff.arcane_instability.react&buff.arcane_instability.remains<action.arcane_blast.execute_time
actions.conserve+=/nether_tempest,cycle_targets=1,if=target!=pet.prismatic_crystal&buff.arcane_charge.stack=4&(active_dot.nether_tempest=0|(ticking&remains<3.6))
actions.conserve+=/supernova,if=target.time_to_die<8|(charges=2&(buff.arcane_power.up|!cooldown.arcane_power.up|!legendary_ring.cooldown.up)&(!talent.prismatic_crystal.enabled|cooldown.prismatic_crystal.remains>8))
actions.conserve+=/arcane_orb,if=buff.arcane_charge.stack<2
actions.conserve+=/presence_of_mind,if=mana.pct>96&(!talent.prismatic_crystal.enabled|!cooldown.prismatic_crystal.up)
actions.conserve+=/arcane_missiles,if=buff.arcane_missiles.react&debuff.mark_of_doom.remains>2*spell_haste+(target.distance%20)
actions.conserve+=/arcane_blast,if=buff.arcane_charge.stack=4&mana.pct>93
actions.conserve+=/arcane_barrage,if=talent.arcane_orb.enabled&active_enemies>=3&buff.arcane_charge.stack=4&(cooldown.arcane_orb.remains<gcd.max|prev_gcd.arcane_orb)
actions.conserve+=/arcane_missiles,if=buff.arcane_charge.stack=4&(!talent.overpowered.enabled|cooldown.arcane_power.remains>10*spell_haste|legendary_ring.cooldown.remains>10*spell_haste)
actions.conserve+=/supernova,if=mana.pct<96&(buff.arcane_missiles.stack<2|buff.arcane_charge.stack=4)&(buff.arcane_power.up|(charges=1&(cooldown.arcane_power.remains>recharge_time|legendary_ring.cooldown.remains>recharge_time)))&(!talent.prismatic_crystal.enabled|current_target=pet.prismatic_crystal|(charges=1&cooldown.prismatic_crystal.remains>recharge_time+8))
actions.conserve+=/nether_tempest,cycle_targets=1,if=target!=pet.prismatic_crystal&buff.arcane_charge.stack=4&(active_dot.nether_tempest=0|(ticking&remains<(10-3*talent.arcane_orb.enabled)*spell_haste))
actions.conserve+=/arcane_barrage,if=buff.arcane_charge.stack=4
actions.conserve+=/presence_of_mind,if=buff.arcane_charge.stack<2&mana.pct>93
actions.conserve+=/arcane_blast
actions.conserve+=/arcane_barrage

The list starts with a safety check, making sure that cooldowns are desynced and used when the fight is about to end. This applies especially in shorter duration sims, when you can't wait for cooldowns to line up again before using them.

---Under construction---

I'll finish this later.

[Komma]

End Word

To be added later.

[Komma]

Here are some goals that consistently correlate with throughput:
- Maximize uptime/usage of cooldowns (Arcane Power/Prismatic Crystal) and talents (Supernova/Nether Tempest/Rune of Power/Mirror Images)
- Avoid capping mana, and get as close to converting 100% of excess mana into Arcane Blasts and Missiles casted at maximum Arcane Charges
- Stay as close to full mana as possible otherwise (while avoiding mana cap), to maximize benefits from Mana Adept

Those should be viable concluding points or starting points instead of goals. It is intuitive that in most cases it will result to those and if they are goals they make a good starting point but the coder should not assume they are de facto correct. This is especially true when it goes to complex cases such as the legendary ring is up, or a boss with a burn phase is simulated, or even when in a patchwerk case it's not bad to question conventional wisdom.

Recovering a post made by Curnivore that I removed, because I didn't want it to be stuck in the middle of walls of text.

[Naedrim]

This is glorious Komma. I'm sure you've already gotten pats on the back over at the IRC for this, but damn this is just so fantastic.

[Zifnab]

Just wanted to mention that some of your APL lines are rather long, and the length is completely hidden by the forum's blockquote styling. The only way to see what these lines are is by inspecting-element, or copy-pasting the blockquote into a separate text editor:

Code: Select all

blockquote { background: #ebebeb none 6px 8px no-repeat; border: 1px solid #dbdbdb; font-size: 0.95em; margin: 0.5em 1px 0 25px; overflow: hidden; padding: 5px; max-height: 900px; overflow-y: scroll; }

I'd suggest perhaps changing the "overflow:hidden" to "overflow:scroll", and remove the overflow-y.

Just a thought! Awesome post though, Thank you Komma for this.

[Curnivore]

The value "2 * spell_haste" is in fact the channel duration of Arcane Missiles, which is the longest duration cast for Arcane Mages

Are there user set variables in scripts? That line makes me think a "var AM_Channel_Duration = 2 * spell_haste" might make it more readable. If not it might be a good feature ask.

[Frosted]

The value "2 * spell_haste" is in fact the channel duration of Arcane Missiles, which is the longest duration cast for Arcane Mages

Are there user set variables in scripts? That line makes me think a "var AM_Channel_Duration = 2 * spell_haste" might make it more readable. If not it might be a good feature ask.

We could make it. Not quite sure it'd be worth it for that, though.

[Curnivore]

Not just for that, I mean for the general readability of scripts.

[Frosted]

Not just for that, I mean for the general readability of scripts.

I know, I am hesitant because of exactly that. It's a rabbit hole of us adding (potentially a lot) more custom expressions to the module to make the APL more end-user friendly. I'm not sure it's worth the time investment (or the added bloat). Additionally, I'd rather the people who are interested in the APL learn how to use the right tools, rather than rely on us hiding them behind custom variables.

[Curnivore]

Alternatively it could have comments above cryptic lines. I remember that line trying to describe AOE and single target on the same formula. That would be almost impossible to decypher without a thread like this.

[Frosted]

Comments are the better option between the two, I'd say.

[Komma]

Here are some goals that consistently correlate with throughput:
- Maximize uptime/usage of cooldowns (Arcane Power/Prismatic Crystal) and talents (Supernova/Nether Tempest/Rune of Power/Mirror Images)
- Avoid capping mana, and get as close to converting 100% of excess mana into Arcane Blasts and Missiles casted at maximum Arcane Charges
- Stay as close to full mana as possible otherwise (while avoiding mana cap), to maximize benefits from Mana Adept

Those should be viable concluding points or starting points instead of goals. It is intuitive that in most cases it will result to those and if they are goals they make a good starting point but the coder should not assume they are de facto correct. This is especially true when it goes to complex cases such as the legendary ring is up, or a boss with a burn phase is simulated, or even when in a patchwerk case it's not bad to question conventional wisdom.

Been a busy week, so I'm a bit late in replying to this.

The word "goal" is for describing what happened during optimization, and the conclusions made from the experience of doing so. We don't start with saying "the goal is to get 100% uptime and ignore overall DPS output". It would be very silly to do so, when our goal is to find out what works best. These goals are not conventional wisdom, as much as an observation of what seemed to work.

The emphasis needed to be made, because the last 2 years have taught me how much the forums enjoy pinpoint focusing on small tricks, and using them as ammunition for attacking our results. One of the more memorable ones was when someone tried to call us out for "not syncing evocation to the final second of bloodlust/some other temporary haste buff".

Just wanted to mention that some of your APL lines are rather long, and the length is completely hidden by the forum's blockquote styling. The only way to see what these lines are is by inspecting-element, or copy-pasting the blockquote into a separate text editor:

I noticed this as well while compiling the post. Dutch is taking a look at it to see if stylesheet changes can be made without breaking it for anyone.

Are there user set variables in scripts? That line makes me think a "var AM_Channel_Duration = 2 * spell_haste" might make it more readable. If not it might be a good feature ask.

I've inquired a few times over the last year about get/set variable functionalities in the APL, but the short answer is that there isn't a good way to do it under the existing framework. In fact, a rough version already exists in code. One big problem with them is that they are implemented as actions. This means they would have no GCD, but still trigger another APL scan from the top, reaching the same point again but needing logic to avoid infinite loops, cause cache invalidation, and lead to a very long list of problems we don't want to deal with.

Another approach would have been to do the calculations in code and maybe memoize some of the results. However, our approach since joining the SimulationCraft project has been to be as transparent as we can be within the APL, instead of abstracting complications away in black-box-like C++ source code. This would be a large departure from that philosophy.

[Curnivore]

How does an APL mainly trigger the legendary ring by the way? I mainly notice cooldown checks for it. It's as if the application triggers it externally but I doubt that's true.

[Komma]

How does an APL mainly trigger the legendary ring by the way? I mainly notice cooldown checks for it. It's as if the application triggers it externally but I doubt that's true.

actions.cooldowns+=/use_item,slot=finger2

I should really find the time to tie this thread up...

[Curnivore]

Komma, how can we reliably edit the script to test for fewer stacks of Arcane Charge before the opener or to avoid using the Crystal for Arcane Missiles? People might be only editing the initialization line. But I heard you or another dev mentioning that this is wrong since the script uses other synergy and it can't just be edited in isolation.

[Komma]

There isn't any easy way to do it. The best thing you can do is change stuff around until you actually see robomage doing what you want him to do, over a number of iterations. That's pretty much what Skiz has been doing. In the case, off the top of my head, you'll have to fix burn phase initiation conditions, list ordering in the master list, conserve phase handling of the pull (because of how on-pull is deferred to conserve), and I don't remember what else.

The problem with most of the suggestions we've seen is this: they make a change in the APL, assume that robomage is doing what they want it to do, and then call it the day. It's the equivalent of a blind electrician messing with switches and wires, and then assuming the light has been turned on properly.