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.