Effective Hit Pool (EHP): почему одного числа недостаточно

Одна и та же сборка спокойно переживает плотную пачку, а затем погибает от одного мощного удара с несколькими типами урона. Это не противоречие и не обязательно признак «маленького EHP». Пачка и мощный удар задают защите разные задачи: в одном случае важны повторные проверки и восстановление между событиями, в другом — способность пережить весь удар прямо сейчас.

Вместо попытки сразу вспомнить все механики задайте четыре вопроса:

1. Что случилось? Hit, Damage over Time (DoT) или их последовательность.
2. Что было доступно защите? Сколько осталось Life и Energy Shield, активны ли Flask, Guard Skill и другие временные эффекты.
3. Куда прошёл урон? Какие защиты вообще могли сработать и в какие ресурсы пришёл остаток.
4. Где возник провал? Hit оказался слишком большим, отложенная потеря Life стала смертельной или восстановление не удержало входящий поток.

Эти четыре вопроса образуют протокол анализа входящего урона. Он помогает выбрать нужный результат и объяснить его, но сам не является ещё одним полем или рейтингом. Если не названы угроза, состояние и время наблюдения, одно красивое число EHP не объясняет, почему персонаж выжил или погиб. Одноимённое поле Path of Building (PoB) мы разберём отдельно в §8 и не будем подменять им весь протокол.

Первая маленькая плашка — заданная учебная сцена [MODEL]. Она напоминает, что числа принадлежат объявленному примеру, а не игре вообще. Остальные метки пока можно пропускать: их смысл и границы мы соберём вместе в §6.

Сквозной фокус — один учебный основной смешанный Hit внутри десятисекундной сцены. В §§1–4 мы изолируем его: в гибридную сборку с 3200 Life и 800 Energy Shield (ES) приходит Attack Hit с Physical-компонентой и дополнительной Chaos-компонентой. К этому Hit мы вернёмся в ключевых точках. В §7 та же именованная сцена раскроется полностью: появятся фоновые угрозы, темп и восстановление. Armour уменьшит только Physical-компоненту основного смешанного Hit, Chaos-компонента обойдёт ES, а остатки обеих частей встретятся в Life.

1. Сначала опишите угрозу и состояние

Не начинайте с перечня всех защит сборки. Сначала заполните короткий паспорт конкретной угрозы:

1. Форма: это Hit, а не Damage over Time (DoT).
2. Источник: этот Hit пришёл от Attack, поэтому защиты только против Spell ему не помогут.
3. Состав: в одном событии есть Physical- и Chaos-компоненты.
4. Снимок: перед Hit доступны 3200 Life и 800 ES; временные эффекты учитываются только если они активны в этот момент.

Уже этого достаточно для первого полезного вывода. Armour может изменить только Physical-компоненту. Обычный маршрут Chaos Damage обходит ES. Значит, вопрос «сколько EHP у гибрида?» слишком груб: нужно увидеть, сколько каждой компоненты дошло до Life и хватило ли этого запаса после объединения остатков.

Угроза описана. Теперь не складываем проценты: сначала проверим, какие защиты вообще имеют право участвовать в этом событии.

2. Какие защиты вообще сработают

Проверка того, сработает ли защита, всегда идёт раньше сравнения величин. Для нашего смешанного удара результат можно прочитать без формулы:

• Evasion и Block могут проверить Attack Hit, если это разрешено его свойствами;
• Spell Suppression не участвует, потому что источником события служит Attack, а не Spell;
• Armour видит Physical-компоненту, но не Chaos-компоненту;
• Chaos Resistance видит Chaos-компоненту, но не исправляет Physical-компоненту;
• ES принимает допустимый остаток урона других типов, а обычный Chaos Damage проходит мимо него.

Поэтому сколь угодно большое значение Armour бесполезно для маршрута, который эта защита не видит. Spell Suppression не является слабым ответом на Attack — оно вообще не является ответом. Общее уменьшение получаемого урона и Fortification тоже нельзя склеивать: первое может покрывать и Hit, и DoT, второе ограничено Hit.

Матрица ниже показывает только право слоя участвовать. Она не обещает, что применимый слой уже достаточно велик.

