Would be fun to have little ASCII games like tictactoe or hangman and such!

Perhaps flow like:

!invite @user

• Create new text channel where it tags both users

// in text channel
!minigame game-name

• Begins game

// game ends

• @user wins!
• Use !minigame game-name to play again, or !endgame to finish
• !endgame should clean up channel

It could be possible to set up long-term scorekeeping in a database by user per guild, though that will be a task for later

Currently, in order to change the spelling or content of any list name / description, or item name / note, the thing must be deleted and remade.

Users should be able to use something like
!updatelist [-l <list-name>] [-name <new-name>] [-description <new-description>]
!updateitem [-l <list-name>] <item-name> [-name <new-name>] [-description <new-description>]
in order to update these values.

NOTE: While items have "note" property in the code, we should probably call them "descriptions" here for user ease-of-use. It may be best to update implementation in the future to simply use "description" in the codebase for everything (not use "note").

In order to resolve this issue, (two) functions will need filled out in cogs/Listkeeper.py to receive, and parse user input; (two) functions will also need filled out in cogs/listkeeper_db/lkdb.py to handle interactions with the database using those inputs.

Users should be able to create a list which can only be modified by themselves and certain other users. This may look something like:

!newlist "My Private List" -access @user1 @user2

Ideally:

• We should be able to @mention any number of users
• We should be able to @mention roles to allow permissions to all users of the role
• We should be able to add or remove access to/from users after list creation.
• There should probably be a list "Owner" with ability to add/remove permissions

This begets some new commands as well...

