Announcing CHAOS Mesmerizer V1.0

The Mesmerizer beta is finally over.  Version 1.0 is live in Vendors and on Marketplace.  It's been a very long time in coming - the beta has been going on for two years now, and I just found the very first version I wrote back in 2011.  But just because the beta is over, doesn't in any way mean that the Mesmerizer is frozen - I have a list of things I want to add, and I'm happy to consider feature requests too.

As announced earlier, the release version is copiable but not transferable, unlike the beta which was transferable but no-copy.  Since you may have given a Mesmerizer you purchased during the beta to someone else (e.g. a sub), I won't be sending release version Mesmerizers out to beta purchasers directly.  Instead I'll be sending out transferable gift vouchers that can be exchanged for a release Mesmerizer.  Thus, if you gave your beta Mesmerizer to someone else, you can give the gift voucher to them to redeem to get the release version.  If you bought your beta Mesmerizer as a gift at the time of purchase (rather than buying it for yourself and subsequently transferring it to someone else), then the recipient will receive the gift voucher.

As a thank-you for being an early adopter, I'm also including a second gift-card that can be spent at any of my vendors.  The packages containing the two gift cards and detailed instructions on how to use them should go out later today (12/10).  Make sure you don't discard the package when it's offered to you.

Now that Mesmerizer V1.0 is out, I will be turning my attention back to the Hubs and Enforcer.  I've had a lot of feedback, most of which I've already incorporated, so the bulk of the remaining work will be in testing.

As mentioned in a previous post, I'm also working on an "Owner HUD" for the Mesmerizer.  This will, of course, be fully remote-capable (if you're also wearing a Communicator).  It probably won't offer all the Mesmerizer's commands, but will give you pushbutton access to the most common commands. In addition to providing a visual way of issuing Mesmerizer commands, the HUD also adds a few new features of its own:

• Logging of channel 99 commands issued (by either the HUD or the owner)
• Easy teleporting by dropping a landmark into the HUD, as well as a "TP to me" feature.
• Simple way to enter multi-line text commands - no more having to use "\n" to insert a newline.

The HUD will require a release version Mesmerizer - it won't work with any of the published beta versions.  I don't have a likely ETA yet for the HUD, but if anyone would like to see an early version, just send me an IM to that effect.

One more thing...

Two more things actually.  As I was wrapping up 0.99g coding, I added two more commands: the spiralalpha and setgroup commands.  They will be in this update, as well as all the things mentioned in the last couple of posts.

spiralalpha was a user request, and does pretty much what you'd expect.  It takes a single parameter which is a floating point number between 0.0 and 1.0, and sets it as the alpha (or opacity) of the spiral. An alpha of 1.0 means the spiral will be completely opaque, and non-zero values below 0.1 will be almost completely transparent.  Attempting to set it to 0 will reset it to its default value, which is 0.58.

setgroup takes a single string parameter which can be either the name or the key of a group that the subject belongs to, and it will set that as their active group.  I was prompted to add this feature as a result of frequenting a sim with rather aggressive group-based security:  if you enter the sim and you're not wearing the authorized group, then you'll be ejected in 30 seconds.  I got fed up with scrambling for my groups once the first warning arrived, so I added the ability to change groups to the Mesmerizer.  When used in conjunction with a couple of trigger rules, the group activation can be made automatic.

Assume that the sim in question is named "Ejection City", and the group that has to be active to be allowed to remain is called "City Dweller".  First, create an internal trigger to switch to that group:

/99 dwell = internal setgroup "City Dweller"

Then create a second trigger that will fire when you change regions, and which will invoke the first trigger if you're in "Ejection City":

/99 on-region = internal executeif "'$sim' 'Ejection City' streq" dwell

Note the use of double-quotes around the expression parameter to executeif, to group '$sim' 'Ejection City' streq into a single parameter, and also the use of single quotes within that expression around $sim and Ejection City to similarly ensure that each of those is treated as a single argument to streq.

Now, whenever you enter a new region, the second rule will fire.  That rule compares the current sim-name with "Ejection City", and if it matches, it invokes the first trigger, which will set the active group to "City Dweller".  So now I no longer have to worry about being too slow in changing groups and getting accidentally ejected.

