Idioms: Notification of incoming messages

If you use Mesmerizer chat, incoming messages will appear in the same place as local chat.   Unlike IMs, they won't cause a persistent flag to appear, so they can be easy to miss.   One way to make them more noticeable is to have a notification sound play when one arrives.   This is simple to do, using a trigger-rule fired by the on-commlink-message event, like this:

   on-commlink-message = internal play "Pling"

"Pling" is an included sound;  if you prefer to use a different sound, you can use the sounds command to list the built-in sounds, or you can use a key of any full-perm sound (for example, one in your inventory).

Idioms: freeze-play

Freeze-play - where a trigger causes the subject to suddenly become unable to move - is commonly used in genuine erotic hypnosis, often as a convincer, and also as a "stage", allowing you to build other effects on top of a frozen subject.  The Mesmerizer's freeze command is probably poorly named, as it doesn't actually stop the sub's avatar from moving, but merely disables the movement controls.   So while they won't be able to go anywhere, their AO will still continue to animate them in-place.

If you're using the Mesmerizer for RP, a suddenly motionless avatar is a lot more visually effective than one that continues to move, but just isn't covering any horizontal distance.  And if you're using the Mesmerizer as an adjunct to genuine hypnosis, having the subject see their avatar frozen in response to your freeze trigger can be a powerful reinforcement of their own trigger.

So rather than use the freeze command, it's better to have your freeze trigger fire a static animation with the play command.   Since play already disconnects the subject's movement controls, there's no need for an additional freeze.  I like to use the built-in "Attention" animation for this, so a typical freeze trigger would be:

   freeze $rpname = play "Attention"

You may want to define a second trigger that fires the stop command to release them from a frozen state.

Idioms: Triggering multiple subs

If you have multiple subs, it's a good idea to have a standard set of triggers that they all share.  The trigger-rules can still be individually tailored, but having a common set of trigger phrases minimizes confusion.  If you do this, it's usually a good idea to include the sub's name in the trigger phrase, so you can direct a trigger to a specific sub if more than one are present.  For example, consider a trigger that will cause the sub to kneel.  A good trigger rule might be:

   kneel $rpname = play "kneel"

Note the use of $rpname as a template for any of the sub's role-play names (names defined individually for each sub via addname or setname).  This lets the same trigger work for three subs with role-play names of Anna, Beth and Cindy:  for example, "Kneel, Beth" will fire only Beth's instance of the trigger-rule.

It's useful to give each sub an additional "collective name", for example "girls", so that the roleplay names of, for instance, Anna would be "anna" and "girls".  This allows you to trigger her either individually:  "Kneel, Anna", or collectively with Beth and Cindy, if they are present:  "Kneel, Girls".

Idioms: Wearing #RLV items by name

I mentioned this in the post on the 0.98l update, but it's worth calling out again. 

Access to the #RLV folder was one of the areas where I was concerned that a command interface would be harder to use than a typical menu-based UI.  However, in practice I find it much quicker to use the commands, in part because they allow much faster navigation between different folders that a menu-driven system, especially if the folders contain more subfolders than would fit in a single menu.

One situation where the Mesmerizer's approach shines is when you you know the sub has a particular item, but you don't know where it is in her #RLV subtree.  For example, assume I know that she owns a set of RR Vixen Leather Cuffs, but I can't remember where she keeps them.  The following sequence would usually let me put them on her:

/99 find vixen
/99 wearoverall "$rlvpath"

This works because the find command (as of 0.98l) sets the variable rlvpath with the results of its search.

Idioms: force-sitting

This is hopefully the first of a series of short posts that will cover some Mesmerizer idioms that might be useful.  I'll use the tag "idioms", both as a label and in the post title to identify such posts.


To get the ball rolling, let's assume that you have a sub who has a particular cage or display case that you want to put them into regularly.  Also, assume that it's the type of case that they would get inside by "sitting on" it.  The conventional way to make the sub get into the case would be to force-sit them, and a Mesmerizer trigger that would do that looks like this:

into your case=sit <key> where <key> is the key of the case.

However, it is much more effective to have them walk over to the case before getting inside it:

into your case=moveto <key> sit <key>

Binds and Modes

This post is about bound poses, or Binds, how the Mesmerizer implements them, and how to add your own.

