Project Espeon: Experience enabled sits in Second Life

Experience scripted force sits - a new project from the Lab (image courtesy of Linden Lab)

Experience scripted force sits – a new project from the Lab (image courtesy of Linden Lab)

Update: thanks to the efforts of one or more juveniles defacing the orginial, the proposal – originally referred to as a Google document in this article – has been converted to PDF format, and this article has been updated to reflect that fact, and how those with a genuine interest in the proposed capabilities can forward ideas and suggestions to the Lab.

Since the introduction of Experience Keys into Second Life to allow more convenient granting of permissions for the system to act on an avatar’s behaviour when engaged on a specific activity – such as a game or a tour – a commonly requested item has been the ability to for scripted forced sits to be made a part of the Experience process.

On Thursday, September 22nd, during the Server Beta user group meeting, Rider Linden announced he is working on just this capability – and that test regions are available on Aditi for Experience creators to test the capability as it stands.

The new LSL functions for Experience-enabled scripted forced sits form Project Espeon (after the Pokémon character). Rider has produced a proposal document on the new functionality, which can be read  in PDF format, which he introduces as follows:

With the advent of Experiences Keys we would like to be able to allow scripts being run as part of an experience to force an avatar to sit in a particular location.  This feature will be useful in an adventure game scenario where an avatar is forced to sit in a trap so that it may sync its animations with the avatar, or in an amphitheatre or classroom situation where a presenter wishes for all the other participants to remain seated.

We will add at least one new LSL script function that will force an avatar to sit on a particular prim and make adjustments to the existing llUnSit() function to perform the counter action.  

Within the document, Rider outlines the current APIs and functions related to sitting (llLinkSitTarget()llSitTarget()llSetSitText()llAvatarOnLinkSitTarget()llAvatarOnSitTarget() and llUnSit() ) which by affected by the new capability, before proposing a new series of APIs and behaviour changes to make Experience scripted sitting possible. At the time of writing this article, these new capabilities comprise:

  • llSitOnLink( )  – Function: integer llSitOnLink( key agent_id, integer link ); – mimic the behaviour of the rightclick “Sit Here” menu item.  The avatar specified by agent_id is forced to sit on the sit target of the prim indicated by the link parameter. If the specified link is already occupied the simulator will search down the chain of prims in the linkset looking for an available sit target, as per the diagram at the top of this article.
  • PRIM_ALLOW_UNSIT – to be added to llSetPrimitiveParams( ) – When set on a prim that is running a script as part of an experience an avatar that is seated on the sit target and has agreed to participate in the experience will be unable to stand, select another prim to sit on or teleport to another location in the same region (inter-regional teleports will act as normal).
  • PRIM_SCRIPTED_SITS_ONLY – to be added to llSetPrimitiveParams( ) – Agents may only be seated on this prim using llSitOnLink().  Attempts to do a manual sit will fail.  This flag applies even outside of an experience enabled region.
  • PRIM_SIT_TARGET – to be added to llSetPrimitiveParams( ) – The sit target if any defined for this prim.  If the active value is 0 the sit target is deactivated, if it is nonzero the prims sit target is set to the indicated offset and rotation. As with llLinkSitTarget(), these values relative to the prim, however unlike llLinkSitTarget() an offset of <0.0, 0.0, 0.0> may be explicitly set.

Note that the above is in summary only, please refer to the Google document for the complete specifics.

Test regions have been set-up on ADITI, the beta grid, and those interested in testing the capabilities should join the Second Life Beta group on Aditi for access. The test regions are: Leafeon or Umbreon or Sylveon, with test content is available on Leafeon. If you wish to have your own Experience added to the regions for testing, contact Rider via IM. Similarly, if you have any suggestions or ideas for improving the proposal document or the functions, should raise a JIRA.

With thanks to Whirly Fizzle.

4 thoughts on “Project Espeon: Experience enabled sits in Second Life

  1. Jim Tarber

    Beyond the changes for experiences, one of the three additional new PRIM_ options stands out. PRIM_SIT_TARGET can presumably used by all scripts, not just those running as part of an experience. So it is of good general value. However, if the new wiki page for it (updated yesterday Sept 23) is accurate, it is effectively the PrimitiveParams equivalent of llLinkSitTarget… but with one *huge* semantic change that may be unexpected to scripters:

    “However, unlike llLinkSitTarget() an offset of may be explicitly set.”

    See http://wiki.secondlife.com/wiki/PRIM_SIT_TARGET

    From my perspective, this is pretty huge. A ZERO_VECTOR has always been the method to clear any sit target. llAvatarOnSitTarget (and llAvatarOnLinkSitTarget) wiki page explicitly even states:
    “A prim does not have a sit target unless llSitTarget/llLinkSitTarget has been called with a nonzero vector as the first argument.”

    I can understand a desire to try to enable zero vectors as valid sit targets, but I’m not sure it is safe or backwards-compatible to do so. e.g. Is that description for llAvatarOnSitTarget wrong now? They’ll be changing it so that scripts may now start getting non-null avatar keys for cases where the sit target has been set to a zero vector? Or only if PRIM_SIT_TARGET has been used to set it (i.e. separate “is set” status from the actual vector stored)?

    The reason I’m highlighting this is that any code that checks for a non-zero sit target cannot be directly converted to use PRIM_SIT_TARGET to check it, and must now actually store whether the sit target is *active* or not as an additional status. There is probably code that just stores the sit offset (common in a LOT of programs) that will need to be updated to also store whether a sit target is active, rather than just checking if it’s a zero vector.

    I welcome the change, it seems this is the way sit targets should have been implemented in the first place, but I think it’s important to go into the change with eyes open and be aware of these subtle (or not so subtle) semantic changes.

    Liked by 1 person

    Reply
  2. Jim Tarber

    Looks like WordPress ate the zero vector supplied in the first quote. I’ll drop the angle brackets which it probably didn’t like. It should read:

    “However, unlike llLinkSitTarget() an offset of 0.0, 0.0, 0.0 may be explicitly set.”

    Like

    Reply
  3. Jim Tarber

    Thanks for mentioning the names of the test regions, and the need to join the Second Life Beta group. Your post made it easy to test this.

    Also after testing, I have two bits of additional information regarding the new PRIM_* options:

    1. The values for the new PRIM_* options are:
    PRIM_ALLOW_UNSIT = 39
    PRIM_SCRIPTED_SIT_ONLY = 40
    PRIM_SIT_TARGET = 41

    2. Also note that the name of the second option, according to the SL beta grid, is PRIM_SCRIPTED_SIT_ONLY, not PRIM_SCRIPTED_SITS_ONLY (“SIT” is singular).

    P.S. Thanks for everything you do. Love the blog.

    Like

    Reply

Have any thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s