Explosions, body parts & line of sight
One explosion can damage several body parts on the same enemy. Each accepted part resolves its own damage and can independently contribute damage to the enemy's main health pool. Line-of-sight verification is also configured per body part.
- Main-health loss
- Sum of part contributions
- LOS policy
- Configured per body part
- Direct heavy zones using None
- 0 found
Multipart health transfer
Large enemies can take several main-health contributions from one blast.
Each body part hit by the explosion is resolved separately. A part can lose its own health and also pass part of that effective damage into the enemy's main health pool. If several eligible parts are hit, those main-health contributions add together.
- 01
The blast reaches a body part
- 02
That part takes local damage
- 03
That part contributes to main health
- 04
The contributions add together
For ordinary body-part hits, the current code gives main-health loss = Σ ceil(transferable part damage × main-health multiplier) across the accepted parts reached by the blast. Transferable part damage is the effective damage after that part's damage rules and any local damage-cap limit have been applied.
A part with a 100% main-health multiplier that takes 300 transferable blast damage loses 300 local HP and contributes 300 damage to main health. If two eligible parts each take 300 damage with a 100% multiplier, their combined main-health contribution is 600. Fractional results are rounded up: 1 damage at a 70% multiplier contributes 1 main-health damage.
Fallback parts
Regular explosion processing resolves the struck body part and checks whether that part accepts radial explosion damage. Parts that do not accept it are handled through the default-zone path instead of taking an ordinary local radial hit. They should not be counted as separate local part hits in the multipart sum above.
Charger rear armor plates, underside, inner flesh, and claws use this fallback behavior. The exact ordering between fallback selection and line-of-sight verification still needs a current runtime trace.
Body-part verification
Each damageable part has an explosion verification mode. The mode controls whether the blast must pass a verification check at that distance.
| Mode | Inside inner radius | Falloff band |
|---|---|---|
| All | Verification required | Verification required |
| Outer Radius | Verification skipped | Verification required |
| None | Verification skipped | Verification skipped |
The inner radius does not universally ignore obstruction.
A part using All still requires verification inside the inner radius. Outer Radius skips verification only while the part is inside the inner radius.
Heavy-enemy layouts
| Enemy | Direct All | Direct Outer | Fallback | Practical result |
|---|---|---|---|---|
| Charger | 12 | 0 | 5 | Every part that directly accepts blast damage uses All. |
| Impaler | 18 | 3 | 2 | The three Tentacle Flesh parts use Outer Radius. |
| Bile Titan | 26 | 0 | 0 | Every active body part uses All. |
| Hive Lord | 0 | 26 | 12 | Every part that directly accepts blast damage uses Outer Radius. |
| Factory Strider | 10 | 22 | 1 | Different parts on the same chassis use different verification rules. |
| Vox Engine | 0 | 12 | 13 | Every part that directly accepts blast damage uses Outer Radius. |
Charger Behemoths and Charger Bulls use the same 12 direct All / 5 fallback layout as the standard Charger. Rupture Chargers add two more direct All parts. Spore Chargers keep 12 direct All parts and have 12 fallback parts.
The Bile Titan is the strictest case in this survey: all 26 active body parts require verification even inside the inner radius. The Hive Lord uses the opposite direct layout, with all 26 directly blast-damageable parts set to Outer Radius.
Verification collision filter
The current data establishes when a verification check is requested. It does not establish which colliders can fail that check. The remaining questions are whether sibling body parts, other enemies, corpses, shields, and world geometry are treated the same way, and whether special wide-blast processing uses the same verification path.
Current verification status
| Finding | Evidence status |
|---|---|
| Current heavy-enemy body-part data matches the researched verification and main-health values. | Current data confirmed |
| Body-part damage transfers to main health as the rounded-up product of transferable part damage and the part's main-health multiplier. | Current code confirmed |
| A per-part cap can limit the damage used for main-health transfer to the part's remaining local damage capacity. | Current code confirmed |
| Regular explosion processing resolves the body part and checks whether that part accepts radial explosion damage. | Current code confirmed |
| All, Outer Radius, and None are carried into the damage packet as three distinct verification settings. | Current packet construction confirmed; current verification consumer still being traced |
| A body part on the same enemy can block verification to another part. | Unresolved |
| Another enemy, corpse, or shield can block an explosion verification ray. | Unresolved |
| Wide-blast sources use the same verification path. | Unresolved |
Research basis
Methodology How the current data was checked
The current decoded health data was compared against the earlier heavy-enemy research set. All 265 surveyed body-part rows matched for verification mode, explosion acceptance, local health, armor, durability, main-health multiplier, and explosive-damage percentage. The health-application routine was also re-established in the current executable from the previously confirmed function and current field behavior. It directly subtracts local zone health, applies the optional local damage cap, rounds the multiplier result up, and subtracts that contribution from main health. The exact collision filter used by explosion verification remains unresolved.
Evidence standard
How the OTL separates code confirmation, controlled live testing, and behavior that remains unresolved.
How the OTL rates evidence
The OTL rates code evidence and live-game evidence separately. A mechanic can be clear in code but still need a controlled gameplay check for hidden state, ordering, or another runtime factor.
Live confirmation means controlled gameplay or instrumented runtime observation, not player impression alone.