Patch 4.1: Addon Messages Will Be Filtered

UI and Macro
03/11/2011 7:38 PMPosted by Naidi
Is there a possibility of getting an UnregisterAddonMessagePrefix?


I've already noticed that reloadui clears the list. Why is unregistering necessary?

03/11/2011 7:38 PMPosted by Naidi
Also, will the default UI access RegisterAddonMessagePrefix from a call stack that needs to be secure (action bars, unit frames, etc)?


I didn't see any calls to that function in FrameXML.
Is there a possibility of getting an UnregisterAddonMessagePrefix?


I've already noticed that reloadui clears the list. Why is unregistering necessary?

Also, will the default UI access RegisterAddonMessagePrefix from a call stack that needs to be secure (action bars, unit frames, etc)?


I didn't see any calls to that function in FrameXML.


Sounds good. Time to get to work on a no-script addon for message spam.

I have setup a CurseForge project for those interested.
http://wow.curseforge.com/addons/addon-spam-filter/
Thank you very much for the excellent questions and further discussion.

03/11/2011 7:38 PMPosted by Naidi
Is there a possibility of getting an UnregisterAddonMessagePrefix?


At this time we don’t really see a need for an unregister function. If one arises we can add that functionality. Right now we wanted to mimic add-on loading/unloading.

03/12/2011 12:19 AMPosted by Xinhuan
Also, the client has a 512 prefix limit but the server only recognizes the first 64?


The difference between the client cap(512) and the server cap(64) are to allow us to raise the server cap (if we needed to), without a client patch.

03/12/2011 12:19 AMPosted by Xinhuan
What happens exactly if 513 prefixes are registered?


The client has a hard cap (ie: once full it will not accept any more prefixes).

03/12/2011 12:19 AMPosted by Xinhuan
What happens exactly if 65 prefixes are registered ?


The server cap is currently soft. If you exceed the server cap you will get all add-on messages (ie: just like it has always worked up to now).

The soft server cap is strictly for add-on author testing/debugging. It is not intended that an add-on would purposefully hit the soft cap in order to get "old functionality". If we see this system being abused we will make the server cap a hard cap, and limit the number of prefixes for all clients.
What will happen when a message is sent with a prefix that has not been registered?

SendAddonMessage("NotRegistered", "Test message", "GUILD")

Will the message be sent and automatically register the prefix?
Will the message be sent but not register the prefix?
Will the message fail to send?
^^^^^^^^^ Orthath approves!
I did some quick testing and found that just calling SendAddonMessage(...) without registering first will silently fail. This is what I did, works both in current patch and in the PTR.


if RegisterAddonMessagePrefix then
RegisterAddonMessagePrefix("PREFIX_1")
RegisterAddonMessagePrefix("PREFIX_2")
end


In 4.0.6 RegisterAddonMessagePrefix doesn't exist, so it's nil. In 4.1 the function does exists, so the prefixes get registered.

This works fine, however I'm still very much a noob when it comes to AddOn development, so there's probably be a better way to do this.

What will happen when a message is sent with a prefix that has not been registered?

SendAddonMessage("NotRegistered", "Test message", "GUILD")

Will the message be sent and automatically register the prefix?
Will the message be sent but not register the prefix?
Will the message fail to send?
does anyone in here use LUI?
03/12/2011 12:19 AMPosted by Xinhuan
Is there both server- and client- side filtering or only server-side in each of these cases? "The server has a 64 prefix limit. If you exceed this limit your client will not filter any messages." doesn't make sense to me.

It's clearly both - the server filters to reduce bandwidth; if you go beyond the 64 prefix limit, the server doesn't know if you might want it or not, so it sends everything on and the client does the filtering.
03/14/2011 2:18 PMPosted by Gelgamak
I did some quick testing and found that just calling SendAddonMessage(...) without registering first will silently fail. This is what I did, works both in current patch and in the PTR.


Are you sure the message doesn't get sent and fails silently? Did the receiving end register for the prefix?
03/15/2011 9:44 PMPosted by Xinhuan
I did some quick testing and found that just calling SendAddonMessage(...) without registering first will silently fail. This is what I did, works both in current patch and in the PTR.


Are you sure the message doesn't get sent and fails silently? Did the receiving end register for the prefix?


I'm currently downloading the PTR to test this. Would anyone be willing to help me test this?
03/15/2011 9:44 PMPosted by Xinhuan
Are you sure the message doesn't get sent and fails silently? Did the receiving end register for the prefix?


Well, you can send messages to yourself via whisper. I tried that.

SendAddonMessage("PREFIX","Testing","WHISPER","Gelgamak")
@Gelgamak

That is correct for whispers.

Here is my proposed test for checking if unregistered prefixes really are sending outbound message:
  • Party of N persons
  • Persons 1,...,N-1 are registered for message prefix "FOOBAR"
  • Person N sends a "PARTY" ("RAID" if N>5) message with a prefix of "FOOBAR"
  • Do persons 1,...,N-1 receive the message?
03/16/2011 5:13 PMPosted by Gelgamak
Are you sure the message doesn't get sent and fails silently? Did the receiving end register for the prefix?


Well, you can send messages to yourself via whisper. I tried that.

SendAddonMessage("PREFIX","Testing","WHISPER","Gelgamak")


Yes, but you obviously wouldn't receive it unless you registered for the prefix. So how do you know the message really got sent or not? You need 2 people to test this (and I can't get on the PTR due to the closed beta account bug).
Now this puts me in an odd spot. I have an addon that has an event trace. In that, you can 'export events' to other people with the same addon. The event name is in the prefix, and the arguments are in the message portion.

Unfortunately, there is nearly 1000 lines of code including event-specific hyperlinks (for descriptions). Is there any chance that the immense amount of addons that get visibly 'broken' in many ways will give us more of a chance to have the old functionality stick around?
Now this puts me in an odd spot. I have an addon that has an event trace. In that, you can 'export events' to other people with the same addon. The event name is in the prefix, and the arguments are in the message portion.

Unfortunately, there is nearly 1000 lines of code including event-specific hyperlinks (for descriptions). Is there any chance that the immense amount of addons that get visibly 'broken' in many ways will give us more of a chance to have the old functionality stick around?


Then, you are going to have to modify your code such that your addon only uses 1 prefix, and put the event name along with the arguments in the message portion. On the receiving end, just extract the event out of the message string and modify it back to its original form and pass it along to whatever 1000 lines of code that uses it.

It's really not difficult, just a slight change to the send/receive protocol of your addon, and the rest of the addon doesn't have to know or care about it.
Official Nerd Thread! Rejoice to all that understands the first post!

Join the Conversation

Return to Forum