This update will include new versions of the Hubs, which have more robust handling of their user databases (in particular the ability to read the user database from a notecard, which makes the system much less fragile). In addition to communicating with Mesmerizer users, the Hubs now have two additional interfaces:
- Web users - individual users registered with a hub can be marked as "web-enabled", which allows them to access the Hub over the Internet, from a web browser. This allows them to take part in Mesmerizer chat with other users of the Hub without being logged in to Second Life. In addition, individual web-enabled users may be granted "command-level access", which enables them to issue channel 99 commands to connected mesmerizer users, subject to normal access controls. This allows a Hub owner to maintain contact with and control of their subs in Second Life, without having to be in-world themselves.
- Automation interface - this allows a Hub or group of Hubs to be managed remotely. It is primarily meant to support the new Enforcer product, described below.
In addition to the enhancements to the Hubs, there are some significant updates to the core Mesmerizer product:
- Initialization has been completely redesigned, which makes it easy to create plugins. As an example of this, I'm intending to release a free plugin that will give the Mesmerizer the ability to display Standard Deviations Entrancer sessions. Standard Deviations is a long-defunct SL vendor of hypnosis devices. Their primary focus was on live trances, but they did make one product - the Entrancer - that used a free HUD to play back trances transmitted by devices disguised as pictures. The system was proximity-triggered, much like the MesmerX - if you approached too close to an Entrancer picture while wearing the HUD, the session automatically started. The plugin gives the Mesmerizer the ability to play back these same trances, so it will only be useful to people who still have some of the old Entrancer pictures lying around. Since the Entrancer uses two image layers, compared to the single layer in the current Mesmerizer, I had to add an additional layer, which means that the plugin will only work with Mesmerizer version 0.98d or later.
- The Mesmerizer now has the ability to store trance scripts internally, and to play them back on demand. This allows you to trigger individual trances for your subs whenever you wish, and wherever they are. If you have network-enabled their Mesmerizer, then you can do this from anywhere on the grid, or even from the web. The systems supports both static trance scripts (implemented as notecards which have to be placed inside the Mesmerizer), and dynamic scripts, which are stored within the Mesmerizer's script memory. Script memory is a scarce resource, so you don't want to over-use this feature. In general it should be used only for short-term trance storage; trances that you want to be retained should be moved to a Notecard and installed manually. Although I'm referring to these as "trances", they are simply sequences of Mesmerizer commands, so they can by used as glorified internal triggers, with the advantage that their presence won't slow down trigger recognition.
- The Mesmerizer now supports LockGuard chains, as well as bound poses, or "Binds". It's long bothered me that the Mesmerizer performs all the functions I expect from an SL collar, except for one - the ability to leash a sub. That's pretty much the only time I have to go to their collar menu. The Mesmerizer does have the follow command, which is very much like an invisible leash, but sometimes you want the visual effect of a physical chain or a rope connecting your sub to you. Now, the Mesmerizer can cause any collar that supports the LockGuard protocol to draw a leash to your hand (if you're carrying a compatible leash holder), or to any prim you care to name. In addition, there are a number of bound poses that make use of LockGuard cuffs (if worn) to create chains appearing to hold the sub in the pose. These poses aren't intended to replace full-function pose-cuffs, but they provide an easy way to integrate ropes and chains into sequences controlled by the Mesmerizer. In addition, with the use of a communications Hub, you can now bind your sub wherever they are on the grid. Access to "Raw" LockGuard functionality is also available - you can get a list of the sub's available LockGuard points, and draw chains from a LockGuard point to a prim, or between two LockGuard points, and delete individual chains at will. So if you don't like the rigging on any of the supplied binds, you can re-tie it. The binds are all defined in a notecard, so you can also edit the definition, so the tie is done the way you like it first time. The first release of Binds will likely have some restrictions around motion when bound - I do want so allow for slow "wriggling" in some of the binds, but that will probably not be in the initial release.
- I fixed a long-standing bug that I had considered annoyance-level up until now - the fact that text written to the screen appears in green when the spiral is not shown, but in brown when it is. It was always intended to be green in both cases, and to my mind this is especially important with the spiral, as the default spiral has a brown tinge, and brown-on-brown text is pretty hard to read, However, I hadn't considered this a pressing-enough bug to focus on until recently. The Entrancer support was the thing that pushed this up in priority, and I'm glad it did, because it turns out that the cause of this bug could also have been the root cause of another very rare but much more serious issue that could cause the Mesmerizer to appear to slow up to a crawl. Now the text is green and hopefully the serious rare bug is also addressed. However, the first of my testers that I showed the new functionality to, instead of being pleased with the improved legibility, said that she found the original brown lettering easier to read. This is obviously a personal choice thing, so I have added a textcolor command that allows the text color to be set for subsequent messages. It takes a single parameter, which is either the name of one of the "Web colors", or an RGB vector (enclosed in angle-brackets).
- There are a few new convenience commands (for example lmlist to see the landmarks installed in the Mesmerizer), a few new pre-defined variables, and on-chat and on-emote events that fire when the sub says or emotes something in local. These could be used by a gag plugin to implement garbling. I have also used this in combination with the Mesmerizer's RLV filtering of what chat the sub can see to implement an interesting isolation scenario, where I can chat with my sub normally - in other words both of us using local - but nobody other than me can hear what she is saying, and she can't hear things said by anyone other than me. People around us can hear my side of the conversation, but not what she's saying. It's an interesting way of being both isolated and dependent, while on full view.
- The Mesmerizer can now rez objects in-world. There are a number of potential uses for this feature, one obvious one being cages. An object is defined to the Mesmerizer via a notecard, so installing a rezzable object consists of adding both the object and its notecard to the Mesmerizer. The notecard specifies where in relation to the avatar the object should be rezzed, and whether or not it supports a simple protocol by which the Mesmerizer can tell it who caused it to be rezzed. There's a script provided that you can drop into a rezzable object that will interpret this protocol.
And finally, the Enforcer, although the name is still provisional. I expect to release this a little after the updates described above. It has grown in scope somewhat since its original conception. The original intent was for it to be a device that could automate sending of Mesmerizer commands to remote users in response to specific events. So, for example, it could send a message to someone when they log in, or teleport or force-sit them somewhere. It could also be programmed to issue commands upon entering specific sims, or based on calendar time, etc. So one very obvious use is to enforce a curfew, where if a given user is seen anywhere outside a few permitted locations after curfew, then will be automatically teleported into a cell for correction. The big difference between doing this via the enforcer, compared with via event rules in the sub's mesmerizer is that the details of the curfew (times, permitted locations, response actions, etc) can be specified and changed at any time - the sub doesn't have to be online. And the centralized enforcement mechanism can target multiple subs at once, without having to do anything to their individual Mesmerizers. This sort of intended use was where then name comes from.
A second use for pre-programmed event responses would be to send an email out to interested users when a Hub changes its web address. This will happen whenever the sim where the Hub is located is restarted, which is typically a roughly weekly event on the main grid. Without this feature, web users would have to log into Second Life after a Sim restart to obtain the new Hub address, before they would be able to reconnect to the Hub from the web.
While building the framework necessary to do this, I kept thinking of useful functions that would make sense to be provided by a device sitting where the Enforcer does in the Mesmerizer network topology, so I've added them, with the result that the original purpose of the Enforcer is now such a minor part of it that it's the last piece of functionality scheduled for implementation. The bulk of the Enforcer's job is now to do with aggregation of data and communications from multiple Hubs, which perhaps means that a different name would be more appropriate.
The Enforcer connects to one or more Hubs, which must reside in the same sim as the Enforcer. It provides a unified view of the current and registered users of all Hubs, allowing you to see in one place who's currently logged in.to any of your Hubs. It doesn't currently support the registration process - that still has to be done at the individual Hub, although I could centralize it in the future. It also supports "bridging" two Hubs together - routing the messages in one Hub to the second Hub. In my own sim, I have 5 hubs, including some for testing purposes, each one serving a different community of subs. Sometimes I've found myself wishing that subs in one community could exchange Mesmerizer chat with subs in another community - not permanently, but just for the duration of some event or other. Bridging allows for this - I can temporarily create a bridge between the Hubs of each of the two communities, and now chat spoken through one Hub will be shared with the second Hub.
Bridges are bi-directional (if Hub A is bridged to Hub B, then Bub B is also bridged to Hub A) but not transitive (if Hub A is bridged to Hub B and Hub B is bridged to Hub C, Hub A is not automatically bridged to Hub C). Messages will only be shared with hubs that are explicitly bridged to the hub where the traffic originated. This avoids the possibility of creating forwarding loops.
One interesting use of bridging would be to create a Hub where the owner is the sole registered user, and bridge that Hub to all their other Hubs. Today, with the 5 Hubs I operate, I have to wear 5 communicators so that I can communicate with users on any of those Hubs. I also have to know which communicator to use if I want to send a message or command to someone. If, however, I were to set up a "Master Hub" that was bridged to all the others, then by connecting to that one Hub I could see traffic in any of the other Hubs, and speak to all of them, but the other Hubs would still be isolated from one another. This would allow me to wear just one communicator, which would cut down my script load a little, to say nothing of the visual and mental clutter of running five communicators. It would mean that my transmissions would by default be heard by all users of any of my hubs, but I have separately been working on a way to target Mesmerizer chat to individual users which would solve this issue.
Another use for bridging would be to allow a large community of subs to be split across multiple Hubs. While I haven't encountered any issues with reasonable number of subs registered in a single Hub, there are LL-imposed HTTP rate limits for a single object which could theoretically come into play with a large community of subs, if they are all logged in simultaneously. This limit could be avoided by splitting the subs across multiple bridged Hubs.
Finally, the Enforcer will support migrating users from one Hub to another, without requiring the sub to manually reconnect to their new Hub.
No comments:
Post a Comment