| Command | Parameters | Description |
|---|---|---|
| signal | 2 | signal an event named <p1>, passing <p2> as a parameter |
So if a Mesmerizer executes the command signal myevent "my parameters", and it is connected to a Hub that has an Enforcer connected to it, then inside that Enforcer, an event named myevent will be triggered, with the user and sim as parameters. So The Enforcer will execute the first of these notecards that it finds in its inventory:
myevent:<username>:<sim-name>
myevent:<username>:*
myevent:*:<sim-name>
myevent:*:*
In addition to the regular variables defined for an event, the string given as <p2> to the signal command will be stored in a variable called data, to allow the event handling code to make use of it. This command allows you to define custom events within one or more Mesmerizers, and push them to The Enforcer for processing centrally. I imagine a future variant of the signal command taking a more structured <p2> parameter, resulting in setting multiple variables within the event handler, but for now a simple string is all there is.
This release also introduces the new named trigger concept. A named trigger is exactly what it sounds like - a trigger that happens to have a name. A regular trigger is defined with a command like:
sleep now $rpname = hypnotize
A similar named trigger would be defined like this:
sleep now $rpname == trance hypnotize
The use of a double-equals "==" symbol identifies this as a named trigger definition, and the name is the word immediately following the ==, in this case "trance". Any scope specifier (me, subject, etc) would appear between the name and the trigger action:
sleep now $rpname == trance me hypnotize
Named triggers behave differently from regular triggers in that the definition of a named trigger will replace an existing definition with the same name, if one exists. A regular trigger will always be added. The main purpose of this is so that triggers can be added "idempotently" (a fancy word that simply means doing it multiple times has the same effect as doing it once), which allows for triggers to be set automatically by things like The Enforcer, the MesmerX or the HoloTrainer. A regular trigger definition would always add the trigger, resulting in duplicate triggers if the sub ran a trance or event more than once.
The following new commands that relate to named triggers are defined:
| Command | Params | Description |
|---|---|---|
| ntdel | 1 | Delete a trigger named <p1> |
| ntadd | 2 | Give trigger number <p1> the name <p2> |
| ntren | 2 | Rename trigger named <p1> to <p2> |
I have tried to make these commands play well with regular un-named triggers too. You should be able to use either a number ("1") or a # followed by a number ("#1") to identify an existing trigger, whether or not it is named. This means, for instance, that the ntdel command can be given a number as a parameter (e.g. ntdel 3) to delete trigger number 3. Obviously this means that you can't use a number (or a "#" followed by a number) as a trigger name, and the Mesmerizer should ignore any attempt to use such a name.
The other major enhancement in this release is an overhaul of the PAN protocol. The Mesmerizer creates a "Personal Area Network" or PAN that other attachments worn by the Mesmerizer's wearer can connect to, to send and receive data from the Mesmerizer (or from one another). A developer's script to interface to the Mesmerizer's PAN is available on request.
Each attachment that connects to the PAN is termed a "Station", and is identified by a station name. There is nothing to prevent multiple attachments from using the same station name, and they will all receive messages directed to that station name, but this situation should be avoided if possible.
These commands relate to the PAN. The first two are existing commands; the third is new in this release. If a * is given as the first parameter to pansend or pansendpars, then all stations on the PAN (except for the sender) will receive the message.
| Command | Params | Description |
|---|---|---|
| pansend | 2 | Send message <p2> to PAN station <p1> |
| pansendpars | 3 | Send message <p2> with parameters <p3> to PAN station <p1> |
| pandir | 0 | List all stations on the PAN. |
If <p3> of pansendpars is used to pass multiple parameter values, they should by convention be separated by colons.
Receiving PAN messages in a Mesmerizer is done by declaring an on-pan internal trigger, which will be fired whenever the Mesmerizer receives a PAN message. Within this trigger, the following variables are defined:
| Variable | Contents |
|---|---|
| source | Sending station-name |
| pancmd | The message that was received |
| pan0 | First parameter |
| pan1 | Second parameter |
| pan2 | Third parameter |
| pan3 | Fourth parameter |
pan0 through pan3 are obtained by splitting the received parameters at colons. A future release may add a pars variable which will contain the entire parameters as a single string.
Why the focus on the PAN in this release? I am about to release a small toy that, while it can operate stand-alone, can also be controlled through the Mesmerizer, via the PAN. This is intended as a demonstration of the ability of the Mesmerizer to control any compatible attachment, which in turn will allow such attachments to be controlled remotely, grid-wide or from the web, simply by connecting the Mesmerizer to a Hub. More details to come in another post.
No comments:
Post a Comment