Warcraft Logs
Analyzing
Guide
Analyzing
Guide
Сейчас, сайт warcraftlogs является неотъемлемым атрибутом каждого ответственного рейдера, а базовые навыки работы с ним должен иметь каждый рейдовый коллектив.
Данная часть статьи является адаптацией поста из англоязычного дискорд-сервера Acherus. Некоторые общие моменты могут пригодиться и для прочих классов-спеков, но в целом приоритетом является фдк. (тут довольно объёмные картинки, так что порой нужно пролистать ещё чуть-чуть.)
Первым и самым важным шагом при просмотре логов является настройка. Пролистывание вкладок, сравнивая происходящее на одной с происходящим на другой – верный шаг к разочарованию.
Тут всё проще. Для билда с Синдрагосой вам нужны Руны (Rune) и Сила рун (RP). Для шаттера нужны только Руны.
Для этого нужно нажать на эти плюсики, которые добавят график в верхнюю часть вашего лога.
Что нужно отслеживать для билда с синдрой и шаттера?
Для билда с Дыханием синдрагосы:
Иней (Rime), Машина для убийств (Killing machine), Дыхание Синдрагосы (Breath of Sindragosa), Ледяной столп (Pillar of frost) и Предвестие бури (Gathering storm).
Для шаттера:
Машина для убийств (Killing machine), Иней (Rime), Высвобожденное бешенство (Unleashed frenzy), Ледяной столп (Pillar of frost), Нечестивая сила (Unholy strength).
Далее для лучшего понимания мы переключимся на врагов. Переходим к разделу лога и меняем «Друзей» на «Врагов»
Затем переходим на вкладку дебаффов и переключаемся со всех источников (под сводкой) на Рыцаря смерти, которого мы рассматриваем.
То, что мы хотим здесь получить, снова зависит от билда, но по несколько иной оси, чем раньше.
Все билды могут взять Вечный мороз (Everfrost).
Билдам с Вестником смерти (Deathbringer) стоит взять Метку жнеца (Reaper's Mark) и Озноб (Frost Fever).
Билды с шаттером должны дополнительно рассмотреть возможность взять Режущий лёд (Razorice Stacks).
В итоге мы получим что-то вроде этого:
Тут есть несколько штучек, которые стоит проверить:
Нажмите на эту маленькую шестеренку и снимите выделение героизма (бла, геры), чтобы не переписать то, что мы собираемся делать дальше в опенере.
Далее, для этих двух, в частности, вы должны нажимать на синие буквы рядом с Graph:, пока не появится надпись
Это выделит те части боя, в которых были использованы кулдауны.
Далее мы выбираем период боя, который хотим просмотреть. Пытаться просмотреть весь журнал за один раз - бессмысленно. Т.к. много лишнего.
Вместо этого нужно перетащить на основной график, чтобы выбрать меньший период боя, где вам будет легче разобрать информацию.
Так гораздо удобнее читать. Теперь просто выберите все нужные касты (в общем случае вы можете исключить такие вещи, как воскрешение или защитные кулдауны)
Теперь мы переходим к разделу, в котором вы рассматриваете лог, и здесь все довольно просто.
Первое, что вы хотите сделать, — это посмотреть опенер. Правильно ли они начали, если неправильно, то дайте им люлей покажите им нормальный опенер и скажите, чтобы они исправились.
Следующее – это то, как они отыгрывают свои кулдауны, что лучше всего разделить на две части:
Дыхание синдрагосы — это достаточно простой процесс: вы нажимаете Уничтожение для генерации RP и продолжаете, пока у вас не закончатся руны. Но есть некоторые нюансы, на которые стоит обратить внимание.
1. Иней — это важная способность для дыхания, но при этом она также может быть опасной. Иней делает Воющий ветер бесплатным, что означает, что он не генерирует RP. Это делает его полезным во время активации дыхания, так как он обновляет Озноб, наносит урон, даёт КМ и имеет 30% шанс вернуть руну.
Однако ближе к концу дыхания, когда у вас больше нет скорости я от Усиления рунического оружия и большого запаса RP, использование этой способности становится опасным. Большинство дыханий прерываются не из-за нехватки ресурсов, а из-за нехватки ГКД (времени глобального восстановления). Поэтому тратить ГКД исключительно на урон — рискованно. При анализе логов обратите внимание, как используется Воющий ветер: используют ли его агрессивно в начале или блокируют ГКД в конце дыхания, что приводит к его преждевременному завершению.
2. Беспощадность зимы — очень мощная способность, с одним из самых высоких показателей урона за затраченную энергию, среди всех способностей ФДК. Она очень эффективна, и одним из показателей хорошего использования дыхания является продление эффекта Предвестия бури. Достижение этого рубежа обычно происходит за счет внешних факторов, таких как удача, использование АМС, или баффы вроде PI (пиай) / BL (бл, то бишь гера.)
Обращайте внимание на то, продлили ли они Бурю. Если нет — они слишком экономят руны или не используют Беспощадность зимы, когда она доступна, — это стоит отметить.
3. Уничтожение — это основной механизм работы Дыхания Синдрагосы, и 90% RP для дыхания генерируется с ее помощью.
Однако часто встречается ошибка, когда игроки переполняют запас RP во время дыхания. С активными эффектами Ускорения (бл/пиай) и ЕРВ, дыхание потребляет 17 RP за тик, и легко растратить лишнюю RP, что нежелательно. Единственная ситуация, когда можно переполнить запас RP, — это наличие прока КМа (Машина для убийств), который нужно использовать немедленно.
4. Способности, расходующие RP: Важно убедиться, что во время дыхания не используются способности, расходующие RP.
5. Способности, генерирующие Рунную Силу: Речь идет о ЕРВ и Горне. Важно использовать их активно. В большинстве случаев ЕРВ используется вместе с дыханием, а Горн — в момент, когда нельзя использовать Уничтожение и не возникает риска перекапа RP. Дыхание — это «взрывной» кулдаун, который сочетается с триньками и проками, поэтому ресурсы во время этих моментов крайне важны.
6. Моменты отчаяния. Использование способностей Смерть и разложение (Оно же днд) и Воющего ветра в конце дыхания. В целом это незначительное увеличение урона, кроме ситуаций с АоЕ. Расход днд для дополнительного тика дыхания является приемлемым в СТ, но в AoE ограниченное количество зарядов днд может привести к потере урона.
Если вы анализируете лог для М+ и видите, что это привело к использованию пиллара без днд, стоит это отметить.
7. Использование днд — это важно для АоЕ, хотя основной механизм урона дыхания в АоЕ — само дыхание. При достаточном количестве уничтожений, использование днд существенно увеличивает урон
Концепция истребления довольно проста. Жмёшь на кнопку, она дамажит. Но с добавлением героической ветки талантов Вестник смерти и апофеоза данной ветки Метки жнеца, всё несколько усложняется, т.к. накопление и менеджмент ресурсов для пиллара становится крайне важной задачей, и начальной фазе пиллара стоит уделить большое внимание.
1. Начальная фаза. Важно, с какого момента начинается использование пиллара, т.к. неправильно выбранный момент ГКД может нарушить баланс ресурсов. Т.е. есть риск потерять ГКД.
Для начала столпа приоритет следующий:
- Воющий ветер, если на цели нет Озноба;
- КМ, если у вас есть прок оного;
- Воющий ветер, если у вас есть прок Инея, а также более двух рун;
- Ледяной удар, если ничего из вышеупомянутого нет
В случае АоЕ, если Воющий ветер уже использован, а также есть два стака КМа, то можно начинать пиллар с днд.
Если при анализе логов вы видите, что кто-то ошибается, то скажите ему, что он неправ.
2. Подготовка к пиллару. Важно не только то, как начинается фаза пиллара, но и как к ней готовятся. Перед прожатием пиллара, оцените, есть ли у игрока 3-4 руны и 30 RP для Метки жнеца и самого пиллара. Это нужно, чтобы как минимум одна руна для Уничтожения была доступна, как и RP для двух Ледяных ударов.
При более углублённом анализе посмотрите, теряет ли при подготовке к фазе пиллара баффы Ледяных когтей, Костомола и Высвобождённого бешенства. Если теряет, то скажите, что поддержание этих баффов важнее накопления ресурсов.
3. Генерация КМов. Каждая атака, что не является Уничтожением, внутри пиллара (с взятым талантом) вызывает КМ. Следует помнить порядок приоритетов:Смена приоритетов между Воющим ветром под Инеем и Ледяным ударом более важна, чем в предыдущих итерациях с Истреблением, т.к. Метка жнеца означает, что вы всегда будете сталкиваться с ситуациями, когда у вас будет бафф Инея и менее двух рун в каждом пилларе. При просмотре лога важно обратить внимание на то, почему произошла смена приоритетов. Ледяной удар имеет 74% шанс получить руну и 18% шанс получить две. 60% – от обычной регенерации рун при расходовании RP, и 30% от таланта Истребление. В отличие от Воющего ветра (и всех триггеров КМов, не связанных с РП), у которых шанс получить руну составляет всего 30%.
- Воющий ветер, если нет Озноба;
- Жнец душ (в экзекутке) при наличии трёх и более рун;
- Воющий ветер под баффом Инея, если в наличии более двух рун и нет проков КМа.
- Ледяной удар, если ничего из этого не подходит.
- Воющий ветер, если нет RP.
Проще говоря, прожимая Воющий ветер без достаточного количества рун, чтобы использовать КМ, вы в 70% случаев рискуете остаться в дураках, в то время как Ледяной удар оставляет вас сухим и невредимым лишь в 26% случаев.
4. Избыток проков КМов. Хотя это менее важно из-за строгого контроля ресурсов, в будущем оно снова станет актуальным. При анализе лога следите за тем, не активирует ли игрок два стака КМа вручную, т.к. это потеря урона.
5. Используйте кнопки как можно чаще. Во время действия пиллара, вы должны прожимать ротацию как можно активнее. Передохнуть можно во время окон.
6. Примечание для СТ и АоЕ боёв: В СТ не используйте Беспощадность зимы во время пиллара. В АоЕ убедитесь, что грамотно используете днд во время пиллара.
Что такое выражения? Выражения создаются с использованием языка выражений WCL (Warcraft logs) и предназначены для экспертов и программистов, которым нужно строить сложные запросы, которые не могут быть обработаны через пользовательский интерфейс поиска.
Но этими данными можно делиться с другими пользователями, так что необязательно быть программистом или экспертом.
Выражения являются способом анализа каждого (записанного) боя, который разбивается на серию определённых событий.
Урон – Исцеление – Положительный / отрицательныйэффект – Касты и т.д.
У этих событий есть три общих компонента: Источник, способность (любого типа) и цель:
Пример: Брексиен применяет Банхаммер на Квереста.
Брексиен – источник события, Банхаммер – способность, Кверест – цель.
(p.s. все совпадения с именами и никами случайны)
Вы, как игрок, можете быть как источником, так и целью события:
Пример: Брексиен получает эффект аксессуара от Брексиена.
Брексиен является и источником и целью. Способность — эффект от аксессуара.
Выражения — это запросы, которые фильтруют все эти события, чтобы получить нужную информацию. Т.е. определённую конкретику по определённому игроку / группе игроков / боссу и т.д. Запрос строится с использованием различных логических операторов и строк для фильтрации данных.
Каждый отчёт лога имеет поле для ввода фильтрационного выражения. Именно сюда нужно вставлять Ваши запросы, если вы пишете их с нуля или воруете берёте у других пользователей.
Warcraft logs использует язык, похожий на SQL (язык программирования, предназначенный для создания, обработки и хранения данных в реляционных бд.) При создании выражения можно использовать различные операторы, такие как те, что перечислены ниже.
Логический оператор — это символ или слово, используемое для соединения двух или более выражений. Для соединения нескольких условий можно использовать ключевые слова логических операторов AND (И), OR (ИЛИ) или NOT (НЕ/Т).
(фактически тут я бы предпочёл использовать стандартное true и false, так что будем учитывать, что тут истина и ложь это соответственно true и false.)
- “A AND B” – означает, что оба условия А и В должны быть истинными.
- “А OR В” – означает, что либо А, либо В могут быть истинными.
- “NOT A” – выражение истинно, если А ложно.
Операторы AND и OR используют вычисления по короткой схеме. Т.е. для А AND B, если А ложно, то В не будет оцениваться вовсе, поэтому выстраивайте свои запросы соответствующим образом.
Операторы сравнения используются для сравнения. Поддерживаются следующие операторы:
<, >, <=, >=, =, !=
- < — означает “меньше чем…” данный оператор фильтрует все данные, которые не соответствуют. Возвращает True, если значение слева меньше значения справа, иначе False.
- > — означает “больше чем…” возвращает True, если значение слева больше значения справа, иначе False.
- <= — означает “меньше или равно” возвращает True, если значение слева меньше или равно значению справа, иначе…
- >= —означает “больше или равно” возвращает True, если значение больше или равно значению справа, иначе False!
- = — означает “равно” возвращает True, если значение слева равно значению справа, иначе ну вы поняли.
- != — означает “не равно”, возвращает True, если значение слова не равно значению справа, иначе оно самое.
Вдогонку, конструкция BETWEEN (между) может использоваться для проверки, находится ли число или строка между двумя другими значениями (включая их).
Пример: А BETWEEN 5 AND 20 истинно, если А >= 5 и А <= 20.
Поддерживаются следующие арифметические операторы: +, -, *, /, %
- + это сложение
- - это вычитание
- * это умножение
- / это деление
- % это остаток от деления (Mod)
Вы можете проверить, является ли объект элементом множества (или не является) с помощью ключевых слов IN и NOT IN.
Пример: A in ("The Nine", "Painsmith Raznal", "Kel'Thuzad")
True, если А равен одной из этих трёх строк.
Вы можете использовать операторы case. Их синтаксис совпадает с синтаксисом SQL, т. е. вы можете использовать как простой, так и полный оператор case.
Пример: CASE WHEN source.name = "Foo" THEN a WHEN effectiveDamage > 1000 THEN b ELSE c END
В приведенном выше полном выражении case условия задаются с помощью оператора WHEN. Если условие истинно (идём по порядку), то возвращается выражение, находящееся в блоке WHEN. Оператор ELSE содержит значение по умолчанию, которое возвращается, если ни одно из условий WHEN не выполняется.
Простой оператор case задает значение case, которое затем можно сравнить со значениями when. Это полезно, когда вы постоянно проверяете равенство.
Пример: CASE source.name WHEN "Foo" THEN a WHEN "Goo" THEN b ELSE c END
Все числа являются целыми числами. Числа с плавающей запятой или десятичные числа не допускаются.
Справка: Число с плавающей запятой — это способ записи чисел, позволяющий использовать очень большие и очень маленькие значения за счёт «плавающей» позиции запятой. Например, число 123,000,000 можно записать как 1.23×1081.23×108, а 0.0000123 — как 1.23×10−51.23×10−5.
Строки могут быть обозначены как одинарными, так и двойными кавычками, то есть "Kihra" и 'Kihra' — это обе допустимые строки. Все строковые сравнения нечувствительны к регистру, поэтому "Kihra" и "KIHRA" считаются эквивалентными.
Некоторые поля событий являются простыми идентификаторами, например, type.
У определённых полей есть подполя. Доступ к ним осуществляется с помощью нотации ".".
Пример: Вы можете запросить имя источника действия в событии, указав: source.name = "A"
Функции выглядят как объекты, но с аргументами, заключёнными в круглые скобки и разделёнными запятыми. Специфические функции ниже документируют количество принимаемых аргументов и их формат.
Каждое выражение оценивается на всех событиях в пределах указанного временного диапазона. Поддерживаются следующие встроенные идентификаторы:
encounterID — можно использовать для фильтрации конкретного боя или его исключения. Например, если вы хотите посмотреть всё прохождение рейда, за исключением одного боя, вы можете использовать encounterID, чтобы исключить этот бой из обзора. Для сражений с трешем значение равно 0.
Пример: encounterID != 730
730 — это encounterID для Ал’ара (Пепел Ал’ара, все дела). Записав это в выражении фильтра, вы исключите бой с ним.
Справка: Вы можете найти encounterID на странице DungeonEncounterID на Wowpedia или вверху представления Summary/Events в отчёте, как показано на изображении ниже.
encounterSize — Размер рейда. Например, рейд на 10 человек или на 25 человек и т. д.
encounterDifficulty— Сложность боя. 1 = LFR, 2 = Flex, 3 = Normal, 4 = Heroic, 5 = Mythic, 10 = Подземелье (Mythic+, CMs, FFXIV), 100 = рейды FF/WildStar.
encounterEnd— Результат завершения боя. Возможные значения: "wipe" (поражение) и "kill" (победа).
encounterDuration— Длительность боя в миллисекундах.
encounterBossHealthPercentage— Процент здоровья босса в конце боя. Число в диапазоне от 0 до 100.
encounterFightPercentage— Продолжительность боя по процентам (соответствует цветным полосам, которые отображаются при просмотре поражений). Число от 0 до 100.
encounterPhase— Фаза, к которой относится событие. Нумерация фаз начинается с 1. Если у боя нет фаз, значение будет 0.
encounterStartTime— Время начала боя относительно начала отчета.
encounterEndTime— Время окончания боя относительно начала отчета.
timestamp— Временная метка события в миллисекундах относительно начала боя.
type— Тип события. Warcraft Logs поддерживает следующие типы событий:
begincast, cast, miss, damage, heal, absorbed, healabsorbed, applybuff, applydebuff, applybuffstack, applydebuffstack, refreshbuff, refreshdebuff, removebuff, removedebuff, removebuffstack, removedebuffstack, summon, create, death, destroy, extraattacks, aurabroken, dispel, interrupt, steal, leech, resourcechange, drain, resurrect, encounterstart, encounterend, dungeonstart, dungeonend, dungeonencounterstart, dungeonencounterend, towerstart, towerend, mapchange, zonechange, worldmarkerplaced, worldmarkerremoved, taunt, modifythreat, calculateddamage, calculatedheal
ВНИМАНИЕ: Warcraft Logs не считает полное поглощение ударом промахом. Оно будет представлено как событие урона.
inCategory — Функция inCategory может использоваться для работы с умной категоризацией WCL. Например, если вы хотите посмотреть события лечения и автоматически включить поглощение урона, можно использовать inCategory("healing") = true вместо type = "heal"
rawDamage — Необработанный урон для события урона. Включает поглощения и превышение урона.
effectiveDamage — Эффективный урон для события урона. Исключает поглощения и превышение урона и отражает, сколько урона на самом деле получил актор.
absorbedDamage — Количество поглощенного урона для события урона.
blocked — Количество заблокированного урона для события урона.
overkill — Превышение урона для события урона.
rawHealing — Необработанное лечение для событий лечения/поглощения. Включает поглощения и превышение лечения.
effectiveHealing — Эффективное лечение для событий лечения/поглощения. Исключает превышение лечения, но включает поглощенное лечение (например, Завеса Тьмы на Сильване Ветрокрылой).
absorbedHealing — Количество поглощенного лечения для события лечения. Для не-поглощающих способностей это отражает количество поглощенного лечения (например, Завеса Тьмы на Сильване Ветрокрылой), а для поглощающих способностей эквивалентно effectiveHealing.
isCritical — True или False — проверяет, является ли событие урона или лечения критическим.
isTick — True или False — проверяет, является ли событие урона или лечения периодическим, то есть DoT или HoT.
isUnpairedCalculation — True или False — проверяет, был ли "призрачный" эффект способности. Покажет "true", если событие приготовления было "призрачным".
isMultistrike — True или False — проверяет, было ли событие урона или лечения мультиударом.
missType — Для промаха указывает, что произошло. Возможные значения: miss, dodge, parry, immune, deflect, reflect, misfire, evade, resist.
stack — Количество стаков для событий баффов и дебаффов.
extraAttacks — Количество дополнительных атак для события дополнительных атак.
source — Источник события. Возвращается специальный актор "Environment" (Окружающая среда), если источник не существует.
target — Цель события. Возвращается специальный актор "Environment" (Окружающая среда), если цель не существует.
ability — Основная способность для события.
supportedActor — Позволяет вернуться к оригинальному забафанному игроку для случаев, связанных с эвокером-аугом. (Augmentaion evoker)
stoppedAbility — Для снятий, прерываний и рассеиваний представляет собой заклинание, которое было рассеяно или прервано.
resources — Возвращает объект ресурсов, который можно использовать для получения информации, такой как количество здоровья, магическая сила, координаты на карте и т. д.
feign — True или False — возвращает true, если событие смерти на самом деле является ложной смертью охотника.
killer — Соответствует событиям смерти, если смертельный удар, вызвавший смерть, был нанесен выбранным актёром.
killingAbility — Соответствует событиям смерти, если смертельный удар был нанесен этой способностью.
absorbedAttacker — Соответствует событиям поглощения, если атакующий, чей удар был поглощен, является выбранным актёром.
absorbedAttackerAbility — Соответствует событиям поглощения, если атака, которая была поглощена, пришла от данной способности.
absorbedHealer — Соответствует событиям поглощенного лечения, если целитель, чье лечение было поглощено, является данным актером.
absorbedHealerAbility — Соответствует событиям поглощенного лечения, если лечение, которое было поглощено, пришло от данной способности.
name — Имя исполнителя. Например, можно указать source.name или target.name.
id — ID исполнителя. Для NPC соответствует ID в URL на Wowhead.
instance — Какая именно копия исполнителя рассматривается. Для игроков это всегда 1. Для NPC — это конкретный экземпляр моба.
instanceGroup — К какой группе относится актер. Для игроков и непринадлежащих группе NPC это 0. Например, для второй волны аддов в бою это будет группа 2.
type — Тип моба. В WCL есть три типа мобов: игрок, NPC и питомец.
class — Класс игрока, например, чернокнижник или рыцарь смерти. Для NPC возвращает boss для боссов и NPC для обычных мобов. Питомцы возвращают pet.
spec — Специализация игрока, например, разрушение или оружие.
role — Роль игрока. Возможные значения: танк, ближний бой, дальний бой и лекарь. Для NPC возвращается значение поля class.
disposition — Определяет, дружественный или враждебный моб. Данный статус фиксирован и указывает, был ли юнит дружественным или враждебным большую часть боя.
rawDisposition — Определяет статус на момент конкретного события. Если игрок находится под контролем разума, он становится врагом по этому полю.
marker — Номер метки рейда, установленной на данном актере. Равно 0, если метка не установлена.
owner — Владелец питомца. Если актер не имеет владельца или не является питомцем, владелец считается самим актером.
firstSeen — Временная метка, когда данный актер (и экземпляр!) впервые появился.
lastSeen — Временная метка, когда данный актер (и экземпляр!) последний раз был замечен.
name — Имя способности. Например, можно указать ability.name.
id — ID способности. Соответствует ID в URL на Wowhead.
actor — Исполнитель, к которому привязаны ресурсы события. Может быть источником, целью или null, если ресурсов нет. (Оно же действующее лицо.)
hitPoints — Текущее количество здоровья
maxHitPoints — Максимальное количество здоровья
hpPercent — Эквивалент hitPoints / maxHitPoints.
attackPower — Сила атаки
spellPower — Сила заклинаний.
x — Позиция X в игре для актера ресурса. Хранится в WCL как оригинальная позиция, умноженная на 100. Например, X-позиция 32.56 представлена как 3256.y — Позиция Y в игре для актера ресурса, также умножена на 100.
С помощью проверки диапазона можно определить произвольные границы диапазона и проверять, находится ли событие внутри него или нет.
Пример: IN RANGE FROM type = "applybuff" AND ability.name = "Swarm of Darkness" TO type = "removebuff" AND ability.name = "Swarm of Darkness" END
Этот пример выражения показывает диапазоны, когда "Swarm of Darkness" активен на Lords of Dread. Это позволяет проверять лечение, произведенное во время действия "Swarm of Darkness".
WHEN — это начальное условие, которое должно быть выполнено перед проверкой границ диапазона. Условия IN RANGE не могут быть вложенными, поэтому это позволяет вам задавать условия, если это необходимо.
FROM — это условие, при совпадении с которым начинается новый диапазон. Если FROM опущено, началом диапазона будет начало боя.
TO (ту) — это условие, при совпадении с которым диапазон заканчивается. Если TO опущено, концом диапазона будет конец боя.
GROUP BY связывает FROM и TO вместе. Например, для положительных и отрицательных эффектов (баффов и дебаффов) обычно выполняется связывание по цели обоих событий. Если необходимо связать источник события в FROM с целью в TO, это можно сделать, добавив AND, чтобы указать другое условие для TO.
ON позволяет дополнительно фильтровать события, требуя, чтобы выражение в ON для тестируемого события совпадало с GROUP BY для границ FROM/TO. Если ON опущено, используется выражение из GROUP BY.
MATCHED condition IN tuple expression END
С помощью выражения MATCHED можно проверить, сколько раз произошло событие, например, второй раз, когда игрок получает определённый дебафф.
Первая часть — это условие, для которого вы хотите подсчитать совпадения, а вторая часть — это кортеж индексов (начиная с 1), соответствующих нужным совпадениям.
MATCHED type = "applydebuff" and ability.name = "Dark Herald" IN (1,3) END
В приведённом примере будут совпадать события для первого и третьего дебаффов "Dark Herald", которые появляются во время боя.
Хотите улучшить свою игру? В этой части статьи мы рассмотрим несколько примеров, которые помогут вам создавать и использовать свои собственные фильтрационные выражения.
Временные метки: Время указывается в миллисекундах, поэтому если вы, например, хотите посмотреть первые 30 секунд боя, то это 30000 миллисекунд.
Пример: timestamp < 30000
Используйте <, >, >=, <=, чтобы указать, на какую часть боя вы хотите взглянуть. Также можно посмотреть определенный временной интервал, объединив два выражения временных меток.
Пример: timestamp > 30000 AND timestamp < 60000 (Пример лога)
Здесь рассматривается временной отрезок с 30-х по 60-е секунды боя. Вы также можете просмотреть несколько отрезков в отчете, чтобы просмотреть только этот конкретный отрезок времени (как показано в примере).
В запросе вы можете объединить несколько исцеляющих способностей.
Пример: ability.name IN ("Aura Mastery", "Divine Hymn", "Holy Word: Salvation", "Power Word: Barrier", "Healing Tide Totem", "Spirit Link Totem", "Ancestral Protection Totem", "Revival", "Restoral", "Invoke Yu'lon, the Jade Serpent", "Tranquility", "Flourish", "Rewind", "Darkness", "Rallying Cry")
Вы также можете использовать ability.id вместо ability.name, указав все ID заклинаний. Если вы используете названия на английском языке, нужно будет перевести логи на другие языки, чтобы фильтр сработал. А также можете исключить способности, используя ability.name NOT IN.
Хотите найти урон определенного типа? Например, вы можете найти весь не-физический урон с помощью этого выражения:
ability.type != 1
Тип способности 1 — физический урон; != означает "любой, кроме физического". Можно также отфильтровать только физический урон с помощью ability.type = 1
Значения параметров для всех типов урона можно найти на странице "Warcraft Wiki - Combat Log Events".
Это выражение удаляет способности / эффекты, наносящие урон себе.
source.id != target.id
Пример: Слово Тьмы: Смерть.
Хотели бы увидеть в логах урон от отраженных заклинаний?
source.id = target.id
Используйте это выражение, выбрав “Враги” и “Полученный урон”.
Icecrown Citadel
Цитадель Ледяной Короны