Someone appears in the dream 

Y 

Caused when the server sends a Spawn Avatar to the client, also know as "when someone enters the dream", the bot gets the name from the string and stores it into the Who list as well. Other variables filled out are: 

• [PLAYER] - receives the name of the triggering player
• [MAFNAME] - duplicate of player maintained for backwards compatibility
• [MAFUID] - the user id of the player (FUID)
• [MAFC] - the color, species, and gender string
• [MAFID] - the avatar frame (SS)
• [MVX] - the server side X position of the player, this is in "true" coordinates as opposed to "map" coordinates (XX)
• [MVY] - the server side Y position of the player (YY)

The C in the below format string is the length of the name. The F is a flag indicating whether the spawn message is new, or re-occurring, not used with Furbot. All numbers are Base 220.

Format: < FUID XX YY SS C FURRENAME COLORS F

Someone exits the dream 

N 

Caused when the server sends the Remove Avatar to the client, also known as "when someone exits the dream", the bot gets the name from the internal who list based on the FUID of the exiting furre. Aside from the FUID, no other information about the exit is sent, so the only variables which are valid with this command are:

• [PLAYER] - receives the name of the triggering player
• [MAFNAME] - duplicate of player maintained for backwards compatibility
• [MAFUID] - the user id of the player (FUID)

Format: ) FUID

Note that this follows the rules above on the Don't Process Furre Manifest. 

Someone comes into view 

Y 

Caused when the server sends the Move Avatar to the client, this is not the same as Animated Move, this one "moves" the Avatar into view, the Animated Move is sent only when the furre uses movement commands, this is sent when DS moves an Avatar as well as when someone walks into view.

This is blocked by the Don't Process Furre Moves.

• [PLAYER] - receives the name of the triggering player
• [MAFNAME] - duplicate of player maintained for backwards compatibility
• [MAFUID] - the user id of the player (FUID)
• [MAFID] - the avatar frame (SS)
• [MVX] - the server side X position of the player, this is in "true" coordinates as opposed to "map" coordinates (XX)
• [MVY] - the server side Y position of the player (YY)

Format: A FUID XX YY SS 

Someone goes out of view 

Y 

Caused when the server sends the Hide Avatar to the client, is actually a square outside the viewable area of the client, same can be said of the above Move Avatar.

This is also blocked by the Don't Process Furre Moves.

• [PLAYER] - receives the name of the triggering player
• [MAFNAME] - duplicate of player maintained for backwards compatibility
• [MAFUID] - the user id of the player (FUID)
• [MAFID] - the avatar frame (SS)
• [MVX] - the server side X position of the player, this is in "true" coordinates as opposed to "map" coordinates (XX)
• [MVY] - the server side Y position of the player (YY)

Format: C FUID XX YY

Someone moves 

Y 

Caused when the server sends the Animated Avatar to the client, this is the command that actually causes furre's to waltz across your screen, that is if you got your F11 animation set to see such, otherwise they will just hop from place to place, your F11 setting does not affect what the server does, just you. The implementation of this command server side is the assumption that your client has a visible avatar at the starting point, and the command sends the new (X,Y) to the client for it to move the corresponding avatar.

This is also blocked by the Don't Process Furre Moves.

• [PLAYER] - receives the name of the triggering player
• [MAFNAME] - duplicate of player maintained for backwards compatibility
• [MAFUID] - the user id of the player (FUID)
• [MAFID] - the avatar frame (SS)
• [MVX] - the server side X position of the player, this is in "true" coordinates as opposed to "map" coordinates (XX)
• [MVY] - the server side Y position of the player (YY)

Format: / FUID CC YY SS

Caused when the server sends the Update Color Code to the client, while this one is not processed by the bot, I figured it wouldn't hurt to include it in this list. If you do need to process this command, it can be captured with Furcadia sends command {B*}, and do note the * in the command, that wildcard is needed. You will have to break down the components of the command yourself, WolfScript will have a BASE220INT conversion function available for you to use.

