AddOn Studio

WoW:API UnitGUID: Difference between revisions

WoW Talk

WoW:API UnitGUID (source)

Revision as of 04:47, 15 August 2023

1,595 bytes added ,  15 August 2023
m
Move page script moved page API UnitGUID to WoW:API UnitGUID without leaving a redirect
m (Move page script moved page API UnitGUID to WoW:API UnitGUID without leaving a redirect)
 
(24 intermediate revisions by 22 users not shown)
Line 1: Line 1:
{{wowapi}} __NOTOC__
{{wowapi}}
Returns the GUID of the specified unit; works on both players and NPC.
guid = UnitGUID("unit")


Returns the GUID of the [[unitId|unit]] specified. Works on both players and NPC.  
==Arguments==
; unit : String - [[unitId|Unit ID]] of the unit to look up.


UnitGUID("[[unitId|unit]]")
== Returns ==
; guid : String - a string containing the hexadecimal representation of the unit's GUID, or nil if the unit does not exist.


== What does it all mean? ==
== Example ==
local name = UnitName("target"); local guid = UnitGUID("target"); ChatFrame1:AddMessage(name.." has the GUID: "..guid);


The GUID is a unique hexadecimal string for each unit in the game.
<big>'''Result'''</big>
Cyan has the GUID: 0x00000000012729FD


The strings always begin with '0x', which is the normal prefix for hexadecimal numbers. The '0x' prefix isn't actually part of the string, it's just to say "this is a hex string."
<big>'''Conversion to decimal?'''</big>


GUIDs are 64-bit numbers, and are far too long to convert to decimal numbers using lua's libraries as a whole. E.g. running tonumber(guid, 16) will produce erronous results.


=== Format for players ===
* The GUID is a simple number in the order characters are created. An older character has a lower number than a new.
It's possible that the first four to six digits are reserved and always has to be '0', which would limit the amount of characters able to be stored, but it's still a very very very high amount of available space. Reserving the first bits and always make them '0' would make it very easy to always identify a character.
Renaming and transfering to another server, or to another account gives your character a new GUID. It's possible that the GUIDs are stored globally, either per datacenter or even per region. It's also possible that there are some reserved bits in there which makes the number higher than it really is.
Restoring a character from backup is untested wether it restores the old GUID or not.
=== Format for non-pet NPCs ===
* The first two digits seems to be 'F1' or 'F3'.
* The next digit seems to always be '3'.
* The next three digits are unknown. It's usually '000'.
* The next four digits are the NPC id.
* The last six digits are the spawn counter.
I couldn't find any logic behind why some NPCs are 'F1' and some are 'F3'. From my testing it seems that 'F1' is more common, but there are some places where I found an 'F1' mob right next to an 'F3' mob. If you take the 'NPC id' and convert it to decimal you can check wowhead and see what NPC it is. See examples below.
=== Format for pets ===
* The first two digits seem to be 'F1'.
* The next digit is always '4'.
* The next seven digits are unknown.
* The last six digits are the spawn counter.
I haven't found any pet that starts with 'F3', like non-pet NPCs. It's possible that the seven digits that at this point are unknown are split into smaller pieces. I couldn't find any structure among them, but looking at non-pet NPCs I'd imagine that the NPC id is there somewhere but I couldn't find it.


== Spawn counter ==
== Notes ==
GUIDs are represented in WoW as hexadecimal strings beginning with '0x' -- this prefix is not part of the data, but merely signifies that what follows is a hexadecimal number. GUIDs are intended to provide a unique way to identify units; the following general rules apply: [http://forums.worldofwarcraft.com/thread.html?topicId=2968233433&postId=44201363100&sid=1#231]
* A monster has a single GUID from spawn until death (or despawn). When it respawns it gets a new GUID.
* Pets get a new GUID each time they are summoned.
* Monster and pet GUIDs can be recycled after server (or instance) restart.
* Players keep their GUID forever, and are unique even in cross-server battlegrounds.
* However, units that "transform" into other units may not switch GUID immediately.


Spawn counter is a unique number given all non-player mobs. It's a simple incremental number, instances and outside world are probably handled differently. The number in itself is not relevant, but combined with the rest of the string it always give this exact mob a unique identifier.
A GUID can be thought of as being composed of multiple pieces of data. Consider "'''0xAABCCCDDDDEEEEEE'''", where:
:; AA
:: unknown; Possible battlegroup identifier when used for players.
:; B
:: unit type, mask with 0x7 to get: 0 for players, 1 for world objects, 3 for NPCs, 4 for permanent pets (including Water Elemental), 5 for vehicles. Temporary pets (Treants, Spirit Wolves, Mirror Images, and Ghouls) are considered NPCs (3), even if talents or glyphs prevent them from expiring.
:NOTE: According to my personal analysis, I found that the number stands for players should be 8 instead of 0. I don't know if this is a newly update.
:NOTE: On the server Alexstraza I have seen the 1st 3 numbers be 040, meaning you must mask with 0x7 and 0=player, not 8.
:CORRECTION: If you have masked with 0x7 then the result CANNOT be 8. Masking 8 with 0x7 gives 0. It seems reasonable to conclude that the original poster is correct.
:; CCC
:: If the unit is a pet, CCCDDDD forms a unique ID for the pet based on creation order; if a world object, CCCDDDD is the object ID; otherwise unknown.
:; DDDD
:: If the unit is an NPC, this is the hexadecimal representation of the NPC id.
:; EEEEEE
:: If the unit is a player, this is a unique identifier based on creation order. Otherwise, this is a spawn counter based on spawn order.<br />(For players it can be 7 digits long, so that its DEEEEEE)




== An example of a GUID ==
=== Example: Determining unit type ===
local guid = UnitGUID("target");
local B = tonumber(guid:sub(5,5), 16);
local maskedB = B % 8; -- x % 8 has the same effect as x & 0x7 on numbers <= 0xf
local knownTypes = {[0]="player", [3]="NPC", [4]="pet", [5]="vehicle"};
print("Your target is a " .. (knownTypes[maskedB] or " unknown entity!"));


=== Example: Decomposing a GUID ===
We have a GUID: "0xF530004D2B008852".
We have a GUID: "0xF530004D2B008852".


From that we know the following: This is a non-pet NPC. It can't be a player because the first two characters are 'F5', players have '00'. The third character is not '3' for NPCs and not '4' for pets.
First of all, let's find out what kind of unit it is. Take the first three digits in the GUID, ie "F53" (or 0xF53 to show it's an hex value) and apply an AND mask of 0x007 to get 0x003. This GUID is for a normal NPC, neither a pet nor a player.


