FIBS Client Protocol Detailed Specification
Copyright 2003-2004 Evan
McLean.
Revision 1.2 (October 10, 2004)
This document is intended as a comprehensive guide to the client interface for FIBS, the First Internet Backgammon Server. The intended audience is programmers intending to write their own client to interface with the FIBS server.
The most up-to-date copy of the document should always be available from either http://www.fibs.com/fibs_interface.html or http://www.fibscommunity.org/fibs_interface.html.
| 1.2 | October 10, 2004 |
|
| 1.1 | March 22, 2003 | Added some notes to the introduction for RepBot and the alert sections that were supplied by Avi Kivity. |
| 1.0 | March 19, 2003 | Initial revision. |
This document is intended as a comprehensive guide to the client interface for FIBS [1], the First Internet Backgammon Server.
The intended audience is programmers intending to write their own client to interface with the FIBS server. It covers every command and the server's responses.
This document outlines the CLIent Protocol for FIBS, also known as CLIP [2]. It does not cover the standard user interface that you get when you log in normally via a direct telnet session.
I do not try to explain all the commands in detail. Readers are encouraged to look up the FIBS Command Reference [4] as required.
I start off with some initial notes, followed by all the CLIP [2] messages. These CLIP messages form the basis of the responses from a lot of other commands. After this the login process is covered.
The sections after this are structured in much the same way as the FIBS command Reference [4] except I leave actual game play to the very end. It's the most complicated part so I cover the easier stuff first.
There's also a section on all the asynchronous messages you might receive for things like waves and invitations and the like.
When we get to the actual game play, rather then going into each command I first go over it from more of a process view, working through the sequence of events that occur during a match and what you might see from the server. After this each game command is then covered in detail.
Finally the available commands and responses from RepBot are covered.
Thanks to Paul Ferguson, the author of the MacFIBS client and the excellent FIBS Cookie Monster [3] for answering questions, reviewing early drafts and making suggestions.
Thanks also to Peter Nevalainen, the author of the JavaFIBS 2001 client for letting me plagiarise some of his documentation [7] and call it research.
I can be contacted via the FIBS CLIP forum at The FIBS Community Projects web site. At least there, if you ask a question and I'm not around then somebody else may be able to help you.
My user name on this forum is “Wendigo” so if you prefer you can always leave me a private message there too.
FIBS expects any client to conform with the telnet protocol specification (RFC854). In practice this means the following:
IAC XX YY”
where IAC is always the byte 255 (hex FF) and XX and
YY are bytes describing the option being negotiated. In practice
you will only ever see this around the login when it tries to tell the terminal
not to echo output for the password prompt. However if you always use the CLIP
login format you never get a password prompt so the whole thing is moot anyway.
Just ignore any three byte sequence starting with ASCII 255 although you'll
probably never get any (except during guest
logins).Great care has been taken to accurately show all messages returned by FIBS, right down to if there is a period at the end of the message or not. However FIBS appears to have the habit of putting one or more spaces on the end of it's output for some messages and not for others. This has not been documented. It's recommended that any parser you write should be able deal with an arbitrary amount of whitespace on the end of the lines returned from the server.
Many commands that can be sent to the FIBS server can be abbreviated. For instance to send the board command you could type any of “b”, “bo”, “boa”, “boar” or the full “board”. I have not tried to document the shortened versions as some of them are documented in the FIBS Command Reference [4], and at any rate, if you're writing a program to talk to FIBS (which is the intended audience for this document after all) you might as well have your program send the full command. You wont save that much bandwidth in the total scheme of things to be of concern.
In a couple of places in this document I have a large blue exclamation mark (“!”). This indicates a point I am not sure about and wouldn't mind some feedback on.
The CLIP or FIBS CLIent Protocol [2] is an effort to make the FIBS server a little more friendly for client programs to interface with. FIBS was originally designed for use with a straight telnet session with a command line like interface.
When you login in CLIP mode (see Standard Log In) the main differences from the telnet mode are:
All the clip commands start with a number. Most of them will occur asynchronously and not always as a direct result of sending a command.
Synopsis:
1 name last_login last_host
Example:
1 myself 1041253132 192.168.1.308
This is the very first line you'll see after a successful standard login in client mode. This is the only time you will see this message.
name:The login name you just logged in as. last_login:The time of the last login given in seconds since 00:00:00 UTC on January 1, 1970. last_host:The host or IP address the last login came from.
Synopsis:
2 name allowpip autoboard autodouble automove away
bell crawford double experience greedy moreboards moves notify rating
ratings ready redoubles report silent timezoneExample:
2 myself 1 1 0 0 0 0 1 1 2396 0 1 0 1 3457.85 0 0 0 0 0 Australia/Melbourne
This is the second line you'll see after a successful standard login in client mode. This is the only time you will see this message.
Most of these just represent various initial settings on FIBS.
name:The login name you just logged in as. allowpip:1 for yes, 0 for no. Refer to Toggle Allowpip. autoboard:1 for yes, 0 for no. Refer to Toggle Autoboard. autodouble:1 for yes, 0 for no. Refer to Toggle Autodouble. automove:1 for yes, 0 for no. Refer to Toggle Automove. away:1 for yes, 0 for no. Refer to Away. bell:1 for yes, 0 for no. Refer to Toggle Bell. crawford:1 for yes, 0 for no. Refer to Toggle Crawford. double:1 for yes, 0 for no. Refer to Toggle Double. experience:Your experience. greedy:1 for yes, 0 for no. Refer to Toggle Greedy. moreboards:1 for yes, 0 for no. Refer to Toggle Moreboards. moves:1 for yes, 0 for no. Refer to Toggle Moves. notify:1 for yes, 0 for no. Refer to Toggle Notify. rating:Your rating as a number to two decimal places. ratings:1 for yes, 0 for no. Refer to Toggle Ratings. ready:1 for yes, 0 for no. Refer to Toggle Ready. redoubles:0, 1, 2 ... or the string “unlimited”. Refer to Set Redoubles. report:1 for yes, 0 for no. Refer to Toggle Report. silent:1 for yes, 0 for no. Refer to Toggle Silent. timezone:A string representing your timezone. Refer to Set Timezone.
Some of the toggles like “telnet” and “wrap” and settings like “linelength” and “pagelength” are meaningless and not at all useful because FIBS ignores them when in client mode. No lines are wrapped and no page breaks made.
Synopsis:
3 motd message text ... motd message text 4
Example:
3 +--------------------------------------------------------------------+ | | | It was a dark and stormy night in Oakland. Outside, the rain | | came down in torrents. Winds of 40MPH+ pounded at the windows, | | and whipped at trees, power lines, and anyone foolish enough | | to be outdoors. | | | | In the middle of the night, I was awakened by a loud BEEP BEEP | | BEEP BEEP. "What is that?" I thought groggily. Ah! We've had | | a power failure, and the computers are running on battery power. | | | | Curious to see how things were working, I crawled out of bed and | | stumbled downstairs to log in. To my delight, people were | | merrily playing backgammon, oblivious to the fact that they had | | just ridden out a power failure that a few months ago would have | | shut down the server most ungracefully. | | | | Thanks to all of the generous FIBSters who bought the UPS and | | made this possible! And coming soon, as soon as I can get it | | built and deployed, a new (more reliable, and maybe faster) | | server. | | | +--------------------------------------------------------------------+ 4
This is usually displayed after the CLIP Own Info line during login, and whenever the motd command is used.
The “3” by itself on a line signifies the start of the message of the day. All lines received from the server between this and the ending “4” on a line by itself are the message of the day text.
Synopsis:
5 name opponent watching ready away rating experience idle login hostname client email (one of more lines of the above, followed by...) 6
Example:
5 mgnu_advanced someplayer - 1 0 1912.15 827 8 1040515752 192.168.143.5 3DFiBs - 5 someplayer mgnu_advanced - 0 0 1418.61 23 1914 1041272421 192.168.40.3 MacFIBS someplayer@somewhere.com 5 anotherplayer - - 0 0 1439.79 1262 410 1041251697 somehost.com - - 6
You are going to see lots and lots of these, and most of the time you receive them asynchronously. You will see them in the following cases:
You receive these who info lines for yourself whenever your own status changes as well.
Note that in theory one or more info lines (starting with a “5”) will always be followed by the end marker line (a “6”). However from studying the output this does not always appear to be the case. In particular, the results from sending the who command do not return an end marker line. The rawwho command always does however, and is obviously intended for use by client programs while who is tended for people using telnet.
name:The login name for the user this line is referring to. opponent:The login name of the person the user is currently playing against, or a hyphen if they are not playing anyone. watching:The login name of the person the user is currently watching, or a hyphen if they are not watching anyone. ready:1 if the user is ready to start playing, 0 if not. Note that the ready status can be set to 1 even while the user is playing a game and thus, technically unavailable. Refer to Toggle Ready. away:1 for yes, 0 for no. Refer to Away. rating:The user's rating as a number with two decimal places. experience:The user's experience. idle:The number of seconds the user has been idle. login:The time the user logged in as the number of seconds since midnight, January 1, 1970 UTC. hostname:The host name or IP address the user is logged in from. Note that the host name can change from an IP address to a host name due to the way FIBS host name resolving works. client:The client the user is using (see login) or a hyphen if not specified. See notes below. The user's email address, or a hyphen if not specified. Refer to Address.
Some client programs (at the time of writing, as far as I know only
JavaFIBS 2001) use
the client field when logging in to encode certain
information using the encoding scheme outlined in the Player Profile
Protocol [7]. This can encode certain
information such as gender, country and the player's real name.
Without going into a lot of detail, the basic upshot is that if the client
is exactly 20 characters long and starts with one of
“>”, “<”,
“=” or “?” then it is using
this protocol. Detailed information at Player Profile
Protocol.
Synopsis:
7 name message
Example:
7 someplayer someplayer logs in.
Received asynchronously every time a user logs in (assuming notify isn't toggled off). You will invariable receive a CLIP WHO INFO line (followed by the who info end marker) immediately after this message for the user who has just logged in, so as a client developer you could safely ignore these messages and just look for who info lines if you had no especial reason.
name:The login name for the user that has just logged in. message:The complete message you would see if you were logged in with a telnet program instead of in client mode.
Synopsis:
8 name message
Example:
8 someplayer someplayer drops connection.
Received asynchronously every time a user logs out for whatever reason (assuming notify isn't toggled off).
name:The login name for the user that has just logged in. message:The complete message you would see if you were logged in with a telnet program instead of in client mode.
Synopsis:
9 from time message
Example:
9 someplayer 1041253132 I'll log in at 10pm if you want to finish that game.
May receive several of these messages during login, or a single message at any time. Refer to the message command.
from:The login name for the user that left the message. time:The time the message was left as the number of seconds since midnight, January 1, 1970 UTC. message:The text of the message.
Synopsis:
10 name
Example:
10 someplayer
If the recipient was logged on at the time you sent the message, then you receive this confirmation that the message has been received. Refer to the message command.
name:The login name for the user that you sent the message to.
Synopsis:
11 name
Example:
11 someplayer
If recipient was not logged on at the time you sent the message, then you receive this confirmation to indicate that the message has been saved for them. Refer to the message command.
name:The login name for the user that you left the message for.
Synopsis:
12 name message
Example:
12 someplayer Do you want to play a game?
Received asynchronously whenever another user used the say or tell command in your direction.
name:The login name for the user that sent the message. message:The text of the message.
Synopsis:
13 name message
Example:
13 someplayer Anybody for a 5 point match?
Received asynchronously whenever another user uses the shout command (assuming silent isn't toggled off).
name:The login name for the user that sent the message. message:The text of the message.
Synopsis:
14 name message
Example:
14 someplayer I think he is using loaded dice :-)
Received asynchronously whenever another user uses the whisper command while you are watching a game.
name:The login name for the user that sent the message. message:The text of the message.
Synopsis:
15 name message
Example:
15 someplayer G'Day and good luck from Hobart, Australia.
Received asynchronously whenever another user uses the kibitz command while you are playing or watching a game.
name:The login name for the user that sent the message. message:The text of the message.
Synopsis:
16 name message
Example:
16 someplayer What's this "G'Day" stuff you hick? :-)
Received when you've used the say or tell command as confirmation that FIBS processed the request.
name:The login name for the user that you just sent the message to. message:The text of the message.
Synopsis:
17 message
Example:
17 Watch out for someplayer. He's a Tasmanian.
Received when you've used the shout command as confirmation that FIBS processed the request.
message:The text of the message.
Synopsis:
18 message
Example:
18 Hello and hope you enjoy watching this game.
Received when you've used the whisper command as confirmation that FIBS processed the request.
message:The text of the message.
Synopsis:
19 message
Example:
19 Are you sure those dice aren't loaded?
Received when you've used the kibitz command as confirmation that FIBS processed the request.
message:The text of the message.
The standard way of logging in for a client program is shown below. This puts your login with FIBS into client mode instead of telnet mode.
If you need to create a new user you have to use a guest login which is in telnet mode.
Logging in with an existing user ID consists of making a TCP/IP connection to the FIBS server, which will display a bunch of banner lines, a date line, then the login prompt. eg:
WELCOME TO THE
_______ _ ______ _____
| _____| | | | __ \ / ____|
| |___ | | | |__| | | |____
| ___| | | | __ < \____ \
| | | | | |__| | ____| |
|_|irst |_|nternet |______/ackgammon |_____/erver
If something unexpected happens please send mail to:
marvin@fibs.com (Andreas Schneider)
Bug reports are welcome.
This server is on the net to meet people from all countries.
All sorts of racists and fascists are not allowed to login here!
Rude language will not be tolerated on this server. Be nice.
LOGIN AS guest IF YOU ARE NEW TO THIS SERVER!
One account per person only!
Thursday, January 02 01:27:27 MET ( Thu Jan 2 00:27:27 2003 UTC )
login:Note that the last line with the login prompt does not end with a carriage return/line feed character sequence, but does have a single space at the end.
When logging in using telnet, you normally just specify your user ID, wait for the password prompt, then enter your password. For a client program to log in it uses a special login format at the login prompt to indicate it is a program that expects to communicate with FIBS in client mode [2]:
login client_name clip_version name password
client_name:A string of a maximum of 20 characters with no whitespace that identifies your client program. clip_version:Tells FIBS which version of the CLIP interface your client understands. The latest version as of January 2003 is “1008”. name:Your user ID. password:Your password.
For example:
login MyClient_v0.1 1008 myself mypassword
If your login is incorrect for any reason (eg invalid user ID or password,
or the client name being longer then 20 characters) then you will simply get
another “login: ” prompt (again, without a
carriage return or line feed).
Recommended best practice is to terminate the TCP/IP connection and try
again. A failed client login puts FIBS into a funny state where you can start
receiving asynchronous CLIP messages such as Who
Info and Shouts, preceded by a prompt
(“> ”).
If your login was successful, you will get the following sequence of information:
** Warning: You are already logged
in.”Thus, a full example would look something like this:
** Warning: You are already logged in. 1 myself 1041253132 192.168.1.308 2 myself 1 1 0 0 0 0 1 1 2396 0 1 0 1 3457.85 0 0 0 0 0 Australia/Melbourne 3 +--------------------------------------------------------------------+ | It was a dark and stormy night in Oakland. Outside, the rain | | came down in torrents. Winds of 40MPH+ pounded at the windows, | ... | Thanks to all of the generous FIBSters who bought the UPS and | | made this possible! | +--------------------------------------------------------------------+ 4 9 someplayer 1041253132 I'll log in at 10pm if you want to finish that game. 5 mgnu_advanced someplayer - 1 0 1912.15 827 8 1040515752 192.168.143.5 3DFiBs - 5 someplayer mgnu_advanced - 0 0 1418.61 23 1914 1041272421 192.168.40.3 MacFIBS someplayer@somewhere.com ... 5 anotherplayer - - 0 0 1439.79 1262 410 1041251697 somehost.com - - 5 myself - - 0 0 3457.85 2396 12 1041253132 192.168.1.308 MyClient_v0.1 - 6
It would not surprise me if you could get a few other asynchronous messages like CLIP Shouts or responses to any toggles or other commands you may have sent in amongst all that.
Guest logins are solely used for creating new accounts.
Login starts the same as a standard login with
banner lines, a date line, and a login prompt. When you simply login with the
user name of “guest” you will then get the
following:
Welcome to FIBS. You just logged in as guest. Please register before using this server: Type 'name username' where name is the word 'name' and username is the login name you want to use. The username may not contain blanks ' ' or colons ':'. The system will then ask you for your password twice. Please make sure that you don't forget your password. All passwords are encrypted before they are saved. If you forget your password there is no way to find out what it was. Please type 'bye' if you don't want to register now. ONE USERNAME PER PERSON ONLY!!! >
The last line is a prompt that has a greater-than symbol and a single space. It does not have a carriage return or line feed on the end.
You could use the client login format to login login MyClient_v0.1 1008 guest guest”)> ” prompt lines, and you start receiving
asynchronous clip messages like Who Info.
At this point the only really useful commands are
“name” to create a new user ID, or
“bye” to log out and close the
connection.
To create a new user ID you want to use the command:
name user_id
If the user ID you specified already exists, you get the message:
** Please use another name. 'user_id' is already used by someone else.
You will get the same message for reserved user IDs (like
“guest” for instance).
If you specify a user ID which is not valid, you get the message:
** Your name may only contain letters and the underscore character _ .
If you avoid the mine-field and happen the pick one that is valid and does not already exist, you'll next be prompted for a password:
Your name will be user_id Type in no password and hit Enter/Return if you want to change it now. [255][251][1]Please give your password:
Again, the final line ends with a space and has no carriage return or line feed. The values in square brackets are the ASCII values of characters that do not have a printable representation. They are attempts by FIBS to tell a telnet session not to echo the characters the user types in next.
If you just send a carriage return and line feed at this point, you get the response:
[255][252][1]** No password given. Please choose a new name >
The last line is a prompt that has a greater-than symbol and a single space. It does not have a carriage return or line feed on the end.
At this point you can either try the “name” command
again, or send “bye” to log
out.
If you do send a password, but it is less than four characters you get the message:
Minimal password length is 4 characters. Please give your password:
The last line ends with a space but no carriage return or line feed.
If you have managed to enter a valid password, you get prompted:
Please retype your password:
The line ends with a space but no carriage return or line feed.
If you fail to enter the same password as at the first prompt, you get:
** The two passwords were not identical. Please give them again. Password:
The line ends with a space but no carriage return or line feed.
If you entered the same password again correctly, you get:
[255][252][1] You are registered. Type 'help beginner' to get started. >
Yet again, the final line ends with a space and has no carriage return or line feed. The values in square brackets are the ASCII values of characters that do not have a printable representation.
At this point it is probably a good idea to send the bye command or close the connection and then do a standard login as you are logged in in telnet mode, not client mode.
Whenever you send an invalid command to the FIBS server, you get the response:
** Unknown command: 'command'
Where command is the name of the invalid command that
was received.
Commands for sending messages back and forth with other players, or stopping them as the case may be.
When you send a shout command:
shout message
You get back a CLIP You Shout line:
17 message
Or, if you have silent togged on you get the following message and the shout isn't sent:
** Please type 'toggle silent' again before you shout.
When you kibitz during a game:
kibitz message
You get two lines back. First a CLIP You Kibitz line, then a line telling you how many users heard you:
19 message ** 1 user heard you.
Or:
19 message ** n users heard you.
Where n is the number of users that heard you (opponent
plus watchers).
If you kibitz while not watching or playing a game, you simply get back the message:
** You're not watching or playing.
When you send the command:
tell name message
If the recipient meets all of the following criteria:
then, you get back a CLIP You Say line:
16 name message
If the person you are trying to send a message to is not currently logged in or doesn't exist, instead you get the message:
** There is no one called name
If the person you are trying to send a message to has gagged you, you get back the message:
** name won't listen to you.
If you try to send a message to someone you have gagged yourself, you get the message:
** You can't talk if you won't listen.
If you try the tell command with yourself as the recipient you get back:
You say to yourself: message
When you say during a game:
say message
You get back a CLIP You Say line:
16 message
If you use the say command while not playing a game, you simply
get back the message:
** 'say' can't be used outside a game
This is true even if you are watching a game. The say command
is only useful while you are playing a game.
When you whisper during a game:
whisper message
You get two lines back. First a CLIP You Whisper line, then a line telling you how many users heard you:
18 message ** 1 user heard you.
Or:
18 message ** n users heard you.
Where n is the number of users that heard you (the
number of watchers).
If there is nobody watching your game, or you are the only one watching, you get:
18 message ** But nobody heard you.
If you whisper while not watching or playing a game, you simply get back the message:
** You're not watching or playing.
When you use the message command to leave a message for a user
such as:
message someplayer I'll log in at 10pm if you want to finish that game.
You get back either a CLIP Message Delivered line if the user is currently logged in:
10 someplayer
Or a CLIP Message Saved if the user is not currently logged in:
11 someplayer
If you specify an unknown user, you get back the message:
** Don't know user user.
If you specify a user, but no actual message, such as:
message someplayer
You get back the error message:
** usage: message <user> <text>
If you specify the message command without any arguments, you get either:
There are no new messages for you.
Or one or more CLIP Message lines showing all the messages you've received since you've logged in.
You can send a message to yourself, but it is usually delivered straight away.
When you the waitfor command without any arguments you get
either:
You are not waiting for any players.
Or:
You are waiting for user
Or:
You are waiting for the following n players: user1, user2...
! I have no idea if it will word wrap if the list of users is too large, but it probably doesn't.
When you specify one or more users with the waitfor command,
you get the following message for each user specified:
** You'll receive a message when 'user' logs in.
Or, if you specify a user that does not exist:
** There is no user called 'user'.
If the user is already logged in, then you get:
** 'user' is already logged in.
If you specify yourself, you get:
** Look behind you. Maybe you are waiting there.
See the section on asynchronous messages for waitfor for what happens when one of the users you are waiting for logs in.
If you specify gag without any arguments you get one of the
following:
** Gagged users: none ** Gagged users: user ** Gagged users: user1,user2,...,usern
NOTE: With the last one that contains multiple users, it will always be on one line, but you may have two or more commas in a row or one or more commas at the end of the line. I'm not sure why, but I suspect it has something to do with line wrapping which isn't being done.
If you specify gag with a user name you get one of:
** There is no one called 'user' ** You gag user. ** You ungag user. ** You talk too much, don't you?
Depending on if the user is:
If you use the gag command with more that one argument on the
line, only the first argument is processed.
If you specify blind without any arguments you get one of the
following:
** Blinded users: none ** Blinded users: user ** Blinded users: user1,user2,...,usern
If you specify blind with a user name you get one of:
** There is no one called 'user' ** You blind user. ** You unblind user. ** You can't read this message now, can you?
Depending on if the user is:
If you use the blind command with more that one argument on the
line, only the first argument is processed.
Commands you can use between games to do things like watch other games, start a new game or log out.
Note that any use of the invite command will toggle your
ready status to on if it isn't already. If this is
done, you will also receive a CLIP Who Info line
for yourself.
If you specify invite without any arguments you get:
** invite who?
If you try and invite a user who either doesn't exist or is not currently logged on you get:
** There is no one called user
If you invite someone who is not ready you get:
** user is refusing games.
If you invite someone who is already playing you get:
** user is already playing with someone else.
If you invite someone who is ready, but you specify a second argument which is not a valid match length number or the word “unlimited” you get:
** The second argument to 'invite' has to be a number or the word 'unlimited'
If you invite a ready user to an n point match, you get the response:
** You invited user to a n point match.
If you try to invite someone to a match greater than 9 points and your experience is not high enough to appear on the rating list, you get:
** You're not experienced enough to play a match of that length.
If you invite someone to an unlimited match, you get the message:
** You invited user to an unlimited match.
If you invite someone to resume a saved match, you get:
** You invited user to resume a saved match.
Unless of course there is no saved match with that player, in which case you get:
** There's no saved match with user. Please give a match length.
If you try and extend an invitation while you are already playing a game, you get:
** You are already playing.
If you extend an invitation to a ready user who currently is away, in addition to the notice showing that you've issued the invitation, you also get a blank line followed by:
user is away: message
Where message is the message they specified when they
set their away status.
If you try and invite yourself to a game you get:
** You can't invite yourself.
!I'm pretty sure there is no timeout on invitations, but you can only have one invitiation at a time. If you issue a second invitation it will cancel the first.
See Start or Resume a Match regarding what happens when the invitee accepts the invitation and you start playing a match.
If you specify join without any arguments and you are not already in a match you get:
** Error: Join who?
If you try and join a user who is not ready you get:
** user is refusing games.
If you try and join a user who is already playing you get:
** Error: user is already playing with someone else.
If you try and join someone who didn't invite you (or has issues another invitation, cancelling yours) you get:
** user didn't invite you.
Finally, if you join someone who did invite you and is still ready to play you get:
** You are now playing a n point match with user Starting a new game with user.
Or for an unlimited match:
** You are now playing an unlimited match with user Starting a new game with user.
If you are resuming a saved match, you get:
You are now playing with user. Your running match was loaded.
If the saved game was corrupted for any reason, upon trying to join both you and the invitee get the following message and the game is not started:
** ERROR: Saved match is corrupt. Please start another one.
If you try and use the command while in the middle of a game (except to start the next game), you get:
** You can't play two games at once
See Start or Resume a Match regarding what happens when you accept an invitation.
Note, if you are currently watching someone and you use the
watch command at all, you get this message before any other
response for the command:
** You stop watching user.
Also, whenever you start or stop watching someone, you are going to get the appropriate CLIP Who Info lines to reflect the change in state.
If you specify watch without any arguments you get:
** Watch who?
If try to start watching a user that doesn't exist or is currently not logged in, you get:
** There's no one called user.
If you try to start watching someone who has blinded you, you get:
** user doesn't want you to watch.
If you try to start watching someone and their opponent has blinded you, you get:
** user doesn't want you to watch.
However, if you start watching someone who has no objections, you get:
You're now watching user.
Additionally, if they are not playing a game at the moment you get:
user is not doing anything interesting.
If you are vain enough to try and watch yourself you get the response:
** Use a mirror to do that.
When the user you are watching starts a game with another player, you'll get:
user1 and user2 start a n point match. Starting a new game with user1.
Or, for an unlimited match:
user1 and user2 start an unlimited match. Starting a new game with user1.
Or, for resuming a saved match:
user1 and user2 are resuming their n-point match.
Or:
user1 and user2 are resuming their unlimited match.
If the person you are watching starts a game with a user that has blinded you, you get:
user1 and user2 start a n point match.** You can't watch the match between user1 and user2.
If you try and use the watch command while already playing a
game you get:
** You can't watch another game while you're playing.
See asynchronous watch messages for messages you can receive while watching if the user or their opponent blinds you.
See Watching a Game for details on what you start getting when the user you are watching is playing a game.
Note that whenever you start or stop watching someone, you are going to get the appropriate CLIP Who Info lines to reflect the change in state.
If you specify unwatch while watching a player you get:
You stop watching user.
If you are not currently watching anybody you get:
** You're not watching.
See asynchronous watch messages for messages you can receive while watching the user or their opponent blinds you.
If you specify look without any arguments you get:
** Look at who?
Otherwise, if you look at a user that is playing a game you get a board state.
If the user is not currently playing a game you get:
** user is not playing.
If you try and look at a player and either they or their opponent has blinded you, you get:
** user doesn't want you to look.
If you try to look at yourself, you get:
You look great.
Note that the players themselves do not get any sort of notification when you look in on their game. This command also works while you are playing a game yourself, which could end up with you receiving conflicting board state.
If you specify oldboard without any arguments you get:
** usage: oldboard <name>
If you specify a user with whom you do not have a saved or recent match (including yourself) or doesn't exist you get:
** There's no saved match with a player called 'user'.
Otherwise you get a board state representing the current state of the game.
If you try and use this command while playing a game you get:
** You can't do this while playing.
If you specify oldmoves without any arguments you get:
** usage: oldmoves <name>
If you specify a user with whom you do not have a saved or recent match (including yourself) or doesn't exist you get:
** There is no saved game with user.
Otherwise you get the moves for the current game in the saved match, which will look something like this:
Score is 2-2 in a 3 point match. someplayer is X - myself is O O: (5 1) 13-8 24-23 X: (6 5) 1-7 12-17 O: (5 3) 8-3 6-3 X: (5 4) 1-5 19-24 O: (5 5) bar-20 6-1 6-1 23-18 X: (4 5) 19-24 17-21 ... X: (1 5) 9-14 9-10 O: (4 4) can't move X: (3 2) 12-14 12-15 ... O: (5 2) 21-16 16-14 X: doubles O: accepts X: (2 1) 1-2 19-21 ... X: (6 4) 21-off 21-off O: (6 2) 1-off 1-off O: wins
The numbers in parenthesis represent the roll of the dice.
If it was an unlimited match, the start of it would look like:
Score is 2-2 in an unlimited match. someplayer is X - myself is O
This command will also work while in the middle of playing a game.
Note that I have not documented all the possible moves you can see here.
Things like resignations and their acceptance or refusal would have special
messages. The identifying factor is that they would all start with either
“X: ” or “O: ”
If you specify away without any arguments you get either:
None of the users is away.
If no one is away, or:
The following users are away: user1: message user2: message ... usern: message
With at least one user listed.
Note that if you are away, and you type the away command
without any arguments, instead of displaying your user login ID, you actually
get the string “You”. e.g.
The following users are away: someplayer: Be back soon. You: Out to lunch.
If you specify away with any arguments it sets you into the
away state, with the arguments as the message other users see. You also get
back:
You're away. Please type 'back'
You will also get this back whenever you send something to the FIBS server (see Asynchronous Away Messages). You do still get back the results of the command you sent, you just get this line after it as well.
If you specify back while you are away, you get:
Welcome back.
If you were not away to begin with, then you get:
** You're not away.
Any extra arguments to this command are ignored.
The bye command also has the following synonyms, all of which
behave the same: adios, ciao, end,
exit, logout, quit and
tschoe.
When you use this command you may get one or two more Asynchronous messages before the logout message. The logout message could be any sort of text, but as of January 2003 it is:
Goodbye.
If you find bugs please report them to:
marvin@fibs.com
As no one seems to type 'about' - here is what it says:
If you enjoyed using this server please send picture postcards,
brownies (ask traveller for her recipe), homemade wine or beer to:
or even Sun-Workstations to:
Andreas Schneider
132 Vanguard Building
18 Westferry Road
London E14 8LZ
England
Thanks for the postcards I've received over the last few months
Keep them coming....After which the TCP/IP socket connection is closed.
The first time you send wave you get:
You wave goodbye.
The second time you get:
You wave goodbye again and log out.
Followed by the logout message (see bye) and closure of the TCP/IP socket.
Various commands related to setting certain user information and game behaviour. In particular the double and greedy toggles can be use to make game play more efficient.
If you issue the toggle command without any arguments, the output will be as follows:
The current settings are: allowpip YES autoboard YES autodouble NO automove YES bell NO crawford YES double YES greedy NO moreboards YES moves NO notify YES ratings NO ready NO report NO silent NO telnet YES wrap NO
Naturally the individual settings will be “YES” or
“NO” as based on each individuals settings.
If you specify toggle with an invalid argument you get the message:
** Don't know how to toggle arg
Where arg is the argument you specified.
You can toggle multiple settings by specifying multiple arguments to the toggle command at once. You will get a response line for each setting that was toggled.
Command:
toggle allowpip
When toggled on:
** You allow the use the server's 'pip' command.
When toggled off:
** You don't allow the use of the server's 'pip' command.
Command:
toggle autoboard
When toggled on:
** The board will be refreshed after every move.
When toggled off:
** The board won't be refreshed after every move.
Although the command reference [4] says this is only useful for players using the command line interface (telnet), I've seen some clients toggle this back on if you try and toggle it off which is probably a good idea.
Command:
toggle autodouble
When toggled on:
** You agree that doublets during opening double the cube.
When toggled off:
** You don't agree that doublets during opening double the cube.
Command:
toggle automove
When toggled on:
** Forced moves will be done automatically.
When toggled off:
** Forced moves won't be done automatically.
Command:
toggle bell
When toggled on:
** Your terminal will ring the bell if someone talks to you or invites you
When toggled off:
** Your terminal won't ring the bell if someone talks to you or invites you
When this is set on, you receive the bell character (ASCII value 7) on the end of the invitations and messages. It is probably a good idea to toggle this off if you see it get set. Also note the setting for this toggle is persistent across logins. It is probably also a good idea to program your client to be able to ignore this character if it is received from the server.
Command:
toggle crawford
When toggled on:
** You insist on playing with the Crawford rule.
When toggled off:
** You would like to play without using the Crawford rule.
Command:
toggle double
When toggled on:
** You will be asked if you want to double.
When toggled off:
** You won't be asked if you want to double.
This is reset to “YES” every time a game is started
or reloaded.
Command:
toggle greedy
When toggled on:
** Will use automatic greedy bearoffs.
When toggled off:
** Won't use automatic greedy bearoffs.
This is reset to “NO” every time a game is started
or reloaded.
Command:
toggle moreboards
When toggled on:
** Will send rawboards after rolling.
When toggled off:
** Won't send rawboards after rolling.
This is pretty darn useful for client programs, so if you see it toggled off you probably want to toggle it back on.
Command:
toggle moves
When toggled on:
** You want a list of moves after this game.
When toggled off:
** You won't see a list of moves after this game.
Command:
toggle notify
When toggled on:
** You'll be notified when new users log in.
When toggled off:
** You won't be notified when new users log in.
Probably another good one to toggle on if you ever see it toggled off.
Command:
toggle ratings
When toggled on:
** You'll see how the rating changes are calculated.
When toggled off:
** You won't see how the rating changes are calculated.
Command:
toggle ready
When toggled on:
** You're now ready to invite or join someone.
When toggled off:
** You're now refusing to play with someone.
In reality, after the ** line you'll receive a
CLIP Who Info line to signal the status change.
So what you'll really see coming back from the server will look more like
this:
** You're now ready to invite or join someone. 5 myself - - 1 0 1418.61 23 21 1042191690 192.168.43.186 3DFiBs - 6
Thus, in writing your client you can pick up the ** message to
detect the server changing your ready state, or look for the
CLIP Who Info line with your login name in it. I
would always check the ready state in incoming CLIP
Who Info lines with your own login name at any rate because inviting
someone to a game sets your own ready state on without giving the
** line.
Command:
toggle report
When toggled on:
** You will be informed about starting and ending matches.
When toggled off:
** You won't be informed about starting and ending matches.
See game reports for a list of the messages you receive when reports are toggled on.
Command:
toggle silent
When toggled on:
** You will hear what other players shout.
When toggled off:
** You won't hear what other players shout.
Command:
toggle telnet
When toggled on:
** You use telnet and don't need extra 'newlines'.
When toggled off:
** You use a client program and will receive extra 'newlines'.
Despite the message, this setting appears to have no discernible effect whatsoever when in logged into FIBS in client mode.
Command:
toggle wrap
When toggled on:
** The server will wrap long lines.
When toggled off:
** Your terminal knows how to wrap long lines.
This can be safely ignored when logged into FIBS in client mode. It has no effect.
If you issue the set command without any arguments, the output will be as follows:
Settings of variables: boardstyle: 3 linelength: 0 pagelength: 0 redoubles: none sortwho: login timezone: Australia/Melbourne
If you specify set with an invalidate setting you get the
message:
** Invalid argument. Type 'help set'.
Command:
set boardstyle
Response:
Value of 'boardstyle' is value
Command with a valid argument:
set boardstyle value
Response:
set boardstyle value
Command with an invalid argument:
set boardstyle bad_value
Response:
** Valid arguments are the numbers 1 to 3.
If you see this set to anything other than “3” you
probably want to set it back.
See Board State for details on what the board looks like for a board style of 3.
Command:
set linelength
Response:
Value of 'linelength' is value
Command with a valid argument:
set linelength value
Response:
Value of 'linelength' set to value.
Command with an invalid argument:
set linelength non_number_value
Response:
Value of 'linelength' set to 0
Command with a number out of range:
set linelength bad_value
Response:
** Valid arguments are the numbers 0 to 999. Use 0 for no linelength.
This setting has no effect when logged into FIBS in client mode.
Command:
set pagelength
Response:
Value of 'pagelength' is value
Command with a valid argument:
set pagelength value
Response:
Value of 'pagelength' is value
Command with an invalid argument:
set pagelength non_number_value
Response:
Value of 'pagelength' set to 0.
Command with a number out of range:
set pagelength bad_value
Response:
** Valid arguments are the numbers 0 to 999. Use 0 for no pagelength.
This setting has no effect when logged into FIBS in client mode.
Command:
set redoubles
Response:
Value of 'redoubles' is value
Command with a valid numeric argument:
set redoubles num_value
Response:
Value of 'redoubles' set to num_value.
Command with a valid string argument:
set redoubles str_value
Response:
Value of 'redoubles' set to 'str_value'.
Command with an invalid argument:
set redoubles bad_value
Response:
** Valid arguments are 'none', 'unlimited' and the numbers 1 to 99.
Command:
set sortwho
Response:
Value of 'sortwho' is value
Command with a valid argument:
set sortwho value
Response:
Value of 'sortwho' set to value
Command with an invalid argument:
set sortwho bad_value
Response:
** Unknown value 'bad_value'. Try 'login', 'name', 'rating' or 'rrating'.
Command:
set timezone
Response:
Value of 'timezone' is value
Command with a valid argument:
set timezone value
Response:
Value of 'timezone' set to value
Command with an invalid argument:
set timezone bad_value
Response:
Can't find timezone 'bad_value'. Try one of: Africa/Abidjan, Africa/Accra, Africa/Addis_Ababa, Africa/Algiers, Africa/Asmera, Africa/Bamako, Africa/Bangui, Africa/Banjul, Africa/Bissau, ... Pacific/Pago_Pago, Pacific/Palau, Pacific/Pitcairn, Pacific/Ponape, Pacific/Port_Moresby, Pacific/Rarotonga, Pacific/Saipan, Pacific/Tahiti,
For a new user the timezone is initially set to UTC.
Note that according to [4] the timezone setting effects the commands who, date, last and time.
When logged into FIBS in client mode, the lines returned by the who command always come back in the form of CLIP Who Info lines so it doesn't really effect them. The other commands are not especially essential to client programs.
Command:
address
Response:
** You didn't give your address.
Command:
address myself@myisp.com
Response:
Your email address is 'myself@myisp.com'. 5 myself - - 0 0 1418.61 23 63 1042199053 192.168.43.186 MacFIBS myself@myisp.com 6
Command:
address myself@myisp.com extraneous rubbish on the end
Response:
Your email address is 'myself@myisp.com'. 5 myself - - 0 0 1418.61 23 63 1042199053 192.168.43.186 MacFIBS myself@myisp.com 6
Note that when you set your address, you will also get a CLIP Who Info response.
Extra arguments on the end of the command are ignored.
Command:
password
or:
password bad usage
Response:
** usage: password <old password>:<new password>:<new password> ** NOTE: The character between the passwords is now a colon!
Command:
password old_password:new_password:new_password
Response:
Password changed.
Command:
password wrong_password:new_password:new_password
Response:
** Sorry. Old password not correct.
Command:
password old_password:new_password:diff_password
Response:
** Please give your new password twice.
Command:
save
Response:
Settings saved.
Any arguments to the command are ignored.
Commands to get information about what users are logged on, playing games and stuff like that.
The help command produces lots of free form text. Your GUI client probably will not be able to process this easily.
Command:
show
Response:
** show what?
Command:
show invalid_command
Response:
** Don't know how to show invalid_command
Command:
show games
Response:
List of games: someplayer - myself (1 point match 0-0) anotherplayer - player_aa (unlimited match 2-6) ... YetAnotherPlayerWithAReallyLongName - player_bb (1 point match 0-0)
There are 15 characters for the players' names plus a space on each side of the hyphen. If a player's name is longer then 15 characters then it will still be their full name and a space (or the space first if they are on the right of the hyphen).
! I have no idea what response you'd get if there were no actual games in progress.
Command:
show saved
Response:
opponent matchlength score (your points first) *someplayer 3 1 - 1 ... **anotherplayer 1 0 - 0 yetanotherplayer unlimited 4 - 2
If the other player is logged in, then there are two asterisks before their name in the listing. If you are actually playing the saved game, there is only one asterisk preceded by a space. Otherwise there is just two spaces before their name.
Or, if there are no saved games you get:
no saved games.
Command:
show watchers
Response:
Watching players: someplayer is watching anotherplayer.
Or, if there are no watchers:
Watching players: none.
Command:
show max
Response:
max_logins is nnn (maximum: nnn)
The output of the who is usually a set of lines as detailed for
the CLIP Who Info messages. eg:
5 mgnu_advanced someplayer - 1 0 1912.15 77827 8 1040515752 192.168.143.5 3DFiBs - 5 someplayer mgnu_advanced - 0 0 1418.61 23 1914 1041272421 192.168.40.3 MacFIBS someplayer@somewhere.com 5 anotherplayer - - 0 0 1439.79 1262 410 1041251697 somehost.com - -
However there are some special cases.
If you send the command “who user” and the
user is logged in, you'll get a single line 5. If the user specified is not
currently logged in or does not exist, you'll receive:
** There is no one called user.
If you specify a command such as “who away” and
there is no one matching that criteria, you'll receive the following line:
No S username rating exp login idle from
Which is basically the header line for displaying a user list when logged into FIBS as a telnet user instead of as a client using CLIP. If there are one or more users matching the criteria you'll receive the CLIP Who Info lines.
Note when using the who command you tend not to get the end
marker line (a “6” on a line by itself after all the lines starting
with “5”). You do always get it for the
rawwho command however.
The where command displays the host name in a form such as:
user from ip_address (host_name)
Example:
someplayer from 192.168.143.5 (somehost.com)
If the host name is unknown, then the IP address is displayed again instead. eg:
someplayer from 192.168.143.5 (192.168.143.5)
If you do not specify an argument for the where command is displays the details for yourself.
If you specify a user who is not currently logged in, you get:
** There's no one called user.
The output of the who is a set of lines as detailed for
the CLIP Who Info messages. eg:
5 mgnu_advanced someplayer - 1 0 1912.15 77827 8 1040515752 192.168.143.5 3DFiBs - 5 someplayer mgnu_advanced - 0 0 1418.61 23 1914 1041272421 192.168.40.3 MacFIBS someplayer@somewhere.com 5 anotherplayer - - 0 0 1439.79 1262 410 1041251697 somehost.com - - 6
Note that unlike the who command, you always get the end line marker (the “6” on a line by itself).
The only exception is if you send the command “who
user” and the user is is not currently logged in or does
not exist, you'll receive:
** There is no one called user.
If course if the user is logged in you'll get the single line for that user starting with “5” followed by the single line with a “6”.
5 mgnu_advanced someplayer - 1 0 1912.15 77827 8 1040515752 192.168.143.5 3DFiBs - 6
If you specify a command such as “who away” and
there is no one matching that criteria, you'll receive the following line:
6
Which is the end line maker for the CLIP Who Info lines.
If you specify whois without an argument, you get:
** please give a name as an argument.
If you specify whois for an unknown user, you get:
No information found on user user.
Otherwise, you get six or seven lines of information back in the form:
Information about user: Last login: date from host last_login_details play_status (away_status) Rating: rating Experience: experience email_address
Note that each line except the first starts with two spaces. There are also
two spaces between “Last login:” and the displayed
date.
The away_status line is only displayed if the user has
used the away command.
Lets take each part piecemeal and then show some examples at the end.
date
Of the form:
Tuesday, January 14 20:27 EST
Date is given in your local timezone if set.
host
The host or IP address the user last logged in from.
last_login_details
If the user is currently logged in, it is:
Still logged in. ss seconds idle.
If the user has been more than a minute idle then you get:
Still logged in. hh:ss minutes idle.
If the user is not currently logged in you get:
Last logout: date
Where date is in the same format as for the login
date.
play_status
If the user is not currently logged in:
Not logged in right now.
Otherwise you get one of the following combinations:
user is not ready to play, not watching, not playing. user is ready to play, not watching, not playing. user is not ready to play, watching another_user, not playing. user is ready to play, watching another_user, not playing. user is playing with another_user.
away_status
The away_status line is only displayed if the user has
used the away command. It takes the form:
user is away: msg
Where msg is the message the user
left when they used the away command.
email_address
If the user has not set their email address:
No email address.
Otherwise:
Email address: someuser@someaddress.com
Examples:
Information about someplayer: Last login: Friday, January 10 12:12 EST from 192.168.143.5 Last logout: Friday, January 10 13:15 EST Not logged in right now. Rating: 1912.15 Experience: 827 Email address: someplayer@somewhere.com Information about anotherplayer: Last login: Tuesday, January 14 20:14 EST from 192.168.40.3 Still logged in. 4 seconds idle. anotherplayer is not ready to play, watching mgnu_advanced, not playing. Rating: 1418.61 Experience: 23 No email address. Information about myself: Last login: Tuesday, January 14 13:05 EST from 192.168.1.308 Still logged in. 10:04 minutes idle. myself is not ready to play, not watching, not playing. myself is away: Back in a tick. Rating: 3457.85 Experience: 2396 No email address.
If you specify ratings without an argument, you get the top
twenty entries:
rank name rating Experience
1 NIHILIST 2295.11 7274
2 sue 2223.18 15625
3 Biggles 2201.53 11720
4 otaku 2180.23 1533
5 loner 2128.04 16818
6 Kraftwerk 2055.30 1286
7 grepster 2054.96 4328
8 mloner 2054.22 97764
9 reno 2027.95 2221
10 garyKay 2021.00 14096
11 mloner_II 2010.78 140276
12 melzi 2007.19 6543
13 dage 2006.96 5275
14 mgnu_zp 2001.41 329354
15 LeSinge 1990.50 2753
16 Zorgtwo 1989.92 236
17 MariosSoup 1988.94 17264
18 erick 1982.49 5096
19 themaz 1979.74 29816
20 alydar 1977.11 29132Note that the header line has one space at the start.
If you specify a user which doesn't exist, you just get the header line:
rank name rating Experience
If you specify a user who does exist, you get just their details:
rank name rating Experience *4431 someplayer 1418.61 23
Note the asterisk at the start. I don't know why.
If you try and specify two players such as ratings
someplayer anotherplayer”
** Please use only one of the given names 'someplayer' and 'anotherplayer'.
If you try and specify more than two players then you get the above message with the first two arguments.
If you specify a range such as ratings from 21 to
30”
rank name rating Experience 21 afendi 1968.79 15453 22 the_drew_boy 1966.76 188 23 norek 1963.75 222 24 mpgnu 1963.22 104465 25 Jellio_Blots 1962.76 933 26 reima 1962.01 8593 27 Schicks 1961.97 720 28 Mads_P_J 1960.43 1840 29 gnu_tutorI 1959.49 10961 30 tommyh 1957.83 6242
If you specify a positive range greater than the total number of users on the system you get just the header line.
If you specify a range with the to number less than the from number, such as
ratings from 20 to 15”
** invalid range from 20 to 15
If you specify a range that is too large, such as ratings
from 1000 to 2000”
** range currently limited to 100.
If you specify just a from range, such as ratings from
nn”ratings from nn to 20”
If you specify just a to range, such as ratings to
nn”ratings from 1 to nn”
If you specify a negative number, zero, or anything else which is not a positive number for the from or to value you get one of the following messages as appropriate:
** Please give a positive number after 'from'. ** Please give a positive number after 'to'.
If they are both bad, it will just complain about “from”.
Me, myself and I
If you appear in the rankings list at all (theorectically you should if you
have more than 50 experience points, but that doesn't always appear to be the
case) then your own ranking should always appear in every valid ratings
response. eg: for “myself”:
rank name rating Experience 21 afendi 1968.79 15453 22 the_drew_boy 1966.76 188 23 norek 1963.75 222 24 mpgnu 1963.22 104465 25 Jellio_Blots 1962.76 933 26 reima 1962.01 8593 27 Schicks 1961.97 720 28 Mads_P_J 1960.43 1840 29 gnu_tutorI 1959.49 10961 30 tommyh 1957.83 6242 3054 myself 1453.28 400
! There seems to be some debate is to if your own entry is preceded by an asterisk or not. It seems to be for some people and not others. Other people with the required experience points do not seem to show up in the ratings list at all anyway. Any definitive insight into FIBS's behaviour on this would be appreciated.
If you specify last without an argument, you get the last
twenty entries:
The 20 last logins/logouts: Wed 11:08 UTC: someplayer drops connection. ... Wed 11:12 UTC: anotherplayer logs in.
If you specify last with any arguments at all you get:
** Please use the 'whois' command.
The command date is a synonym for time (or vice
versa?)
If you specify time without an argument, you get the current
time, both in your nominated timezone and in UTC.
eg:
Wednesday, January 15 22:18:35 EST ( Wed Jan 15 11:18:35 2003 UTC )
If you specify time with a timezone you get the current time in
that timezone and in UTC.
If you specify an invalid timezone you get a an error message like this:
Can't find timezone 'bad_value'. Try one of: Africa/Abidjan, Africa/Accra, Africa/Addis_Ababa, Africa/Algiers, Africa/Asmera, Africa/Bamako, Africa/Bangui, Africa/Banjul, Africa/Bissau, ... Pacific/Pago_Pago, Pacific/Palau, Pacific/Pitcairn, Pacific/Ponape, Pacific/Port_Moresby, Pacific/Rarotonga, Pacific/Saipan, Pacific/Tahiti,
Information about the FIBS server itself.
See CLIP Motd for an example of the output from this command in client mode.
The server ignores any extraneous ar