Authors CurseForge

Alright, I went ahead and added new *_GUID_* events (to essentially mirror all of the unit events) and changed the way *_UNIT_* events trigger by making sure each possible unitID gets its own event, rather than the the first one found.

That being said (and to quote Adirelle), are all of the *_UNIT_* events going to be useless in light of the new *_GUID_* events? Regardless, I already have the GUID converted to a unitID (in order to use UnitAura) at that point, so removing the *_UNIT_* events wouldn't really do much. :neutral:

It's really just the difference between:

function MyAddon:LUC_GUID_*(eventGUID, ...)
  if UnitGUID(self.unitid) == eventGUID then
    ...
  end
end

and

function MyAddon:LUC_UNIT_*(eventUnitID, ...)
  if self.unitid == eventUnitID then
    ...
  end
end

Although I guess this just applies when you have a unitID you're looking for. I suppose if someone just wanted to "announce" when any unit was affected by something the *_UNIT_* events work better, but that seems sort of useless.

Quote from Adirelle

I'm curious : how do you select the spell ids ? It seems to be automated in some way.

I parsed all the spell/spelleffect DBC files and assigned the different aura modifiers arbitrary bitmask values in order to produce a table with a structure of "[spellID] = effectMask" (which makes things incredibly simple). However, a side effect of this is that it needs to be updated with each patch to make sure it's information is current, but this was the only feasible way I could find to ensure every effect in the game was accounted for properly.

Quote from Adirelle

By the way, as a single game entity (one GUID) can have several unit tokens, I'm not sure the *_UNIT_* events are relevant.

The real reason unitID's are being thrown around is because I have to use UnitAura to help test whether a unit has lost or gained a mod.

There are currently two undocumented events (LUC_GUID_GAIN_AURA and LUC_GUID_LOST_AURA) and if those suit you better I can also add LUC_GUID_*_MOD events as well (I'll just go ahead and do it anyway).

Quote from Adirelle

Or you should fire them for every unit tokens that match the GUID. I mean that from the PoV of an unit frame developper, I could think I could just register LUC_UNIT_GAIN_MOD and LUC_UNIT_LOST_MOD for each of my unit frame and then simply test if the unit argument matched my frame argument to update. But if the event was only fired for "player" but not for "raid5" which is also the player, only one of the two frames would be updated.

That's an excellent point. I'll change it to make sure it triggers events for all possible unitID's rather than the first one found.

A library which provide tools for detecting adverse effects on units (such as those that cause you to lose control of your character). Is currently configured for use with WoW version 4.0.

Includes:

• Individual API's used to indicate whether a specified unit is Banished/Charmed/Confused/Disoriented/Feared/Frozen/Horrified/Incapacitated/Polymorphed/Sapped/Shackled/Asleep/Stunned/Turned/Disarmed/Pacified/Rooted/Silenced/Ensnared or has simply lost control of their character.
• Can differentiate between mainhand/offhand/rangedslot disarms.
• Can create effect masks which can be used to query whether a unit has all or some of the desired effects (rather than using the individual API's).
• Callback events for when a unit has effect modifiers applied or removed.

Edit:
As a talking point, I left out slow (melee/cast speed mods), enraged, wounded (ms effect), shielded (ex. PW:S), and invulnerable. If anyone would find these useful I can add them.

Edit: I went ahead and added 'ENRAGE' and 'WOUND' as new possible effects.