Okay. I still don't see how enforcing a limit by kicking a player out is better than enforcing it by introducing chat delay, but it seems I'm the only one with that opinion, so I'll just yield here. After all, the whole reason for writing the library was to have lots people actually want to use it, so I really do have to win the popularity contest :-P
BigWigs sync messages are useless when they are delayes too long...
Okay. I still don't see how enforcing a limit by kicking a player out is better than enforcing it by introducing chat delay, but it seems I'm the only one with that opinion, so I'll just yield here. After all, the whole reason for writing the library was to have lots people actually want to use it, so I really do have to win the popularity contest :-P
BigWigs sync messages are useless when they are delayes too long...
Yep. Absolutely. This is a good reason to use ChatThrottleLib and send them in ALERT priority; they will not be delayed as long as we are not running a risk for kicking the player out of the game. It is not a good reason to ignore ChatThrottleLib altogether.
I just thought I'd post a small update to have it somewhere other than IRC logs:
Both AceComm and Telepathy (Sky's rewrite for 1.12) use ChatThrottleLib.
CTRA does NOT use it, and Cide fails to see the point in using a common throttler; he much rather keeps using his own throttler. Any argument that several addons using their own throttler will still cause an overload falls on deaf ears.
Yep. Absolutely. This is a good reason to use ChatThrottleLib and send them in ALERT priority; they will not be delayed as long as we are not running a risk for kicking the player out of the game. It is not a good reason to ignore ChatThrottleLib altogether.
Imagine you want to count Chromatic Drakonid kills. The 2 doors are too far apart, there's no way you can get the death messages from both sides. If a Chromatic dies on the left side, and 0.3 seconds later one on the right (=your side) dies. With a delay of roughly 0.2 seconds and 100ms latency you risk not tracking the kill on the left.
If you want to use the Shadow Flame warnings to start casting heals on the MT (with at least 2.5 sec casting time) every tiny bit matters... Edit: I'm not saying that is the best strategy to deal with shadow flames :p
In both cases no delay would be better, and a delayed message is about as usefull as none at all. I'd rather have the other users sorting their add-ons not to spam so much than making message timing even more unpredictable.
So what if someone with 500ms latency reports the kill and someone with 30ms ? Same problem. But since both sides usually have different names you could check for that ;9
One possibility would to send the timestamp of the kill with the sync message.. but then again you would need a precise server time.
So what if someone with 500ms latency reports the kill and someone with 30ms ? Same problem. But since both sides usually have different names you could check for that ;9
One possibility would to send the timestamp of the kill with the sync message.. but then again you would need a precise server time.
Chromatics still are called Chromatics, no matter what side they are :p
You're right, normal latency is bad enough. There's no way to guarantee every Chromatic is counted (because there's no unique ID, not everyone gets every kill message, there's no global time and there's no minimum time between 2 kills). That's less of a problem for the colours, since everyone on one side should be able to get all the "local" kill messages... For the Chromatics every bit of delay, both from latency and artificial, makes syncing less reliable.
It really takes a lot of data to be throttled. If someone is sending huge tables or something in the middle of Nef they probably shouldn't writing mods in the first place...
In both cases no delay would be better, and a delayed message is about as usefull as none at all. I'd rather have the other users sorting their add-ons not to spam so much than making message timing even more unpredictable.
I will re-iterate:
ChatThrottleLib will NOT CAUSE DELAYS UNLESS NECESSARY. None at all. Not even a little. If there's room to send messages without delaying, there is no delay.
While there is a base 1000CPS limit, ChatThrottleLib recognizes that there is a receive buffer at the server, and allows burst transfers up to 8KB without delays if recent traffic has been low
By declaring that your traffic is too important to pass through ChatThrottleLib, you're being totally ignorant of the fact that when the outbound pipe is full, It. Is. Full. It doesn't matter if your traffic wants to be real time. If you overload the outbound pipe, you kick the player off, and your traffic is not just not real time. It is NOT. At all.
I'd rather have the other users sorting their add-ons not to spam so much than making message timing even more unpredictable.
... by making addon authors use ChatThrottleLib even though they all feel that their traffic is important enough to kick players off in order to, oh, for example, keep an accurate count of Chromatics?
It really takes a lot of data to be throttled. If someone is sending huge tables or something in the middle of Nef they probably shouldn't writing mods in the first place...
Actually, that makes me think I should throttle bulk traffic further if the player is in combat. Not every addon wants to be bothered with checking what mob they're fighting before responding to e.g. a data transfer request from another player. E.g. another player nowhere near BWL.
ChatThrottleLib will NOT CAUSE DELAYS UNLESS NECESSARY. None at all. Not even a little. If there's room to send messages without delaying, there is no delay.
My problem is that it makes the timing unpredictable. You cannot know what other add-ons the user is running, and how long your messages might be delayed...
Quote from Mikk »
By declaring that your traffic is too important to pass through ChatThrottleLib, you're being totally ignorant of the fact that when the outbound pipe is full, It. Is. Full. It doesn't matter if your traffic wants to be real time. If you overload the outbound pipe, you kick the player off, and your traffic is not just not real time. It is NOT. At all.
Actually i said I'd prefer people being disconnected. I do notice the benefit of ChatThrottleLib, but I don't trust the average WoW player to pick "chat friendly" add-ons unless something makes them. Blizzard chose to disconnect them... Maybe a big fat error popup saying "you'd just have been disconnected because your outbound traffic is too high" would have the same effect.
Quote from Mikk »
I'd rather have the other users sorting their add-ons not to spam so much than making message timing even more unpredictable.
... by making addon authors use ChatThrottleLib even though they all feel that their traffic is important enough to kick players off in order to, oh, for example, keep an accurate count of Chromatics?
If people see a timer bar (like for Sartura's Whirlwind), they tend to rely on it. Depending on the "purpose" of that timer no bar at all might be better than a wrong one. That's why I think some time-critical events are better sent immediately or not at all. (Maybe they should have their own cathegory...)
Situation A) User has an assload of mods (3 damage meters, a threat meter, etc...) that all send tons of information and he decides "Hey, I'm going to install BigWigs since all the cool kids are doing it". To make this even more complicated lets say hes an dumb raid leader, and the main tank at that. Raid time comes and zomg, he keeps getting disconnected during boss-fights. He decideds "well, the only thing I recently changed is BigWigs, so this mod must suck!". He was kicked becuase BigWigs was sending the 'straw that broke the camel's back' so to speak. He tells his guild to not use BW becuase "it sucks".
Situation B) Same stupid user again has an assload of mods, this time they all use CTL. He decides "Hey, I'm going to install BigWigs since all the cool kids are doing it". Raid time comes, and oh noes! BigWigs messages seem delayed. He blames it on server lag and decides to deal with it.
Honestly, people who aren't bogging down their system with a ton of stuff are going to send the messeages immediatly regaurdless, becuase they have the space to send it. Also this ignorent-user is still going to recieve those sync messeages, on time, from the smart user. The ONLY things it's going to cause issue with is things like NefCount that are counting most/all users sending things instantly and acurately.
Given the two hypotetical situations, I'd rather see situation B.
Situation A) User has an assload of mods (3 damage meters, a threat meter, etc...) that all send tons of information and he decides "Hey, I'm going to install BigWigs since all the cool kids are doing it". To make this even more complicated lets say hes an dumb raid leader, and the main tank at that. Raid time comes and zomg, he keeps getting disconnected during boss-fights. He decideds "well, the only thing I recently changed is BigWigs, so this mod must suck!". He was kicked becuase BigWigs was sending the 'straw that broke the camel's back' so to speak. He tells his guild to not use BW becuase "it sucks".
Situation B) Same stupid user again has an assload of mods, this time they all use CTL. He decides "Hey, I'm going to install BigWigs since all the cool kids are doing it". Raid time comes, and oh noes! BigWigs messages seem delayed. He blames it on server lag and decides to deal with it.
Honestly, people who aren't bogging down their system with a ton of stuff are going to send the messeages immediatly regaurdless, becuase they have the space to send it. Also this ignorent-user is still going to recieve those sync messeages, on time, from the smart user. The ONLY things it's going to cause issue with is things like NefCount that are counting most/all users sending things instantly and acurately.
Given the two hypotetical situations, I'd rather see situation B.
Hmm... You're probably right. As long as there's at least one user per side that's sending messages on time this should not even be an issue for NefCount.
I have been patching most of the mods I run to use ChatThrottleLib, it helps so much, and I dont notice any slowdown at all.
Since its such a political hot-potato, perhaps throwing another mod into the mix could help.
Since there are 2 issues with the addon channel
1) outbound data rate control
2) duplicated inbound event checks (1 from each mod - to see if its their's)
Why not create a proxy that allows the *user* to control which addons use CTL and what priority they communicate at. Also, inbound event routing would mean just 1 mod processing the event then passing it on to the mod that it belongs to.
It would tie everything together - as a developer i dont want someone else to mess with my mod, as a user, i want some control over what the mods are doing - especially if im gettting disconnected.
BigWigs sync messages are useless when they are delayes too long...
The hooking already got fixed Grim :P
Yep. Absolutely. This is a good reason to use ChatThrottleLib and send them in ALERT priority; they will not be delayed as long as we are not running a risk for kicking the player out of the game. It is not a good reason to ignore ChatThrottleLib altogether.
Both AceComm and Telepathy (Sky's rewrite for 1.12) use ChatThrottleLib.
CTRA does NOT use it, and Cide fails to see the point in using a common throttler; he much rather keeps using his own throttler. Any argument that several addons using their own throttler will still cause an overload falls on deaf ears.
Imagine you want to count Chromatic Drakonid kills. The 2 doors are too far apart, there's no way you can get the death messages from both sides. If a Chromatic dies on the left side, and 0.3 seconds later one on the right (=your side) dies. With a delay of roughly 0.2 seconds and 100ms latency you risk not tracking the kill on the left.
If you want to use the Shadow Flame warnings to start casting heals on the MT (with at least 2.5 sec casting time) every tiny bit matters... Edit: I'm not saying that is the best strategy to deal with shadow flames :p
In both cases no delay would be better, and a delayed message is about as usefull as none at all. I'd rather have the other users sorting their add-ons not to spam so much than making message timing even more unpredictable.
One possibility would to send the timestamp of the kill with the sync message.. but then again you would need a precise server time.
Chromatics still are called Chromatics, no matter what side they are :p
You're right, normal latency is bad enough. There's no way to guarantee every Chromatic is counted (because there's no unique ID, not everyone gets every kill message, there's no global time and there's no minimum time between 2 kills). That's less of a problem for the colours, since everyone on one side should be able to get all the "local" kill messages... For the Chromatics every bit of delay, both from latency and artificial, makes syncing less reliable.
I will re-iterate:
... by making addon authors use ChatThrottleLib even though they all feel that their traffic is important enough to kick players off in order to, oh, for example, keep an accurate count of Chromatics?
Actually, that makes me think I should throttle bulk traffic further if the player is in combat. Not every addon wants to be bothered with checking what mob they're fighting before responding to e.g. a data transfer request from another player. E.g. another player nowhere near BWL.
My problem is that it makes the timing unpredictable. You cannot know what other add-ons the user is running, and how long your messages might be delayed...
Actually i said I'd prefer people being disconnected. I do notice the benefit of ChatThrottleLib, but I don't trust the average WoW player to pick "chat friendly" add-ons unless something makes them. Blizzard chose to disconnect them... Maybe a big fat error popup saying "you'd just have been disconnected because your outbound traffic is too high" would have the same effect.
If people see a timer bar (like for Sartura's Whirlwind), they tend to rely on it. Depending on the "purpose" of that timer no bar at all might be better than a wrong one. That's why I think some time-critical events are better sent immediately or not at all. (Maybe they should have their own cathegory...)
Situation A) User has an assload of mods (3 damage meters, a threat meter, etc...) that all send tons of information and he decides "Hey, I'm going to install BigWigs since all the cool kids are doing it". To make this even more complicated lets say hes an dumb raid leader, and the main tank at that. Raid time comes and zomg, he keeps getting disconnected during boss-fights. He decideds "well, the only thing I recently changed is BigWigs, so this mod must suck!". He was kicked becuase BigWigs was sending the 'straw that broke the camel's back' so to speak. He tells his guild to not use BW becuase "it sucks".
Situation B) Same stupid user again has an assload of mods, this time they all use CTL. He decides "Hey, I'm going to install BigWigs since all the cool kids are doing it". Raid time comes, and oh noes! BigWigs messages seem delayed. He blames it on server lag and decides to deal with it.
Honestly, people who aren't bogging down their system with a ton of stuff are going to send the messeages immediatly regaurdless, becuase they have the space to send it. Also this ignorent-user is still going to recieve those sync messeages, on time, from the smart user. The ONLY things it's going to cause issue with is things like NefCount that are counting most/all users sending things instantly and acurately.
Given the two hypotetical situations, I'd rather see situation B.
Hmm... You're probably right. As long as there's at least one user per side that's sending messages on time this should not even be an issue for NefCount.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSince its such a political hot-potato, perhaps throwing another mod into the mix could help.
Since there are 2 issues with the addon channel
1) outbound data rate control
2) duplicated inbound event checks (1 from each mod - to see if its their's)
Why not create a proxy that allows the *user* to control which addons use CTL and what priority they communicate at. Also, inbound event routing would mean just 1 mod processing the event then passing it on to the mod that it belongs to.
It would tie everything together - as a developer i dont want someone else to mess with my mod, as a user, i want some control over what the mods are doing - especially if im gettting disconnected.