BWP Architecture

From Grigbertz

(Difference between revisions)
Jump to: navigation, search
m
Current revision (09:07, 12 September 2008) (view source)
m (Comm Module)
 
(20 intermediate revisions not shown.)
Line 9: Line 9:
<command> = BWP::<relay info>::<set name>::<receiver>::<sender>::<action>
<command> = BWP::<relay info>::<set name>::<receiver>::<sender>::<action>
-
<action> = <action name>[|id=<key>][|<arg1>|<arg2>...|<argN>]
+
<action> = <action name>[|<arg1>|<arg2>...|<argN>]
<receiver> = <sender> = <name>[|id=<key>][|num=<number>][|<arg1>|<arg2>...|<argN>]
<receiver> = <sender> = <name>[|id=<key>][|num=<number>][|<arg1>|<arg2>...|<argN>]
Line 19: Line 19:
** 1 - handled by Comm module only. Ignored by others.
** 1 - handled by Comm module only. Ignored by others.
** 2 - ignored by Comm module.
** 2 - ignored by Comm module.
 +
** (Use bits instead specify what type of channels to relay to)
* <b>set name</b> Common name of all objects using the set channel
* <b>set name</b> Common name of all objects using the set channel
* <b>receiver</b> An identifier telling the receiving end this is the action for me
* <b>receiver</b> An identifier telling the receiving end this is the action for me
-
** <b>num</b> Optional. Script number for initial filtering of link messages. Sent as the num argument in the link message.
 
-
** <b>id</b> Optional. Is this useful?
 
* <b>sender</b> Identifies the original source of the command
* <b>sender</b> Identifies the original source of the command
-
** <b>num</b> Optional. Sent as the sender_num argument in the link message.
 
-
** <b>id</b> Optional. Is this useful?
 
* <b>action</b> The info handled by the receiver.
* <b>action</b> The info handled by the receiver.
Line 35: Line 32:
==== To Do ====
==== To Do ====
-
* How best to specify sender and recever?
+
* 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
* Fields for handling of e-mail info
* Adapt this for efficient handling of menus
* 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 ====
==== Example ====
-
(take this from Techno Cuffs 'chains' script)
+
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.
 +
# Draw a particle chain from the right ankle cuff to the left ankle cuff
 +
## BWP::1::Techno Cuffs::rankle::ChainsMenu|id=<menu clicker id>::addchain|lankle
 +
### Sent on the setChannel when selecting menu item "Options..." -> "Chains..." -> "Add"
 +
### Picked up by the comm script and relayed by link message.
 +
### Received by the chains script "Chains T-1.4::rankle" in the inner chain ring prim of the Right Ankle Cuff.
 +
# The Right Ankle Cuff asks the Left for its UUID
 +
## BWP::2::Techno Cuffs::lankle::rankle::connectchain
 +
### Sent on the setChannel by the receiving chains script. The '2' in the second field makes the comm script ignore this.
 +
### 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.
 +
# The Left Ankle Cuff replies and the chain is drawn.
 +
## BWP::2::Techno Cuffs::rankle::lankle::connectchainok|<UUID of the lankle prim>
 +
### Sent on the setChannel by the receiving chains script. The '2' in the second field makes the comm script ignore this.
 +
### Received on the Set Channel by the chains script "Chains T-1.4::rankle".
 +
### The chains script can now start the Particle chain with the received target key (i.e. <UUID of the lankle prim>)
 +
### (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 ===
=== Main Comm module ===
Line 49: Line 71:
== Status Module ==
== Status Module ==
-
Handles Item status and Set status.
+
Handles Item status and Set status. The single source of set constants for each set item, making initializing new sets easier.<br>
-
 
+
Any change in status is relayed to other Status Modules of the set through the set channel.
Any change in status is relayed to other Status Modules of the set through the set channel.
-
<br>(Anti-loop exeption: A status change from a set channel message is not relayed again).
+
(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.
A status update is also sent to the link set.
-
Status should be properly applied on re-log.
+
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) ===
=== Examples of status (Magic Cuffs) ===
==== Set Constants ====
==== Set Constants ====
-
* Set name
+
* <b>Set name</b>
-
* Basic Channel
+
* <b>Basic Channel</b>
-
* Basic key channel
+
* <b>Basic key channel</b>
-
* Dialog strings
+
* <b>Dialog strings</b>
==== Set Properties ====
==== Set Properties ====
-
* Owner id
+
* <b>Owner id</b>
-
* Owner name
+
* <b>Owner name</b>
-
* Owner initials
+
* <b>Owner initials</b>
* <b>Set Channel</b>
* <b>Set Channel</b>
* <b>Operators</b> Anybody / Just me / Operator list
* <b>Operators</b> Anybody / Just me / Operator list
Line 96: Line 116:
* <b>Leash state</b> Leashed / Unleashed
* <b>Leash state</b> Leashed / Unleashed
* <b>Leash anchor</b> Agent key / Object Key / NULL_KEY
* <b>Leash anchor</b> Agent key / Object Key / NULL_KEY
 +
 +
==== Item Constants ====
 +
* <b>Set name</b>
 +
* <b>Item Name</b> - Not implemented in current version
 +
* <b>Basic Channel</b>
 +
* <b>Basic key channel</b>
==== Item Properties ====
==== Item Properties ====
 +
* <b>Item Attachment position</b> - Not implemented in current version
* <b>Set Channel</b>
* <b>Set Channel</b>
* <b>Item color:</b> Steel / Gold / Iron / etc....
* <b>Item color:</b> Steel / Gold / Iron / etc....
Line 106: Line 133:
* <b>Part of current bound anim:</b> Cuffed / Not Cuffed
* <b>Part of current bound anim:</b> Cuffed / Not Cuffed
* <b>Cuff state:</b> Red / Yellow / Green
* <b>Cuff state:</b> Red / Yellow / Green
-
 
== Menu Module ==
== 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 ====
 +
<pre>
 +
---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
 +
</pre>
 +
 +
=== 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 ====
 +
<pre>
 +
---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
 +
</pre>
 +
 +
== Sessions Module ==
 +
Standalone or handled by menumodule?

Current revision

Second Life
Bondage Witch Project logo

Contents

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?

Personal tools