Для основного смешанного Hit Armour участвует только в Physical-компоненте, а на Chaos-компоненту не влияет. Chaos Resistance, наоборот, не исправляет Physical-ветвь. ES принимает подходящий остаток урона других типов, но обычный Chaos Damage обходит его. Если увеличить Armour и увидеть рост предела Physical- ветви, это ещё не доказывает рост общего запаса: Chaos-ветвь могла остаться ограничением. Поэтому следующий шаг после карты применимости — не суммирование процентов в окне персонажа, а проведение каждой компоненты до конечного ресурса.

3. Куда проходит остаток удара

Мы знаем, какие защиты включились. Теперь проведём смешанный удар до ресурсов четырьмя действиями:

1. Один Hit разделяется на Physical- и Chaos-компоненты.
2. Каждая компонента встречает только подходящие ей сопротивления, уменьшение входящего урона и другие применимые модификаторы.
3. Если они активны, остаток сначала встречает поглощение активного Guard Skill, затем Ward.
4. Остаток распределяется между ES, Mana и Life с учётом обхода ресурсов.

получено от события = Σ получено по маршруту каждой компоненты
поглощено активным Guard Skill + поглощено Ward + к ресурсам = всего получено
ES + Mana + Life = к ресурсам

Порядок важен не только для правильного итога, но и для объяснения причины. Сначала заявленный урон разлагается на компоненты. Затем каждая компонента получает только свои снижения, сопротивления и модификаторы. После этого рассчитанный остаток в установленном порядке встречает поглощение активного Guard Skill и Ward. Лишь затем урон делится между ES, Mana и Life с учётом обхода. Если перепрыгнуть прямо от исходного Hit к одной итоговой сумме, исчезает главный диагностический факт: какая защита действительно сработала и какой запас закончился.

Для разового удара нужна граница на конкретном маршруте. В изолированной клетке одного исходного типа ей соответствует поле PoB Maximum Hit Taken. У произвольного смешанного пакета нет одного прямого поля PoB: его результат ниже мы называем пределом именно этого основного смешанного Hit. Достижимым считаем маршрут, который разрешён зафиксированной сценой, даже если частота его ветви не задана. Минимум ищут только среди таких маршрутов и рядом хранят второй: после улучшения слабого места ограничение может переехать.

Перед числами заморозим полный снимок сборки. У неё 3200 Life, 800 ES, 17 000 Armour, четыре Endurance Charges, по 75% Elemental Resistances и Chaos Resistance, активное Fortification с 20% уменьшением урона от Hit и 800 Life Regeneration в секунду. Шансовые слои — 50% Evade Chance, 35% Block Chance, 35% Spell Block Chance и 50% Spell Suppression Chance — меняют доступные ветви; в детерминированный предел уже прошедшего Hit они не входят. Поглощение активного Guard Skill, Ward и перенаправление в Mana в этом снимке отсутствуют.

У предела Hit есть два корректных режима чтения. Изолированная клетка спрашивает, какой отдельный Hit одного типа переживёт сборка в объявленном состоянии. Проверка сцены спрашивает, переживёт ли она конкретный смешанный Hit или последовательность событий. Первая проекция удобна для поиска слабых маршрутов, вторая — для проверки сформулированной угрозы. При снимке выше матрица рассчитывает для изолированного Physical Attack Hit предел около 8879 урона. Его нельзя сложить с пределом Chaos Hit: в смешанной сцене обе компоненты сходятся в одном запасе Life.

Матрица выше — только карта перед путешествием Hit. Она показывает разные пределы изолированных Physical- и Chaos-клеток, но заданная сцена [MODEL] содержит обе компоненты одновременно. Основной смешанный Hit заявляет 7500 Physical Damage и создаёт отдельную Chaos-компоненту размером 130% от базы: 7500 × 1,30 = 9750. Это заданный вход сцены, а не вывод о типичном игровом ударе. Поэтому ниже нужен не ещё один усреднённый столбец, а один прослеживаемый путь: сколько вошло, сколько сняли применимые защиты и какие ресурсы оплатили остаток. Все суммы обязаны сходиться с законом сохранения выше; визуализация не пересчитывает урон самостоятельно.

Разберём увиденное словами. Заданная сцена [MODEL] даёт две компоненты: 7500 Physical Damage и 9750 дополнительного Chaos Damage. Эти числа ещё нельзя вычитать из Life: каждая компонента сначала проходит собственные защиты. Armour и Endurance Charges уменьшают Physical-компоненту, Chaos Resistance — Chaos-компоненту, а активное Fortification действует на обе как на компоненты Hit. После этих правил остаётся примерно 3168 Physical Damage и 1950 Chaos Damage. Вместе до ресурсов доходит около 5118.

