New Year's gift - Mesmerizer 1.6.5

Another small update to the Mesmerizer is in vendors now.  I'll be updating the Marketplace store soon as well, but you can get the update as a redelivery from any of my vendors, regardless of whether you originally bought from a vendor or from MP.

Variants of scheduling commands

The Mesmerizer supports scheduling of triggers to fire in the future via the executein and executeevery commands. These commands allow you to specify a trigger to be fired either once (executein) or repetitively (executeevery).  The commands generate a key to name the future event in case you want to cancel it before it fires (using the cancel command, which takes the name of the event to be canceled); you can see the currently-scheduled events using the showsched command.

A user wanted to be able to schedule and cancel events from within a script, and the problem they were having was that there was no way to determine the name assigned to the event other than the showsched command, which isn't useful from a script, as there is no way for a script to obtain the output from the command.

Mesmerizer 1.6.5 addresses this need by providing executein2 and executeevery2 commands, which are variants of the original commands that allow you to specify the name to be given to the scheduled event as an additional last parameter.  If you use the name of an event that is already scheduled, the new event replaces the original one.

For example, the command:

/99 executein2 90 foobar fred

will schedule an event to fire the trigger "foobar" in 90 seconds time.  It will give the name "fred" to this event, as can be seen via showsched:

/99 showsched

[08:44] Nue's Mesmerizer v1.6.5.5 (L): Scheduled Events:

  fred 2021-12-10 16:46:22Z "foobar" one-time for 7f1cfe79-71ae-4855-b766-754ec2e38bd7

If I wanted to cancel the event before it fired the trigger, I would use:

/99 cancel fred

Bugfixes

In addition to the new scheduler commands, Mesmerizer version 1.6.5 has a couple of fairly important fixes to the RLV relay, plus a fix to a bug with overlays that I inadvertently introduced when I added support for vision spheres.

The Enforcer 1.1.2

Hot on the heels of Mesmerizer 1.6.4 comes a minor update to The Enforcer.  As previously described, this update addresses a bug in argument parsing and introduces a new command, !charmap,  that enables "sanitization" of strings, and likely has a number of other uses as well. 

The Enforcer 1.1.2 is going up in vendors today.  Both this and Mesmerizer 1.6.4 will be on Marketplace shortly, but you can get a product update from my vendors (locations in the "Vendor links" sticky to the right) now, even if you originally bought the product on MP.

With these two updates complete, I can focus on two near-future products: The RoboCollar and the Trance Library. 

Mesmerizer 1.6.4 release

 As usual, I was a little optimistic in the previous post as far as release timing goes.  But Mesmerizer 1.6.4 is up in vendors as I type, and I expect The Enforcer 1.1.2 to follow soon.  Both will be updated on Marketplace soon after they appear in vendors, but you can get the update via a redelivery from a vendor regardless of whether your original purchase was through a vendor or from Marketplace.

As described earlier, this release is mostly focused on preparation for the new RoboCollar, but it also contains a few bugfixes and one new pre-defined variable, hypnotist, which will contain the key of the current hypnotist during trance, and the string "none" if no trance is in effect.    

The work towards supporting the RoboCollar is mainly in the area of the behavior of the leash.  While 1.6.4 makes a significant improvement, I'm still not completely happy with its responsiveness in laggy sims so I expect to make further tweaks in future releases.  However, I no longer feel that I need to hold up the RoboCollar for those tweaks.

In parallel with the RoboCollar and The Enforcer 1.1.2, I've been working on a new Trance Library product.  This will act as an external controller for The Enforcer, and will support the centralized playback of trance scripts.  The trance scripts are very similar to trance scripts within the Mesmerizer, with only very small differences which in most cases are unlikely to be relevant.  The upshot of this is that in most cases you will be able to take script notecard from a Mesmerizer and drop it into the Trance Library unchanged, from where it can be broadcast to one or many subs, either manually (via a Trance Library menu choice) or via a script command in The Enforcer.

The Trance Library is still in a fairly early stage of development, but once the update to The Enforcer is out, I will be able to focus on both the Library and the RoboCollar.

Another pair of small updates to the Mesmerizer and The Enforcer.

This could be a first - two updates in the same month.   In actuality, I suspect Mesmerizer 1.6.4 and The Enforcer 1.1.2 will be released early next month.

Mesmerizer 1.6.4

Mesmerizer 1.6.4 fixes another minor bug reported by Allison from Trance Lab, as well as a permissions error that caused the Mesmerizer to be no-copy (although you could obtain a fresh copy if needed via a redelivery).  However, the focus of this update is mostly on making leashing work more effectively in preparation for the new CHAOS Collar range.  Previously, leashing was implemented by internally using the follow command with the addition of a visible chain.  Follow works fine, but it allows the sub to trail behind their owner, and in high-lag sims there can be a good distance built up between them  This doesn't look right if the sub is supposed to be leashed to the dom.  So Mesmerizer 1.6.4 gives leash its own more aggressive mechanism to stay close to the dom.  The follow command retains its original behavior.

Another minor enhancement is the addition of a built-in Mesmerizer variable called "hypnotist" that will be set (if the wearer is in trance) to the key of their hypnotist.  If no trance is in effect, the variable will be set to "none".  The primary purpose of this is to allow Enforcer programming to test whether the wearer is in the middle of a trance before doing something that might be disruptive.  

