This is a consolidated list of the announced (and sometimes observed) changes in the User Interface API's and functionality for the 2.4 release. Please note that this thread is to discuss the upcoming changes and any clarifications or features that are a direct result of those changes, or things which we've been asked to remind slouken of.

IMPORTANT: Off-topic or entirely redundant posts are liable to get deleted. It is however in everyone's best interest to not post them in the first place - We'd rather slouken could spend his time coding us cool things than moderating this thread!

Significant Changes
* The combat logging mechanism is completely overhauled with explicit data instead of text strings delivered to the UI. See slouken's post below for a sneak-peak at some of the current details. Highlights include detailed flags indicating relationship of involved units to player, unique identifiers for units with the same name within the combat log -- great for log analysis.

2.4 Changes - Concise List
2.4 Changes - Concise List
2.4 Changes - Concise List
2.4 Changes - Concise List

* The combat log range is now everything you can see.

* The In-game Interface Options screen is being revamped and the new architecture should allow AddOn authors to modify its contents without the taint issues presented by the current system. Additionally this system will contain an area for AddOn authors to present their own configuration options. Authors interested in this feature should be sure to experiment on the PTRs before patch 2.4 is released so that any issues can be surfaced and discussed. Basic details on how to use this system can be found in code comments in the 2.4 UIOptionsPanel.lua.

2.4 Changes - Concise List
2.4 Changes - Concise List

Font String Display
* Textures can now be included in FontStrings locally using a new | escape code: |T<path>:<width>[:<height>:<xOffset>:<yOffset>]|t
* Selected textures can also be included in Chat messages and sent to other users, the current available textures are represented in a form like: {star}

2.4 Changes - Concise List

Visual Settings
* There's a new cVar unitHighlights; 0 = no model highlighting with Alt-Z, 1 = model highlighting on with Alt-Z. (e.g. /console unitHighlights 1)
* Players can now toggle the display of Friendly and Enemy player names, as well as their pets and creations. You can toggle cosmetic pet names too. :)

(Continued...)

[ Post edited by Iriel ]

---

UI and Macros Forum MVP - Understand GC!

There is a new console variable in 2.4:

unitHighlights
0 = no model highlighting with Alt-Z
1 = model highlighting on with Alt-Z

e.g.
/console unitHighlights 0
/console unitHighlights 1

Combat Log Revamp!

In 2.4 the combat log is being completely reimplemented so that it sends events with arguments instead of text strings to the UI code.

It's still in development, so nothing is final, but here is a raw sneak preview:

-- Object type constants
-- Affiliation
COMBATLOG_OBJECT_AFFILIATION_MINE = 0x00000001;
COMBATLOG_OBJECT_AFFILIATION_PARTY = 0x00000002;
COMBATLOG_OBJECT_AFFILIATION_RAID = 0x00000004;
COMBATLOG_OBJECT_AFFILIATION_OUTSIDER	= 0x00000008;
COMBATLOG_OBJECT_AFFILIATION_MASK = 0x0000000F;
-- Reaction
COMBATLOG_OBJECT_REACTION_FRIENDLY = 0x00000010;
COMBATLOG_OBJECT_REACTION_NEUTRAL = 0x00000020;
COMBATLOG_OBJECT_REACTION_HOSTILE = 0x00000040;
COMBATLOG_OBJECT_REACTION_MASK = 0x000000F0;
-- Ownership
COMBATLOG_OBJECT_CONTROL_PLAYER = 0x00000100;
COMBATLOG_OBJECT_CONTROL_NPC = 0x00000200;
COMBATLOG_OBJECT_CONTROL_MASK = 0x00000300;
-- Unit type
COMBATLOG_OBJECT_TYPE_PLAYER = 0x00000400;
COMBATLOG_OBJECT_TYPE_NPC = 0x00000800;
COMBATLOG_OBJECT_TYPE_PET = 0x00001000;
COMBATLOG_OBJECT_TYPE_GUARDIAN = 0x00002000;
COMBATLOG_OBJECT_TYPE_OBJECT = 0x00004000;
COMBATLOG_OBJECT_TYPE_MASK = 0x0000FC00;
-- Special cases (non-exclusive)
COMBATLOG_OBJECT_TARGET = 0x00010000;
COMBATLOG_OBJECT_FOCUS = 0x00020000;
COMBATLOG_OBJECT_MAINTANK = 0x00040000;
COMBATLOG_OBJECT_MAINASSIST = 0x00080000;
COMBATLOG_OBJECT_RAIDTARGET1 = 0x00100000;
COMBATLOG_OBJECT_RAIDTARGET2 = 0x00200000;
COMBATLOG_OBJECT_RAIDTARGET3 = 0x00400000;
COMBATLOG_OBJECT_RAIDTARGET4 = 0x00800000;
COMBATLOG_OBJECT_RAIDTARGET5 = 0x01000000;
COMBATLOG_OBJECT_RAIDTARGET6 = 0x02000000;
COMBATLOG_OBJECT_RAIDTARGET7 = 0x04000000;
COMBATLOG_OBJECT_RAIDTARGET8 = 0x08000000;
COMBATLOG_OBJECT_NONE = 0x80000000;
COMBATLOG_OBJECT_SPECIAL_MASK = 0xFFFF0000;

