Authors CurseForge

http://svn.wowace.com/wowace/branches/LibGUIDRegistry-0.1/

This is 100% drycode that I came up with in the middle of the night.

The idea is that we have a library scan the combatlog to gather information before an addon needs it. A good example for this is FuBar_TopScoreFu which currently only works if you are targeting a mob of the same name as the one you did damage to so that it can gather UnitLevel and UnitClass. So if we scan the combatlog and use COMBATLOG_OBJECT_TARGET and COMBATLOG_OBJECT_FOCUS to map a GUID to a unitid we can query with normal functions then we can save that data for when its needed later. No data is saved between sessions.

The second part of the idea is that while we are doing this we can provide another useful feature. When we use COMBATLOG_OBJECT_TARGET, COMBATLOG_OBJECT_FOCUS, or COMBATLOG_OBJECT_RAIDTARGET? to map a GUID to a unitid or raidtarget we can then fire a callback to inform addons that we now know the GUID for that object and store it for query. An example where this could be used is Omen, if you have a group with mobs of the same name and you set raidtargets on them ahead of time (and nobody changes any raidtargets) you should be able to tab between them after they've been identified and know the GUID because of the raidtarget.

Like I said previously this is 100% drycode and not optimized. And I don't really know what I'm doing for optimizing the bitlib usage.

EDIT: Ok I've cleaned it up some and it should now only do stuff when it needs to (sorta, maybe some cool usage of CallbackHandler could make it only record stuff that addons want to know but not actually fire callbacks for those events?)

am not sure if this is an issue

but as far as i know only players will have unique GUID's that a persistent. all other GUID's are assigned on mob creation and are destroyed when it despawns. now i can see the potential situation where

you are playing for a long time without reloading/restarting.

and you keep killing the same mobs say for farming purposes. how do you handle the same GUID showing up multiple times for different mobs over the course of a single session. will there be some sort of timeout for each GUID because you can't rely on the person seeing the mobs death and as such its removal of the GUID.

I beleive the GUID will only be reused on a server restart or in a new instance.

Thanks for making this, was about to try doing somthing similar for the addon I was creating.

The library should gather info again every time your target or focus change so that stuff like level is always updated, and in the rare cases classification and name since there are some mobs that will change those (but I have no clue if the GUID changes, if you want to test that do the Giant Zapping quest in Feralas from the goblin at the dock).

This is still 100% drycode and any input on cleaning it up is welcome and encouraged.

Just a few small things:
Line 73:

lib.frame:UnregisterAllEvents()

(small "r")
Line 101:

lib.reg[GUID].fation	= select('2', UnitFactionGroup("target"))

(bracket fix)

and it might be a good idea to cache the raid and party ids as well

Hmm.. this library could also use raid addon communication to exchange pet/totem owner information with other raid members.
Whenever it notices a new pet/totem guid and can determine the owner (because it's the own pet) it could send it to others.

Yes that is a possible feature. I also did see somebody use a shaman elemental totem on the PTR and I'm fairly sure it said "Owner's Guardian" instead of "Totem's Guardian" so that would make things easier too.

Currently Threat-2.0 is using LibGUIDRegistry for unit to GUID mappings and that part of the API seems to be perty good. It has been recommended that the GUID to unit info part of the API is a bit excessive, requiring an API call for every bit of info requested and that a single API call to return all the info be added but I am unsure of how I want to do this. I would rather not return the data as arguments in an arbitrary order that could change if new data is added or parts of the API are removed. I think returning a table would be cleaner but that introduces the problem giving a direct pointer to the data so an addon could potentially alter the data, another option is returning a copy of the table but that would cause a new table to be produced every call to the API. Allowing the addon to pass its own table that it can recycle when it calls the API is an option to reduce table creation but that could create unnecessary complexity.

Quick reminder about storing _GUARDIAN guids. They act comparable to pet GUIDs except that you can possibly have more (for shaman totems for example).

I was thinking instead of:

:Fire("TargetGUIDSet", GUID)

do something like this instead:

:Fire("UnitGUIDUpdate", unit, GUID)

I'm seeing an error from this lib. I'm not sure where if the ultimate source of the problem is something in Omen2 (where I got the lib) or within this library but here is what I'm seeing:

When my warlock enslaves a demon and I change or clear my target before the spell cast completes, I get an attempt to concatenate nil error on line 158 of the library. If I do not change my target until after the demon is actually enslaved, everything works fine.

I'm new to the inner workings of WoW Addons so apologies if this post is in the wrong thread.

Can someone please tag this as a library on the SVN? It's showing up in updaters as having a category of "unknown" instead of "library".

Got these when I Mind Controlled mobs in heroic MgT:

BugSack: 147. [2008/04/25 18:00:05-1906-x4]: LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:158: attempt to concatenate a nil value
LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:115: in function `?'
LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:97: in function <...stry-0.1\LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:96>
 ---

BugSack: 148. [2008/04/25 18:01:55-1906-x4]: LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:158: attempt to concatenate a nil value
LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:114: in function `?'
LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:97: in function <...stry-0.1\LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:96>
 ---

Quote from Snago »

Got these when I Mind Controlled mobs in heroic MgT:




I get those mind controlling in Heroic Mechanar and normal MgT as well as Heroic MgT. Probably in more places, too, if I was on MC detail there.

Further info on the error - happens the first time I mind control any given MOB. If I re-MC the same MOB again, no error.

Sometimes i get following error with different classes/chars doing different things. Dunno exactly when it happens, but Baud Error Frame catches:

...stry-0.1\LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:158: attempt to concatenate a nil value
Count: 1

Call Stack:
[C]: ?
...stry-0.1\LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:158: in function `ProcessActor'
...stry-0.1\LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:114: in function `?'
...stry-0.1\LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:97: in function <...stry-0.1\LibGUIDRegistry-0.1\LibGUIDRegistry-0.1.lua:96>