For example, suppose that you want to periodically send the sub some text from The Enforcer, using the Mesmerizer's text command inside an event notecard "SendText" that requeues itself every 10 minutes while the sub is still online.  That requeuing would likely use the !eventin command, possibly using !checkonline first to determine whether the sub is actually online, and only executing !eventin if they are.  However, if the sub is in trance, the text command is likely to overwrite trance text and generally disturb the flow of the trance.   

One way to check that the sub is both logged in (eliminating the need to call !checkonline) and not in trance is to invoke the SendText notecard not directly via !eventin, but indirectly by making the sub signal the event, and as part of that signal, include whether or not a trance is active.

To do this, you need a second notecard, which we'll name "SignalSendText".  All this notecard does is send a signal command to the sub, using a command like:

^signal "SendText" "$$hypnotist"

This SignalSendText event is the event that would be scheduled via !eventin inside the SendText notecard, and if you want to run the event manually, it's what you would cause to fire.  SignalSendText tells the sub's Mesmerizer to signal a SendText Enforcer event, and pass the value of the Mesmerizer symbol hypnotist in the event's data variable.  Note the use of the double-$ which suppresses variable expansion in The Enforcer, and instead replaces the double-$ with a single $ in the command sent to the Mesmerizer so that the variable expansion will happen in the Mesmerizer, and be returned to The Enforcer in the signaled event. 

If the sub isn't logged in, there will be no Mesmerizer there to execute the signal, so no more events will be scheduled.  If they are logged in, then they'll signal the SendText event, which should check the value of $data to see if they're in trance.  If their Mesmerizer is 1.6.4 (or later), this symbol will contain either their hypnotist's key, or "none" if they're not in trance.  An older Mesmerizer will likely not have the variable hypnotist defined, so the "$hypnotist" in the second parameter to signal will be replaced by "hypnotist" - this is the original behavior for expansion of undefined symbols that I mentioned when I changed it in The Enforcer - The Mesmerizer still uses the original behavior, at least for now.

This technique of having The Enforcer send a signal command to the Mesmerizer is a straightforward way to obtain information from the Mesmerizer that would otherwise be unavailable to The Enforcer.  The parameter to signal is fairly limited - while you can pass a list as the parameter to collect multiple pieces of data at once, each list element is pretty much constrained to being obtained via variable expansion.  But if you want to keep track of some state information for which there isn't a built-in variable, you can sometimes use a Mesmerizer trigger to maintain your own state variable for use in a signal.  If you find yourself doing this, let me know, and I may well add a built-in variable if whatever you're tracking is of general utility.

The Enforcer 1.1.2

Hot on the heels of The Enforcer 1.1.1 comes another bug-fix release, to address a bug found (yet again) by Allison.  This bug concerns variable expansion and how that plays with the use of "::" as an argument separator in Mesmerizer commands.  Previously, variable expansion was done before parsing out the arguments from a command, so if a variable that was expanded contained two successive colons as a substring, that would be interpreted as an argument separator.  This is almost never what's intended.   Enforcer 1.1.2 fixes this so that the argument separators are parsed first, before variable expansion takes place.  At the same time, I fixed another bug where external whitespace surrounding the arguments was not being ignored.

A related but distinct bug arises from expansion of symbols that contain either single or double quote marks.  Since the double-colon is used to separate arguments of a Mesmerizer command, quote marks are really only significant in expressions, or in commands that are to be sent to the Mesmerizer.  Usually you know if a variable expansion might contain one of these characters, and (at least within expressions) you can use the other one to delimit the words of the expression.  However, if the variable is obtained from "outside" (for instance, it's the name of an object that was sat-on), then it might contain either or both types of quote mark.

To allow for this, while providing a potentially useful new function, The Enforcer 1.1.2 will contain a new command: !charmap.  This command takes three arguments - the first is a string, which can contain "unsafe" characters since it's in an argument position; the second is a map, and the third is the name of a variable into which the mapped string will be written.  The map (the middle argument) tells !mapchar which characters should be replaced, and what they should be replaced with.  It is simply a string that contains pairs of characters, and if the first character in a pair appears in the input string, then it will be replaced by the second character in the output string.  So for instance:

!charmap This value contains both " and ' and neither are matched :: "' :: output

will result in $output containing the string "This value contains both ' and ' and neither are matched" (without the surrounding double-quotes). The map-string may not be very legible in a browser, but it contains two characters - a double-quote followed by a single quote, and it tells !charmap to replace any double-quotes with single quotes.  So !charmap can be used to "sanitize" unknown strings by replacing potentially troublesome characters with more innocuous ones.

Note that because whitespace surrounding a command argument is now ignored, if you want to write a map that involves space characters, you need to make sure that space is neither the first nor last character of the map.  Usually this is easy - you just put character pairs that contain a space character somewhere other than at the start or end of the map.  If you can't do this (for instance, if you're writing a map to convert space characters to underscores), then you need to add a dummy pair so that the space is internal to the map.  So a map that converts spaces to underscores might look something like:

!charmap $input :: .. _ :: output

The map string is four characters: two periods, a space and an underscore.  So it consists of two pairs - the first maps a period to a period, which is a no-op, and its sole purpose is so that the next pair, which maps a space to an underscore, is not at the start of the map so that the space in it will not be ignored.

