Core Concepts

SYNQ Objects

Understanding SYNQ objects and how to work with units, players, and game objects

SYNQ Objects are intelligent tables containing attributes and functions used to easily get information about and interact with units, players, and other objects in game.

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

Key Features

  • Static SYNQ objects always available for common units (target, focus, etc.)
    • You can make an amazing routine using mostly these
  • Object lists are filtered arrays of SYNQ objects by type (e.g., enemies, friends, objects) generated and returned each frame they are referenced

Accessing Object Data

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

Attribute Example

target.hp

Function Example

target.isUnit(focus)

Empty Objects

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

  • object.castTarget - Returns the destination target of a spell cast as a SYNQ object
  • object.target - Returns the object's target as a SYNQ 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 SYNQ objects.

Proper Existence Checks

if target.enemy then
    -- Now we know the target exists and they're an enemy - safe to proceed with enemy-specific logic
end

if target.combat then
    -- Now we know the target exists and they're in combat - safe to check combat-related attributes
end

Problematic Patterns

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
    -- This is not a proper existence check!
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! Always check existence first.
end

Important Notes

  • Receiving true from most boolean 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

Next: Learn how to create and use Spell Objects for your rotations.