COMBATLOG = ChatFrame2;

-- Process the event and add it to the combat log
function CombatLog_AddEvent(...)
	local info = ChatTypeInfo["COMBAT_MISC_INFO"];
	local timestamp, type, srcGUID, srcName, srcFlags, dstGUID, dstName, dstFlags = select(1, ...);
	local message = format("%s> %s, %s, %s, 0x%x, %s, %s, 0x%x",
 date("%H:%M:%S", timestamp), type,
 srcGUID, srcName or "nil", srcFlags,
 dstGUID, dstName or "nil", dstFlags);
	for i = 9, select("#", ...) do
 message = message..", "..(select(i, ...) or "nil");
	end
	COMBATLOG:AddMessage(message, info.r, info.g, info.b);
end

-- Save the original event handler
local original_OnEvent = COMBATLOG:GetScript("OnEvent");
COMBATLOG:SetScript("OnEvent",
	function(self, event, ...)
 if ( event == "COMBAT_LOG_EVENT" ) then
 CombatLog_AddEvent(...);
 return;
 end
 original_OnEvent(self, event, ...);
	end
);
COMBATLOG:RegisterEvent("COMBAT_LOG_EVENT");

There is a new console variable in 2.4:

unitHighlights
0 = no model highlighting with Alt-Z
1 = model highlighting on with Alt-Z

e.g.
/console unitHighlights 0
/console unitHighlights 1

---

Q u o t e:
I know it's not final code, but is select(1, ...) in there instead of ... for any particular reason?

---

Mostly for clarity, since this this is just sample code.

---

Q u o t e:

Slouken: Out of curiosity, will the old CHAT_MSG_COMBAT_... events still be sent, or will the new combat log event be the only one transmitted?

---

The old combat events are no longer generated. All existing combat log AddOns will need to be rewritten.

---

Q u o t e:
Slouken, your babies, can I have them please?

---

You'll have to work that out with my beautiful and pregnant wife. :)

---

Q u o t e:

Will there be a way to to get a name/level/whatever from a GUID? Something analogous to UnitName(GUID)?

---

Not at the moment, although you'll notice that the name comes with it in the event.

---

Q u o t e:

If enGB hasn't seen an event with 1234 yet, though, then they'll have no name to associate with 1234, and deDE can't pass across a name when asked for it, since they won't have the enGB equivalent. It'd be nice to get data via GUID to patch up holes like that, though admittedly, it won't be too critical so long as players have sane combat log ranges.

---

The combat log ranges are the same. You'll find that the GUID decodes into the type of creature, which can then be matched against data in the WDB cache ... not that anyone would ever try to decode that data. :)

