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

This is now automatically filled in by the bot because there's a new server instruction provided which is an aid for the client when dealing with the new bookmarkable dreamurl's part of Furcadia Pounce.

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.

The name of the channel that triggered the event, this WILL have the @ sign in front of the channel.

Rather handy element that actually can help in weeding out spoof emits, mainly that a user generated emit will not be the color DRAGONSPEAK.

Contains the ID code of the last Cookie Request Dialog which was seen by the bot.

Contains the number of cookies requested by the last Cookie Request Dialog which was seen by the bot.

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.