!charmap has a lot of other potentially interesting uses, which is why I decided to expose it as a general-purpose command rather than building in a specific sanitization rule.  For instance, it could be used to convert a string to lowercase via a map such as:

AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz

To be sure, this is a fairly inefficient way of down-casing a string, but previously it wasn't even possible in The Enforcer.

A day late, but hopefully not a dollar short

 The updates I mentioned a few days ago (The Enforcer 1.1.1, Mesmerizer 1.6.2 and Owner HUD 1.0.1) are now live in the vendors.  I'll update them on Marketplace over the next day or so, but regardless of whether you bought on MP or from a vendor, you can get a redelivery from any CasperVend machine.   The locations of my own vendors are listed in the stickies on the right side of this page.

There was one additional fix that I made to The Enforcer 1.1.1 which was an issue that sometimes caused the !event and !eventin commands to appear as it they weren't working.  Also another fix in Mesmerizer 1.6.2 that addressed a bug that would miss a line in a script when returning from a call to a second script.

When updating the Owner HUD, you can use the "Save" button in the main menu to have the old HUD save all its settings (Teleport destinations, Macro definitions and recent targets) as a string to local.  Then, once you're wearing the new HUD, you can use its "Load" button and paste the string that "Save" produced back into local to transfer the settings to the new HUD.

As stated earlier, Mesmerizer 1.6.2 (or higher) will be needed in order to use the upcoming CHAOS RoboCollar.  I'm still working on some tweaks that will need to be in the base Mesmerizer for best support of the new collars, so there may well be a 1.6.3 release that contains those tweaks (plus fixes for any other bugs I'm made aware of), but 1.6.2 will support the new collars.

Along with the collar, I will be providing an optional "Utility HUD" for the Mesmerizer user to wear.  The Utility HUD shows the current charge in the collar's battery, and also provides some other miscellaneous features that are potentially of use to any Mesmerizer wearer, even if they don't have a CHOAS Collar:

• The ability to lock core avatar components (e.g. body, head, etc) against accidental detaching.
• One-touch access to Mesmerizer chat
• Programmable buttons to issue Mesmerizer triggers, RLV commands or channel messages 

I expect the CHAOS Utility HUD will be included with any CHAOS Collar that uses a battery, and available for a nominal charge to anyone else.

Updates, Errata and News

Updates and Errata

I expect the following minor product updates to be in vendors this weekend.  Sadly, my expectations around product dates frequently aren't met, but I will do my best on these.

Mesmerizer 1.6.2

Firstly, an unscheduled Mesmerizer update: 1.6.2.   This mini-release fixes a bug that caused the setvarex command to silently fail (big thanks to Allison from Trance Lab for bringing this to my attention), and it also provides some support functionality needed by an upcoming product - the CHAOS RoboCollar, described below.

The Enforcer 1.1.1

Another minor update, this time just to add a times operator to The Enforcer's expression language.  times simply treats its two arguments as integers, and multiplies them together.  This enhancement will also be in the Mesmerizer expression language in Mesmerizer 1.6.2. 

CHAOS Owner HUD 1.0.1

This update adds the "find" functionality to locate items in the wearer's #RLV folder, and removes the annoying message when you click the HUD somewhere other than a button.

News

I have been working on several collar-related projects recently.  I first created a collar that works with the Mesmerizer a couple of years ago but never turned it into a product.  Now, though, I'm going to start releasing some of those projects, the first one being the CHAOS RoboCollar.

Collars in SL serve a variety of different purposes, and I intend to reflect this in the CHAOS collar range.  The simplest type of collar is similar to a real-world BDSM collar, and is primarily a symbol of ownership, perhaps with a secondary function of providing somewhere to attach a leash.  A basic collar like this can use the Mesmerizer to provide almost all its functionality.  More complex collars may have additional features, and could also provide a simple menu interface to some relevant Mesmerizer commands.

The RoboCollar is a sci-fi collar, intended to be used within cyborg roleplay.  The reason I chose this collar as the first release is that it's the most feature-rich collar that I've been working with.  Other collars, to be released later, will be implemented as cut-down versions of the RoboCollar, omitting those features that don't make sense in a given collar.

Here are the features currently planned (and mostly implemented) for the CHAOS RoboCollar:

• Usual SL collar features including leashing and quick access to all the animations installed in the Mesmerizer.
• Both menu-driven and traditional command-line user interfaces.
• "Holographic" label, supporting multi-line text with the ability to change fonts.  Additional font-packs will be available for a nominal charge, but it's quite easy to create your own.
• The concept of a "home" location, with the ability to teleport the wearer to their home.
• "Power off" and "Freeze" modes, with separately configurable restrictions and animations. These generate new Mesmerizer events: on-power-off, on-power-on, on-freeze, and on-unfreeze.
• Battery support, with automatic power-off when charge becomes critically low, and optional delayed automatic TP home on battery-out.  Power-out generates a Mesmerizer event on-power-out, and an Enforcer Event PowerOut. A couple of battery charging stations are planned - one for wireless charging, and one that requires the wearer to sit in the charger.
• Synchronized trance support, so that the wearer's trances can be visible in-world.  The collar projects a holographic spiral (showing the same spiral that the wearer is seeing), and this in-world spiral contains the CHAOS trance relay functionality, so that trance text can be seen in-world (if publictext is enabled).
• Display of current status, battery charge, etc on the front of the collar, and also (for the wearer) via a CHAOS Utility HUD, which can also be programmed to issue self-triggers and RLV commands for the wearer's own use.  This allows you, for instance, to create simple pushbutton commands to do things like lock and unlock your hair, or switch between the relay modes that the owner has given the wearer access to.

