Patch 4.1: Addon Messages Will Be Filtered

(Locked)

85 Human Death Knight
1580
sorry about asking in this forum but idk how to play a rfc i have my account im level 85 but idk if i need to download the ptr client also i want to know hot play when the download finish pls help im new in the forums
85 Undead Warlock
4190
Just curious if this is linked to the "possible" damage /dps/ threat meter, as well as the "possible" boss mod feature that "may " be coming?.If so.. would be a welcome change
85 Undead Warlock
4190
Just curious if this is linked to the "possible" damage /dps/ threat meter, as well as the "possible" boss mod feature that "may " be coming?.If so.. would be a welcome change

03/11/2011 07:01 PMPosted by Iriel
Cool, the way this is described means that as long as any addon that's using addon messaging registers the prefixes it needs, it should otherwise be able to behave exactly as it does today. (It should also reduce event clutter for developers who're working on something but turn off other event-spammy addons when in guilds/parties with people still running those addons).


Just a thought then?.. are the devs designing the instance/dungeon around the fact that most.. not all .. have certain mods? and maybe designing those instances/dungeons a bit harder?
85 Blood Elf Rogue
8675
Is there going to be a way to turn filtering off.. Some people want to see everything that happens in the addon channels...
90 Human Paladin
14125
03/14/2011 11:14 AMPosted by Kaivax
The soft server cap is strictly for add-on author testing/debugging.


What does this mean? What sort of testing/debugging might make use of a 64-prefix server-side soft cap?

Also, I still don't understand the reason for a 512-prefix "hard" client-side limit and a 64-prefix "soft" server-side limit. If N prefixes are registered where 0 < N < 65, then first the server and then the client will filter all but those N prefixes. If 64 < N < 513, then the server filters nothing while the client again filters all but N prefixes. If 512 < N, then the server filters nothing while the client filters all but the first 512 prefixes registered. Finally, if the "soft cap" is raised above 512 and 512 < N < new soft cap, then the server filters all but N prefixes while the client again filters all but the first 512 prefixes registered. And if new soft cap < N, then once again the server filters nothing while the client filters all but the first 512 prefixes registered. In short, it seems as if the server-side limit is always irrelevant; the client-side limit does all the work. Stated differently, the number of prefixes available to be processed by add-ons seems always to be either N or 512 (the client-side limit), whichever is smaller.
Edited by Protasm on 4/15/2011 12:58 PM PDT
90 Draenei Shaman
9660
04/15/2011 12:57 PMPosted by Protasm
Also, I still don't understand the reason for a 512-prefix "hard" client-side limit and a 64-prefix "soft" server-side limit.


In the same post you quoted, Kaivax mentions that the server-side cap can be increased through a hot fix. Having the limiting factor be adjustable in real time allows Blizzard more control over the server-side cap should live feedback suggest that 64 is insufficient. Conceivably, Blizzard would also be able to change the limit to a "hard" cap with a hot fix.
80 Night Elf Hunter
580
Yet the server-side cap is not a limiting factor at all? It seems the end result on the client side is the same with or without the server-side cap.
Community Manager
It looks like some authors are starting to look at this change on the PTR. This is good!

From these posts it sounds like the rules are understood, but perhaps there's a bit of misunderstanding of the deep magic here.

The client side cap is intended to create a list of registered prefixes for sending up to the server. The list cannot grow unchecked, so the cap is set to a high value(512). We do not expect end-users to actually hit it.

The server side is the real throttle. We originally thought it would be a “hard” cap (ie: any prefixes over this value[64] would be dropped).

But feedback was that it would be too constraining that way. So the design was changed to a “soft” cap (ie: we filter up to the cap[64], but after exceeding the cap we stop filtering). So if you have registered 65 prefixes you will get ALL messages sent to you, regardless of whether it was registered or not. The server side cap can change based on how we see the system progressing.

Please feel free to reply in this thread if you have any further questions or concerns.
90 Worgen Druid
8535
04/16/2011 06:59 AMPosted by Borogove
Yet the server-side cap is not a limiting factor at all? It seems the end result on the client side is the same with or without the server-side cap.

Yes, the end result SHOULD be the same, the only difference is if the server has to send a lot of messages or only the ones you want. It's a bandwidth-saving mechanism (and the client normally won't have to filter out lots of excess messages either, so could save some CPU time on the client side as well).

Behavior of what messages are seen after filtering should be identical regardless of the server-side cap, that allows them to change it if it would improve performance without breaking anything.
36 Draenei Paladin
240
awesome... Can't wait to play with more folks like this!
Synérgy just might be my group for this!
85 Blood Elf Death Knight
12530
Thanks Daciana that helps

also reporting this for sticky
85 Human Paladin
9470
Thank you very much for the excellent questions and further discussion.

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.


Just curious from a software engineering standpoint...

Why on earth would you not be loading the cap values from a server side table thus removing any need for client patches just to tweak this value... (same for any other values stored static on the client side that may need tweaking from time to time for that matter)?

Dynamic Robust Software Engineering 101...
- Technical Support
90 Human Warrior
18580
this seems buggy. Even if a prefix is registered, and you verify it with /dump GetRegisteredAddonMessagePrefixes() often times you won't get addon messages from other users of addon who's prefix is also registered, i'ven oticed this behavior with a few mods, it's like server is still filtering com traffic despite your prefix.
90 Undead Priest
12090
It Would Be Cool[tm] if the error reporting dealing with prefixes were extended just a teensy bit. Right now I'm seeing the occasional

Prefix is too long

error... but the error message doesn't say what the too-long-prefix *is*, which means tracking down the addon(s) causing trouble is going to be a pain.
Edited by Farmbuyer on 4/26/2011 10:43 PM PDT
- Technical Support
90 Human Warrior
18580
probably an addon not actually updated, just getting auto registered by acecomm using it's old prefix, i haven't seen any updated addons doing this intentinoally.

do a /dump GetRegisteredAddonMessagePrefixes()

see what addons did register, then process of elimination.
04/26/2011 09:14 PMPosted by Omegal
this seems buggy. Even if a prefix is registered, and you verify it with /dump GetRegisteredAddonMessagePrefixes() often times you won't get addon messages from other users of addon who's prefix is also registered, i'ven oticed this behavior with a few mods, it's like server is still filtering com traffic despite your prefix.


I'm seeing similar issues. We're using an addon for loot bidding and at points it would just stop receiving messages. What seemed to work was we had everyone logout and log back in and it started working again, but during the course of the raid the problem kept reappearing.
- Technical Support
90 Human Warrior
18580
i noticed same problem, with DBM, ORA3 and our loot mod, all which register prefixes properly, and syncing works for a while, then server just goes blah and starts filtering messages again until the user relogs. i'm tending for the sake of testing to schedule and run register prefix every 20 min or so to see if it keeps the channel open so to speak, a keep alive of sorts, to prevent the server from blowing it off after a period of time has passed.
I too notice the same problem with the server seemingly filtering prefixes which are registered. It seems to reliably happen every time I zone, and fixes itself after a /console reloadui
This topic is locked.

Please report any Code of Conduct violations, including:

Threats of violence. We take these seriously and will alert the proper authorities.

Posts containing personal information about other players. This includes physical addresses, e-mail addresses, phone numbers, and inappropriate photos and/or videos.

Harassing or discriminatory language. This will not be tolerated.

Forums Code of Conduct

Report Post # written by

Reason
Explain (256 characters max)
Submit Cancel

Reported!

[Close]