The protocol of Furcadia's client-server communication is entirely in text. Nothing is sent through binary. This makes it relatively easy to make third-party software.
Much of the data used by the server/client are "encoded" as ASCII values. This is done by taking whatever number needs communicated and adding 32 to it, which effectively puts all the values into the range of typable characters. So for example if the server needed to communicate the number 0, it would send ascii value 32+0=32 which is a space. If it needed to communicate the number 1, it would send ascii value 32+1=33 which is the '!' character. Values up to 94 can be sent in this way. A few pieces of data occupy 2 bytes; for these, the first byte's non-encoded value (ei. if byte is '!' value is 1) is multiplied by 95 and added the the non-encoded value of the second byte. For example, the 2 byte data string !# would represent the value 98.
Commands sent to the server:
This command is used to login to the furcadia server, it should be the first thing sent to the server after connecting. use: connect Name Password where Name is the character name to login with, and Password is the character's password. You cannot use this command to create a new character. Note: This is optionally followed by some sort of code that the server interprets and sends back. I believe this is used to prevent the normal client from running on any other server.
Tells server to disconnect.
This command is used to set your characters description. It can be used at any time. use: desc My Description Goes here. < br> color This command sets the color, species, and gender for your character. The change may not take effect until you change maps. use: color Data where Data is an ascii encoded 13 byte string as follows (going left to right): (see "color" in the "constant values" section of this document) byte 0: fur color byte 1: markings color byte 2: hair color byte 3: eye color byte 4: badge color byte 5: vest color byte 6: bracer color byte 7: cape color byte 8: boot color byte 9: pants color byte 10: gender byte 11: species byte 12: (unused, old furc marking style?)
This moves or rotates your character. use: m X where X is one of the following: 9: move north (up-right) 7: move west (up-left) 3: move east (down-right) 1: move south (down-left) <: rotate counterclockwise >: rotate clockwise
Picks up or sets down an item.
Uses your current item.
sit, stand, liedown
Makes your character sit down, stand up, or lay down.
Cycles your character between laying down, sitting, and standing up
Toggles your characters wings on or off (if you have them).
Gets the desctription of a furre at a specific location (anywhere on the map). use: l XXYY Where XX and YY are 2 bytes each, representing the x and y location of the tile to look at.
This is sent to inform the server that the client is ready to enter a map. It is sent everytime the player changes maps, but the server seems to completely ignore it on the main maps. It's only use appears to be in dreams. After entering a dream, the server will place the character into a sort of "suspended" state. The client would then download the dream, and send this command when it was finished. This command causes the server to "unsuspend" the character and to place them at the starting location in the dream.
Message 8: '('
Any line beginning with the character '(' indicates text that thats intended to be displayed to the user. All the data following the '(' is a plain text message. Format: (Trek waves. is intended to be displayed to the user as: Trek waves.
Message 15: '/'
This indicates that a furre has moved. Note that it is also possible to move without changing position by moving into a solid object. It is followed by 20 bytes of data in the following format: /CCCCCCCCCCHHIIFFJJKK where CCCCCCCCCC is the color of the furre: (see "color" in the "constant values" section of this document) byte 0: fur color byte 1: markings color byte 2: hair color byte 3: eye color byte 4: badge color byte 5: vest color byte 6: bracer color byte 7: cape color byte 8: boot color byte 9: pants color where HH,II is the new position and JJ,KK is the old position: (see section "Numeric Data Encoding" on 2 byte values) where FF is the index of the animation frame to display, encoded as: (see "animation offets" in the "constant values" section of this document) index = SPECIAL + SPECIES + POSITION + DIRECTION
Message 17: '1'
Tells the client that a floor has been changed on the map. Format: >XXYYOO XX,YY is the map position of the floor, OO is the new floor number
Message 22,23,24: '6', '7', '8'
These are somehow related to scripts running on the map... not tried to figure these out yet though.
Message 28: '<'
This indicates that either a furre should be displayed for the first time or that an existing furre has changed their direction, sitting state, or avatar state (such as wings). It is followed by 16 bytes of data in the following format: <CCCCCCCCCCHHIIFF where CCCCCCCCCC is the color of the furre: (see Message 15 for 10 byte CCCCCCCCCC meaning) where HH,II is the x,y position of the furre: (see section "Numeric Data Encoding" on 2 byte values) where FF is the animation frame, gender, and species encoded as follows: If frame value is 0, furre should dissapear. (see Message 15 for FF meaning)
Message 29: ';'
Tells the client to load a specific map. Format:
Message 30: '>'
Tells the client that an item has been placed at a specific location. Format: >XXYYOO XX,YY is the map position of the item, OO is the item number Also, there may be many sets of XXYYOO one right after another, in a single > command.
Message 32: '@'
This usually appears as a response to the current player moving. It tells where the client's view should be centered. There are 2 variations of it: Format 0: @XXYY Format 1: @XXYYAABB where AA,BB is the old position and XX,YY is the new position.
Message 61: ']'
I'm not sure what this is for in many cases, but it mostly related to the client's graphical interface. It is followed by a "type" parameter, which is then followed by other data thats specific to that type. It's as follows: ]TX Where T is 1 byte for the type of control message. X is present only for some types, and it's length depends on it's type.
Known values of T
67 ('c'): Controls which graphics file is displayed for a certain part of the UI. It is followed by 1 byte, which might specify which portion of the UI is changed, but I'm not sure. After that byte, the rest of the data is a string for the filename to use (from the patches directory).
41 ('s'): Add a dream portal. Format for the data of this message is: XXYY??I D Where XX,YY is the position to place the dream. ?? is some sort of id or sub-type. After that is 2 strings seperated by a space, I is a string for the title of the dream, D is a string for a short description of the dream.
42 ('t'): Remove a dream portal. Format of data is: XXYY Where XX,YY is the position of the dream to remove. Something else I noticed, is this is usually followed by a (set item at XX,YY to 0) command, which leads me to believe that furc's normal client treats dreams on the map as items.
81 ('q'): This is related to entering a dream. It tells the client the ID of the dream to download from the file server. It's followed by a space, then an 11 byte piece of data, then a space, and a 9 byte piece of data. The 9 byte string appears to be identical to the 11 byte string only without the leading td For Example: ]q td2316690942 2316690942
92 ('|'): I believe this tells the client to stop displaying the previous map, and possibly to display a loading screen. Not certain on this though.
All messages sent "to" the server seem to end in a cairrage return like the normal furc server. Similarly all non-binary messages from the server end in a cr.
Downloading a dream
When you first connect to the file server, it will send this:
10 Welcome to Furcadia file server, proceed to id.
The command to download a dream is the following:
RC NAME PASSWORD DREAM_ID 0 2 CHUNKSIZE
NAME and PASSWORD are your normal furcadia login. DREAM_ID is the ID from message 61:81 in the normal game server protocol, which begins with td. CHUNKSIZE is the size of chunks the server will send. Normally this is 4096 bytes, which means that the tcp/ip protocol will break it up into 2 packets of size 1460 and 1 packet of size 1176. I'm not sure what the 0 and 2 there are for yet.
So for example:
RC MyName MyPass td2316690942 0 2 4096
The server should then respond with this:
44 FILESIZE 2 CHUNKSIZE 0
FILESIZE is size of the file. CHUNKSIZE is the same as above, possibly altered by the server if it didn't like your original number. Again, not sure what 0 and 2 are for.
It will then begin dumping binary data on you.
The whole file is sent in chunks. Each chunk is CHUNKSIZE bytes, and begins with a 10 byte chunk header. You are required to send a confirmation that you recieved each chunk before it will send you the next one. The last chunk is padded with 0's so that it is a full CHUNKSIZE bytes in length.
Each chunk header is 10 bytes total: SCXXXXYYYY The first 2 bytes are just the characters SC (0x53 0x43) followed by 4 bytes for the "chunk number". The "chunk number" starts at 0 for the first chunk, and is incremented for every chunk after that. The last 4 bytes there (YYYY) I'm not sure what it is. Following the 10 byte header is (CHUNKSIZE - 10) bytes of data for the actual file.
You simply append the data portions of these chunks together one after another, to get the resultant file. Do not append the padding of 0's in the last chunk though. You can determine how many bytes of real data the last chunk holds based off the FILESIZE that was given to you previously.
There should be exactly ceiling(FILESIZE/(CHUNKSIZE-10)) chunks total.
The acknowledgement to send (in plain, cr terminted text) after a chunk has been fully recieved is:
Where CHUNK_NUMBMER is the number of the chunk, from the chunk's header.
After the last chunk is recieved and acknowledged, send the server:
and it will respond with:
99 Log out sequence initiated.
And now you have the "Dream File".