Пошаговое руководство
по редактированию и анализу APL в симуляциях
На примере фдк
Обновлено 29.06.2025
Это руководство поможет игрокам World of Warcraft, которые хотят научиться редактировать APL (Action Priority List) для симуляций в SimulationCraft/Raidbots. Даже если вы не знакомы с программированием, но понимаете игровые термины и механику классов, вы сможете разобраться в том, как настраивать профили, редактировать приоритеты и анализировать результаты симуляций.
настройка профилей
Все актуальные профили для каждого класса и специализации на текущий сезон хранятся на GitHub по ссылке:
https://github.com/simulationcraft/simc/tree/thewarwithin/profiles
Их поддерживают теорикрафтеры и авторы гайдов по каждой специализации. Обычно для каждой специализации есть два профиля (по героическому таланту), но встречаются и более простые версии с одним профилем.
https://github.com/simulationcraft/simc/tree/thewarwithin/profiles
Их поддерживают теорикрафтеры и авторы гайдов по каждой специализации. Обычно для каждой специализации есть два профиля (по героическому таланту), но встречаются и более простые версии с одним профилем.
Шаг 1. Откройте GitHub и выберите профиль
Перейдите по ссылке и выполните следующие шаги:
- Выберите сезон, с которым вы работаете
- Выберите класс, для которого хотите редактировать APL
- Откройте файл профиля и скопируйте его содержимое целиком
Шаг 2. Загрузите профиль на Raidbots
Обратите внимание! Для небольших правок и тестирования отдельных изменений не обязательно использовать режим Advanced - проще и быстрее воспользоваться стандартным симулятором в разделе Top Gear, которым пользуются большинство игроков. Advanced рекомендуется для более глубоких изменений и анализа сложных ситуаций, когда нужно работать с полным профилем и множеством вариантов.
Перейдите на сайт Raidbots (Advanced Sim):
https://www.raidbots.com/simbot/advanced
Так вы получите базовый профиль, на основе которого будете редактировать APL. По желанию можно сделать его компактнее, удалив промежуточные секции - от строки:
# This default action priority list is automatically created based on your character.
до строки:
actions.variables+=/variable,name=fwf_buffs,value=(buff.pillar_of_frost.remains<gcd.max|(buff.unholy_strength.up&buff.unholy_strength.remains<gcd.max)|(talent.bonegrinder.rank=2&buff.bonegrinder_frost.up&buff.bonegrinder_frost.remains<gcd.max))&(active_enemies>1|debuff.razorice.stack=5|!death_knight.runeforge.razorice&(!talent.glacial_advance|!talent.avalanche|!talent.arctic_assault)|talent.shattering_blade)
Эта часть профиля также называется APL-секция профиля. Если APL явно не прописан, оригинальный профиль будет по умолчанию использовать стандартный APL, встроенный в симулятор. Такой подход делает профиль немного аккуратнее, но может вызвать путаницу, если что-то сделать неправильно.
Кроме того, вы можете изменить экипировку, таланты или расу персонажа прямо в тексте этого профиля. Эти изменения автоматически применятся ко всем копиям и вариантам профиля, которые вы создадите на его основе.

В самом низу окна симулятора добавьте несколько пустых строк и напишите:
copy="test"

Эта команда создаст копию профиля, которая сохранит все ключевые параметры оригинального профиля, за исключением тех, что вы будете менять в этой копии.
Для начала работы с редактированием APL в этой копии вы можете вставить сюда именно ту APL-секцию, которую ранее по желанию удаляли из профиля, и производить с ней эксперименты.

Прежде чем перейти непосредственно к редактированию APL, необходимо упомянуть ещё один важный момент - настройку условий боя.
В верхней части текстового поля Raidbots вставьте следующие строки:
В верхней части текстового поля Raidbots вставьте следующие строки:
single_actor_batch=1
report_details=1
desired_targets=1
target_error=0.05
iterations=100000
max_time=300
optimal_raid=1
ptr=0
Эти параметры задают базовые условия боя, которые будут использоваться в симуляции. Большинство из них очевидны и не требуют подробных объяснений - значение
Важно, чтобы
Ниже приводятся дополнительные строки, которые позволяют явно задать рейдовые баффы:
override.bloodlust=0
override.arcane_intellect=0
override.power_word_fortitude=0
override.mark_of_the_wild=0
override.battle_shout=0
override.mystic_touch=0
override.chaos_brand=0
override.skyfury=0
override.hunters_mark=0
override.bleeding=0
И отдельная строка для Power Infusion:
external_buffs.power_infusion=120
Полный список всех доступных баффов и дебаффов можно найти на вики SimulationCraft:
https://github.com/simulationcraft/simc/wiki/BuffsAndDebuffs
https://www.raidbots.com/simbot/advanced
- Вставьте скопированный профиль в большое текстовое поле.