Of course, you'll have to wait for 0,99g to be released before you can do this yourself.  I did send out the note to purchasers concerning the permission changes that I mentioned in the previous post, as well as sending it as a group notice to my support group, and I've pretty much decided that 0.99g will be when I make that change.  So if you bought a Mesmerizer and have given it to someone else, please send me a notecard with your name and the name of the person you've given it to, so that they will get future updates, rather than you.



Edit, 12/11/2017:

I gave a couple of triggers above that allow you to have the Mesmerizer automatically set your default group on entering a sim.  It turns out that doing this can run into an extremely annoying SL bug.  Apparently, changing the default group stops the rezzing process, so if you change your group very soon after entering a sim, you may find that various objects don't rez at all, and stay invisible.  They're still there, in that you can't walk through them, but you won't see them, and you can't click on them.  The only way to bring them back is to TP out of the sim and then come back again.

The solution is relatively simple.  I gave the following as the trigger above to change the group:

/99 dwell = internal setgroup "City Dweller"

To avoid this SL bug, you just need to delay the group change for long enough that the scene will be rezzed, for example:

/99 dwell = internal wait "10.0" setgroup "City Dweller"

August update

The previous post talked about the upcoming 0.99g version of the Mesmerizer.  This release has grown somewhat, both in response to feature requests from users, as well as some bugs that surfaced from a new project, which I'll preview below.  As well as the two items discussed in the previous post - supporting multiple results from #RLV folder searches (which required the ability to handle list variables), and subliminals - 0.99g will now also include these new features:

• A variant of the text command that allows you to specify how many seconds the text should stay visible.  Specifying 0 makes the text remain visible until replaced or explicitly cleared.  This can be useful during trance, to avoid "blanks" between phrases.
• A fix for color handling and newline processing within in-trance text.  Previously, these options were honored by on-screen text when not in-trance, but broken when a spiral was displayed.
• A fix for the image distortion that crept in unnoticed (by me at least) in an earlier update.
• A fix to make negative setspiral numbers work properly.  Now they mean the same as the corresponding positive spiral number, except the spiral will rotate in the opposite direction.  I will also be documenting how to add your own custom spirals.
• A new feature where, when in trance, the up-arrow and down-arrow keys can be used to supply yes/no responses.  This is discussed in more detail below.
• A change to allow commands to be issued by a device worn by an owner.  This is needed to support the new Owner HUD.

The new 'feedback' feature was a user request, and is intended to allow a subject to respond easily to yes/no questions when in trance.  Subjects who are touch-typists typically have no problem in using the keyboard to type complex responses, even in trance.  But many people have to look down at the keyboard when typing, which immediately pulls their focus away from the trance.  I often ask new subjects to position their hands over the keyboard so that they can easily type Y or N without looking down, but that still requires two keystrokes (Y or N, plus the Enter key), and the keys are far enough away from one another that they usually need to use both hands.  So 0.99g provides a feature where, when in trance, the up-arrow and down-arrow generate "yes" or "no" responses in local chat.  There's visual feedback on the screen, in the form of a green "thumbs-up" icon, or a red "thumbs-down" icon.  And if you press the arrow keys multiple times within a short interval (half a second), you can indicate stronger agreement or disagreement (indicated by the somewhat Orwellian "+yes" or "++yes" and "-no" or "--no").

I will likely also make the change in permissions I've been talking about, making the Mesmerizer copy/mod/no-transfer.  Currently, it's no-copy/mod/transfer, the intent being that this allows a dom(me) to buy a Mesmerizer and configure it before transferring it to a sub.  This ability for the dom(me) to configure the device is valuable, but I intend to address this requirement with a separate tool, to allow just the transfer of configuration information (which will also serve as a configuration backup).  More on this in a future post.  When I do switch from transferable to copiable, I won't be able to send out the initial copiable version of the Mesmerizer automatically, since if anyone has transferred their Mesmerizer, the current owner should receive the update, and not the original purchaser.  So I'll be reaching out to current purchasers, asking them to let me know who should get future updates for the Mesmerizers they've purchased.  I'll be making a similar change in permissions to the Hubs in their next update, and again will be reaching out to prior purchasers first.

