Announcing attempts in SAY no longer works after Blizzard change to SendChatMessage()

[Duckwhale]

Source: WowAce

my rarity is not announcing to chat anymore and i have no idea why i didnt change anything its still set to output > channel > say
but its not announcing "tries" anymore or what number you are on or when you have found something

Apparently, Blizzard has now disabled SendChatMessage automation in chat channels: https://twitter.com/deadlybossmods/status/1176685822223011842

SendChatMessage automation disabled in public/private chat channels
It’s ALSO disabled from SAY/YELL out in world.
It’s permitted in raid/party/guild chat, and SAY/YELL within instances

This means that the SAY sink probably won't work most of the time. I guess the setting should be disabled or at least get a tooltip that explains why it won't work in some circumstances?

[Duckwhale]

Need to look into LibSink and how Rarity uses it to output announcements.

I fully expect the code to be resistant to change, as per usual, so it might take more work to fix this problem than one might think (hence the TBD tag).

[nickbayley]

I had a brief look today. I'm still very new to all this, but I had some success.

You can do something like the following:

local sink_configuration = self:GetSinkAce3OptionsDataTable()
sink_configuration.args.Channel = nil

And then set the options key to sink_configuration instead of the call to self:GetSinkAce3OptionsDataTable().

This completely removes the "Channel" checkbox from the "Announcements > Output" option. I'm sure this is not what you'd want, but I guess it would be possible to do something similar and remove certain channels from the drop down list.

If you wanted to support "yell", "say", etc. in unprotected areas (instances), I guess it'd have to be a little more complicated.

Hopefully some of the above makes sense.

[Duckwhale]

I'm not sure removing certain channels is a good idea; firstly it would make the setting stored in the saved variables obsolete for those who selected one of the restricted channels. Secondly, we'd essentially be hacking LibSink to work around Blizzard's design and therefore place the maintenance burden on us for no good reason. Lastly, the restricted channels are still generally functional, so there's no reason to prevent people from actually using them.

Instead, I suppose it would be better to allow the usage of restricted channels, but prevent the calls that cause the errors when restrictions do apply (not sure how to detect this currently). I'd also wrap the LibSink API similar to the TSM one, if we need to hack it in somehow (as it doesn't look like it supports differentiating between restricted and non-restricted areas or anything).

A preliminary plan of action could then look approximately like this:

1. Move LibSink functionality (used APIs) to a separate module: Core/Interfaces/OutputChannels.lua (or similar)
2. Add description (red text) to the Options UI, under the Announcements/Output group, notifying users that some channels are not working, and why (just blame Blizzard.). This, combined with the below measures, will hopefully prevent future bug reports concerning the same issue
3. When a channel is selected that is restricted, and the restrictions currently apply, skip announcements. That is, whenever Blizzard would block the call to SendChatMessage()) we just don't use the channel to avoid causing an error
4. Show a one-time (per session. No need to save this permanently?) warning whenever a chat message would be blocked. This should be notifying users that the attempts could not be announced, and why (blocked/disallowed by Blizzard), as well as what they can do to avoid/fix the problem (select a different channel). If it really bothers them, they can pick a channel that isn't blocked by Blizzard and if they don't care to do this, it would still work as expected at least some of the time

The details are obviously TBD; I haven't really worked with LibSink before.

Thoughts? :D