Error running OnDamage script in Entity

[Rama]

This error keeps flooding logs by thousands of instances, and may be related to random crashes. I've never been able to figure out the cause. It happens at random to any unit in the game. What could this error be related to?

Example:

warning: Error running OnDamage script in Entity ura0304 at 2c2e9808: ...gramdata\faforever\gamedata\lua.nx2\lua\sim\unit.lua(5560): attempt to call method `GetArmy' (a nil value)
         stack traceback:
         	...gramdata\faforever\gamedata\lua.nx2\lua\sim\unit.lua(5560): in function `OnDamage'
         	...\gamedata\units.nx2\units\ura0304\ura0304_script.lua(33): in function <...\gamedata\units.nx2\units\ura0304\ura0304_script.lua:28>
         	[C]: ?
         	...ta\faforever\gamedata\lua.nx2\lua\sim\projectile.lua(647): in function `DoDamage'
         	...ta\faforever\gamedata\lua.nx2\lua\sim\projectile.lua(388): in function <...ta\faforever\gamedata\lua.nx2\lua\sim\projectile.lua:331>

[Resin_Smoker]

@rama

Question Does your mod change unit.lua at all? (Please post it as a zip attachment)

I ask because the error is indicative of the unit or projectile in question being destroyed when self:GetArmy() is being called.

Its good practice to apply for many scripts is to do a "self" check before calling a function.

Example...

if self and not self:BeenDestroyed() then
   self.MyArmy = self:GetArmy()
end

This will 100% ensure that the unit is good before the function is called to avoid a nil value. Granted it's not always needed and in many case applying it everywhere can be overkill. Its just one of those things that's added when a potential problem arises or is expected to for a give situation.

Note: Just off of my head, URA0304 is a standard Cybran air unit... Its most likely the bomber and not a custom unit, so that does eliminate the custom unit shenanigans.

-Resin

[Ctrl-K]

checking for self is excessive

[Resin_Smoker]

@ctrl-k

In most instances yes... Sometimes though it can't be helped, as its not 100% possible to death proof a script.

[Rama]

@resin_smoker

The mod is AI Wave Survival. The script can spawn hundreds to thousands of units per wave, so the error shows for any type of units that can be spawned in a wave. I played one game that had over 8000 such errors before crashing after 1 hour in.

The spawn script first runs

unit = aiBrain:CreateUnitNearSpot(rspawn, posX, posZ)

It checks if the unit was created, and if not, tries again using

unit = CreateUnitHPR(rspawn, aiBrain:GetArmyIndex(), posX, terrainAltitude, posZ, 0, 0, 0)

It then checks if the unit exists with the following code, before modifying things like the units health, veterancy, and damage.

if unit and unit ~= nil and not unit.Dead then

It then runs an attack script for each unit, which chooses a random target from a list, and issues orders where:
pUnit = Random Target
aUnit = Spawned Unit

local pUnit = nil
  if Random(1, 3) <= 2 then
    if Random(1, 2) == 1 then
      pUnit = RandomEnemyUnitsLandDefenseList(self)
    else
      pUnit = RandomEnemyUnitsLandEconomyList(self)
    end
  else
    if Random(1, 3) == 1 then
      pUnit = GetClosestEnemyNearAntiNavy(self, aUnit)
    else
      pUnit = RandomEnemySubsForAntiNavyList(self)
    end		
  end
  if pUnit and not pUnit:BeenDestroyed() then
    IssueClearCommands({ aUnit })
    local VECTOR3
    local pUnitPos = pUnit:GetPosition()
    if Random(1, 8) <= 6 then
      IssueMove({ aUnit }, pUnitPos)
    else
      if Random(1, 4) <= 3 then
        IssueMove({ aUnit }, pUnitPos)
        WaitSeconds(Random(20, 60))
        IssueClearCommands({ aUnit })
      end
      IssueAggressiveMove({ aUnit }, pUnitPos)
      WaitSeconds(Random(48, 78))
      repeat
        WaitSeconds(12)
        if aUnit:BeenDestroyed() or pUnit:BeenDestroyed() then
          break
        end
        if Random(1, 12) == 6 then
          break
        end
      until pUnit:BeenDestroyed() or pUnit == nil
      WaitTicks(20)
      if aUnit ~= nil and not aUnit:BeenDestroyed() then
        IssueClearCommands({ aUnit })
      end
    end
  end

Actually writing out all the code, it looks like the error might be from having orders issued to units that may already be dead, as I forgot to add checks for when I have a delayed order.

And what would be a faster way to check if a unit is dead or not, if I wanted to optimize the code a little?

[Resin_Smoker]

Units spawned may take 1-2 ticks before becoming fully initialized. In theory it should be instantaneous but I know from experience that it's not. Hence, it maybe nessisary to add a small delay between the request for the unit, and your checks to confirm its existence. While also placing a limit on the number of units spawned in at any given moment to keep the overhead down.

[Jip]

@Rama what other mods are you running? Your mod does not hook the unit class and there's no reference to GetArmy at line 5560 in the base game.

[Rama]

@jip

The modlist I was using when playing was:

ACU Boost 1.5x (Increases all ACU stats by 1.5x)
AI Wave Survival
50% Air Crash
All Factions Quantum Gate
BlackOps FAF: ACUs
AntiNuke 50% Cost
Half Commander Upgrade Costs
Hardened T1 Point Defense (Adds new T1PD with 4x health)
Hive Engineering Stations for All
No Friendly Fire
Reclaim Turret
Wreck Reclaim 33%
1.3x Build Range

And this would be the replay # with the crash, though I don't know if it is related to the error.
#22741098

[Rama]

@resin_smoker

Units are spawned in batches, but there is no wait between when a unit is created and when it is checked if it is dead or not. One player likes to host games with waves as large as 3500 units spawned per wave. Adding a 1 tick delay on such waves would add up to 350 seconds to spawn the entire wave.

[Resin_Smoker]

@rama but have you localized the error yet?

[Rama]

@resin_smoker

Not yet! I did find a few things I could optimize, though.

[Resin_Smoker]

After re-reading all the above posts I was thinking... Rather than issue orders to unit, why not have the units retrieve or ask for orders? At least this way, they'd be alive and fully in play when orders are given.

Oh and those 3rd party mods just compound things as you've no way of knowing the source of the errors. Hooks, upon hooks upon merges that make the error log useless.

[Rama]

@resin_smoker

I finally got around to running a test without extra mods enabled. Looks like the error is mod related. I would guess it is related to the No Friendly Fire mod, as that mod is the only mod that affects all the units.

[Resin_Smoker]

@rama but that's an assumption unless the log supports it.