PathOfBuildingCommunity / PathOfBuildingCommunity/PathOfBuilding

Revamp eHP Calculations (for Recovery over Time)

Abierto
#9,883 1 comentario 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

enhancement
Lenguaje dominante
Lua
Estrellas
5.4k
Forks
2.4k
Merge medio
1 d 12 h
PR fusionados (30 d)
26

Descripción

Check for duplicates
  • I've checked for duplicate open and closed issues by using the search function of the issue tracker
What platform are you running Path of Building on?

Windows

Is your feature request related to a problem?

I think eHP, as a concept, is extremely valuable. Representing the total amount of damage a character can take before dying is one of the most useful survivability metrics available.

However, the current implementation falls far short of that goal.

The main issue is that eHP only accounts for a limited set of mechanics, such as avoidance and instant recovery on block or before hits. Those are handled well, but actual survivability is also heavily affected by recovery that occurs between hits. This recovery over time is completely neglected.
If eHP is intended to represent "damage taken before dying", ongoing recovery should be part of the calculation.


As an example, any build with sufficiently high attack/spell block and Life/ES gained on block can reach extremely high eHP values against the default hit configured in PoB.
And that's correct because, yes: you can tank this hit basically forever then.

However, the exact same outcome can be achieved through many other recovery mechanics that currently do not contribute to eHP.
At the extreme end:

  • A character has X Life.
  • It is hit for D damage.
  • D < X.
  • The hit occurs every T ms.

If the character recovers D Life over the interval T, then it is functionally immortal against that scenario.

Yet none of the following currently affect eHP:

  • Any Regen
  • Any Leech
  • Any Recoup
  • Other recovery-over-time mechanics
  • Life/ES/Mana gained on Hit
  • Continuous Life Flasks
  • and probably more I can't think of right now

If the purpose of eHP is to display "damage taken before dying", omitting these mechanics makes the metric incomplete.

As a result, the current eHP value is often misleading. It only accurately represents survivability for a relatively small subset of builds that rely on the mechanics currently supported by the calculation.

It also leads to players overly focusing on avoidance mechanics and recovery on avoidance effects because those directly increase the displayed eHP number.
Since "bigger number = better", players undervalue recovery mechanics that substantially improve "real world" survivability but do not change the eHP in PoB at all.

Describe the solution you'd like

I'd like to see eHP evolve into a model that takes time into account.
The config section already contains a hit-rate field. That information could be incorporated into the calculation.

Consider the following simplified example:

  • Character has X Life.
  • No avoidance.
  • No currently supported eHP modifiers (e.g. Defiance of Destiny).
  • No armour or other physical mitigation.
  • Incoming hit deals D physical damage, without Crit Chance
  • Hit occurs every T ms.

Right now in PoB, the displayed eHP is simply:
eHP = X
No amount of regeneration or leech changes this value, despite having an obvious impact on survivability over time/the number of hits until death.

Now assume the character also has:

  • Life regeneration per second: R
  • Life leech per second (non-instant): L

Then the actual damage that can be sustained before death becomes:

$$
D \times \left\lceil \frac{X}{D - (R + L)\left(\frac{T}{1000}\right)} \right\rceil
$$

where

$$
\left\lceil \frac{X}{D - (R + L)\left(\frac{T}{1000}\right)} \right\rceil
$$

is the hit number on which the character dies.

I illustrated this using the following sawtooth graph:
https://www.geogebra.org/graphing/nvaj29j2

e.g. with:

  • 5000 Life
  • 1000 Life/s regeneration
  • 2000 Life/s leech
  • 2000 damage every 620 ms

The character dies on the 36th hit, corresponding to 72,000 eHP.

EDIT: okay I actually forgot to cap the health at the Life max, currently it overfills and thus inflates. It's too late, gonna fix that tmrw.

Describe alternatives you've considered

No response

Additional context

This example is intentionally pretty minimal.

Things such as "X gained on hit" are comparatively straightforward to model, but things become more complicated once mechanics such as Recoup with its ramp over time are introduced
Damage being distributed across different pools (Life, ES, Mana, Ward), each with potentially different recovery methods also will make it more complicated.


I doubt every currently unsupported recovery mechanic could realistically be added at once.

However, eHP has already been significantly limited for a long time. Moving toward a time-based model and initially supporting only a subset of recovery mechanics (for example regeneration, leech, gain on hit, and recoup) would already be a massive improvement.

Perfect should not be the enemy of good, yadda yadda.

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Comienza localizando el cálculo de eHP y el campo de hit-rate de la sección config. Usa el ejemplo simplificado de regeneración y leech para entender el modelo propuesto basado en el tiempo y, después, determina qué mecánicas de recuperación pueden admitirse primero. Se considera terminado cuando eHP tiene en cuenta un subconjunto explícitamente delimitado de mecánicas de recuperación a lo largo del tiempo sin inflar la recuperación por encima del máximo de Life o ES correspondiente.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
lua
Área
game-dev
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Tranquilo
Claridad
Bastante claro
Aptitud para principiantes
35/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.