Owner HUD 1.3 preview

The next version of the Owner HUD adds support for the swap command, and also provides two ways to teleport your sub(s) with you - a feature I will refer to as "Companion Teleport".

Swap 

The swap command, introduced in Mesmerizer 1.7.3, is intended to allow you to easily swap between similar items that the sub is wearing - for example to swap her current hair for a different one.  As the goal of the command is to simplify doing this, it made sense for the feature to be provided via the Owner HUD, where it is even simpler to use.  There is a new button labelled "Swap" in the "Dress" page of the HUD, which prompts you first for the Base folder (the folder below which all items will be detached/unworn) and then for the folder to add instead.  

Companion Teleport

When teleporting around SL, I often wish to bring a sub along with me.  To do this prior to this release of the Owner HUD, I either had to wear a Mesmerizer myself and manually issue a tpto command to teleport us both together, or go ahead by myself and then send for the sub.  Companion teleport provides a more automated way to travel with a sub.  In fact, it provides two distinct ways, called "TP Self" and "Follow".  The two methods are enabled or disabled via a new "TP Prefs" choice in the HUD's main menu (the one you get by clicking the 3-bars menu icon). 

"Follow" teleport provides a simple way to have your sub follow along with you as you TP around.  If follow-teleport is enabled, then each time you teleport, a menu will appear to allow you to send a command to your sub(s) to teleport to your current location.  The menu is there to give you time to activate the communicator(s) that will connect the HUD to your subs' Mesmerizers, and also allows you to cancel the command if you didn't mean your sub to accompany you this time.  There is also an option on the menu to disable Follow teleport, so that you don't get bothered by future menus.

"TP Self" teleport will automatically teleport you whenever you use the HUD to send your sub a location.  This lets you teleport together just by dropping a landmark onto the HUD.  If you don't have RLV enabled, then when you turn on follow-teleport, you will be prompted to allow the HUD to teleport you.

Mesmerizer 1.7.4 preview

Continuing my recent focus on use of the #RLV folder, Mesmerizer 1.7.4 adds support for "large" folders, as well as a fix for an issue with synchronous commands that's been bugging me for a while.

Large #RLV folders

Any RLV operation that returns data is limited to a message size of less than 1024 bytes.  Currently no RLV operation can return more than one message. This means that the total size of any data returned from an RLV operation has to be less that 1024 bytes.  For most operations, this isn't an issue.  However, it does become a problem when listing the contents of a folder beneath #RLV.  It is quite easy to create enough sub-folders to make the return data exceed that amount, in which case the data will be truncated.

When Mesmerizer 1.7.4 encounters a folder listing from RLV that approaches this limit, it will warn both the wearer and the requestor.  This warning also includes a suggestion to the wearer on how to fix the problem.   Assume that you asked to see the folders inside #RLV/Hair/Blonde, and that request resulted in the warning message indicating that the folder may be too large.  The way to address this is to create a new subfolder inside #RLV/Hair/Blonde called "~More" (with the leading tilde), and to move a few subfolders from #RLV/Hair/Blonde into the new folder.  The Mesmerizer will recognize the "~More" folder and will add the contents of that folder to the listing it's creating. If necessary, #RLV/Hair/Blonde/~More may itself be extended by adding a ~More folder inside it, and storing additional "overflow" subfolders in #RLV/Hair/Blonde/~More/~More.

Mesmerizer 1.7.4 limits its understanding of ~More folders to listing, but that understanding applies to both outfits and regular folders, so both getinv and listoutfits support it.  A future release will likely make these overflow folders more transparent in use (although they will always have to be set up manually by the wearer), but I wanted to get this initial level of support out as soon as possible, so for now the dominant will have to take note of whether an item to be worn is in the base folder or one of the associated ~More folders.  In playing with this feature myself, it hasn't been that complicated to use.

Synchronous commands

Most Mesmerizer commands operate asynchronously - in other words the command starts an operation but doesn't wait for it to complete before moving on to the next command.  The operations started by most commands are either quick (e.g. setting a restriction) or are intended to continue until stopped (e.g. follow).   However, a few commands operate synchronously, meaning that the operation has to complete before the next command is executes.  The moveto command is a good example.  This command is designed so that it can be paired with something like a sit command, so that the sequence moveto chair sit chair will cause the target avatar to walk over to the selected chair, and then sit on it.  For this to work, the moveto command has to operate synchronously - no subsequent commands are processed until the moveto indicates that it's finished, which it does when the avatar is close to the target.