Other than the Mesmerizer itself, the other big news is that I've been working on an Owner HUD.  This will let you issue the most common Mesmerizer commands at the push of a button.  It also makes using the on-screen text command much easier than the command line, especially if you like to create multi-line messages.  With the HUD, you just type them as multiple lines - no need for messing around with "\n" character sequences.  The HUD also echoes the text and the commands that it sends, so that they appear in your local chat log, but are not visible to anyone else.  It similarly echoes Mesmerizer commands you manually type on channel 99, giving you a record of those too.  The Owner HUD works seamlessly with a CHAOS Communicator, allowing it to control remote Mesmerizers.

I expect the Mesmerizer 0.99g update to be ready for release very soon, with probably a preview version of the Owner HUD to follow soon after.

Q2 Mesmerizer Update

It's been a slow year for releases so far, but I haven't been idle.  I've been working on the updates to the Hubs and The Enforcer that I mentioned in the previous posting, along with looking at the update process in general.  Much of the CHAOS range involves configuring things with notecards or other additional inventory, and doing updates by simply replacing an item with the updated version makes for a lot of manual copying of these extra configuration items.  And for the Hubs, replacing them with an updated version requires that all the users have to reconnect.  The user migration feature that I have planned will help with this, but it would be better to perform updates in-place where possible, which is what I've been focusing on for much of the year.

In the previous post, I said that the Hubs and Enforcer updates would likely come out before the next Mesmerizer update.  I think I'm going to change my mind on that now.  As a result of user feedback, I have a couple of new Mesmerizer features that I'd like to get out ASAP, so I will likely release a Mesmerizer update first, as soon as I'm happy with the testing.

There are two main features I've added.  These are subliminals and multiple #RLV folder searching.

Subliminals

In the context of the Mesmerizer, subliminals are text messages that are selected at random from a set defined by the Owner, and are displayed briefly at random places on the wearer's screen.  These messages aren't really "subliminal" - for a message or image to be truly subliminal, it would have to be displayed in such a way that it wasn't visible to the conscious mind, but hypothetically would be seen and understood by the subconscious.  That's the definition of "subliminal" - something that's "below the threshold of sensation or consciousness".  Research pretty much indicates that true subliminal messages don't really work - if something is shown in such a way as to be invisible to the conscious mind (for example, being displayed in a single frame in a movie), then the subconscious won't see it either.

In the Mesmerizer, however, they can be useful in several ways.  First, in RP, they can be assumed to work as true subliminals, and the sub can roleplay being affected by them.  And in the context of genuine hypnosis, they can be used as subtle reminders or reinforcements of suggestions.  There are four new commands that relate to subliminals:

Command	Parameters	Description
subliminal	1	Start displaying subliminals as indicated by <p1> (see text). Specify "-" to disable subliminals without discarding them, and "." to re-enable them.
listsubliminals	0	List the current subliminal(s) and available sets.
subliminaltiming	2	Defines the timing to be used for subliminals. <p1> is the mean interval in seconds between displaying subliminals (default = 20 seconds); <p2> is the length each one is displayed (default = 0.5 seconds). Remember that a period is treated as a separator, so to include one in a parameter value, you need to enclose the parameter in double-quotes
subliminalparameter	2	Defines a parameter to be used within subliminals (see text).

The subliminal command is the most interesting of these. It takes a string parameter, which can be either of the two 'special' strings "-" or ".", or it can specify the actual subliminal messages to be displayed.  The two special strings are used to temporarily disable ("-") and re-enable (".") display of subliminals, without discarding the actual strings.  This is especially useful within a login event trigger - the actual subliminal messages are retained when the wearer logs out, but upon relogging, the display will be temporarily disabled.  Simply adding a subliminal "." command to a login event handler in either the Mesmerizer or The Enforcer will cause display of the currently defined subliminals to be automatically restarted on each login.