All access control is via the Mesmerizer.  Only those listed as Owner in the Mesmerizer's Access notecard have access to the collar.

The collar is implemented as a PAN device (actually a pair of PAN devices "collar" and "titler"), and while you can use the low-level PAN commands to drive the collar, the expectation is that you will use the two Mesmerizer plugins that come with it.  One plugin supports a command-line interface (defining collar and collar2 commands), and the other layers a menu-driven UI on top of the command-line interface.  The collar and collar2 commands (and the PAN interface) are accessible remotely (as are all Mesmerizer commands), while the menu-driven collar UI only works locally.

Future

The next (full) release of the Mesmerizer will almost certainly be a performance enhancement.   The experience I gained from re-factoring The Enforcer convinces me that I can significantly improve the Mesmerizer's performance through similar techniques.  This will be a non-trivial project, which is why I want to release Mesmerizer 1.6.2 with enough support for the new RoboCollar before embarking on refactoring the Mesmerizer.

I'm also still planning the Scheduler and Trance Engine controllers for The Enforcer, as well as an update to the Noise-Cancelling Headset, but those will likely have to wait until the RoboCollar is released.  

A longer-term project that's been on the back-burner for some time is a pose-engine designed specifically for bondage furniture, plus one or two individual furniture items that use the engine.  Almost all Second Life bondage furniture is built using one of a small number of multi-pose furniture engines, and these general-purpose engines are a poor fit for bondage furniture.  I will expand on this in a future post, going into more detail on what I see as the problem(s) with current furniture, and the proposed solution that I've been working on.

Mesmerizer 1.6 Released

Mesmerizer 1.6 is up in vendors, and will be on MP shortly.  As described in the previous post, this update adds support for RLVa Vision Spheres, Enforcer events for sitting and standing up, and improved reporting.  You can obtain the new version by touching any of my vendors (locations given in the stickies on the right) and choosing "Redeliver".  Instructions for updating a Mesmerizer are also in the stickies, under "Mesmerizer Version Upgrades".

As promised, updates to the Noise-Cancelling Headset and the Owner's HUD will be available very soon, along with an update to the Trance Titler.

Mesmerizer 1.6 preview

 I know I said that the next product releases would be an update of the Noise Canceling Headset and the Owner's HUD.   These are still planned for release very soon (and if anyone would like a pre-release version of either, send me an IM in-world).  However, Mesmerizer 1.6 has been the focus of my attention recently, and it will probably be released before (or perhaps simultaneously) with those other two product updates.

Mesmerizer 1.6 was planned to be a minor bugfix release.  It still will be mostly bugfixes, however there are a few new features that are worth previewing.  The main reason I write these preview posts is to allow people to comment or request changes to the functionality before release, so if you dislike anything I talk about in these previews, or have an idea for a better way to achieve the same result, let me know.  Once a feature has been released, I'm reluctant to change it in a way that might break trigger rules or EnforcerScript that uses the feature (although I'm happy to extend features in a backwards-compatible way).

Enforcer Events

First, there are new Sit and Stand Enforcer events, fired when the wearer sits on a piece of furniture, or stands up from sitting.  The Sit event has access to the name of the object that was sat upon in the $data variable.

Improved reporting

The report command now shows the parcel owner as a clickable link that opens their profile (or the group profile, for group-owned parcels).  If the wearer is sitting on an object, the report now includes the owner and creator of the object (also as clickable links).

Similarly, the information returned by the getattachments command now includes a clickable link to the creator of each worn attachment.

Vision Spheres

The main new feature is support of (a subset of) the new RLVa Vision Spheres that finally made it to Firestorm.  Vision Spheres are a long-awaited feature that can be used to interfere with the wearer's vision.  The initial Mesmerizer implementation provides three different effects: one that simulates fog, another that simulates blurring and a final one that pixelates the image.  These effects are distance-based - in other words, nearby objects are unaffected, but the effect gets increasingly stronger for more distant objects.  

These effects are currently mutually exclusive - if you create a fog effect, you can't simultaneously use the pixelation effect.   This restriction is due to the underlying vision sphere being a property of the viewer - and only a single vision sphere is supported.  In addition there is some (unintentional) interaction between overlay and vision spheres in the underlying RLVa.  I hope this will be addressed in the next Firestorm update, but for now, you shouldn't try to use overlays and vision spheres at the same time.  However, the fact that there is this interaction forced me to modify the Mesmerizer's implementation of  overlays so that it relinquishes the screen's overlay when it's not actually displaying anything - it previously grabbed the overlay full time.  This change should make the Mesmerizer play much better with other devices that also wish to use the overlay feature, so by forcing me to make that change, the RLVa bug actually made things better.