Так вы получите базовый профиль, на основе которого будете редактировать APL. По желанию можно сделать его компактнее, удалив промежуточные секции - от строки:
# This default action priority list is automatically created based on your character.
до строки:
actions.variables+=/variable,name=fwf_buffs,value=(buff.pillar_of_frost.remains<gcd.max|(buff.unholy_strength.up&buff.unholy_strength.remains<gcd.max)|(talent.bonegrinder.rank=2&buff.bonegrinder_frost.up&buff.bonegrinder_frost.remains<gcd.max))&(active_enemies>1|debuff.razorice.stack=5|!death_knight.runeforge.razorice&(!talent.glacial_advance|!talent.avalanche|!talent.arctic_assault)|talent.shattering_blade)
Эта часть профиля также называется APL-секция профиля. Если APL явно не прописан, оригинальный профиль будет по умолчанию использовать стандартный APL, встроенный в симулятор. Такой подход делает профиль немного аккуратнее, но может вызвать путаницу, если что-то сделать неправильно.
Кроме того, вы можете изменить экипировку, таланты или расу персонажа прямо в тексте этого профиля. Эти изменения автоматически применятся ко всем копиям и вариантам профиля, которые вы создадите на его основе.
- После этого прокрутите окно симулятора в самый низ.

В самом низу окна симулятора добавьте несколько пустых строк и напишите:
copy="test"

Эта команда создаст копию профиля, которая сохранит все ключевые параметры оригинального профиля, за исключением тех, что вы будете менять в этой копии.
Для начала работы с редактированием APL в этой копии вы можете вставить сюда именно ту APL-секцию, которую ранее по желанию удаляли из профиля, и производить с ней эксперименты.

Прежде чем перейти непосредственно к редактированию APL, необходимо упомянуть ещё один важный момент - настройку условий боя.
В верхней части текстового поля Raidbots вставьте следующие строки:
В верхней части текстового поля Raidbots вставьте следующие строки:
single_actor_batch=1
report_details=1
desired_targets=1
target_error=0.05
iterations=100000
max_time=300
optimal_raid=1
ptr=0
Эти параметры задают базовые условия боя, которые будут использоваться в симуляции. Большинство из них очевидны и не требуют подробных объяснений - значение
1
означает включено, а 0
-
выключено.Важно, чтобы
report_details
всегда было равно 1
, чтобы получить подробный отчёт.Ниже приводятся дополнительные строки, которые позволяют явно задать рейдовые баффы:
override.bloodlust=0
override.arcane_intellect=0
override.power_word_fortitude=0
override.mark_of_the_wild=0
override.battle_shout=0
override.mystic_touch=0
override.chaos_brand=0
override.skyfury=0
override.hunters_mark=0
override.bleeding=0
И отдельная строка для Power Infusion:
external_buffs.power_infusion=120
Полный список всех доступных баффов и дебаффов можно найти на вики SimulationCraft:
https://github.com/simulationcraft/simc/wiki/BuffsAndDebuffs
Редактирование APL
После того как мы настроили профиль и задали параметры симуляции, можно переходить непосредственно к редактированию APL (Action Priority List).
APL для рыцаря смерти разделён на несколько отдельных списков - по сути это мини‑APL, которые вызываются в зависимости от различных условий боя.
Ниже приведён список действий для специализации фрост дк.