У сборки нет поглощения активного Guard Skill, Ward и перенаправления в Mana, поэтому их вклад равен нулю. Physical-компонента расходует доступные 800 ES и отправляет оставшиеся примерно 2368 в Life. Chaos-компонента обходит ES и целиком отправляет туда ещё 1950. Всего из Life должно уйти около 4318 при доступном запасе 3200. Не хватает примерно 1118: Hit смертелен.

Это не универсальный предел персонажа и не реконструкция реальной смерти. Размер и состав удара — входы заданной сцены [MODEL]; применение правил и баланс сохранения — повторяемый расчёт [DET] при этих входах. Вывод конкретнее фразы «мало EHP»: ES помог только Physical-ветви, Armour не помогла Chaos-ветви, а в Life сошлись остатки обеих. Следующий эксперимент уже можно сформулировать точно: не меняя сцену, по одному проверить Armour, Chaos Resistance и увеличение Life на дефиците 1118. Запас сопротивления сверх максимума — другой опыт и может дать нулевой результат.

4. Что меняют случайные проверки

В §3 мы уже находились на ветви, где удар дошёл до расчёта урона. Теперь отделим её силу от другого вопроса: как часто генератор событий вообще приводит к этой ветви.

Block Chance, Evasion и Spell Suppression Chance меняют то, какая ветвь наступит, но делают это по-разному. Block выполняет отдельную случайную проверку для каждого подходящего Hit. Evasion использует состояние, которое выравнивает последовательность попаданий и промахов. Успешное Spell Suppression уменьшает урон, а не превращает Spell в промах.

Чтобы найти предел удара при шансе ниже 100%, нужно рассмотреть достижимую ветвь, где случайная защита не спасла. При 100% Spell Suppression для подходящего Spell Hit такой ветви уже нет: подавление применяется к каждому достижимому Hit и входит в его детерминированный предел. Чтобы обсуждать серии неудачных проверок, нужно явно задать генератор событий, число попыток и их веса. Тяжёлая контрольная точка — это заранее выбранная верхняя величина Hit, например средний Hit с множителем верхней границы damage roll. Без распределения и числа попыток она показывает чувствительность сборки, но не вычисляет вероятность смерти именно вашего персонажа.

Виджет разводит три утверждения. Детерминированный предел отвечает, что произойдёт, если ветвь с уроном уже наступила. Усреднение допустимо как диагностическая эвристика только при явно заданной модели. Тяжёлая контрольная точка отвечает, выдержит ли сборка выбранное сочетание вроде Critical Strike и верхней границы damage roll. Ни одна из этих проекций сама по себе не сообщает, как часто такое событие встречается.

Это особенно важно при выборе между ещё одним шансовым слоем и защитой «за ним». Первый уменьшает долю ветвей, где урон дошёл до ресурса. Вторая уменьшает величину уже дошедшего урона или расширяет доступный запас. Если проблема — единичный прошедший удар, который гарантированно смертелен, увеличение Block Chance может повысить долю безопасных ветвей, но не исправит смертельную ветвь. Если каждый прошедший удар безопасен, а опасность создаёт множество попыток, шансовый слой может быть правильным рычагом — но тогда результат принадлежит заданному генератору событий и временному окну.

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

Шансовая модель ответила, наступит ли ветвь с уроном, но не ответила, что произойдёт после пережитого удара и между событиями. Основной смешанный Hit для этого плохой учитель: он убивает сразу. Поэтому следующий раздел честно берёт отдельный переживаемый удар и показывает следующий переход состояния.

5. Что меняют время и восстановление

Здесь мы намеренно меняем сцену. У отдельной учебной сборки есть 5000 Life. В модели на неё наложен эффект Progenesis: он откладывает 40% потери Life от Hit. Это авторская доля для наглядного перехода, а не заявленная величина текущего уникального Flask. В сборку приходит Hit на 8000 без других защитных ресурсов. Сразу теряется 4800 Life и остаётся 200: момент получения Hit пережит. Ещё 3200 Life записываются как долг и равномерно выплачиваются за 4 секунды. Без восстановления этот долг отнимет оставшиеся 200 примерно за 0,25 секунды.

Это не продолжение основной сцены смешанного удара. Там сам удар смертелен, а отложенного долга нет. Здесь удар пережит, но следующая обязательная выплата смертельна. Смена примера нужна, чтобы разделить три разных утверждения:

1. Hit пережит в момент получения: доступный запас не закончился сразу.
2. Последствия Hit пережиты: отложенный долг выплачен с учётом допустимого восстановления.
3. Всё окно пережито: следующие события и постоянная нагрузка тоже не исчерпали ресурсы.

Слово «пережил» без названного окна неполно. Оно может быть истинным для первой строки и ложным для второй. Progenesis и Petrified Blood именно поэтому нельзя сворачивать в один «бонус к запасу»: они меняют переход состояния после удара, но не стирают обязательную потерю.

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

чистая скорость = входящий урон/с − восстановление/с
время до исчерпания = доступный запас / чистая скорость
если чистая скорость ≤ 0: время до исчерпания = ∞ в пределах модели

Эта формула относится к одному восстанавливаемому запасу. Она не разрешает сложить Life, ES, Mana и все виды восстановления в одну дробь. Life Regeneration не восстанавливает ES. Recoup появляется только после Hit. Leech и Flask зависят от времени активности. Mana может одновременно быть защитным буфером и ресурсом для действий.

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

Damage over Time (DoT) тоже читается через скорость и окно. В паспорте уязвимостей он показывает входящий урон в секунду и время до исчерпания ресурса. Это другая единица, чем предел переживаемого удара: 900 урона в секунду нельзя честно поставить в один рейтинг с ударом на 9000.

У любого источника восстановления есть как минимум три независимых свойства: величина в секунду, момент начала и доля времени, когда он остаётся активным. Одинаковые 500 восстановления в секунду дают разные исходы, если Life Regeneration работает постоянно, Flask заканчивается посреди сцены, а ES Recharge ещё не успела открыться. Длительность самой сцены — четвёртый параметр, а не другое название доли активности. Нельзя компенсировать короткое окно предположением, что источник «обычно включён»: нужно записать оба значения отдельно.

Отложенная потеря от этих двух эффектов живёт на той же временной шкале, но не становится входящим DoT и не проходит защиту повторно. Сначала рассчитывается сам удар, затем из направленной в потери Life создаётся долг, затем расписание выплачивает его. В нашей модели смертельный момент Hit проверяется раньше следующего шага восстановления: последующее лечение не отменяет уже наступившую смерть.

Практический временной разбор состоит из четырёх вопросов. Что осталось сразу после удара? Какой долг создан и с какой скоростью он выплачивается? Какое восстановление действительно активно? Какое следующее событие снова закроет ES Recharge или изменит доступный запас? Если вместо ответа стоит слово «обычно», время до исчерпания уже относится к другой сцене.

Сборка может не удерживать поток бесконечно, но переживать его достаточно долго для заданной фазы. Тогда конечное время до исчерпания сравнивается именно с длительностью сцены. Обратная ошибка — увидеть нулевую или отрицательную чистую скорость и объявить бессмертие: короткий удар всё ещё может убить раньше, чем восстановление проявится, а пауза в Flask, Leech или входящем потоке изменит обе стороны формулы.

Отдельный пример показал то, чего не мог показать смертельный основной смешанный Hit: жизнь после момента удара. Возвращаясь к основной сцене, мы уже знаем, что её основной смешанный Hit не создаёт отложенного долга; временная проверка понадобится только для фонового потока полного десятисекундного окна.

6. Где заканчивается модель

Статья и виджеты не восстанавливают конкретную смерть и не знают, как часто выбранное событие встречается в бою. Они отвечают на более узкий вопрос: что произойдёт с явно заданной угрозой, состоянием и окном наблюдения.

Короткие метки рядом с результатом показывают происхождение знания:

• правило игры [RULE] задаёт маршрут или применимость;
• повторяемый расчёт [DET] даёт одинаковый результат для одинаковых входов;
• заданная сцена [MODEL] хранит выбранную нами величину или расписание;
• приближение [APPROX] имеет объявленную ограниченную область применения;
• недостаток данных [OPEN] означает, что готового вывода нет.

Метка относится не ко всему виджету сразу. Размер удара и его время могут принадлежать заданной сцене [MODEL], а проведение этого удара по защитам — повторяемому расчёту [DET]. Тяжёлая контрольная точка без распределения показывает достижимую уязвимость, но не вероятность смерти. Неизвестность нельзя чинить «разумным средним»: нужно создать две отдельные сцены или оставить вопрос с недостатком данных [OPEN].

Границы объявлены. Теперь можно менять одну величину и честно смотреть, какая причина отказа исчезла, а какая стала следующей.

