xeckt / neo

A modular and friendly Discord bot written in Python.

Gists

neo's Issues

Create a module system

A common goal in this project to reach is to create a versatile system on which the bot runs. This versatile system is along the ideas of being able to edit current features within the bot. These features aren't limited to logging, database, things like games as well as the types of interaction -> removal, moving, disabling, enabling. Sort of like a "plugin" system.

Firstly we'd need to completely fulfill requirements with Discord and discordpy. This is simple enough as you really need next to nothing to have a running bot.

Next is how the module system would actually work. We'd need a simple system that wouldn't be too convoluted on disabling and enabling modules primarily. It's probably a good idea to set "default" modules one could load to enable some form of "profile" type behaviour. It may even be a consideration to even make it behave like discordpy's bot_extension.*() for cogs

Clean the main bot code and move it to a class

It's about time to clean up the code for the main bot and have everything moved over to a class in which we can interact with the bot. Makes for cleaner access to the modules and getting needed behaviour out of the bot.

It would also be a good idea to clean up the imports throughout the source to clean up object inits and whatnot otherwise we end up writing the whole module path just to initialise.

Adjust Foxcord configuration and role behaviour

• enableBotLog is part of bot rather than logData or an object dedicated to logging

• logData appears to be using single files for each type of logging, but this won't scale with time, and those individiual files will just get bigger. it's better to split logs taken up by day ie. yyyymmdd in the filename which makes the relevant logs you're looking for easier to find and makes it easier to delete/archive older logs (edited)

• commandData having enableuserCommands, enableModCommands, etc. implies a built in categorization system, which isn't necessarily a bad thing, but it means that whatever system of categories isn't easily customizable/is hardcoded. same thing for
  userId, modId, etc.

• userId, modId, etc. implies singular ids, multiple people being able to have the same role is a common expectation of permission and hierarchy systems, especially if mod refers to moderator in the context of moderating servers

Credit: 06000208

[BUG] - Implement error handling

Bug description & behaviour
Barely anything is handled error wise within the source which now needs to change ASAP. It's now at a stable stage so now it needs some care.

There are a few bugs with the recent PR's where file existence isn't being checked and so forth which raised this intervention.

Permissions System

Right now, the permissions aren't handled in a very canonical or dynamic way.

Currently Foxcord is using decorators for each individual command. Some might prefer to handle each command permission individually. However, because the commands are categorized based on standard roles (admin, dev, mod, etc) and are representative to the cog directory naming, this would mean for each command in admin cog directory it should dynamically apply the admin role id permission to those commands, without specifying it via commands.has_any_role() decorator in each command file.

Move sensitive information to .dotenv

Is your feature request related to a problem? Please describe.
No.

Describe the feature you'd like to see added
It's a good idea to move the bot token and database information over to .dotenv files. This would apply well for anything future related.

It also makes sense so the user can specify variables inside the env through their host system so they never expose any of that data.

Convert settings to YAML

Is your feature request related to a problem? Please describe.
No.

Describe the feature you'd like to see
Moving over the config from JSON to YAML is a sensible option. The syntax is more readable for beginners, indentation is easy. This also creates an easier route to have the .dotenv enhancement at issue #10 and the logging changes represented within issue #6 for any interaction between them relying on variables or anything alike.

https://pyyaml.org/wiki/PyYAMLDocumentation

Documentation

Following things need to be done:

• Add comments throughout the codebase for beginners to understand the logic
• Create detailed documentation for beginners using the bot teaching python and how an API is used

Migrate from Discordpy following the discontinuation in April

Follow Danny's public disclosure of the discontinuation of Discordpy we now need to completely move the discordpy module to something else.

Nextcord seems like a good option along with Disnake for the slash command support. It would be a good idea to support Discord new intentions format for April 2022.

This project should be finished long before then so we can get started on Golangs counter-part for the full featured bot.

Database Support

• Create support to be able to connect to a database
• Most likely use asyncpg to compensate for MySQL limitations
• Make database modular in terms of removing / disabling / configuring

There would be no need to create an entire working system for the SQL as each environment will have it's own specifications, databases and table data. The only necessary option to add this feature is to create a function to setup the SQL pool and have it run properly through aio on bot start. Ideally, isolating the startup between the DB and the bot is a necessity so the base bot behavior isn't effected on whether or not there is any use for a database.