Index

Xelagot action script

Events: Chat and messages

The Xelagots can receive, process and send chat messages through various channels. There is a variety of event handlers and statements to cope with all this messaging. This page has three sections: the first one describes the Chat event used for AW chat, the second one describes the 3.3 Console Message event, the third one has an overview of all events dealing with chat messages.

If you wish to stop receiving messages, uninstall the Chat event handler:
OnChatEvent

To install a different Chat event handler, reinstall it this way:
OnChatEvent yyy

Inside this event handler you can retrieve the message and the information about who sent the message, and how it was sent (chat or whisper):

The bot can use one of the many Say statements to answer back. If you retrieve the person with GetChatPerson &p, a whole bunch of information becomes available about the person, and the bot can use Whisper to answer back. As from X1 2.9999950 and Av99Bot 1.66, you can use the generic Reply statement.

An example script: when the bot hears "hello" it says or whispers "A good day to you, John" (if the person is called John), if it hears "bye" it answers "Goodbye, John". It will not answer to bots.

[Head]
Type=Script
Version=2.0

[Settings]
Origin=0.000n 0.000w 0.00a 0.0°

[Script]
  OnChatEvent Chat
Label MainLoop
  Goto MainLoop
End

Event Chat
  $b = ""
  GetChatPerson &p
  IfPerson &p IsBot EndEvent
  GetChatName $n
  GetChatline $a
  IfString "hello" IsIn $a $b = "A good day to you, "
  Else IfString "bye" IsIn $a $b = "Goodbye, "
  IfString $b = "" EndEvent
  # IfChatIsSay SayConcat $b $n
  # Else WhisperConcat &p $b $n
  ReplyConcat $b $n
  # ReplyConcat does the same in one line
  # as the two previous lines
  # which are commented out
EndEvent

If you install a Chat event, the chat message first goes to the Chat event handler, and then to the Verbal Command processor in the bot (which uses the dialog file). If no Chat event is installed, the message goes directly to the Verbal Command processor.

To allow more control through scripts, it is possible to disable partially or (almost) totally the application's Verbal Command processor, using these two statements:

As from world server 39, which is AW 3.3 compliant, Caretakers and Caretaker bots can send a Console Message to individual avatars. This message appears in colour, and can be in bold and italics. To receive this message in the Action Script, you must install a Console Message event handler:
OnConsoleMessageEvent xxx
where xxx stands for an event label

This message does not have a defined sender (although, of course, there is one, as any Caretaker bot can send this message), so you can not ask GetChatName or the like, nor can you reply to it. It is also not processed by the bot's Verbal Command processor.

These statements must be inside the ConsoleMessage event handler. After exiting the event handler, the data may get written over by other events. These are 3.3 statements.
GetEventType %e	stores the event type code 8440 in variable %e.
GetChatLine $a or GetMessage $a	stores the console message in variable $a
GetMessageColor %r %g %b	Retrieves values from 0 to 255 for each of the red, green and blue components of the message colour.
IfChatIsConsoleMessage statement1 Else statement2	tests if the chat event is a 'console message' event (EventType 8440). If so, executes statement1; if an Else statement follows, statement2 is executed if the chat is not 'say'.

Chatting though the world server is but one of the possible ways of sending and receiving messages (Chat event). Historically for Xelagots, the first method I introduced was one that allows communication between bots in the same application, if they are running scripts: the BotChat event. And for the owner to chat with the script through the user interface, I added the BossChat event, now called UIChat event. Both these event handlers work like the Chat event: they intercept the message, which then proceeds to the Verbal Command processor.

When in January 2000 the bots acquired their BotClient software, allowing them to log into a Xelagot server, and the WriteToBot processor was installed in the application, new events appeared. Most of these use the WriteToBot command set to communicate. Using the WriteToBot Hear set to send Verbal Commands, bots in the same application have BotHear and BotAnswer to replace BotChat; using CLWriteToBot Hear, bot clients have CLHear and CLAnswer, and the Av99Bot and SrvcXlgBot processes file requests with DBHear. For security reasons, bots connected to a server must have MASTER protocol to send CLWriteToBot commands, so CLHear only receives messages from a MASTER bot or from a USER (the owner of the bot if s/he has USER protocol). BotHear, CLHear and DBHear trap messages sent with a xxWriteToBot Hear command. These are first trapped by the event handler (if it is installed), and then go to the Verbal Command processor. The Verbal Command processor replies to the sender using a special WriteToBot Answer command, which can only be detected by a bot if it has a BotAnswer and CLAnswer event handler installed: these two event handlers do not pass on the reply to their Verbal Command processor. To complete the series of xxWriteToBot related events, there used to be two more handlers, now obsolete: BotConfirm was used by bots to trap confirmation messages from bots in the same application, CLConfirm trapped them from Bot Clients. These are confirmation messages from WriteToBot commands (excluding replies from the WriteToBot Hear command). For example, the WriteToBot Download sends a confirmation when it has finished downloading a file. These confirmation messages now go to BotAnswer and CLAnswer.

If you do not wish the Verbal Command processor to be involved at all, but wish the bots to freely send messages to each other's scripts, you have three event handlers at your disposal: BotMessage for bots in the same application, CLMessage for Bot Clients, and DBMessage for the file interface (Av99Bot and SrvcXlgBot). These messages have no pre-defined meaning, it is up to the scripts to interpret them.

All these event handlers have similar structure and methods to retrieve information:

Event xxx
   GetEventType %e
   GetChatLine $message
   ## or GetMessage $message
   GetChatName $name
   # your code here   
EndEvent

This means you can install various event handlers using the same handler:

  OnBotAnswerEvent BotChat
  OnBotMessageEvent BotChat
  OnCLAnswerEvent CLChat
  OnCLMessageEvent CLChat

...

Event BotChat
  # $n is the bot's name 
  GetChatName $n
  GetChatline $a
  ...
  # if $b has the answer
  # you can reply
  # using MessageToBot $n $b
EndEvent

Event CLChat
  # $n is the Login name
  GetChatName $n
  GetChatline $a
  ...
  # if $b has the answer
  # you can reply
  # using CLWrite $n $b
EndEvent

To test which type of event a handler is processing, here are a few conditional statements (X1 2.9999950, Av99Bot/SrvcXlgBot 1.66):

Scripts that send messages to bots in the same application retrieve the data of the bot in this way, if the number %number of the bot (1, 2, 3 ...) or its name $bname is known
GetPerson &bbot %number
GetName $bname %number
GetName $bname &bbot
or using these conditionals:
IfGetBot &bbot %number statement1
IfGetBot &bbot $bname statement1

The peculiarities of these event handlers are described in the following tables.

Index