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].

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.

These two variables will contain the count and names from the Spawn Avatar's seen by the client, it should be considered more reliable than the variables below because they are updated constantly. Every time someone enters the dream, they get put into the WHOSTACK (Internal Structure), and when they exit the dream, the name is removed from the same stack. It is reset when the bot enters a dream and repopulates automatically. Not reliably watchable, you need to be watching something else in order for the watch window to update them. 

These are more of an internal variable available to you, they are only set when the bot process's a Who List, until you do execute a Who, they remain empty. Like the above two, they are reset when the bot enters a dream, and remain empty until you execute that who. Unless you have a good system set up in regards to using the Who, you should not rely on them. 

The name of the dream itself, this is cleared when the bot enters a map, as indicated that the bot spotted the "Load Map" or "Load Dream" command from the server. The name of the dream is gained from the first Who the bot does, if you're on a public map, it will be "PUBLIC MAP" and that is with a space, not a pipe ( | ) in the string. 

The dream's URL, gained when you say "dreamurl".

Varies, just a bit. If you enter a Public Map, it will be the map's name, if it's a downloadable dream, it will be the ID of the download. In theory, it should be possible to use this to reload the dream, providing the server has not cleared it from the cache, by using the right combination of commands to register the dream. Note that the dream must be "owned" by the uploader for this to work. The program is loading the full ID of the download into the variable, and the commands to register the dream only require the numeric portion of the ID.

This is the numerical index of the system.fsh image used as the header of an emit, for a list of what the number will be for a particular emit, just head on over to the Emit Translation Table and look it up. The most common one you will be interest in is #91, the , which is used with all emits from players and DragonSpeak. Capturing emits is easy, just use the trigger "An emit is seen", add in an additional condition check on which emit icon was part of the emit, and you have a valid capture. The tricky part is parsing the emit if you're using emits to transmit dream data to the bot, you need to plan out your format, and check the various words of the emit itself to ensure that it is your emit, and not a spoof by a visitor to your dream who's figured out the format.

Strange catchall which gets information from the logfile system that indicates in some cases what the results of the last $LOG command was. For some of the status strings which are returned in this variable, read up on the $LOG commands.

Yes, the results of lag checking is available to the bot, there was no reason to not have this available to you, the programmer, so you can take actions, if need be, based on how badly the connection is lagging. The system uses ping pong, if lag checking is enabled, you won't see the pong, the program eats the message.

Currently, the time is set to 60, later versions of the bot may provide a means to dynamically adjust the time within limits. 

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.