The bot runs on top of Mudlet (a multi-user dungeon client). It is an odd fit but Mudlet is a telnet client with LUA scripting support and features triggers, timers and scripts which makes it ideal. When you first run your bot and connect it to your server, the script FirstRun is executed. It just sets some control flags, but you could add anything you want to run first here. There are comments in the LUA code and more is added occasionally. The code itself is quite easy to read and the main challenge is learning what triggers each code block.
Mudlet is event driven and the next script that runs is StartupBot which sets up many things including connecting to the databases. The server then requests the telnet password which triggers the Login trigger. If the login works, the Login Successful trigger runs which sets some more flags and sends several commands to the server to gather information such as who are the admins, players, banned players, server settings and more.
Your bot is now running, connected and initialised. Several timers run which cause the bot to send commands to the server and perform several other tasks. I use timers to pace the bot so that it doesn't spam the server too quickly and to give order to the various tasks that it needs to run repeatedly. Everything else is triggered from telnet activity that determines which script runs in response. Triggers and scripts use pattern matching on the current telnet line and activate when a match is made.
The code is organised into many scripts, each containing code and commands that relate to each other such as admin commands, teleport functions, and inventory scanning. The largest block of code processes game chat and begins with the trigger GMSG which detects GMSG lines in telnet, gathers info from the line into a temporary LUA table and then calls many gmsg scripts until one of them sets a flag indicating that it ran a command. If the flag isn't set, it checks to see if the line was a request to teleport to another player or waypoint. Finally if it didn't match a command and wasn't a teleport request it will tell the player that they gave an unknown command. It will also do this if the player tried a command that they are not allowed to use.
Another large block of code reads and writes to the IRC server. However the heart of the bot is the trigger called playerinfo which runs when the server responds to the 'lp' command (list players). This trigger reads the player's position and several stats and other data. The information is recorded and many bot features and functions rely on it. If this trigger stops working, the bot won't know where players are and won't be able to manage them effectively. The modular nature of the code means that major functions can fail but not necessarily break the bot. Other functions will still work. This trigger is able to detect when it is broken (which is usually just a matter of missing data) and can attempt to repair itself by collecting the missing data or filling in the blanks with default values. Once the fault is fixed, the bot is then able to gather real data and function normally. Fault detection and repair is coded in several parts of the bot in an attempt to make the bot as fault tolerant as possible and to save you from debugging problems that could be fixed this way.
Many scripts are contained in functions even though they are only triggered when certain conditions are met. This is done because LUA will immediately execute the code after you edit it even though the condition that should trigger it isn't met. If you aren't editing the bot live, you could edit the call to these functions so that it just runs them rather than re-testing the line for the presence of the trigger text.