WowAce

What is the enhancement in mind? How should it look and feel?

The RankWatch addon put this idea in my head.  RankWatch auto-spams someone who casts a downranked spell to remind them to update their bars (dual spec leads to that issue).  Given the case of multiple RankWatch users in the same group, he didn't want 24 other RankWatch users in the raid to all spam that 1 poor down-ranked spell user with the same warning message whisper, so he uses a network feature to communicate with the other RankWatch clients to let them know "hey I already announced this event to this target, so don't be redundant with me"

When multiple SpeakinSpell users are in the same party together, the spam can become compounded in a similar way.  The logic required to make use of this idea and apply it to SpeakinSpell is less clear than it is in RankWatch, but some kind of SpeakinSpell option along these lines should be possible and could be useful.

Please provide any additional information below.

I went on some dungeon runs with both Meneldill and Dire Lemming last night, and it was indeed spamtastic for the 3 of us running SS at the same time. I was waiting for the 2 random pug members to complain (so I could take credit LOL) but they must have been either entertained or not reading chat.

I got to thinking a place to start would be to signal the other SS clients that I announced an event, and give the event key, ex. "entering combat"

but what to do when I receive this notification?

Exactly what is the logic for deciding whether or not to speak after receiving a notification that another SS user just announced an event?

considerations:

• Everyone should get a chance to SpeakinSpell, not just the fastest PC, or the tank who enters combat first. Some kind of round-robin should be used.
  • if everyone has cooldowns and/or random chances in effect, that would achieve enough distribution
• It takes time for Dire Lemming to transmit the notification over the network to alert me that she announced Entering Combat, but by that point I probably already announced the event redundantly. So a time delay is (probably) needed to wait for a possible notification.
  • Maybe check on joining the group if anyone else in the group uses SS so we know whether to wait like this?
• I only want some of my events to do this - not all - so it has to be a per-event setting
  • When I pop mirror images, I don't care if another mage just announced mirror images. I want to announce that spell no matter what other players are spamming.
  • However if someone just cried a battlecry on entering combat, I'd rather silence mine

A possible simple approach to this idea could use a checkbox as a global option applied to all speeches...

[X] Take turns with other SpeakinSpell users

If other SS users are detected in my group, then after I spam a macro, don't spam another macro until another person spams one, then I can go again.

Just thinking about how this would play out if there are 3 SS users total in the group, named A, B, and C ...

• A says something ... A is now blocked, but that makes B and C allowed
• B says something ... B is now blocked, now A and C are allowed
• A says something
• C says something at the same time
• they may cross-network communicate and re-enable each other

We get to a point again where A is now blocked, but that makes B and C allowed... B and C drop group... we need to detect that to stop blocking A since it won't hear from B and C now.

Moved to new Anti-Spam category

I guess some kind of "ranking" could be applicable, too...

I'd think about something like:

• caster first,
• target second,
• observers last.

Obviously this only works for casting events. System events should be checked by other methods (like "round robin" or something similar).

Update for WoW 5.0...

My latest thinking on this idea is to simply create a % reduction in SS output while in a group with other SS users. The net effect over an hour dungeon run should result in the equivalent number of speeches per hour as if there had been only 1 SS user.

• 2 SS users in the group = 50% chance to speak
• 3 SS users in the group = 33% chance to speak
• 4 SS users in the group = 25% chance to speak
• 5 SS users in the group = 20% chance to speak
• etc.

chance to speak = 1 / (Number of SS users in the group or raid)

Mathematically, it doesn't matter if we make this determination before or after checking other cooldowns and random chance options for the event. This is probably more likely to block the speech (50% or more is a high chance to silence the announcement), which makes it more efficient to check it first, before checking event-specific cooldowns/random chances.

Such a feature should be accompanied by an option to mark an individual event trigger as "[X] Combat Critical" which means it ignores all cooldowns and random chances (to be filed under a separate ticket)

I'm re-assigning all my tickets to Duerma

Unassigning tickets that are not actively being worked on