------------------------------------------------------------------------ r1340 | nevcairiel | 2024-05-07 23:06:36 +0000 (Tue, 07 May 2024) | 1 line Changed paths: M /trunk M /trunk/Ace3.toc M /trunk/changelog.txt Update changelog before release ------------------------------------------------------------------------ r1339 | nevcairiel | 2024-05-07 22:57:17 +0000 (Tue, 07 May 2024) | 39 lines Changed paths: M /trunk M /trunk/AceComm-3.0/ChatThrottleLib.lua ChatThrottleLib: Add Battle.net addon message support 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. - The BNSendGameData API supports sending messages up to 4078 bytes in length, but our implementation limits it to 255 bytes. - The BNSendGameData API has a different parameter ordering and no 'chattype' parameter, whereas our implementation is consistent with SendAddonMessage. 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 we limit it to the usual 255 bytes. 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 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 accomodated 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). ------------------------------------------------------------------------ r1338 | nevcairiel | 2024-05-06 12:57:05 +0000 (Mon, 06 May 2024) | 1 line Changed paths: M /trunk M /trunk/AceComm-3.0/ChatThrottleLib.lua ChatThrottleLib: Remove unused upvalues ------------------------------------------------------------------------ r1337 | nevcairiel | 2024-05-06 11:51:06 +0000 (Mon, 06 May 2024) | 30 lines Changed paths: M /trunk M /trunk/AceComm-3.0/ChatThrottleLib.lua Improve handling of errored send calls With the changes to implement prefix throttle support the logic around despooling was changed such that messages in a queue are peeked, sent, and then popped based upon whether or not it was throttled. The rationale behind that approach was simply performance; currently message pipes are an array of messages where a pop down-shifts every element in the queue. If we had to re-queue a message that would result in re-shifting everything back up unnecessarily. This change however makes things a bit worse in the case of send calls that encounter an error in the C API itself - eg. due to invalid parameters. In such a case, because we've not popped the message prior to sending it we end up in a situation where the message sticks in the queue, and CTL now infinitely tries to re-send it expecting a different result. To alleviate this concern, the PerformSend and MapToSendResult function have been altered slightly to now xpcall the send function and check whether or not it actually succeeded. - In the event where a message failed to send due to an error, the global error handler is invoked and CTL will continue its own logic with the assumption that the message generally failed to send. It will be dequeued and not retried. - In the event where no error occured, the logic is ultimately the same as before, just now centralized in the MapToSendResult function. ------------------------------------------------------------------------ r1336 | nevcairiel | 2024-05-06 07:17:04 +0000 (Mon, 06 May 2024) | 11 lines Changed paths: M /trunk M /trunk/AceComm-3.0/ChatThrottleLib.lua Move Link method off Ring metatable There's a bug in the upgrade logic where existing rings created by older versions of the library never have their metatables upgraded. As such, a load of a version older than v25 followed by v25 or newer will result in a call to a nil 'Link' method on rings. Rather than think through the ramifications of just setmetatable-ing rings again unilaterally on upgrade (though that is probably a perfectly sane idea and should work), for now let's just make the new Link method a local function instead as that's the safer option. ------------------------------------------------------------------------ r1335 | nevcairiel | 2024-05-05 19:35:16 +0000 (Sun, 05 May 2024) | 3 lines Changed paths: M /trunk M /trunk/AceConfig-3.0/AceConfig-3.0.lua AceConfig-3.0: Fix documented arguments of RegisterOptionsTable RegisterOptionsTable only takes 3 arguments, not 4 ------------------------------------------------------------------------ r1334 | nevcairiel | 2024-05-05 19:29:01 +0000 (Sun, 05 May 2024) | 26 lines Changed paths: M /trunk M /trunk/AceComm-3.0/ChatThrottleLib.lua Add support for logged addon messages This commit imbues CTL with the knowledge of logged addon messages added in patch 8.0. A new surface API is added for enqueuing logged messages for transmission, and the existing traffic bypass hooks are extended to additionally monitor raw usage of the SendAddonMessageLogged API. A few small notes: - Pre-8.0 compatibility checks for C_ChatInfo were removed to simplify some of the changes. - The core "should I send or queue it" logic used by SendAddonMessage has been moved out to a new function (SendAddonMessageInternal) to cut down on duplication both it and SendAddonMessageLogged. - The monitoring hook for SendAddonMessageLogged calls a function that just forwards on to the hook for SendAddonMessage; this is just in case any circumstance arises in the future where the handling of these hooks needs to differ. - Management of the SendAddonMessageLogged uses yet-another securehook boolean on the CTL library instance. Feels like this should really be changed to some "hook version" approach based on the minor version, but that's a bit of a larger and riskier change. ------------------------------------------------------------------------ r1333 | nevcairiel | 2024-05-05 16:24:39 +0000 (Sun, 05 May 2024) | 4 lines Changed paths: M /trunk M /trunk/AceComm-3.0/AceComm-3.0.lua AceComm-3.0: Change the default queue name to be only the prefix This lines up with the ChatThrottleLib changes made to make per-perfix throttling easier to manage. ------------------------------------------------------------------------ r1332 | nevcairiel | 2024-05-05 16:23:29 +0000 (Sun, 05 May 2024) | 8 lines Changed paths: M /trunk M /trunk/AceComm-3.0/AceComm-3.0.lua Add sendResult to AceComm callback forwarding Most people probably interface with AceComm rather than CTL directly, so it makes sense to pass the send result from CTL fully through the chain. One downside is that because AceComm currently appends its own textLen argument, we're forced to effectively sandwich it by appending sendResult to the end of the list. ------------------------------------------------------------------------ r1331 | nevcairiel | 2024-05-05 16:23:23 +0000 (Sun, 05 May 2024) | 23 lines Changed paths: M /trunk M /trunk/AceComm-3.0/ChatThrottleLib.lua Adjust default queue name to just be the prefix As throttles are now per-prefix, any default queue strategy that fragments messages sharing a common prefix amongst multiple pipes has an effect where the despool logic will make very slow progress attempting to send them. This is particularly problematic for whispers. If an addon were to queue up a lot of data for unique whisper targets, we can only despool one message per second for at most one of those targets, with all the other pipes constantly being blocked. The worst case scenario is whisper data backs up faster than it can be sent out on a prefix, and if the data itself is formed of multiple messages then it may be the case that no user receives complete data in a timely manner. Because of this, the default queue name is now just the prefix itself. This should ensure that in large transfers across a prefix at least one player is still getting data in a more reasonable timeframe, and makes delivery behavior more consistent with raw use of the API. This also reduces the amount of work CTL has to do internally when despooling, as by default there'll be less unique pipes. ------------------------------------------------------------------------ r1330 | nevcairiel | 2024-05-05 16:23:16 +0000 (Sun, 05 May 2024) | 83 lines Changed paths: M /trunk M /trunk/.luacheckrc M /trunk/AceComm-3.0/ChatThrottleLib.lua Add support for per-prefix transmission throttling In patch 4.4.0 and 10.2.7 Blizzard have tightened the restrictions on addon comms to add a per-prefix throttle across all chat types, effectively restricting them to one message per second with a small accrued burst capacity. The SendAddonMessage APIs now return an enum result code which includes information if this client-side throttle has been applied to a submitted message. With it, we can now properly handle throttling in CTL and avoid situations where addon messages would be dropped for exceeding it. This PR takes into consideration the discussion on Discord and takes a slightly different approach to the other open one by instead implementing the concept of a "blocked" pipe. A pipe enters the "blocked" state whenever a message at its head is attempted to be sent off, and a throttle result code is returned from the API. When transitioning to this state, the pipe is removed from the transmission ring of its parent priority and is instead placed into a separate (and new) blocked ring. This prevents the despool logic from seeing blocked pipes and pointlessly attempting to re-send on them. Periodically - currently every 0.35s - the contents of the blocked rings in each priority are reintegrated back into the transmission rings, allowing us to attempt re-transmission of queued messages. This means there may be some added latency when a prefix entered a blocked state if the API was about to perhaps unblock it, but this also allows us to reallocate bandwidth that would be consumed by priorities that are fully blocked to others that can more readily use it. The value of 0.35s was chosen almost arbitrarily and could be tuned later if found to be a bit high. It's important to also note that we specifically don't consider the 'ChannelThrottle' return code a retryable error condition. The reasoning here is that this throttle isn't new, and the API can return this value but still sometimes send off the message albeit subject to additional server-side throttling checks - and also at the time of writing, a server-side bug that causes it to more aggressively throttle than it actually should. Aside from prefix throttling, there's a few other small changes. - Failure to send a message either due to an error or throttling no longer consumes bandwidth that had been allocated to a priority. - Priorities that enter a blocked or empty state now release their bandwidth back to the global pool for redistribution immediately, instead of waiting until there's no data queued up whatsoever. This is required to deal with edge cases involving priorities sending many small messages on one prefix infinitely accumulating bandwidth. - Transmission logic has been centralized into a new PerformSend function to minimize the number of call sites individually needing to remember to toggle boolean variables with each Send call. - Queued transmissions no longer apply checks to see if the player is in a group or raid. The API has dedicated return codes for this condition and has been tested to not trigger erroneous system message spam if attempting to send a message to either chat type while not being in a group. This is not the case for guilds, however the library never checked this case previously so one hasn't been added. - User-supplied callbacks are now supplied an accurate 'didSend' parameter that will be false if the API returns a non-throttle-related error code. - User-supplied callbacks are additionally now supplied the new result code as a third parameter. For Classic Era, we synthesize one from a subset of the enum values based off the boolean result that the API will still be providing there for now. - User-supplied callbacks no longer let errors blow things up in an uncontrolled manner by being subject to securecall wrapping. This is also consistently applied irrespective of whether or not the send itself was immediate or queued. - Some compatibility with the pre-8.0 global SendAddonMessage API was removed as it's no longer needed. ------------------------------------------------------------------------ r1329 | funkehdude | 2024-04-30 17:18:58 +0000 (Tue, 30 Apr 2024) | 1 line Changed paths: M /trunk/Ace3_Vanilla.toc bump toc ------------------------------------------------------------------------ r1328 | nevcairiel | 2024-03-20 22:36:27 +0000 (Wed, 20 Mar 2024) | 1 line Changed paths: M /trunk M /trunk/AceDB-3.0/AceDB-3.0.lua AceDB-3.0: Sync type checks for New and ResetDB defaultProfile ------------------------------------------------------------------------ r1327 | nevcairiel | 2024-03-20 07:23:40 +0000 (Wed, 20 Mar 2024) | 1 line Changed paths: M /trunk M /trunk/Ace3.toc Update TOC for 10.2.6 ------------------------------------------------------------------------ r1326 | nevcairiel | 2024-03-11 13:41:10 +0000 (Mon, 11 Mar 2024) | 1 line Changed paths: D /trunk/.docmeta Remove docmeta, the generation hasn't worked in years ------------------------------------------------------------------------ r1325 | nevcairiel | 2024-03-11 13:38:36 +0000 (Mon, 11 Mar 2024) | 1 line Changed paths: M /trunk A /trunk/Ace3_Cata.toc Add TOC for Cata Classic ------------------------------------------------------------------------ r1324 | funkehdude | 2024-02-22 00:57:48 +0000 (Thu, 22 Feb 2024) | 1 line Changed paths: M /trunk/AceGUI-3.0/widgets/AceGUIWidget-ColorPicker.lua AceGUI-3.0: ColorPicker: No need to force enable mouse anymore, this was fixed in a mini patch after 10.2.5 ------------------------------------------------------------------------ r1323 | nevcairiel | 2024-02-22 00:30:09 +0000 (Thu, 22 Feb 2024) | 1 line Changed paths: M /trunk M /trunk/AceGUI-3.0/widgets/AceGUIWidget-ColorPicker.lua AceGUI-3.0: ColorPicker: Sanity check that alpha exists before calculating with it ------------------------------------------------------------------------ r1322 | nevcairiel | 2024-02-22 00:25:11 +0000 (Thu, 22 Feb 2024) | 4 lines Changed paths: M /trunk M /trunk/.luacheckrc M /trunk/AceGUI-3.0/widgets/AceGUIWidget-ColorPicker.lua AceGUI-3.0: ColorPicker: Fix alpha handling on Classic Era Fixes WoWHead Ticket #655 Closes GitHub #11 ------------------------------------------------------------------------ r1321 | funkehdude | 2024-02-07 12:06:48 +0000 (Wed, 07 Feb 2024) | 1 line Changed paths: M /trunk/Ace3_Vanilla.toc bump toc ------------------------------------------------------------------------