WoWInterface - Chat message colours

WoWInterface (https://www.wowinterface.com/forums/index.php)

- General Authoring Discussion (https://www.wowinterface.com/forums/forumdisplay.php?f=20)

- - Chat message colours (https://www.wowinterface.com/forums/showthread.php?t=48725)

Chat message colours

Hey all, Happy Christmas!

Just a quick question...

Does anyone know of a simple way to obtain the colour of the most recently shown text in the ChatFrames?

I have a function in my addon which makes a frame 'pulse' when a new message is received, kinda like:

Lua Code:

ChatButton.Pulse = function(self)
  self.fadeStep = ( (self.pulseIntensity * 2) / (self.pulseDuration * GetFramerate()) );
  self.isFading = nil;
  self.pulseTexture:SetTexture(1, 1, 1); -- [color="Red"]to match chatType colour[/color]
  return ( self.pulseIsEnabled and (not self.alpha) ) and self:SetScript("OnUpdate", self.OnUpdate);
end

This doesn't really relate to the question I guess, but the onupdate code is:

Lua Code:

ChatButton.OnUpdate = function(self)
  self.alpha = self.isFading and ( (self.alpha or 0) - self.fadeStep ) or ( (self.alpha or 0) + self.fadeStep );
  if ( (self.alpha >= 0) and (self.alpha <= self.pulseIntensity) ) then
    return self.pulseTexture:SetAlpha(self.alpha);
  elseif self.isFading then
    self.alpha, self.fadeStep, self.isFading = nil, nil, nil;
    return self:SetScript("OnUpdate", nil);
  end
  self.alpha, self.isFading = self.pulseIntensity, true;
end

Thanks in advance for any possible guidance :)

Aanson

It depends on what messages you want to listen to. If you don't care about what is added, just do a hook on ChatFrame:AddMessage.

If you need to know the actual message type (rather than just what color the message was printed in) you will need to either (a) use chat filters or (b) hook ChatFrame_MessageEventHandler. Both suffer from the same problem, in that both will get you every single chat message, whether or not it's set to show in a specific frame, or any frame, so you'll have to figure that out yourself.

Code:

local eventToCategory = {}



local function SaveLastMessageType(frame, event, ...)

        local category = eventToCategory[event]

        -- This maps eg. "CHAT_MSG_PARTY_LEADER" to "PARTY"

        -- which you can look up in ChatTypeInfo etc.

        

        -- Insert code here to figure out whether this frame

        -- should display this category, and return out if not.

        

        frame.lastMessageType = category

        -- Now you can reference this value in your other scripts.

end



for category, events in pairs(CHAT_CATEGORY_LIST) do

        for i = 1, #events do

                local event = "CHAT_MSG_" .. events[i]

                eventToCategory[event] = category

                ChatFrame_RegisterMessageEventFilter(event, SaveLastMessageType)

        end

end

Thanks very much. The event filtering function is just what I'm after.

Out of interest, see if I was just looking for the colour used for the last message, is there a simple way of going about that?

Do what ravagernl suggested several posts up:

Code:

local lastR, lastG, lastB

hooksecurefunc(ChatFrame1, "AddMessage", function(self, message, r, g, b, ...)

    lastR, lastG, lastB = r or 1, g or 1, b or 1

end)

That's great to know, thanks.

I need to know the message type (ChatTypeInfo) and the Chat Frame it was posted to.

I can hook the AddMessage function of each ChatFrame to establish the latter.

Cheers :)

If you need that, just use a filter function, as in the code I'd posted previously; you can get the color from ChatTypeInfo, as detailed in the comments in that code. You do not need to hook multiple functions and deal with tracking messages between them.

Yeah, I like the idea of simply hooking ChatFrame_MessageEventHandler too. I think I may be able to accomplish everything with that one hook. I'll put something together and find out.

Quote:

Originally Posted by Aanson (Post 290554)

Yeah, I like the idea of simply hooking ChatFrame_MessageEventHandler too. I think I may be able to accomplish everything with that one hook. I'll put something together and find out.

Don't hook CF_MEH. Just use the "filter" system that Blizzard put into the game for exactly this purpose. >_<

Quote:

Originally Posted by Phanx (Post 290593)

Don't hook CF_MEH. Just use the "filter" system that Blizzard put into the game for exactly this purpose. >_<

I implemented a function using event filters very much like the one suggested in your first post. It worked well, but like you'd said in that post, I still needed to get round the issue of working out which chat frames (if any) the message would be displayed on.

I should have said all this in my initial post, but (although I know that event filtering can be used for other things) the feature I'm adding doesn't need to filter chat messages (in-fact, it doesn't even need to know the content of the message). It's simply an alert feature for when a particular type of message is received. A sound will be played and the chat button will 'pulse' the colour of the chat message. It also auto-undocks the chat window (this is all dependent on user settings).

When I say auto-undock, I'm not referring to undocking a ChatFrame from GENERAL_CHAT_DOCK. It's a feature of my chat module which essentially allows the user to show/hide all chat frames within GENERAL_CHAT_DOCK with a hotkey.

In order to work properly, the function requires:

1. A guarantee that the message will actually be displayed.

2. The event (firstly so that I can get the message event category via CHAT_CATEGORY_LIST which I can then compare to user preferences and secondly, so that I can get the r, g, b values for the message).

3. The chat frame(s) on which the message will be displayed.

After a good bit of experimentation, I have eventually settled on just hooking each chat frame's 'OnEvent' handler. To avoid unnecessary processing (to prevent the code from being read for config/system events), the first line of the hooked function is:

Lua Code:

if ((strsub(event, 1, 8) ~= "CHAT_MSG") or (not self.isDocked)) then return; end

I've found that this works well, because due to the system already implemented in Bliz's ChatFrame.lua, each particular event will only fire for chat frames which are registered to receive them.

I know that if I added a filter, I could retrieve the channel name (arg9) and work out which frames receive that channel, but I'm hoping that that won't be necessary.

The obvious downside to hooking OnEvent is that my function will bypass not only the user-created filters, but also MessageEventHandler which will result in false positives. I'm going to be testing it a lot to see what kind of impact this has.

Just so you know, I don't think for a second that this is the perfect way to handle what I'm attempting to achieve so any suggestions which encompass all of the function's requirements above are always welcome.

Chat filter functions receives the [chat]frame as the first argument and also MessageEventHandler is called as a result of OnEvent, so I don't believe you gain anything by hooking OnEvent directly.

What if AddMessage is called like this:

Code:

:AddMessage("|cffff0000Hello.|r")

That hook won't know about that red. Also, what if the message has multiple colors in it? Which is "right"?

Quote:

Originally Posted by Lombra (Post 290682)

Chat filter functions receives the [chat]frame as the first argument and also MessageEventHandler is called as a result of OnEvent, so I don't believe you gain anything by hooking OnEvent directly.

MessageEventFilters have nothing to do with frames, so the chat frame isn't it's first argument (event is). The filter doesn't need to know which frame (if any) a message will be displayed on. It just provides the ability to return out of CF_MEH early before it starts calling AddMessage to appropriate chat frames.

Quote:

Originally Posted by pelf (Post 290734)

What if AddMessage is called like this:

Code:

:AddMessage("|cffff0000Hello.|r")

That hook won't know about that red. Also, what if the message has multiple colors in it? Which is "right"?

What's "right" is whatever colour has been chosen for any given message type. Eg for vanilla, guild chat is green, party blue, whisper pink etc etc. The function I've written provides a visual representation of what type of message has been received, so it doesn't matter if a message has 1 or 10 colours in it.

The only relevant colour is the one which has been chosen by the user to represent the chat type being displayed. Your example would default to Channel1 which would not be monitored.

Quote:

Originally Posted by Aanson (Post 290756)

http://wow.go-hero.net/framexml/1768...Frame.lua#2840

Quote:

Originally Posted by Lombra (Post 290758)

http://wow.go-hero.net/framexml/1768...Frame.lua#2840

But that points to CF_MEH which is where 'self' is coming from. I know that MessageEventHandler is passed with chat frame as it's 1st arg. Filters don't. If you check out ChatFrame_AddMessageEventFilter (event, filter) line 3193 of ChatFrame.lua, you'll see what I'm talking about.

Quote:

Originally Posted by Aanson (Post 290757)

The only relevant colour is the one which has been chosen by the user to represent the chat type being displayed. Your example would default to Channel1 which would not be monitored.

Well, if all that's actually needed is what channel the last message came through, isn't there a much easier way to do that? I also wouldn't immediately expect that someone would refer to channels as "colors".

I'm pretty sure that I've found a good way of getting everything I need now, using Ravagernl's suggestion.

Lua Code:

local frame;
for i = 1, NUM_CHAT_FRAMES do
  frame = _G["ChatFrame"..i];
  frame:HookScript("OnEvent", function(self, event, ...)
    self.lastEvent = (self.isDocked and MONITORED_EVENTS[event]) and event;
  end);
  hooksecurefunc(frame, "AddMessage", function(self, message, r, g, b, ...)
    if (not self.lastEvent) then return; end
    -- do my thing...
  end);
end

That way I have a guarantee that the message will actually be displayed. It should be reliable because self.lastEvent will always be obtained immediately before AddMessage gets called.

Cheers all :)

Quote:

Originally Posted by pelf (Post 290760)

I think there's been some confusion. Blizzard set up channel colouring precisely so that people would associate colours with channels, so I'm not really sure what you mean. The channel the message is displayed on isn't all I need either. You may want to read prev comments.

Anyhoo, I've sorted it now.