Like overlays, Vision Spheres are RLVa-specific, or at least the details are.  The original RLV (e.g. Marine's viewer) has had its own vision sphere implementation for many years, and RLVa (the implementation used in Firestorm and Catznip) has lagged behind.  Now RLVa has implemented the feature, but rather than duplicating the RLV commands for establishing vision spheres, RLVa has its own incompatible set of commands and the underlying sphere implementation is very different too.  In Mesmerizer 1.6, I'm focusing on the RLVa version, although there is an attempt at providing some compatibility with RLV, at least for the fog effect.  This compatibility layer will be improved in subsequent releases, but due to the very different underlying visual processing, I don't think that full compatibility is possible (unless RLV adopts the RLVa spheres in addition to its own version).  So the description below refers to the visual experience when using RLVa - primarily Firestorm or Catznip.

Each Vision Sphere effect has its own command: fog, blur and pixelate.  The command syntax for each of these commands is reminiscent of the overlay and overlayslides commands, in that they take a single parameter which is a series of colon-separated keyword=value pairs.  However, each effect command can also take a simple on, off, yes, no or default parameter instead of a keyword/value list.  

So /99 fog on will enable a fog effect, using whatever the current parameters are.  The default parameters result in a mist that gradually increases to maximum at 100m distance.  /99 fog default will return all fog parameters to their default values, and will show the resulting mist.  Since all three commands use the same underlying vision sphere, specifying the parameter off to any of them will disable all effects. 

The following table lists the keywords that can be specified to each of these commands:

Keyword	Description	Example
show	Boolean. Whether to show the effect. Default is yes.	show=no
origin	Whether the effect should be centered on the avatar or the camera. Default is avatar.	origin=camera
ramp	Number of seconds to take to apply the new settings.  Default is 3 seconds.	ramp=3.0
maxdist	Distance in meters at which the effect is at its maximum strength. Default is 100	maxdist=50
mindist	Distance in meters at which the effect is at its minimum strength. Default is 1m	mindist=2.5
color	For fog command only.  R/G/B color of fog. Default is a gray, at 0.35/0.35/0.35.  A few predefined color keywords may be used instead of RGB values: black, white, gray, pink, red, green, blue.	color=0.5/0.5/0.5 or color=pink
min	For fog and blur commands only.  The intensity of the effect at mindist, in a range 0-1.  Default is 0.	min=0.1
max	For fog and blur commands only. The intensity of the effect at maxdist, in a range 0-1.  Default is 0.95 for fog and 1.0 for blur.	max=0.8
width	For pixelate command only.  Number of horizontal pixels to pixelate.  Default is 15.	width=10
height	For pixelate command only.  Number of vertical pixels to pixelate.  Default is 15.	height=20

These commands set parameters for the corresponding command, and these parameters are remembered on subsequent uses of the command.  So for instance, setting a fog color with /99 fog "color=green" will cause subsequent fog commands to produce green fog, until another fog command explicitly changes the color.  On a relog, all parameters are reset to their default values.

For instance:

/99 fog "color=pink:mindist=2.5:maxdist=10:ramp=5" will create a thick pink fog that builds up over 5 seconds.  

/99 pixelate "mindist=5:width=20:height=20" will cause severe pixelation of everything more than 5m from your avatar (the pixelate command only uses a single distance value - you can use either mindist or maxdist, but if you supply both, then mindist is used). 

/99 blur "maxdist=10" will simulate fairly strong myopia.    You can set the max strength parameter to a value greater than 1 to distort the image even more, but this results in obvious multiple images, rather than a simple blurring.

The values set by one command are retained for subsequent instances of that same command, so /99 fog "mindist=2" followed by /99 fog "maxdist=20" will have same eventual result as /99 fog "mindist=2:maxdist=20", except that if ramping is enabled (as it is by default) the first form will visibly establish the minimum distance first, and then the maximum distance, whereas the second form will establish them both simultaneously.  However, each command (fog, blur and pixelate) retains its own settings, which are unaffected by changes made using another command.

Bugfixes

In addition to the features above, Mesmerizer 1.6 includes some fixes to the overlay and overlayslides commands, as well as a refactoring of the RLV relay to give it more headroom.   I will likely continue to tinker with the relay in subsequent releases.

Lara 5 Clothing Layers

 This post has almost nothing to do with the CHAOS range, or indeed any Clean Sweep Designs product, other than hopefully being useful to Mesmerizer wearers who also use the Maitreya Lara mesh body.  While there is strong competition between makers of mesh bodies (especially female ones), as of this writing Lara still seems to be the most popular, at least judging from the support of clothing makers.

Lara 5.x introduced a novel and very powerful change from the previous versions:  the tattoo, underwear and clothing layers are now individual objects, rather than being part of the body.  When you first see this, it seems like complexity for no benefit, not to mention the additional attachment points that are needed to wear those new extra layer objects.   But the hands and feet are now part of the main Lara body, so you're saving attachment points there.  And you don't always need to wear all three layers anyway, so the change can actually be a net saving of attachments.  However, why didn't Maitreya just bring the hands and feet into the body and leave the layers part of it too, so that the whole thing would use just a single attachment point?

One reason is that making the clothing layers be individual objects allows you to dispense with appliers, or rather to let you create applier-based clothing that works like "real" clothes - that you can wear and remove through inventory (or RLV) and they work as expected, without you needing to play with appliers or save slots as part of changing clothes.  Separate layer objects allow you to turn any applier clothing item into a piece of rigged mesh clothing, which you can then wear (and take off) like any other piece of clothing.  This is particularly useful if you're an RLV user, and you want to allow other people to change your clothes for you.  Previously, RLV couldn't affect applier clothing; with Lara 5 you can expose your applier-based clothing via the #RLV folder in the same way that you do with mesh clothing.

I'll illustrate the basic concept first, and then go through how to set up an applier-based catsuit that has zippers over the breasts and crotch, and show one way of setting things up so that those zippers can be pulled open or closed through RLV.

Appliers as objects

Applier clothing and mesh clothing behave very differently from one another.  Mesh clothing can be included in outfits, so that when you wear the outfit, the clothing item is worn, and when you remove or replace the outfit, the mesh clothing item is removed, as expected.   Appliers, on the other hand, don't behave like this at all.  Prior to Lara 5, applier layers were part of the body, so the only way to have your applier clothing change automatically when you change outfits was to have a different copy of the entire body in each outfit, with the correct applier clothing "pre-applied".  While this is possible, it means that each outfit has its own skin too (since the skin is also part of the body), so if you decide to update your skin, then you have to update every copy of the body individually.  And when you come to update to a new version of the body, every copy of the body has to be updated separately.   What the new separate layers gives you is the ability to turn applier clothing into regular mesh clothing, and once you've done that, you can use the applier-based clothing item within an outfit, and have it just work the way you expect clothing to work.

There are three distinct clothing layers in Lara 5 - Tattoo, Underwear and Clothing.  Let's assume you have a simple catsuit that comes as an applier, and you want to create an outfit that includes that catsuit.  The first step, once you've chosen which layer you want to wear the catsuit on, is to make a copy of that layer.  I'll assume you're going to wear the catsuit on the underwear layer, so make a copy in inventory of the Lara underwear layer.  Ideally, you'd want to rename this copy something like "catsuit", but unfortunately Maitreya ships it no-modify, so you can't change its name.  What you can do though, is to create a folder called something like "Catsuit on Underwear" and put the copy of the underwear layer into that folder.  This way you'll know what it is when you want to add it to outfits.

Next, wear the copy you just made.  Make sure you're not wearing any other underwear layers, or ideally any other layers at all.  Use the catsuit applier to apply the catsuit, and check everything looks ok.  Once you're happy, take off the underwear layer, and ideally wait a few seconds to ensure that it gets updated on the SL servers before wearing it again to check that it still works.

Assuming everything looks good, you now have the catsuit, but as a piece of mesh clothing that can be included in an outfit, just like any other clothing item.  You won't need to use the appliers when you wear the outfit, as the catsuit is "pre-applied" to the underwear layer copy.

Appliers with variants

Now let's assume that the appliers for the catsuit we just created have "variants", for example versions with exposed breasts and/or exposed crotch.  Several catsuits come like this, typically with separate appliers for top and bottom half, so that you can mix and match the various versions.  Clothing layers can be used the same way - with separate layer copies for upper and lower halves, but that gets messy, and wastes attachment points.  I'll describe a method that I like, which is suitable for using in your #RLV folder, to allow someone else to "unzip" and expose those areas.

I'll assume you created the "normal" version of the catsuit as described above.  Since this is a regular piece of mesh clothing, you can put it in a folder under #RLV to allow someone else to have you wear the catsuit (or strip it, if you're already wearing it).  I would strongly recommend keeping a single copy of the "Catsuit Underwear Layer", and just putting a link to it under #RLV, rather than making more copies of it.

