What are they?#

Basically tables, containing attributes & functions#

• Used to easily get information about and interact with units, players, and other objects in game.

All awful objects with an existing underlying unit will have all of the expected attributes and functions available for you to access.

There are a number of static awful objects always available for use for common units such as target, focus, etc. You can make an amazing routine using mostly these.

Object lists are filtered arrays of awful objects by type e.g, [enemies, friends, objects] generated and returned each frame they are referenced.

We access attributes by referencing them, and functions by calling them.

• This is an attribute: target.hp

• This is a function: target.isUnit(focus)

Empty objects#

Empty objects are a shell, containing only isUnit. They are only generated by functions which generate an object, such as these, when there is no relevant underlying object:

• object.castTarget : Returns the destination target of a spell cast as an awful object

• object.target : Returns the object's target as an awful object

• Tip: This is so you can always rule out things like object.castTarget.isUnit(healer) without the need to redundantly check for existence of the castTarget.

Existence checking#

You should always check if an object exists before attempting to query more information about it. It makes no sense to check something like object.distance < 15 if there is no object, right? Plus, some functions may just be entirely missing from empty awful objects.

if target.enemy then
  -- now we know the target exists, and they're an enemy.
end

if target.combat then
  -- now we know the target exists, and they're in combat.
end

if not target.combat then
  -- ⚠️ We still don't know if the target exists or not, we only know that if they do exist, they aren't in combat. ⚠️
end

if target.hp < 30 then
  -- ⚠️ This will cause a "graceful failure" if the object doesn't exist. It won't break your routine, but the code here may or may not run, based on the comparison type. What we know for sure is it's not working as we intended! ⚠️
end

• Receiving true from most bool attributes, such as object.enemy or object.friend also proves existence, so you don't need to redundantly check existence in other ways if you are already doing it with another "bool must have value" statement.

You cannot do math comparisons on nil (empty) values in Lua, and a lot of attributes return numbers.

Most number attributes will return default number values when object does not exist to cause a graceful failure that can later be fixed with our debugging tools.

You should always do a proper existence check anyways before anything else, otherwise your following logic is rendered completely arbitrary, and things will not be running for the reason you intended.