Can't find a concrete answer. I guess AceComm uses ChatThrottleLib. And I understand that the addon sending the messages is protected from sending too much too quick. But what about the addon's receiving the messages? Can they get flooded and disconnect or does AceComm handle that end too?
The server does not disconnect you for receiving too many messages, only for sending them. In any case, addons cannot prevent the server from sending you a message, so even if AceComm throttled the rate at which it passed incoming messages back to addons, it would make no difference in the amount of bandwidth used.
If too many clients all at the same time send messages to the same reciepient, then that recipient will most likely get disconnected to to having their receive buffer filled (or rather the servers send buffer to that client is full). So, if an addon is designed to e.g. send a message a new player logging on and everyone in a large guild does that, new players would probably get disconnected as soon as they log on. The addon need to spread out the "hi there" message so the clients wont be sending them at the same time (or find another way to accomplish the message).
In GuildAds, this is handled by spreading out the messages in time (login "Hi there" message) and also in structure (clients A and B whisper C, clients D and E whisper F, clients C and F whisper G and G broadcasts a combined message. No clients is mass-messaged that way. Used for data searches.).
Well, if the addons were all adding the same message to guild chat (instead of sending the person a whisper) then everyone would receive the message, not just the recipient. Even if they're whispering the message, there's still no way for an addon on the recipeint's end to prevent those messages from being sent from the server to their client.
Also, I don't think there's any realistic scenario under which the number of messages one person receives from addons in the whisper channel (eg. send only to that person) is greater than the number of messages received by everyone over the guild or group channels (eg. sent to everyone), or even close to the number of messages seen in the Trade channel pre-4.0, which never caused anyone to disconnect.
Thanks for the answers. I'm looking into an idea that may, at times, be spammy. Most likely when a raid group is just forming and people are accepting quickly. Or if by some crazy coincidence a bunch of people log on at the same time. I have concerns about that as it's when most of the "Hey there!" ... "Oh Hi!" chatter would occur.
Well, do you expect a response to your addon message? I.e. when you log on and emit your "hi there" message, will your addon (if every client uses it) cause an automatic reply? Then just think about big guilds (200+ members if they even exist). You log on and send 1 message and receive 200 message back, all at the same time. This could disconnect you.
Here's the current "protocol" (using the term loosely). What are the best practices here? This WOULD be an in combat addon so I'm very concerned about issues. I'd like to know before I start worrying about code whether this is bound to cause issues or not.
Note that I do have a working prototype.
There are Senders (S's) and Receivers (R's)
R's listen to comm channel "R" and send on comm channel "S".
S's listen to comm channel "S" and send on comm channel "R".
R's and S's don't listen to the same channel they send on.
R's and S's are not activated unless in a raid.
All messages go through RAID or WHISPER, but mostly RAID.
In short, there are three messages:
INTEREST (sent from R's to S's when first joining a raid group, no messages sent in response)
EXIST (sent from S's to R's when first joining a raid group, an INTEREST message is sent in response to the S)
UPDATE (sent from S's to R's as often as every 1 second but only when certain in game events happen, no messages are send in response)
Here are more specific details if it helps...
When R's become active they:
Join the "R" comm channel.
Broadcast message to comm channel "S" indicating they have INTEREST in something.
When S's become active they:
Join the "S" comm channel.
Broadcast message to comm channel "R" advertising that they EXIST.
When S's receive the INTEREST message they:
Update internal data structures and identify what, if any messages need to be sent during the next message cycle.
On each message cycle all messages that need to be sent are done so via comm channel "R". Let's call these messages UPDATE.
Note: A message cycle is basically a one second timer.
When R's receive the UPDATE message they:
Update internal data structures but do nothing in return.
When R's receive the EXIST message they:
WHISPER message to the S who sent the message with an INTEREST message.
How many senders would at most be active at any given time?
40 would be the worst case scenario based on current raid sizes. With 40 receivers as well. Keep in mind each Sender could have quite a few items to keep track of, say 10 of them. So if all 10 "changed" then on the next message loop 10 messages would be sent out to all 40 receivers.
I'll stop being so secretive about the idea. It's a raid cooldown tracking addon concept using AceComm instead of using combat log events. I realize using addon comm has some drawbacks but it also has some benefits.
I'm still in the "is this a sound idea or not" phase so I appreciate all the help here.
40 senders broadcasting every second? Everyone would receive 40 messages per second? Do I understand this correctly? If so, your addon would scale horribly. The messages being broadcast should probably contain information to reduce the need to broadcast continuously.
Besides the initial handshaking, broadcasts would only happen every 1 second -IF- something needed to be broadcast. And I'm not sure how often that would be.
For example, if 40 receivers all wanted to track Guardian Spirit and Guardian spirit were on a 2 minute cooldown, the following would take place anytime a Sender uses Guardian Spirit:
1. Sender "A" uses Guardian Spirit: Message is sent by Sender "A" to the Receiver comm channel (message contains sender name, spellid and cooldown remainder).
2. All 40 receivers receive the message and start their own individual cooldown timer based on the message.
No other messages would be sent by this Sender for this spell unless the
cooldown duration for it changed dramatically (e.g. it got longer for some reason or it got shorter for some reason). Guardian spirit used to have a thing where it's cooldown would be two minutes if it didn't proc and 3 minutes if it did. It doesn't anymore, but presumably there are still spells like that.
Of course, that's just one spell. If there are 40 receivers/senders, and all senders use an ability requested by a receiver, then yes, 40 messages would be sent out at the same time more or less.
So for one spell it's not a big deal, the concerns are when there are a lot of spells, or more specifically, a lot of really short duration spells that are used on cooldown.
And I have to admit I'm not completely naive. I'm very suspicious of this idea! Mostly because I'm surprised it doesn't already exist in a mature form (I looked and looked and could not find something equivalent to what I want to do.....I haven't explained all the features btw).
The fact that it doesn't exist, makes me think there is a fundamental reason for it. Be it technical or otherwise.
This is really the same thing was what oRA does, and similar to what RaidCooldowns does. But oRA only tracks a few spells and RaidCooldowns uses a hybrid Comm/CLU approach.
So far the only answer I can find why it doesn't exist, is because it forces people to run addons to be useful. That's a darn good reason but it's the only one I've come up with.
And it's pretty much the only reason anyone needs. If you raided back in the days when threat meters required everyone to run them, or in a guild where everyone was supposed to have CTRA, oRA2, and/or a specific boss mod and the raid leader ran version checks all the time, you probably remember what a gigantic pain in the ass it was, and how much time was wasted trying to get every single person running the exact same version.
If your goal is to track the cooldowns of raid members' spells and abilities, or the duration of effects on raid members, the best approach is to watch the combat log, detect when the spell is cast or the buff applied, and then determine the cooldown or duration based on a hardcoded list modified by talent scanning as needed.
This works for the vast majority of spells and effects, and is a much better solution than relying on Player X to run an addon to tell everyone that he cast Innervate on Player Q; not only will Player X probably balk at having to run an addon, have trouble installing an addon, and/or forget to ever update an addon, but all of this information is already available locally from your own client through the WoW API.
The only things you need addon communication to track are cooldown reductions from glyphs (because there is no API for finding out which glyphs someone else is using) and the targets of casting spells (because there is no API for finding out the target of a spell being cast by someone else, until after the cast finishes and the spell actually affects the target).
Hmm yeah. It's disappointing to read and I'm trying not to get hung up on it :(
I've seen the code required to try and track the "weird" spells and it's complex, requires heavy combat log monitoring, etc.
Some of what I thought would be advantages of a message based approach were:
1. No CLU (at the expense of messages though)
2. No complex code surrounding weird cooldown timing/changes.
3. REALLY easy to track anything since we're not tied to CLU weirdness and/or limitations. It's as simple as a receiver sending over a spell id to a sender.
Guess you could sum all that up by saying it's very simple to code and the data would be very reliable +/- message lag (which I'm personally ok with).
I think I'm probably still going to work on this, and convince a couple healers to try it out with me. I've got no other projects :)
I honestly wanted it because I tank, I'm not happy with the features available in RaidCooldowns, and I REALLY want to know status of Guardian Spirit, Pain Suppression, Hand of Sacrifice, and one or two other external cooldowns without having to be so vocal about it in Vent.
Keep the feedback coming!
Oh btw, as far as features go (and some of this is already in my working prototype):
1. You can choose whether you want to receive and/or send to cut down on resources. I expect only tanks, healers, and raid leaders would actually have a use for it.
2. No spells are hard coded into the program, each receiver configures what spells it wants to monitor. If you look around at similar addons this is the biggest complaint (being hard coded into it)
3. It's smart about if people are dead, disconnected, or not in the zone.
As far as UI is concerned:
1. If Receiving you have a basic box with an icon for each spell you're tracking. In the center is a number showing "how many are available" (just like an aura's stack count for example). Below the icon is a timer which shows up if all people have used the ability and you need to know how long until one is available again (think battle res).
2. When you hover over an icon you'll see a tooltip with the status of each person who has that spell. It'll show their name, whether it's available, and it not how long until it's available again.
3. One of the nicer things is that it's not a bunch of bars with one bar per player per spell (and a generic bar at that). But if you're looking for a specific spell, you just look at the one icon and you can quickly know if it's available and if not when.
In short, you can get a running summary of the status of all people who have a spell, not just that it's on cooldown, but also how many are potentially available and the status for each player.
Seemed like a useful tool. Could this be done with CLU, yeah. I'm too optimistic and apparently too lazy :)
If you have any idea how much Internet bandwidth addons like Omen2 and some of the older versions of boss mods and even LibHealCmm used to take up.... That Blizz ended up implementing them to the game client directly.
It ended up being a little more trouble that I thought to keep the chatter down during initial communication. And I haven't had a chance to test it our in a real raid environment yet (only 3 users so far).
I got to play with some new stuff though. Tried getting ButtonFacade support but after a couple of hours I gave up. I was having issues with how ButtonFacade appears to reparent frames or some such. I "sort of" had it working but yanked the code out after spending too long.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Thanks. Probably an obvious answer.
In GuildAds, this is handled by spreading out the messages in time (login "Hi there" message) and also in structure (clients A and B whisper C, clients D and E whisper F, clients C and F whisper G and G broadcasts a combined message. No clients is mass-messaged that way. Used for data searches.).
Also, I don't think there's any realistic scenario under which the number of messages one person receives from addons in the whisper channel (eg. send only to that person) is greater than the number of messages received by everyone over the guild or group channels (eg. sent to everyone), or even close to the number of messages seen in the Trade channel pre-4.0, which never caused anyone to disconnect.
Note that I do have a working prototype.
There are Senders (S's) and Receivers (R's)
In short, there are three messages:
Here are more specific details if it helps...
When R's become active they:
When S's become active they:
When S's receive the INTEREST message they:
When R's receive the UPDATE message they:
When R's receive the EXIST message they:
40 would be the worst case scenario based on current raid sizes. With 40 receivers as well. Keep in mind each Sender could have quite a few items to keep track of, say 10 of them. So if all 10 "changed" then on the next message loop 10 messages would be sent out to all 40 receivers.
I'll stop being so secretive about the idea. It's a raid cooldown tracking addon concept using AceComm instead of using combat log events. I realize using addon comm has some drawbacks but it also has some benefits.
I'm still in the "is this a sound idea or not" phase so I appreciate all the help here.
For example, if 40 receivers all wanted to track Guardian Spirit and Guardian spirit were on a 2 minute cooldown, the following would take place anytime a Sender uses Guardian Spirit:
1. Sender "A" uses Guardian Spirit: Message is sent by Sender "A" to the Receiver comm channel (message contains sender name, spellid and cooldown remainder).
2. All 40 receivers receive the message and start their own individual cooldown timer based on the message.
No other messages would be sent by this Sender for this spell unless the
cooldown duration for it changed dramatically (e.g. it got longer for some reason or it got shorter for some reason). Guardian spirit used to have a thing where it's cooldown would be two minutes if it didn't proc and 3 minutes if it did. It doesn't anymore, but presumably there are still spells like that.
Of course, that's just one spell. If there are 40 receivers/senders, and all senders use an ability requested by a receiver, then yes, 40 messages would be sent out at the same time more or less.
So for one spell it's not a big deal, the concerns are when there are a lot of spells, or more specifically, a lot of really short duration spells that are used on cooldown.
The fact that it doesn't exist, makes me think there is a fundamental reason for it. Be it technical or otherwise.
This is really the same thing was what oRA does, and similar to what RaidCooldowns does. But oRA only tracks a few spells and RaidCooldowns uses a hybrid Comm/CLU approach.
So far the only answer I can find why it doesn't exist, is because it forces people to run addons to be useful. That's a darn good reason but it's the only one I've come up with.
If your goal is to track the cooldowns of raid members' spells and abilities, or the duration of effects on raid members, the best approach is to watch the combat log, detect when the spell is cast or the buff applied, and then determine the cooldown or duration based on a hardcoded list modified by talent scanning as needed.
This works for the vast majority of spells and effects, and is a much better solution than relying on Player X to run an addon to tell everyone that he cast Innervate on Player Q; not only will Player X probably balk at having to run an addon, have trouble installing an addon, and/or forget to ever update an addon, but all of this information is already available locally from your own client through the WoW API.
The only things you need addon communication to track are cooldown reductions from glyphs (because there is no API for finding out which glyphs someone else is using) and the targets of casting spells (because there is no API for finding out the target of a spell being cast by someone else, until after the cast finishes and the spell actually affects the target).
I've seen the code required to try and track the "weird" spells and it's complex, requires heavy combat log monitoring, etc.
Some of what I thought would be advantages of a message based approach were:
1. No CLU (at the expense of messages though)
2. No complex code surrounding weird cooldown timing/changes.
3. REALLY easy to track anything since we're not tied to CLU weirdness and/or limitations. It's as simple as a receiver sending over a spell id to a sender.
Guess you could sum all that up by saying it's very simple to code and the data would be very reliable +/- message lag (which I'm personally ok with).
I think I'm probably still going to work on this, and convince a couple healers to try it out with me. I've got no other projects :)
I honestly wanted it because I tank, I'm not happy with the features available in RaidCooldowns, and I REALLY want to know status of Guardian Spirit, Pain Suppression, Hand of Sacrifice, and one or two other external cooldowns without having to be so vocal about it in Vent.
Keep the feedback coming!
Oh btw, as far as features go (and some of this is already in my working prototype):
1. You can choose whether you want to receive and/or send to cut down on resources. I expect only tanks, healers, and raid leaders would actually have a use for it.
2. No spells are hard coded into the program, each receiver configures what spells it wants to monitor. If you look around at similar addons this is the biggest complaint (being hard coded into it)
3. It's smart about if people are dead, disconnected, or not in the zone.
As far as UI is concerned:
1. If Receiving you have a basic box with an icon for each spell you're tracking. In the center is a number showing "how many are available" (just like an aura's stack count for example). Below the icon is a timer which shows up if all people have used the ability and you need to know how long until one is available again (think battle res).
2. When you hover over an icon you'll see a tooltip with the status of each person who has that spell. It'll show their name, whether it's available, and it not how long until it's available again.
3. One of the nicer things is that it's not a bunch of bars with one bar per player per spell (and a generic bar at that). But if you're looking for a specific spell, you just look at the one icon and you can quickly know if it's available and if not when.
In short, you can get a running summary of the status of all people who have a spell, not just that it's on cooldown, but also how many are potentially available and the status for each player.
Seemed like a useful tool. Could this be done with CLU, yeah. I'm too optimistic and apparently too lazy :)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHermes
It ended up being a little more trouble that I thought to keep the chatter down during initial communication. And I haven't had a chance to test it our in a real raid environment yet (only 3 users so far).
I got to play with some new stuff though. Tried getting ButtonFacade support but after a couple of hours I gave up. I was having issues with how ButtonFacade appears to reparent frames or some such. I "sort of" had it working but yanked the code out after spending too long.