There's a problem with this, though.  If some object is blocking the avatar's path to the target object, then they will continue trying to walk through the object indefinitely.   It was to provide a fix for this that I introduced the continue command, which effectively signals a command completion and allows subsequent commands to be executed.  Continue is special in that the command interpreter will look ahead to see if a continue command is pending and if so, will execute it immediately.  Note that continue doesn't actually cancel the command that was running - it just lets the command interpreter move on to the next command - but in the case of moveto an object followed by a sit on the same object, the act of sitting will bring the avatar to the target object which will cause the moveto to complete.

continue was always intended to be a stop-gap - a quick manual fix for an avatar that has gotten "stuck" like this.  The proper fix would be to add a timeout to every synchronous command, so that if it didn't complete within a specified time, the command would give up.  While that's still the correct long-term approach, in Mesmerizer 1.7.4 I'm introducing another partial fix, this time one that can be used sensibly in scripts (or trigger actions or macros) as a preventative measure - the continuein command.  continuein is very simple - all it does is automatically issue a continue after a specified delay.  It's intended to be used prior to a sequence like the above.  So instead of:

moveto chair sit chair

you'd write:

continuein "10.0" moveto chair continuein "0.0" sit chair

What this does is allow the moveto chair command ten seconds to complete, after which command processing will resume.  So if the avatar got stuck on their way to the chair, after ten seconds of trying they'd be force-sat there anyway.

The second continuein "0.0" cancels any pending continuein after a successful completion of the moveto command. It's usually not strictly necessary to do this, since most commands are asynchronous and executing a continue only has an effect if a synchronous command is running.

Outfit enhancements and supporting multiple bodies

Some people use multiple bodies, switching between them according to the outfit they want to wear.  I expect this to become significantly more common now that Maitreya includes LaraX with their original Lara body, and many clothes vendors are choosing to support only one of these bodies on the reasonable assumption that if you have one, then you also have the other. 

The current Outfits support assumes that you have a base avatar (defined in the core or .basics folders) that is used with each outfit.  While OC-style outfits have supported multiple core folders for a while, P9 outfits only support a single .basics folder, which means that all Mesmerizer P9 outfits need to use the same base body.

This may also be an appropriate time to add support for the "final" Peanut-style outfits, which were carried forward into the No9 collar, and which will be referred to here as "No9 outfits".   Currently the Mesmerizer supports both Open Collar and the original Peanut layouts for outfits.  About half-way through its life, the Peanut collar introduced the No9 layout that the Mesmerizer doesn't currently offer support for.  The good thing about the new layout is that it inherently supports including the body with the outfit.  It's also much easier to set up than either OC or the original Peanut layout.  The bad thing is that it doesn't make it easy to make a "global" change (e.g. change the skin worn by a body across all outfits).  Luckily, the format in use can be determined by looking at the #RLV folder layout, so it's quite possible to support any or all of these formats without requiring any sort of manual switching.  

Like the existing OC and P9 outfits, a No 9 outfit is a folder in inventory located within the #RLV folder.  Whereas OC outfits are beneath #RLV/.Outfits and P9 outfits are beneath #RLV/Outfits, No9 outfits live under #RLV/> Outfits (that's a ">" symbol, followed by a space, followed by "Outfits").  Like with OC and P9, you can use subfolders beneath #RLV/> Outfits to help organize your No9 outfits, even though the No9 Collar doesn't support this.  The overflow folders described above also work with No9 outfits, as do images.

The actual outfit folder for a No9 outfit is very simple:  It's exactly what the viewer's Outfits look like.  In fact, that's the recommended way to create a No9 outfit - use the viewer's Appearance popup window to save what you're currently wearing as an outfit, and then in the Inventory window, drag the newly created outfit folder from beneath the system Outfits folder to a place beneath #RLV/> Outfits.  And that's it.

Allowing outfits to specify which body to use is high on my priority list.  I don't think that adding that feature to P9 outfits will be ready in time for 1.7.4, but if not, it will be in the next release after that.  Regardless, Mesmerizer 1.7.4 will include the new support for No9 outfits, which inherently supports switching bodies.

Wrap-up

In addition to the above new features, there are some miscellaneous bugfixes and performance improvements.  There is a fair amount in this new version (even without multi-body P9 outfits), but I expect it to be available within the next few weeks, unless final testing uncovers a problem.

Mesmerizer 1.7.3a

 A bugfix-only release, hence I'm only adding an "a" suffix to the version number, since there is no functional change. This version fixes a bug that could cause messages to the owner to be randomly dropped.  It was most obvious when listing large #RLV folders.