---

Q u o t e:


Man, I've been sent deaf by the cheers. And I'm all the way over the other side of the planet!

---

*grin* You'll have to thank AlexanderYoshi who convinced me it was a good idea. :)

*laugh* I replied, but figured I oughtn't. :)

Oh, the combat log text file format changed as well, dumping the text format in favor of a comma separated event format for easy post-processing and analysis.

Remember, this is a moderated thread for discussing upcoming scripting API changes in the 2.4. patch. Off topic posts will be deleted.

I'm not sure why everyone is concerned about the "possession" stance. If I remember correctly, it's simply an actionbar page change, right?

Oh, right, so it's a bonus bar. There isn't already a state driver for the bonus bar? It seems like there should be... :)

---

Q u o t e:
I'm not sure if there is anything that currently is allowed in multiple types of bags. However there definitely are materials that are used by multiple professions. The API as presented would be a difficulty if those were ever made to go into more than one type of bag.

---

Hey Nayala, thanks for the suggestions.

We’ll no longer be adding GetContainerItemFamily and GetInventoryItemFamily. Instead we’ve added the following:

bagType = GetItemFamily(itemID | "name" | "itemLink");

When used with a container, this returns the type of container. When used with an item, it returns the type of container the item can go in.

Currently there isn't anything allowed in multiple types of bags. However, bagType is a bitflag, so GetItemFamily for something that could go in a quiver (bagType 1) and an ammo pouch (bagType 2) would return 3. A bag that can hold both arrows and bullets would also return 3.

--Zootfizzle

The content of the logs aren't changing, just the way the information is delivered. The person with Lifebloom really is healing themselves. :)

As of 2.4, PARTY_MEMBER_ENABLE and PARTY_MEMBER_DISABLE no longer provide information about which party member was enabled or disabled.

---

Q u o t e:

HA!!! I found it!
http://www.youtube.com/watch?v=aGpUX1FpA_I&NR=1
The question is at 5:50, the answer is at 7:30, with direct references to outfitter and itemrack. I'd have to do some extreme forum crawling to dig up the post mentioning this as a change in 2.4 specifically, but when else would it be implemented? WotLK?

And if you continue listening, there is mention of a built-in threat meter, which I presume goes hand-in-hand with the combat log changes that have been discussed at length in this thread.

---

These are planned features for WotLK, but haven't been started yet, so no promises. :)

Since the combat log filter is global, there is a new event that AddOns can register for:
COMBAT_LOG_EVENT_UNFILTERED
If you register for this event, you will receive the event regardless of whether it matches the current filter.

There is also a new optional ignoreFilter parameter for the following functions:
CombatLogGetNumEntries()
CombatLogSetCurrentEntry()
CombatLogAdvanceEntry()
Passing true as the last parameter allows you to iterate over combat log entries ignoring the filter.

Interface Options Revamp

Along with Patch 2.4 we will be releasing a revamped in-game Interface Options screen. Most of the systems that interact with the current Interface Options screen have seen some code changes as a result. The new architecture for the system should allow AddOn authors to modify its contents without the taint issues presented by the current Interface Options system.

Additionally, this new system will contain an area for AddOn authors to present their own configuration options to players with a custom heading, subcategories, and frames. I'd like to encourage authors interested in utilizing these features to try the new system on the PTRs before Patch 2.4 is released. Basic details on how to use this system can be found in code comments in Blizzard_InterfaceUI.lua.

Please be aware that AddOns that interact with the Interface Options screen, modify it, or change the way that its options affect other systems within the game will need to be updated with the release of Patch 2.4.

FYI, this is a moderated thread for technical discussion of upcoming features. Off topic posts will be deleted. :)

2.4.0 Guide to the New Combat Log

Hello Fellow UI Modders,

With the release of patch 2.4.0, we’ve made some enormous changes to the existing combat log. While this will result in some hard work now, it should be easier to maintain your AddOns in the future.

