Communications Hub release

The new 0.8 Communications Hub release is in the vendors now, and will be on MP soon.  This version addresses a number of shortcomings in the beta version, particularly around sim restart.  The release version includes both the regular and low-prim versions of the Communications Hub, and each version is copiable (but no-transfer).  As a result, the price has increased from L$399 to L$499.

As promised though, purchasers of either of the original beta versions of the Hub can get a free upgrade.  I will be sending out a transferable gift-card to every purchaser of the original beta Communications Hub, entitling them to a free release version.  If, when you receive your gift-card, you've already bought a new Hub, you can IM me to exchange the gift-card for a refund of your purchase price.  But please don't send me the gift-card until I ask for it.

From the "0.8" designation, you can infer that I'm not completely satisfied that this is final release quality.  In particular, the Web Interface is still a little clunky, and while it works, it's not particularly elegant.  I do intend to rewrite it to make it a little more pleasant to use.  However, there are enough important fixes to make it worth releasing an update, and this is a perfect time to make it copiable too.  Having it copiable not only protects against SL eating or otherwise damaging your Hub;  it also makes it practical to divide a large community of subs into sub-groups, each with its own Hub.  If you do that, you might well consider using The Enforcer to bridge your sub-groups so that they can share both Mesmerizer chat and programming.

3.3 Update to Stasis Tube

I just released an update to the Repository Stasis Tube.  This fixes an issue where users of the RLV relay in the Peanut collar weren't properly locked-down after a relog.

You can get the updated version by asking for a redelivery from any of my vendors, which are listed here.

Roadmap for the rest of 2019

I've focused a lot on the Mesmerizer over the last year, which makes sense as it's the core product in the CHAOS range.  However, the other CHAOS products need some attention too.  So while I have a plan for Mesmerizer 1.4, I think I'll focus on updates to the supporting products for a while.

Most in need of an update are the Communications Hubs.  I've made a number of reliability enhancements to my own Hubs, and publication of those enhancements is long overdue.   As I did with the release version of the Mesmerizer, I will be changing the Communications Hubs from being transferable to being copiable.  This both protects against SL eating your Hub, and makes updates pretty trivial - you just get a redelivery, and then transfer your Users database from your old Hub to your new one.  Your users will have to re-connect to the new Hub after this, to actually move to the new Hub, but you can leave the original Hub running until they have all migrated.  As an alternative, I intend to support in-place upgrades, which will avoid the need for users to migrate - you'll simply shut down your existing Hub, update it, and then restart it.  Which method is easiest really depends on how many users are registered with the Hub - for a small user community, the straight replacement method is simple enough;  if you have a large number of users, the requirement that they must all re-connect to a new Hub might argue for doing an in-place update.

I expect I will implement the change in protection using the same method as I used with the Mesmerizer:  I'll give purchasers of the pre-release Hub a transferable gift card for the (copiable) product version of the Hub.  So if you bought a hub and gave it to someone else, you can give the gift card to that same person to let them update to the full product version.  Or if you prefer you can use the gift-card to buy your own Hub (but then whoever you gave your original Hub to will have to buy again if they want an update).

As part of this update, I will also be combining the low-prim and the regular version of the Hubs into a single product.  So whichever flavor of Hub you originally bought, the update will give you both flavors.   The low-prim and regular Hubs are functionally equivalent, the only differences are cosmetic (and of course that the low-prim version is only 1 LI).

I have made some reliability enhancements to The Enforcer too.  There are a few minor functional enhancements as well, but the main change is to do with better memory utilization.  I've been using The Enforcer quite a bit, and the current version is much more efficient and better able to handle multiple simultaneous subscribers that the original beta version could.   Again, I need to get these enhancements out as a proper release product.

Incidentally, if anyone has been experiencing reliability issues with their Communications Hubs or Enforcers, I will happily give you the latest pre-release version to see if that solves whatever issues you're seeing.

