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.
