TL;DR: EDIT 2: Confirmed immolation grenade kills whose AoE overlaps with a red barrel or a scab bombers grenade AoE will count correctly. 200 kills in 2 missions, but I was baiting hordes to red barrel.
I think it has to do with the AoE radius logic and how it tracks enemies within it. Based on behaviour from video posted above by @Ethaes (https://youtu.be/atqc2ZOy31Y) (thanks @Ethaes !!), the counter goes up by one, from a visible death for the Scab Bruiser death at 0:30 timestamp. This bruiser didn’t get hit by the initial wave of the immolation AOE and ran through it post-detonation and seems to have received all the damage for their death from the immolation grenade.
The next death counter uptick is again a scab bruiser that dies from going into the AOE post detonation and dies from solely that damage at 0:49. We see any that died from another damage source and any that died that were in the original blast radius of the immolation grenade do not count towards the counter increase.
At 1:04 we see Ethaes is at 1477 kills. At around 1:11 on their right, we see 4 groaners just outside the AoE post detonation and going into the radius; subsequently dying to DoT by 1:17. His kill count goes to 1481.
The last clip at 1:49 kind of counters this theory, as there is a groaner at the end that walks inside the AoE post detonation and dies to it without having the counter go up. But I think this is a separate issue. I think the event trigger that is checking for AoE boundary crossings is delayed. See clip starting at 0:21 shows a bruiser enter the AoE post detonation, but within 2 seconds of it being in place, and its death is not counted. But a bruiser that comes after the AoE is there for more than 4 seconds does have its death count.
I think the core issue is logic in the AoE boundary crossing event checking; specifically a time delay before it starts and how it tracks enemies within it at initialisation. I’m only guessing, but the script likely sets a flag upon entry to the AoE (which likely an event trigger in of itself) and then checks if a certain damage source (the grenade) directly causes the death AND has the flag. If a unit dies after entering the area, from immolation DOT tick, the kill is counted, but units already within do not trigger the entry event logic, thus never getting the flag. They likely have it coded this way, as there is no class for the immolation grenade damage type, otherwise there is a way easier way to track kills (just check last damage source== ImmolationGrenade). It’s likely just alt parameter fire damage that is the same as what’s used with the barrels.
i.e. Observed behaviour (time delay and unit initial position not accounted for):
function InitializeAoE(AoEcenter, AoEradius):
thread.delay(2000)
AoE.center = AoEcenter
AoE.radius = AoEradius
AoE.active = true #init boundry crossing event trigger for radius AoEradius around AoEcenter.
# No initial check for enemies within the radius
#Boundary-Based Event Trigger; only triggers on boundry crossings.
function OnEnemyEnterAoE(enemy):
enemy.hasEnteredAoE = true
function OnEnemyDeath(enemy, causeOfDeath):
if causeOfDeath == fire_DoT and enemy.hasEnteredAoE:
increment ImmolationGrenade_kill_counter
What we want is a check (and remove the time delay):
function InitializeAoE(AoEcenter, AoEradius):
AoE.center = AoEcenter
AoE.radius = AoEradius
AoE.active = true
# Mark all enemies initially within the AoE as affected
for enemy in GetAllEnemies():
if distance(enemy.position, AoE.center) <= AoE.radius:
enemy.isAffectedByAoE = true # Ensures all initial enemies are tracked
function OnEnemyPositionUpdate(enemy):
# Continuously track and mark any new entries after AoE setup
if distance(enemy.position, AoE.center) <= AoEradius:
enemy.isAffectedByAoE = true
But I can see why this isn’t a simple fix, due to for loops being O(n) within a single call, would cause a lag spike every time someone threw an Immolation Grenade, where n is a number of enemies in a cell (do they do cells for DT?).
The better fix is to check the parameters for the damage type that is the last damage source: i.e fire damage that has been set to not hurt us and apply the counter if that subtype of fire_DoT is the last damage type.
function ApplyDamage(enemy, damageSource):
# Retrieve the coefficient directly from the damage source class
damageCoefficient = damageSource.getCoefficientFor(enemy.type)
# Apply damage only if the coefficient is greater than zero
if damageCoefficient > 0:
enemy.health -= calculateDamage(damageSource) * damageCoefficient
# Update the last damage source to track the type of damage
enemy.lastDamageSource = damageSource
function OnEnemyDeath(enemy):
# Increment the kill counter if the last damage source was fire_DoT
# and the fire_DoT (damage source) coefficient for operatives is set to 0
if enemy.lastDamageSource == fire_DoT and enemy.lastDamageSource.getCoefficientFor(operative) == 0:
increment ImmolationGrenade_kill_counter
This way they don’t need to check all enemy positions every time an immolation grenade is thrown. Not sure how their codebase looks and if that is how they track damage, but they should have some way to check the parameters on damage types that kill enemies, hopefully?
Regardless, this is all guess work, the thing to check is with pre-emptively throw your immolation grenade and get a hoard to run through it after it detonates by a 2-second margin. I’ll test myself today.
EDIT: Checked it by playing myself: couldn’t confirm my theory; seemed to not count bruiser who entered late in some cases, could have been killed by something stray from another player but unsure.