Hypnosis in Second Life

Someone asked me today "Do these trance things really work?".  I thought that was a question that would have wider interest, hence this post.

To start with, the majority of hypnosis in Second Life is role-play.  This post isn't concerned with RP hypnosis, although I will probably make another post that does discuss RP, as well as the blurring that can sometimes happen between RP and genuine hypnosis, which when it does occur can be either very exciting for the sub, or alarming.  This post considers the sub who genuinely wants to experience hypnosis, and the various options available within Second Life to help achieve that goal.  I'm using the word "sub" here in the same way as I use it in the Mesmerizer documentation - as an intentionally ambiguous abbreviation of both "submissive" and "subject". 

A hypnosis session can be undertaken for a number of reasons, from simple relaxation, to creating a vivid experience of some imagined event or activity during the trance, to establishing triggers for post-hypnotic suggestions, to changing behaviors.   A discussion of dangers and ethics of anything more than simple relaxation is the topic of another post.

Hypnosis devices in second life fall into basically two categories - ones that play back pre-recorded trances, and ones designed to aid a live session between a hypnotist and a sub.  So the first part of my attempt to answer the "does this work" question will be about the differences between a live and a pre-recorded trance.

We'll start with what a "pre-recorded trance" in second-life actually is.  It's a hypnosis script - a series of sentences to be presented to the sub - that generally begins with an induction (the process of leading the sub into trance), possibly followed by a deepener (intended, as the name suggests, to deepen the trance), followed by the main content of the trance (which may include the description of a scene to be experienced by the sub during the trance and/or post-hypnotic suggestions), ending with an awakener, which ends the trance in an appropriate manner, usually but not always gently.  Hypnosis scripts can be used in RL hypnosis sessions, although simply reading from a script has most of the drawbacks of pre-recorded trances in SL that I'm going to discuss below.  In RL, scripts are more often used as ways of demonstrating ideas for inductions or suggestions, and are meant as a way of sharing information and ideas among hypnotists rather than to be used verbatim during a session.

In the SL instantiation of a hypnosis script, the playback device will display one sentence at a time to the sub, usually over a background of one or more patterns (typically spirals) intended to help eye-fixation, and often with (possibly changing) pictures superimposed over them.  Trances can be purchased off-the-shelf (or from-the-vendor) or can be created by a hypnotist for a specific subject.  Some brands of playback devices try, with varying degrees of success, to prohibit their owners from creating their own trances; others encourage the practice.  Using a typical playback device consists of selecting a particular trance, and having the sub either sit on or wear the device, although the activation mechanism varies.  Depending on the playback device, as well as how it is set up, the sub may perform the selection and activation themselves, or a separate operator might do that.


So running a pre-recorded trance is a matter of "select and watch".   Compare that to a typical live trance with a new subject that would start with a pre-talk where the hypnotist explains what hypnosis is, and gives the sub the opportunity to ask questions.  The pre-talk helps the sub establish expectations for the upcoming trance, and allows the hypnotist to address any concerns the sub might express, as well as agree on bounds and limits.  It also serves to establish a degree of rapport between a sub and hypnotist if they didn't already know one another.

During the actual trance session, the hypnotist will continually monitor the sub's responses, and adjust pacing and approach based on what seems to be the most effective.  Individuals respond differently to different approaches - some people are very visually-oriented, and respond well to a detailed description of a scene, perhaps augmented with images, whereas others prefer to rely more on their own imagination, requiring the hypnotist to be more vague and open in his or her descriptions, to avoid contradicting something the sub is picturing, which can be jarring.


Pre-recorded trances lack at least four things compared to a live hypnosis session:  Pacing, Personalization, Participation and Rapport.   Pacing is the ability of the hypnotist to monitor the sub and adjust the speed of the trance, perhaps repeating things or trying a different approach if resistance is encountered, or going faster for a receptive sub.  Personalization is to do with tailoring the trance content based on the combined goals (desires and kinks) of the sub and the hypnotist.  Participation is the inclusion of the sub in the trance - asking questions, providing a way for the sub to have input both before and during the trance.  Rapport is to do with trust between the hypnotist and sub, and being comfortable with one another. 

All of these are missing in an off-the-shelf trance.  It would be possible to allow the sub to control the speed at which sentences of a script are delivered, but I don't know of any playback devices that offer that ability once a session  has started.  Unless the sub happens to know the creator of an off-the-shelf trance, there is no live hypnotist with whom to establish rapport.  Obviously an off-the-shelf trance will not be personalized, beyond the possible substitution of the sub's name into the text.  None of the devices I'm aware of allow any sort of participation by the sub, who is simply expected to sit back and watch.

In an ongoing relationship between a hypnotist and a sub, each session would build on the previous ones, refining and reinforcing triggers, exploring and enhancing the sub's ability to experience various hypnotic effects, and generally improving the effectiveness and efficiency of the trances as the relationship progresses.  This could be automated in a fairly primitive way, if trance machines kept track of what trances they had played for whom, and adjusted their scripts according to each sub's trancing history, but I know of no playback devices in Second Life that attempt to do that.

This isn't to say that pre-recorded trances can't work.  The ability to enter trance is something that you learn how to do, and some people are naturally good at it, and for these subs, the limitations of pre-recorded trances may not be show-stoppers.  Off-the-shelf trances still have the problem that in general their goals and content are not disclosed in advance in anything more than a very general sense, and it's usually hard or impossible to preview a pre-recorded trance for content as often the only way to see what's in it is to run it.  Many of the pre-recorded trances that I've looked at are intended for RP use, making suggestions that only make sense when interpreted within the Second Life virtual world. This is a pity, as it encourages the idea that hypnosis in Second Life is just role-play.  It's also difficult to predict how someone who actually lets themselves be drawn into a trance would react to these suggestions.