The update is up on Marketplace, and in vendors (see stickies on the right for locations), so you can get it by just asking for a redelivery.

Mesmerizer 1.7.3 released

 Mesmerizer version 1.7.3 is up in vendors and on MP - for once Marketplace didn't lag behind the vendors.  A description of the new features is found in the previous post.  As always, you can get the new version via a redelivery from any of my vendors (links in one of the stickies to the right).

One feature I had hoped to get into this release but had to push out was to bring the image handling of Mesmerizer trance scripts up to parity with TranceCaster scripts. That will be high on my list for the next version.

Mesmerizer 1.7.3 Preview

 First, a confession - in adding the new lookat/lockat commands in 1.7.2, I broke the mouselook command.  That's working again in the upcoming version 1.7.3.  Another fix is that I've refactored the outfit handling code so that it can handle much larger folders under #RLV.  I've been making a lot of use lately of outfits and other #RLV things, and 1.7.3 builds on this with a new swap command. 

The Swap command

swap is intended to be used to swap one worn object for another object of the same type, for instance swapping one hair for another.  To use it, you have to arrange the folders under #RLV so that objects of a given type all are beneath a single directory.  So you might have a folder immediately under #RLV called "Hair", and beneath that perhaps "Blonde" and "Brunette" subfolders, and then individual folders beneath those containing the actual hairs.

Let's say the sub is wearing a blonde hair called Agnetha, stored in #RLV/Hair/Blonde/Agnetha, and you decide she'd look better as a brunette, so you'd like to swap her hair for the one in #RLV/Hair/Brunette/Anni-Frid.   The new swap feature lets you do that in a single command:

swap "/Hair" "Brunette/Anni-Frid"

