ajaxnz/geas-bot
1
0
Fork 0
forked from viveksantayana/geas-bot
Code Issues Pull Requests Projects Releases Wiki Activity

Debugged membership sign-ups and pitch menu.

Browse Source 
Ready for more rigorous testing.
This commit is contained in:
Vivek Santayana
2021-07-24 17:58:23 +01:00
parent 173aeb2a3c
commit e30e89e7e3
13 changed files with 356 additions and 245 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
README.md
View File

@ -31,6 +31,7 @@ DATA=(Path to data file. The bot defaults to './data/data.yml' if not provided.)
LOOKUP=(Path to the game role lookup file. The bot defaults to './data/lookup.yml' if not provided.)
GM=(Path to the GM lookup file. The bot defaults to './data/gm.yml' if not provided.)
CATEGORIES=(Path to the channel category lookup file. The bot defaults to './data/categories.yml' if not provided.)
PITCHES=(Path to the pitches data file. The bot defaults to './data/pitches.yml' if not provided.)
BOT_VERSION=(verson string)
BOT_MAINTAINER_ID=(Discord user ID of the person maintaining the bot to enable debug features.)
```
@ -74,7 +75,9 @@ in order for to authenticate as the correct bot.
| | | |-- on_guild_role_update.py
| | | |-- on_guild_update.py
| | | |-- on_message.py
| | | `-- on_ready.py
| | | |-- on_ready.py
| | | `-- secondary
| | | `-- pitch_listener.py
| | |-- membership
| | | |-- membership_verification.py
| | | `-- restriction_listener.py
@ -194,8 +197,10 @@ There is currently no way of having an exception for the Bot's edits.
To reconcile this, the bot would need to work such that the command process that modified games only acted upon the roles, which would then trigger the event listeners to synchronise these changes with the categories, and subsequently the data.
Having the bot edit the data in the main command process would mean that there would be conflicts with the simuntaneous execution of parallel threads.
This works for individual commands, but it breaks down when trying to use the `purge` command because of conflicts causedb by simultaneous changes to the data files.
Programming around this will need a further layer of complexity, involving flags checking for R/W operations and a time-out.
### Membership sign up performance issues
The way the membership signup prompt works is that it creates a new instance of the process executing for each member who submits a verification request, and the command runs until the verification is complete (either by verifying it or rejecting it).
This means that there is a risk that several active instances of the command will run simultaneously if a lot of members submit membership confirmation at once.
This should probably also be changed to being a global event listener, with the requisite inforation being passed to the function in the event listener via the custom values of the buttons and drop-down menu options.
I have set the member verification prompt to use a global listener to avoid a situation where it creates several backlogged processes when multiple people post sign-ups at the same time.
This should also mean that the sign-up prompts should persist over reboots.