Well, a list of new stuff since I last worked up such a list:

1. WolfScript
   • CONTROL
     1. EXITACT
   • DATABASE
     1. DBEOF(DatabaseID)
     2. DBEXECUTE DatabaseID SqlExecuteCommand
   • LOGFILE
     1. TXGETENTRY(FileName RecordName EntryIndex)
   • MATH
     1. FIX(Number)
     2. INT(Number)
     3. SQR(Number)
   • STRING
     1. FORMAT(ValueToFormat FormatString)
     2. SPRINTF(SourceString %1 ... %9)
2. Conditions
   • DATABASE
     1. $DATABASE: If field {#0) in table {#1} doesn't exist in database {#0}
        • 0 FieldName
        • 1 TableName
        • 2 Database ID
     2. $DATABASE: If field {#0) in table {#1} exists in database {#2}
        • 0 FieldName
        • 1 TableName
        • 2 Database ID
     3. $DATABASE: If table {#0} doesn't exist in database {#1}
        • 0 TableName
        • 1 Database ID
     4. $DATABASE: If table {#0} exists in database {#1}
        • 0 TableName
        • 1 Database ID
   • LOGFILE
     • $FILESYSTEM: If file {#0} does not exist
       • 0 Filename
     • $FILESYSTEM: If file {#0} exists
       • 0 Filename
3. Commands
   • CONTROL
     1. Set user button {#0} to run procedure {#1} with the caption of {#2} and tooltip of {#3}
        • 0 Button number (0-7)
        • 1 Procedure name
        • 2 Button Caption (Avoid Wrapping)
        • 3 Tooltip (Optional)
   • WEB
     1. $WEB: Combine the URL {#0} data into variable {#1} optionally adding onto {#2}
        • &0 GET assumed/GET,POST,USER
        • 1 Variable to use
        • 2 Optional prefix data
     2. $WEB: Remove the URL member named {#0} from the {#1} stack
        • 0 Parameter to remove
        • &1 GET assumed/GET,POST,USER,ALL
     3. $WEB: Reset the {#0} URL parameter stack
        • &0 GET assumed/GET,POST,USER,ALL
     4. $WEB: Set URL {#0} Parameter {#1} to the value of {#2}, Strip Special Characters {#3}
        • &0 GET assumed/GET,POST,USER
        • 1 Parameter Name 2 Value to use
        • &3 False assumed/False,True
     5. $WEB: Store the URL parameter named {#0} from the {#1} stack into variable {#2} {#3}
        • 0 Parameter name
        • &1 USER assumed/USER,GET,POST,ANY
        • 2 Variable to use
        • &3 Decoded assumed/Decoded,Raw
     6. $WEB: Store the URL string {#0} to the {#1} stack
        • 0 String to use
        • &1 USER assumed/USER,GET,POST
     7. $WEB: Transfer, Merge, Exchange, or Copy: {#0} the {#1} stack to the {#2} stack
        • &0 Transfer assumed/Transfer,Merge,Exchange,Copy
        • &1 GET assumed/GET,POST,USER
        • &2 USER assumed/USER,GET,POST
     8. $WEB: WebFetch, using {#0}, follow redirection {#1}, include GET parameters {#2}, to variable {#3}
        • &0 GET assumed/GET,POST
        • &1 Follow assumed/True,False
        • &2 GET include assumed/True,False
        • 3 Variable to use

Got a documentation page up for how to use the WebServer access functions in Furbot, and made a couple of minor adjustments to the coding of the system.

There was apparently a bug, or quirk, in the server command parsing switch where if you got a command from the server in which there was no native means of decoding, you were out of luck. Well that's been fixed, however, it's OFF by default. You can turn it on either with the special variable [$PROCESS_OTHER_COMMANDS], just set that to TRUE, or you can enable it under the advanced bot settings. Note that I do NOT recommand that you run the bot with that enabled all the time, hence it's OFF by default, because all the unhandled commands are passed to the trigger processor, like sounds, play music, the Eight triggers, ...

Also made a modification to the WolfScript command FURCTOINT, if you pass it a second parameter of TRUE, it will decode the passed string in Base220 instead of Base95. This was also important because you can now do something like this:

Trigger Name: Process Object Manifests
Furcadia sends command {>}
   No Additional Conditions.
THEN:
$ Begin Wolfscript: (1)
// decoding object manifests
&newvar #message &mid(&getvar(message) 2)
&newvar #posx
&newvar #posy
&newvar #count
&newvar #object
&newvar #loop &len(#message)
&newvar #results {Objects: }
&newvar #temp
&div #loop 6
&for #index=1 to #loop
  &set #posx &furctoint(&mid(#message 1 2) true)
  &mul #posx 2
  &set #posy &furctoint(&mid(#message 3 2) true)
  &set #object &furctoint(&mid(#message 5 2) true)
  &set #message &mid(#message 7)
  &set #count #posy
  &div #count 1000
  &set #count &int(#count)
  &set #temp #count
  &mul #temp 1000
  &sub #posy #temp
  &set #temp {(%1,%2)[%3,%4] }
  &set #temp &replace(#temp {%1} #posx)
  &set #temp &replace(#temp {%2} #posy)
  &set #temp &replace(#temp {%3} #count)
  &set #temp &replace(#temp {%4} #object)
  &join #results #temp
&endfor
&display #results

Oh woot?

BTW: Floors are first character in the message being 1, while walls are 2. And with wall manifestations, the #POSX is NOT multiplied by 2.

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:

One of the things that Variables does not count are Variables that are passed to various Subs and Functions as parameters. So that count is rather off, boost it to maybe 750ish and it may be closer to right. I'll tinker with the code for making this table another day. Also, in MessagePump is the core message parser, which is about 1,200 lines of code.

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.