A Bind is the term the Mesmerizer uses for a combination of a pose and some sort of chaining.  The 0.98l version of the Mesmerizer ships with a single Bind;  as mentioned in a previous post, I intend to add more in the final release.  But you can easily add your own, and this post will describe how to do that.

Binds are an extension of Modes - the Mesmerizer's term for its mini-AO that will over-ride the sub's own AO while the mode is active.  Modes are intended for things like doll play, where you may have created a trigger that puts the sub into "doll mode" for a period, and want their movements to reflect that.   The Mesmerizer ships with two Modes - "doll" and "ballet".  Use the setmode command to activate a Mode, for example setmode doll.  You can cancel a Mode and revert to the sub's AO by using setmode with a mode-name of "-":  setmode -.  On canceling a Mode, the sub may have to make a small movement in order for their AO to notice that it has control again.  A Bind is simply a Mode plus a list of the LockGuard points that should be linked together to make it look as if the chains or ropes are holding the sub in the pose.

At first glance, it might seem that Binds should be more like semi-static poses - in other words animations as run by the play command - than Modes, which generally allow the sub to move around.   In fact, most real tie ups wouldn't prevent the sub from moving (unless they were tied to something fixed), although movement would be hindered.   For example, even if hogtied, the sub would likely still be able to move, albeit slowly, by squirming and wriggling.  This is why the Mesmerizer chooses to build Binds on top of Modes, rather than on top of static poses.

The 0.98l release introduces Binds, but there is more functionality that needs to be added before they're complete.  This post will describe the current state of Binds, and I'll update it as more functionality is added.

Modes and Binds are both defined in the Modes notecard in the Mesmerizer's inventory.  Here is the shipping contents of that notecard as of 0.98l:

Mode=Doll
Stands=DollStand1,DollStand2
Walks=~DollWalk3
Mode=Ballet
Stands=Ballerina1
Walks=~BallerinaWalk1
Bind=Hogtied
Desc=Hogtie, knees apart
Stands=Hogtie
Unlink=*
Link=lwrist rankle, rwrist lankle

It consists of a number of sections, each introduced by either a "Mode=" or "Bind=" line.  The default file therefore defines two modes (doll and ballet) and a single bind (hogtied).  Note that mode names are not case-sensitive, but the case used in this notecard will be what's used in Mesmerizer messages, and an initial capital works best with those messages.

We'll look at the mode definitions first, "Doll" in particular.  A mode specifies the animations used for various activities.   Doll-mode only defines animations for standing and walking, although the Mesmerizer also supports the following activities or animation states: stands, walks, runs, turning left, turning right.  I may support more states in the future.  All of these allow the specification of multiple animations, with the expectation that one will be chosen at random, although in 0.98l, only the first in each list is used.

Note that the name of the animation used for the Doll-mode walks, ~DollWalk3, begins with a tilde character.   If you were to play a walk, the sub would walk in place which would look strange;  the leading tilde in the animation name "hides" the animation from the anims command, which is used to see what animations are available to be played.

Doll and Ballet Modes are followed by the definition of the "Hogtied" Bind.  Like Modes, Binds can specify animations for the various animation states.  Unlike Doll and Ballet modes, Hogtied only specifies a stand - there is no walk animation.  Binds (and Modes) that omit a walk are considered "in-place" binds or modes, and no movement is permitted.


The "desc=" line is intended for a brief description of the Bind or Mode, to be shown in an extended version of the listbinds or listmodes commands.  Currently it's not used.

The "Unlink=" and "Link=" lines define the LockGuard chaining to be used, and apply only to Binds, not Modes.  Unlink gives a comma-separated list of LockGuard points that should be unlinked prior to drawing new ones; "Unlink=*" means unlink all points.  Link gives a comma-separated list of pairs of LockGuard points, and will cause a chain or rope to be drawn from the first member of each pair to the second.  Choice of chain or rope is made by a preceding lgropes or lgchains command; chains are used by default.

So when activating the Hogtied bind, with the bind hogtied command, first, any existing chains or ropes will be removed, and then new ones will be drawn from the sub's left wrist cuff to their right ankle cuff, and from their right wrist cuff to their left ankle cuff.  You can edit this notecard to draw other bonds if you prefer to tie a hogtie differently.


As I said earlier, Binds are a work in progress.  In particular, walking (or squirming) in a Bind is still under active development.  I expect that the next update will complete this feature.