The feature we’re most proud of is the ability to filter your combat log. The combat log stores the last five minutes worth of raw combat events. Filters can be setup on multiple criteria, affiliation, ownership, etc. Any events that match the current filter are passed through the client via the COMBAT_LOG_EVENT message. The combat log filter is global. However, AddOns which want to parse all events the moment they happen can register for the COMBAT_LOG_EVENT_UNFILTERED message. This should allow all existing AddOns to still respond to combat events without a complicated middle-manager AddOn.
While the default combat log will only be setting 1-2 filters at a time, the WoW client supports many simultaneous filters. It’s possible to setup multiple filters to filter very specific source-target-event combinations. If a combat log event passes any of the filters, the COMBAT_LOG_EVENT event fires. This allows AddOns to define extremely specific settings we chose not expose in the base UI.

The new combat log will be coming with two text formats. One is the familiar, grammatically correct sentences with substitutions. The other is a terse format, containing the source, target, spell, action and result. There will be a number of ways to manipulate the formatting, from unit name coloring to coloring the damage numbers by their magic school. The settings used for these formats are stored in the Blizzard_CombatLog_Filters variable.

The result of the new terse format is that it’s very easy to write AddOns to modify or extend the format which ships with 2.4.0. In the formatting section, you can read up on a quick demonstration of how to convert the combat log to a “Nurfed” style combat log. While you can do a lot by just adjusting the settings within WoW, it’s also possible to provide an AddOn that changes the strings used to generate the Combat Log messages. This allows for more extensive formatting changes without re-writing the entire parsing engine. See the Formatting Section for an example.

The whole combat log also supports a new coloring model, based on context. While by default, entire lines are a single color, highlighting the most important details. The combat log also supports coloring just unit names, spells, actions and damage numbers. Spells and damage can also be colored by school. However, there are several features not exposed in the base UI that AddOns can use right away. These are event-specific coloring, unit coloring with greater granularity and the ability to customize the list of highlighted events.

There are several other formatting related features. You can enable timestamps which show the time that spell or attack happened. You can show or hide square braces, change formatting without refreshing the combat log and disable the display of raid icons. These features were too niche to go into the base UI, but can be easily exposed for power users. By now you’ve already thought of some features of your own and are ready to get to coding. So let’s jump straight to some examples.

From the designer:

Q: Does the new log system give us a way to distinguish between:

- Physical Melee. Autoattacks that deal physical damage that can be dodged, blocked, and parried but not resisted (e.g. autoattacks from some guy with a sword);

Yes. These are logged under the SWING_DAMAGE event with a school mask of 1 (Physical).

- Elemental Melee. Autoattacks that deal elemental damage that can be dodged, parried, and resisted but not blocked (e.g. autoattacks from Hydross the Unstable);

Yes. These are logged under the SWING_DAMAGE event with a school mask greater than 1 (Magical).

- Pure Spells. Elemental damage that can be resisted but not dodged, blocked or parried (e.g. Fireball); and

Yes. These are logged under the SPELL_DAMAGE event with a school mask greater than 1 (Magical).

- Melee Spells. Physical or elemental damage that counts as a spell but may be dodged, blocked, and parried; may or may not be resistable (e.g. Heroic Strike) ?

Yes. These are logged under the SPELL_DAMAGE event with a school mask of 1.



Q: How is the Water Elemental flagged in the summoner’s combat log?

A: The Water Elemental is flagged 0x1111. Mine | Friendly | Player-Owned | Pet. This means that if all Frost mages submit their combat logs, then the specific GUIDs for each Mage’s water elemental can be determined. Other Mage’s Water Elementals in the same raid are flagged 0x1112 (Same Party) or 0x1114 (Same Raid).

---

Q u o t e:

Just how dynamic are these GUIDs? For example, in any of the following situations, would a new GUID be generated?

---

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.

Additional change in 2.4.0:

The Raid UI now can display the range of players relative to you. The option to enable this is in the Party & Raid section of the UI Options.

