This is the folder from which furbot is running from, default on most systems will be C:\Program File\Furbot WX\

This is the folder which furbot generates in your Documents folder, that is, if it can find it, otherwise it will default to being the same as APPDIR. Note that once you set the logging system on for the bot, that is, to instruct the bot to create connection logs, the program will create a LOGS folder in that folder.

This will be your furcadia installation, generally C:\Program Files\Furcadia\

Very cool addition to furbot, this is the folder which the current botscript was loaded from, means you can apply some means of separation to your various bots that you use. As an example, I've already modified Dream Makers Guild to use a specific folder in my BOTDIR folder for all it's data files, now my WX folder looks much cleaner, and I know where to go to find all my data files.

Note: Because furbot now saves the botscript files as plain text, it is now possible to use a text editor program to do a search and replace on your botscript, and make massive changes to it. In the above reference to modifying DMG to use SCRIPTDIR, I did just that. Beware however if you got extensive WolfScript in the bot which also makes use of main variables, depending on your coding habits, you need to ensure that if you're using, say, APPDIR in your WolfScript, you do a search and replace on the variable without [brackets].

Stopaction is initially set to "NULL" when entering an action, specifically set by the WolfScript functions &ACTCONT and &ACTSTOP, this causes an override of the default action to take when the entire command finishes executing. &ACTCONT sets this to be "FALSE" while &ACTSTOP sets it to be "TRUE". Do note that, this is part of the internal structure of the botscript file, if the Stop Action is checked, that means the internal flag is set TRUE, so setting this value to FALSE, via &ACTCONT, will cause the bot to continue checking and processing commands until finished, or it's reached another command which also matches the parameters of the Trigger or Action that has the Stop Action checked. Likewise, if normally the command would permit continuing down the list, setting this to TRUE, via &ACTSTOP, will end the command checking AFTER it finishes processing all elements of the command.

Because the engine continues checking elements of the command, it is possible to toggle the state of this variable back and forth during the execution of a single command. Currently there's not means of checking the actual Stop flag of the command, nor to be able to set it back to "NULL".

Exitaction is a drastic command, and will cause the engine to quit processing elements of a command when it EXITS the WolfScript engine. The main engine will continue with normal command checking and processing depending on the Stop Action setting, either of the command, or as set with the above variable. Unlike STOPACTION, this is a pseudo boolean variable usage, it's either True, or False. When the engine begins processing a matching command, this is set to "FALSE", once you use the WolfScript command &EXITACT, the engine will quit the command once it exits the WolfScript engine. Unlike the STOPACTION, this is available in all 4 command systems of the bot, so you can use this to quit processing a timer or whois command. Currently, there's no means to unset it, once you execute the command, you're done for, but like all variables in the bot, the status can be gotten with the &GETVAR command in WolfScript.

Contains the name of the bot, very handy with ensuring that the bot only operates in the dream it is the uploader of. Once you get the dreamname, you can use a simple AND check of the botname against the dreamname, and if both are the same, your code which does emitting and sharing and what not will do what it's supposed to, and prevent all them wonderful error messages from the server when things go boom and the bot lands someplace unexpected.

if variable {[DREAMNAME]} is the same as {[BOTNAME]} (text comparison)

Handy variable if you do extensive updating of the bot's description on the fly, and you need to reference back to what the description was when the bot connected to the server. For example, with DMG, I update the description every couple of minutes to indicate the bot's running time as well as the length of time it's remained connected. So my timer function does this:

Change description {[newdesc] [onlinetime] / [connecttime]}

And the code previous to this line loads [newdesc] with the original [botdesc] and does a check on whether it's holding the colors of someone who gave it a cookie, and if so, includes that as well. (Note that DMG is a sponsor.)

Final variable which is loaded when the bot connects. Overall, might not be useful to all, however it's available to be used if the user so desires.