Its the only function that takes a GUID, however, and it only reports "static" properties, that is properties that will not change for this GUID. Which would kinda imply that a race/class/sex change will change your GUID ;)
Its used in the ChatFrame for Class Coloring, fwiw.
What do you try to do with the UnitGUIDs?
- the UnitGUID in WoW is a 64-bit hexadecimal string. do not use tonumber(). you will get trouble if you do this.
I was kind of interested in the UnitGUIDs of the EU Cata beta server ... also was wondering which characters were the oldest and which the newest.
I'm using tonumber() with strsub() as in: local sourceID = tonumber(string.sub(sourceGUID, 13, 18 ), 16)
- do not use excessive code execution in COMBAT_LOG*EVENT(s). minimalism rules.
- disable guid scanning/digging/catching in combat!
- simply save the whole UnitGUID and you can sort it easily.
- digging for UnitGUIDs on a test/beta realm is really useless. nearly all characters are created in a very small period of time. if you try to test code for testing purpose, okay, but ptr/beta servers are slow, really very very slow compared to live servers.
I know little about code optimalization/refactoring but I will post the code I use at the moment: Paste 2471
- it's not possible to get a creation date unless you link the UnitGUID with the information someone can see in the account management side (this is the only place where you can see _when_ an account! (not a char!) was created (date only, no time). nobody with brain would allow some external code dig data from the WoW account management side --- or you have a SendAddonMessage() addonbot that sends played time data to you (but played time is not creation date)...).
Well ehh I was also interested in when the character was made, but I guess somebody has to tell u when they made their character, or a SendAddonMessage() addonbot yes, or make characters myself to see between what date the Player IDs are. But .. thats going really far for a simple test addon isnt it
By the way, your GT100GCX also shows a date for the Player ID, is that the creation date?!
- check out GT100GCX aka 'Gnomish Top100 GUID Catcher Xtrem'. the current release version available here at wowace.com can catch up to 1000 UnitGUIDs per server (main purpose of this addon is to get old characters, and well i am currently doing a rewrite). in local tests i tried 5000, 10000 and even 250000(!!!): after digging nearly 1 year with 250000(!!!-one server only) i have not seen that much different UnitGUIDs on my server (and my server is one of the best visited and one of the oldest in europe). conclusion: your number of 3 million UnitGUIDs is not real, even on a ptr/beta server where people from the whole world join. you simply can not dig that much UnitGUIDs in such a short period of (ptr/beta) time. impossible!
- a high or low UnitGUID says nothing without a very large amount of comparable data and server-based experience.
sorry, don't know if this is offtopic or useful
I mean if the Player ID starts from 1, and it normally increments by 1, then my logic assumes that if I see a player with an ID of 3.200.000~ that there would be also 3.2 million Player IDs/GUIDS ... Anyway I'm a lua noob, so what u say is useful to me : )
while we're discussing GUIDs... I see that you can pull GUIDs out of combat logs... and from the code posted it looks like the 12th argument of chat events seem to be GUIDs too (although I can't find it mentioned in documentation... is this new?)
This has existed for quite some time (half year at least?). I found out myself from the /eventtrace.
Although, now WoW Programming and WoWWiki(changed June 24) already got it documented, but when I checked it, it wasn't yet in their API docs
1. If you have a only the GUID, you can't do anything with it. There is no WoW API that takes in a GUID.
Also have to quote Nevcairiel, thats not 100% correct. API SetItemRef also takes GUIDs, even though it isnt documented yet
(I think its actually added functionality from the Blizzard Combat Log AddOn by hooking)
-- Blizzard Combat Log AddOn
local oldSetItemRef = SetItemRef;
function SetItemRef([COLOR="DarkGreen"]link[/COLOR], text, button, chatFrame)
[COLOR="DarkGreen"] if ( strsub(link, 1, 4) == "unit") then
local _, guid, name = strsplit(":", link);[/COLOR]
if ( IsModifiedClick("CHATLINK") ) then
elseif( button == "RightButton") then
-- Show Popup Menu
EasyMenu(Blizzard_CombatLog_CreateUnitMenu(name, guid), CombatLogDropDown, "cursor", nil, nil, "MENU");
API SetItemRef Example:/run SetItemRef("unit:"..UnitGUID("target"))
You can replace the UnitGUID with any GUID, it doesn't have to be a "valid unitID handle", however you require to have seen the GUID recently(cached).
Kind of like Xinhuan said: "the GUID was in render distance, or in the combat log or chat events".
However, once the unit/player is cached, but out of render range, it would return the unit level as "??", and it won't return the guild name anymore. Name, Race, and Class would still return. Actually, a lot of variables are missing, like: "name", "text", "button", "chatFrame"; but it still works fine though without those variables.
You can even call it from an UI Escape Sequence. (those hyperlinks in the Blizzard Combat Log) UI Escape Sequence "unit" Example:/run print("\124Hunit:"..UnitGUID("target").."\124h["..UnitName("target").."]\124h")
...Thats pretty inaccurate. They are numbered sequentially, so while one could argue that the date/time plays a role there, saying "date/time based" implies that the actual date and time take part in calculating the GUID, which is wrong. It doesn't matter if you create a character now, or in one hour. As long as no other player creates one in that time, the GUID will be the same...
true. your explanation is mainly exactly what i try to say. eg. there are/were UnitGUID ranges [which was/were reserved ranges (eg. serverOne got 0x03100000AA192FE0 till 0x03100000AAE92FE0 serverTwo in the same battlegroup got 0x03100000AAE92FE1 till 0x03100000BEE92FE1 and than serverOne started again with 0x03100000BEE92FE2) in a very very small time frame (especially with patch 3.0 and 3.1 - and i bet there will be some when gobs/worgens (4.0) are released, but this is just a guess, because the 3.0/3.1 guid changes was much more dramatic)] ... what i tried to say was: every UnitGUID on a specific server is incremented (by 1 [_depends_]) because this depends on factors that nobody expect Blizz coders knows... (and: you never ever know if _you_ can catch such a UnitGUID!) ... but: a lower UnitGUID is _always_ an older character (date/time based [yeah not only!]) on a server!).
...I mean if the Player ID starts from 1, and it normally increments by 1, then my logic assumes that if I see a player with an ID of 3.200.000~ that there would be also 3.2 million Player IDs/GUIDS...
no. there is no correlation between a 'high' and a 'low' UnitGUID (btw: check my previous post here: the UnitGUID is a hexadecimal string, not a decimal one [hex=0-9a-f and starts with 0x0??...ok, lets say its a string thats starts 0x0?? ;) ... ok ok 3200000 is possible (for char ident) ... ]).
its obvious that this can not be true, because first of all you need to know the lowest (or nearly lowest) UnitGUID of your server(!!!). this is the base. you can only get a lowest UnitGUID by catching many many UnitGUIDs in a very very large period of time. than you need to know the preserved guid ranges (which definitly exists on live servers that are older than 3.0/3.1!). if you know this facts you can make some guesses about server population, but you can never know if ever character creation is incremented by 1...(like i said before this _can_ be the case, but it must not be the case...nobody knows, expect Blizz coders)
question for you on your combat log code...
local _, _, sourceGUID, sourceName, _, destGUID, destName, _ = select(1, ...)
lets say you're from Vekil'nash grouped with 4 other people.... one of whom is a guildie of yours called "Dogbreath" and another one is from another realm... "Catbreath" from Frostmourne
clearly each will have their own GUID... clearly a massive fluke if they happen to be the same one
but my question is: destName and sourceName... what format are they in?
"Dogbreath" & "Catbreath-Frostmourne"?
or "Dogbreath" & "Catbreath"?
or "Dogbreath-Vekil'nash" & "Catbreath-Frostmourne"?