So you might make a "Catsuit" folder under #RLV (or maybe a hierarchy of folders like "Clothing/Catsuits/Black"), and put the link to the full catsuit underwear object into that.  This will let someone make you wear the catsuit, or remove it via RLV commands.

To allow them to expose your breasts, go through the process above to make a copy of the underwear layer, and apply the catsuit, but this time use the "breasts exposed" version of the applier.  Then make a "Breasts Open" subfolder of the #RLV folder that holds the regular catsuit, and use copy/paste-as-link to put a link to the new "breasts exposed" underwear layer into that folder.

Do the same with the open crotch version, and finally with both open breasts and open crotch, giving you four copies of the underwear layer, each with a different variant of the catsuit pre-applied.  Paste links to all variants into appropriately named subfolders of the regular catsuit folder.  This might result in a folder hierarchy like the following:

/#RLV

  |
  |-- /Clothing

       |
       |--/Catsuits

           |
           |-- /Black

                |
                |- (link to Closed Catsuit underwear layer)

                |

                |--  /BreastsOpen

                |     |
                |     |- (link to BreastsOpen underwear layer)
                |
                |--  /CrotchOpen
                |     |
                |     |- (link to CrotchOpen underwear layer)
                |
                |
                |--  /BothOpen

                      |
                      |- (link to BothOpen underwear layer)

                

Folders are indicated in the above diagram by being in bold font, and prefixed with a forward-slash character.

Someone using RLV to force-wear the #RLV/Clothing/Catsuits/Black folder would result in you wearing the regular, closed version of the catsuit, but they could then force-wear #RLV/Clothing/Catsuits/Black/BreastsOpen to expose your breasts.  Since the underwear layers are all worn on the same attachment point, wearing the BreastsOpen version will displace the regular version.

An alternative would be to put all four variants, including the default "Closed" version, in four parallel subfolders.  Either scheme works, and with the Mesmerizer at least, it's fairly obvious which layout you've chosen.

The one "gotcha" is the statement above that the various underwear layer copies are all worn on the same attachment point.  This is true, if you followed the instructions so far.  As shipped by Maitreya, the Lara Underwear Layer attaches to the Right Shoulder attachment point, so all your copies should also attach there, and so the different variants will knock each other off (as desired) when "worn" (rather than "added").  However, the Maitreya Tattoo and Clothing layers also attach to the Right Shoulder, which means that wearing an underwear layer will knock off any clothing or tattoo layers you happen to be wearing, not just other underwear layers.