Adding Custom Animations

It's very easy to add a custom animation to the Mesmerizer - simply dragging it into the Mesmerizer's inventory will make it available to the play and anims commands.  There are a few constraints on the types of animations that are suitable though.

Animations should be looped - that is, they should not stop by themselves.  This is always true of static poses (which in SL are simply looped single-frame animations), but some non-static animations may stop by themselves when they've finished.  The play command assumes that it is playing a looped animation, and will restart it if it stops, which will likely look strange with a non-looped animation that has played to completion.  I may add a playonce command that doesn't automatically restart, but as of 0.98l you should only used looped animations.

Secondly, animations whose names start with a tilde ("~") will not be displayed in the list of animations returned by the anims command.  This is to avoid cluttering the list with animations that are intended to be only used with a mode or bind (such as walks).  So the names of animations intended for use with the play command should not begin with a tilde.

Finally, the animation should ideally be full-permission.  The Mesmerizer needs to determine the key of an animation in order to properly manage it, and it currently cannot do this for animations that have restricted permissions.  You may add animations that aren't full-permission, but if you do, you will need to carry out an extra step to tell the Mesmerizer the key of your animation.  This can be determined with a device that's included with the Mesmerizer - the "Animation Tester".  To use this, rez the Animation Tester - it will ask for permission to animate you the first time you use it - and simply drag your animation into its inventory.  It will tell you the key of the animation in local chat.   Once you have the key of the animation, you can drag the animation into the Mesmerizer's inventory and edit the AnimFixup notecard to tell the Mesmerizer the key of the animation.  To supply the key for an animation, add a line of the form animation-name|key, for example:

Jump Up|ea54436b-7625-b93f-05dc-2e0a2ba1aa29

In general, you should try to avoid spaces in animation names, and keep them in lower case.   This will let you avoid having to enclose the name in double-quotes in a play command: play "Jump Up".

The AnimFixup notecard also allows you to specify a height offset to be used with the animation, and an optional delay before applying the offset.   See the notecard for more details.

I expect to build the Animation Tester functionality into the Mesmerizer before the final release, so that installing an animation, regardless of permissions, will be drag and drop.

The Mesmerizer as an outfit manager

It's quite easy to set up the Mesmerizer so that it operates as a simple outfit manager, to let you change your sub's entire outfit with a single command.

For the sake of simplicity, we'll assume that the sub has three outfits, and you want to be able to switch them into any of these outfits at will.   The simplest way to do this is to create an "Outfits" folder in the #RLV folder, and put each of the three outfits into its own folder within "/Outfits".  Recall that the Mesmerizer uses "/" as a separator between folders in a path from the #RLV folder, and that a leading "/" means that the path starts at the #RLV folder itself.  We'll assume that the outfits are imaginatively named "Outfit 1", "Outfit 2" and "Outfit 3", so we'll put them in "/Outfits/Outfit 1", "/Outfits/Outfit 2" and "/Outfits/Outfit 3".  We'll further assume that, at the start, the sub is wearing "Outfit 1".

The goal is to create triggers that will make the sub change into one of the other outfits.  For example, we want to define a trigger "wear outfit 2" that will cause them to do exactly that.  As a first cut at a solution, you might define the trigger action to be something like wearreplaceall "/Outfits/Outfit 2".  We use a replace-style wear so that the new outfit will replace the old one, and an all-style wear so that if there are sub-folders inside the "Outfit 2" folder, then the sub will wear them too.

The problem with this is that wearreplace doesn't replace entire outfits - it replaces individual clothing items.  So if Outfit 1 (the one that the sub is initially wearing) includes something worn on, say the left lower leg attachment point, and so does Outfit 2, then the correct thing will happen - the new left lower leg attachment from Outfit 2 will replace the old one from Outfit 1.  However, if Outfit 2 didn't include anything on the left lower leg, then there would be nothing to "knock off" the attachment from Outfit 1, so the sub would end up with a mixture - all of Outfit 2, plus any bits of Outfit 1 that don't have corresponding items in Outfits 2.

What we really want to do is have the trigger-rule first take off Outfit 1 and then put on Outfit 2 - something like this: detachall "/Outfits/Outfit 1" wearoverall "/Outfits/Outfit 2".  Note the use here of wearoverall (as opposed to wearreplaceall).   This allows Outfit 2 to contain things that might want to be worn at the same point as some object that's really part of the sub's base avatar, rather than a specific outfit.  For example, the sub's hair might not be included in each outfit, but Outfit 2 might include something else worn on the skull - wearoverall allows the new object to be added without knocking the sub's hair off.

