Spirals

You don't need a Mesmerizer of your own to place a sub in trance using their Mesmerizer - all you need are the appropriate access permissions as described in the previous post,  This means that you may not have an easy way to see what options are available for spirals.   I have some ideas about how I might provide this information automatically, but for now I'll just show the standard spirals here in this post.

A "spiral" is the eye-focus image that's displayed to the sub while they are in trance, and is typically a rotating spiral.  It doesn't have to be a spiral, and it doesn't even have to rotate - it can also be a sequence of frames to make up an animation loop. You can select a particular spiral with the setspiral command, which takes an integer parameter, currently ranging from 1 to 7, with the initial value being set to 1.   The spiral selection is persistent across logins, so if the sub finds one of the provided spirals particularly effective, you can set that as their standard image.

Shown below are the 7 standard spirals, as of version 0.98.  Note that all of these are displayed with an alpha of somewhat less than 1, so the sub can see through them.  Spirals that appear static below will be displayed by the Mesmerizer as rotating clockwise.  The direction of rotation (or of animation, for frame sequences) can be reversed by using a negative number.  For example, setspiral "-1" will show spiral number 1 below, rotating counter-clockwise.

setspiral 1

setspiral 2

setspiral 3

setspiral 4

setspiral 5

setspiral 6

setspiral 7

Mesmerizer Access Control

Specifying who can access your Mesmerizer can be a little complicated.  The most important thing you should be aware of is that if someone can put you into a trance, they can execute any Mesmerizer command and place triggers for themselves or others to use in the future.   So, unless you permit only people you trust to activate a trance, it's worth keeping either yourself or someone you do trust as an owner, so that you can review and remove any undesirable triggers that might be implanted.

There are basically three types of access that someone can have to a sub's Mesmerizer, each of which is controlled differently:

• Channel 99 command access
• Placing the sub in a trance
• Triggering post-hypnotic suggestions

Channel 99 command access is the simplest.  Channel 99 access allows someone to issue Mesmerizer commands without the sub necessarily being aware of it.  It is also required for someone to be able to control the sub's Mesmerizer remotely, through a Communications Hub.  This type of access is reserved for owners - people listed in an owners= line in the Mesmerizer's Access notecard.

If someone places the sub in a trance, then, for the duration of the trance, they have access that's equivalent to owner-level access, except that instead of using channel 99, they will be given a random channel to use.   They cannot use this access remotely - only true Owners can use the sub's Mesmerizer without being within earshot of it (and only if the sub has enrolled in a Hub the owner controls).  There are three ways in which someone might place a sub into a trance:

• If they have channel 99 command access and use the hypnotize, hypnotizeac or spiral commands.
• If they use the default "sleep now <name>" trigger.
• If they use a custom re-induction trigger.

The default "sleep now <name>" trigger is equivalent to a custom trigger-rule of the form:

     sleep now $name = other hypnotizeac

The rule is defined using the other keyword which means that it's triggerable by anyone except the sub.  The trigger rule invokes the hypnotizeac command, or "hypnotize with access control".   This command will use the access control lists to determine whether the person tying to hypnotize the sub is permitted or prohibited from doing so.  The access control lists are initialized from the Access notecard.  If the would-be hypnotist is not found in either list, then the sub will be asked if they will allow the hypnosis attempt.  They can respond "yes" or "no", or they can choose "never" (which will reject the attempt and add them to the "Denied" list) or "always" which will allow the attempt, and add them to the "Allowed" list.

A custom trigger using the hypnotizeac command will operate in the same way.  However, the hypnotize and spiral commands do not check access, so a trigger using these commands will allow even someone on the denied list to induce trance, if they are permitted to use the trigger.   In general, therefore, use the hypnotizeac command in public trigger-rules, and keep the hypnotize and spiral commands for use as manual commands, or in trigger-rules restricted to specific people.

As stated above, the access control lists are initialized from the Access notecard.  This is a typical Access notecard:

reset
Owner=abcd1234-b9a1-423b-1235-c2128b4af803
Allow=7f1cfe79-71ae-4855-b766-754ec2e38bd7
Deny=*

The "reset" keyword clears the current lists when the Access notecard is read.  Without this, entries from the notecard will be added to the existing lists, rather than replacing the existing lists.  In general, you should start the notecard with "reset" until you are happy with your access permissions, and then remove it, so that permissions added subsequently via the hypnosis permission popup will not be discarded whenever something is added to the Mesmerizer's inventory (which causes the Access notecard to be re-read).

The above notecard specifies one Owner, and one other avatar who will be able to use the default sleep now trigger.  An attempt to use the default trigger by anyone else will be rejected, because of the deny=* line.  If the deny=* line were omitted (or identified a few specific avatars instead of using a wildcard), then when anyone else attempted to use the default sleep now trigger, or any trigger that runs the hypnotizeac command, the Mesmerizer would prompt the sub as to whether or not they were willing to succumb to the attempt.

