LCARS 2nd Generation Architecture

From LCARS Database
Jump to: navigation, search


The LCARS 2nd Generation Architecture is the framework in which the Fishsticks Discord bot operates. It is a vast improvement over the obsolete LCARS 1st Generation Architecture which was based on a solitary script.

Capabilities & Structure

The 2nd Generation Architecture was designed to eliminate the use of a solitary script as a foundation for a Discord bot. In comparison to the 1st Generation Architecture, the 2nd employs the use of various "handler" mechanisms that handle the commands and needs of the bot. Commands are filtered through a series of events and handlers in order to make the commands run appropriately and efficiently. This system for operation makes the entire bot very versatile and modular, allowing for a more detailed and loose build bundled with powerful systems handling.

A bot running the 2nd Generation Architecture runs a significantly lower risk of crashing upon a command execution. The reason for this is that the architecture uses the handlers as an attempt to run an external function called a command function handoff.

File:FS QuickStructureRef 71118.jpg

The figure above displays the system that the Fishsticks bot uses in it's customized framework that uses the 2nd Generation Architecture. The chart displays numerous systems checks and attempts prior to completing a command to verify that the system will follow through. While the architecture is not completely fool proof, it's internal crash-prevention is still much greater than the 1st Generation.

There are very few systems built into the core script, a mere few hundred lines of code. The 1st Generation, since it was centralized, had over a thousand lines of code to make each command run. The 2nd Generation checks each line of text that a channel receives be it simple text or an advanced command. This "on message" event triggers the bot to read it. The message is taken and broken into parts called arguments and passed through a series of checks. In the case that we're using for Fishsticks, it is passed through a few hard-coded checks first and then moves into the handlers. The first of these checks is a twitch link filter. It checks the message for certain characters/phrases that are set in the code and for if the author of the message as "The Nod" role. If so, carry on with the post; if not, move on through the next few checks.

This process of passing through the post Twitch link filter and before the handlers are called hard-coded passive commands and are detailed in the Fishsticks Bot Guide.

After moving through the pre-handler checks, assuming the command hasn't passed any of them, the message and its arguments are passed to the Active command handler. This handler takes the message itself, the commands taken from it, and the bot client and hands them off to an external module. This external module is the command script. The handler checks the arguments gathered from the message and checks for the existence of a command file that matches the attempted command. If one is found, the message, arguments, and bot client are passed to that script and the module runs. The returned response is based off of the completion of the command where if something fails, the bot returns an error message or simply crashes. Successful commands obviously work and you are shown the desired result.

Part of what makes the 2nd Generation Architecture so powerful is this handler ability. Since the handler attempts to resolve and doesn't "tell" it to resolve, the response determines it's action. Crashes do not originate from the core code of the bot, but rather a flaw in a command script. This is infinitely easier to locate and resolve in modular commands rather than a massive script.

If in such cases that an Active command cannot be resolved in the handler, the message, arguments, and bot client are passed to a sub-handler that deals with passive commands. Passive commands function in the same way but do not check for whole statements but rather the first word of a statement.

Each handler logs attempts, errors, and more into the console while performing its action. Commands also log to the console as they were programmed. Handlers and commands all have unique identifiers so it is easier to identify where errors originated from. These console ID's follow the following template: [XXXX-XXX] or [XXX-XXXX] such that they are all 7 characters long and initiate each line of the bot's actions. For example, the Engineering Mode code is: [ENG-MODE] and the music player uses: [MUSI-SYS].

Plans & Enhancements

The sudden appearance of the 2nd Generation Architecture was simply based on the introduction of the modular structure over the static structure of the 1st Generation. As of right now, the active development of the Architecture and further development is handled on the Fishsticks bot. Tests and further development are handled there. However, once the update to LCARS from the 1st Generation to the 2nd is finished, active test development will shift from Fishsticks to LCARS in an attempt to lift the potential burden and server damage risk of unstable Fishsticks code.

Further enhancements and developments are uncertain and not planned currently apart from custom implementations for LCARS and Fishsticks.