Get an Epic Experience with Premium

2.4: Combat Log Changes

While there's no real info yet on major 2.4 changes -- other than Sunwell knowledge -- which has been talked about for months now, Slouken posted quite the sneak peek at the combat log changes today.

Iriel has a new Upcoming 2.4 Changes list going in the UI & Macros forum, and Slouken kicked it off in grand fashion with information about some of the combat log changes. This isn't a simple update to functionality here either -- we're talking a complete overhaul that will make quite a few very cool things possible.

Slouken wrote:

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, ...);

%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");


.

New API functions:

CombatLogResetFilter()
CombatLogAddFilter("events", "srcGUID" or srcMask, "dstGUID" or dstMask)
CombatLogSetRetentionTime(seconds)
seconds = CombatLogGetRetentionTime()
count = CombatLogGetNumEntries()
CombatLogSetCurrentEntry(index)
timestamp, type, srcGUID, srcName, srcFlags, dstGUID, dstName, dstFlags, ... = CombatLogGetCurrentEntry()
hasEntries = CombatLogAdvanceEntry(count)
CombatLogClearEntries()

Note that you can change filters on the fly and re-query previous combat log entries, which are retained for 5 minutes by default.

Keep an eye on Iriel's thread in the days and weeks to come -- there will no doubt be more information on the UI changes posted soon.

Comments

  • #1

    lots of work for the coders ^^

  • #2

    This is a really nice (and big!) change. Instead of using heavy parsers and a lot of in-game communication via messages addon-between, things will get smaller, faster and neater.
    Hopefully more people will understand how to develop threat/DPS/healing meters etc. now too - so you'll have more choices available out there...

    :)

  • #3

    Yes, as soon as threatlib is re-written to work with the new combat log code, it means exactly that.

    Even with mobs with the same name, it will be possible to accurately track threat / dmg per mob.

    It should also make it much easier for various meters to accurately report healing from stuff like prayer of mending also.

  • #4

    Does this mean no more guess work when working with Omen and fighting multiples mobs with the same name? It will track them all independently instead of all as one?

  • #5

    Didn't blizzard say something about implementing their own version of a threat meter? Maybe this is when we'll see that functionality.

  • #6

    AddOns will be able to accurately track multiple targets at the same time for things like threat meters, dps parsing, etc. without any guess-work at all. :)

  • #7

    What's that all about?

  • To post a comment, please login or register a new account.

Popular News

Network News

Login to Curse

Don't have an account? Create One.

Get an epic experience with Curse Premium
  • Faster addon downloads
  • Premium-Only Beta Giveaways
  • Ad-Free Curse experience
  • Premium Curse Client
  • and many More Features
  • Learn More »

Minecontest - Win a 2013 Minecon Cape!