На данном этапе подробное понимание этой таблицы не является обязательным, однако она может помочь вам сосредоточиться на конкретных секциях, которые вы хотите редактировать. Кроме того, это хорошее введение в синтаксис APL и его основные правила.
Давайте посмотрим на вызов действия для cold_heart и на его примере разберём синтаксис APL:
actions+=/call_action_list,name=cold_heart,if=talent.cold_heart&(!buff.killing_machine.up|talent.breath_of_sindragosa)&((debuff.razorice.stack=5|!death_knight.runeforge.razorice&!talent.glacial_advance&!talent.avalanche&!talent.arctic_assault)|fight_remains<=gcd)
What is happening = В данном случае это немного отличается от стандартной строки APL, однако по сути означает следующее - «это выполняется. Это действие, которое должно быть выполнено».
Why it’s happening = Это описание условий, при которых происходит выполнение действия. Всё, что следует после данной части, указывает симулятору, когда именно необходимо выполнить действие.
& = Оператор и. Он связывает два условия и требует, чтобы оба условия были выполнены одновременно. Пример формулировки на естественном языке - «Игрок имеет активный бафф и выбранный талант».
| = Оператор или. Он разделяет два условия, из которых должно быть выполнено хотя бы одно. Это позволяет объединять несколько условий в одной строке для компактности. В естественном языке это можно представить как - «Игрок потерял здоровье, или на него наложен дебафф» - условия разные, но не исключающие друг друга.
() = Скобки. Используются для группировки условий. Подобно математическому правилу порядка операций (BODMAS), всё, что находится внутри скобок, вычисляется в первую очередь и влияет на выражение целиком. Это позволяет более компактно и наглядно оформлять сложные или вложенные условия. Например - «Игрок потерял здоровье (из‑за атаки босса или действия окружения)».
! = Отрицание. Это означает, что если условие не выполняется, то оно считается истинным для выполнения APL. Например -
talent = Проверка выбранного таланта. Если указанный талант выбран игроком, условие считается выполненным.
buff = Проверка активного баффа. Если на персонаже активен указанный бафф, условие считается выполненным.
debuff = Проверка дебаффа. Если на противнике наложен указанный дебафф, условие считается выполненным.
stack = Проверка количества стаков. Следует обратить внимание, что используется именно
= = Оператор равенства. Условие выполняется, если значение точно соответствует заданному.
> or < = Операторы сравнения. Символ
up = Условие активности эффекта. В данном контексте проверяется, активен ли указанный эффект. Например, проверяется, активны ли способности Ледяной столп или Беспощадность зимы. Это важная часть синтаксиса APL, позволяющая учитывать текущие состояния эффектов на персонаже.
Ticking = Данный элемент синтаксиса не имеет большого значения для специализации фрост, однако обычно используется для обозначения эффектов периодического урона, которые могут обладать дополнительной функциональностью. Например, способность Смерть и разложение, которая продолжает существовать на земле после нанесения урона, чтобы различать момент нанесения урона и период, когда эффект только поддерживается.
Dot = Эффекты периодического урона (Damage over Time), которые представляют собой разновидность баффов или дебаффов, но более специализированные.
Воспринимайте этот раздел скорее как справочник, к которому можно возвращаться при разборе и адаптации других строк APL.
Теперь перейдём к рассмотрению конкретной строки APL.
actions.cooldowns+=/any_dnd,if=!buff.death_and_decay.up&(raid_event.adds.remains>5|!raid_event.adds.exists&active_enemies>1)&(buff.pillar_of_frost.up&buff.killing_machine.react&(talent.enduring_strength|buff.pillar_of_frost.remains>5))&(active_enemies>5|talent.cleaving_strikes&active_enemies>=2)
actions.cooldowns+=/any_dnd,if=!buff.death_and_decay.up&(raid_event.adds.remains>5|!raid_event.adds.exists&active_enemies>1)&(buff.pillar_of_frost.up&buff.killing_machine.react&(talent.enduring_strength|buff.pillar_of_frost.remains>5))&(active_enemies>5|talent.cleaving_strikes&active_enemies>=2)
Прежде чем продолжить, необходимо рассмотреть ещё два важных ключевых слова.
react = Встроенная задержка реакции симулятора на срабатывание эффекта, предназначенная для того, чтобы соответствовать человеческой скорости реакции. Данный элемент часто используется при проверке состояния Машина для убийств.
remains = Проверяет оставшееся время перезарядки способности относительно указанного числа. Также может использоваться для проверки оставшейся продолжительности баффа, например Высвобожденное бешенство.
Также следует отметить наличие проверок событий рейда (raid event checks) и проверок количества активных противников (active enemy checks). Эти элементы позволяют разделять решения для одной цели и для AoE‑ситуаций. Однако, на практике лучше модифицировать эти параметры под конкретную ситуацию.
Теперь полностью разберём следующую строку APL.
actions.cooldowns+=/any_dnd - при вызове списка действий кулдаунов применяется любая версия DnD (Осквернение / Смерть и разложение и т. д.)
,if= - если следующие условия выполняются.
!buff.death_and_decay - бафф Смерть и разложение (сам эффект рассекающие удары) в данный момент не активен.
&(raid_event.adds.remains>5|!raid_event.adds.exists&active_enemies>1) - и выполняются все условия внутри: дополнительные цели будут существовать ещё более 5 секунд или дополнительные цели отсутствуют, но количество активных противников больше одного.
&(buff.pillar_of_frost.up&buff.killing_machine.react&(talent.enduring_strength|buff.pillar_of_frost.remains>5)) - и выполняются все условия внутри: Ледяной столп активен, Машина для убийств среагировал в пределах человеческой скорости реакции, и при этом либо выбран талант Стойкая сила, либо Ледяной столп будет длиться более 5 секунд.
&(active_enemies>5|talent.cleaving_strikes&active_enemies>=2) - и выполняются все условия внутри: количество противников больше пяти или выбран талант Cleaving Strikes и количество активных противников не менее двух.
Что это значит?
Эта строка выполняется, если Смерть и разложение не активен, событие AoE продлится более 5 секунд или существует стабильная AoE‑цель, а также активен Ледяной столп и готов Машина для убийств, при этом Ледяной столп будет длиться ещё более 5 секунд или выбран талант Стойкая сила, а количество противников либо больше пяти, либо два и более при наличии таланта рассекающие удары.
На первый взгляд строка кажется неочевидной, но при поэтапном разборе становится понятно, как она устроена и какие её элементы можно модифицировать для изменения поведения.
Предположим, что необходимо изменить её поведение - например, добавить условие на Bonegrinder.
В первую очередь необходимо скорректировать параметры симуляции боя.

Поскольку планируется моделирование в условиях боя по нескольким целям (AoE), целесообразно установить количество желаемых целей равным 5. Для обеспечения полноты анализа следует включить параметр

