Portal of Dragons: the video!

Here is a little video I recently edited to show our Portal of Dragons in Second Life®. A few words about the configuration hopefully show the whole thing is very easy to set up.

The details of this product are mentionned in this previous post.

Comments are welcome!

ChainDance HUD

The ChainDance HUD is a device that attaches to your Head Up Display and lets you play animations in a "chained" way, meaning that you define for how long an animation (dance, pose, etc.) will play before switching to the next animation.

The order and duration of each animation is defined in a very simple notecard inside the HUD. This lets you create sequences very easily by editing a notecard such as this :

// comments begin with 2 slashes, they are ignored
// use comments to enhance readability if needed
BellyDance 1:20
boxing:30
Russian Dance:10.3

In this example, the "BellyDance 1" animation will play for 20 seconds, then "boxing" will play for 30 seconds, then "Russian Dance" for 10.3 seconds. After that, looping occurs and the HUD will play BellyDance again.

The only requirement is that the animations are placed inside the HUD's inventory along with the notecard (you cannot specify an animation by its UUID, unfortunately - SL limitation).

The ChainDance HUD automatically detects changes in inventory and reloads the configuration as required. To activate the sequence, just touch the HUD (and watch it spin!).

This applies only to the wearer of the HUD. If you need a device to animate several avatars, then you can have a look at the OAnim HUD !

The ChainDance HUD is completely free and available at Oggy's Scripted Items marketplace and in-world stores. Check it out!

Theme-O-Matic v2.0 with preloading!

Today we released a very important update to the Theme-O-Matic System. For new customers, let's recall that this system is designed to store themes, that is sets of parameters for an object, its prims and faces, into notecards and later activate them.

This new release mainly addresses the first drawback of the previous version 1.1 : speed of theme activation.

Indeed, the "old" way of activating a theme is to read the notecard and apply it "on the fly". This is fine if you only have a few parameters to change, if your notecard only contains a few lines. However, for large themes (where you change the textures and materials of many faces on many prims for example), this is slow as the SL server may take time to feed the scripts with notecard lines.

While this way of doing things still is supported, this new version 2.0 introduces preloaders to solve this problem. If you do not want to wait for theme application, you can just "preload" them into script memory with the help of additional scripts - called preloaders.

These new scripts are an arbitrary number of copies of the same script - drop as many as you need into your object. They will, at your command, preload a theme notecard and have it ready for, later, almost immediate activation. You can even skip the explicit preload command by naming your theme notecard suitably thanks to an automatic preload feature - great for an AVsitter interface without using an additional command script!

While this principle sounds simple, under-the-hood mechanics tend to be quite complex, but the Theme-O-Matic takes care of the numerous details there. Just define your themes - themes created with earlier versions remain compatible - and decide how you want them activated : with or without preloading ? by simply clicking the object ? using a full-blown menu ? interfaced with another system (instructions are provided here for interface with AVsitter, Wearpose System and MvtPlayer) ?

When you prepare your object, you have to equip it with the "T-O-M Core" script, as many copies of the "T-O-M Preloader" script as you need, and maybe a standard command script, or one of your own...

Speaking of standard command script, 4 of them are provided:

• T-O-M-SC SimpleCycle : theme activation without preloading, at the click of the object,
• T-O-M-SC AutoMenu : automatic menu without preloading,
• T-O-M-SC QuickCycle : theme activation with preloading at the click of the object,
• T-O-M-SC PreloaderMenu: with preloading, full configurable menu.

All of them are full perm, and full instructions on the API in the documentation allow you to create your own command script. Of course you may always contact us for help.

An example of an object using the PreloaderMenu is rezzed in our inworld store ; check it out!

Here is the list of changes in this new version:

• New preloader system allows for dramatic increase in theme activation speed.
• Auto-load feature for preloaders to automatically preload suitably named themes.
• Hover text and Omega are now prim properties, as opposed to object properties: you can now set them on every prim individually and not the whole object only.
• New object property: Physics.
• New prim property: Physics shape.
• New "prim2" menu in preparation to allow selecting the extra prim properties
• Much much richer API. Now scripts can gather much more information from the Theme-O-Matic and usefully dialogue with it.
• Asynchronous Core operation: while a theme is being applied, the Core continues to answer script requests.
• Applying (or preloading) a theme can now be aborted.
• Many optimizations and fixes.

