ChatThrottleLib: Add Battle.net addon message support #14
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds the necessary hooks and public APIs to support sending comms over the BNSendGameData API.
There's a few differences to note up-front about CTL's provided interface for this functionality.
On message size, our round-robin message selection effectively pauses when it reaches a message for which there isn't yet enough accrued bandwidth to send. In the case of 4078 byte messages that this API supports, this could mean with the current CPS value that a priority blocks for up to 5 seconds before enough bandwidth is available to send it off. This would be extremely unfair to everything else sending data, so limiting it to the usual 255 bytes sounds more reasonable.
On parameter ordering, there's an inconsistency between the API's parameters and the data supplied in its event; the API doesn't have a chattype parameter but its receipt event fires with one always set to 'WHISPER'.
If the API changed to require a chattype parameter down the line it would require a backwards compatibility break in our interface if we hadn't accommodated it, so it feels sensible to just require it up-front even if it must always be 'WHISPER'.
With both the message size and added chattype parameter in mind, it then also makes sense to just make the interface have the same parameter ordering as SendAddonMessage to make it a bit easier to generically use these functions. BNSendGameData requires an order of
(target, prefix, data)
, whereas our interface is the standard(prio, prefix, data, chattype, target, ...)
.