This almost works, but what we've actually defined is a trigger that will switch from Outfit 1 to Outfit 2.  It won't work if the sub happened to be wearing Outfit 3.  What we want is to detach anything that's part of any of the outfits before putting on the one we want.  Doing the detachall at the /Outfits level will do that, and the complete trigger definition is:

wear outfit 2 = detachall "/Outfits" wearoverall "/Outfits/Outfit 2" 

Similarly:

wear outfit 1 = detachall "/Outfits" wearoverall "/Outfits/Outfit 1"
wear outfit 3 = detachall "/Outfits" wearoverall "/Outfits/Outfit 3"

In a future version of the Mesmerizer, I may support parameterized triggers that would allow these three triggers to be specified as a single rule, but I think this is the best you can do today.

Chaining with the Mesmerizer

The latest 0.98l Mesmerizer release introduced the ability to control LockGuard chaining points worn by the sub, and this post describes that ability and some of the things it can be used for.

The main reason for wanting to support chaining was to enable bound poses, or "Binds", within the Mesmerizer.   These are poses that involve the sub being tied up in some way.  Previously, while the Mesmerizer might have been able to move the sub's body into, say, a hogtie position, it would have looked rather strange without any ropes to keep them that way.  As of 0.98l, the Mesmerizer can cause ropes or chains to be drawn as part of a Bind.

I will cover Binds in detail in a future post; this post is specifically about chaining.  While Binds certainly use chaining, the Mesmerizer also makes the chaining features directly available, which allows for some creative "custom rigging" when securing a sub.  Here's an example:

Perhaps I was a little over-zealous with those chains, and if I were doing it again, I think I'd use ropes rather than chains, but I don't think she'll be going anywhere for a while.

The restraints she's wearing are Marine Kelley's new Deluxe Straps, which have a number of LockGuard points available, and are therefore ideal for this kind of over-the-top custom rigging.  I suppose I should take a step back and explain how LockGuard works.

LockGuard is the name of a protocol supported by many restraints that lets you tell them to draw a particle chain or rope from a prim on the restraint to some other prim.  In addition, it provides a way for the prims that can emit chains to identify themselves by a label.  For example, the loop on a collar where you would attach a leash would by convention be labeled "collarfrontloop".  So if I had a wall-mounted ring (or a table-mounted ring as in the picture) and I wanted to cause a leash to be drawn from the sub's collar to that ring, I'd send a LockGuard command to "collarfrontloop" telling it to draw a chain to the ring, and I'd identify the ring by its key.   Each prim in second life has a unique "key" which you can find by a somewhat convoluted process I'll describe in detail later in this post.

So the Mesmerizer doesn't really have to do very much to support chaining - it just has to be able to find the LockGuard-enabled prims that the sub is wearing, and then be able to tell them to draw chains to other prims.  The following low-level LockGuard commands support that:

Command	Params	Description
lglist	0	List all the LockGuard points that the sub is currently wearing. This command takes a few seconds to complete to give all points time to respond, even in a laggy sim.
lgchains	0	Use chains for subsequent LockGuard bindings
lgropes	0	Use ropes for subsequent LockGuard bindings
lgsize	1	Specify a size for subsequent LockGuard bindings.  <p1> is a floating-point value; the default is 0.04
lggrav	1	Specify how much subsequent LockGuard bindings should sag under gravity. <p1> is a floating-point value; the default is 0, or no sag. Negative values will make the chains or ropes lift in the middle
lglink	2	Draw a chain or rope from <p1> to <p2>.  <p1> is the name of the initiating LockGuard point; <p2> is either the name of a second LockGuard point, or the key of the target prim
lgunlink	1	Remove the chain/rope drawn from LockGuard point <p1>
lgrestore	0	Restore the links that were previously drawn

lgrestore needs a little more explanation.   It is intended to be used in an on-init or on-rlv-enabled event handler, and will restore the chains that were being drawn when the sub previously logged off.  Used outside that context, its behavior may be unpredictable.

These commands are what I used to draw all of the chains in the picture above, except for the one from her collar to the front left tie-point, which is a regular collar-drawn leash.