---

Q u o t e:
We already have that, it's IsSpellInRange and CheckInteractDistance, and "In Range" is fairly vague given that can mean 10 different things.

---

Yes, but IsSpellInRange requires a spell action to be ready on a cursor before actually being able to give you the data. CheckInteractDistance is also for game objects.

Alexander is correct, there's a function called UnitInRange(unit) that returns a boolean based upon a static value (because we can't predict what spell you might want to cast) that is based upon Flash Heal/Cure range. So yes, it could return true incorrectly. We haven't quite built the AI that will predict the action of any player in every game situation... yet!

Kaythedree, this functionality is not in the Party UI. You, however, can make it yourself! =D

---

Q u o t e:
will we be able to change that static range or is it hardcoded?

---

This is a static value set within code. Though it would be cool to let you pass in a value, it might make writing bots that much easier. :)

New for 2.4.0
* Players can now toggle the display of Friendly and Enemy player names, as well as their pets and creations. You can toggle cosmetic pet names too. :)

New in 2.4:
icon = GetItemIcon(item)
This information is available if the item exists, even if GetItemInfo() returns nil.

---

Q u o t e:

HO-HO!!!!
Been asking for this for YEARS!!!!!!!!
http://forums.worldofwarcraft.com/thread.html?topicId=101150523&sid=1&pageNo=8#156
Thank you Slouken!!!!!!!!!!!!!!!!!!!!

---

It's been driving me nuts for years.

So, you're welcome.

:P

Embedded Textures in FontStrings
A new feature in 2.4 is the ability to embed textures inside FontStrings. This functionality works similar to embedding a hyperlink, and should allow AddOn authors a great deal more flexibility in using textures in conjunction with FontStrings.

The format for placing a texture inside a FontString is as follows:

|T<path>:<width>[:<height>:<xOffset>:<yOffset>]|t

If the height argument is omitted, the width will be used, resulting in a square texture.

Example:
ChatFrame1:AddMessage(“\124TInterface\\Icons\\Spell_Holy_WordFortitude:64\124t is the icon for Power Word: Fortitude”);

This will add a message to ChatFrame1 with a 64x64 texture for Power Word: Fortitude, along with the text “ is the icon for Power Word: Fortitude”.

Limitations:
At this time, to prevent potential abuse, raw texture links cannot be sent to other players. In order to allow players to send each other textures, we have added support for texture tags to ChatFrames and the Raid Warning frame. Texture tags are parsed out of messages added to these frames and replaced with appropriate textures.

Texture tags use the following format:

{star}

Currently there are only texture tags for raid icons. We may add more texture tags in the future.

Available texture tags:
{star}, {rt1} - Star icon
{circle}, {rt2} - Circle icon
{diamond}, {rt3} - Diamond icon
{triangle}, {rt4} - Triangle icon
{moon}, {rt5} - Moon icon
{square}, {rt6} - Square icon
{cross}, {rt7} - Cross icon
{skull}, {rt8} - Skull icon

HOWTO: Add new categories of options

The new Interface Options frames allows authors to place their configuration
frames (aka "panels") alongside the panels for modifying the default UI.

Adding a new panel to the Interface Options frame is a fairly straightforward process.
Any frame can be used as a panel as long as it implements the required values and methods.
Once a frame is ready to be used as a panel, it must be registered using the function
InterfaceOptions_AddCategory, i.e. InterfaceOptions_AddCategory(panel)

Panels can be designated as sub-categories of existing options. These panels are listed
with smaller text, offset, and tied to parent categories. The parent categories can be expanded
or collapsed to toggle display of their sub-categories.

When players select a category of options from the Interface Options frame, the panel associated
with that category will be anchored to the right hand side of the Interface Options frame and shown.

The following members and methods are used by the Interface Options frame to display and organize panels.

panel.name - string (required)
The name of the AddOn or group of configuration options. This is the text that will display in the AddOn options list.