To avoid this, I would recommend changing the default attachment points for the three layers so that each layer is worn on its own point.  It would also make sense to move them to locations that are unlikely to be accidentally knocked off by wearing another piece of clothing.  If your avatar is human, then there are several bento attachment points that you are unlikely to want for anything else, for instance Left Wing, Right Wing and Tail Tip.  You can use "Attach To..." to wear each of the original Lara layers on a different point, and then future copies will inherit this new location, and from then on your copies will only interfere with other copies of that same layer.

         

The Enforcer 1.1

 The 1.1 update of The Enforcer has been in my vendors for a few days, and I'll be updating the MP version soon, although even if you purchase through Marketplace, you should be able to get the new version as a redelivery from any of my vendors (locations given in the stickies on the right), or indeed any CasperVend vendor.

The Enforcer 1.1 has a minor bugfix to do with namespace initialization in the event command, plus the new eventin command that will create an event after a specified interval.  I have updated the Command Reference Manual for The Enforcer (also in the stickies on the right) to cover the new command.

Also included is a "Button" freebie.  As described in the previous post, once configured, this allows you to create events within The Enforcer at the touch of an in-world button.  You can use this for all sorts of things, from bringing your sub to you, to changing their outfit, to starting trances within their Mesmerizer.  The Button is the first instance of an external "controller" that can be connected to The Enforcer, and as previously described, I have plans for at least the following additional controller products:

• a Scheduler controller, which will allow events to be executed at a specific time, possibly repeating on a schedule.
• a Trance controller, which will allow trances to be broadcast from The Enforcer to one or more subs.

As previously stated, I will soon be shipping a 1.1 update of the Noise-Cancelling Headset, as well as a very minor update to the CHAOS Owner's Hud.

I am also planning an update to the Mesmerizer.  So far, this looks to be primarily a bug-fix update, addressing RLV relay stability, as well as a couple of issues identified in the overlay commands.  I'm currently testing these fixes, and I will probably ship this as a 1.5.1 bugfix release, without any additional new features.

Product updates

Updates, both large and small, to several products are on their way.  First, The Enforcer 1.1 will be up in vendors and on MP soon, followed by minor updates to both the Owner's HUD and the Noise-Cancelling Headset.  I expect to push these updates out to Vendors and Marketplace within the next couple of weeks.

Owner's HUD 1.0.1

I'm making a very small update to the Owner's HUD - just the addition of the "Find" functionality, for locating #RLV folders when you can't quite remember where they are.  This will be an additional button on the HUD's "Dress" page.  If the sub has a large set of #RLV folders, Find can save you having to perform a bunch of list/getinv operations to track down the item you're looking for. Since the Find command sets the rlvpaths variable, after performing a Find, if you want to add, say, the third instance that was found, you can simply specify $rlvpaths.3 as the thing to be added.  This works both in the Owner HUD and as a Mesmerizer command.

As an example, let's say that you know that your sub owns a set of Real Restraint Vixen leather cuffs, and you remember that she has divided them into two subfolders called "Cuffs" and "Collar".  You want to add the cuffs, but you can't remember where in her #RLV folders the Vixen folder is.  You also can't remember exactly what it was called, other than it had "Vixen" in its name.  So first you do a find operation, and specify "vixen" as the search string.  This will result in the Mesmerizer saying something like this to you:

1: /Clothing/Lingerie/Vixen Chain Teddy
2: /Clothing/Shoes/Leather Vixen Heels

3: /Restraints/Cuff Sets/Vixen Leather

Obviously, the third one is the one you want.  So to make your sub wear her Vixen cuffs, which you remembered were in a "cuffs" subfolder, you'd press the Add button and enter "$rlvpaths.3/cuffs" (without the quotation marks) as the folder to add.  If you wanted to use the command line instead of the HUD, you'd use: /99 wearover "$rlvpaths.3/cuffs".  Note that in the command line version, you do need quotes, since there's punctuation in the string.  If you use the HUD's Add button, though, it will add those quotes around whatever you type, so you don't need to type them yourself. 

Noise-Cancelling Headset 1.1

This update fixes a very intermittent bug, where after many relogs wearing the headset, it might no longer detect RLV.  In addition to that fix, this update will permit resizing in all three directions (rather than just the two in the original headset), as well as allowing you to change the color of the plastic parts.  There are a handful of preset colors, plus the ability to specify a tint by its RGB value.

There is also an additional restriction: "OwnerDeaf", which works in conjunction with the existing "Deaf" restriction.  Previously, the wearer would be able to hear chat from their owner, even if the "Deaf" restriction were enabled.  In 1.1, when the new "OwnerDeaf" restriction is enabled, then enabling the "Deaf" restriction will also prevent the wearer from seeing their owner's chat.

Finally, the LED on the opposite side of the headset to the microphone is now functional, and indicates the deafness restrictions in effect: green if just "Deaf" is enabled, and red if both "Deaf" and "OwnerDeaf" are enabled.

Enforcer 1.1

Delayed events