Далее имя профиля изменяется в соответствии с внесёнными изменениями для удобства ведения учёта и последующей идентификации созданного варианта.

На следующем этапе рекомендуется изолировать редактируемую строку для упрощения анализа и минимизации вероятности возникновения ошибок при внесении изменений.
Далее необходимо добавить условие, соответствующее проверке Костолом, в логическую конструкцию.
Поскольку все условия внутри строки взаимосвязаны и конструкция с использованием оператора

Таким образом, в конец строки добавляется условие

Результаты симуляции показывают значительное снижение наносимого урона в секунду (DPS).
APL для рыцаря смерти разделён на несколько отдельных списков - по сути это мини‑APL, которые вызываются в зависимости от различных условий боя.
Ниже приведён список действий для специализации фрост дк.

На данном этапе подробное понимание этой таблицы не является обязательным, однако она может помочь вам сосредоточиться на конкретных секциях, которые вы хотите редактировать. Кроме того, это хорошее введение в синтаксис APL и его основные правила.
Давайте посмотрим на вызов действия для cold_heart и на его примере разберём синтаксис APL:
actions+=/call_action_list,name=cold_heart,if=talent.cold_heart&(!buff.killing_machine.up|talent.breath_of_sindragosa)&((debuff.razorice.stack=5|!death_knight.runeforge.razorice&!talent.glacial_advance&!talent.avalanche&!talent.arctic_assault)|fight_remains<=gcd)
What is happening = В данном случае это немного отличается от стандартной строки APL, однако по сути означает следующее - «это выполняется. Это действие, которое должно быть выполнено».
Why it’s happening = Это описание условий, при которых происходит выполнение действия. Всё, что следует после данной части, указывает симулятору, когда именно необходимо выполнить действие.
& = Оператор и. Он связывает два условия и требует, чтобы оба условия были выполнены одновременно. Пример формулировки на естественном языке - «Игрок имеет активный бафф и выбранный талант».
| = Оператор или. Он разделяет два условия, из которых должно быть выполнено хотя бы одно. Это позволяет объединять несколько условий в одной строке для компактности. В естественном языке это можно представить как - «Игрок потерял здоровье, или на него наложен дебафф» - условия разные, но не исключающие друг друга.
() = Скобки. Используются для группировки условий. Подобно математическому правилу порядка операций (BODMAS), всё, что находится внутри скобок, вычисляется в первую очередь и влияет на выражение целиком. Это позволяет более компактно и наглядно оформлять сложные или вложенные условия. Например - «Игрок потерял здоровье (из‑за атаки босса или действия окружения)».
! = Отрицание. Это означает, что если условие не выполняется, то оно считается истинным для выполнения APL. Например -
!buff.killing_machine.stack=2
означает, что условие выполнено до тех пор, пока количество стаков Машина для убийств не равно двум.talent = Проверка выбранного таланта. Если указанный талант выбран игроком, условие считается выполненным.
buff = Проверка активного баффа. Если на персонаже активен указанный бафф, условие считается выполненным.
debuff = Проверка дебаффа. Если на противнике наложен указанный дебафф, условие считается выполненным.
stack = Проверка количества стаков. Следует обратить внимание, что используется именно
stack
, а не stacks
. Этот элемент используется для любых баффов или дебаффов, которые имеют накопительный эффект, и может комбинироваться с другими условиями.= = Оператор равенства. Условие выполняется, если значение точно соответствует заданному.
> or < = Операторы сравнения. Символ
>
означает, что значение должно быть больше указанного числа, а <
- что значение должно быть меньше указанного числа.up = Условие активности эффекта. В данном контексте проверяется, активен ли указанный эффект. Например, проверяется, активны ли способности Ледяной столп или Беспощадность зимы. Это важная часть синтаксиса APL, позволяющая учитывать текущие состояния эффектов на персонаже.
Ticking = Данный элемент синтаксиса не имеет большого значения для специализации фрост, однако обычно используется для обозначения эффектов периодического урона, которые могут обладать дополнительной функциональностью. Например, способность Смерть и разложение, которая продолжает существовать на земле после нанесения урона, чтобы различать момент нанесения урона и период, когда эффект только поддерживается.
Dot = Эффекты периодического урона (Damage over Time), которые представляют собой разновидность баффов или дебаффов, но более специализированные.
Воспринимайте этот раздел скорее как справочник, к которому можно возвращаться при разборе и адаптации других строк APL.
Теперь перейдём к рассмотрению конкретной строки APL.
actions.cooldowns+=/any_dnd,if=!buff.death_and_decay.up&(raid_event.adds.remains>5|!raid_event.adds.exists&active_enemies>1)&(buff.pillar_of_frost.up&buff.killing_machine.react&(talent.enduring_strength|buff.pillar_of_frost.remains>5))&(active_enemies>5|talent.cleaving_strikes&active_enemies>=2)
actions.cooldowns+=/any_dnd,if=!buff.death_and_decay.up&(raid_event.adds.remains>5|!raid_event.adds.exists&active_enemies>1)&(buff.pillar_of_frost.up&buff.killing_machine.react&(talent.enduring_strength|buff.pillar_of_frost.remains>5))&(active_enemies>5|talent.cleaving_strikes&active_enemies>=2)
Прежде чем продолжить, необходимо рассмотреть ещё два важных ключевых слова.
react = Встроенная задержка реакции симулятора на срабатывание эффекта, предназначенная для того, чтобы соответствовать человеческой скорости реакции. Данный элемент часто используется при проверке состояния Машина для убийств.
remains = Проверяет оставшееся время перезарядки способности относительно указанного числа. Также может использоваться для проверки оставшейся продолжительности баффа, например Высвобожденное бешенство.
Также следует отметить наличие проверок событий рейда (raid event checks) и проверок количества активных противников (active enemy checks). Эти элементы позволяют разделять решения для одной цели и для AoE‑ситуаций. Однако, на практике лучше модифицировать эти параметры под конкретную ситуацию.
Теперь полностью разберём следующую строку APL.
actions.cooldowns+=/any_dnd - при вызове списка действий кулдаунов применяется любая версия DnD (Осквернение / Смерть и разложение и т. д.)
,if= - если следующие условия выполняются.
!buff.death_and_decay - бафф Смерть и разложение (сам эффект рассекающие удары) в данный момент не активен.
&(raid_event.adds.remains>5|!raid_event.adds.exists&active_enemies>1) - и выполняются все условия внутри: дополнительные цели будут существовать ещё более 5 секунд или дополнительные цели отсутствуют, но количество активных противников больше одного.
&(buff.pillar_of_frost.up&buff.killing_machine.react&(talent.enduring_strength|buff.pillar_of_frost.remains>5)) - и выполняются все условия внутри: Ледяной столп активен, Машина для убийств среагировал в пределах человеческой скорости реакции, и при этом либо выбран талант Стойкая сила, либо Ледяной столп будет длиться более 5 секунд.
&(active_enemies>5|talent.cleaving_strikes&active_enemies>=2) - и выполняются все условия внутри: количество противников больше пяти или выбран талант Cleaving Strikes и количество активных противников не менее двух.
Что это значит?
Эта строка выполняется, если Смерть и разложение не активен, событие AoE продлится более 5 секунд или существует стабильная AoE‑цель, а также активен Ледяной столп и готов Машина для убийств, при этом Ледяной столп будет длиться ещё более 5 секунд или выбран талант Стойкая сила, а количество противников либо больше пяти, либо два и более при наличии таланта рассекающие удары.
На первый взгляд строка кажется неочевидной, но при поэтапном разборе становится понятно, как она устроена и какие её элементы можно модифицировать для изменения поведения.
Предположим, что необходимо изменить её поведение - например, добавить условие на Bonegrinder.
В первую очередь необходимо скорректировать параметры симуляции боя.