Full PDF documentation in English and French is available by clicking here.

As usual, reasonable requests are always considered, constructive criticism welcome, and recommendations even more welcome :) Feel free to contact us!

Spread the word!

Portal Of Dragons

New at Oggy's Scripted Items for you pyromaniacs is the brand new Portal Of Dragons !

Are you looking for some impressive addition for the entrance of your clan, club, roleplay sim or anything else? Do you like dragons? Do you like fire-breathing roaring dragons? Then this Portal Of Dragons is for you! :)

Rez the portal and witness the mighty beasts guarding the animated flames. As you approach, see your own profile picture appear inside the flames and be asked for the password! Watch your tongue as the dragons will ruthlessly burn you to ashes if you are wrong!

Luckily you did know the password, and now the portal is opening! Watch the magic operate with light and sound!

Did you just want to touch an object or a HUD to open the portal, or maybe trigger it from another object ? Two types of full-perm remote control scripts are provided to do just that, and 4 examples of remote control using them are provided. Everything is documented so that you can interface them with your own objects and scripts.

A scripting API is also included so that you can synchronize your own scripts with the portal when it detects someone, when a password is provided, when it opens etc. Details are inside a dedicated "Scripting" notecard shipped with the portal.

The whole thing is configurable through a very simple configuration notecard to :

• define the password ;
• set the channel to listen for the password (may be public chat without causing lag) ;
• activate or deactivate dragons breathing fire at intruders ;
• set the detection range for the mirror in flames ;
• define how long the portal remains open for visitors to cross ;
• customize the messages : password prompt, "access granted", "access denied", with codes to include the visitor's name inside them ;
• mute sounds ;
• define remote control parameters.

Inpiration and artistic direction by Carisma Alex
Building by Carisma Alex and Oggy Fink
Scripting, documentation, packaging by Oggy Fink

This work uses sounds released under a creative commons attribution licence, details are in the "Installation" notecard.

MvtPlayer 2.0

The MvtPlayer is a script system for creators and enthusiasts to help them define sequences of movements and other actions for their objects in Second Life®.

Such a sequence consists of a virtually unlimited number of steps with different types :

• Smooth (keyframed) movements: the object moves from where it is currently to another point in a smooth manner in a given number of seconds. Doing so it may also rotate, or maybe only rotate, as you decide it.
• Immediate movement: same thing but the movement (and rotation) happens as fast as possibly allowed by the sim.
• Pause: the object waits for a number of seconds. The sequence then resumes with the next step.
• Sound: the object emits a sound.

A plugin system allows for extra step types by communicating with other scripts :

• plugin action: a message is sent to the plugin and the sequence goes on with the next step
• plugin wait: a message is sent to the plugin and the sequence is paused until the plugin replies.

Two flags can also be set as part as the sequence definition :

• Loop: the sequence starts again when reaching the end
• Back to origin: the object is set back (as an immediate movement) to its origin point (its position and orientation it had when starting the sequence) when the sequence reaches its end.

Sequences are recorded by a special Recorder script (using a very clear menu interface), saved to notecards (so that you can define as many sequences as you wish) and played with a Player script. The player is copiable and transferable so you can include it with your creations.

The whole playback system is commanded through a controller script that sends commands (like "load this sequence", "play", "stop", "pause", "resume"). You can either use one of the provided (full perm) controller scripts or design your own if you have the knowledge (full PDF documentation available here).

You can also interface with another system like AVsitter (so that the movement begins as soon as someone sits on your object and stops when all avatars stand up). You decide. And of course, should you need a special controller or plugin script you can always contact me.

One standard full perm plugin is provided that supports commands to say, shout or whisper messages publicly, as well as activating Theme-O-Matic themes. It also supports "plugin wait" steps by waiting for a specific command over a private channel, ideal to be used by some remote control HUD for example.

The scripting API is rich but efficient and easy to use. The player script performs the required computations so that when you begin the sequence playback with a different orientation the whole movement is turned as you intuitively expect it. Try it!

The MvtPlayer system is now available at Oggy's Scripted Items marketplace store. The documentation is available as a PDF file in English and French here.