The low-level LockGuard commands only create particle chain or rope effects - they don't restrict the sub's movement in any way.  In order to create chains that do restrict movement, use the leash family of commands:

Command	Params	Description
leash	0	Draw a leash from the sub's collarfrontloop point to the command issuer. If the command issuer is wearing a compatible leash-holder, the leash will be drawn to that; if not, then it will be drawn to the center of their body
leashto	1	Draw a leash from the sub's collarfrontloop point to the prim whose key is <p1>
unleash	0	Remove the leash
leashlen	1	Set the length of the leash. <p1> is a floating point number giving the desired length in meters.

I may add to the leash family of commands to permit leashing from other points, if I can figure out what to do if the avatar is leashed to two different points that are further apart than the sum of the lengths of the leashes.

I did discover one small annoyance when implementing LockGuard.  While the LockGuard specification defines a set of standard names for various LockGuard points, not all restraints strictly follow the standard.   The most common cuff attachment points should be named leftwrist, rightwrist, leftankle and rightankle according to the standard.   However, several popular brands of cuffs instead use lwrist, rwrist, lankle and rankle instead.  For the most part, the Mesmerizer treats these as synonyms for the standard names.


Finally, as promised, here's the process to find the key of an individual prim, in order to chain or leash to it.  The process puts the key into your paste buffer, so you can then paste it into a command.  The instructions are written for Firestorm, but most viewers should behave similarly.

• Right-click the object containing the prim and choose "Edit"
• Make sure the "General" tab is showing in the edit window
• If your object has just a single prim, press the "Copy Keys" button and you're done
• Otherwise, check the "Edit Linked" checkbox near the top left of the edit window.
• Use the left/right arrow buttons below the "Edit linked" checkbox to move through the individual prims of the object until the one you want is highlighted.   Then press "Copy Keys" and you're done.

Upgrading a Mesmerizer

Now that the Mesmerizer update is out, and I'm about to start sending it to current owners, I thought I should make a post about how to upgrade from an existing Mesmerizer.

A Mesmerizer's persistent state consists of triggers, role-play names, teleport permissions, access-lists, commlink state, variables, scheduled events, things you've added to the inventory, and a couple of internal state items like chastity and lockguard chains.  Of these, triggers, the access-lists, the comm-state and inventory additions are the most important to preserve.  The backup command is useful for much of this.

Before using the backup command, though, you should set the access control in the new Mesmerizer.  The first time you rez or wear a new Mesmerizer, it will go through a fairly lengthy initialization process.   Let it finish this before you try to do anything else with it (including taking it back into inventory or detaching it).  If you do interrupt the initialization, you may get an initialization error the next time you wear the Mesmerizer, and doing a /99help may only show a handful of commands.  In either case, you should issue a /99rebuild command to restart the initialization from the beginning, and this time wait until it completes.

Once the new Mesmerizer has initialized, edit its Access notecard to match the entries in the old Mesmerizer's Access notecard.  Usually, you can just replace the shipped Access notecard in the new Mesmerizer with the one from your old Mesmerizer, but it is possible that the format might change (especially during the beta period), so at least look at the new notecard and make sure it uses the same format as your original one (the 0.98l update doesn't change the Access notecard format).

Once the new Mesmerizer's owner(s) are correctly set, you (or your owners) can use backup to transfer the bulk of the persistent state.  Issuing a /99backup command will result in an output like this:

/99Nue Broome:
#1 robot-off = internal play "Attention"
#2 normal = internal stop
#3 on-pan = internal executeif "'$pancmd' off streq" robot-off
#4 on-pan = internal executeif "'$pancmd' on streq" normal
#5 good night = me hypnotize
#6 on-rlv-enabled = internal text "RLV on!"
#7 tphome = internal tpto "ThroneRoom"
#8 on-chat = internal say "$message"
#9 on-emote = internal emote "$message"
#10 doll time $rpname = me env "pinktint"
setname "fred"
setcommaddr "1234d2cb-124f-2345-05fd-abc1540ab8cc@lsl.secondlife.com" 12345678-abcd-1234-5678-9abcdef12345