When used to define the actual subliminal messages, the parameter consists of one or more items, separated by commas, where each item is either a string that will be displayed, or "set:" that identifies a notecard containing a set of subliminals, one on each line.  The name of the notecard must start with "Subliminal:", and everything after that is the name of the "set".  So, assume you had added a notecard to the Mesmerizer called "Subliminal:Obedience", containing three lines:

Obey
I Need to Obey
I Love to Serve

The command subliminal "set:Obedience" will begin displaying subliminals, chosen at random from the three lines of the notecard, at whatever timing is currently in force.  Or you could augment the set with a literal string of your own: subliminal "set:Obedience,Obedience is Pleasure" - now each time a subliminal is displayed, it will be randomly chosen from four strings - the three in the notecard, and "Obedience is Pleasure".

While each subliminal string in a notecard has to appear on a single line, you can use the "\n" character sequence within a string to make the resulting text appear as multiple lines on-screen.

Subliminal strings, either in a notecard or given directly in the subliminal command, can contain 'parameters'.  This is mostly so that I can include some sample subliminal sets that can be used directly, without requiring editing.  The use of subliminal parameters is best illustrated by an example.

Assume you wanted a subliminal message to say "I will obey my owner".  That's fine, but it's rather impersonal.  It would be better for the message to include your name, for example "I will obey Fred".  And indeed you can create subliminals that contain your name like this.  But it's more flexible to used a parameterized syntax, where the subliminal includes a "placeholder" where the owner name will be inserted.  This lets you set the owner name without having to change the subliminal text.  So in the above string, instead of "Fred", you would put the special string "{O}" which means "Insert the O (Owner) parameter here".  The O parameter is defined via the subliminalparameter command, like this:

subliminalparameter O "Fred".

This defines the "O" parameter to be "Fred", so that the subliminal string "I will obey {O}" will be displayed as "I will obey Fred". 

Currently, "O" is the only supported parameter, but the syntax allows for other future parameters to be added.

The notecard(s) containing subliminal sets aren't stored in the main prim of the Mesmerizer.  Subliminals have added a new prim, and this is where the wearer has to put any notecards that hold sets of subliminal strings.  To make the process of adding notecards to non-root prims easy, you can use the existing maintenance command.  This command takes one parameter, which is either on or off.  Maintenance on will put the Mesmerizer into Maintenance Mode, where the various prims that might need adjusting become visible to the wearer.  Each of the major prims becomes an icon - a set of gears to indicate the main (root) prim where most of the scripts and configuration are, a "brain" icon, which is where the scripts responsible for storing triggers are located, a "loudspeaker" icon, which holds scripts relating to batching messages and the help system, and a "bat" icon, which is where the subliminals live.  So, for the owner to add a subliminal set notecard:

1. Create the notecard in your inventory and fill in the strings, then give it to the wearer.
2. Issue the maintenance on command to make the component parts of the Mesmerizer visible to the wearer as icons.
3. Have the wearer right-click one of the Mesmerizer icons and choose "edit".  An edit dialog should appear, and all icons should appear highlighted.
4. Have the wearer select the "Edit linked" checkbox in the edit dialog, and then click the "bat" icon, so that it is the only one highlighted.
5. Have the wearer switch to the "Content" tab in the edit dialog - they should see a script called "~Subliminals", plus any existing subliminal set notecards.
6. Have the wearer drag the new notecard from their inventory into the Content tab.  The notecard should now appear in the tab along with the script.
7. Have the wearer press "Escape" to exit the edit dialog.
8. Issue the maintenance off command to take the Mesmerizer out of maintenance mode.

Once the notecard is in place, you should be able to see it via the listsubliminals command, which displays all the current settings for subliminals, as well as the sets that are available.

The subliminaltiming command allows you to specify the average interval between subliminals and length of time for which each subliminal is displayed.  So subliminaltiming 20 "0.3" will cause subliminals to be displayed on average every 20 seconds, and each one will be shown for 0.3 seconds (which is probably a little too fast to read unless the messages are short).  The first parameter is the mean interval - subliminals will actually be displayed at random intervals, to prevent the wearer from predicting exactly when the next one will be shown.

#RLV searching