Theme-O-Matic 1.1

Considering a customer request, I have made a quick update to the Theme-O-Matic system (read the original article about it here) to support two new face properties:

• Normal map,
• Specular map.

For those who may legitimately wonder what this is about, here are two pages that explain how you can use these properties to fine-tune the appearance of your objects without overloading their land impact :

• Understanding the difference between texture maps,
• Materials: normal and specular mapping.

Version 1.1 includes these two new properties, so the system is now able to manage 3 object properties, 9 prim properties and 9 face properties. And of course the filter system still allows you to only record the prims and faces you want.

The Theme-O-Matic is now available at our marketplace store as well as our inworld store (check my "picks" to get the latest location). Full PDF documentation is available in English and French here.

WPS: beware of priority-5 animations

My attention has been brought recently on a so-called problem with the WearPose System (see here for a description), stating that adjustment would not work on some animations.

Problem? Solution!

Indeed, upon investigation it appeared that the "main" animations configured were priority 5 animations. For adjustment to work as expected, the adjustment poses are supposed to have a priority higher or equal to the main pose priority (see here for an explanation about the theory of adjustment poses).

Thing is the standard adjustment poses provided with the WearPose System are priority 4, hence the encountered problem.

The solution may sound easy: just use priority 5 animations as adjustment poses. Or even priority 6! Or 7?

Not so fast!

The animation priority system was (cleverly) designed by LL to allow one animation to override some joints of a lower priority animation. However, people are using this clever system stupidly. Here is what the official wiki says about animation priority usage, summed up in a table.

Priority	Purpose and guidelines
0	Used for many of the internal animations which are intended to be overridden with an AO.
1	Used for internal emotes.
2	Priority 2 is a good choice for stands in AOs.
3	Priority 3 should have been the best choice for walks, dances, sits and most other animations. Unfortunately many of those animations have been given priority 4 leading to unpredictable user experiences for creators who do try to use priority 3.
4	Priority 4 is used for many walks and most pose ball animations, such as dances, sits and vehicle driving animations.
5	Priorities higher than 4 should be reserved for situations when the objective is to override only some joints of the existing priority 4 animation. For example, a handbag might override an arm and boots might override feet. In these cases, the alternative to a priority 5 animation is a script which continuously alternates priority 4 animations, generating a lot of unnecessary script events. If you do not need part of the existing priority 4 animations to continue playing, you do not need, and should not use, priority 5. The internal turn_180 animation, which plays during Edit Appearance, uses priority 5.
6	As priority 5 animations proliferate, a use for priority 6 is certain to materialize. However, as with priority 4 and 5. If your objective is not to allow part of an existing priority 5 animation to continue playing, then you can meet your objective either with a priority 5 or a priority 4 animation. It is uncertain whether viewer and server support for priorities higher than 5 exists today or will continue to exist in the future.

The SL official viewer, as well as third-party viewers like FireStorm, are not able to upload priority 5 animations without some serious hacking. I will not cover this subject here since it's not officially supported. And moreover such hacks are often broken: the hacked viewer appears as it's uploading an animation to priority 5 while some internal code in the viewer brings it back to 4.

Yet some people manage to upload priority 5 animations and sell them, sometimes very expensive. While there is, in my opinion, no true reason for doing that, this is a problem for the WearPose System's adjustment poses.

The WearPose System itself is perfectly able to cope with that, as scripts are not aware at all of animation priorities anyway. But the visual result will not be what you expect as "normal" high priority animations (like adjustment poses) are priority 4.

So?

What do do ? Two solutions.

1. AVOID buying priority 5 animations. Creating them and selling them is unprofessional behavior in my opinion. It will prevent users from partly overriding them with normal, legitimate, animations or poses.
   If you bought a priority 5 animation from a creator, you should contact them and tell them about this situation and ask (or demand!) they reupload their animation with a lower, more normal, priority, like 4 or 3.
2. Use priority 5 adjustment poses. You will need to create and download them (as .bvh files) using the WearPose System website and find a way to upload them as priority 5 animations.
   As I said previously, I cannot and will not support this. You're on your own there.

I hope this clarifies this situation. Have fun with your WearPose System !