• !listaccess [<list-name>] to show which users/roles have access to the list (and any "Owners")
• !addaccess [<list-name>] <*@users> (or) <*@roles> to give permission to users/roles
• !rmaccess [] *@users (or) *@roles` to revoke permissions from users/roles

Notes:

• Will need to update cogs/listkeeper_db/lkdb.py models to add columns for Owner, Allowed_Users
• In the same file, will need to add CRUD functions for accessing these columns from the db'
• Of course, will need the new commands added to cogs/Listkeeper.py
• I'm not sure how tricky it will be to add columns to the production db. Will need to fill in values for existing lists? Will need to recreate existing lists but with default values for permission columns?

1. Include instructions for installation/running the bot
2. Complete the list of commands
3. Clean up introduction

We should be able to create a new list for anything we want, not just tabletop games, or even games at all.

Examples of Desired Behavior:

!list -createlist MyList -desc "A list made for testing"

!list MyList -a first_item;second_item;third_item

!list MyList -rm third_item

!list MyList
> first_item
> second_item

!list -createlist SecondList

!list -deletelist MyList

!list
> SecondList

Files affected:

-- I think the changes will only be made within cogs/Tabletop.py
-- Tabletop cog should be renamed to reflect the cog's new purpose
| --> Remember to update the very bottom lines of Tabletop.py where the cog is initialized to the bot

May want to implement a few regex patterns to properly recognize things like !list MyList -a "hello world";"foo bar"

It's definitely time to add testing for this bot. I'd certainly rather_not_ take the route of writing a second bot that feeds commands / examines output, so I'd like to try using a library called dpytest to do this.

The library is still in alpha (0.5.3) and may have feature gaps and/or breaking changes at times ... but I'd really rather not write a second bot just to test this one.

Since the creation of this bot, a lot of new files and directories have been written; the filesystem ought to be cleaned up and organized better.

This will probably entail a few things, like:

• Creating a bot or src dir for code
• cogs/ will probably move there? Need to check other repos to see convention
• Moving baby-bot.py into that dir
• Might need to add a run.py in root dir?
• Will certainly need to update the Heroku PROCFILE to properly start the bot
• Perhaps adding a config/ dir

Of course, imports and the open()ing of files will need to be checked and updated.

Current behavior:
!cat returns a link to a thumbnail image from Google search results. This image is small and cannot be seen in a larger form.

Desired behavior:
!cat should return a larger image, so that it can be clicked in discord and seen at a reasonable size.

Further info:
This seems to be common behavior when trying to scrape images from search engines; I've tried adapting this command to use a different engine, but a couple others also present this issue of returning a thumbnail.

Next Step:
While writing this, I popped by ecosia.org image search to check on what it looked like. I don't remember what the obstacle was last time, but it looks like it may be possible to scrape appropriately large images from here?

Here is an example of what an img result looks like (target with class="image-result__image"):

<img src="https://tse4.mm.bing.net/th?id=OIP.RGO2_JeImrSM658MPIASrwHaEo&amp;pid=Api" data-src="https://tse4.mm.bing.net/th?id=OIP.RGO2_JeImrSM658MPIASrwHaEo&amp;pid=Api" alt="kittens, Kitten, Cat, Cats, Baby, Cute Wallpapers HD ..." class="image-result__image" data-v-737b338e="">

That src link is directly to the target image and can be accessed by pasting it into the browser.

Testing required.

It would be nice if the bot were able to keep track of how many/how frequently a user is sending messages in a channel, and time them out / delete their messages as appropriate if they are sending too many messages in a short period of time.

Ideally the parameters of "too many" and "too frequently" would be configurable by at least guild, and even better if it were configurable by role as well.

SparksieBOT normally ensures that music commands are only used in the proper channels, and deletes any messages from the music bot that are sent outside of the correct channel.

After the transition to Hydra, most of the functionality should still work as-is, however I think there are a couple of things (like deleting the bot's messages when appropriate) that will need to be updated to work as desired.

I'd like to add tests to this project. However, setting everything up as-is would require one of two (undesirable) paths forward:

1. Building a second bot to feed input and test responses,
2. Using another testing library ( like dpytest ) which is still in development and not clearly documented yet

I prefer a third option, which is to move all of the "work" code into non-discord, easily-testable files. For example:

# before
@commands.command()
async def add_numbers(self, ctx, *args):
    result = sum(args)
    ctx.channel.send(f"The sum is {result}")


# after
import myCommands

@commands.command()
async def add_numbers(self,  ctx, *args):
    result = myCommands.add_numbers(args)
    ctx.channel.send(f"The sum is {result}")

With the latter implementation, we can now implement test_add_numbers() without needing to worry about any of the async/websocket Discord api stuff.

Will implement

I have not attempted to dutifully reproduce this bug, however I'm pretty sure this is the case:

Listkeeper.selected_list is not separated by guild! The bot only knows which is the most recent list it has dealt with.

Fixing this should be relatively straightforward. In cogs/Listkeeper.py:

1. Listkeeper.selected_list should be implemented as a dict with keys {guild_id : Collection} (Union[Dict[str, Collection], None])
2. References to Listkeeper.selected_list should be updated to reference Listkeeper.selected_list[str(ctx.guild.id)]

With the addition of Listkeeper, some of the functions of which take several args / flags, it would be helpful to implement a proper argparser. Some of the functions have relatively busy top sections which are purely deciding whether there are args/flags passed and handling them accordingly; not elegant.

A handful of server/user-specific things have hard-coded values. For example, the server channel "groovybot-corner" where music bot commands are allowed to be used.

These should be swapped for a config file / environment variables that can be set from outside of the code!

It seems that Discord.py is deprecated and will no longer be maintained. Big sad.

Will need to find a new library to replace it.

I've read in passing that "pycord" is a fork of Discord.py, and may only require some very small changes in order to keep my current codebase operational.

Research required.

UPDATE

With the new addition of Discord "Buttons", perhaps use those instead of indexes!!

I can imagine several ways of implementing them, some experimentation will be needed.

Docs here for reference.

It is a hassle to work with lists and items that have long names. It would be VERY nice if lists and items had index numbers that we could use to refer to them instead of having to type out their long names.

I'm almost certain that users would more readily use indexes, so they should probably be the default usage. Perhaps !rm by name would merit adding another flag !rmitem -n/-name "This item has several words".

Example:

Test List With A Long Name
A description for this verbosely-named list.

• This item has several words
  • Hello there everyone!
• There are a handful of extra words in this item
  • A note to clarify the meaning of this item

Before

!rmitem "There are a handful of extra words in this item"

After

!rmitem 2

When working with the Listkeeper cog, text channels get cluttered and spammy very quickly. In order to cut down on this slightly, bot should add 👍 reactions to successful command executions instead of sending a reply to the text channel. Not only will this reduce notifications in text channels, it will be much easier for users to look back and read what commands were executed.

All changes will take place in cogs/Listkeeper.py, usually toward the end of functions. I'm not exactly sure how to add reactions at this moment, but it's likely to be something vaguely along the lines of

- await ctx.channel.send("Successfully added note 'This is a test item for a list!'!")
+ await ctx.message.add_reaction(":thumbsup:")

Would be nice to have a cog with commands like:

!anydeal [--all] [--store store-name] game-name

"The lowest price found for {game_name} is {price} from {store}. URL: {url}"

"No exact match found for {game_name}. Did you mean:

1. ...
2. ...

Even further, maybe a !suggest command that integrates this API also:

!suggest game-name That returns an embed with full information about the game in the steam store including banner, description, price, etc

API docs found here

R.I.P Groovy.
When a message contains 'groovy', SparksieBOT should now respond with a more positive and sentimental reply commemorating GroovyBot.

Change will be in the on_message event section of baby_bot.py.