panel.parent - string (optional)
Name of the parent of the AddOn or group of configuration options. This identifies "panel" as the child of another category.
If the parent category doesn't exist, "panel" will be displayed as a regular category.

panel.okay - function (optional)
This method will run when the player clicks "okay" in the Interface Options.

panel.cancel - function (optional)
This method will run when the player clicks "cancel" in the Interface Options. Use this to revert their changes.

panel.default - function (optional)
This method will run when the player clicks "defaults". Use this to revert their changes to your defaults.

EXAMPLE -- Use XML to create a frame, and through its OnLoad function, make the frame a panel.

MyAddOn.xml
<Frame name="ExamplePanel">
<Scripts>
<OnLoad>
ExamplePanel_OnLoad(self);
</OnLoad>
</Scripts>
</Frame>

MyAddOn.lua
function ExamplePanel_OnLoad (panel)
panel.name = "My AddOn"
InterfaceOptions_AddCategory(panel);
end

EXAMPLE -- Dynamically create a frame and use it as a subcategory for "My AddOn".

local panel = CreateFrame("FRAME", "ExampleSubCategory");
panel.name = "My SubCategory";
panel.parent = "My AddOn";

InterfaceOptions_AddCategory(panel);

EXAMPLE -- Create a frame with an okay and a cancel method

--[[ Create a frame to use as the panel ]] --
local panel = CreateFrame("FRAME", "ExamplePanel");
panel.name = "My AddOn";

-- [[ When the player clicks okay, set the original value to the current setting ]] --
panel.okay =
function (self)
self.originalValue = MY_VARIABLE;
end

-- [[ When the player clicks cancel, set the current setting to the original value ]] --
panel.cancel =
function (self)
MY_VARIABLE = self.originalValue;
end

-- [[ Add the panel to the Interface Options ]] --
InterfaceOptions_AddCategory(panel);

Tivs and Maul:

Thanks for the reports! These have been fixed for 2.4 release.

In 2.4, the behavior of the SetParent() function has changed. Previously, changing a frame’s parent would update its FrameLevel, but not change its children's FrameLevels. With the release of patch 2.4, changing a frame’s parent will update all its children's frame levels as well.

For example, Frame A is on FrameLevel 0. Frame B is a child of Frame A and is on FrameLevel 1. Frame C is a child of UIParent and is on FrameLevel 2.

Running Frame A:SetParent(Frame C) will now change Frame A’s FrameLevel to 3 (one higher than its parent, Frame C) and will change Frame B’s FrameLevel to 4 (one higher than its parent, Frame A).

---

Q u o t e:
Thanks. Still think it's a bug since 0 has meaning for this function so returning 0 just because the info isn't in the item cache is wrong. Function should return nil if it can't return the data I asked for.

---

Shefki, thanks for bringing this to our attention. The behavior of this function has been changed for 2.4 release. If the client does not have information for an item, it will now return nil instead of 0.

---

Q u o t e:
I posted this to the Test Realm forums, but thought maybe here was more appropriate...

The affected party Name for the SPELL_ENERGIZE line as below is incorrect. The guid is correct, referring to "Mara", but the name listed is "Jerierex", whose guid is different. The two previous lines establish the guids of the two, and are consistent with the rest of the log file.

Either that, or I'm missing something big :)

2/12 06:32:20.840 SPELL_DAMAGE,0x000000000055C520,Mara,0x518,0xF1300061AA0F9B6F,Unleashed Hellion,0xa48,26862,Sinister Strike,0x1,1269,1,nil,nil,nil,1,nil,nil
2/12 06:32:21.231 SWING_DAMAGE,0x0000000000569D9B,Jerierex,0x518,0xF1300061A90F9F2F,Abyssal Flamewalker,0xa48,169,1,nil,nil,nil,nil,nil,nil
2/12 06:32:21.231 SPELL_ENERGIZE,0x000000000055C520,Mara,0x518,0x000000000055C520,Jerierex,0x518,35548,Combat Potency,0x1,15,3