The Mesmerizer has had the find command for a long time.  This command looks for a folder beneath the wearer's #RLV folder that contains the string specified as a parameter.  So, for example, find cuffs would return "/MD Cuffs" or "/Restraints/Cuffs/My Cuffs" if one of those folders existed in the wearer's inventory.  There are two problems with the find command.  The first is that there is a difference between RLV and RLVa in that RLVa performs this search in a case-insensitive fashion (which is what's usually wanted), whereas RLV, at least in some viewers, appears to be case sensitive.  This isn't something the Mesmerizer can easily fix.  The second problem is that find returns only one folder name, even if there are multiple matches.  The RLV recently added a new search function to address this, and in this update I have added the findall command to make it available through the Mesmerizer.

As its name suggests, findall returns all the folders that match the provided search criteria.  The search parameter to both find and findall can be more than just a simple string - it can contain several strings, concatenated with "&&" and will only return folder names that match all of the strings.  So find "cuff&&leather" should match any of "/Leather cuffs", "/Cuffs (steel and leather)", but not "/MD Cuffs".

The findall command sends a message to the command issuer, listing all the matches found, along with index numbers.  For example:

/99 findall nude
[10:56] Nue's Mesmerizer v0.99g: 1: /Nude
2: /Nude Attachments (Standard)
3: /Nude Attachments (Emerald)


The index numbers are used to pick a specific folder.  Recall that the find command sets the variable rlvpath to the search result, so that having performed a successful find, you can then use $rlvpath in a getinv or wear command. findall sets rlvpath too, but only to the first path returned (/Nude in the above example).  But findall will also set the rlvpaths variable (note the s on the end).  Using the same example, rlvpaths will be set to ":/Nude:/Nude Attachments (Standard):/Nude Attachments (Emerald):" - in other words a colon-separated list of the individual paths, with additional colons at start and end.  The Mesmerizer uses this list format elsewhere, and provides built-in functions for testing membership in a list in this form.  As of this update, you can also use a dot-selector notation to pick a specific element from a variable that contains a list.  So, if rlvpaths contains the above list, the following variable substitutions work:

Variable	Result
$rlvpaths	:/Nude:/Nude Attachments (Standard):/Nude Attachments (Emerald):
$rlvpaths.1	/Nude
$rlvpaths.2	/Nude Attachments (Standard)
$rlvpaths.3	/Nude Attachments (Emerald)

So, if findall returns you a single match, then to navigate to that match you can use $rlvpath just as with the find command. But if multiple matches are returned, you can use $rlvpaths.1, $rlvpaths.2 etc. to easily navigate to whichever match you want.


I will be releasing the 0.99g update shortly.  I'll announce it in this blog, and via the in-world CSD Support group.

Update 6/24:  During testing, I've come to realize that findall is a complete replacement for find, in that it preserves all behavior of find (other than the detailed format of the user message), and so there's no need to introduce a new command.   I will simply extend the find command to have the new behavior documented above for findall.

Update 5/8/2019:  As part of the support for installers in Mesmerizer 1.1, subliminal notecards must now be named with a prefix of "Subliminal:".  So in the example above of a subliminal set called "Obedience", the corresponding notecard would be named "Subliminal:Obedience".  Also, the use of an installer to install a subliminal notecard is much simpler than the manual process described above, and should be used instead wherever possible.

First quarter 2017 update

It's the end of March, and so far this year there have been no product updates.  That won't last though.  I've been working on updates to both the Communications Hubs and The Enforcer.

Communications Hub

The Communications Hubs have an annoying bug where sometimes, when the sim they're in is restarted, the web interface doesn't start by itself, and you have to manually restart it.  This has been difficult to debug as it's an intermittent problem, and also because it needed a sim restart to trigger it.  But I believe I have the problem fixed now, and will be releasing an update to the Hubs as soon as testing is complete.  I will likely take this opportunity to change the Hubs from being Transfer/No-Copy to Copy/No-Transfer.  Copiable objects are much safer in that if SL eats a copiable object you can just rez another one, and they're also much simpler for me - I can just ship out updates and allow self-service re-deliveries without worrying about where they're going to end up.  And in the case of the Communications Hub, you might actually want to run multiple Hubs.  This would allow you to separate your user community into disjoint subsets, which can be useful if you want to partition your Mesmerizer chat, for example.  With The Enforcer, you can always bridge multiple Hubs when you want them to act as a single community, and then remove the bridge to make them disjoint again.

I would really like to make the Mesmerizer Copy/No-Transfer too, but that's a much harder problem, as I want to retain the ability for a dominant to configure the Mesmerizer before giving it to their sub.  I have some ideas on how to support that with a copiable Mesmerizer, but it will be a little while before I can translate those ideas into product.

 

The Enforcer

I delayed the original release of The Enforcer because of a late-breaking out-of-memory problem.  While I significantly increased the available memory headroom before the release, it's still a concern.

I've been working on two different short-term approaches to improving the situation, and have a longer-term strategy for eliminating the problem.  I expect to ship an update to The Enforcer that includes the two short-term fixes soon, probably around the same time as the Communications Hub update.

 

The Mesmerizer

While my focus so far this year has been on the supporting products, the Mesmerizer itself is also due for a minor update to address a small bug and a couple of minor annoyances.  Unless any major issues surface, I will likely wait until after the Hub and The Enforcer updates are out before updating the Mesmerizer.

Final Word

I've also updated this blog so that the tables should be more readable in Chrome.  If anything looks strange regardless of browser, please send me (Nue Broome) an IM in-world letting me know.

Hypnosis in Second Life, part 2

This is a follow on from an earlier post about hypnosis in SL. While the earlier post talked about the differences between live and recorded trances, this one will focus on live trancing, specifically some of the risks and dangers that are associated with it.

Trance and Waking

Given that the viewer, SL itself, and the typical home internet connection can all be somewhat unstable, people new to trancing are often concerned about the possibility of losing their connection in the middle of a trance.  Luckily, you can't get "stuck" in trance.  If your connection (or your hypnotist's connection) goes away, then once you get bored with staring at a screen with nothing happening, you'll either wake up, or the trance will convert to normal sleep.

