PathOfBuildingCommunity / PathOfBuildingCommunity/PathOfBuilding

Revamp eHP Calculations (for Recovery over Time)

Offen
#9,883 1 Kommentar 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

enhancement
Vorherrschende Sprache
Lua
Sterne
5.4k
Forks
2.4k
Ø Merge
1 T. 12 Std.
Gemergte PRs (30 T.)
26

Beschreibung

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.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne damit, die eHP-Berechnung und das Feld für die Trefferquote im config-Abschnitt zu lokalisieren. Verwende das vereinfachte Beispiel für Regeneration und Leech, um das vorgeschlagene zeitbasierte Modell zu verstehen, und bestimme anschließend, welche Wiederherstellungsmechaniken zuerst unterstützt werden können. Erledigt bedeutet, dass eHP eine ausdrücklich abgegrenzte Teilmenge von Wiederherstellungsmechaniken über die Zeit berücksichtigt, ohne die Wiederherstellung über das relevante Life- oder ES-Maximum hinaus aufzublähen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
lua
Bereich
game-dev
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Ruhig
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
35/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.