Format: B FUID SS COLORS 

Someone tries to join 

N 

Caused when someone does a `join to the bot. The verbiage processor detects the command in the string and executes the trigger function with the [PLAYER] variable filled in. At this time, [SHORTNAME] is not filled in.

Someone tries to summon 

N 

Caused when someone tries to summon the bot. The verbiage processor detects the command in the string executes the trigger function with the [PLAYER] variable filled in. At this time, as much as I would like to, the map to which the bot is being summoned can't be easily extracted from the string.

Desc and color trigger is activated 

N 

This event is caused once the bot has gotten a description from the look command, the event is actually divided into two sections which are processed in order. The first event the bot sees is the Portrait & Colors string from the server, this fills in the [COLORS] part of the event. The next thing the server will send, if the looked at player has on, is the Custom Portrait string, this is why you get that before the Custom Portrait downloads. Hey, got to have something to look at. The description catch is executed when the bot finds the markup tag for the description in the string. 

An emit is seen 

N 

Covers all emits image headers currently found in system.fsh, with the slight problem of emits which are preceded by the "paw" icon (), like  when found with the message the receiver of a gift sees:

Dreamless Dancer just gave you a Candy Cane!

I'm going to fix that where it falls through because the first thing the bot does is run it through the WhoList processor due to the initial paw that's seen. That bug aside, the emits are translated into an Ascii character in addition to the processor filling in the variable [EMITICON], for a full list of translations, see Emit Translations for the list. When your function is triggered, you get the entire message in [MESSAGE].

Banish reply is detected 

N 

Executes when the bot sees a banish reply from the server and the bot was the instigator of the command. Very important to remember that, if you manually type in a banish command from the bot (or client), this does not trigger! Currently, the following types of replies from the server are processed, and are checked in the following order:

1. Banish Success, the bot successfully banished the name from the bots dream.
   1. [BANISHCODE] = BanishSuccess
   2. [BANISHNAME] = Furre Name
2. Banish Many, the server coughs and tells the bot that there's many names matching the one it attempted to banish.
   1. [BANISHCODE] = BanishNameMany
3. Banish List, the bot requested the banish list and got it.
   1. [BANISHCODE] = BanishList
   2. [BANISHLIST] = the names of the furre's who are banished.
4. Banish Removed, the bot got the reply from the server that the named Furre's banishment has ended.
   1. [BANISHCODE] = BanishOff
   2. [BANISHNAME] = Furre Name
5. Banish Removal Failed, the name was not on the banish list. Name not included.
   
   1. [BANISHCODE] = BanishOffFail
6. Banish List Empty, there was nobody on the list, whoops!
   1. [BANISHCODE] = BanishNoBanish
7. Banish Removed For All, the server reports that all banishments have ended.
   1. [BANISHCODE] = BanishOffAll
8. Banish Self, sorry Charlie, you can't banish yourself from your dream.
   1. [BANISHCODE] = BanishSelf
9. Banish Name Not Online, you can only banish people who are online, so this is a failure to banish someone.
   1. [BANISHCODE] = BanishNoName
10. Banish Instructions, well, gotta include this, can get this if you issue either a banish with no name, or a banish-off with no name. However, the syntax for the banish-off command is that if you leave the name part blank, it becomes the banish-off-all command, so you shouldn't get that warning.
    
    1. [BANISHCODE] = BanishWarning

And in all the cases above, the actual string is stored in [BANISHACT] for you to do things with.

Furcadia sends command {EVENT}

Y

This is the general catchall service for all the commands the server sends which furbot does not have a native trigger action to, say like the sound triggers, or perhaps you want to implement an online detection system. In such cases, providing the parser IS letting the command get to this point, you can create your own trigger with this. Except in this case, you have no system variables to work with except for the [MESSAGE] variable which will hold the entire event, you're on your own for making things work.

The exception is when the bot gets a camera move command from the server, in which case, before calling on the trigger function, it preloads 4 variables for you, [BX], [BY], [BX2], & [BY2]. There's two types of Camera Moves, DS'ed, and Self Powered. If it was a self powered move, you will have the From position in the second set of variables, otherwise they will be Zero. In both cases, the first set of variables is the position to which the client has been instructed to move the camera to.

Camera Move format: @ X1 Y1 X2 Y2

Procedure 

A procedure is a function which you can call from other parts of the botscript, it does not have to be a trigger to call on it. It's a means to  create common code which is used several places, helping you to avoid rewriting code several times that does the same thing. The user buttons will also use procedures to contain the code they execute. Currently, you can't call a procedure from WolfScript because if the procedure contains WolfScript, the currently executing WolfScript will become corrupt. The botscript command you use is:

Execute Procedure {Procedure Name}

The bot enters a dream 

N 

Executes when the server sends  either the ;mapname.map or the ]q td command to the client. They both will load the [MAPNAME] variable with the name of the map, and in both cases, will erase the player list, and if the bot is operating without the client, will also send the vascodagama command back to the server.

]q td252346322 252346322 <- for normal player uploaded dreams.
]q pmsnowalleg2 1783379717 <- for DEP uploaded dreams, the second number is the CRC for the dream.
;NewVinca.map <- using a default map. 

DS-trigger # is sent 

Y 

This is also known as the Seven trigger, this is executed whenever the server sends the command string to the client to execute "Other" DS, that is, DS that was not triggered by the client doing something in the dream. This can be broken down further than what the bot does, the entire message is passed to the execution in the [MESSAGE] variable. For the most part, you don't need to get this nitty gritty with the DS, the sole purpose of the function is to give an indication to the bot that a specific line, or range of lines, has caused the Seven trigger. The following variables are filled out for you to work with in testing and governing what it is that you are wanting to do:

• [DSX] = first X position of the trigger (XA)
• [DSY] = first Y position of the trigger (YA)
• [DSX2] = second X position of the trigger (XB)
• [DSY2] = second Y position of the trigger (YB)
• [DSID] = first line that caused the trigger (L1)
• [DSIDX] = first X position of the trigger line (X1)
• [DSIDY] = first Y position of the trigger line (Y1)

Note that the X position is in server coordinate, not map coordinates, and the numbers are Base 95. The event continues for as many lines that are included in the trigger, starting with the L1X1Y1, it keeps that arrangement until your run out of triples. The example format shows this:

7 XA YA XB YB L1 X1 Y1 L2 X2 Y2 L3 X3 Y3

The bot triggers DS # 

Y 

When the bot causes a DS trigger, also known as a Six trigger, the same rules governing the breakdown of the command, and the format of the command string is like the Seven trigger above. However, we use a different set of variables, unless a flag (not installed) is set to instruct the engine to use the same variables as the Seven trigger.

[BOTDSX] [BOTDSY] [BOTDSX2] [BOTDSY2] [BOTDSID] [BOTDSIDX] [BOTDSIDY] 

Connection establishes

N 

This event is fired whenever the bot successfully makes the connection to the server, this does not indicate that a valid connection is made, just that the socket connect request was accepted by the server. This is only called from one section of the bot, the WinSock Procedure for the client, when the client makes connection to the proxy. 

Connection closes 

N 

This event is fired whenever the connection is lost between the bot and the server. This is only called from one section of the bot, when Stop Services is executed. 

FurBot has logged in Furcadia 

N 

This is fired once the bot, or rather the client, has sent the username & password to the server, and we spot commands from the server that gives us an indication that, yes, we did make contact. There's two indications looked for, and if found, switches modes of the engine from pass through to process mode. Very important to know this, the engine does nothing with the datastream until it gets this indication that the server is willing to talk to the client.

Program starts 

N 

This is not quite named right, but the context in which it's meant works. This is called right as soon as the bot has loaded the botscript.

Program ends 

N 

And likewise, this is called right before the botscript is dismissed from memory.