Overlays
As mentioned earlier, one of the features added in Mesmerizer 1.4 will be support for overlays. Overlays are a way of adding an image to the screen. Unlike an image displayed on a HUD, you can't interact with an overlay image - you should think of it as part of the viewer window, rather than something that's displayed within the window. Overlays are currently only available in RLVa, which means that they will only work in viewers that support RLVa (as opposed to RLV). Firestorm and Catznip are two viewers that support RLVa, so overlays should work for a majority of SL users.Overlays are an alternative to the image display that's always been a part of the Mesmerizer. Regular images are displayed on the Mesmerizer HUD itself, and it's possible for the user to move them aside. They also interfere with mouse activity, so you don't want to leave them up for very long as they significantly impair the sub's interaction with their environment. Overlays don't have this issue - you can click through them, and they always fill the entire viewer window - they can't be dragged to one side. The fact that they are always stretched to fill the viewer window is actually a bit of an issue when making textures for them, since even if you assume that the window is maximized, screens come in various different aspect ratios. However, the 16:9 format is undoubtedly the most common ratio in use, and a texture made in this ratio isn't distorted too much if displayed on either a 4:3 or an ultra-widescreen display. Textures made for display using the Mesmerizer's show family of commands, on the other hand, will always be displayed in a square aspect ratio, filling the window vertically, but leaving gaps on either side.
The Mesmerizer uses the underlying overlay mechanism to implement two distinct type of overlay: a static image and a slide-show. For both types, you can specify how long the image takes to fade up, how long it will be displayed for and how opaque that display will be, and how long it will take to fade to transparent.
The slide-show format might be useful as an automatic background for trances. You can start a slide show during the trance and leave it running for as long as you like, and it will cycle through the chosen images in sequence.
The static overlay can be used as a "frame" around the SL window, if you use a texture with a large central transparent region, and narrow decorated edges. You can use frames as visual triggers, to continually remind the sub of suggestions you've made in trance. Another use for static overlays is as a blindfold, to block or restrict the sub's view. A single texture can provide a number of different levels of restriction, simply by varying the the opacity of the overlay.
Overlays are specified with two commands: overlay which defines a static overlay, and overlayslides which defines one or more images to display in a slide-show. Each of these commands takes a single parameter, which consists of one or more subcommand strings of the form keyword=value, separated by colons. While the parameter syntax of both commands is the same, the valid keywords are different for each.
The overlay command specifies a single image that can be displayed either for a specified length of time, or indefinitely. Valid keywords for overlay are as follows:
| Keyword | Description | Example |
|---|---|---|
| t | Key of texture | t=2c658bf0-414d-89b0-de6d-999d9cc3c6bd |
| tint | R/G/B color. Default is 1/1/1 | tint=0.5/0.5/0.5 |
| alpha | Opacity of image. Default is 1.0 | alpha=1.0 |
| hold | Number of seconds to display image at specified opacity. Default is 0, or indefinite. | hold=5.0 |
| ramp | Number of seconds to take to bring image to specified opacity. Default is 0.5 | ramp=3.0 |
| show | Boolean - whether to show the image immediately (default is yes) | show=yes |
| clear | Boolean - whether to clear the current image | clear=yes |
| report | Boolean - whether to report overlay properties | report=yes |
Apart from clear and show, subcommands are executed left-to-right.
If present, clear=yes will be executed before any other subcommands. It is only useful if the remainder of the parameter does not cause a new image to be displayed, since display of a new image would automatically cause any previous image to be removed.
If present, show=no will be executed after all other subcommands. If it is not present, then the image will be displayed immediately.
If present, report=yes will be executed as it is processed, and will report the current settings of the static overlay.
The other keywords set the values that will be used when a static overlay is displayed.
Some examples:
| Parameter | Effect |
|---|---|
| overlay "clear=yes" | Remove the overlay |
| overlay "show=yes" | Display the current overlay |
| overlay "t=2c658bf0-414d-89b0-de6d-999d9cc3c6bd" | Display the specified texture as the overlay |
| overlay "t=2c658bf0-414d-89b0-de6d-999d9cc3c6bd:show=no" | Save the specified texture as the overlay, but don't display it yet |
| overlay "alpha=0.5:ramp=5.0:duration=10" | Display the previously-specified static overlay at half-opacity, taking 5 seconds to ramp up to that opacity, and remaining for 10 seconds |
If hold is specified as 0, meaning indefinite, this means that the image will be displayed continuously, and will not be removed. This is particularly appropriate for "frames", that are intended to decorate the viewer window, perhaps to act as a reminder to the sub of some desired behavior. If there is a static frame set with an indefinite hold, it will automatically be redisplayed after any slideshow overlays are completed.
The overlayslides command specifies one or more images that can be displayed in sequence. Valid keywords for overlayslides are as follows:
| Keyword | Description | Example |
|---|---|---|
| t | Key of texture. The t subcommand may appear multiple times to specify multiple textures. | t=2c658bf0-414d-89b0-de6d-999d9cc3c6bd |
| max | Maximum number of slides. If more slides than this are specified, older ones will be discarded. Default is 16 | max=10 |
| tint | R/G/B color. Default is 1/1/1 | tint=0.5/0.5/0.5 |
| alpha | Opacity of image. Default is 1.0 | alpha=1.0 |
| hold | Number of seconds to display image at specified opacity. Default is 5 seconds | hold=3.0 |
| rampup | Number of seconds to take to bring image up to specified opacity. Default is 0.5 | rampup=3.0 |
| rampdown | Number of seconds to take to fad image down after display. Default is 0.5 | rampdown=3.0 |
| interval | Number of seconds to pause between slides. Default is 0.5 | interval=3.0 |
| run | See below | run=no |
| clear | Boolean - whether to clear the current texture list | clear=yes |
| report | Either keys or parameters | report=keys |
Apart from clear and run, subcommands are executed left-to-right.
If present, clear=yes will be executed before any other subcommands. It is only useful if the remainder of the parameter does not cause a new image to be displayed, since display of a new image would automatically cause any previous image to be removed.
If present, run=no will be executed after all other subcommands. If it is not present, then the image will be displayed immediately. The value for run can be either a Boolean or an integer. As a Boolean, it simply enables or disables the display of all slides. As an integer, it specifies how many slides to display in sequence. So run=yes will cause all slides to be shown in rotation, until the slideshow is explicitly stopped via a new overlay or overlayslides command; run=3 will display the next 3 slides in sequence and then end the slideshow.
If present, report=keys or report=parameters will be executed as it is processed, and will report the current settings of the overlay slides, listing either all the texture keys, or the other slide parameters.
The other keywords set the values that will be used when the slides are displayed.
Some examples:
| Parameter | Effect |
|---|---|
| overlayslides "clear=yes" | Clear the slides. If running, the slideshow will stop after the current slide is finished. |
| overlayslides "run=yes" | Run the slideshow |
| overlayslides "t=2c658bf0-414d-89b0-de6d-999d9cc3c6bd" | Add the specified texture to the list of slides and start the slideshow. |
| overlayslides "t=2c658bf0-414d-89b0-de6d-999d9cc3c6bd:run=no" | Save the specified texture to the list of slides, but don't start the slideshow. |
| overlayslides "alpha=0.5:rampup=5.0:duration=10" | Change display parameters for future slides. |
On-Text Mesmerizer event
Another new feature in 1.4 is the on-text event. This is very similar to the existing on-commlink-message event, and will fire each time new text is displayed on-screen via the text or text2 commands.Sometimes, a novice trancer's first experience with text trancing may be unsuccessful for a very simple reason: as they begin to drift into trance, many people have a natural tendency to close their eyes. Obviously this makes reading the hypnotist's words impossible. Not everyone has this tendency, and it can usually be overcome with practice, but the on-text event allows for a rather simpler work-around. By defining a trigger-rule for the on-text event, a soothing chime can be played when each message is received, signaling to the sub that they should open their eyes to read it. If within the trance you refer to the process of the sub opening their eyes upon hearing the chime, and then after they've read the message closing them again and drifting deeper, this can work as a sort-of automatic Elman fractionation process, one that continues throughout the trance.
If used in this way, there may be times during trance when you won't want each text command to have an associated audio cue. For example, you wouldn't want to continue with fractionation during the wake-up phase of a trance. Therefore, as with the on-emote and on-chat events, there is a companion hooktext command that takes a Boolean parameter to specify whether the on-text event will fire or not. hooktext yes will enable the on-text event; hooktext no will disable it.
Enhanced sound control
Related to the above, I've added variants of the play and playloop commands. While the regular play and playloop commands use the volume level established by the volume command, the new play2 and playloop2 commands take, as an initial parameter, a volume setting for the sound. This is particularly useful for sounds used as triggers or via the new on-text event, as it can ensure that these sounds will be played at a reasonably low volume, regardless of what the default volume is set to.So whereas play fe3e1012-a6f7-a671-aa2d-972ce000beea would play a tinkling chime sound at whatever the current volume setting is, play2 3 fe3e1012-a6f7-a671-aa2d-972ce000beea would play the same sound at a predictable volume level of 3.
Emoting and speaking for the sub
The say, whisper, shout and emote commands have existed since the very first pre-release. Previously, they always "spoke" using the current display name of the sub. In other words, if a sub's username is "fred12345" and their display name is "Fred", then /99say "Hello there" would cause the following to be spoken in local:Fred: Hello there
Most of the time this is fine, but sometimes you might want to customize the name used. The new emotename command allows for this. It takes a single parameter - the name to be used for subsequent say, whisper, shout and emote commands. So if Fred's mesmerizer was given the command: emotename "Frederick the great", then the above /99say command would result in the following text:
Frederick the great: Hello there
Specifying an empty string for the emotename parameter will set the name used back to using whatever is the current display name.
One use for the emotename command is to program the Mesmerizer to be a renamer. To do this, you will need to create a trigger-rule for the on-chat event, something like the following:
on-chat = internal say "$message"
You will also need to issue a hookchat yes command to redirect chat to the on-chat event.
This will cause anything that the sub tries to say in local be issued via the say command instead, which will use whatever name has been set via emotename. So if Fred says "Suffering Sassafrass", their original speech will be suppressed, and the on-chat trigger will immediately invoke the say command with the same text, resulting in something like:
Frederick the great: Suffering Sassafrass.
Emotes can be similarly renamed with a trigger-rule for the on-emote event that invokes emote, and the hookemotes yes command. on-emote will receive the emoted text (via the message variable, just like on-chat) with a leading "/me", and the emote command has been enhanced so that it's tolerant of a leading "/me", but doesn't require it.
Multiple .basics for Peanut outfit folders
This feature doesn't yet have a good descriptive name. It refers to the extension to Peanut Folders that I mentioned at the time of the 1.3 release. 1.3 added the ability to have subfolders within your Peanut Outfits folder, but still required that the .basics and Nothing folders reside inside the Outfits folder itself. In 1.4, these folders can optionally appear in lower levels in the directory hierarchy as well.The primary reason for this is to support outfits that use different mesh bodies, since the .basics folder is expected to contain the body (and other body-parts), and the nothing folder should contain the corresponding "glimpse of nothing" object, along with the default hair for that body.
When wearing an outfit, the .basics and Nothing folders from the closest ancestor of the outfit folder are used.
New Login and RLV Enforcer events
The Enforcer's existing Logon event is perhaps misleadingly named. What it signals is that the sub's Mesmerizer has logged on to its Hub. Usually this corresponds to the sub logging into SL; however, if the sub were to log out and then back in again within a few minutes, their Hub session wouldn't be logged out, and so the second log-in would not generate a Logon event in the Enforcer. This can sometimes be a problem. For instance, if the Logon event is used to set RLV restrictions, simply relogging would allow these restrictions to be avoided, since they wouldn't be applied to the second login.To prevent this, Mesmerizer 1.4 adds a new Enforcer event: Login. The existing Logon event is still generated, and is a suitable place to do things like sending a "message of the day" to the sub. But actions that should be performed on each and every login to SL should use the new Login event instead.
There are also new Enforcer events corresponding to the on-rlv-enabled and on-rlv-disabled Mesmerizer events. Within the Enforcer, these events are called RlvEnabled and RlvDisabled. One of these events should fire on every login, but the RlvDisabled event may be delivered only after a delay, because the only way that the Mesmerizer can tell that RLV isn't enabled is by not receiving a response to an RLV status query within a certain timeout, so it has to wait for at least that timeout interval before signaling the RlvDisabled event.
Miscellaneous bugfixes
In addition to the new features listed above, 1.4 contains some bugfixes, including addressing some issues with the RLV relay around recapture with certain furniture engines.
No comments:
Post a Comment