Xelagot server/client

Server and action script

Script statements are subject to change while the Server/Client is in beta testing

These script statements refered to on this page are listed in detail in the ActionScript pages: Server statements and Events: Server handlers.

See Notes: present limitations and to-do list.

This page contains informations about how to use the action script to set up parts of the Server parameters to open and close a listening connection. This can also be done with the user interface. The user interface (not the script) makes the Server connection list which is needed by Bot Clients to connect to the Server.

The information on this page is not needed to run Bot Client connections: for this, you can simply do with the user interface to set up and run the Server, and with the statements for Bot Clients to connect and run the bots. See Bot Clients and action script and Setting up a script connection and their links.

This page also contains information on how a bot can use the Server directly (not through internet). This is only needed for very specific tasks, which will not be explained on these pages.

The Server can interact with the bot through the action script. Besides using the user interface to connect and disconnect the Server, these actions can be performed by the script. Before it can connect, the bot must know and set through the user interface or through script statements the Port number of its listening connection, using the statement ServerPort %p. To connect and disconnect the Server, the script uses ServerConnect and ServerDisconnect.

The script must have event handlers active to trap the Server messages. The handlers for trapping Server connection and disconnection are as yet not present. The event handlers for Client connection, chat and disconnection are: ClientLogin, ClientRead and ClientDisconnect. Do not confuse these with the Bot Client event handlers CLLogin, CLDisconnect.

Within the handlers, the script gets information about what is going on, using statements like GetMessage $a in ClientRead. But things get complicated here. ClientConnect and ClientDisconnect events are sent to all bots, and contain the Login name, which can be retrieved within the handler with GetClientLogin $n. The bot may ask the server at any time whether a client is logged in: IfClientIsOnline $n .... To avoid unnecessary information, the bot will only receive Server chat messages from clients it 'captures'. The bot must decide whether to capture the client or not. A statement as

IfClientIsOnline $n ClientCapture $n

will do the trick. To release a client, use ClientRelease $n. This does not close the connection, but works like a mute command. Note: Version 2.99993 allows a client to be captured by many bots at the same time, previous versions only allow one bot to capture the client. When the client disconnects, all its bot captures are released, so when it reconnects, the bot must re-capture the client: if in doubt, capture.

The reason for this complicated system is that partners can be of four sorts: Central Clients logging into the Server, and Bot Clients doing the same, user and the bots in the program. We will need a way for Bots and BotClients to communicate freely with other Bots and BotClients through one Server. This could be achieved with the Protocol field in the Server list. I still have to experiment with this to reach a better solution.

The Bot writes to the Server's clients using a few statements: ClientWriteLogin $n $a to write to Login name $n, ClientWriteAll $a to write to all, ClientWriteLoginX $n $a to write to all except to $n.

Index