Fishsticks V18 Progress Update

Last month, I discussed the plans laid out for V18. Progress has been under way, but with the increase in work and my own general lack of attention to my need to work on the update; it’s been slow. Fortunately I have been making at least some degree of progress. Since the update plans article, I have pushed 2 staging commits to the Fishsticks repository for V18 and both of them are stacking up to a very fine update. This article will likely be short and sweet, but I’m going to attempt to cover some of the ground that I’ve covered in development. Due to the amount of stuff back here that I’ve changed, I won’t be referencing this directly to the update plans article but I will be referencing the current live version of Fishsticks (V1.17.6). You might consider this a sort of pre-release changelog as it stands.

• Completely refactored events handlers (the gizmos that fire off other things):
  • Command handler: I’ve done a massive amount of backend work on this one. Command handling has shifted entirely to it’s own module that is fired off when a command is received. After making sure that the bot is not talking to itself, the command is then validated for FSO so that it is made certain the issuer has access to the various other features of Fishsticks. Following this, commands are now broken down and stored in a re-purposed variable. In the current version of Fishsticks, the cmdvariable would hold the parameters for whatever command was sent. Now, it serves as the end all object for the properties of the message sent as well since it includes the message object itself. This makes firing off commands easier to send and is more performance friendly.
  • Startup/Ready Handler: Fishsticks’ startup sequence has been redone to it’s (near) entirety. Previously when the ready state was fired (the point where Fishsticks is presumed to be fully online and ready to receive commands), all Fs did was to send a small message to the Fishsticks console that would be removed after a few seconds. Now, it processes a (simplified, more later) set of data that outlines a couple things about the startup. Things such as when the last startup time was and how long it’s been, etc. FSO status connections are made and verified and the presence is set (as normal).
  • New handlers have been added (but not yet fleshed out); warn, error(for when something happens between the Discord.js API/Discord services and the Fishsticks client), voiceStateChange (triggers when someone enters or leaves a channel; used in temporary channels), guildMemberAdd, guildMemberRemove(triggers when someone joins/leaves the server respectively), andmessageReactionAdd, messageReactionRemove(triggers when a reaction is added/removed respectively – used for the poll system).
• FSO Reconstruction: put simply, Fs is moving away from MySQL standard API/commands to what is called a NoSQL system. FSO will be based on a new system called RethinkDB which is a document based database (similar to MongoDB, which is what Discord uses for it’s server clusters). It is very fast and processes data in manner that JS applications (majority of web-applications and others using JSON storage) in a very efficient and retrievable manner. FSO data will be recorded here and available at any time via command. Fs also uses FSO to store all variable information between restarts such as session count, docket points, commands sent vs. completed, and eventually the XP system, plus so much more.
• Module performance optimizations: V18 is seeing a complete revamp of how Fishsticks shunts data to functions for processing. Previously (current V17), Fs would handle functions via requirements nodes at the start of the script and would call on it when necessary. Each of those nodes would be it’s own script and would be categorically stored in a folder. V18 changes that. Each module is it’s own category and each function node is handled within that module. Modules that require the services of another are called from the module in question by the command and is no longer needed by the command itself. A series of chain requests that cleans up both the code and the filetree.
• Per command changes:
  • Execution: the core script command handler that is fired when a command is issued in chat will not fire off a module call that will run the command dynamically. This is very similar to the current setup except that each command now handles the commands on a function level instead of a full on module export. This lets commands export more than just a single function (run) which is executed by the handler.
  • Help: due to the above change, commands will now have a new module export called help that comes standard with all commands. This is executed by the !helpcommand. This is very good because now command help is not limited to strictly a giant embed in the help command but is rather dynamic in nature and automatically adapts when new commands are added or removed and can be edited on a per command basis.
• Other performance/system optimizations and changes:
  • Fs code is now seeing a standardization protocol wherein code added/refactored is being linted for equality across the entire codebase.
  • Command verbosity is being added so that various alternative commands can run the same thing. ie, !roll and !dicedo the same thing now.
  • New utility functions:
    • Message embeds are handled by an embed handler, making embed additions on a per command basis much easier.
    • Time utils standardize server/system date and time across all commands.
    • User utilities grant commands the ability to access a universal permissions checker and FSO validator.
    • Console logging is now run through a util adding severity levels before the message; this makes error/bug crushing much easier to locate.

Mmmmm, tasty copy pasta. Yup, the original can be found here.