Ignoring the actual content of the triggers (which are mostly for my own testing), the output is a channel-99 command that will restore the triggers, role-play names, teleport permissions, chastity and commlink state.  If it's too long to fit in a single message, multiple messages will be used, and each will be a complete channel-99 command.   So to transfer all these things from one Mesmerizer to another, you wear your old Mesmerizer, issue a /99backup command, and wait until it's finished.  The last thing it outputs will always be the setname and (if your mesmerizer is networked) the setcommaddr commands.   Then detach your old Mesmerizer, wear the new one (and if this is the first time you've worn the new one, wait until it's finished initializing), and then and cut and paste each message from local into the chat bar.  If there are multiple messages, the order in which you repeat them doesn't matter, although  it will change the numbering of the triggers.  Make sure to paste the entire message in one go, and not individual lines from it.  And only paste each message once, or you'll end up with duplicate triggers.

backup is also useful if you want to simply see all your sub's triggers, or delete some of them.   The number at the start of each trigger line can be used with the delete command to remove the specified trigger.  So, with the above triggers, if I did a /99delete 1, the "robot-off" trigger would be removed (and the rest of the triggers renumbered).

After transferring triggers, the final things to move over should be any sounds, images, animations or landmarks that you've added to the inventory of your old Mesmerizer.  If you had to edit the AnimFixup notecard to accommodate custom animations that aren't full-permission, you will have to transfer the key values from your old AnimFixup notecard to the new one.  The format of this notecard has changed, as it now does double duty - to declare  keys for non-full-perm animations, and to specify height offsets.  The new format is described in the 0.98l Mesmerizer's AnimFixup notecard.

There is currently no simple way to transfer the state of variables or scheduled events forward, so you will have to manually re-schedule any events and re-define any variables you want to preserve.

Communications Hub 0.656

The new Hubs, version 0.656, are up on marketplace and in the Vendors as well.  The update comes in both styles of Hub - the pseudo-Cray standard version and the low-prim version.  I have taken the opportunity to adjust the size of the standard version, so most avatars should now reasonably be able to sit on the circular bench, without partially disappearing inside the Hub.

As mentioned in previous posts, the key new feature of this update is Web Access.  If you choose to enable Web Access, then you can allow any of the registered users to connect to the Hub from a web browser, and take part in Mesmerizer Chat from the web.  You can also grant individual users the ability to issue Mesmerizer commands from the web.  These commands will be subject to normal access control at the receiving Mesmerizer - in other words, only someone listed as an Owner in the Mesmerizer's Access notecard can use channel 99 commands, whether locally or through a Hub, regardless of whether the command was issued from a Communicator or from the web.

Note that some Mesmerizer commands return information to the command issuer.  If the command issuer is not in the same sim as the target, the Mesmerizer will use IM to send its response.   So if you expect to make use of the Web Access feature to issue Mesmerizer commands, you should set your SL account to forward IMs to email, so that you will be able to receive these responses when not logged in. 

Setting up Web Access first requires that you enable it for the Hub as a whole.   This is done in the Hub's "Web" menu page.  When you enable Web Access, you will see the Hub's hovertext expand to include an extra address line, showing its web URL.

Once Web Access is turned on for the Hub, individual user accounts can be flagged as web enabled for chat only, or for both chat and commands.  Do this in the "User DB" menu page - choose "Mod User", pick the user record you want to modify, and Choose "+ Web-Access" or "+ Web-Comm" to grant chat or chat/command rights, or "- Web-Access" or "- Web-Comm" to remove rights from the account.

Once a user account has Web Access enabled, the user can touch the hub and choose "Get Web Key".  This will give them both the current URL of the Hub, and a "Web Authentication Key", which is specific to their account on that Hub, and is akin to a password.

Once they connect to the URL from a browser, they will be prompted to enter their authentication key, and once entered, they should see a page where they can take part in Mesmerizer chat.  New chat can be entered in the text bar at the bottom of the page.

If the user account was enabled for command access, the web-page will contain a list-box allowing it to be switched between "chat" and "command" modes.  In command mode, the text bar at the bottom is used to enter a Mesmerizer command line.   After the command line is transmitted, the page will revert to chat mode.


The other visible feature of this update is that the user database can now be loaded from a notecard, making the system somewhat more robust.  The running Hub still uses an in-memory copy of the database, but there is a menu choice on the "User DB" page to "Reload" the database from the notecard.  If the in-memory database has been changed, you will be warned and given the opportunity to save the current DB.  This can also be done manually, via the "Backup" menu choice.  This works by writing the current DB to local chat in the same format as is used in the Users notecard, so you can cut it from chat and paste it directly into the notecard.