Поскольку планируется моделирование в условиях боя по нескольким целям (AoE), целесообразно установить количество желаемых целей равным 5. Для обеспечения полноты анализа следует включить параметр
report_details
, который обеспечивает формирование подробного отчёта о ходе симуляции. Для повышения достоверности результатов устанавливается низкий уровень погрешности target_error
, равный 0.05. Дополнительно увеличивается число итераций для минимизации влияния случайных факторов и повышения стабильности данных. Максимальная длительность боя задаётся равной двум минутам в рамках рассматриваемого сценария.
Далее имя профиля изменяется в соответствии с внесёнными изменениями для удобства ведения учёта и последующей идентификации созданного варианта.

На следующем этапе рекомендуется изолировать редактируемую строку для упрощения анализа и минимизации вероятности возникновения ошибок при внесении изменений.
Далее необходимо добавить условие, соответствующее проверке Костолом, в логическую конструкцию.
Поскольку все условия внутри строки взаимосвязаны и конструкция с использованием оператора
|
заключена в скобки, новое условие может быть добавлено в конец строки. Оно будет корректно учтено в рамках общей логической проверки.
Таким образом, в конец строки добавляется условие
buff.bonegrinder_frost.up
, поскольку в данном случае приоритетом является компонент урона от льда, а не компонент критического удара. После внесения изменения запускается симуляция для проверки результатов.
Результаты симуляции показывают значительное снижение наносимого урона в секунду (DPS).
Анализ строки - где в отчёте искать информацию для понимания её поведения
На данном этапе встаёт вопрос - где именно в отчёте следует искать информацию, позволяющую понять, почему данная строка работает таким образом.

На следующем этапе следует открыть HTML‑отчёт симуляции. Для обеспечения корректности анализа рекомендуется открыть отдельный отчёт для каждого исследуемого варианта APL, так как одновременное сравнение нескольких изменений в одном отчёте может затруднить интерпретацию результатов.

После этого необходимо открыть оба профиля, участвующих в сравнении, чтобы провести детальный анализ различий в их поведении.

