PathOfBuildingCommunity / PathOfBuildingCommunity/PathOfBuilding
Revamp eHP Calculations (for Recovery over Time)
Nadie ha tomado este issue todavía.
- 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
XLife. - It is hit for
Ddamage. D < X.- The hit occurs every
Tms.
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
XLife. - No avoidance.
- No currently supported eHP modifiers (e.g. Defiance of Destiny).
- No armour or other physical mitigation.
- Incoming hit deals
Dphysical damage, without Crit Chance - Hit occurs every
Tms.
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
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- 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