Mesmerizer 1.2 preview

The next Mesmerizer update will bring some performance improvements, a reworking of initialization, some improvements to the "follow" behavior especially for leashing, an enhancement to Mesmerizer chat, an RLV relay plugin, and a couple of free attachments.

RLV Relay Plugin

The relay plugin is included mostly because I've been working on a collar that will play well with the Mesmerizer as part of the CHAOS range, and many people use the relay built into an existing collar, so if you wanted to use the CHAOS collar instead, you'd need a separate relay.  There are existing RLV relay HUDs, but there are a number of advantages to having one built in to the Mesmerizer, most importantly that it understands the Mesmerizer's concept of owner(s).

People listed as owners will be permitted to use the relay in all modes except "Off".  So even if the relay is set to "Ask" mode, your owner(s) and objects belonging to them will still be able to use the relay without generating a permission prompt.

The relay plugin has all the typical modes: Off (where the relay won't accept new commands), Trusted (where only people and objects that have been previously designated as trusted will be permitted to control your viewer), Ask (where the wearer is asked whether to permit access by an untrusted object or person), and Auto (where anything not explicitly banned may use the relay).  In addition, the Mesmerizer supports an Owner Ask mode, which is very similar to Ask mode, except that if an owner is in the same sim, then the owner is asked for permission, rather than the Mesmerizer wearer.  This is not a new idea - I believe that Dahlia's OC plugin for her relay supported this, but I don't know of another relay that has adopted it since.  Dahlia's relay is sadly long gone, and in some ways, the Mesmerizer's relay is an homage to it.

Safewording works in a similar fashion.   If your owner is in the sim when you call safeword, then they get to decide if the attempt to safeword should be permitted.  If your owner is not at hand, however, you can call safeword by yourself.  If you safeword, your owner(s) will be notified, and a new on-safeword event will fire, allowing your owner to create a custom response to safewording.  For now, on-safeword is a local event, and not delivered to The Enforcer, although the custom response is free to signal an Enforcer event.

Since the relay is controlled by Mesmerizer commands, your owner(s) can decide which commands you have access to.  If you aren't listed as an owner in your Mesmerizer's Access notecard, then you can't execute Mesmerizer commands directly, but only via triggers, so someone else (usually your owner) will have to create self-triggers for any relay commands they want you to be able to use.  This means that, for example, your owner can give you triggers to switch your relay between Owner Ask and Auto modes, but not give you the ability to switch it off.  Since safewording is also done via a Mesmerizer command, your owner must give you the ability to safeword, with a self-trigger something like the following:

/99 chaosred = subject relay safeword

This defines a self-trigger "chaosred" which the sub can say in local chat or on channel 98 to call safeword.  Since the Mesmerizer will look for triggers within regular speech, it's important to make the safeword something you're unlikely to say in a normal sentence.

Like all Mesmerizer commands, those controlling the relay are available remotely.  So an owner can release you from an RLV trap if they wish without having to come to the sim in which you're trapped.  Equally, they can turn on your relay remotely, without requiring permission from you.

The relay supports multiple simultaneous controllers.  This should be standard in a relay, but surprisingly some widely-used relays only allow one controller at a time.  Support of multiple controllers is necessary in many fairly common situations, for example if you want to use RLV furniture in an area that uses an RLV Zone.

Most relay functions are controlled via the relay command, which takes a single parameter specifying the desired operation:

relay on - turn the relay on (in whatever mode it's currently set to)
relay off - turn the relay off
relay ask - turn the relay on in ask mode
relay ownerask - turn the relay on in ownerask mode
relay auto - turn the relay on in auto mode
relay trusted - turn the relay on in trusted mode
relay status - display a message indicating whether the relay is active and the mode it's in
relay report - list relay status, including the restrictions imposed by each active controller
relay access - lists the trusted and banned users or objects, and allows these lists to be edited.
relay clear - remove all current restrictions
relay safeword - remove all current restrictions, after checking that a safeword is permitted

A few commands need an extra parameter, in addition to the operation.  These commands use the relay2 command:

relay2 trust <user-or-object> - add the specified user or object to the 'trusted' list
relay2 untrust <user-or-object> - remove the specified user or object from the 'trusted' list
relay2 ban <user-or-object> - add the specified user or object to the 'banned' list
relay2 unban <user-or-object> - remove the specified user or object to the 'banned' list
relay2 ownersw on/off - Set whether owner's object can be safeworded.

In the above commands, <user-or-object> is the key of either an avatar or an object.  You can also specify the name of a nearby avatar.

The trusted and banned lists are actually 2 lists each, as users and objects are stored separately.  Each list is kept to at most 20 entries, with least recently-used entries being removed to make room for new entries.

Chat Textbox

A sub of mine recently ran into a situation where she was locked down and her use of channels was blocked by RLV.  This meant that she couldn't communicate with me via Mesmerizer chat, which is normally available, even if IMs are blocked.  She could receive my messages, but she couldn't reply in the normal way, using channel 97, as that channel had been blocked.  To (mostly) avoid this situation, I've added a new command, commdlg, which takes a parameter of on or off.  This command activates (or deactivates) a textbox into which you can type messages to be sent by Mesmerizer chat, instead of speaking them on channel 97.  When commdlg is on, each message sent will cause the text box to be redisplayed.

The intended use of this is that, if the sub is to be able to use this feature, the owner would define a self-trigger for them, such as:

/99 meschat = subject commdlg on

This creates a trigger "meschat" that the subject can use, which will issue the commdlg on command.  So any time that channel 97 access is banned, the sub can simply say "meschat" in local to enable the Mesmerizer chat textbox.

Of course, if channels are banned, there's a good chance that local chat may be restricted too.  In RLVa (which is the version of RLV implemented by Firestorm, among other viewers), chat surrounded by double parentheses "((" and "))" is considered OOC chat, and is never restricted.  So even if local chat is prevented, on a viewer that implements RLVa, saying "(( meschat ))" will cause the above trigger to fire.  Viewers that implement the original RLV spec don't have this option, but I have included a tiny HUD that can be worn by the Mesmerizer wearer to allow self-triggers to be issued even when channels are locked down.  This HUD can be used by RLVa users too, and it is more 'stealthy' than saying a magic word in local, as it can say it on the 'alternate' self-trigger channel 98.  It's completely programmable, so it can be used to issue any self-triggers that may be defined, not just to bring up the comm dialog.  For instance, if the sub is to be permitted to change their RLV relay settings, the self-triggers to do that can be added to this HUD, so that the sub doesn't have to remember them.

Follow and Chaining Enhancements

The Mesmerizer performs all the functions of a typical SL collar (and many additional things), with two exceptions:  the symbolism of a locked collar, and the ability to leash to it.  The Mesmerizer has always has its own leash command, which is basically a combination of enabling following and drawing a leash from the lockguard collar front-loop point to the target avatar (or leash handle, if they're holding one), so if you wear a collar with lockguard support, leashing via the Mesmerizer was already possible.  However, the behavior of follow is rather less assertive than is reasonable for someone being dragged by a leash, and the default lockguard chain and rope textures are pretty awful.  Also, while you can manually add some gravity effects to the particle chain, it doesn't automatically give the appearance of being slack when the leashed avatar is close and taut when they're near the leash length.

Version 1.2 addresses all these defects, in preparation for the forthcoming CHAOS Collar, which provides the symbolism of a physical collar, as well as somewhere to attach a leash to.  It also allows for a number of different collar styles.  Since the Mesmerizer is doing all the heavy lifting, the collar itself is very lightweight in terms of script load.  I'll discuss the CHAOS Collar in another post.

Trance Relay/Titler

The trance relay is an optional device that can be worn by the sub to let people nearby see what text is being displayed on their screens.  This is intended for use in a public, or demonstration trance situation.  The on-screen text is duplicated as hover-text over the sub's head.  This can be enabled or disabled by the publictext and nopublictext commands.  To avoid confusing the sub during trance, they will not be able to see the hovertext, although those around them will.

The trance relay can also be used as a titler.  The two functions (title and trance text) are  visually separated by the title (if any) appearing in white, above the trance text which appears in green.

The Trance Relay/Titler is a PAN device, and is therefore accessed via the pansend and pansendpars commands.  It supports the following commands:

pansend titler lock - Prevents the titler from being detached
pansend titler unlock - Permits the titler to be detached
pansendpars titler text "some text" - displays "some text" in green.  Empty string to clear.
pansendpars titler title "new title" - sets the sub's title to "new title".  Empty string to clear.

The publictext and nopublictext commands make the Mesmerizer repeat (or stop repeating) all received text and text2 commands as PAN text commands to the titler.

AutoInstaller released

As is becoming the norm, the release of the AutoInstaller was delayed a little, but it's up on marketplace and the vendors as of today.   Here's the sales banner:

The AutoInstaller must be owned by a Mesmerizer-wearer, and is intended to be left rezzed in some location they frequently visit, ideally their (or their owner's) home.  Once AutoInstaller access rights have been granted to someone (usually their owner), that person can load custom content into the AutoInstaller, and enable the AutoInstaller for upload, which will then happen automatically when the Mesmerizer-wearer comes within range.

The custom content that can be delivered by the AutoInstaller can be trance scripts, subliminals, windlight environments, animations, images, sounds or even objects.  The major use for it is to upload trance scripts, allowing the owner to repeatedly refine and extend them.

This version of the AutoInstaller is disguised as a tea-light in a cut-glass holder, that is intended to look at-home in a variety of different environments.

The AutoInstaller will only work with Mesmerizer V1.1 or higher, so if you haven't done so already, pick up your free upgrade by visiting one of my vendors and asking for a re-delivery,

Mesmerizer 1.1 released

The V1.1 Mesmerizer is in the vendors now;  I'll be updating the version on MP soon.  If you already own a Mesmerizer, this update is free.  To get your copy, just visit one of my vendors in Pak, Sleepy Hill or Coghaven and request a re-delivery.  You can actually ask for a re-delivery from any CasperVend vendor, but if you use one of my vendors, purchases from my store will be shown at the top, which will save you having to search.

Included in the V1.1 version is the CHAOS Installer, which greatly simplifies the installation of custom content (e.g. trance scripts, subliminals, animations, sounds, images, environments, etc).  You just place the content inside the installer (with notecards named according to the convention discussed in the previous post), and touch the installer to have the content automatically uploaded into your Mesmerizer (V1.1 or higher).  The installer is transferable, so your Dom(me)/hypnotist can fill it up with content and then transfer it to you for easy installation. 

Another use for the CHAOS Installer is to use it as a backup of any custom content you wish to load into your Mesmerizer.  If you load all your custom content into a "backup" Installer, then updating to a new Mesmerizer release is much easier:

1. while wearing your old Mesmerizer, issue a /99 backup command (or have your owner do that if you don't have command access) to save your triggers and settings to local as one or more /99 messages.
2. Take a copy of the Access notecard from your old Mesmerizer's contents by dragging it into your inventory.
3. Switch to the new Mesmerizer and let it initialize, then drag the Access notecard you saved in step 2 into the new Mesmerizer's contents.
4. Touch the "backup" installer to upload your custom content into the new Mesmerizer.
5. Replay the /99 messages that were emitted in step 1 (or have your owner do that if you don't have command access) to restore all your triggers and settings.

Without a "backup" installer, step 4 above would involved dragging lots of notecards and other assets into various prims within your Mesmerizer.  Having all your content sitting in an Installer makes this step trivial.

I may enhance the Installer in a future release to be able to "snapshot" a Mesmerizer, thereby automatically creating a backup.

As mentioned in the previous post, I'm also working on a new AutoInstaller product, which you can set up to act as a channel from your Dom(me)/Hypnotist to your Mesmerizer, so that they can add and delete custom content without requiring you to be actively involved (once you've given them permission to use the AutoInstaller).  The CHAOS AutoInstaller should be released within a couple of weeks.

Trance Scripts and the AutoInstaller

I had planned for V1.1 of the Mesmerizer to focus on outfits, but instead two other features seem to have taken center stage in the release:  Trance Scripts and Installers.  I realized that I've never documented how to write a Mesmerizer script, other than by including the 'Default' script, so here's a quick overview of how a Mesmerizer script is structured.

Mesmerizer Scripts

Non-dynamic Mesmerizer scripts are contained in notecards, whose name starts with "Script:".  So the "Default" script is stored in a notecard called "Script:Default".  A simple script is just a series of lines of text to be displayed in the center of the sub's screen:

This is the first line
This line will be displayed next
These two lines\nare displayed together
And finally, this.

These will cause a sequence of four messages to be displayed to the sub, with the third message spanning two lines - the "\n" sequence means a line-break.  After each message is displayed, the Mesmerizer will pause to allow the sub to read the message.  The length of the pause is somewhat dependent on the length of the message - the longer the message, the longer the pause will be.

Lines starting with an exclamation point (!) are considered commands.  Commands are either script commands or Mesmerizer commands.  A script command is of the form:

!keyword = value

There are only a few script commands.  Here are examples of each of them:

!pause=60.0 (new in V1.1)
!delay=5.0
!blank=3.0 (new in V1.1)
!call=Sub1 (new in V1.1)
!note=This is a note to the hypnotist (new in V1.1)
!speed=10.0
!picalpha=0.7
!piclength=10 (lines of text per picture)
!bgpics=pic1, pic2  (keys or names of images)
!addbgpics=pic3
!subbgpics=pic1

Anything else on a line beginning with an exclamation point is assumed to be a Mesmerizer command, and will be issued to the Mesmerizer.  Any Mesmerizer command can be executed like this from within a script, so scripts can be very powerful - they can apply RLV restrictions, they can force-sit the sub, and they can even teleport the sub anywhere on the grid.  If you create triggers that perform many actions, you might want to put those actions into a notecard script and reduce the trigger action to something like runscript "myTriggerActions" - that will both free up trigger memory and improve the speed of trigger matching.

Since pause is both a Mesmerizer command and a script command, it will actually work with or without the equals sign, but using the equals sign to make the script engine interpret it directly is much more efficient, and ensures proper synchronization with subsequent script commands.  Pause and delay commands are very similar to one another - they both add the specified number of seconds to the wait period before the next line is executed or displayed.  The difference is in the notification that is sent to the hypnotist.  Delay will just add some extra seconds before executing the next command;  pause will do this too, but in addition it will inform the hypnotist that the script is waiting for his input, as described in the previous post.  Typically, the interval given to a pause command would be much larger than that used as a delay, and should be thought of as a timeout that usually won't be reached, whereas delay is expected to wait for the full interval.

blank is very similar to delay, except that it removes any on-screen text first, leaving the screen free of text for the specified number of seconds.  This is sometimes useful to insert a short break between messages.  A blank text line will do this too, but it will result in the normal delay between messages; blank is needed if you want a shorter break.

The call command invokes a second script, and the first script will wait until the called script has finished.  Dynamic scripts can call notecard scripts (and vice versa, although it's probably not a good idea to do this as dynamic scripts are expected to be fairly short-lived compared to notecard scripts).  One good use for this is to create a number of trance fragment scripts as notecards, and then create one or more higher-level scripts (either dynamic or notecard) to assemble the fragments into more complete trances.  This allows you to use the same fragment in multiple trances.

The note command sends a message to the hypnotist.  This is intended to be used to remind the hypnotist about what the trance script has done.  For example, I use it in scripts that turn on the spiral (induction scripts), to remind myself at the end of the script that the sub's spiral is still running.

speed sets the minimum wait between successive lines.  The default speed has a minimum of ten seconds between messages (more after longer messages).  I would suggest making only minimal use of the speed command though - the ideal pace of a trance is more a function of the particular sub than it is to do with the content of the trance, and there is a new scriptscale Mesmerizer command that will allow trance speed to be tweaked globally.

picalpha, piclength, bgpics, addbgpics and subbgpics allow for the automated display of background pictures during trance, behind the spiral.  picalpha sets the opacity with which pictures will be displayed, while piclength says how many messages a picture will be displayed for before the next picture is used.  bgpics is used to specify a list of pictures, and addbgpics and subbgpics make it easy to add or remove pictures from the list as the trance progresses.

Script-related Mesmerizer Commands

Since the previous posts, I've made a couple of small changes to the script-related commands.  Since I think that most often a hypnotist will want to see the text of scripts they run, I've made that the behavior you get from the playscript command, while the original "silent" behavior has been moved to the (new) runscript command.  So the playscripti command no longer exists.

Also, as mentioned above, I've added a scriptscale command, used to tweak the interval between messages displayed by a script.  The algorithm to decide how long to wait between successive messages is fairly complex, but it seems to give reasonable results.  The script can set a "speed" parameter (which defaults to ten seconds) - this is the default time to wait after displaying a short message - one of less than about 70 characters.  If the message is longer, then the wait is increased somewhat.  But the interval is multiplied by the current scriptscale value (which defaults to 1) before being used.  This lets you use copies of a common script in multiple subs' Mesmerizers, even if their reading and comprehension speeds are very different.

So here is the full set of script-related commands in V1.1:

Command	Parameters	Description
runscript	1	Execute script <p1>
playscript	1	Execute script <p1>, informing the hypnotist as each line is displayed
scriptscale	1	Adjust timing. The pauses between messages will be multiplied by <p1>
stopscript	0	Terminate the currently running script
pause	1	Pause the currently running script for at most <p1> seconds
resume	0	Resume the current script
createscript	1	Create a dynamic script called <p1>
deletescript	1	Delete dynamic script <p1>
addscript	2	Add line(s) <p2> to dynamic script <p1>
listscripts	0	List available dynamic and notecard scripts
dumpscript	1	Display the contents of dynamic script <p1>

CHAOS AutoInstaller

I've mentioned installers in a previous post.  They are devices that will install custom content (e.g. trance scripts, animations, subliminal sets, etc.) into a Mesmerizer.  V1.1 of the Mesmerizer will come with an installer that can be transferred, allowing for an owner to give a bundle of content to their sub in a way that's easy to add to their Mesmerizer.  The sub simply rezzes the installer, and touches it to install the content. An installer provides an easy way to pass custom content between avatars, and avoids the complexity (and danger) of directly editing the Mesmerizer's content.

The AutoInstaller is a new product that builds on this idea.  Unlike a regular installer, which an owner will edit to load up with custom content and then pass to subs (this can also be a way to sell custom content), the AutoInstaller is no-transfer, and belongs to the sub into whose Mesmerizer it will upload custom content.  It is designed to remain rezzed in a place that the sub visits frequently (their home, for example).  The sub can permit specified other people (their owner(s)) to drop content into the AutoInstaller, and it will be automatically uploaded when the sub is nearby.

This allows for an owner to easily make incremental changes to a script, or to add completely new scripts, without having to have the sub get involved with a potentially complex edit.

To capitalize on the Installer and AutoInstaller, I've made some changes to how the Mesmerizer stores some of its configuration data.  Version 1.0 stored all its Windlight environment definitions in a notecard called Env, and stored all its modes and bind definitions in a notecard called Modes.  In V1.0, adding a windlight environment or a mode involved the sub editing these notecards and adding sections for the new definition.  The installers can't do this - they can only add or replace entire notecards.  So, in order to allow an installer to add (for example) a new mode, I've changed this so that now each mode is specified in its own notecard, with a name of "Mode:" followed by  the name of the mode.  So the standard "Doll" mode is now defined in a notecard called "Mode:Doll".

The same goes for binds and Windlight environments - these are now specified in individual notecards with names starting with "Bind:" and "Env:" respectively.  Notecards defining subliminal sets must also now be prefixed with "Subliminal:".  The Installer greatly simplifies the installation of subliminal notecards compared to using the object editor.

This naming convention has the useful side-effect of collecting all definitions of a given "type" together in the Mesmerizer's contents, when viewed via the object editor.

Availability

Mesmerizer V1.1 updates should be available in vendors next week.  I will post a note here and in the CSD group, and also send out a notification via CasperVend to existing purchasers.  The AutoInstaller should be available soon after.  Note that the AutoInstaller and regular Installers will only work with Mesmerizer V1.1 (or higher).

Owner HUD preview released, Trance fragments and Mesmerizer 1.1

The Owner HUD preview should be up in vendors this evening.  It's free (although in order to purchase it, you have to give the vendor L$1 which it will promptly refund), so anyone with "owner"-level access to a Mesmerizer should consider getting it.  I've come to rely on it, especially for live trancing, which is one reason that I'm releasing it as a preview - it's so useful even in its current limited state that I felt I shouldn't keep it to myself.  I'll happily accept suggestions for ways to improve it, as well as comments on some of the non-standard UI design choices I've made. 


Since the previous post, I've been experimenting more with the concept of "trance fragment scripts", and I'm getting to like them more and more.  One significant problem with pre-recorded scripts though, is the lack of interaction with the sub.  As I said in my post on hypnosis in second life, one of the big issues I have with prerecorded trances is the lack of participation by the sub - they are pretty much expected to just sit back and watch.  This perhaps isn't such a big issue with fragment scripts, since they tend to be short sequences of messages that you can use within a longer trance, but it still bothered me, so I've tried to at least begin to address it in V1.1.

The minimum sort of interaction that I think is useful is just asking the sub a simple yes/no question within the trance, ideally one in which the answer is pretty-much a foregone conclusion.  Something like "Are you feeling calm and relaxed?" or "Can you hear me?".  The expected answer to both of these questions would be "yes", or some agreed-upon signal that indicated agreement.  To allow for the sub to respond to this sort of question, I've added pause and resume commands to V1.1.  These operate on the currently-playing script, and pause/resume playback.  The pause command takes a parameter, which is a number of seconds to pause before the script will automatically resume.  Scripts themselves have been augmented with a variant of the pause command so that the script playback mechanism can handle that itself rather than having to issue and re-parse the Mesmerizer command.

The way this is intended to operate is in conjunction with the new playscripti command, which tells the hypnotist each line that's being displayed to the sub.  When the script asks a question of the sub, then next line would be something like "pause 60" (or "!pause=60" in script language).  The hypnotist would see the question, as well as the sub's answer, and he can either issue a resume command (if the sub gives the expected response), or issue a stopscript command and take over the trance if the sub gives a response that requires a different continuation.  The timeout (60 seconds in the example above) means that, if the sub says nothing, then the trance will eventually continue anyway.  Of course, the hypnotist can resume the trance early if he so chooses, without waiting for the timeout or the sub's response.

I've only just started to experiment with this, but so far I think it works well.  So well, in fact, that I may have to add two more buttons to the Owner HUD button bar to quickly pause or resume a trance.

More on Mesmerizer V1.1, and the CHAOS Owner HUD

Since the previous post, I've been working on enhancements to the Mesmerizer's support of trance scripts.  As my first post on hypnosis in second life implied, I'm not a big fan of scripted trances.  But recently I've been using scripted trance fragments within a larger unscripted trance, and I've found that works well.


The Mesmerizer currently supports two types of trance script:  Notecards and dynamic scripts.  Notecards are the preferred way to store a trance script in a Mesmerizer, but I added dynamic scripts to make it easy for an owner to create scripts within their subs' Mesmerizers, without having to pass a notecard to the sub and have them edit their Mesmerizer to add it.  Dynamic scripts allow a trance script to be created and edited via Mesmerizer commands.  The downside of dynamic scripts is that there is only limited memory space for them, whereas notecard-based scripts can be of unlimited length, at least in V1.1 (better memory utilization for scripts was one of the enhancements mentioned above, along with much faster startup).  But distributing a notecard script to a sub and having them install it isn't a trivial process, and requires that the Mesmerizer is unlocked.  So in V1.1 I'm providing a transferable installer to make it simple.

An installer is a device into which you can load notecards, animations, landmarks or textures, and have them installed into the proper places inside your Mesmerizer.  Since the installer is transferable, you can give it to a sub (assuming the content you loaded was also transferable) and then they will be able to install the content in their mesmerizer.  It makes distributing notecard-based scripts easy:  you write the script in a notecard whose name starts with "Script:", drop the notecard into the installer along with any other content you like, and give it to your sub.  They rez it, touch it to activate the installation, and in a few seconds the content is inside their Mesmerizer and ready to be used.

As I said above, I've been using scripts for "trance fragments" - a short series of messages that can be played back in the middle of a live trance session.  Repetition within a trance, or common phrasing between different trances, can have a powerful effect, and the use of trance fragments is an easy way to achieve that.  When I first created Mesmerizer scripts, I had in mind devices like the MesmerX, where a "script" controls all elements of the trance including the activation of a spiral at the start, and its deactivation at the end (and of course, scripts can do much more than just display spirals and text - they can include any Mesmerizer commands).  A fragment script would in general contain just some text to be inserted into a trance. The existing playscript commands works fine for this except that the hypnotist won't get any feedback as to what the script is saying or doing.  So in V1.1 I've added a playscripti variant which will inform the hypnotist about the start and end of the script, and show them the individual lines of text that are being displayed to the sub.  playscripti can be thought of as "playscript with information", and it works as expected remotely (if you're wearing a Communicator).

The final Mesmerizer topic is an update on outfit support.  The support I have currently in V1.1 works with the layout under #RLV that OpenCollar uses for its outfit support.  However, the "Nut" fork of OpenCollar has changed the layout of outfit folders in its latest version (Peanut 9).  This means that if you're using a Peanut-based collar with outfits, you will have to reorganize your folders to allow them to continue working under Peanut 9.  I will likely enhance the Mesmerizer so that it can handle outfits with either layout, but it probably means I will release V1.1 sooner than I expected (with OpenCollar but not Peanut 9 support), since I'm already hearing from people who are using Peanut (or HeartCore) and don't want to be forced to change their folders.  If any Mesmerizer users reading this also use OpenCollar and have outfit folders set up according to the original layout, and want to help test the Mesmerizer support for such folders, drop me an IM in-world and I'll give you a V1.1 pre-release to try out.

Along with the V1.1 Mesmerizer, I've continued to work on the Mesmerizer Owner HUD.  I've found myself relying more and more on this HUD, especially for live trancing, where it makes it easy to see and control vertical text layout, and to insert blank pauses into the message sequence.  The HUD has three modes of operation - minimized, button-bar, or full.  In its minimized form, the HUD reduces itself to a single small button and hides away in a corner of the screen.  In its full and button-bar modes, the HUD is intended to reside on the right side of the screen, beneath the area where blue popup-menus are drawn, although you can move it elsewhere if you prefer.  The button-bar mode is intended to be sufficient for trance use, and contains buttons to select target subs, to start and end a trance, to hide or show the spiral, and to display and control on-screen messages to the selected subs.  It also contains a button to easily send any Mesmerizer command to the selected subs, as well as supporting the storage and playback of commonly-used command sequences (macros) and teleport destinations.  Finally, just dropping a landmark onto the HUD will teleport the selected subs to the landmark location.  I'm playing with various UI choices to try to maximize usability, which is one reason why I consider the version I'll release soon to be a "preview" version.  The Owner HUD will most likely be free (possibly L$1 on MP so it can be gifted), and should be available shortly.

The New Year - Mesmerizer V1.1 preview

One of my resolutions this year was to try to get updates out quicker.  In my plans for this year are the product (non-beta) versions of the Communications Hubs and The Enforcer, the release of the CHAOS Owner HUD, and an update to the Mesmerizer.

While the Hubs are overdue for an update, I've been working on a new feature for the Mesmerizer that will probably see the light of day even before the Hubs do.   That feature is Outfits.  The Mesmerizer's outfits are based on the design used by OpenCollar, and are compatible with an OpenCollar folder structure.  However, Mesmerizer outfits provide some extra features to address some limitations with OpenCollar's outfits.

OpenCollar has had outfit support for a while, and it's a nice feature.  The intent is to allow your owner to change your complete look, much like regular inventory outfits let you change your own clothes and body in one go.  The RLV commands around wearing items from the #RLV folder are much more focused on things that you might add or remove from an outfit (e.g. a set of cuffs), than they are on changing everything you're wearing, so OpenCollar has had to define some conventions to separate "complete outfits" from "items that can be added", so that it can handle them differently.

The way it achieves this separation is by making use of the feature of the #RLV folder that folders whose names begin with a period (".") are not reported back to a RLV user.  This means that folders that begin with periods are essentially invisible to RLV queries, although they are still accessible by RLV commands (or at least RLVa commands - see footnote).  For example, if you have a folder under #RLV called folder and inside that a second folder called .hidden, then asking RLV for the names of sub-folders of folder (e.g. the Mesmerizer command getinv /folder) would show no such sub-folders, but performing a recursive attach operation on folder (e.g. the Mesmerizer command wearoverall /folder) would cause the contents of both folder and the .hidden subfolder to be added.

OpenCollar uses this behavior for two things.  First, it defines a convention that a hidden folder called .Outfits, immediately beneath the #RLV folder, shall be the 'root' folder for all outfits.  The fact that .Outfits begins with a period means that it won't show up in RLV queries, so RLV users won't be tempted to see what happens if you 'add' an outfit to what you're already wearing.

OpenCollar also uses this behavior to define .Core folders, which I'll come back to in a moment.  But before we get into that added complexity, the basic idea of outfits is simple - they are folders that exist underneath #RLV/.Outfits, but unlike "regular" #RLV folders, they are expected to contain a complete avatar - clothes, shape, hair, skin, any HUDs, collars and other gadgets or toys you usually wear, plus body, hands, feet and full-body alpha layer if you use a mesh avatar.  The commands to change outfits will remove everything you're currently wearing before putting on the new outfit.  You can create a folder hierarchy beneath .Outfits - for example, you might want to divide your outfits into "Gowns", "Casual", "Lingerie", etc, and use these as first-level folders beneath .Outfits, and create the actual outfits as subfolders of the appropriate first-level folder.  OpenCollar would show you these first-level folders when you go to the Outfits menu, and clicking on any of them would go into the folder and show the actual outfit folders inside, letting you choose one to wear.

OpenCollar thinks of an outfit as a combination of a "core look" and some clothes.  A core look is basically your avatar - shape, skin, makeup, hair, plus HUDs and other attachments you always wear.  Typically, the same core look might be shared between several outfits, although it doesn't have to be.  The convention for OpenCollar is that, when you ask it to change to an outfit, it will first look for the "core look" associated with that outfit, wear that, and then add the contents of the actual outfit folder.

The way it finds a "core look" is fairly simple.  It assumes that a core look will be specified in a folder called .Core, and it will look for such a folder first in the folder containing the outfit you're trying to wear, and if it doesn't find one there, it will look in the parent folder, and so on until it gets to the .Outfits folder.

This method of locating a core look, separately from the actual outfit, matches some common use-cases well.  For example, if you are a role-player with several characters, you might use those characters as your first-level folders - a folder for every character, each with its own core look - and then different clothes for the character in subfolders.  Or you might use the top-level folders to simply define different looks for a single avatar - perhaps one with hair in an up-do and evening makeup with which you'd wear formal outfits, and another top-level folder for a more casual look, etc.  The advantage of splitting the .Core folders from the actual outfits is that it allows you to modify a core look (perhaps by changing the hairstyle) and have that change immediately appear in all outfits that share that same core look.

This is a neat way of doing things - it allows a "core look" to be shared across multiple outfits, but doesn't require that you do that - you're free to define a different core look as part of each outfit, or at any level in the folder hierarchy you create beneath #RLV/.Outfits.

So what are the limitations of this scheme?  The main one is that, if you're sharing a core look among several outfits and you want to change any part of that core look for just one outfit, you have to make a complete new .Core folder for that outfit, with its  own copies of every object in the core look, with just the one change you want to make.  Let's assume that you have a look you're very fond of, and so you put the objects that make up that look into #RLV/.Outfits/.Core so that it becomes the default "look" to be used by any of your outfits.  But then you find that you want to use a different hair with one specific outfit.  Your only options are to either remove the hair from the core look and instead put it into every single outfit, or to create a complete .Core folder in the one outfit with which you want to use the different hair, effectively giving that outfit its own core look.  If you create a .Core folder inside the outfit folder, then whenever you want to change your core look (for example, use a different skin), then you have to remember to update the skins in all the .Core folders.   It's possible to use the viewer's "Find All Links" feature to help, but ideally, you'd want to be able to define a .Core folder for the outfit that contained just the new hair, and somehow took everything else for your core look from the 'standard' .Core folder.

The Mesmerizer's extensions to OpenCollar outfits makes this possible.  With the Mesmerizer, any .Core folder that contains things to wear will behave just as it does in OpenCollar.  However, a .Core folder that just contains subfolders behaves differently.  For a .Core folder that contains nothing but subfolders, each subfolder is considered to contain a named group of items to wear, with the name of the group being the folder name.  When building a core look, if the Mesmerizer finds such a folder, it will wear the contents of the subfolders, remember their names, and then continue to the parent's .Core folder.  But it will only wear items from a given named group the first time it encounters it.

Let's look at how this would solve the issue described above, of wanting a different hair in just one outfit.  Assuming you have your favorite core look in the top-level #RLV/.Outfits/.Core folder, but you want to use just a different hair for an outfit that's in #RLV/.Outfits/Casual/Jeans&TShirt.  To do this, you'd create a .Core subfolder inside the Jeans&TShirt outfit folder, and inside that folder, create a subfolder called Hair.  You can call the subfolder whatever you like, but you should pick a descriptive name for it.  Inside #RLV/.Outfits/Casual/Jeans&TShirt/.Core/Hair you'd place the hair that you want to use with this outfit.  Then, in the top-level #RLV/.Outfits/.Core folder, you'd create a similarly-named subfolder called #RLV/.Outfits/.Core/Hair and move the hair from #RLV/.Outfits/.Core down into #RLV/.Outfits/.Core./Hair.  Then, when building a core look for the Jeans&TShirt outfit, the Mesmerizer would first look in #RLV/.Outfits/Casual/Jeans&TShirt/.Core, and see that it contains a subfolder called Hair.  So it would add the contents of that subfolder (the hair for this outfit) to the core look, and remember that it's added the "Hair" group.  Since #RLV/.Outfits/Casual/Jeans&TShirt/.Core contains no wearables (just subfolders), it would look in the outfit's parent folder, #RLV/.Outfits/Casual and then in #RLV/.Outfits for a .Core folder.  Finding #RLV/.Outfits/.Core, it would see that it contains a subfolder called Hair, but since it knows that it already has a "Hair" group, it will ignore that subfolder, but will wear any other subfolders, as well as all the wearables in the .Core folder itself.

The end result of this is that the "Hair" group in the outfit overrides the "Hair" group in the default outfit, but everything else in the core look for the Jeans&TShirt outfit is taken from the top-level default core look, which is exactly what we wanted.  When wearing an outfit that doesn't have a "Hair" group in its .Core folder (or doesn't have a .Core folder at all), the Mesmerizer would use the Hair subfolder from #RLV/.Outfits/.Core.

You can use this technique to override any part of your core look at any level in your outfit hierarchy.  It's particularly useful if you use a mesh body, or even mesh body-parts.  My exposure to mesh bodies is mostly to the Maitreya Lara body, but I believe that what I'm about to say is applicable to other bodies too.

Maitreya Lara comes with hands and feet as separate mesh objects that you can choose to wear (or not) with the body.  You'd want to wear them in an outfit if they would be visible in that outfit, but if the outfit includes mesh gloves, there's probably not much point in wearing mesh hands.  Similarly, an outfit that contains mesh knee-boots probably wouldn't need to include feet.  These "tweaks" can easily be done with the Mesmerizer's outfit support by putting the Maitreya hands and feet in subfolders (called "Hands" and "Feet") of the top-level .Core folder.  Then any outfit that doesn't want to include hands or feet can include an empty .Core/Hands or .Core/Feet folder.  When building the core look, the Mesmerizer doesn't care that these folders are empty - upon encountering them it will remember that it has already worn "Hands" and/or "Feet" and therefore will not wear them from any higher-level .Core folders it visits.

With mesh bodies, clothing falls into two basic types - mesh and applier.  Some clothing items may actually contain objects of both types, but for the purposes of this discussion, such "hybrid" clothes will be considered to be appliers.

From the point of view of assembling an outfit, mesh clothing is simplest, since you wear it by simply adding it to your outfit, and you remove it by just detaching it.  Some mesh clothing may need the body's alpha regions to be adjusted on wearing/unwearing, but much clothing does this automatically.  With Lara, at least, there is a free kit that allows you to add this feature to mesh clothing that doesn't already have it.  For best use with Outfits, you will want to enable this "auto-hiding" on any clothes you use as part of an outfit.

Applier-based clothes are very different.  An applier is in some ways similar to system clothing - it's a texture that's applied to a mesh layer defined by the body.  Unlike system clothing, however, there's no standard way to automatically "remove" an applier layer from a mesh body.  With Lara, you can do this via the Maitreya HUD, but I'm not aware of an existing way to do it "automatically", via inventory operations.

Since appliers effectively modify the body (by loading a texture onto one of the body's clothing layers), they can cause problems if you share a single copy of the body between multiple outfits, since the effect of using an applier in one outfit will be seen in other outfits that subsequently use the same body.

Non-applier clothing has a similar issue with the auto-hiding mentioned above.  Switching outfits involves first removing everything that's not locked, and then wearing the new outfit.  If the original outfit included clothes that automatically hide parts of the avatar (for example a pair of boots that hide the lower legs), then normally if you took off the boots, you'd expect them to un-hide the parts that they had hidden.  However, detaching all worn items in preparation for an outfits change might easily remove the body before the boots, which would mean that when you next wore the body (possibly as part of the outfit you're about to change into) the lower legs will still be hidden.

The two issues are both cases where the setting for one outfit "leaks" into another outfit because they share a single instance of the body.  This doesn't happen with the SL avatar, because both alpha layers and system clothing can be removed, with the expected effects.  Mesh bodies don't in general provide anything that works in quite the same way.

What's wanted is a way to put the body into a known state - with no clothing layers applied and all body-parts visible - when it's first worn, as part of a core look, so that subsequently an outfit can add applier layers, or hide body parts if necessary.  This is possible with some but not all mesh bodies today.

As an example, the Maitreya Lara body supports the creation of an "auto-hide object" that can hide a set of body regions on wearing, and un-hide them upon removal. This can be used to create a "show all" object that will simply unhide the entire body, by having it first hide everything, and then detach itself.  This sort of object can be put into your top-level .Core folder, so that your default look has all body parts visible.  Individual outfit folders can contain objects with their own auto-hides (or clothing with auto-hide functionality built-in).

For this to work, some careful sequencing is required, so that the core look body is worn first, then the auto-hide object from the core look, which must be given time to detach itself, and then clothing and auto-hide objects from the outfit folder.  The way the Mesmerizer allows for this sequencing is that, for each .Core folder it visits while building the core look it will first wear objects from the .Core folder itself, then it will visit each subfolder of the .Core folder (each of which defines a group) and wear items from those folders, but won't yet wear items in any sub-folders of the group folders.  Then it will pause for a second or two before adding the sub-folders of the group folders.  This allows you to place, for example, a mesh body in a "body" group, and a "show all" object in a sub-folder, with the pause allowing the mesh body to be worn and initialized before the "show all" object is added.  Once the core look is worn, the Mesmerizer will pause again to give any "show all" objects time to work and detach before it adds the contents of the outfit folder.

A similar pattern will work with objects that clear applier layers.   Such objects can be created with the Omega system.  However, they don't work well with the Maitreya body, since Lara insists on prompting for approval before accepting an applier layer change request, and multiple such changes will get dropped.  The Omega people have asked Maitreya to make this work;  hopefully Maitreya is listening.

There are two new commands to handle Outfits:  listoutfits and wearoutfit.

Command	Parameters	Description
listoutfits	1	Show the outfits available below folder <p1>
wearoutfit	1	Wear outfit <p1>

Both commands take a path, which behaves very similarly to the path given to the wear and getinv commands, except that the root "/" of the outfit paths is #RLV/.Outfits, rather than #RLV as it is for the wear and getinv commands.  Like wear and getinv, the new outfit commands can handle either absolute pathnames (starting with a "/" character) or relative pathnames, which are treated as relative to the last valid outfit path given.  And similar to the find command, listoutfits sets a variable "outfits" to a list containing the outfit folders it displayed, so that to wear for instance the second outfit returned by listoutfits, you can simply say wearoutfit "$outfits.2"

Along with outfits, the Mesmerizer update, tentatively named V1.1, will include some extra spirals, as well as improved support for adding your own textures as either frame-based or rotating animations.  This has always been possible, but there were some limitations in the feature that 1.0 made available, and I never documented it.   The setspiral command lets you choose from one of the provided spirals if you invoke it with a small integer, e.g. setspiral 5.  The integer specifies which built-in spiral you want (1 to 7 in v1.0, 1 to at least 14 in v1.1).  You can use a negative number to run the spiral backwards.

To use your own texture, specify the texture's key instead of the small integer.  The texture can be animated either by rotating it, or it can be treated as a series of frames which are displayed as an animation.  This is specified via the setspiral parameter as follows:

Example	Description
setspiral 684e2d18‑ae40‑42e5‑af3d‑9e652018e2ea	Rotate the given texture at default speed
setspiral "684e2d18‑ae40‑42e5‑af3d‑9e652018e2ea:2.0"	Rotate the given texture at 2 radians per second
setspiral "684e2d18‑ae40‑42e5‑af3d‑9e652018e2ea:2:3"	The texture is an array of 3 rows of 2 frames each. Animate at default speed.
setspiral "684e2d18‑ae40‑42e5‑af3d‑9e652018e2ea:4:2:8.0"	The texture is an array of 2 rows of 4 frames each. Animate at 8 frames per second.

Note how when the parameter contains special punctuation such as ".", it must be placed in double-quotes to keep it as a single parameter.  You can put a "-" sign in front of the texture key to cause it to be rotated or animated in reverse.  And if an animation texture contains fewer frames than the product of rows and frames-per-row you can specify the actual number of frames in square brackets after the texture key, for example:

setspiral "-684e2d18-ae40-42e5-af3d-9e652018e2ea[5]:2:3"

This says that the texture is arranged as a 2x3 array of frames, but only the first 5 frames should be displayed.  The "-" sign at the front says that the five frames should be animated in reverse.

Footnote on RLV vs RLVa

RLV and RLVa are two different versions of the RLV spec, and which one you have depends on which viewer you use.  Firestorm, for instance, uses RLVa.  While there are some minor differences between the two specs, most of the time you shouldn't care.  However, Outfits are one of the times that it does make a difference.   While both RLV and RLVa hide the presence of foldernames that begin with a ".", RLVa permits such folders to be included within paths in RLV commands, so that, while the folders won't be shown, you can navigate into them, or make queries about them if you know their names.  RLV doesn't do this - folders beginning with a "." are completely hidden.  This means that Outfits (both in the Mesmerizer and in OpenCollar)  will only work on a viewer that provides RLVa.  In the Mesmerizer, Outfits are implemented in their own script, as a plug-in, so if you only use a viewer that doesn't support RLVa (or you simply don't want Outfit support), you can remove this script and issue a rebuild command to reduce your script count.  If you do this, you should work on a copy of the Mesmerizer, to avoid damaging the original.