The other significant new feature is latent support for the upcoming Enforcer product, about which I will post more soon.

Mesmerizer 0.98l

The new version is in the vendors and up on Marketplace.  It's taken a long while to get this far, but I think 0.98l is close to the final release version.  I don't know of any major functionality still to be implemented.  There are some enhancements still to do, but those are along the lines of "more of the same" rather than brand new features.  For example, 0.98l includes the "binds" that I've mentioned in previous posts, but it actually ships with just a single Hogtie bound pose.  Before I declare Version 1.0 I want to make a few more of those.

So here is a list of the features that are new in 0.98l:

• The SD Entrancer plugin.   This ships installed, but can be uninstalled if you don't need it and want to reduce your script count by 1.
• Stored scripts (both static and dynamic) to allow trances and command sequences to be replayed from the Mesmerizer's inventory or memory.  This is like having a MesmerX built in to the Mesmerizer.
• Chaining.  If you wear attachments (for example a collar or cuffs) that support the LockGuard chaining protocol, the Mesmerizer can now draw chains or ropes from them.  Chains can be drawn between LockGuard attachments (to chain two cuffs together, for instance), from a LockGuard attachment to another object, or, in the form of a leash, from a LockGuard collar to a leash-holder or in-world object.
• Binds.   These are rather like a combination of Modes with Chaining.   They let the Mesmerizer tie the sub up using LockGuard chaining.   As mentioned above, 0.98l ships with just a single bound pose - a hogtie - but I intend to add more before the final release.
• Rezzable objects.  You can now put objects into the Mesmerizer's inventory, and have it rez them on demand. This is intended for things like cages, but the possibilities are pretty wide-open.  There is a simple protocol between the Mesmerizer and the object that tells the object who caused it to be rezzed, and is extensible so that other commands could be send to the new object through the Mesmerizer.  0.98l ships with a single demonstration rezzable object, cleverly disguised as a plywood cube, which lets you see how to interpret the protocol;  I intend to include at least one "useful" rezzable object in the final release version.
• The find command that searches #RLV for a folder whose name contains a sub-string now sets a variable called rlvpath with the result of the search.  I got fed up with doing a find cuffs, and then having to copy and paste the returned folder-path into the follow-on wearoverall command.   Now you can simply do:

        find cuffs
        wearoverall "$rlvpath"

• on-emote and on-chat events to allow the sub's speech and emotes to be grabbed.  To avoid firing events unnecessarily, you have to turn on these events with hookchat yes or hookemotes yes (and with a parameter of no to turn them back off again).  Both events are passed the text the sub said or emoted in the message variable.
• lmlist command to list the landmarks stored in the Mesmerizer's inventory.
• xcheck command to force a rescan for Xcite! genitals.  If the sub adds their genitals at some time after wearing the Mesmerizer, it may take a few minutes for the Mesmerizer to notice by itself;  this command nudges the Mesmerizer into checking right away.
• tptype command, which indicates whether the sub has granted TP permissions to the Mesmerizer, or is relying on the RLV teleport capability.
• textcolor command to set the color that subsequent text commands will use.  It takes a single parameter which is either an SL color vector (e.g. "<1.0, 0.0, 0.0>" is a pure red color), or a named HTML 4.01 "web color", one of the following:  white, silver, gray, black, red, maroon, yellow, olive, lime, green, aqua, teal, blue, navy, fuchsia, purple.  Because I can never remember how to spell it, "fuschia" is accepted as a synonym for "fuchsia".
• A number of miscellaneous bugfixes

I will be writing follow-on posts with proper documentation for the new features and their associated commands.  The help command describes them all now, but it is fairly terse, and intended more to remind you of what the command name is than to let you browse through all the commands.

I will be reaching out to existing purchasers to notify them of the new version, but if you want to get an update early, just send me (Nue Broome) an IM requesting one.  If your Mesmerizer was bought for you as a gift, please include the name of the actual purchaser in your IM.


Now that the Mesmerizer update is out, I'll be hard at work to get the new Hubs out too.  In many ways the new Hub functionality is the most exciting thing in this round of updates, as it enables Web Access, and also puts in place the groundwork for the Enforcer.