And why that distinction matters for real Path of Exile 2 gameplay.
Introduction
Most DPS tools answer a simple question:
“How much damage can this build deal?”
Oracle answers a different one:
“How reliable is this skill’s damage in real gameplay?”
This distinction is intentional — and especially important in PoE2.
The problem with a single DPS number
PoE2 combat is dynamic.
Damage output depends on:
- Enemy density
- Player movement and positioning
- Skill setup time
- Hit overlap and uptime
- Execution and reaction time
Reducing all of this to a single number requires assumptions.
Oracle makes those assumptions explicit.
Skill DPS Simulation
Oracle simulates DPS at the skill behavior level.
Each skill is classified into a behavior model, such as:
- Instant Hit
- Persistent Area
- Projectile Travel
- Channeling
- Position Dependent
- Damage over Time
Each behavior defines:
- How damage is simulated
- Which multipliers are safe to apply
- The maximum confidence the result can reach
What “Confidence” means
Confidence is not accuracy.
It is reliability under real gameplay conditions.
| Confidence | Meaning |
|---|---|
| HIGH | Damage application is deterministic and consistent |
| MEDIUM | Damage is reliable within a bounded range |
| LOW | Damage depends heavily on positioning, setup, or uptime |
Some behaviors will never reach HIGH confidence — by design.
That is not a limitation.
It is a signal.
Skill DPS Simulation in practice
Each skill is evaluated independently:
- Estimated DPS reflects simulated behavior
- Confidence reflects reliability, not potential
Why some skills are inherently uncertain
Not all damage is equal in terms of reliability.
Skills that depend on:
- Player positioning
- Enemy movement
- Area overlap
- Setup or ramp time
Will always carry more uncertainty.
Oracle does not remove that uncertainty — it exposes it.
Golden Calibration Builds
Oracle is calibrated using Golden Snapshots:
- Real characters
- Real skill setups
- Anchored to known behavior models
These snapshots are:
- Versioned
- Regression-tested
- Used to prevent silent changes
What Oracle will never do
Oracle will never:
- Assume perfect execution
- Inflate damage via idealized uptime
- Collapse multiple behaviors into a single number
- Hide uncertainty behind precision
Final note
Oracle is not designed to impress with large numbers.
It is designed to explain:
- Why a build feels stable
- Why another feels inconsistent
- And where real risk actually lies