naschorr / clipster Goto Github PK

Currently, the help interface doesn't show any of the non-clip commands for the bot. Namely, 'random', 'find', or 'skip'. These, and the others should be added into the interface.

Clipster and Hawking both share this code, and in the future I'd like to have a set of core modules that can be maintained in a single place and distributed to both bots. During the Discord API refresh, I made it mostly generic, but during the porting process to get Hawking back online, I noticed a few places that still need some work.

• Genericize all instances of "clips" to be audio
• Ensure the play_audio methods just handle taking an audio file and getting it injected into the audio player event loop
• Rewrite the disconnect message logic to take a method to handle prepping the phrase/clip
• Start removing unneeded class members

This'll will also allow the dependabot merge for an aiohttp upgrade too. See #51

• Updated admin skip logic to reuse the audio_player implementation, but with some flavor of guard/check
• Properly check if any users in the voice channel are bots or not
• Remove the weird non percentage based skip system, that's always been not great

Since the help sub commands (ex. 'internet' in '=help internet') are commands themselves, they can be suggested when a user makes an invalid command. This leads to a useless cycle where someone doing the '=internet' command would be suggested to do a '=internet' command instead.

Basically copying these changes into Clipster. naschorr/hawking#53

Right now, it's kind of a pain to debug errors and issues in production. I'm thinking some simple logging with Python's logging module would be nice.

It doesn't really make sense to expose inside jokes and similarly niche clips to the wider Clipster audience, so there should probably be a way to ensure this happens.

Really this should just involve:

• Adding a flag to the relevant manifests that specifies the server_ids that it should be allowed on (with the default falsy state making it available on all servers)
• Updating the Clips and ClipGroup classes to acknowledge this new flag, as well as throw the appropriate permissions error when a user from a disallowed server attempts to invoke one of these restricted commands.
• Updating the ClipsterHelpCommand to only show clips and groups that the invoking server is allowed to see
• Updating the README.md

Lastly, it'd probably be a good idea to consider how to handle clip name collisions. Would a command prefix be okay? Otherwise the behavior of a restricted clip intersection with either another server's restricted clip or one of the default clips might lead to some unexpected behavior in regards to clip loading.

It's kind of wild that I've gone this far without them, so it really needs to be done. This'll be super important once I migrate the latest Hawking changes over, to ensure that I don't accidentally break anything.

Hawking had a major overhaul to comply with Discord's policies. Clipster should be able to leverage the work done for Hawking

Sometimes, Discord will have issues that make the bot unreliable, leading to command errors. When the on_command_error method is invoked, it should never suggest the same command that it was given.

See naschorr/hawking#315

In my experience, the find command is used with a specific command in mind. With people often running it to get the name of the command, and then executing said command. I'm thinking about just reworking the command to play the found command, else give the user notice that nothing was found.

This doesn't really make sense anymore now that a proper logging implementation exists

Right now, when the server restarts, all of the bots simply disconnect. No feedback is provided to the users, which makes it seem like something broke, rather than a scheduled restart.

By adding the ability to send messages out to all connected bots, users can be notified that this is a scheduled restart, and that the bot will be available again in a few seconds.

Discord's already got a built in concept of bot ownership, so just use that instead of having an extra field to configure.

TL;DR: naschorr/hawking#18

Basically, the syntax would be \preset @username. This would send Clipster to the voice channel that @username is connected to, to play the [preset] clip.

Pretty self explanatory, that file hasn't been touched since 2018

Right now, the readme is next to useless.

It needs to have a quick start section, installation instructions (multi-platform), a command guide, and config instructions at a minimum. Basically, it should look like Hawking's readme but for Clipster.

See: naschorr/hawking#64

Clipster dumps the normal command error text, and doesn't actually alert the user that something is wrong

The recent work on https://github.com/naschorr/hawking/tree/78-module-compartmentalization for Hawking affects some of the common functionality shared between the bots, so those changes should be implemented and accounted for here as well.

So the clip skipping logic is basically untouched from when it was first implemented in Hawking back in 2017. What I want to do it:

• Remove the total_votes based skipping, leaving on percentage based skipping. This was always kind of dumb and nonintuitive.
• Fix how it calculates the number of people in a voice channel, right now it doesn't account for other bots.
• Updated config.json with these changes as well

If you mess up trying to invoke a help command, let's say '=<category>' instead of '=help <category>', as long as '<category>' doesn't map to an existing command, it should be smart enough to dump the help interface for that command.

Clips.py already tracks category names inside Clips > self.clip_groups. So it should be fairly easy to implement.

See naschorr/hawking#35

I've been noticing that Clipster (and Hawking) will seem to come online and offline more often than they should. After taking a look at the logs, I've noticed that there are some instances of the socket closing, and the service having to reconnect it automatically. websockets.exceptions.ConnectionClosed: WebSocket connection is closed: code = 1006 (connection closed abnormally [internal]), no reason. Upon further inspection, there is a constant type error that seems to cause this issue:

Traceback (most recent call last):
  File "/usr/local/bin/hawking/code/hawking.py", line 206, in <module>
    hawking.run()
  File "/usr/local/bin/hawking/code/hawking.py", line 198, in run
    self.bot.run(utilities.load_json(self.token_file_path)["token"])
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/client.py", line 640, in run
    return future.result()
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/client.py", line 621, in runner
    await self.start(*args, **kwargs)
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/client.py", line 585, in start
    await self.connect(reconnect=reconnect)
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/client.py", line 499, in connect
    await self._connect()
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/client.py", line 463, in _connect
    await self.ws.poll_event()
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/gateway.py", line 471, in poll_event
    await self.received_message(msg)
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/gateway.py", line 425, in received_message
    func(data)
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/state.py", line 750, in parse_guild_create
    guild = self._get_create_guild(data)
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/state.py", line 725, in _get_create_guild
    guild._from_data(data)
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/guild.py", line 296, in _from_data
    self._sync(guild)
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/guild.py", line 323, in _sync
    self._add_channel(TextChannel(guild=self, data=c, state=self._state))
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/channel.py", line 107, in __init__
    self._update(guild, data)
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/channel.py", line 131, in _update
    self._fill_overwrites(data)
  File "/usr/local/bin/hawking/lib/python3.6/site-packages/discord/abc.py", line 294, in _fill_overwrites
    self._overwrites.append(_Overwrites(id=overridden_id, **overridden))
TypeError: __new__() got an unexpected keyword argument 'deny_new'

Fortunately, I'm not the only one to experience this (see: Rapptz/discord.py#5109). The recommended course of action seems to be to update discord.py to the latest version (1.3.4), as it's currently on 1.3.2

2020-02-02 23:22:50,499 - clipster - on_command_error - ERROR - Unable to process command.
Traceback (most recent call last):
File "H:\Apps\clipster\lib\site-packages\discord\ext\commands\core.py", line 83, in wrapped
ret = await coro(*args, **kwargs)
File "H:\Apps\clipster\code\clips.py", line 263, in random
await command.callback(ctx)
File "H:\Apps\clipster\code\clips.py", line 251, in _clip_callback
await play_audio(ctx, path, target_member=target)
File "H:\Apps\clipster\code\audio_player.py", line 332, in play_audio
voice_channel = target_member.voice.channel
AttributeError: 'NoneType' object has no attribute 'channel'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "H:\Apps\clipster\lib\site-packages\discord\ext\commands\bot.py", line 892, in invoke
await ctx.command.invoke(ctx)
File "H:\Apps\clipster\lib\site-packages\discord\ext\commands\core.py", line 797, in invoke
await injected(*ctx.args, **ctx.kwargs)
File "H:\Apps\clipster\lib\site-packages\discord\ext\commands\core.py", line 92, in wrapped
raise CommandInvokeError(exc) from exc
discord.ext.commands.errors.CommandInvokeError: Command raised an exception: AttributeError: 'NoneType' object has no attribute 'channel'

Should be an easy fix, too bad python doesn't have proper null coalescing