В результате открывается детализированная таблица отчёта, объём которой значительно превышает пределы одного экрана и включает множество вспомогательных элементов, не имеющих непосредственного отношения к рассматриваемому вопросу.
Данные элементы на данном этапе рекомендуется оставить без внимания, поскольку первоочередной анализ следует начинать с информации, расположенной в нижней части отчёта.

Откройте раздел отчёта, содержащий список приоритетов действий (Action Priority List), для последующего анализа.

Данный раздел содержит два полезных источника информации - первый представляет собой детализированное поштучное распределение всех строк APL, сработавших в ходе симуляции, а второй - пример журнала событий (sample log), отражающий последовательность выполнения действий.

Это позволяет получить как макроуровневое, так и микроуровневое представление о происходивших в ходе симуляции событиях, каждое из которых полезно для анализа в своей области.
В первую очередь рассматривается макроуровневый анализ журнала событий.

Далее необходимо перейти к разделу отчёта, содержащему список строк APL, и найти ту строку, которая подвергалась редактированию. Если возникает затруднение с её идентификацией, следует ориентироваться на её начальную часть, которая ранее в данном руководстве выделялась зелёным цветом как часть описания “what is happening”.
Затем следует проследовать по таблице вниз, чтобы найти отредактированную строку в обоих отчётах и определить, повлияли ли внесённые изменения на частоту её срабатывания.


В рассматриваемом случае наблюдается значительное снижение количества выполнений данной строки - почти в два раза по сравнению с исходным вариантом на протяжении всего боя. Это привело к перераспределению части нагрузки на другие строки, однако общий эффект оказался отрицательным, что выразилось в снижении эффективности симуляции по показателю DPS.
Как правило, на данном этапе можно заключить, что полученной информации достаточно, и принять решение о необходимости вынесения данного условия в отдельную строку, корректировки условий для повышения гибкости или полном исключении его из ротации. Однако в рамках демонстрации следует предположить, что текущих данных недостаточно для окончательного вывода.
Следующим шагом в анализе является переход к разделу отчёта с журналом событий (sample log) и изучение отдельных случаев выполнения строки. Это позволяет более детально понять, при каких условиях она функционирует некорректно, и оценить характер возникающих отклонений.

В данном случае период продолжительностью десять секунд, когда способность Ледяной столп оставалась активной без покрытия со стороны Смерть и разложение, уже сам по себе демонстрирует неблагоприятную картину, даже если частота выполнения строки не позволяла сделать этот вывод ранее. Однако, в целях демонстрации, будем исходить из предположения, что требуется дополнительное исследование.
На следующем этапе следует вернуться к верхней части отчёта и рассмотреть возможные подходы к дальнейшему анализу. Первым и наиболее очевидным является анализ графиков, которые позволяют оперативно выявить расхождения и отклонения.


На данном этапе целесообразно зафиксировать несколько ключевых наблюдений. Во‑первых, изменение строки приводит к перераспределению времени применения способностей: увеличивается доля времени, затрачиваемого на использование способности Уничтожение, при этом время применения Смерть и разложение снижается не в полной мере компенсируя изменения. Подобная диспропорция указывает на каскадное воздействие на ротацию в целом. Также фиксируется увеличение простоев, снижение частоты использования Воющий ветер и рост доли времени на Ледяной удар.
Такая динамика свидетельствует о нарушении баланса потребления ресурсов, возникающем при исключении Смерть и разложение из ротации. Данное обстоятельство может указывать на необходимость дальнейшего анализа структуры APL, однако в рамках текущего рассмотрения внимание смещается на другие аспекты.
Следующим шагом является изучение распределения источников наносимого урона.


Следует отметить недостаток визуализации: при слишком малой доле значений некоторые сегменты круговой диаграммы могут скрываться, причём критерий их отображения определяется непоследовательно. Например, в исходной версии профиля доля Ледяной удар составляет 5,8 %, что больше, чем доля Метка жнеца в изменённой версии профиля, однако визуализация показывает только последний сегмент.
Тем не менее, общее представление о распределении урона можно получить, даже если приходится наводить курсор на сегменты диаграммы для уточнения значений. Фиксируется значительное снижение доли урона от Уничтожение, что изменяет общую структуру профиля урона. Перераспределение затрагивает и другие способности, включая Ледяной удар, что дополнительно подтверждает наличие структурных проблем, требующих дальнейшего изучения.
Для более детального анализа целесообразно перейти ко второму направлению исследования.
(текущий набор приоритетов действий — current APL)

(условие связанное с талантом Bonegrinder)
Срабатывания, время активности и эффективность
Данный инструмент является весьма полезным, поскольку позволяет избежать необходимости детального анализа всех активных баффов.
Он дает ясное представление о ключевых срабатываниях (procs) и о том, что происходило в ходе симуляции.
На основе полученных данных можно сделать ряд выводов. В частности, условие Костолом фактически активировало больше срабатываний Машина для убийств, вероятно, за счёт меньшего использования Смерть и разложение и, как следствие, наличия большего количества доступных рун. Также фиксируется, что условие Костолом приводит к несколько большему расходу силы рун, что ранее уже предполагалось.
Тем не менее, несмотря на то что данный инструмент позволяет получить отдельные полезные сведения, он не даёт полной картины происходящего. Поэтому целесообразно перейти к дальнейшему этапу анализа.
На следующем этапе необходимо более детально погрузиться в структуру отчёта.


