CSD Stasis Tube Version 3

The Stasis Tube is the oldest CSD product that's still available, and it's been a decent seller over the years.  It's a pretty simple device - it's a tube that can capture an avatar and apply various RLV restrictions.  Its notable features are fairly flexible access control and that it announces restrictions as it applies them, to let the prisoner know exactly what abilities are being stripped from them.  It's also fairly aggressive at capturing and recapturing, as it's intended to support holding a prisoner long-term.  It's not much to look at - just a simple glass tube.  When role-playing with it, I generally mention an (unseen) "Stasis Field Generator" with the implication that this field is what's holding the captured avatar motionless.  The advantage to the simple look of the tube is that it has a Land Impact of just 1 prim, so it's feasible to have a wall full of them, which makes an impressive display, especially if they're all occupied.

I had considered the Stasis Tube to be a stable product, and wasn't planning an update.   There have been occasional requests for enhancements - a timer being the most popular one - but my focus for quite a while now has been on the CHAOS range, so I'd given little thought to enhancing the tube.  I think the last update was to support long usernames, which shows how long ago that must have been.

A little while ago, however, I met someone who I guess liked the concept of the Stasis Tube rather more than the execution, Dusty Hays-Tegan, who one day presented me with a mesh model for a brand new tube.  It looked magnificent, but it had an LI of 8, which we both felt was too high.  Thus began a series of refinements and tests, the end result of which is pictured here.

It's a composite mesh/sculpt/prim object with an LI of 3, which is more than the original tube, but in my own set-up, where I have a wall of 20 tubes, each one is paired with a 3-prim display light, whereas the new tube has lighting built in, so effectively I'm saving a prim per tube.  The model is all Dusty's but getting down to a LI of 3 also required that I rewrite the scripts from scratch, so that everything fitted into just 2 scripts.  My scripting has improved quite a bit since I created the original tube, and I found I had room to add both on-line and off-line timers, as well as building in the "externalizer" functionality so that it's compatible with the CHAOS HoloTrainer out of the box.  It also supports a few additional RLV restrictions that have been added to RLV since the original tube debuted, which taken together make it rather more secure than the original against various escape devices, as well as making it suitable for self-bondage.  With the original tube, the tube's owner could always escape.  That's still the default, but if you want to use the tube for self-bondage you can set a restriction to prevent you from touching the tube, which will make it impossible to get a "Release" button.  Finally, the tube now intelligently handles restrictions and timers for multiple captives.  The need for this was a major part of the reason I had resisted adding a timer until now.

This is a problem that's common to any capture device with a timer.  Assume you have a capture device, and you've just caught "Alice" in it, and set a 3 hour on-line timer.   The intent of that is that the device should keep Alice prisoner for a total of three hours.  If she were to log out after an hour, and then log in again the following day, she should still have 2 hours of her sentence to run.  That doesn't seem hard to do, but what happens if Bob sits on the device and gets captured by it while Alice is offline?  It doesn't seem right that Bob should use up Alice's timer - if the device has a timer enabled by default, then Alice and Bob should each get their own independent timer instance.  So the device really should be able to handle multiple instances of the timer - a different one for each captive avatar.

The stasis tube has a quirk of its own.  Since one intended use of it is for long-term storage, it has the concept of being "reserved" for a specific prisoner.  This doesn't mean that it can't be used for storing another captive, but it will only actively grab the intended target - for anyone else to be caught, they have to sit on the tube.  And in the new version, if the "reserved" avatar logs in while the tube is occupied, this will cause any current prisoner to be released, so that the tube can re-capture the real target.  This means that any RLV restrictions that were set for the reservee should be restored when they log in, even if different restrictions had been applied to another avatar in the interim.  Both this and the requirement to have per-avatar timers mean that the stasis tube has to maintain multiple contexts, where a context is a pair of timers (on-line & real-time) and a set of RLV restrictions, and apply the appropriate context when an avatar is recaptured.

The new version of the stasis tube maintains a default context, which is used as a template to create "active" contexts when an avatar is first captured.  Once the avatar is explicitly released, their context is deleted, but it is kept if they simply log out while captured, and will be re-applied if they are recaptured.  To avoid the possibility of running out of memory, the tube only retains up to five contexts for non-reserved users, plus one for the reserved user.  If more than five additional avatars sit and log out, only the most recent five are preserved.

The new model has a base that houses the "stasis field generator", which glows dimly when waiting for the target to appear, and brightly once an avatar is captured.  When I used the original tube to grab someone, I would generally describe the field as "reaching out and enveloping them, then pulling them into the stasis chamber".  I took the opportunity of the script re-write to make it actually do this during capture, as this picture shows.

The stasis field color and initial default restrictions can be set by editing a Config notecard.  I did it this way rather than add menu options as this way you can set the options once, and have them apply to any copies of the tube you make, rather than having to set each tube individually if you have more than one rezzed.  Finally, the new version of the stasis tube will be copiable, so that creating a wall of them isn't too expensive in terms of either prims or Lindens.

The new tube should be on Marketplace and in the vendors this evening, and will be available as a free upgrade to prior purchasers of any version of the stasis tube.

Brief Update

It's been a while since my last post, but I haven't been idle.  The Enforcer is very nearly ready for release - it has been running continuously now for several months, letting me know when my Hubs' addresses change, so I can maintain Web Access after a sim restart without having to log into SL to find the Hubs' new address.  I've also used the bridging capability on a number of occasions.  There are one or two more features I want to add, but I don't think I need to hold up the initial release for those.

I've been somewhat side-tracked with a major update to the CSD Stasis Tube.  I'll go into the details of this in another post, but it's a significant improvement in functionality coupled with a huge cosmetic improvement.  This should be released soon too, and will be available as a free upgrade to purchasers of the original tubes. 

There is a Mesmerizer update in the works too.  As mentioned earlier, this will have the new signal command, which allows a Mesmerizer trigger to generate an Enforcer event.  It will also include a feature I've been intending to add for a while, but hadn't got around to until it was requested recently by a user.  This allows Mesmerizer triggers to be defined by devices like the HoloTrainer and the Enforcer.  You can do this today, but they will be added - so if you create a HoloTrainer trance that adds a trigger, and someone runs that trance more than once, they will end up with multiple instances of the trigger defined in their Mesmerizer.  The new update of the Mesmerizer will allow for an alternative syntax for defining triggers that allows the trigger to be given a name, and adding a named trigger will replace any existing trigger with that same name.  You will eventually also be able to delete named triggers by name and to name or rename existing triggers, although that capability may not make it into the next update.