A step up from the off-the-shelf pre-recorded trance is the custom trance.  If a trance is recorded by a hypnotist for a specific sub, and there is already a degree of rapport between them, that can make the trance much more effective.  Participation by the sub is still not possible (at least, not actually during the trance with any of the playback devices I'm aware of today), and pacing is still fixed, but at least that fixed pace can be chosen based on knowledge of the sub, and the content would be set in a similar way as in a live trance: based on shared desires.

The fact that custom trances have the potential to be far superior to off-the-shelf trances is why my own playback products, the MesmerX and the HoloTrainer, are both intended to be loaded with trances keyed to specific avatars, rather than offering a number of off-the-shelf trances to be chosen from a menu.


Best of all is a live session.  Staying within Second Life, this can be either with text, using local chat, instant message, or on-screen text that some hypnosis devices support (e.g. the Mesmerizer's text command), or with SL Voice.  Voice has several advantages both to the sub hearing their hypnotist's voice and to the hypnotist hearing the verbal and non-verbal reactions of the sub.  Also, some people have a natural tendency to close their eyes in trance, and this can obviously make the use of text problematic for these subs.  This tendency can be overcome with practice though, so text can still be used with such subs, after training.  And the requirement to keep the sub's hands available to type responses can make some in-trance activities challenging.   But text has advantages too.  The sub will often imagine "hearing" text created by a favorite hypnotist in a voice that's actually superior to that hypnotist's real voice.  Also, text allows the hypnotist a little time to play with wording before pressing 'send', which can make for more literate trances.  Of course, this advantage can be offset by the opportunity for typos.

With both text and voice, some hypnosis devices (such as the Mesmerizer) can aid the process by providing visuals - for example patterns such as spirals that start off as aids for eye fixation but that with repeated use quickly become anchors for the trance state, or background pictures to help illustrate the hypnotist's words; on the other hand, devices that can only replay pre-recorded trances are generally not useful with live trances.



So yes - these "trance things" can work, but how well they work depends very much on the sub.  Almost universally however, live trances are much more effective than recorded trances, and personalized recorded trances are much more effective than off-the-shelf recorded trances.  It does require practice and confidence to take on the role of hypnotist, and the sub may have difficulty connecting with someone they trust who has both the inclination and the ability to take on that role.  Many subs may quite reasonably be wary about trusting their subconscious minds to an unknown hypnotist.  In a situation like this, pre-recorded trances may be the best option available.

Miscellaneous Updates

As mentioned in a previous post, I've been working on a bunch of enhancements to the Mesmerizer, which I hope to have completed soon after Thanksgiving, ready for a December release.  These include "bound poses", that will work with LockGuard-compatible collars and cuffs to draw chains where appropriate, for both binding and leashing, as well as scripts, which allow sequences of Mesmerizer commands to be stored either dynamically or in notecards and played back by a single command.

In addition, I've been working on some enhancements to the Communications Hub.  These include both minor usability features, like allowing the user registry to be stored in a notecard for safety, and significant new features, the most important of which is web access.    This allows the Hub's owner, as well as users they authorize, to connect to the Hub from the Internet via a web browser, and take part in Mesmerizer chat, or issue Mesmerizer commands to in-world users.  Like the communications mechanism itself, all processing is done in the Hubs, which means that there is no dependency on any external database or web service for any of the Mesmerizer features.  I was originally intending Web Access to be an add-on product, but I have now decided that it should be a standard Hub feature.  If you want it, all you have to do is turn it on in your Hub.

I also have a brand new CHAOS product under development, that I'm provisionally calling The Enforcer.  This is a monitoring device for one or more hubs, that will allow for the automatic playback of commands in response to Hub events, such as a user logging on, or moving to a different sim.  In effect it provides centralized event processing for multiple Mesmerizers.  You can use it for anything from displaying a message of the day (or image of the day) to your Mesmerizer users on login (or at random times), to centrally enforcing sim or other restrictions.  Another useful ability is that it can be set to send notification emails when a connected Hub changes its http address, which will happen whenever the Hub's sim is restarted.

Finally, I have been contemplating an "Owner's HUD", that would simplify the use of the Mesmerizer command interface.  There are two "levels of integration" at which such a HUD could be implemented.   The first would be simply as an alternative to issuing Mesmerizer commands directly, so that the HUD would mostly serve to avoid having to learn the different commands and their parameters.  Any communication back from the Mesmerizer would still come to the owner, rather than the HUD.  Allowing the HUD to receive and process responses would be the second level of integration, and would require enhancements to the communications protocol (and therefore both the Mesmerizer and the Hub).  I'm still weighing up the pros and cons of each approach, although it doesn't have to be an either-or decision - I could release an Owner's HUD that initially only transmits commands, and then add the communications enhancements to support a response channel in an update.

Mesmerizer Command Reference, Arousal

Arousal play is a staple of RL erotic hypnosis.  The Mesmerizer integrates with worn Xcite! genitals, allowing this type of play to be simulated in SL.  The Mesmerizer will automatically detect whether Xcite! genitals are worn, and whenever the genitals report a change in arousal level, will update the built-in variable arousal (which runs from 0 to 100) and trigger an on-arousal event.  If the genitals report an orgasm, the on-orgasm event will be triggered.

Here are the commands relating to setting arousal level:

Command	Params	Description
arouse	1	Add to the sub's arousal.  <p1> is the amount to add, capped at 10.   Use a negative number to decrease arousal.
arouseb	2	Add to the sub's arousal, bounded.  <p1> is the amount to add, capped at 10.   Use a negative number to decrease arousal.  <p2> is the maximum level the arouseb command can cause the arousal to rise to.
arousebt	3	Add to the sub's arousal, bounded, with text.  <p1> is the amount to add, capped at 10.   Use a negative number to decrease arousal.  <p2> is the maximum level the arouseb command can cause the arousal to rise to.  <p3> is a text string that the sub's genitals will emote.
arousebtk	4	Add to the sub's arousal, bounded, with text and kink.  <p1> is the amount to add, capped at 10.   Use a negative number to decrease arousal.  <p2> is the maximum level the arouseb command can cause the arousal to rise to.  <p3> is a text string that the sub's genitals will emote.  <p4> is the name of an Xcite! kink that the arousal will depend on.
cum	0	Make the sub orgasm
chaste	1	Prohibit/allow the sub to orgasm.  <p1> is "yes" to prohibit orgasm, "no" to allow it.  The cum command will work regardless of the state of chaste.
minarousal	1	Specifies a minimum arousal level.  The Mesmerizer will continuously add arousal when the level is below <p1>
maxarousal	1	Specifies a maximum arousal level.  The Mesmerizer will continuously subtract arousal when the level is above <p1>

Mesmerizer Command Reference, Teleport

The Mesmerizer supports teleporting of the sub, both by an explicit command, and by allowing auto-acceptance of TP requests.  The following commands relate to teleportation:

Command	Params	Description
tpto	1	Teleport the sub to a specified location.  <p1> is an SLurl or map reference.  For example tpto "Help Island Public (125, 124, 27)" or tpto "http://maps.secondlife.com/secondlife/Help%20Island%20Public/128/128/27"
autotp	0	Makes the sub auto-accept future teleport offers from the command issuer
noautotp	0	Removes the command issuer from the list of people whose teleport offers will automatically be accepted
autotp1	1	Makes the sub auto-accept future teleport offers from a specified avatar.  <p1> is the key of the avatar whose requests are to be auto-accepted.
noautotp1	1	Removes a specified avatar from the list of people whose teleport offers will automatically be accepted.  <p1> is the key of the avatar whose requests should no longer be auto-accepted.
listtp	0	Lists the keys of avatars from whom teleport offers will automatically be accepted.

Mesmerizer Command Reference, Roleplay Names

As discussed in the Overview Guide, the Mesmerizer can maintain a list of "roleplay names", any of which will match the pattern "$rpname" in a trigger-phrase.  So if the sub frequently role-plays as several different characters, you can add those character names to their Mesmerizer, and define triggers that use $rpname instead of their actual name, to allow those triggers to be directed to any of their characters.

This is also useful if you want to create triggers that can operate for either individual subs, or a group.  Assume you have a group of female subs Alice, Barbara and Christine, and you want to create a "go home" trigger for each of them that will teleport them back to your home.  The obvious way would be to give Alice a "go home alice" trigger, give Barbara a "go home barbara" trigger, and give Christine a "go home christine" trigger.  An improvement would be to use a "go home $rpname" trigger for each of them, and define Alice's role-play name to be "Alice", Barbara's to be "Barbara" and Christine's to be "Christine".  If in addition you give them each a role-play name of "girls", then you will be able to teleport them individually by name, or to say "go home, girls" to teleport them as a group.

Command	Params	Description
names	0	List the sub's roleplay names
addname	1	Add a name to the sub's roleplay names.  <p1> is a name, or a comma-separated list of names to be added
delname	1	Delete a name from the sub's roleplay names
setname	1	Set the sub;s roleplay name(s).  <p1> is a name, or a comma-separated list of names

Mesmerizer Command Reference, Expressions

Expressions may only occur in a few places (currently just two, but this list may grow):

• The first parameter to executeif, that specifies the condition
• the second parameter to setvarex, that specifies the value to be assigned. 

Apart from these specific places, all other parameter positions are treated as simple strings (which may include variable expansions).  So unless you use those specific commands, the only reason to read further in this post is if you're having trouble sleeping.

Expressions are written using Reverse Polish Notation (RPN).  Any expression consists of a mix of values and operators; in RPN the values are written ahead of the operator that uses those values.  In a conventional expression, the way you'd indicate adding two values a, b and then multiplying by third value c would look like this:  "(a + b) * c".  In RPN, the same expression would be written as "a b + c *".  The main advantage of RPN is that it eliminates the need for both brackets and rules to determine the precedence of operators.

In the Mesmerizer's implementation of RPN, operators are named with words.  The following operators are currently defined:

Operator	Example use	Description
gt	x y gt	x > y
lt	x y lt	x < y
ge	x y ge	x ≥ y
le	x y le	x ≤ y
eq	x y eq	x = y (as integers)
streq	x y streq	x = y (as strings)
ne	x y ne	x ≠ y (as integers)
strne	x y strne	x ≠ y (as strings)
plus	x y plus	x + y
minus	x y minus	x - y
and	x y and	x ∧ y
or	x y or	x ∨ y
csv2l	x csv2l	convert comma-separated values to colon-demarked list
l2csv	x l2csv	convert colon-demarked list to comma-separated values
contains	x y contains	true if y is an element of colon-demarked list x
toseconds	x toseconds	convert interval x to integer number of seconds
asbool	x asbool	convert x to boolean (truth) value
asinteger	x asinteger	convert x to integer value
asinterval	x asinterval	convert x to a canonical interval
istrue	x istrue	synonym for asbool
isfalse	x isfalse	complement of istrue
isdefined	x isdefined	true if x is the name of a defined variable.  Note that 'x' should not include a leading "$" symbol - the name of the variable is needed, not its value
rand	x rand	return a random integer between 1 and x inclusive
select	aN .. a3 a2 a1 x y select	returns ax, in other words the xth a-value.  y is the total number of parameters to select, not counting y itself - in other words y must be N+1

select is an example of a vararg operator - one that takes a variable number of arguments.  Vararg operators will always take, as their nearest parameter, an integer specifying how many other parameters there are.  So in the case of select, if there are N alternatives to select from, and one more parameter to specify which should be selected, the total number of additional parameters is N+1, and this value must be specified as the final (nearest) parameter.

Some examples of RPN expressions and their meanings follow:

• "$x 1 gt" - true if the value of x is greater than 1.
• "$x 1 minus 0 gt" - true if "x-1 > 0", or the same as the previous example.
• "'$forbidden' '$sim' contains" - true if the current sim is in forbidden (assumed to be a list).  Note the use of single-quotes around the string variable expansions to keep them grouped as two single objects, even if their expansion(s) contain spaces.
• "$x 0 ge $x 5 le and" - true if (x >=0) && (x <= 5)
• "three two one 3 rand 4 select" - will return one of "one", "two" or "three"; the choice is random

Variables and expressions are expanded or evaluated as strings.  However, some contexts require particular types of values.  For example, the first parameter of the executeif command will be interpreted as a boolean value.  The strings "true" and "false" are the canonical boolean values.  Some other strings will be interpreted as "true":  "yes", "t", and non-zero integer;  all other strings will be considered to be "false".  

A colon-demarked list is simply a string representation of a list, where the elements are separated by colon characters (":"), and a colon also appears at the start and end of the string.   So a list containing "red", "green" and "blue" would be represented as: ":red:green:blue:".  The advantage of this format is that searching for an element within the list simply involves searching for a substring that is the desired element with a colon at either end.  So to search for "blue" in the above list, you would check to see whether the colon-demarked form contains ":blue:"  (and it does).

Mesmerizer Command Reference, Events and Variables

An event is a trigger-phrase, generated internally by the Mesmerizer, usually in response to some external event, that will cause corresponding trigger-rules to fire. The following events are defined:

• on-rlv-enabled - fires when RLV is detected
• on-rlv-disabled - fires when RLV is not detected
• on-enter-trance - fires when the sub is placed into a trance
• on-leave-trance - fires when the sub leaves a trance
• on-stand - fires when the sub stands from sitting on something
• on-sit - fires when the sub sits on something
• on-init - fires on login or when the Mesmerizer is reset
• on-detach - fires when the Mesmerizer is detached
• on-attach - fires when the Mesmerizer is attached
• on-teleport - fires when the sub completes a teleport
• on-region - fires when the sub changes regions
• on-report - fires every few minutes after report data has been collected
• on-mode - fires when the animation mode changes
• on-pan - fires when a PAN message is received
• on-commlink-message -  fires when a Mesmerizer chat message is received.
• on-arousal - fires when the subject's arousal changes (when using Xcite! or other compatible genitals)
• on-orgasm - fires when the subject's Xcite! or compatible genitals report an orgasm
• on-chat - fires when the sub says something in local chat (as of version 0.98b)
• on-emote - fires when the sub emotes something in local chat (as of version 0.98b)

You can define a trigger-rule to respond to one of these events simply by using the event-name as the trigger-phrase.   So a rule definition such as:

on-orgasm = internal shout "I'm cumming!!!"

would make the sub shout that every time their Xcite! genitals reported an orgasm.

You should avoid defining your own trigger-phrases beginning with "on-", to eliminate the possibility of collision with a future Mesmerizer-defined event.

Events are not passed parameters, but they can make use of variables to determine precisely why they were invoked.  For example, consider the following trigger-rule:

on-region = internal text "Entered $sim"

The effect of this rule is that, whenever the sub enters a new region, the name of the sim will be briefly displayed at the center of their screen.  $sim is an example of a variable expansion.  The Mesmerizer maintains a number of pre-defined variables, and you may define your own variables with the setvar and setvarex commands.  In the example above, sim is the name of a pre-defined variable, and $sim corresponds to the value of that variable - the name of the current sim.

Here is a list of the current pre-defined variables:

• date - a UTC date in the form YYYY-MM-DD
• datetime - a UTC timestamp in the format "YYYY-MM-DDThh:mm:ss.ff..fZ"
• sim - The name of the current sim
• parcel - The name of the current parcel
• username - The sub's username (e.g. "susan.calvin" or "fred")
• legacyname - The sub's legacy name (e.g. "Susan Calvin" or "Fred Resident")
• firstname - The first word in the sub's legacy name (e.g. "Susan" or "Fred")
• event - the name of the current event, or "none" if no event is firing.
• rlvrestricted - a comma-separated list of RLV restrictions that are currently applied.
• rlvpermitted - a comma-separated list of RLV restrictions that are _not_ applied
• rlvsavedrestricted - the last saved rlvrestricted value
• rlvsavedpermitted - the last saved rlvpermitted value 
• rlvattachlockadd - comma-separated list of attachment points locked for add
• rlvattachlockrem - comma-separated list of attachment points locked for remove
• rlvclotheslockadd - comma-separated list of clothing layers locked for add
• rlvclotheslockrem - comma-separated list of clothing layers locked for remove
• rlvsendchannels - Either "all" or a comma-separated list of permitted channels
• sitting - Key of object the sub last sat on and didn't stand up from
• hypnotist - name of current hypnotist, or "none" if not in trance
• arousal - the most recent arousal level (0..100) reported by compatible genitals.
• ReportNearbyList - "ReportXXX" variables will be described in another post.
• ReportNearby
• ReportLocation 
• ReportParcel
• ReportFacing
• ReportSittingOn
• ReportParcelFlags
• message - the most recent message the sub said or emoted in chat (as of 0.98b)

While there is nothing to prevent you using the the setvar and setvarex commands to change the value of a predefined variable, such changes will be overwritten by the Mesmerizer on an unpredictable schedule, so there is little point in doing so, and any rules that do so are relying on behavior that may change in a future version of the Mesmerizer.  You should treat all predefined variables as if they were read-only.

This table lists the commands relating to variables:

Command	Params	Description
setvar	2	Set the value of variable <p1> to <p2>
setvarex	2	Set the value of variable <p1> to the value given by evaluating the expression <p2>. Expressions are covered in a separate post

Mesmerizer Command Reference, Triggers

This section covers trigger-rules, probably the most significant feature of the Mesmerizer and the key to much of its power.

A trigger-rule is a sequence of commands (the Trigger-Action) that is named by a word or phrase (the Trigger-Phrase).   The trigger-action is executed when the trigger-phrase is used;  this is described as the trigger-rule firing.

Trigger-rules may be external or internal.  External rules are fired when their trigger-phrase is spoken in open chat by someone authorized to fire the trigger;  in addition, the sub can fire their own authorized external rules via chat on channel 98.  Internal rules are fired via one of the execute family of commands.  Since these commands may be included within the action of another trigger-rule, this allows one trigger-action to fire other triggers.

A trigger-rule is defined to the Mesmerizer via the following syntax on a command channel:

<Trigger-phrase> = <Trigger-action>

The presence of an unquoted "=" identifies this as a trigger definition;  everything to the left of the "=" is taken as the trigger-phrase, and everything to the right is taken as the trigger-action.  The first word of the trigger action may optionally be a key or one of the following keywords to specify who can fire the trigger:

• me - only the person defining the trigger may fire it.  This is the default
• subject - only the subject may fire the trigger
• other - anyone other than the subject may fire the trigger
• any - anyone may fire the trigger
• internal - the trigger is internal, and may only be fired via an execute-family command or an event.

If an avatar key is used instead of a keyword, then only that avatar may fire the trigger.

Events are triggers that are generated internally by the Mesmerizer, usually in response to some external activity.  They will be covered in a future post.

The "=" syntax is used to define triggers.   The following table describes the other commands used to manipulate defined triggers, as well as the execute commands that are used to fire internal triggers.

Command	Params	Description
list	0	List the defined triggers via a menu that allows you to move through the defined triggers and delete individual ones
backup	0	Emit a string of commands that save the Mesmerizer's state. The primary purpose of this command is to transfer settings to a new Mesmerizer, but it can also be a convenient way to see all the defined triggers in a single list
delete	1	Delete a trigger. <p1> is the number of the trigger (as shown by list or backup). The remaining triggers will be renumbered
execute	1	Execute a trigger. <p1> is the trigger-phrase of the desired trigger-rule. The execute family of commands is the only way to fire an internal trigger
executeif	2	Conditionally execute a trigger. <p2> is the trigger-phrase of the desired trigger-rule; <p1> is an expression. <p2> will be fired only if <p1> evaluates to true
executein	2	Schedules a trigger event. <p2> is the trigger-phrase of the desired trigger-rule; <p1> is an interval. <p2> will be fired after the specified interval has passed
executeevery	2	Schedules a repeating trigger event. <p2> is the trigger-phrase of the desired trigger-rule; <p1> is an interval. <p2> will be fired each time the interval passes
showsched	0	Lists the scheduled events (created via executein and executeevery). Each scheduled event has a key that can be used with the cancel command to cancel the scheduled event
cancel	1	Delete a scheduled event. <p1> is the key of the event to be canceled

The executeevery and executein commands take an interval parameter.  This is a string that specifies a time duration.   The easiest way to describe an interval is to give examples:

• "1s" - 1 second
• "1m" - 1 minute or 60 seconds
• "1m1s" - 1 minute and 1 second, or 61 seconds
• "2h30m" - 2 hours and 30 minutes, or 150 minutes
• "1d" - 1 day or 24 hours

The executeif command takes an expression as a parameter.  Expressions are complex enough to deserve their own post.

Communications Hub

The CHAOS Communications Hub, available in two versions - one inspired by the Cray X/MP and the other a low-prim modern server - probably needs an overview post.  So here it is.

As its name suggests, a Communications Hub supports communications between Mesmerizer users , as well as between users of the "CHAOS Communicator", a device that is included with the Communications Hub purchase.  A Communicator is intended for the hypnotist or dom to use, to communicate with their sub(s) or their subs' Mesmerizers, wherever they are in SL.  The Hub's owner must have owner-level access to the Mesmerizers of the users of the Hub.

The Hub does two things:

• It allows Mesmerizer and Communicator users that are connected to a Hub to take part in "Mesmerizer chat" with other users connected to the same Hub.  This is somewhat similar to SL group chat in the current beta version, although I intend to release an update that will allow chat to be optionally targeted to individual users.
• It allows for commands to be sent by a Communicator user to all connected Mesmerizers, thus extending the channel 99 command interface grid-wide.

I am working on an optional upgrade that will provide a web interface to both these functions, allowing for both participating in chat and sending commands when not logged-in to SL.

The Hub needs to be rezzed in-world.  Mesmerizer and Communicator users have to "connect to" the hub before they can use it.   Connections are persistent - as users log in and out, they will remain connected to the Hub.  However, taking the Hub back into inventory will close any connections it was maintaining.  Therefore the Hub should be left permanently rezzed to avoid having to require the users to re-connect to it.  If left rezzed, connections will persist even across a restart of the sim where the Hub is rezzed. 

The Hub maintains a list of users who are permitted to connect to it.  Adding a user to that list is a two-step process that ensures that both the Hub owner and the user give permission for the connection.  First, the prospective Hub user clicks on the Hub and chooses "Register".  This will cause the Hub owner to be notified that a registration is pending their approval.  The Hub owner must then click the Hub and choose "Validate", which will present each pending registration for approval or rejection.   If the owner approves the registration, the user will be notified by IM that they may now connect to the Hub.

Connecting simply involves clicking on the Hub and choosing "Connect" while wearing the Mesmerizer or Communicator to be connected to the Hub.  In normal use, the Hub's owner would wear a Communicator and their sub(s) would wear Mesmerizers, and both the Mesmerizers and the Communicator would go through the registration/validation/connection process.

Once the Communicator and Mesmerizers are connected, Mesmerizer users can take part in Mesmerizer chat simply by speaking on channel 97 - in other words, beginning their chat with "/97".  Text spoken on channel 97 will be sent to all connected Mesmerisers and Communicators, and displayed to their users.

The Communicator is very similar, except that it has the ability to mute the transmission on channel 97 chat.   The Communicator is a very simple HUD, consisting of a circle surrounded by a ring.  The ring shows the state of the connection to the Hub (dark if not connected, green when connected) as well as whether Mesmerizer chat transmission is enabled or muted (the ring will slowly flash green when muted).  Muting is useful if multiple Communicators connected to different Hubs are worn - you can direct your chat to a specific Hub by muting all the other Communicators.  Muting is toggled on and off by clicking the outer ring.  Once connected and not muted, chat is sent by simply speaking it on channel 97.

In addition to Mesmerizer chat, the Hub extends the channel 99 command interface grid-wide.  The circle at the center of the Communicator indicates the state of this grid-wide command channel - green is active, red is deactivated.  If the Communicator is connected (outer ring is green or flashing green), the command channel can be activated or deactivated by clicking on the center circle.  Once activated, the command channel will remain active until no commands have been sent for a minute, after which time the command channel will deactivate itself.

This means that, when the communicator is active, you can control your subs' Mesmerizers via channel 99 wherever they are in SL, just as if they were standing beside you.  Most commands operate exactly the same when used remotely;  the exceptions are the few commands that display a menu - sit "?", list and delete.  When invoked remotely, sit "?" will send a list of potentially-sittable objects and you can re-issue the command specifying the chosen one; list with operate identically to backup when invoked remotely; delete will not invoke list after completion when invoked remotely.  Other than those three, all Mesmerizer commands operate identically locally and remotely.  This means that you can pose the sub, display images or sounds to them, make them sit, or walk under your control, teleport them from wherever they are to anywhere in SL, and even define new triggers for them, all from the comfort of your virtual armchair.

Note that all connected subs' Mesmerizers will receive any commands you issue on channel 99 through an active Communicator.   This is just the same as if the subs were local to you.  If you want to send a command to just one sub's Mesmerizer, then precede the command with their name, followed by a colon.   For example, to target a channel 99 command to a sub with a username of "Susan Calvin" and a display name of "Sue", you could use any of "Sue:", "Susan Calvin:" or "Susan:" as your command prefix.

Mesmerizer Command Reference, Stripping and #RLV folder

This section covers the Mesmerizer's support for stripping clothing and attachments, and for access to shared folders (#RLV).

First, stripping. See a previous post here for a discussion on a way to make stripping work in a predictable way.

Command	Params	Description
getclothes	0	List the clothing layers the sub is wearing.
remclothes	1	Remove clothes worn on a clothing layer. <p1> is the name of a clothing layer. Clothing layers recognized are gloves, jacket, pants, shirt, shoes, skirt, socks, underpants, undershirt, skin, eyes, hair, shape, alpha and tattoo, although not all of those layers can be removed.
getattachments	0	List the attachment points where something is attached.
remattachment	1	Remove everything attached to the specified attachment point. <p1> is the name of the attachment point. Attachment points recognized are chest, skull, left shoulder, right shoulder, left hand, right hand, left foot, right foot, spine, pelvis, mouth, chin, left ear, right ear, left eyeball, right eyeball, nose, r upper arm, r forearm, l upper arm, l forearm, right hip, r upper leg, r lower leg, left hip, l upper leg, l lower leg, stomach, left pec, right pec, neck and root, as well as these HUD points: center 2, top right, top, top left, center, bottom left, bottom and bottom right. Note that some of these names include spaces, so you will have to surround them in double-quotes to group them into a single parameter to remattachment.
smartstrip	1	Remove clothes worn on a specified clothing layer, as well as other items worn from the same #RLV folder. See the post titled Stripping via RLV for more information on smart-strip.
smartstripall	1	Remove clothes worn on a specified clothing layer, as well as other items worn from the same #RLV folder, or descendant sub-folders of it. See the post titled Stripping via RLV for more information on smart-strip.

The next table lists the commands that manipulate the #RLV folder and its contents. Only the names of shared folders are visible via RLV - individual items cannot currently be named. Many of these commands take a "#RLV Path" as a parameter, to specify the folder that the command should operate on. For example, the getinv command takes a path as a parameter, and displays the subfolders within the folder identified by the path. An #RLV path is simply a "/"-separated list of folders that would be traversed to reach the intended folder. A path starting at the #RLV folder begins with a leading "/" character. So if, within the #RLV folder, there are subfolders named "cuffs", "gags" and "ropes", then the full path-names of each of these subfolders would simply be "/cuffs", "/gags" and "/ropes". If the "gags" folder contained subfolders "ballgags" and "ring gag", the full path-names of each of these folders would be "/gags/ballgags" and "/gags/ring gag".

A path starting with a leading "/" is one that starts at the #RLV folder and "goes down" to the target folder. A path that doesn't start with a "/" is considered to be relative to the last path that was used. Assume I have just issued the command getinv "/gags". This would show the two subfolders "ballgag" and "ring gag", and leave the "current path" as "/gags". Then I could issue the command getinv "ballgags" to see the contents of the "/gags/ballgags" folder, and leave that as the current path. Assume that there are two subfolders in the "ballgags" folder: "red" and "black". I could now make the sub wear the red ballgag by issuing wearoverall "red".

Two "special symbols can be used in a path. "." means "the current place", and is useful it you want to perform an operation on the folder identified by the current path. So if, instead of using wearoverall "red" above, I'd looked into the "red" folder to see if it too had subfolders, by issuing getinv "red", I could subsequently make the sub wear the red folder's contents by the command wearoverall ".".

The other special symbol is "..", which means "go up a folder". So if, after making the sub wear the red ballgag as in either of the examples above, I changed my mind and decided I'd prefer them to wear the black ballgag instead, I could use the command wearreplaceall "../black". The ".." in the path here "goes up" from the current path (/gags/ballgags/red) to the /gags/ballgags folder, and then the path continues down to /gags/ballgags/black.

The use of any path parameter will set the current path, even if the given path doesn't exist. So if, for instance, I had made a typo in the command above and typed wearreplaceall "../block" instead, then the current path would be set to /gags/ballgags/block, even though that doesn't correspond to any actual inventory folder. In this case, simply reissuing the correct command wearreplaceall "../black" would work, as the ".." would go up from the non-existent "block" subfolder to the correct /gags/ballgags folder, and then the rest of the path would go down to the correct /gags/ballgags/black folder.

Here are the #RLV folder commands:

Command	Params	Description
worn	1	List the #RLV folders that contain items worn on attachment point or clothing layer <p1>.
getinv	1	List the subfolders within the specified folder, along with an indication as to whether items are worn from them. <p1> is an #RLV Path to the desired folder. Force-given folders will not be displayed, although the output will note whether any force-given folders are present and suggest the use of getinvf below to see them.
getinvf	1	List the subfolders within the specified folder, along with an indication as to whether items are worn from them. <p1> is an #RLV Path to the desired folder. Force-given folders will be included.
wearreplace	1	Force the sub to wear the contents of the specified shared folder. <p1> is an #RLV Path to the desired folder. If items are already worn on the attachment points or clothing layers contained within the specified folder, those items will be replaced.
wearreplaceall	1	Force the sub to wear the contents of the specified shared folder, as well as any subfolders. <p1> is an #RLV Path to the desired folder. If items are already worn on the attachment points or clothing layers contained within the specified folder, those items will be replaced.
wearover	1	Force the sub to wear the contents of the specified shared folder. <p1> is an #RLV Path to the desired folder. If items are already worn on the attachment points or clothing layers contained within the specified folder, those items will be retained, and the new items will be added.
wearoverall	1	Force the sub to wear the contents of the specified shared folder, as well as any subfolders. <p1> is an #RLV Path to the desired folder. If items are already worn on the attachment points or clothing layers contained within the specified folder, those items will be retained, and the new items will be added.
detach	1	Force the sub to remove the contents of the specified shared folder. <p1> is an #RLV Path to the desired folder.
detachall	1	Force the sub to remove the contents of the specified shared folder, as well as any subfolders. <p1> is an #RLV Path to the desired folder.
find	1	Find #RLV shared folders whose names contain strings in <p1>. <p1> is a list of strings to search for, separated by double-ampersands: "&&"

Stripping via RLV

Edit: 2019/07/19:   With Mesmerizer 1.3, the "Precision Stripping" feature addresses almost all of the problems highlighted in this post.  Smart-strip still has some use for clothing articles that consist of multiple attachments that should be stripped together, but this is a rare situation.  This post will be retained for users of earlier versions of the Mesmerizer or of other RLV controllers, but for Mesmerizer 1.3 and later, the issues discussed here are mostly of historical interest.

RLV support for stripping is fairly limited today, being based upon clothing layers and attachment points, which are rapidly becoming meaningless as SL moves more and more towards rigged mesh.  A rigged mesh clothing item will appear at its proper place on the avatar regardless of the attachment point to which it's attached, so it's difficult to predict the point on which a particular item is worn, which makes stripping by attachment point a very haphazard operation.

Conventions agreed between the sub and their owner can help significantly.  For example,  it can help to make sure that mesh body parts are worn on attachment points that are unlikely to be stripped, and to explicitly use appropriate attachment points for clothing items instead of just accepting the default placing (many clothing designers seem to attach all items to the right hand point).

Another possibility is the use of smart-strip.  This requires a small amount of work by the sub when setting up his or her outfits.  The basic idea behind smart-strip is that when a clothing layer is removed (for example a pair of jeans), you would typically want to also remove associated attachments (for example a prim belt).  That is what smart-strip does - when you "smart-strip" a clothing layer item, the viewer will look under #RLV for the folder that contained the item, and if found, will also remove everything else in that folder.  So in the example above, if the sub had a folder under #RLV for "Jeans with belt" that contains both a "pants" clothing-layer pair of jeans and a prim belt,. then smart-stripping the "pants" layer would remove both the jeans and the belt.

Setting things up in this way is a fair amount of work for the sub, since it would appear that every clothing item that they want to be "strippable" has to be given its own folder under #RLV, in which case it doesn't seem to offer much more than could be done by simply using RLV to remove the folder.  In addition, smart-strip doesn't seem to support non-clothing-layer clothes (in other words mesh).  However, an alternative way of setting things up can address both of these problems, and make smart-strip a very useful tool.

Let's assume that the jeans in the example above are rigged mesh, rather than being clothing-layer items.  This would seem to make smart-strip not applicable, since smart-strip starts with a clothing-layer.  However, it is possible to easily create an invisible pants layer clothing item that can be worn along with the actual mesh jeans and belt.  Then smart-stripping "pants" would also remove the belt and jeans if they are is the same #RLV folder as the invisible pants.  Instead of creating a #RLV folder for each pair of pants, it is much easier to create a single folder under #RLV for "all smart-strip pants" that contains the invisible pants layer item described above, as well as links to anything in your inventory that you want to be considered "pants" for smart-stripping purposes.  Then to enable smart-strip, all you have to do is to ensure that you're wearing the invisible pants - smart-stripping them will then also remove anything that's linked from the "all smart-strip pants" folder.

Doing things this way means that, when you acquire a new outfit, all you have to do to make part of that outfit smart-strippable (as pants) is to add a link to the invisible pants into the outfit, and add links to the "pants parts" of the outfit to the "all smart-strip pants" folder under #RLV.   You can make different parts of the outfit smart-strippable as different clothing layers without having to divide the outfit into multiple folders.  There is no "dress" clothing layer, but a useful convention is to make dresses smart-strippable as "skirts".


Smart-strip can remove alpha layers along with mesh or prim clothing, to avoid leaving "holes" when clothes are stripped.  However, as mesh bodies become more common, alpha layers are becoming less useful.  Today, most mesh avatars include HUDs that control which parts of the body are made transparent.   A few bodies are starting to include ways of setting transparency by wearing scripted objects, which is a promising development, but as yet it is not standard.  The best way today to make stripping work with mesh bodies is to buy clothing that fits the body without requiring any tweaking of transparency.

Mesmerizer Command Reference, Media Commands

Handling of media, currently text, images and sounds, is one of the unusual features of the Mesmerizer. This section covers these topics for media that is directed to the sub - so for example, it will cover text presented to the wearer, but not text emitted on public channels.

Command	Params	Description
Text	1	Display <p1> on the sub's screen. The text will be removed after a few seconds.
Anims	0	List the names of animations stored in the Mesmerizer's inventory.
Pics	0	List the names of images stored in the Mesmerizer's inventory.
Sounds	0	List the names of sounds stored in the Mesmerizer's inventory.
Play	1	Play either a sound (that only the sub can hear) or a pose or animation. <p1> is either the name of a sound or animation in the Mesmerizer's inventory, or it's the key of a full-perm sound stored elsewhere (for example, in the sub's or their owner's inventory).
Playfor	1	Play an animation for <p1> seconds. &ltp2> is the name of an animation in the Mesmerizer's inventory.
Playloop	1	Play a looped sound. The sound will continue until the stoploop command is given. <p1> is either the name of a sound in the Mesmerizer's inventory, or it's the key of a full-perm sound stored elsewhere (for example, in the sub's or their owner's inventory).
Stoploop	0	Stop playing a looped sound.
Volume	1	Sets the volume for future sounds. <p1> is a floating-point number between 0.0 and 11.0.  The initial value is 8.8.
Showstart	1	Display an image on the sub's screen. <p1> is either the name of a texture in the Mesmerizer's inventory, or it's the key of a full-perm texture stored elsewhere (for example, in the sub's or their owner's inventory). See text for a discussion on preparing images for use with the Mesmerizer.
Showstop	0	Stops displaying a picture.
Show	1	Display an image on the sub's screen, automatically removing it after an interval (currently about four seconds). <p1> is either the name of a texture in the Mesmerizer's inventory, or it's the key of a full-perm texture stored elsewhere (for example, in the sub's or their owner's inventory). See text for a discussion on preparing images for use with the Mesmerizer.
Showflash	1	Display an image on the sub's screen, automatically removing it after a short interval (currently about one second). <p1> is either the name of a texture in the Mesmerizer's inventory, or it's the key of a full-perm texture stored elsewhere (for example, in the sub's or their owner's inventory). See text for a discussion on preparing images for use with the Mesmerizer.
Showlong	1	Display an image on the sub's screen, automatically removing it after a longer interval (currently about ten seconds). <p1> is either the name of a texture in the Mesmerizer's inventory, or it's the key of a full-perm texture stored elsewhere (for example, in the sub's or their owner's inventory). See text for a discussion on preparing images for use with the Mesmerizer.
Alpha	1	Sets the transparency of future images. <p1> is a floating-point number between 0.0 (completely transparent) and 1.0 (completely opaque). The initial value is 0.48.

The Mesmerizer displays images with a square aspect-ratio, so to avoid distortion, the textures should be square too. In terms of pixels, SL textures have to be a power of 2 on each side, so 512 x 512 pixels or 256 x 256 pixels are reasonable sizes for images intended for the Mesmerizer. If you want to display a non-square image, the best way to avoid distortion is to use an image editor to add either horizontal or vertical transparent borders so that the texture as a whole is square.

Mesmerizer Command Reference, Sitting and Moving

This post will cover the movement control commands, and those to do with force-sitting.

First the force-sit commands.  The goal here (as with all the mesmerizer commands) is ease of use.  So you can specify the object by name, or if this is ambiguous (if there are a number of identical objects, for example) you can use a key. 

Command	Params	Description
Sit	1	Force-sit on an object. <p1> specifies the thing to sit on. It can be the name of an object, the key of an object, or "?" to get a list of candidate objects. If you are in the same sim as the subject, the list will be presented as a menu for you to choose a sit-target from; if you are remote, it will be sent as a list, and you can re-issue the sit command with one of the objects as the target.
Stand	0	Stand up from sitting on an object.
Resit	0	If the subject is standing, sits them on the last object they were force-sat on; if they are already sitting on something, they will stand and then force-sat on it again. This is useful if the object expects cuffs, and they weren't wearing them when they sat originally - you can add cuffs and then re-sit them.

Now for movement control. To fully take control of an avatar's movements you should first either freeze them or play an animation (which will implicitly freeze them). If you don't do this, the movement functions will still operate, but the subject can counter the movement.

Command	Params	Description
Freeze	0	Prevents the subject from moving. They are still free to change animations unless you play an animation of your own.
Freezefor	1	Prevents the subject from moving for <p1> seconds. They are still free to change animations unless you play an animation of your own.
Unfreeze	0	Releases a frozen subject.
Turn	1	Make the subject turn, relative to the direction they're currently facing. <p1> can be left, right, sharpleft, sharpright, around.
Face	1	Make the subject turn to face an object, person or direction. <p1> can be me, a key of an avatar or object, N, S, E, W, NE, SE, NW, SW.
Step	1	Make the subject take one step in a specified direction. <p1> can be forward, left, right, back, up or down
Walk	0	Make the subject start to walk forwards.
Halt	0	Cancels a previous walk command.
Follow	0	Causes the subject to start following you.
Nofollow	0	Cancels a previous follow ccommand.
Moveto	1	Makes the subject walk to an avatar or object. <p1> is the key of the target avatar or object. Moveto is a synchronous command like summon; use continue if you need to stop it before it has completed. Being synchronous, a sequence like moveto <object-key> sit <object-key> will operate as expected - the subject will walk to the specified object and, once there, will sit on it.

Mesmerizer Command Reference, RLV restrictions

These are the commands that manipulate standard RLV restrictions. They are all of the general form MayXXX no to prohibit doing XXX, or MayXXX yes to permit it, although the last two take an additional parameter before the yes/no to indicate the clothing layer or attachment point that's being locked or unlocked.  I don't think there's anything unusual here.

Command	Params	Description
Mayedit	1	Allow/prevent editing objects. <p1> is "yes" or "no"
Mayfly	1	Allow/prevent flying. <p1> is "yes" or "no"
Mayhear	1	Allow/prevent hearing chat. <p1> is "yes" or "no"
Mayhearme	1	Allow/prevent hearing the person who set the command. Used to set an exception to mayhear no. <p1> is "yes" or "no"
Mayspeak	1	Allow/prevent speech. <p1> is "yes" or "no"
Maytalk	1	Allow/prevent talking above a whisper. <p1> is "yes" or "no"
Mayhud	1	Allow/prevent use of HUDs. <p1> is "yes" or "no"
Mayinv	1	Allow/prevent use of inventory. <p1> is "yes" or "no"
Maymap	1	Allow/prevent use of the map and minimap. <p1> is "yes" or "no"
Maynames	1	Allow/prevent seeing names. <p1> is "yes" or "no"
Mayrez	1	Allow/prevent rezzing objects. <p1> is "yes" or "no"
Mayrcvim	1	Allow/prevent receiving IMs. <p1> is "yes" or "no"
Maysndim	1	Allow/prevent sending IMs. <p1> is "yes" or "no"
Maystartim	1	Allow/prevent initiating IM sessions. <p1> is "yes" or "no"
Maysendch	1	Allow/prevent speaking on private channels. <p1> is "yes" or "no"
Maysit	1	Allow/prevent sitting on objects. <p1> is "yes" or "no"
Maystand	1	Allow/prevent standing up from sitting on an object. <p1> is "yes" or "no"
Maytouch	1	Allow/prevent touching objects. <p1> is "yes" or "no"
Maytp	1	Allow/prevent teleporting. <p1> is "yes" or "no"
Mayadd	2	Allow/prevent adding to a clothing layer or attachment point. <p1> is the layer or attachment point; <p2> is "yes" or "no"
Mayremove	2	Allow/prevent removing from a clothing layer or attachment point. <p1> is the layer or attachment point; <p2> is "yes" or "no"

Mesmerizer Command Reference

I've been slow in creating a manual for the Mesmerizer, although the combination of built-in help, the Quick-Start Guide and the Overview Guide provides a complete but brief tour of what.s available.  I do need to create a proper Command Reference Manual though, and I think the best way would be to use this blog to compile material, which can eventually be extracted into a manual.

The existing guides cover the basics of setting up and using the Mesmerizer, so I won't repeat that here.  Posts labeled "Command Reference" will contain just commands and a description of their parameters and what they do. 

Within both this blog and the Mesmerizer help, I use the notation "<p1>" to mean "the first parameter to a command"; "<p2>" means "the second parameter" etc. Parameters are separated from one another and from the command by one or more spaces, and if you want a parameter to include spaces, you have to group the words of the parameter together using double-quotes. For example, the text command that displays text on the sub's screen takes a single parameter - the text to be displayed. If you want to display the string "Hello, Sub" you would have to group the two words Hello and Sub together inside double-quotes: text "Hello, Sub".

So we'll start with the ten most basic commands.  I'll add to this list in subsequent posts.

Command	Params	Description
Help	0	Displays one-line help on every command.
Hypnotize	0	Put the sub into a trance. You will be given a channel number which can be used within the sub's hearing to issue any other Mesmerizer commands.
Hypnotizeac	0	Attempt to put the sub into a trance, using the access notecard, and if that does not provide a definitive answer, the sub will be asked if the hypnosis attempt should be allowed. This is what the default "Sleep Now" trigger does.
Wake	0	Wake the sub from a trance.
Spiral	0	Put the sub into a trance, but don't play animations or emotes. You will be given a channel number that can be used within the sub's hearing to issue any other Mesmerizer commands.  Spiral can be used if the sub is already performing an animation that you don't want to interfere with, or if you don't want it to be apparent to anyone else that they are entering trance.
Nospiral	0	Removes the spiral, but doesn't stop any animation or emit any emotes.  This can be useful to temporarily remove the spiral to allow the sub to click on some in-world object that it would otherwise obscure..
Summon	0	Makes the sub come to you. Summon is one of the few synchronous commands - no subsequent command will be executed until the summon has completed - in other words until the sub has reached you, or you are no longer within range. The continue command can be used to stop waiting for this or any other synchronous command to complete.
Continue	0	Stops waiting for a pending synchronous command. If no synchronous command is being waited for, the continue is ignored.
Follow	0	Makes the sub follow you, until the nofollow command is used.
Nofollow	0	Makes the sub stop following you.

Late September update

Although I only just pushed the "publish" button on the previous post, I did want to give an update on a couple of other new features that I've implemented, that will be available in the same update that includes support for "bound poses".

First is a new on-chat event that fires when the wearer speaks in chat.  The wearer's most recent chat is now available in a variable, and the combination of these two features makes the implementation of chat filters, garblers (think gags) or other manipulations of speech possible.  The on-chat event and the speech variable operate even if speech is prohibited (via mayspeak no), which allows for an interesting effect where open chat is suppressed but attempts to speak are redirected as IMs to an owner.  When coupled with an inability to hear anything except the sub's owner's speech (via mayhear no mayhearme yes), this enforces an isolation from other people in SL and a dependence on the owner that's much more effective that simply forcing the use of IMs.  Since the sub's owner's speech is still audible, people who overhear (one side of) a conversation are likely to figure out what's going on, which some subs may find exciting.

At the moment, implementing a decent garbler would be pretty hard, given that it would have to be done using the Mesmerizer's built-in expression language.  If I want to support this use, it would probably be better to create an "extension point" where an external script can interface with the Mesmerizer in a supported way.

The second new feature is the ability to store and execute scripts in notecards.  A script is any sequence of Mesmerizer commands, although as the original intent was to allow a Mesmerizer to carry around a collection of trances, there is special support for writing text to the wearer's screen.  Indeed, the initial implementation only supported scripting of trances, automatically enabling a spiral and background pictures during the run of a script.  However, the ability to use any Mesmerizer command means that Mesmerizer scripts are capable of being much more that just hypnosis scripts, so now the background pictures and spiral have to be explicitly enabled by the script.  While my expectation is that they will still be used primarily for stored trances, scripts can also be used to collect any sequence of commands into something that can be run by a single command.  So they are rather like the existing execute command (which allows the firing of a trigger), except that they're much better suited for running long sequences of commands, and that you can define any number of them without causing trigger recognition to slow down.

The big down-side of these scripts is, of course, that they are notecards, which means they can't be added or altered dynamically.  I have been considering supporting in-memory storage of scripts as an alternative, which would allow them to be dynamically modified.  My concern with that is around memory management - avoiding the dreaded stack/heap collision error.  I think I need to come up with a robust solution to that before I make dynamic scripts public.

Both these features, along with the bound poses and the accompanying re-vamp of modes, should be available in the beta version soon.  To upgrade, just send me an IM and I will swap your existing Mesmerizer for the current version.

New release version and looking forward

A brief update on how the CHAOS Beta is going, as well as what to look for in the next update.

 

 0.97v

So far, there has been one serious bug found in the Mesmerizer, which necessitated issuing a new release - 0.97v.  If you are using an earlier version, please contact me (Nue Broome) in-world and I'll replace your Mesmerizer with the latest release version.  The effect of this bug is that you couldn't remove a permission or denial once established.

The Mesmerizer allows you to dynamically add permissions or denials to attempts to place you in a trance, if there is no existing permission or denial that applies to the person attempting to induce the trance.  You have the option of making your permission or denial permanent.  If you choose to do this, there is no command available to revoke the permission or denial later.  Since the mesmerizer wearer typically does not have access to any commands (unless established as triggers by an owner), the way that you would remove such a persistent permission or denial would be to edit the Access notecard.  However, this only allows you to move them from one list to another - if they were permanently permitted, you could edit the Access notecard to permanently deny them access, but you couldn't return them to the default "undecided" state.

So 0.97v adds a "reset" keyword to the Access notecard.  When read, this clears all the permitted, denied and owners lists.  The intent is that, if you need to restore the mesmerizer permissions to the state given by the Access notecard you would make the first line of the notecard be reset, which will clear the lists, and then the rest of the notecard will re-populate them.  This process removes any dynamically-added "permanent" permissions or denials.  Once you've saved the Access notecard, you should open it and remove the reset keyword, and then save it a second time, so that if it is read again it won't delete dynamically-added persistent entries again.


Upcoming

The most significant new feature I'm working on at the moment is a redesign of how modes are defined, and an expansion of the concept to support bound poses, along with drawing chains, if you happen to be wearing LockGuard cuffs.

Today, a mode is a little like a mini-AO - it defines standing and walking animations that replace whatever animations your own AO has set up, to facilitate roleplay.  The Mesmerizer comes with pre-defined Ballet and Doll modes, and, like most Mesmerizer features, is designed to be user-extensible - it's very easy to add your own modes.  Today, each mode is defined in its own notecard, with a name beginning with "mode:", so the built-in modes are specified in notecards called mode:doll and mode:ballet.  These notecards just specify the animations to be used by the mode for walking and standing.  It has always been my intent to expand the animations to include some of the other motion types, such as turning and running.

I recently started looking into adding some "bound" poses to the Mesmerizer, along with the ability to draw chains from LockGuard cuffs.  This would allow you to turn any set of LockGuard-compatible cuffs into pose cuffs.  My original intent was that this would simply involve the Mesmerizer playing an animation at the same time as causing appropriate chains to be drawn.  However, there are some "bound" poses that should allow quite a lot of motion.  For example, binding your wrists together behind your back shouldn't prevent you from walking.  The "play" command, which is the normal way the Mesmerizer causes an animation to play, is intended to be used with standing animations, and actively prevents you from walking while an animation is playing.  So it struck me that these bound animations might be much more like a mode than simply playing back an animation.

This approach offers a number of nice features.  For example, even in a more severe bound position - a hogtie, for example - there can be some mobility.  The use of a mode allows a walking animation to be specified (although the "walking" animation for a hogtie would be more like "wriggling").  The mode would be extended to allow specification of the chains to be drawn, as well as any required LockGuard id values.  It might be feasible to specify "prereq" commands that would be executed if the necessary LockGuard points aren't found - so that, for example, putting you into a "Hogtied" mode would automatically cause you to wear your favorite set of wrist and ankle cuffs, if you weren't already wearing cuffs that could properly chain.  There would likely also be the ability to specify commands that would be executed on entry and on leaving the mode - so that, for example, when you were placed in that tight hogtie, the Mesmerizer would also prevent you from touching anything that's not right under your nose.

Welcome

With the release of the CHAOS range, I thought it was about time to create a blog to collect feedback on existing products, as well as share ideas and solicit suggestions about future offerings.  From time to time I might offer freebies here too.