BWP Architecture

From Grigbertz

Current revision

Comm Module

This script listens on the Set Channel and relays incoming commands as Link Messages.

The command string looks the same sent by chat, link or e-mail.

BWP Communications Protocol

<command> = BWP::<relay info>::<set name>::<receiver>::<sender>::<action>

<action> = <action name>[|<arg1>|<arg2>...|<argN>]

<receiver> = <sender> = <name>[|id=<key>][|num=<number>][|<arg1>|<arg2>...|<argN>]

Fields

• BWP The Magic Word
• <relay info> Values:
  • 0 - handled by any receiver
  • 1 - handled by Comm module only. Ignored by others.
  • 2 - ignored by Comm module.
  • (Use bits instead specify what type of channels to relay to)
• set name Common name of all objects using the set channel
• receiver An identifier telling the receiving end this is the action for me
• sender Identifies the original source of the command
• action The info handled by the receiver.

The Relayed Link Message

• sender_num = sender->num (default: 0)
• num = receiver->num (default: 0)
• msg = the command string
• id = original chat message id (default: NULL_KEY)

To Do

• How best to specify sender and recever? Should there be a standardized item identifier?
  • <item name>|<script name>[|<keyword1>...|<keyword1N>] might be good.
  • Receivers, 'all' keyword:
    • 'all' = all scripts of entire set
    • 'all|runes = all 'runes' scripts of entire set
    • 'rankle|all = all scripts of right ankle item
    • 'rankle|links' = all 'links' scripts of right ankle item
• Fields for handling of e-mail info
• Adapt this for efficient handling of menus
• Is there any need for a unique message ID field?
• Relay info. Bitfield.
• Request/Response standard format
• Is it possible to rule that all scripts should use link message to item Comm script for all communication? Only receiver and action + arguments need to be specified. Anything else is added by the Comm script.

Example

Techno Cuffs ankle chains. In this example the chain scripts listen on the Set Channel and communicate directly with each other. The names 'rankle' and 'lankle' should identify a specific item within the set.

1. Draw a particle chain from the right ankle cuff to the left ankle cuff
   1. BWP::1::Techno Cuffs::rankle::ChainsMenu|id=<menu clicker id>::addchain|lankle
      1. Sent on the setChannel when selecting menu item "Options..." -> "Chains..." -> "Add"
      2. Picked up by the comm script and relayed by link message.
      3. Received by the chains script "Chains T-1.4::rankle" in the inner chain ring prim of the Right Ankle Cuff.
2. The Right Ankle Cuff asks the Left for its UUID
   1. BWP::2::Techno Cuffs::lankle::rankle::connectchain
      1. Sent on the setChannel by the receiving chains script. The '2' in the second field makes the comm script ignore this.
      2. Received on the Set Channel by the chains script "Chains T-1.4::lankle" in the inner chain ring prim of the Left Ankle Cuff.
3. The Left Ankle Cuff replies and the chain is drawn.
   1. BWP::2::Techno Cuffs::rankle::lankle::connectchainok|<UUID of the lankle prim>
      1. Sent on the setChannel by the receiving chains script. The '2' in the second field makes the comm script ignore this.
      2. Received on the Set Channel by the chains script "Chains T-1.4::rankle".
      3. The chains script can now start the Particle chain with the received target key (i.e. <UUID of the lankle prim>)
      4. (In this case it would have been better if the 2nd msg included a UUID and the left ankle cuff drew the chain. But this is only a communications example after all. Also the target could have been a leash handle, without its own particle system)

Main Comm module

• All Comm modules listen to Basic Channel (set class specific) and Set Channel (set instance specific)
• The Main Comm module handles requests on the Basic Channel for Set Channel number, if set owner matches.
• The Main Comm module broadcasts Set Channel number on the Basic Channel when rezzed.
• Other Comm modules request Set Channel number on the Basic Channel when rezzed.

Status Module

Handles Item status and Set status. The single source of set constants for each set item, making initializing new sets easier.
Any change in status is relayed to other Status Modules of the set through the set channel. (Anti-loop exeption: A status change from a set channel message is not relayed again). A status update is also sent to the link set.

Status should be properly applied on re-log. Initial status values could be loaded from a notecard. Also an external "backup station" can be used to save and restore set status.

Examples of status (Magic Cuffs)

Set Constants

• Set name
• Basic Channel
• Basic key channel
• Dialog strings

Set Properties

• Owner id
• Owner name
• Owner initials
• Set Channel
• Operators Anybody / Just me / Operator list
• Operator list list of names (or Groups (level 2))
• Item color: Steel / Gold / Iron / etc....
• Sparkles: Sparkles On / Sparkles Off
• Sparkle color: White / Green / etc...

Set State

• Key state: Key Activated / Key Not Activated
• Cuffed state: Not Cuffed/ Cuffed
• Cufflocked state: Not Cufflocked / Cufflocked
• Locked state Unlocked / Locked
• Freedom state: Free (Not Cufflocked and Unlocked )/ Locked Free (Not Cuffed and Locked) / Not Free ((Cuffed and Locked) or Cufflocked)
  • Derived State
  • Free: All menu choices available.
  • Locked Free: You can make some menu choices like "Leash..." or "Poses..."
  • Not Free: Severely restricted menu choices
• Sit state Sitting / Not Sitting
• Sit pose Sit Pose / Cuff Pose
• Cuff pose Showing cuff pose / Not showing cuff pose
  • Derived state. A function of Sit State, Sit pose, Cuffed state
• Current animation Animation name / NULL_STR
• Current squirm animation Animation name / NULL_STR
• Current playing animation Animation name / NULL_STR
  • Derived state. A function of Sit State, Sit pose, Current animation, Current squirm animation
• Leash state Leashed / Unleashed
• Leash anchor Agent key / Object Key / NULL_KEY

Item Constants

• Set name
• Item Name - Not implemented in current version
• Basic Channel
• Basic key channel

Item Properties

• Item Attachment position - Not implemented in current version
• Set Channel
• Item color: Steel / Gold / Iron / etc....
• Sparkles: Sparkles On / Sparkles Off
• Sparkle color: White / Green / etc...

Item State

• Part of current bound anim: Cuffed / Not Cuffed
• Cuff state: Red / Yellow / Green

Menu Module

Use Animation Server.

Must somehow allow duplicate button names in different menus. Maybe give every menu its own channel (e.g. menu number + setChannel). The menu module listens to all of them.

Example

---anklechains---
* Apply chains to ++owner name++'s ankle cuffs:

[Add]  BWP::1 | rankle | addchain | lankle | keepmenu
[Remove]  BWP::1 | rankle | removechain  | keepmenu
[ ]  
[ ] 
[Back...] menu | options
[Main...] menu | main

Variables

Variables connected to status values. ++owner name++ stands for owner name in the previous example.

The following example defines alternate versions of some buttons, defined by status values. The first status to match is chosen. If no match is found, the last 'default' version is used

Example

---anklechains---
* Apply chains to ++owner name++'s ankle cuffs:

++ freedom state == free ++
[Add]  BWP::1 | rankle | addchain | lankle | keepmenu
[Remove]  BWP::1 | rankle | removechain  | keepmenu
[ ]  
++ freedom state == locked free ++
[Add]  BWP::1 | rankle | addchain | lankle | keepmenu
[ ]  
[ ]
++ Default ++
[ ]  
[ ]
[ ]
+++  
[ ] 
[Back...] menu | options
[Main...] menu | main

Sessions Module

Standalone or handled by menumodule?