На данном этапе целесообразно воспользоваться электронными таблицами для корректного сравнения данных между профилями. В этом разделе отчёта представлено покадровое распределение урона по каждой способности. Здесь можно непосредственно вычесть урон от способности Уничтожение из обоих профилей и сравнить суммарный DPS, чтобы убедиться, что значения практически совпадают. Это позволяет сделать вывод о том, что наблюдаемое снижение эффективности, вероятно, связано исключительно с некорректностью самой строки.
Тем не менее, в целях продолжения исследования можно перейти к анализу способности Смерть и разложение.


При анализе статистического распределения урона можно отметить, что условие Костолом существенно смещает вклад способности Смерть и разложение, нарушая характерный для исходной строки более плавный профиль возрастания и спадания урона. Также фиксируется, что сама способность была применена на 0,67 раза меньше за симуляцию, что, с округлением, соответствует примерно одной утраченной активации за симуляцию, при этом общая картина подтверждает данные наблюдения.
Далее целесообразно перейти к анализу распределения ресурсов.

Необходимо оценить наличие нетипичных перерасходов ресурсов и изменения в их структуре. Однако на данном этапе следует критически оценить целесообразность столь глубокого анализа данной строки с точки зрения её влияния на общую эффективность.
Дополнительно можно проанализировать раздел отчёта, содержащий сведения о баффах.


На завершающем этапе анализа следует отметить, что значительная часть информации, представленной в данном разделе отчёта, дублирует ранее рассмотренные данные, однако в иной форме. Здесь, в частности, отражены сведения об обновлениях эффектов, количестве применений способностей и продолжительности их действия. Эти данные могут быть полезны для окончательной верификации выводов.
Таким образом, изложенный алгоритм анализа позволяет системно оценить влияние отдельных изменений APL на общую эффективность ротации и выявить возможные структурные несоответствия. Последовательное применение данного подхода способствует повышению качества принимаемых решений при оптимизации приоритетов действий.

На следующем этапе следует открыть HTML‑отчёт симуляции. Для обеспечения корректности анализа рекомендуется открыть отдельный отчёт для каждого исследуемого варианта APL, так как одновременное сравнение нескольких изменений в одном отчёте может затруднить интерпретацию результатов.

После этого необходимо открыть оба профиля, участвующих в сравнении, чтобы провести детальный анализ различий в их поведении.

В результате открывается детализированная таблица отчёта, объём которой значительно превышает пределы одного экрана и включает множество вспомогательных элементов, не имеющих непосредственного отношения к рассматриваемому вопросу.
Данные элементы на данном этапе рекомендуется оставить без внимания, поскольку первоочередной анализ следует начинать с информации, расположенной в нижней части отчёта.

Откройте раздел отчёта, содержащий список приоритетов действий (Action Priority List), для последующего анализа.

Данный раздел содержит два полезных источника информации - первый представляет собой детализированное поштучное распределение всех строк APL, сработавших в ходе симуляции, а второй - пример журнала событий (sample log), отражающий последовательность выполнения действий.

Это позволяет получить как макроуровневое, так и микроуровневое представление о происходивших в ходе симуляции событиях, каждое из которых полезно для анализа в своей области.
В первую очередь рассматривается макроуровневый анализ журнала событий.

Далее необходимо перейти к разделу отчёта, содержащему список строк APL, и найти ту строку, которая подвергалась редактированию. Если возникает затруднение с её идентификацией, следует ориентироваться на её начальную часть, которая ранее в данном руководстве выделялась зелёным цветом как часть описания “what is happening”.
Затем следует проследовать по таблице вниз, чтобы найти отредактированную строку в обоих отчётах и определить, повлияли ли внесённые изменения на частоту её срабатывания.


В рассматриваемом случае наблюдается значительное снижение количества выполнений данной строки - почти в два раза по сравнению с исходным вариантом на протяжении всего боя. Это привело к перераспределению части нагрузки на другие строки, однако общий эффект оказался отрицательным, что выразилось в снижении эффективности симуляции по показателю DPS.
Как правило, на данном этапе можно заключить, что полученной информации достаточно, и принять решение о необходимости вынесения данного условия в отдельную строку, корректировки условий для повышения гибкости или полном исключении его из ротации. Однако в рамках демонстрации следует предположить, что текущих данных недостаточно для окончательного вывода.
Следующим шагом в анализе является переход к разделу отчёта с журналом событий (sample log) и изучение отдельных случаев выполнения строки. Это позволяет более детально понять, при каких условиях она функционирует некорректно, и оценить характер возникающих отклонений.

