Well, I got interested in what I've put into Furbot WX so far, and constructed a quick and dirty tally program to peek into it's guts:

This is a minor update in which while the main focus of the update was to permit the ability to "recurse" procedures, that is, you can have procedures call other procedures, just not have any procedure call a calling procedure, it also address's a couple of bugs in the code.

For example, a gift will either shut the bot down, render it unable to reconnect, or crash, depending on when and how it saw the gift.

The portrait select command was not permitting the user to enter a value for which portrait they wanted.

And a Furcadia installation where the settings was not in an expected default location would cause the bot to fail in making a proper connection.

That I would have a specific agenda for adding features to the program should not be a surprise, what should surprise you is that they do get done.

This particular update addressed the means which was started way back when I first overhauled the bot, the ability to import and export individual commands or groups of commands to and from botscript files. Several issues with the system, naturally, by default, anything imported into a bot will be disabled unless you check the box to have it be enabled. And anything exported from the bot will be enabled. Which also means that another feature system of the bot is now working, if you create a bot via the export means, when opening a botscript file, if it finds that it's the type BotClip, it will open the import function of the bot, and you can select what commands are inserted into the current bot.

Notation, botscript files are plain text, and while there is not a menu option for this yet, regular botscript files may be tagged as an example bot, you just open the file with notepad, and add the following to the headers: ExampleBot=True, and the filename gets zapped from the internal control structure, forcing you explicitly save the bot on exit. Though you don't need to actually assign the value of true to the statement, anything will work, it's the presence of the header that causes the effect.

Overall, this was a monster of a fix, the biggest being that I included a means to hard fix the IP address which furbot uses for connecting to the server. I looked into several different options, finally deciding to go with this method because the possibility may occur in the future where this will be needed again. So now, in configuration, there's the means to not only use the Hard IP address of the server, but also, bonus, select which port you want to use.

Other fixings include the harding the database system to avoid runtime crashes caused by preforming database operations on an unopened database, that's now got a flag which is set when the database is opened. If the botscript executes an operation which requires an open database, and it's not, it won't do anything but deliver an error message.

What's that you ask? What took time?

Why documenting the internal variables of FurBot, what else. Furbot has a rich set of variables which are set whenever an event happens, whether it's someone entering the dream, a whisper, or a DS trigger, and if you don't know what's done where and how, you won't know how to get the best from the bot.

Or worse, whisper me in game, "What variable does the triggering furre's name get put into?"

This, along with the Trigger Events table should be some serious help with figuring out how you want to make furbot do something. All the command tables are in place with the exception of the WolfScript documentation, that's sitting in the unpublished and unfinished area of this site right now, along with a few other things that need to get documented.