Similarly, if something should happen in RL that demands your attention, you'll find you can break out of trance.  This is actually a familiar experience to many people.  If you've ever been driving on a highway and have let your mind start to wander, and a few minutes later suddenly realized that you don't remember passing the last few exits, then you've experienced a natural trance, and a very common one.  If something unexpected were to happen while you were daydreaming - another driver suddenly pulls out in front of you, for example - you would likely find yourself suddenly back at the wheel and having to deal with the situation.  This is exactly the same as abruptly waking yourself up from hypnosis, except that as a hypnotic trance is likely considerably deeper than a natural "highway trance", suddenly waking up from it can be even more disorienting.  Fortunately, you're unlikely to find yourself suddenly having to perform an evasive driving maneuver upon waking from hypnosis.  But if the phone rings, or an alarm goes off, you'll likely find that you're jerked abruptly out of trance, and it may take a moment or two before you regain your bearings.

Those are probably two of the three most frequently-voiced concerns of a novice trancer.  The third is around what the hypnotist might get you to do.  And that's very much up to you.

Suggestions

You don't "lose control" in trance.  You retain the ability to refuse to do what your hypnotist is asking.  And if something is suggested in trance that upsets you, it may well cause you to wake up from the trance.  However, in trance you are much more suggestible than usual (which, after all, is one of the main reasons that trance is interesting) and that does leave you more open to being tricked into doing something you might not be comfortable with.  And this is one reason that it's important to establish some level of trust in your hypnotist before letting them trance you.

Trust and Infatuation

Trust is deeply entwined with what I consider to be the biggest risk associated with hypnosis, and especially with erotic hypnosis, which covers the overwhelming majority of hypnosis in SL.  You need to have some level of trust in your hypnotist in order to let the hypnosis work at all, and as I said above, it's a very good idea to make sure that they deserve that trust before you sit down with them, because the very act of being hypnotized by someone will likely serve to increase your trust in them, regardless of whether that trust is actually deserved.  This increase in trust happens whenever you share positive experiences with someone - it's how normal relationships are built.  The sort of sharing that happens via hypnosis, particularly erotic hypnosis, can be very intense and very intimate, and it's very easy for this shared intimacy and quickly growing trust to develop into an infatuation.  While I think it's far more common for someone to become infatuated with their hypnotist than the other way around (if for no other reason than because typically a hypnotist will have multiple "hypno-partners", whereas many subjects will limit themselves to a single hypnotist) it can happen in either direction.

 Addiction