В данном случае период продолжительностью десять секунд, когда способность Ледяной столп оставалась активной без покрытия со стороны Смерть и разложение, уже сам по себе демонстрирует неблагоприятную картину, даже если частота выполнения строки не позволяла сделать этот вывод ранее. Однако, в целях демонстрации, будем исходить из предположения, что требуется дополнительное исследование.
На следующем этапе следует вернуться к верхней части отчёта и рассмотреть возможные подходы к дальнейшему анализу. Первым и наиболее очевидным является анализ графиков, которые позволяют оперативно выявить расхождения и отклонения.


На данном этапе целесообразно зафиксировать несколько ключевых наблюдений. Во‑первых, изменение строки приводит к перераспределению времени применения способностей: увеличивается доля времени, затрачиваемого на использование способности Уничтожение, при этом время применения Смерть и разложение снижается не в полной мере компенсируя изменения. Подобная диспропорция указывает на каскадное воздействие на ротацию в целом. Также фиксируется увеличение простоев, снижение частоты использования Воющий ветер и рост доли времени на Ледяной удар.
Такая динамика свидетельствует о нарушении баланса потребления ресурсов, возникающем при исключении Смерть и разложение из ротации. Данное обстоятельство может указывать на необходимость дальнейшего анализа структуры APL, однако в рамках текущего рассмотрения внимание смещается на другие аспекты.
Следующим шагом является изучение распределения источников наносимого урона.


Следует отметить недостаток визуализации: при слишком малой доле значений некоторые сегменты круговой диаграммы могут скрываться, причём критерий их отображения определяется непоследовательно. Например, в исходной версии профиля доля Ледяной удар составляет 5,8 %, что больше, чем доля Метка жнеца в изменённой версии профиля, однако визуализация показывает только последний сегмент.
Тем не менее, общее представление о распределении урона можно получить, даже если приходится наводить курсор на сегменты диаграммы для уточнения значений. Фиксируется значительное снижение доли урона от Уничтожение, что изменяет общую структуру профиля урона. Перераспределение затрагивает и другие способности, включая Ледяной удар, что дополнительно подтверждает наличие структурных проблем, требующих дальнейшего изучения.
Для более детального анализа целесообразно перейти ко второму направлению исследования.
(текущий набор приоритетов действий — current APL)

(условие связанное с талантом Bonegrinder)

Данный инструмент является весьма полезным, поскольку позволяет избежать необходимости детального анализа всех активных баффов.
Он дает ясное представление о ключевых срабатываниях (procs) и о том, что происходило в ходе симуляции.
На основе полученных данных можно сделать ряд выводов. В частности, условие Костолом фактически активировало больше срабатываний Машина для убийств, вероятно, за счёт меньшего использования Смерть и разложение и, как следствие, наличия большего количества доступных рун. Также фиксируется, что условие Костолом приводит к несколько большему расходу силы рун, что ранее уже предполагалось.
Тем не менее, несмотря на то что данный инструмент позволяет получить отдельные полезные сведения, он не даёт полной картины происходящего. Поэтому целесообразно перейти к дальнейшему этапу анализа.
На следующем этапе необходимо более детально погрузиться в структуру отчёта.


На данном этапе целесообразно воспользоваться электронными таблицами для корректного сравнения данных между профилями. В этом разделе отчёта представлено покадровое распределение урона по каждой способности. Здесь можно непосредственно вычесть урон от способности Уничтожение из обоих профилей и сравнить суммарный DPS, чтобы убедиться, что значения практически совпадают. Это позволяет сделать вывод о том, что наблюдаемое снижение эффективности, вероятно, связано исключительно с некорректностью самой строки.
Тем не менее, в целях продолжения исследования можно перейти к анализу способности Смерть и разложение.


При анализе статистического распределения урона можно отметить, что условие Костолом существенно смещает вклад способности Смерть и разложение, нарушая характерный для исходной строки более плавный профиль возрастания и спадания урона. Также фиксируется, что сама способность была применена на 0,67 раза меньше за симуляцию, что, с округлением, соответствует примерно одной утраченной активации за симуляцию, при этом общая картина подтверждает данные наблюдения.
Далее целесообразно перейти к анализу распределения ресурсов.

Необходимо оценить наличие нетипичных перерасходов ресурсов и изменения в их структуре. Однако на данном этапе следует критически оценить целесообразность столь глубокого анализа данной строки с точки зрения её влияния на общую эффективность.
Дополнительно можно проанализировать раздел отчёта, содержащий сведения о баффах.


На завершающем этапе анализа следует отметить, что значительная часть информации, представленной в данном разделе отчёта, дублирует ранее рассмотренные данные, однако в иной форме. Здесь, в частности, отражены сведения об обновлениях эффектов, количестве применений способностей и продолжительности их действия. Эти данные могут быть полезны для окончательной верификации выводов.
Таким образом, изложенный алгоритм анализа позволяет системно оценить влияние отдельных изменений APL на общую эффективность ротации и выявить возможные структурные несоответствия. Последовательное применение данного подхода способствует повышению качества принимаемых решений при оптимизации приоритетов действий.