The main enhancement in 1.1 is the ability to schedule events to run after a delay, either from the menu or via the new !eventin command.  !eventin works just like the existing !event command, except that it has an additional first parameter which specifies an interval to wait before running the event.  So to run an event called "Test" for me, presetting a variable called "answer" to 42, I might use the following !event command, 

!event Test::Nue Broome::answer=42

And if I wanted to run that same event in 30 seconds from now, I'd instead use:

!eventin 30s::Test::Nue Broome::answer=42

The first parameter to !eventin, in this case the string "30s", is an example of an interval.  An interval is simply a string that represents a length of time.  It's composed of alternating numbers and letters, specifying the duration in seconds, minutes, hours, days and/or weeks.  Some examples should make it obvious:

Interval	Meaning
30s	30 seconds
1m	1 minute
1m30s	1 minute and 30 seconds, or 90 seconds
1h30m	An hour and a half, or 90 minutes
3d	3 days
1w2d21h3m2s	1 week, 2 days, 21 hours, 3 minutes and 2 seconds

The different units can be given in any order (so "1h30m" could be given as "30m1h"), and spaces are allowed between the numbers and letters (but not between the digits of a number).

There are already some operators that deal with intervals in expressions, so they're not a new concept, although the syntax has been tightened up a little.

Delayed events are in general preferable to the use of the !delay command for any significant delay.   If you want to have a pause of a second or two between issuing Mesmerizer commands, !delay is appropriate.  But if you wanted to wait for, say, 10 minutes before doing something, then doing that something in a delayed event is a much better choice.  This is because an event executing a !delay is still active and consuming resources even while it's waiting.  It's much better to schedule a new event after a delay, as that won't use any resources until it fires.

External Controllers

The Enforcer's main menu has been rearranged a little to make room for the second new feature: External Controllers.  I mentioned these in a previous post, but the idea is to permit other devices to be connected to The Enforcer in a way that allows those devices to create events and/or issue Mesmerizer commands.  

The immediate reason for wanting to do this is to allow for the creation of an external scheduler that can create events at specific calendar times.  This is very different to the delayed events above in that delayed events are mostly intended to be kicked off from within other events, and are therefore delayed with respect to the parent event, whereas scheduled events will run at specified times, regardless of anything else that might be running.  Scheduled events may also be set to repeat automatically. 

While the CHAOS Scheduler is a (near) future product, the ability to connect such a device as an external controller is in The Enforcer 1.1.  In order that this feature actually does something before the Scheduler is available, I've included a simple controller "button" that will let you fire events within The Enforcer at the click of a mouse.  To set it up, rez the button, edit it to set its name to something meaningful, and set the description field to a string of the form "Event-name:Avatar-name", and then switch to the "content" tab and press "Reset Scripts" to make the button pick up the changes.  The button should display green hovertext giving its name, and also its status, which should be "INACTIVE" after the script reset.  Click the button to make it "AVAILABLE" so that The Enforcer can see it.

Then in The Enforcer's menu, press the "Cntrllers..." button and choose "Find New...".  After a few seconds you should be presented with a menu listing the controllers found in the sim, which should include the new button.  Choose this to connect the button to The Enforcer.   Once connected, the button hovertext should disappear after a few seconds, and each time you click on the button, your specified event should fire within The Enforcer. 

For instance, if you set the Description field of the button to "Test:Nue Broome", then each press of the button would cause an event called "Test" to run on my behalf.  You can omit the avatar-name field ("Test") or leave it blank ("Test:") if you don't want The Enforcer to look for avatar-specific notecards to handle the event.

By default, only the owner of the button can click it.  You can change this by prefixing the description field with "*>" to mean everyone, "&>" to mean anyone in the same group as the button, or an avatar legacy name followed by a ">" to mean just that avatar.  So if I changed the description above to "Susan Calvin>Test:Nue Broome", then only Susan Calvin could operate the button (although when she clicks it, it will run the event for me).

While originally intended as a demonstration of an external controller, the button does allow the triggering (from anywhere in the sim) of complex programs to be run in The Enforcer.  I can imagine quite a few uses for this functionality.

Bugfix

The Enforcer 1.1 also addresses a bug in the initialization of namespaces by the Event menu command, so it's well worth picking up, even if the new features aren't of interest.  This bug is a major reason for releasing The Enforcer 1.1 now, rather than waiting for the release of the Scheduler, which was my original intent.

Upgrading

The process for upgrading The Enforcer is a little complex, due to the user-installed Notecards in The Enforcer.  Future versions of The Enforcer will simplify this process.  For now, the procedure described below is the best way to perform an update.

1. Create a folder in your avatar inventory to use as a temporary storage for notecards.
2. Right-click your existing (running) Enforcer, and edit it.   Switch to the "Content" tab.
3. Select all the notecards in the Content tab, and drag them into the inventory folder you created in step 1.  Close the edit window.
4. Rez a copy of the new Enforcer.
5. Right-click the new Enforcer and change its name to something meaningful.  This will help if you need more than one Enforcer in the future.  If you renamed your original Enforcer, then you can give the new one the same name.
6. Switch to the Content tab in the new Enforcer 
7. Drag the notecards you saved in step 3 from your inventory into the new Enforcer's Content tab.  Close the edit window.
8. Use the new Enforcer's menu to connect it to your Hub(s).  As each Hub is connected to the new Enforcer, you can disconnect that Hub from the original Enforcer.
9. Once all the Hubs have been moved over to the new Enforcer, you can take the old one back into inventory.