Finally, the HoloTrainer and MesmerX need to become copiable too.   I haven't made any functional changes to these products, but something I do want to do is to unify the scripting languages that are used in these devices with the Mesmerizer's own scripting.  Ideally you should be able to take a script from, say, a MesmerX, and just install it into a Mesmerizer (after renaming the notecard according to the Mesmerizer's convention).  Today, that won't work at all, but it's a worthy goal to aim for.

So that's my goal for the remainder of 2019:  to bring these beta-level products up to full release level.  I may find diversions along the way, but if I do, I hope that this blog post will help to ensure that they don't take me too far off course.

Announcing Mesmerizer 1.3

Mesmerizer version 1.3 is going live as I type.  It'll be in vendors tonight, and on MP by tomorrow.  If you own a previous version, you can get 1.3 by requesting a redelivery from any of my vendors, or indeed any CasperVend vendor.

Mesmerizer 1.3 is a small but worthwhile release.  Details of the new features are given in my previous post. Precision stripping alone is worth the upgrade, and I find myself using the improved help feature all the time.

Instructions on how to upgrade from a previous Mesmerizer can be found via one of the links on the sidebar to the right.

Mesmerizer 1.3 preview

Another Mesmerizer release so soon after 1.2?   So far, I'm expecting this to be a pretty small update, so yes, it may well be quick.  Currently there are only four features committed:  access groups, improvements to the Help command, precision stripping, and the ability to organize peanut-style outfits into sub-folders.

Access Groups

Currently, you can create triggers that will respond to a specific individual (usually the person creating the trigger, but it can also be a specified other speaker, or the Mesmerizer wearer), or to anyone.  This is flexible enough for most common use cases.   However, there are some situations where you'd like to create a trigger that can be used by any of a several people, but you don't want to open the trigger to the world.  Currently the only way to do this is to create multiple copies of the trigger, one copy for each individual you want to be able to use it.  This rapidly becomes unmanageable for more than a few users and triggers, and the resultant large number of triggers will slow down the Mesmerizer's processing of all triggers.  Access Groups are an attempt to solve this problem.

An Access Group is simply a group of users that the Mesmerizer maintains.  The group has a key, and that key can specified in a trigger definition, instead of a user key, to allow any member of the group to use the trigger.  The initial implementation adds the following commands:

Command	Description	Example
agcreate <p1>	Create access group <p1>	agcreate mytrainers
agcreate2 <p1> <p2>	Create access group <p1> with key <p2>	agcreate2 mytrainers 6ac58587-8609-6142-41c4-15f6049cc032
aglist <p1>	Display access group <p1>.  Specify a group "*" to get a list of all the access groups.	aglist mytrainers
agdelete <p1>	Delete access group <p1>	agdelete mytrainers
agadd <p1> <p2>	Add user key(s) <p2> to access group <p1>	agadd mytrainers 7f1cfe79-71ae-4855-b766-754ec2e38bd7
agrem <p1> <p2>	Remove user key(s) <p2> from access group <p1>	agrem mytrainers 7f1cfe79-71ae-4855-b766-754ec2e38bd7
agset <p1> <p2>	Set the contents of access group <p1> to the user key(s) <p2>	agset mytrainers 7f1cfe79-71ae-4855-b766-754ec2e38bd7

Once a group is defined and populated by the above commands, it can be used by giving its key in a trigger specification.  For example, if the group mytrainers has a key of 6ac58587-8609-6142-41c4-15f6049cc032, then I can define a freeze trigger than any member of the mytrainers group can use as follows:

freeze = 6ac58587-8609-6142-41c4-15f6049cc032 play "Attention"

At the moment, users have to be named in the agadd, agrem and agset commands by giving their keys. Access group keys are used in trigger specifications, and the key of an access group can be found via the aglist command.  I will consider permitting users and access groups to be specified by name as an alternative to by key, but that will probably not be in the initial version.  If I do add it in the future, the current syntax will continue to work, and will likely be used by backup, since keys are unambiguous, whereas usernames and group names may collide.

Improved Help

Today's help command dumps the entire list of Mesmerizer commands to local, along with a brief description of each.  While some sort of help is essential, I usually have a good idea of the command I'm looking for, and it's annoying to have to sift through over 200 commands to locate the one or two I want help with.  So the help command will change so that it takes an optional parameter - the command that you want help with.  So help by itself will work just as it does today and display a list of all supported commands, but you can do help aglist to get just the help on that one command, or help ag to get help on all commands that start with "ag".

Precision Attachment Stripping

Stripping of attachments via RLV has always been a rather hit and miss affair, and this situation has been made far worse by rigged mesh.  In fact I wrote a post about this back in 2015, here.  A year after that post, the Lindens provided a way for scripts to find out what attachments are worn, and at roughly the same time, Marine added a feature to RLV (which had been in RLVa for a while) to remove attachments by key (rather than by attachment point).  Together, these two features allow for predictable removal of attachments.  To support this, the Mesmerizer's getattachments command has been changed so that instead of returning just a list of the occupied attachment points, it returns the names of every attached object along with where it's attached.  Similar to the listoutfits command, getattachments will also set a variable called attachments to a list of the keys of the worn attachments.  And the remattachment command can now accept a key as an alternative to a attachment point name.  So, if I were to issue a /99getattachments command, I might get something like the following:

[2019/06/08 20:33]  Nue's Mesmerizer v1.3.1.3 (L): 1: //Ascend// Anton Leather Jacket / Black - Belleza [chest]
 2: -Belleza- Shea Black Shoes [left foot]
 3: VAW XTC cock V3.1 [pelvis]
 4: Nicholas - Eclipse [skull]
 5: //Ascend// Anton Shirt - Belleza [r upper leg]
 6: [MC] ROGUE PANTS JAKE [stomach]
 7: //Ascend// Anton Tie - Belleza [neck]
 8: Polina's Silver & Amber Leashing Ring [left ring finger]
 9: -Belleza- Jake 2.0 Bento [root]

Yes, I was surprised to see that I'm wearing my shirt on my upper leg too.  That proves my point about attachment positions often being unpredictable.  But let's say I wanted to have the Mesmerizer remove that shirt.  I can see now that it's on the "r upper leg" point, so I could detach it with a remattachment "r upper leg" command.  But if I happened to be wearing something else on that same point as well, then both items would be removed.  However, I can remove just the shirt by saying remattachment "$attachments.5".  The getattachments command sets the variable attachments to a list of the attachment keys, in the same order as they are displayed, and the .5 syntax above means "the 5th element of the list".  The list positions are shown in the display.

This makes stripping both simple and predictable, and doesn't require that the wearer do any special setup or follow conventions for where they wear various clothing items, which was the best solution previously.

Nested Outfit Folders

I added support for Peanut-style outfits in 1.2, to complement the Open Collar outfits support that appeared in version 1.1.  My implementation of Peanut outfits was limited to a single level of folders, immediately beneath the #RLV / Outfits folder; deeper folders were not supported.  This restriction mirrored that of Peanut itself, and in everyday use I've found it to be quite limiting.  I had assumed that Peanut imposed the restriction for implementation simplicity, but more recent versions of the Peanut collar have imposed similar restrictions elsewhere in the #RLV folder, and it appears to be a deliberate decision, aimed perhaps at forcing the sub to limit what they put in their #RLV shared folder.  While I've seen a few shared folders that could benefit from some forced discipline like this, I don't feel that it's the business of a collar (or the Mesmerizer) to dictate how one should arrange their inventory any more than is necessary.  As I said above, in everyday use, I've found the lack of subfolders in outfits to be limiting.  I would very much like to be able to have my subs' outfits at least divided into categories such as "dresses", "lingerie" etc.

Why consider adding nested folders to Peanut outfits when I already have OpenCollar outfits that support nesting?  Well, to make them work in a general fashion, Open Collar outfits (with the Mesmerizer extensions) are pretty complicated to set up.  This is largely to support things like the use of different mesh bodies for different outfits.  Peanut outfits make a few simplifying assumptions that make them much easier to create, one of which is that there's a single .basics folder that contains everything for the 'base' avatar.  Also, there's the assumption that if a hair is contained in an outfit, then it will knock off a hair that was added by the nothing outfit or the .basics folder - in other words that all hair is worn on the same attachment point (usually the skull point).  As far as I can see, this isn't mentioned in the Peanut documentation for Outfits, but it's necessary if you want to have a default hair overridden in certain outfits.

With these simplifying assumptions (none of which feel unreasonably restrictive to me), the Peanut folders are very easy to set up, and switching outfits with them is much faster than with Open Collar outfits.  Fortunately, the absence of nesting isn't one of those simplifying assumptions, so I can easily add it and still retain all the advantages of the Peanut mechanism.

In the initial implementation, I will support locating the .basics and nothing folders only at the top level of the hierarchy (i.e. immediately inside the Outfits folder, where they are today).  This is a very straightforward extension to the current Peanut layout - simply allowing for the outfits themselves to use subfolders for organization.  In the future, I might allow for .basics and nothing to be located elsewhere in the hierarchy, which will bring the capabilities close to those of Open Collar outfits, without adding significant complexity.  Any such extension will remain backwards compatible with a Peanut folder layout, so if you wear a Peanut collar and want to use its outfit manager too, you'll simply not take advantage of the Mesmerizer extensions.


Version 1.3 is in pre-release testing at the moment.  I expect to release it around the end of June, unless significant bugs crop up.  If anyone would like a pre-release version, send me an IM in-world.

Announcing Mesmerizer 1.2

Mesmerizer Version 1.2 is in the vendors, and will soon be up on Marketplace too.  To get your update, visit my vendor at Sleepy Hill and ask for a redelivery.  You can actually use any CasperVend terminal, but if you use mine, then purchases from my store will be easy to find at the top of the page.

As described earlier, 1.2 has many new features:

• An internal RLV relay.
• Support for "Peanut" outfits, in addition to the OpenCollar outfits added in 1.1.
• Support for the OpenCollar authorization API.
• Simplified access to Mesmerizer chat.
• Improvements to leashing behavior.
• Support for the new titler add-on.
• Various minor bugfixes.

The CHAOS Titler and the "Wearer HUD" mentioned in previous posts will be available in the vendors shortly, as a free "Add-on pack".   In addition to being able to issue Mesmerizer self-triggers, the Wearer HUD can be programmed to issue RLV commands directly, so it would be easy to use it to create, for example, a pair of menu items to lock or unlock your hair, or mesh body, to prevent them from being knocked off by accident.  Once the Wearer HUD is released, I will make a post here that discusses how to do things like that.

After the free "Mesmerizer add-on pack" is out, I have a new version of the Owner HUD that I should publish, as it has some significant bugfixes.  I also intend to release updated versions of the Communications Hubs and The Enforcer.  There's no functional change to either, but there are some bug-fixes I want to get out.

Looking forward, my plans for the next release of the Mesmerizer include:

• support for a new version of the AutoInstaller that will make it easy to keep the Mesmerizer and AutoInstaller in sync with one another
• restructuring of custom animations to make it easier to install new animations
• rewrite of how synchronous commands are implemented.  The current implementation has some mostly theoretical but occasionally significant flaws.

More on Mesmerizer 1.2

Virtual Disgrace makes a very nice blindfold, along with a reasonably standard gag.  Both products are very low in resource utilization, in part because they are designed to off-load everything to do with authorization and owner-lists etc. to OpenCollar, using a remote authorization API that's implemented by OpenCollar 6, OpenCollar 7 and Peanut.  As of version 1.2, the Mesmerizer also implements this API, meaning that third-party products (like the Virtual Disgrace blindfold and gag) that rely on this API (and therefore previously required the presence of one of the above flavors of OpenCollar) can now work with just a Mesmerizer.

By default, this OpenCollar authorization emulation is disabled, but it can be turned on via the new ocauth command, and off again via the noocauth command.  This is a persistent command - once turned on it remains on across relogs.  When the Mesmerizer is the authorization provider for these third-party products, only Mesmerizer owners are granted access;  the Mesmerizer doesn't have the equivalent of OpenCollar's "open" mode that would give non-owners access.

Another feature that I'm still working on for version 1.2 is support of Peanut-style outfits.  In version 1.1, the Mesmerizer added support for OpenCollar outfits, with some extensions to avoid some of the issues with the OpenCollar outfit framework.  These extensions were backwards-compatible with OpenCollar - in other words, if you set your inventory up to play well with OpenCollar, then the Mesmerizer would offer similar functionality to OpenCollar;  however if you added structure to your inventory that took advantage of the Mesmerizer extensions, then OpenCollar might not understand them.  Peanut addressed the deficiencies in the OpenCollar outfits in a different way - by removing the problematic functionality in the original OpenCollar outfits and mandating a much simpler (albeit less flexible) folder structure.  Fortunately, Peanut and OpenCollar outfits use different top-level inventory folders for the root of their respective outfits - Peanut uses "Outfits", while OpenCollar uses ".outfits" (with a leading period in the name) - so the Mesmerizer can provide a unified view of outfits, whether they're defined using the Peanut or OpenCollar structures (or even both).

The 1.1 outfit commands (listoutfits and wearoutfit) have been extended to support outfits defined under either style.  If your inventory contains both types of outfit definition (in other words, you have both #RLV/outfits and #RLV/.outfits folders) there will be a conflict if you have duplicate outfit names in the two structures; if you do, then the Mesmerizer will use the Peanut-style outfit and the OpenCollar outfit definition will not be accessible.  This conflict is unlikely to occur in practice, since OpenCollar outfits tend to use a hierarchy (e.g. outfits called something like /formal/ball-gown), whereas Peanut outfits are all top-level ones (e.g. /ball-gown), and a conflict will only occur if the full paths match (e.g. in the above example a Peanut outfit called /formal would conflict with the top-level OpenCollar folder /formal). Since Peanut outfits don't support subfolders, having to specify a folder argument to the listoutfits command is rather superfluous, so Mesmerizer 1.2 will add a new outfits command which is a synonym for 'listoutfits "/"'. 

The upshot of this is that the Mesmerizer should be able to use either OpenCollar or Peanut outfits, in the same way that each of those collars do (with the additional flexibility offered by the Mesmerizer's extensions to OpenCollar outfits, should you choose to take advantage of those extensions).  Being much simpler, changing into a Peanut-style outfit is somewhat faster than a typical OpenCollar outfit, so if you don't need the flexibility of OpenCollar outfits, and you don't have a huge number of outfits that you want to make available to an owner, then you should probably use Peanut-style outfits.

Note that there appears to be nothing in the design of Peanut-style outfits that would prohibit using a  hierarchy for organizing folders - the non-support of subfolders seems simply to be an implementation decision of Peanut, perhaps in order to simplify menu-based navigation. A future release of the Mesmerizer might lift this restriction and permit hierarchical Peanut folders, in which case the only difference between Peanut and OpenCollar outfits would be that they have different root folders under #RLV, and that the core or basics are handled differently.

The whole topic of outfits and how to set them up under #RLV probably warrants a post of its own.