We can extract the Unit ID by taking the sixth to tenth digit and converting it to decimal form: "4D2B", or converted to decimal form "19755". A quick visit to wowhead shows that the NPC with that id is "Mo'arg Weaponsmith", [http://www.wowhead.com/?npc=19755]. All "Mo'arg Weaponsmiths" will have that id to identify them.
We can also extract the Unit ID by taking the seventh to tenth digit and converting it to decimal form: "4D2B", or converted to decimal form "19755". A quick visit to wowhead shows that the NPC with that id is "Mo'arg Weaponsmith", [http://www.wowhead.com/?npc=19755]. All "Mo'arg Weaponsmiths" will have that id to identify them.


The last six digits, "008852" is the spawn counter. There will never be two "Mo'arg Weaponsmith", possible even never two mobs in the outside world, with the same spawn number.
The last six digits, "008852" is the spawn counter. There will never be two "Mo'arg Weaponsmith", possible even never two mobs in the outside world, with the same spawn number. This spawn counter, combined with the rest makes it possible to always refer to exactly this "Mo'arg Weaponsmith", and not the one next to it.


== Speculations ==
A simple in game script command can be used to get the NPC ID from your target: ''Target NPC ID: 19755''
/run print("Target NPC ID:", tonumber((UnitGUID("target")):sub(-12, -9), 16))
More informative script: ''NPC ID("Mo'arg Weaponsmith") = 0x4D2B = 19755''
/run local a=strsub(UnitGUID("target"),7,10); print("NPC ID(\""..UnitName("target").."\") = 0x"..a.." = "..tonumber(a,16))


The value returned from players is how recent the player have been created. Someone with the number 1000 would be the 1000th created character on the server, a NPC would simply count up. Each NPC that respawns adds a number higher, so 4294967295 means that there have been 4294967294 NPC before that one that have respawned. Renaming does not change the player UnitGUID value so you can track players trough renames using this, unfortunately if you transfer you're character obtains a new GUID, the last value obtainable (as creating a new character). In instances spawned NPC/mobs return the same value, unlike outside a instance. Player pets keep their value when you despawn then spawn them back, so pets appear to have their own GUID counter like character GUID (creation) counter.
=== Cross-server and GUID "uniqueness" ===
Player GUIDs are local on a per-server basis, making the "global" scope to be bound to the specific server. Every time a character is created, a new GUID is assigned from a simple +1 counter and then given to that character. It should be noted that the act of transferring characters, either server to server, account to account, or even account to account while remaining on the same server will generate a new character GUID, because of how the process works (the character "ceases to exist" for a short period, and is then recreated). This act erases friend and ignore lists. Renaming a character does not trigger a new GUID, as that process is much simpler than a full character move.


Uniqueness is guaranteed in cross-realm battlegrounds by masking the player GUID with a server specific unique identifier, when needed.


== Returns ==
NPC GUID collisions have also been observed. It is unknown why or when in specific they occur, but differing mob types have had a NPC ID number which corresponded to an entirely different NPC. This is considered a very rare phenomenon.
<!-- List each return value, together with its type -->


:;GUID : Returns the unit GUID in hexdecimal.
== {{C-inline}} 4.0 changes to NPC ID ==
Along with the Live [http://www.wowwiki.com/Patch_4.0.1 4.0.1 patch (build 13164)], the NPC portion has moved 2 digits to the left, to <font color="#F6ADC6">CC</font><font color="#ADFF2F">DD</font> instead of <font color="#ADFF2F">DDDD</font>.  
*Before: (9th to 12th digit)
0xF13000<font color="#ADFF2F">73AB</font>06AE87,"King Varian Wrynn"
*After: (7th to 10th digit)
0xF130<font color="#ADFF2F">73AB</font>00001BB4,"King Varian Wrynn"


The NPC portion of this is 0x73AB in hex, and a NPC ID of 29611 in decimal.


== Example ==
Water Elemental is now a permanent pet and as such has an id of 4 instead of 3.
local name = UnitName("target"); local guid = UnitGUID("target"); ChatFrame1:AddMessage(name.." has the GUID: "..guid);
 
<big>'''Result'''</big>
Cyan has the GUID: 0x00000000012729FD
 
<big>'''Conversion to decimal?'''</big>
 
GUIDs are 64-bit numbers, and are far too long to convert to decimal numbers using lua's libraries as a whole. E.g. running tonumber(guid, 16) will produce erronous results.
Anonymous user
Retrieved from "https://addonstudio.org/wiki/Special:MobileDiff/17924...17949"