| Commit message (Collapse) | Author | Lines |
|
Previously we were showing the entire queue of coming-up icons. As we're
now showing full paths (rather than just filenames), this creates a lot
of visual clutter that is unnecessary. It's not critical to know in
which order the icons will be cycled, as there's no way for us to affect
it anyway. This list of all available icons is still displayed above.
The information about configured cycle frequency goes in the footer,
if we're cycling.
|
|
There is an annoying collision in the "server icon" vs "bot icon"
nomenclature, so I made the decision to always refer to the bot's image
as avatar. This choice is already visible through the module, we only
need to adjust the actual filename that we're looking for.
The filenames will be adjusted in the branding repository.
|
|
Less error-prone; easier to adjust.
|
|
The previous implementation would simply ignore assets not present in
the current season's directory.
On the condition that at least one asset is missing, and the current
season is not the evergreen, we also poll the evergreen directory,
and use it as fallback.
This behaviour is shielded such that we only make the extra API call if
there is a missing asset, i.e. if there is something to be gained.
|
|
Since the banner and avatar assets will always have the same filename,
we need their full paths to differentiate between assets of different
seasons. Rather than introducing more complexity to the `pretty_files`
function and deconstructing the download urls, we can just store the
path as provided by the API.
We also now print the `path` instead of showing bools in the status
embed, as just the fact that there is some banner is not enough
information - we want to know which season's banner has been picked
up during refresh.
|
|
We do not have any multi-word seasons at the moment, but there is no
reason to restrict the command to just one word.
|
|
|
|
Asyncio's sleep will accept both, and we default to an int, so might
as well not break our own promise.
|
|
Importing the bot instance will allow us to safely access
the `wait_until_ready` method without having to make fragile
assumptions about the arguments passed to the decorated method.
Although still not perfect, this feels a lot cleaner and safer than
the previous approach.
|
|
It makes more sense for it to be positioned alongside other core bot
features.
|
|
|
|
See docstring for implementation details.
|
|
We want to prevent listeners from performing season-specific behaviour
outside of specific months.
|
|
A guarded listener will abort if the triggering event happens outside
of `allowed_months`. This provides a convenient way of season-locking
listeners without having to write guards directly within their bodies.
|
|
Raise a custom exception if the command fails. This is then handled
in the error handler, and the user will be informed of which months
allow the invoked command.
|
|
|
|
|
|
Prevent re-applying branding if the user requests an already active
season. This saves us an expensive operation.
Only trigger typing if season switch was successful and `apply` will
be called, as otherwise the bot will respond immediately.
|