The Enforcer - Progress Report

I've been making good progress on the Enforcer, so I thought I should give an update.  But first, time for a confession. 

The current published version of the Mesmerizer is 0.98m, not the 0.98l that I intended.  The day after I released 0.98l, I needed an expression evaluation function for use in the Enforcer.  Partly because I'm lazy, but mostly to ensure consistency between the Mesmerizer and the Enforcer, I decided to reuse the expression evaluation code from the Mesmerizer in The Enforcer.  This has the big advantage that you'll only have to become familiar with one syntax for Reverse Polish expressions, as the expressions are almost identical between the Mesmerizer and the Enforcer (the only difference being that the Enforcer doesn't implement the isdefined operator).  For my first test of the ported expression code I had it add 1 and 1 - and to my surprise I found it couldn't do it.  It turns out that I'd omitted the plus and minus operators in the original Mesmerizer code.  Perhaps adding and subtracting aren't things that a trigger rule needs to do very often, but it was still embarrassing to discover they weren't there.  Adding them was trivial, and so I re-issued the Mesmerizer as 0.98m with the fixed code.  I took the opportunity to rationalize (and update this blog to correctly document) a couple of operators whose argument order was the reverse of what you'd expect.  I've sent out the 0.98m update to people who bought from vendors;  I'm in the process of updating Marketplace purchasers.

Now onto the good news - the Enforcer is coming on well.  For those of you who haven't waded through this blog, the Enforcer is a device that connects to one or more CHAOS Communications Hubs and provides two distinct functions - management of the Hubs and programmable control of users.  The Hub management features include providing a single point where users can be viewed across all your Hubs, and the ability to "bridge" Hubs together so that chat and/or command traffic on one Hub can be forwarded to another Hub, linking the user communities of the two Hubs.  The user control aspects are somewhat similar to event triggers within a Mesmerizer - the differences are that they are stored in and executed out of the Enforcer, so a given event response can be shared by multiple users, and can be defined or changed even when the affected user(s) aren't logged in.

Event rules in the Enforcer can:

• issue Mesmerizer commands, by default to the Mesmerizer that generated the event, although you can specify a different recipient
• send instant messages to specified users
• send email
• set and use variables, which  can be either global and long-lasting, or transient and exist only for the duration of the event.
• call other event rules
• contain conditional logic

Most events are triggered by a Mesmerizer connected  to one of the Hubs associated with the Enforcer.  There are a few standard events - logon, logoff and location change, but I recently decided to add custom events.  This requires a new "signal" Mesmerizer command to signal an event, so the Enforcer release will be accompanied by another Mesmerizer update.  There are a few events that are triggered by things other than a remote Mesmerizer - a Hub web address changing generates an event, for example, so that an Enforcer rule can be defined  to send an IM and/or email to interested web users to inform them of the new address.  I will probably allow for custom events to be locally-generated too, so that Enforcer rules can be used to automate multiple-command sequences that would otherwise have to be manually typed into a Communicator.

I don't yet have a launch date, but I don't expect it to be much later than the end of April.

Idioms: silent self triggers and gestures; facial expressions

The Mesmerizer offers a lot of functionality that isn't necessarily tied to controlling the sub.   For example, the express command can be used by the sub to adopt various facial expressions.  It takes a single parameter, which is a comma-separated list of expression names to be activated, or, if the name is preceded by "no", to be deactivated.  Any expressions that are already playing will continue to play if they are not mentioned.  "all" is used to indicate all possible expression animations; it's mostly used to cancel all expression animations: express noall.

If the sub isn't listed as an owner in their Mesmerizer's Access notecard, they can't issue commands directly, but an owner can define triggers for them that will do this.  Since the sub won't want to accidentally fire an expression trigger in regular speech, you should make the trigger-phrase something that they are unlikely to say except when they want to fire the trigger, for example "se1" (short for 'set expression 1') for, say, a smile expression:

se1 = subject express smile

Note the use of the subject keyword at the start of the trigger-action.  This keyword means that this trigger will fire only when spoken by the sub.  Now, whenever the subject says "se1" in local, they will smile.  You should probably define a trigger to let them stop making faces too:

se0 = subject express noall

Speaking incantations like "se1" in open chat would be a little distracting to the people around the sub, so the Mesmerizer will also accept self-triggers spoken on channel 98.  So to smile without saying anything strange in local chat, the sub would do "/98 se1".

Finally, the sub could create gestures that issue these channel-98 commands, allowing them to define a keystroke to cause them to smile.  Since gestures can include wait steps, it's easy to define one that will start to smile by issuing a "/98 se1", wait for a few seconds, and then return to a neutral expression with "/98 se0".

Gestures and channel 98 can be used to link any self-trigger to a keystroke.  So you could create, for example, a "panic button" that uses the tpto command to teleport the sub to a safe location.