AardWolf / MHTimerBot

Discord bot that understands mousehunt timers
MIT License
8 stars 12 forks source link

Command class structure #97

Closed tehhowch closed 4 years ago

tehhowch commented 6 years ago

Right now we just have keywords with some self-written documentation. Ideally we would do something more traditional, e.g. implement each command keyword as a Command class and support things such as cls.getHelp(), etc. for greatly simplified code within parseUserMessage.

This approach is recommended in discord.js documentation: https://discordjs.guide/#/command-handling/

I'm opening as an issue since I don't have the time to do it right now, and it's something that you may prefer to do yourself anyway.

AardWolf commented 6 years ago

Reading through the guide and thinking of the code, keeping notes for myself for later.

For example, to implement find and/or ifind in their own command file(s) they should probably also manage their own group of nicknames and their own array of names that Jack's tools know about that are relevant. Currently these are bot-global structures but there is no overlap for them.

Similarly, the remind command would have a startup/init routine to set appropriate timeouts for every timer as the remind loop (only sends PMs). It would manage loading/saving reminders as appropriate (maybe using sequelize: https://discordjs.guide/#/sequelize/). Timers would be loaded as part of the next and/or sched command and would schedule their announcements.

It's possible the timers loops need to remain global in which case an additional collection of timer objects would be loaded for the time-related commands. Or some objects remain global and commands can use the - nicknames, mouse list, item list, and timers seem like good candidates so they can potentially be reused for future commands (whereis to find locations items can be acquired [shops, areas dropped])

AardWolf commented 5 years ago

Thinking this through more - main js file could have the "globals" - things like managing nicknames, mice names, filters, etc. Then each command can have its own file and appropriately know about these globals.

So startup means reading the reminders and timers, setting the appropriate repeats, saving, etc. Then there's a new file for the command "remind" which can read/modify the reminder structures. remind is a good use case, mildly complex but not entangled with other commands.

AardWolf commented 4 years ago

162 is nearly done and sets up the framework for this but before I feel like it can be closed I need to add a test module as a model for future assets to be added.

So how does one test a command like iam using tape. It requires a Discord.message that has particular bot properties. The underlying functions also require this, as written.

AardWolf commented 4 years ago

169 was released. Leaving open until "all" commands are moved.