BWP Architecture

From Grigbertz

Revision as of 12:11, 6 September 2008 (view source) Grigbertz (Talk | contribs) m (→Menu Module) ← Previous diff		Revision as of 12:12, 6 September 2008 (view source) Grigbertz (Talk | contribs) m (→Sessions Module) Next diff →
Line 161:		Line 161:
	== Sessions Module ==		== Sessions Module ==
		+	Standalone or handled by menumodule?

---

Revision as of 12:12, 6 September 2008

Contents 1 Comm Module 1.1 BWP Communications Protocol 1.1.1 Fields 1.1.2 The Relayed Link Message 1.1.3 To Do 1.1.4 Example 1.2 Main Comm module 2 Status Module 2.1 Examples of status (Magic Cuffs) 2.1.1 Set Constants 2.1.2 Set Properties 2.1.3 Set State 2.1.4 Item Constants 2.1.5 Item Properties 2.1.6 Item State 3 Menu Module 3.1 Example 3.2 Example 4 Sessions Module

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.
• set name Common name of all objects using the set channel
• receiver An identifier telling the receiving end this is the action for me
  • num Optional. Script number for initial filtering of link messages. Sent as the num argument in the link message.
  • id Optional. Is this useful?
• sender Identifies the original source of the command
  • num Optional. Sent as the sender_num argument in the link message.
  • id Optional. Is this useful?
• 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> might be good.
• Fields for handling of e-mail info
• Adapt this for efficient handling of menus
• Is there any need for a unique message ID field?

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.

Example

---anklechains---
* Apply ankle chain:

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

Variables: %p stands for 'ankle' in the below example.

Example

---%pchains---
* Apply %p chain:

[Add]  BWP::1 | r%p | addchain | l%p | keepmenu
[Remove]  BWP::1 | r%p | removechain  | keepmenu
[ ]  
[ ] 
[Back...] menu | options
[Main...] menu | main

Sessions Module

Standalone or handled by menumodule?