FlagRSP2 Communication Documentation

1.) Communication Format and Tags
2.) Procedures of Communication

-=Communication Format and Tags=-
Description Version
<DV># (-1 to infinity)
Example: <DV>1
Used to inform other clients of the current version of the charcter's description. -1 signifies that the character has no description or has chosen to not distribute it. When a different client encounters a number higher than its own records, it requests an update.

Description Pull
<DP>Name
Example: <DP>Trela
Sent by a client to ask a character to send out their description. This can only happen once every five minutes in FlagRSP2.

Character Status
<CS#> (0-4)
Example: <CS3>
Updates other clients of the character status. The practice of <CS#># is no longer used. The status version number has been depreciated.
0 - Do not show status
1 - Out of Character
2 - In Character
3 - In Character and Looking For Contact
4 - Storyteller

Role Play Level
<RP#> (0-5)
Example: <RP2>
Updates other clients of the character's level of role play..
0 - Do not show level
1 - Roleplayer(Default)
2 - Casual Roleplayer
3 - Fulltime Roleplayer
4 - Roleplaying Beginner
5 - Mature Roleplayer(This flag should selectively respond. Only players with this selected should see others with it selected, otherwise display Roleplayer.)

Additional Character Name(New for FlagRSP2)
<AN#>Name (1-3)
Example: <AN1>First
Example: <AN3>Last
Provides an additional name for the character for adding a last name or replacing a first name.
1 - Character name prefix
2 - Character name middle(Future addition, unused.)
3 - Character name suffix

Surname(FlagRSP 0.5.x and FlagRSP2 Compatibility)
<N>Name
Example: <N>Last Name
Provides an additional name for the character.

Title
<T>Title
Example: <T>The First Goddess
Provides a title for the character.

Description Chunks
<D##>Text (01-xx)
Example: <D01>This was first of many descriptions to be written!\\eod
When a description is transmitted, it is broken up into chunks of text 250 characters long. Each chunk is transmitted until the last piece is sent with \\eod at the end of the text. Clients will accept and display partial descriptions, but will notify the displaying client. The transmitting client will always make a best effort attempt at sending a whole description; barring disconnection, etcetera.

-=Procedures of Communication=-
Every five minutes, FlagRSP2 sends out an automatic update(changed or not) of character status with the following tags. This information is also sent out immediately after changing the additional name, title, description, or status options; this also resets the five minute timer so it does send have a chance of sending out less than five minutes later.
All sent together in a batch. <RP#><CS#><DV#><AN1>Name<AN2>Name<AN3>Name
Title field is sent on a separate transmission. <T>Title

---NOTE: Description sending timers and rules are currently under review. Some things such as the user changing the description may effect the example shown below. Peers should always be getting proper updates anyway. The example below is not the best, but should give an idea of what is going on.---

Descriptions can only be sent every five minutes. It can happen at any time in that five minute window, so the description could be sent out less than five minutes apart, but it will take more for it to resent.
Example: Description is requested sent at 4:59. Peer requests an early update at 6:15 and gets it. The timer hits 9:59 with a request for update, but can not send the description because it has already been sent in the 5:00 to 9:59 five minute block. At 14:59, the description is sent again on schedule. So by a peer requesting an early update, it caused an extra 3:45 of cool down until the description can be sent again.


Comments

Posts Quoted:
Reply
Clear All Quotes