What this does is first remove anything the sub might be wearing from folders beneath the first parameter (#RLV/Hair in this case) and then wear the contents of the folder specified in the second parameter.  If the second parameter is a relative path (i.e. it doesn't start with either a dot or a slash), then it's treated as relative to the first parameter, so the full path of the folder named above is #RLV/Hair/Brunette/Anni-Frid.  You can also use an absolute path (starting with a slash character) in which case the folder you're adding can be anywhere inside the sub's shared folders, and doesn't have to be below #RLV/Hair, or a path rooted at "." which means the current default folder.  So if you've just used getinv to examine the sub's #RLV/Hair/Brunette folder, you could simply say:

swap "/Hair" "./Anni-Frid"

To work well with outfits, any hairs contained in individual outfits (or in the .basics or .core folders) should be links, with the actual hairs living beneath #RLV/Hair, otherwise the swap command won't recognize them as hairs, and so won't remove them.  I think that's generally good practice - that outfits shouldn't contain actual "things" but instead should consist of links to things stored elsewhere.

Avatar Radar

Firestorm's radar will alert you when avatars come and go in your vicinity.  Mesmerizer 1.7.3 adds a somewhat similar capability to the Mesmerizer.  This is done through four commands:  radar, radaradd, radarrem, and radarlist.  The radar command can take a parameter of either on or off to enable or disable the radar, or can take a float to set the range over which it should scan.  To minimize the number of unwanted events generated, you must specify individual avatars to scan for via radaradd and radarrem, which add and remove one or more avatars to be scanned for, while radarlist simply shows the currently defined targets and other radar settings.  If there are no targets specified, no events will be generated.  It is also significantly more efficient to scan for a single avatar than for multiples.

When one (or more) of the targets enters or leave the scan range, an on-radar event will be generated.  The variable $radar will be set to a list of the usernames of target avatars that are within the scan range.  It is done this way rather than specifying which avatar(s) have entered or left because the $radar variable can be updated at any time, and in a laggy but heavily-populated sim, multiple events may be raised.  If $radar were to contain just the changes to the nearby targets, it's possible that it would be overwritten by a later scan before an earlier event has a chance to be processed, possibly resulting in missed targets.  Having $radar always contain the current targets within range allows these avatars to be read at any time (even outside of the on-radar event) without introducing any race condition.

Radar settings will be preserved across a logout.  This means that, if the sub was near one of their radar targets when they logged out, it is likely that they will receive an on-radar event when they log in next to indicate that the target is no longer nearby.

Mesmerizer 1.7.2

 Mesmerizer 1.7.2 is up in vendors, and will soon be on MP as well.  As announced previously, this is primarily a bugfix release, addressing some issues that were uncovered by the recent support for #RLV images, as well as some significant refactoring of the code to better support large #RLV folders.  There is also a bugfix to the RLV relay, and a change to the lookat commands to automatically unlock the camera when the avatar moves, with the original behavior now being implemented in the parallel lockat commands.

As always, you can get the update by requesting a redelivery from any of my vendors (see stickies to the right for locations), or indeed from any CasperVend vendor, regardless of whether you originally purchased your Mesmerier from a vendor or from Marketplace.   Once the update is up on MP, you will be able to get a redelivery there too.

Mesmerizer 1.7.2 preview

Bugfixes

 Another pending Mesmerizer release, nipping at the heels of 1.7.1, this version fixes a couple of bugs relating the new support for images in the #RLV folder.   The first was that numbering of outfits and folders was messed up in the outputs of various #RLV list/find commands.  This bug was introduced in 1.7.1, when I switched to sorting the returned folders alphabetically.  The second bug was that long responses to these commands could get truncated.  The presence of image keys in the #RLV folder means that longer responses are likely to occur more often, which exposed this bug that had been lurking there for a while.  I've also refactored the Mesmerizer's support of the #RLV folder to make more memory available for large subfolders.

In an unrelated change, I also addressed a bug that sometimes caused the RLV relay to miss re-sitting the avatar on login.

New Functionality

As far as new functionality goes, 1.7.2 is fairly limited.  So far, the only change is a slight modification to how the lookat camera control command works.  I often use this command to show a sub something by using the CHAOS Owner HUD to move their camera to see whatever I'm looking at.  If we then walk away, their camera remains steadfastly locked at whatever I was pointing out.  Now, sometimes this might be the desired behavior, but I've found that more often it's simply because I forgot to unlock their camera before we move.

To address this, lookat will now automatically unlock the sub's camera if they move more than a couple of meters from their initial position.  For those who wish to keep the original behavior, there is a new lockat command which behaves exactly as lookat used to.  The same change has been made to the lookat2 variant - that will now auto-unlock on avatar movement, while lockat2 preserves the original behavior.

Mesmerizer 1.7.1 and Owner HUD 1.2 release

 The new versions of the CHAOS Mesmerizer (1.7.1) and CHAOS Owner HUD (1.2), as described in the previous post, are in vendors now, and will be available on Marketplace in the next couple of days.  As always, regardless of whether you originally purchased via a vendor or on MP, you can obtain the free update by requesting a redelivery from any of my vendors (listed in the stickies on the right), or indeed any CasperVend vendor.

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.

Mesmerizer 1.7.1 and Owner HUD 1.2 preview

I'll be releasing a relatively minor update to the Mesmerizer in the near future (ideally this weekend), version 1.7.1, along with an accompanying update to the Owner HUD to version 1.2

Bugfix

This release fixes a bug in trance scripts which prevented symbol translation from working.  With the update, you can define a symbol to represent the wearer's name, for instance, with:

setvar subname "Fred"

and then if a trance script contains something like:

Hello $subname

the wearer will see:

"Hello Fred"

This can be useful in creating scripts that can be used with different wearers, just by redefining a few symbols.  This sort of thing might be better suited to TranceCaster scripts rather than Mesmerizer scripts, but it was supposed to work within the Mesmerizer, and now it does.

Apart from that bugfix, I have tinkered with the mouselook command so that instead of putting the wearer's camera in the center of their head, it now just constrains it to being close to their head.  While still not being a true "mouselook" the new behavior is (I think) more useful and less annoying than the original version.

New features

#RLV images

I've started work on a significant enhancement to #RLV use.  One problem with the #RLV folder is that it's often tough for someone accessing it via RLV to figure out what a given folder contains.  RLV only grants visibility to folders (as opposed to the items within those folders), so the usability of the #RLV folder is completely dependent on how well the wearer names the folders beneath #RLV.  This is particularly an issue with outfits, especially if you have a lot of them, as it's often difficult to come up with descriptive names that aren't too long.

Mesmerizer 1.7.1 allows the wearer to insert pictures of their outfits and other items into their #RLV folder, so that their owner can see what each outfit is.

The way to set this up is as follows.  Let's say you have an outfit folder called "Red Ball Gown", and that folder is in #RLV/Outfits/Gowns.  You (or someone else) takes a picture of yourself wearing the "Red Ball Gown" outfit, saving it to inventory.  Choose one of the standard square aspect ratios when taking the picture - don't use a custom size.  Then find the resulting texture in inventory, right-click it, and choose "Copy Asset UUID".  This will put the "key" of the texture into your paste buffer.   If someone else took the photo, they can paste its key into chat or an IM to you, so that you have it.  All you need is the key - you don't need the actual texture.

Once you have the key of the image, go to the folder that contains the outfit folder you want to attach the image to (in this case #RLV/Outfits/Gowns).  Right click the outfit folder itself (Red Ball Gown) and choose "Rename".  Go to the end of the current name, and append a tilde ("~") and then paste the key of the image - so the outfit folder that used to be called "Red Ball Gown" is now called something like 

"Red Ball Gown~a4f8ce15-d1ca-6441-fce2-a547c7a5d97a"

(assuming that the key you got from Copy Asset UUID was "a4f8ce15-d1ca-6441-fce2-a547c7a5d97a")

That's it.  Outfit folders named in the form above will be understood by the Mesmerizer as being the 'real' name of the outfit, followed by a key for an image, and someone using the Mesmerizer to list the contents of the "Gowns" outfit folder will see "Red Ball Gown" outfit folder annotated with a camera icon, and the key "a4f8ce15-d1ca-6441-fce2-a547c7a5d97a".  If they're using the new Owner HUD 1.2, they can use this key to view the image within the HUD, as I've added an image display feature to the HUD. A small button at the bottom left of the opened HUD allows a new panel to be pulled out either to the left or below the main HUD, and clicking on this panel allows you to provide a key, which the panel will then display.

Someone accessing your #RLV folder with a different RLV controller will see the full name, including the tilde and the trailing key, from which they can still obtain the image key, but it's just a bit clumsier than the Mesmerizer's display.  You can put spaces around the tilde if you wish, which may serve to better visually separate the image key from the main part of the name for someone using a non-Mesmerizer RLV controller.

While the feature is intended primarily for outfits, regular #RLV folders may be annotated with images in the same way.  In general, you shouldn't go overboard with images, since adding a key like this significantly increases the size of folder names, and there is a limit to the total number of characters that RLV can handle in its messages.  There is also a limit to the length of each individual folder name (currently 63 characters), and the tilde and key consume 37 characters, leaving only 26 characters for the "real" name.  26 characters should be enough to describe most #RLV subfolders though, and I do have several possible workarounds if you really need to use longer folder names, one of which is the ability to use compressed keys.  This reduces the characters needed to express a key and its leading tilde from 37 to 23, leaving 40 characters for the "real" name.  When viewed via Mesmerizer commands, a folder with an image annotation expressed as a compressed key will be displayed with the key expanded to its full form.  The downside of compressed keys is that someone using a different RLV controller will not easily be able to obtain the actual keys, so they should only be used if absolutely necessary.  The image display feature in CHAOS Owner HUD 1.2 will accept either a compressed key or a "normal" key. Also included with Mesmerizer 1.7.1 is an object that will compress and decompress keys, in versions that which can either be worn as a HUD or rezzed in-world.

I said "started work" above because, while this feature is fully functional in version 1.7.1, I may extend or enhance it based on user experience.  So please let me know if the ability to see pictures of your subs' #RLV contents is useful, and if the experience of setting up or viewing those pictures could be improved.

Local animations

A second enhancement to the Owner HUD in version 1.2 is the ability to animate or pose avatars "locally".  Local animation does not require that the target of the animation be wearing a Mesmerizer, but unlike Mesmerizer animations, which will work grid-wide (if the wearer's Mesmerizer is networked to a Communications Hub that you control), local animations will only work within the sim.  The target of a local animation must grant permission to be animated, but the Owner HUD keeps track of the most recent ten avatars that have been animated and remembers that permission has been granted by those avatars, so they will not have to give it again (unless they fall out of the most recent ten targets).

Local animations require that the animation be loaded into the Owner HUD.  Owner HUD 1.2 comes preloaded with all the animations that are shipped as standard within a Mesmerizer (except for mode animations), and you can easily add your own animations by simply dropping the animation into the HUD.  

TranceCaster update

I just released version 1.0.2 of the CHAOS TranceCaster.  This is a minor update that addresses a performance bug and also adds menu options to see the progress of running trances, and to optionally abort trances.  

There is a new top-level menu item, "Playing", which gives a list of all the sessions that are currently active, where a session is identified by the target name and the original script that was played.  Selecting a session lets you see which script notecard is being run (you can use the "refresh" choice to get an update to allow you to watch the session progress), and you also have "Stop" and "Abort" choices available.  Both of these choices will terminate the session; the difference is that "Abort" will immediately stop the session, while "Stop" will first issue a "wake" command and clear the target's screen. 

You can get the update by requesting a redelivery from any of my vendors (locations in the stickies to the right).  As usual, Marketplace lags a little behind my vendors, but the updated version should be available there soon as well.