r1335-alpha
Details
-
FilenameAce3-r1335-alpha.zip
-
Uploaded by
-
UploadedMay 5, 2024
-
Size166.53 KB
-
Downloads682
-
MD52197202208f800d47761e3cb0ebd5c07
Supported WoW Retail Versions
- 10.2.6
Supported WoW Cataclysm Classic Versions
- 4.4.0
Supported WoW Wrath of the Lich King Classic Versions
- 3.4.3
Supported WoW Classic Versions
- 1.15.2
Supported WoW Burning Crusade Classic Versions
- 2.5.4
Changelog
------------------------------------------------------------------------
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
------------------------------------------------------------------------