Error running OnDamage script in Entity
-
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> -
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() endThis 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
-
checking for self is excessive
-
In most instances yes... Sometimes though it can't be helped, as its not 100% possible to death proof a script.
-
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 thenIt 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 Unitlocal 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 endActually 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?
-
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.
-
@Rama what other mods are you running? Your mod does not hook the unit class and there's no reference to
GetArmyat line 5560 in the base game. -
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 RangeAnd this would be the replay # with the crash, though I don't know if it is related to the error.
#22741098 -
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.
-
@rama but have you localized the error yet?
-
Not yet! I did find a few things I could optimize, though.
-
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.
-
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.
-
@rama but that's an assumption unless the log supports it.