The possibility of infatuation discussed above is probably an unavoidable danger of erotic hypnosis, especially when you perform multiple trances with the same partner.  However, the likelihood is significantly increased with the practice by some hypnotists of deliberately adding "addiction" themes and suggestions to their trances.  These suggestions can be aimed at creating an addiction to trance itself, but are more usually intended to generate an addiction for the individual hypnotist.  Because this serves to amplify the infatuation effect that's fairly strong to start with, these suggestions can be very powerful.  I consider this a highly unethical practice, particularly when used with novice trancers, and one that can have serious first-life repercussions. 

Protecting yourself

The only sure way to avoid these various dangers is by not exposing yourself to them - in other words, to avoid trancing at all.  If you have an addictive personality or suffer from depression it probably would be advisable to avoid recreational trancing.  If you don't fall into one of those groups and want to experience trance, the most important thing is to make sure that your potential hypnotist is worthy of your trust.  There's no infallible way to do that, but at a minimum you should get to know them before you let them trance you, and ideally you should discuss the issues raised in this article with them.  For example, assume that you talk with a potential hypnotist about "addiction" suggestions before trance, and they promise not to use them.  If, during trance, they do attempt to insert that sort of suggestion, then their clear breach of promise is likely to be enough to both wake you from trance, and legitimately destroy any trust that you might have had in them.

Of course, the idea of addiction can be very seductive in itself.  However, consider that if a hypnotist uses this sort of suggestion with you, they likely use it with many others too.  Behind every SL avatar is a real person, who has only a limited amount of time they can spend in SL each day.  The act of trancing someone can involve a lot of mental energy so a hypnotist is unlikely to want to spend all their time in SL performing trances.  Allowing yourself to become addicted to someone who has to share their limited time with many other addicts is a recipe for unhappiness.  If the idea of being enthralled to someone in SL is that appealing, it's far better to find someone who you want to be with anyway, and have them learn some basic hypnosis techniques.  Hypnosis is not hard to do, and there are plenty of resources on the net to help learn how to do it.  Learning to trance as your dom/domme learns to hypnotize is a great way to strengthen the relationship.

A word about privacy and SL ToS

There appear to be some misconceptions about what is possible for scripts to do regarding monitoring of messages between avatars, and what they are allowed to do under the SL Terms of Service (ToS).  To start with, there is no capability in LSL to allow a script to receive IMs.  Scripts can send IMs under their own names (which can be changed to spoof an avatar name) but unlike regular IMs, IMs from objects will always be displayed in "nearby chat" rather than their own tabs or windows.  Clicking on the "sender name" of such an IM will show where the object is, and who its owner is.  Scripts cannot monitor IMs sent to another user either.

There are products available that claim to monitor IMs.  What these product actually do is use RLV to prevent the exchange of "normal" IMs, and then provide an alternative messaging method that they can monitor.  It isn't possible to covertly monitor regular IMs¹.

Scripts can hear local chat, as well as messages on private chat channels (these are not IMs, but things like the Mesmerizer's channel 99 command channel).  The SL Community Standards document (which is incorporated into the SL ToS) says: "Remotely monitoring conversations in Second Life, posting conversation logs, or sharing conversation logs without the participants' consent are all prohibited".  This clearly prohibits monitoring someone's chat without their consent unless you are physically within earshot.

As with similar products, and in accordance with the ToS, the CSD NCH will only relay chat spoken by the wearer - it will not relay nearby chat spoken by others.  The assumption is that if you wear the device, you have implicitly given consent for it to monitor your chat, but you can't give consent on behalf of anyone else.


1 - While LSL scripts cannot monitor IMs, a hacked viewer could potentially do this, as well as many far more unpleasant things.  Make sure that you obtain your viewer from a genuine download location.