| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also not quite sure if they goofed rustfmt or something, but its changes it did were a bit bizarre.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upgrade `rust-websocket` to v0.20, maintaining use of its sync client.
This indirectly switches from `rust-openssl` v0.7 - which required
openssl-1.0 on all platforms - to `native-tls`, which allows for use of
schannel on Windows, Secure Transport on OSX, and openssl-1.1 on other
platforms.
Additionally, since hyper is no longer even a dependency of
rust-websocket, we can safely and easily upgrade to `hyper` v0.10 and
`multipart` v0.12.
This commit is fairly experimental as it has not been tested on a
long-running bot.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modules are now separated into a fashion where the library can be used
for most use cases, without needing to compile the rest.
The core of serenity, with no features enabled, contains only the
struct (model) definitions, constants, and prelude. Models do not have
most functions compiled in, as that is separated into the `model`
feature.
The `client` module has been split into 3 modules: `client`, `gateway`,
and `http`.
`http` contains functions to interact with the REST API. `gateway`
contains the Shard to interact with the gateway, requiring `http` for
retrieving the gateway URL. `client` requires both of the other features
and acts as an abstracted interface over both the gateway and REST APIs,
handling the event loop.
The `builder` module has been separated from `utils`, and can now be
optionally compiled in. It and the `http` feature are required by the
`model` feature due to a large number of methods requiring access to
them.
`utils` now contains a number of utilities, such as the Colour struct, the
`MessageBuilder`, and mention parsing functions.
Each of the original `ext` modules are still featured, with `cache` not
requiring any feature to be enabled, `framework` requiring the `client`,
`model`, and `utils`, and `voice` requiring `gateway`.
In total the features and their requirements are:
- `builder`: none
- `cache`: none
- `client`: `gateway`, `http`
- `framework`: `client`, `model`, `utils`
- `gateway`: `http`
- `http`: none
- `model`: `builder`, `http`
- `utils`: none
- `voice`: `gateway`
The default features are `builder`, `cache`, `client`, `framework`,
`gateway`, `model`, `http`, and `utils`.
To help with forwards compatibility, modules have been re-exported from
their original locations.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds multiple configurations to the command builder, and adds methods
to various structs.
Context::get_current_user is a shortcut to retrieve the current user
from the cache.
Message::get_member retrieves the member object of the message, if sent
in a guild. Message::is_private checks if the message was sent in a
Group or PrivateChannel.
User::member retrieves the user's member object in a guild by Id;
Adds 6 configurations to the command builder:
- dm_only: whether the command can only be used in direct messages;
- guild_only: whether the command can only be used in guilds;
- help_available: whether the command should be displayed in the help
list;
- max_args: specify the maximum number of arguments a command must be
given;
- min_args: specify the minimum number of arguments a command must be
given;
- required_permissions: the permissions a member must have to be able
to use the command;
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Audio can be played with support by passing one of the following into
the `Handler::play` method:
`serenity::ext::voice::{ffmpeg, pcm, ytdl}` functions, where
- `ffmpeg` accepts a path (such as a `File`);
- `pcm` accepts a raw reader source;
- `ytdl` accepts a URI, which works with everything youtube-dl supports:
<https://github.com/rg3/youtube-dl/blob/master/docs/supportedsites.md>
The source can be stopped via [`Handler::stop`].
Receive is supported through [`Handler::listen`], which accepts a
`serenity::ext::voice::AudioReceiver` implementation.
An example is provided in the form of the file located at
`./examples/07_voice.rs`, which can be run by cloning the repo and
performing the command `cargo run --example 07_voice`. Prior to running
the command, set a bot token as the value of the env variable
`DISCORD_TOKEN`. The example supports:
- `deafen`: deafens the bot;
- `join`: joins a voice channel by ID. The example is a primitive
implementation, and requires the ID of the channel to be passed to the
bot as a command of `~join 131937933270712320`;
- `leave`: leaves the current voice channel, if in one;
- `mute`: mutes the bot and will continue to play source audio;
- `play`: plays source audio from a URI, through a command like
`~play https://www.youtube.com/watch?v=5KJjBRm0ElA`;
- `ping`: responds with "Pong!" to ensure the bot is working properly;
- `undeafen`: undeafens the bot, if that's actually a word;
- `unmute`: unmutes the bot.
Documentation for audio can be found at:
<https://serenity.zey.moe/serenity/ext/voice/index.html>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-organize the client module, creating a `gateway` submodule, and
splitting the connection into separate files in it.
The connection was a conglomeration of a number of purposes, most of
which are actually used elsewhere in the library and/or exposed to the
user. Thus, it makes sense to separate each item in a gateway-specific
module.
By splitting the client module further, this is a re-organization for
preliminary RPC support WRT the Client.
Additionally, rename the Connection struct to a Shard. The Connection
itself was not the actual connection, and was a higher-level interface
to the real connection logic. A Shard is a more accurate representation
of what it actually is.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Most of the docs were linking to `enum.EnumName.html#VariantName.v`,
which should have been linking to
`enum.EnumName.html#variant.VariantName`.
|
| |
|