---

Nope, this was a bug that is fixed for the next test realm update.

---

Q u o t e:
One more: Just an inconsistency more than anything, but I figured you might change it now so it doesn't annoy too many others down the track :)

The first "Spell School" parameter is hex, the second where there is one is decimal.

---

Can you post specific examples? Environmental damage is already fixed for the next test realm update, are there any others?

Thanks!

The combat log range is now everything that you can see.

Added for 2.4:
guid = UnitGUID("unit")
Returns a string representing a unique identifier for the given unit. This is the same string that is used in the combat log to identify a unit.

---

Q u o t e:

Slouken, don't you go getting any ideas...he's mine! That is, unless I can have your babies...

---

I have plenty already, thanks! :)

---

Q u o t e:

Now what are the chances of a FEW(!!!) of the Unit*() functions accepting GUIDs? Just wanting informational ones like name, class, race, level, classification, creaturetype, creaturefamily, faction, sex, and buffs. Nothing like health, mana, castinginfo, or anything like that.

---

Hmm, I thought it was a little chilly on the way to the office today...

With the release of patch 2.4 we’re adding a new event, UPDATE_INVENTORY_DURABILITY.

This event will fire whenever the durability of an item in your inventory changes. UPDATE_INVENTORY_ALERTS has not changed, and is sent in conjunction with UPDATE_INVENTORY_DURABILITY when appropriate.

---

Q u o t e:

Perhaps a useful function for addons would be an enhanced form of CombatLogGetCurrentEntry() that included an additional parameter to specify the Unfiltered combat log

---

This is already implemented, and I believe was posted to this changes thread already...

---

Q u o t e:
and an additional parameter (or parameters) to specify the filter to apply. I think this would make sense

---

This is a little tricky, since the filter is actually a set of filters. :)
The intent with the "unfiltered" combat log is that you would run your own filtering on the return values from the function in the same way you handle them in the COMBAT_LOG_EVENT_UNFILTERED event. You'll notice that the return values from the API function exactly match the arguments to the event.

---

Q u o t e:
So going through combat logs, I see for some spells there is never a spell cast success message. In particular, i was looking for a spell cast success message for earth shield. Is there a reason we don't get messages for some spells?

---

Yes, auras don't currently have a spell cast success message, but this is planned for a future patch.

There are two new combat log events for the next test realm update:
SPELL_SUMMON
SPELL_CREATE
These are sent with the guid and name of the creature or object that is created by a spell (along with who cast it, naturally)

You're welcome! :)

In this case nil and 0 are interchangeable. I went ahead and converted nil to 0 for text log output.

---

Q u o t e:


Thanks for the change Slouken! How about the effective healing change? Is it at all possible?

---

Not at the moment, the client doesn't have access to that information.

---

Q u o t e:
Is it just me, or is the new combat log totally not picking up players dieing now? It worked fine on PTR, but now the UNIT_DIED event isn't firing for players dieing. So they're just not showing up - either in the ingame combat log or using /combatlog

---

This is fixed for 2.4.2. Thanks!

---

Q u o t e:
Every player GUID i've run across so far begins with 0x00, i've been trying (with success so far, but who knows if there are counterexamples, I'd love to see them) to use the upper bits of the GUID to determine what kind of GUID it is, right now I have:

0xF13 -- NPC
0xF53 -- NPC

0xF14 -- PET
0xF54 -- PET

0x000 -- Player

(I haven't figured out if there's any useful significance of the 0xF1 versus 0xF5 thing)

---

It's a player if the upper bits masked with 0x00f = 0x000
It's a creature if the upper bits masked with 0x00f = 0x003
It's a pet if the upper bits masked with 0x00f = 0x004

---

Q u o t e:

Is there any way to properly pass the GUID to APIs that currently use ("unit")? Even in a round-a-bout way?

---

No, and there are currently no plans for this. The scripting system is not intended to have complete knowledge of the surrounding area, only with units that you are directly interacting with.