7. Как выбрать следующее изменение

Рабочий разбор сборки — не поиск «лучшего EHP», а повторяемый цикл.

Здесь нет четырёх конкурирующих списков. Три входа — угроза, состояние и окно — задают сцену. Четыре вопроса из введения направляют диагноз. Четыре проверки ниже подробно раскрывают вопрос «где возник провал?». Семь шагов превращают этот диагноз в один проверяемый эксперимент:

1. Опишите угрозу: форма, источник, типы урона, размер удара или урон в секунду.
2. Зафиксируйте состояние и окно: текущие ресурсы, активные эффекты, восстановление и длительность.
3. Отбросьте защиты, которые не могут сработать против этого события.
4. Проведите каждую компоненту через применимые защиты до поглощения активного Guard Skill, Ward и конечных ресурсов.
5. Прочитайте четыре проверки сверху вниз; назовите первую проваленную и следующий достижимый ограничитель.
6. Измените одну величину, не меняя одновременно угрозу, состояние и проверяемый результат.
7. Сравните пользу с ценой и повторите цикл, если ограничитель переехал.

Перед таким экспериментом полезно собрать четыре проверки сцены в одну упорядоченную запись. Она не складывает несовместимые единицы. Она спрашивает по очереди: пережит ли основной удар, пережита ли тяжёлая контрольная точка, выплачен ли созданный долг и выдержан ли постоянный поток на заданном окне. «Первая» здесь означает первую проваленную проверку в диагностическом порядке, а не первый момент игровой временной шкалы.

проверки = удар → тяжёлая точка → долг → постоянный поток
вердикт = первая проваленная проверка
если провала нет: заданное окно пережито

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

Теперь снимем изоляцию с основного смешанного Hit и предъявим полную сцену, из которой получается временной вывод. Окно длится 10 секунд. В нём:

• основной смешанный Hit на 7500 Physical Damage с дополнительной Chaos-компонентой 130% приходит 0,3 раза в секунду; тяжёлая точка отдельно умножает верх урона на 1,2;
• Hit от Attack прислужников на 800 приходят суммарно 4 раза в секунду; кластер до трёх Hit меняет тяжёлую точку, но не средний темп;
• Fire Hit на 3500 без шансовой проверки приходит 0,25 раза в секунду;
• у сборки действуют 50% Evade Chance, 35% Block Chance и 800 Life Regeneration в секунду.

Это авторское расписание заданной сцены [MODEL], а не частота игрового босса. Каждый наступивший маршрут всё так же рассчитывается повторяемо [DET]. Только после этих входов число около 18 секунд становится проверяемым результатом, а не скрытой посылкой.

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

В исходной сцене основной смешанный удар уже смертелен. Тяжёлая контрольная точка тоже смертельна, но не определяет итог: более ранняя проверка удара провалилась первой. Отложенный долг здесь равен нулю — не потому, что некий «переживший кандидат» успешно его выплатил, а потому, что данная сцена вообще его не создаёт. Для предъявленной выше постоянной нагрузки время до исчерпания составляет около 18 секунд и превышает окно сцены в 10 секунд. Эта поздняя проверка пройдена, но она не может отменить смерть в момент удара.

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

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

польза(x) = [метрика после(x) − исходная метрика] / цена(x)
если x не действует на событие: польза(x) = 0

Здесь x — ровно одно изменение, а его цена — выбранная вами единица дефицитного бюджета: например, место аффикса, очки пассивного дерева или валюта. Формула не объявляет эти разные цены взаимозаменяемыми; она заставляет заранее записать, чем именно вы готовы платить.

Честный опыт замораживает всё, кроме одной величины. Если одновременно увеличить Life, сменить Flask, включить другой эффект в Configuration и выбрать более слабую угрозу, улучшившийся результат не сообщает, какое решение сработало. Полезнее сделать четыре коротких сравнения с одним исходным состоянием, чем один большой «до/после» без причинной связи.

Нулевая польза тоже является результатом. Она может означать не слабую механику, а отсутствие права участвовать в выбранном маршруте. Armour не обязана улучшать прямой Chaos Damage over Time (DoT), а Spell Suppression — Attack Hit. Такой ответ экономит ресурсы сборки: следующий опыт нужно ставить на защите, которая видит событие, либо на общем конечном запасе.

