Patch 5 . 0 . 4 / API changes Party and Group APIs . Several of the specialized Party and Raid functions and events have been consolidated . The naming convention cleanup is basically that : ' Party ' and ' Raid ' groups have semantically become just a ' Group ' ; and ' Party ' within a ' Raid ' has semantically become just a ' SubGroup ' . This effectively means that a Group is now a ' Group ' , whether raid or party . And a raids ' parties are now ' SubGroups ' . There were some return value type changes where the new GetNum functions return Lua ' true ' and ' false ' instead of ' 1 ' and ' nil ' , as is the growing trend with new fuctions after WoW went to Lua 5 . 0 . Similarly , the party and raid leaders have converged , while ' UnitIs . . ' covers ' Is . . ' now . Per removal of NumParty and NumRaid , both and were added . ' Group ' , as above , means any kind of group . And the coresponding events have merged . Instance and Zone API . With all the changes to the back - end for greater cross - realm functionality , instance and zone semantics have changed more on the client , causing API updates or further clarification of those to fit the new world and server constructs . This is a partial grand summary of the current state . The ' instance ' concept on the client is even more aligned now with the natural world load chunks , like when you have to see a loading screen . The basic containership for areas , from the servers persective , is instance / map ( whether its a " persistant " one or not ) - > zone - > sub - zone . Your base - line given tools are ( theorectically ) : " tooltip method works only if in zone , in a group , or on a list " Basically using the base API , thats it . . . unless a player is on your friends / bnet / guild / etc . . . list , or by using ' who ' API . The API for the Lua side has changed real meanings for these several times , towards what zone means . Normally in a regular ' home ' zone , you cant target or get updates for those outside your zone or a certain radius , so theres no normal mechanism as its irrelivant to the regular WoW UI needs . Furthermore this holds true across instances as well , as it would ( whether you think of instance in terms of ' specific map ' or ' running copy ' . ) Only if you have some other association does the client get updates or potentially have the data , without specific other request . However , like the friends list , updates occur for those in a raid , party , and presumably ' senarios ' , together . In this case the client intends to be able to recieve and cache info for that extended set of players , besides those in your zone . Other than there is no other API for accessing these , but there are workarounds . Specialization and Talent APIs . Several of the player Talent and Specialization functions have been renamed for clarity and to be more general , and more follow the naming for Party and Groups functions . Achievement APIs . There was some specialized Achievement API rework where function has been split , getting info by ' index ' or ' id ' seperately and less awkwardly . The parameter differneces are via ' criteriaIndex ' and ' criteriaID ' respectively . XML Lua Object References . In addition to the existing ' parentKey ' there are now a few more standard reference and related attributes . These ' key ' references are used to automatically set an object reference at runtime to a its LayoutFrame object instance , which would be directly avaible to the inline script functions and other functionality . Two of the new additions , realtiveKey and targetKey , allow setting targets based on object references directly from XML . On LayoutFrame : On Animation : On Anchor : Key Notation . General notation for ' Keys ' ( object refrences ) follows similar convention as the relative naming convention for ' names ' in LayoutFrames , like ' $ parentMyChildName ' . One difference is that each key reference for ' parentKey ' implicitly refers to the parent already . For example where the child frame will place a reference , named ' Child ' , to itself on the outer frame . However , an inner frame using ' relativeKey ' for an anchor must use ' $ parent . Child ' to refer to the same key on the outer parent , as otherwise it could be refering to a key placed on itself . For example where the second inner frame will be positioned the bottom of the first inner frame .