This bug is with the ZK mod. unit_is_on_fire.lua
Saktoth's reversion has changed:
AddUnitDamage(unitID,t.fireDmg*CHECK_INTERVAL,0,t.attackerID, t.weaponID )
to:
AddUnitDamage(unitID,t.fireDmg*CHECK_INTERVAL,0,t.attackerID, t.weaponDefID )
t.weaponDefID in this one is nil (not initialized)
The bug happens due to the AddUnitDamage SyncCrtl triggering the callin UnitDamaged. t.weaponID in the current stable is derived from the original weapon that set the unit on fire (it's the same as the weapon).
Since the weaponID is passed to AddUnitDamage, which triggers UnitDamaged, this weaponID ends up in the weaponID parameter for the callin. Since the original weapon passed the
---- if (flamerWeaponDefs[weaponID]) then
check, this weaponID passes as well. Which triggers the setting on fire code again, refreshing the endFrame timer -> results in units burning forever.
Sak's reversion changed weaponID in the AddUnitDamage to "nil" essentially and flamerWeaponDefs[nil] isn't true, thus it doesn't trigger and units stop burning forever.
One way to fix it would be to check if the unit is already on fire and then check if the damage received from the callin is exactly
fireDmg*CHECK_INTERVAL
and the attackerID and weaponID is identical to the one already remembered.
If those are all true, it doesn't run the check.
This would only prevent units being hit by the same attacker, with the same weapon, dealing exactly the same damage as one tick of fire damage... from being put on fire that frame; which can be rare enough to be ignored.