Лаборатория ниже намеренно открывается отрицательным опытом: Spell Suppression против Attack. Затем выберите Life или Armour, чтобы увидеть ненулевое изменение. Показанный предел относится ко всему фиксированному основному смешанному Hit; у него нет одного прямого поля Maximum Hit Taken в PoB.

Сквозной пример теперь завершается конкретнее совета «добавить защиты». Armour меняет только Physical-компоненту основного смешанного Hit. Chaos Resistance меняет только Chaos-компоненту, а запас сопротивления сверх максимума может не изменить её вовсе. Life расширяет общий конечный запас, в который сходятся обе компоненты. Сначала сравниваем эти изменения на одном модельном пределе Hit, затем снова запускаем все проверки сцены. Если после улучшения Chaos-маршрута ограничением становится Physical-ветвь, эксперимент сработал: он обнаружил следующую проблему.

8. Как перенести разбор на свою сборку

Финальные поверхности — не каталог дополнительных калькуляторов. Каждая отвечает за свой участок цикла: сравнение сцен задаёт разные входы; повтор боя показывает состояние во времени; PoB проверяет вашу сборку; Атлас тренирует чтение одного маршрута без импорта персонажа.

Три карточки держат одну и ту же сборку и меняют только сцену. Это не рейтинг игрового контента и не прогноз смертей. Плотная серия событий, смешанный наземный урон и мощный удар атакуют разные маршруты и окна. Если одна карточка пройдена, а другая нет, противоречия нет: изменились событие, состояние или время наблюдения.

Перед Атласом проиграйте отдельный учебный бой. Это новая заданная временная сцена [MODEL] со своей сборкой на 4500 Life и 2200 ES, а не продолжение основного смешанного Hit. Величины и расписание угроз, окна Flask и Leech заданы автором; каждое событие проходит тот же порядок защит и распределения по ресурсам. Смотрите не на драматичность анимации, а на три причинных перехода: Chaos Damage может уменьшать Life при сохранившемся ES, новое повреждение снова закрывает Energy Shield Recharge, а окончание входящего потока меняет баланс восстановления. Повтор не является записью карты, реконструкцией смерти или игровой вероятностью.

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

Перенос в PoB начинается не с копирования чисел учебной сцены. В точных полях ниже Effective Hit Pool — это агрегат PoB, а не название диагностического протокола статьи.

1. В Configuration восстановите тип события, состояние персонажа и условия противника.
2. В Calcs раскройте Damage Taken: там видны Enemy Damage и преобразование Taken As. Итог после защит ищите в строке Hit taken внутри Damaging Hits. Затем проверьте Maximum Hit Taken в одной из пяти строк исходного типа. Защитное преобразование Taken As внутри такой строки учитывается, но смешанный пакет из нескольких исходных компонентов проводите по частям: одного прямого поля для всего такого пакета нет.
3. Effective Hit Pool и Time before death читайте только вместе с настроенным Hit и скоростью действий противника, для которых они рассчитаны.
4. Измените одну величину и сравните то же поле, не перестраивая одновременно всю сцену.

Эти поля не являются версиями одного рейтинга. Damage Taken и Hit taken показывают разные этапы расчёта. Maximum Hit Taken для отдельного типа отвечает за предел соответствующей настроенной проекции. Effective Hit Pool умножает среднее число повторений настроенной попытки удара до смерти на сумму её исходных компонентов. Это среднее уже учитывает выбранную форму события и шансовые защиты PoB. Поле времени до смерти Time before death умножает то же среднее число на настроенный интервал действий противника с Attack или Spell; восстановление ресурсов между ударами оно по временной шкале не проигрывает. Это не наша общая формула «запас / чистая скорость» и не готовый ответ для смешанного десятисекундного расписания. Ни одно из этих полей не заменяет четыре вопроса статьи. Если адрес поля не совпадает с вопросом, точное число всё равно будет точным ответом не на ту задачу.

Если источник, время активности или состав компонентов неизвестны, сохраните несколько отдельных сценариев вместо среднего. После каждого улучшения снова назовите первую проваленную проверку и следующий достижимый ограничитель. Тогда метод остаётся полезным, даже когда заданная учебная сцена [MODEL] уже не похожа на вашу карту.

Финальная самопроверка занимает одну строку: назовите угрозу, состояние и окно; проведите компоненты до ресурсов; укажите первую проваленную проверку; предложите одно изменение и следующий возможный ограничитель. Если все пять частей названы, вы воспроизвели метод, а не просто узнали знакомое число.