The mathematical description of how status effects such as blast is well-described in How Status Works: Definitive Status Guide MHW/Iceborne (link). However, I will attempt to summarize it here, in addition to clarifying some features of this game mechanic not mentioned in the video.
This document will focus on modelling the damage done by the following status effects:
Poison
Blast
Status Application
Status effects can be applied to monsters in a variety of ways, such as attacking while using a weapon with a poison/paralysis/sleep/blast value.
When a status is applied to a monster, that status is “built-up”. Only when this internal status application counter reaches certain thresholds does the status effect trigger (or proc).
All monsters have unique tables regarding status effect application. Buildup usually involves four particular values:
Base Tolerance (or simply base): The threshold before the first proc.
Tolerance Buildup (or simply buildup): Every time we hit the threshold, we increase the new threshold by this value.
Tolerance Cap (or simply cap): The maximum threshold.
Decay: The internal status application counter decays at a constant rate over time.
To illustrate how these values work, let’s consider Dodogama’s sleep values:
Base: 150
Buildup: 100
Cap: 550
Decay: −105 per second
Additionally, let’s specifically consider the following quest values:
Base Multiplier: 1.25
Buildup/Cap Multiplier: 1.90
Thus, our effective sleep values for that particular quest are:
Base: 150×1.25=187.5
Buildup: 100×1.90=190
Cap: 550×1.90=1045
Decay: −105 per second
Our first threshold is 188, so we must apply 188 sleep in order to get the first sleep proc.
After the first sleep proc, our new threshold is 188+190=378, so we must apply 378 sleep for the second proc.
After the second sleep proc, our new threshold is 378+190=568, so we must apply 568 sleep for the third proc.
This follows an arithmetic progression up until the cap, where it is clipped:
188⟶378⟶568⟶758⟶948⟶11381045⟶1045⟶1045⟶⋯
IMPORTANT: This is a draft. I actually don’t know how the rounding works, or other variables that status decay depends on, but my blast model is a continuous model, and blast doesn’t decay, so it doesn’t affect the remainder of this document.
Poison
(This section will be written later!)
Blast
Blast is a status effect that does not decay (i.e. decay is 0 blast per second).
A blast proc deals fixed damage, regardless of monster (100 in Low Rank, 120 in High Rank, and 300 in Master Rank). The damage is dealt instantly, and the status can immediately continue being built-up.
Model Design Goals
Raw damage and elemental damage have been shown to be easily and effectively compared by determining a representative raw and elemental damage per hit. Such methods are totally independent of time and player skill as each and every hit has the same average raw and elemental damage.
The goal of each damage model is to find similar numbers for status damage, estimating the effective average damage done by a status effect, per weapon hit.
Unfortunately, status effects are not as easy to model in the same way since the rate of status procs decreases as more status is applied on the monster. Status damage can also depend on player competence due to status buildup being disabled while a monster is suffering from a status effect.
While Q and H are very easy to finding depending on the quest, n must be found through experimentation.
This model is used due to the relatively low number of procs per hunt that can usually be determined.
Do note that this model assumes that poison status applied is already factored into n by the player, therefore all poison weapons will behave the same under this model.
Model Derivation
Let R be the total raw damage done during the quest. Qn is the total poison damage, so:
R=H−Qn
Let k be the total number of hits required to kill the monster. Then:
k=ρR=ρH−Qn
Let ψ be the effective poison damage per hit. This can be easily found:
ψ=kQn=H−QnρQn
Thus, we have found our damage model.
The Continuous Blast Damage Model
Input Variables
Our model is based on the idea that a single specified attack always deals a predictable amount of average damage and blast application each time the attack is performed.
For example, if a greatsword draw attack dealt 100 raw damage and 5 status buildup on average, we can expect that using the attack n-times would deal n×100 raw damage and n×5 status buildup on average.
These variables shall be:
ρ (average raw damage of an attack)
σ (average status application of an attack)
Conceptually, we can try counting how many of the specified attack (such as the greatsword draw attack) we have to deal before we slay the monster, so we consider monster health to be another variable:
H (monster total health)
If we ignore blast damage and assume all our damage comes from raw, it is trivial to see that we’d require ρH uses of the specified attack in order to kill the monster. However, it gets tricky when we factor in blast.
The variables related to blast are:
a1 (blast base)
d (blast buildup)
c (blast cap)
P (blast damage per proc)
Blast does not decay and blast procs do not cause status-application downtime (like how you cannot apply poison status if a monster is actively suffering from poison). This means that blast damage prediction can be completely independent of time, and dependent only on parameters relating to the sequence of attacks performed on the monster.
Our model will attempt to find the average blast damage per attack.
Pre-Cap Model Derivation
The following two equations are given for arithmetic progressions:
an=a1+(n−1)dSn=2n(a1+an)(1)(2)
where a1 is the first element of the sequence, an is the nth element, d=ai+1−ai, and Sn is the sum of the first n elements.
Equivalently, an is the threshold for the nth blast proc, and Sn is the total blast that must be applied to reach the nth blast proc.
Let Rn and Bn denote the total raw and blast damage (respectively), given n blast procs.
Since P is blast damage per proc, total blast damage is simply:
Bn=Pn
Thus, we can calculate B as:
Bn=P2dd−2a1+(2a1−d)2+8dSn
Since we know that we apply σ status for every ρ raw damage, it is trivial to calculate Rn using:
σρ=SnRn(4)
Thus, we can introduce Rn into our equation. Additionally, we no longer care about counting blast procs, so we can simplify the notation of total raw and blast damage to R and B:
B=P2dd−2a1+(2a1−d)2+8Rdρσ
In order to slay the monster, total raw and blast damage must add to equal the total health pool H:
Thus, we now have an expression for total blast damage, given the monster’s total health pool.
Now, we want to find out the average amount of blast damage dealt per attack, given the attack’s raw damage.
Let βp denote the average blast damage per attack, before hitting the blast cap.
It is trivial to use the ratio between R and B:
ρβp=RB=H−BB
Thus, we get an expression for βp in terms of B, H, and ρ:
βp=ρH−BB
Since we can use (6) to calculate B in terms of model input values, we now have an expression for calculating average blast damage per attack, given only our model input values.
For this model, it is useful to think of average blast damage per attack as a function of H, so we shall rewrite βp as a function [0,∞)→R such that:
βp(H)=ρH−B(H)B(H)
βp(H) is only valid up until H reaches the blast cap.
Blast Cap Derivation
The blast cap can be expressed as:
an≤c(7)
So to find where the pre-cap portion of the model stops, we must find the range of H in which (7) is true.
2σdρ(c2+cd+a1d−a12)≥H−Pρd2Hσ+(2d1(P2a1−d+ρ2σ))2−2dP2(P2a1−d+ρ2σ)2σdρ(c2+cd+a1d−a12)−2dP2(P2a1−d+ρ2σ)≥H−Pρd2Hσ+(2d1(P2a1−d+ρ2σ))2(10)TODO: The equations above are too long.
At this point, the status buildup threshold remains constant at c.
Since we have a constant threshold, then if we ignore pre-cap damage, any status buildup dealt will be linearly proportional to the damage it deals.
We will start by forming a relation between some number of hits k, average status per hit σ, and a blast threshold c:
k:=σc
Thus, k hits is required to cause a blast proc.
Let βc′ be the effective average blast damage dealt per hit, but only valid to damage dealt after C damage has been dealt to the monster:
βc′:=kP=cσP
Note that βc′ does not depend on monster health.
We know that each hit after reaching blast cap deals an average of ρ+βc′ damage, and we must distribute this damage in the remaining H−C health of the monster.
This allows us to construct an expression involving the actual effective average blast damage dealt per hit βc, which includes damage dealt before C damage was dealt to the monster. This expression is simply a weighted average:
TODO: Do we actually care to do a discrete-procs model? The continuous model is probably good enough for most purposes.
Motivation
In reality, blast damage is done on the monster only every now and then (though in a predictable manner).
For example, the continuous model might calculate the total number of blast procs as the non-integer number of 25.7, leading to a total blast damage calculation of 25.7×300=7710.
If one wishes to model the DPS fluctuations that are associated with this effect, then this total number of blast procs must be floored. In this case, the continuous model calculation of 25.7 must be floored down to 25, leading to a total blast calculation of 25×300=7500.
TODO
TODO: Start figuring out the math?
Model Extensions
I left out certain interpretations of the models in order to keep discussion as simple as possible. Now that the model has been introduced, we shall expand on these additional interpretations.
Combos
It turns out that if you can predict the average amount of raw damage and status application of a single attack, you can also do it for a given sequence of attacks.
Thus, ρ and σ can instead be interpreted as values for a given sequence attacks rather than just a single attack.
Target Health
H doesn’t actually have to be the monster’s total health pool if we don’t intend on slaying it. For example, we can instead make H the damage required in order to capture the monster.
Multiplayer might also be considered here since multiple players share the full health pool of the monster. For example, if we assume four perfectly equal players, then we might want to divide the full 4-player health pool by 4.