Linden Lab annonce un système d'AO côté serveur

Le nouveau système utilise une série de nouvelles commandes LSL qui peuvent être placée dans un script situé dans un prim qui a la permission d'animer votre avatar, un peu comme les AO actuels. Cependant, l'avantage avec les nouveaux appels est qu'ils sont codés directement dans les serveurs d'états d'animations, à la différence des AO actuels qui fonctionne un peu en conflit avec les serveurs d'état d'animation. Par exemple, avec le système actuel, le fait de déplacer votre avatar (marcher) provoque une mise à jour qui doit être envoyée au serveur, qui tente d'abord de lancer l'animation par défaut (l'horrible "marche en canard"). Cependant, le script AO détecte aussi le changement d'état de votre avatar, et ordonne ensuite au serveur de remplacer l'animation par défaut par le l'animation souhaitée.

Avec le nouveau système, plutôt que d'essayer de lancer l'animation par défaut, puis avoir un AO qui lui dise quoi faire, le serveur remplace simplement l'animation par défaut par l'animation souhaitée, ce qui simplifie grandement le processus.

Cette nouvelle fonctionnalité devrait donc réduire de manière conséquente le lag lié aux AO.

A noter :

• Les nouveaux appels devraient être compatibles avec les AO existant, en supposant que les priorités appropriées sont utilisées
• Les éléments tels que des animations ralenties ou des animations piscine sont traités séparément par le viewer. Elles ne sont donc pas couvertes par les nouveaux appels
• Cette fonctionnalité ne nécessité pas de changement coté viewer à l'heure actuelle, mais il est probable qu'une mise à jour du viewer sera faite prochainement pour permettre à l'option de menu "Stop Animating Me" (arrêter l'animation) de réinitialiser les états d'animation définis à l'aide des nouveaux appels.
• Les sièges et les poseball devraient continuer à utiliser des animations de déclenchement
• Les objets de type poseball devront utiliser llStopAnimation (llGetAnimationOveride ("Sitting")) au lieu de llStopAnimation ("Sitting") afin de travailler en harmonie avec les nouveaux appels.

Les états d'animation couverts par les nouveaux appels LSL sont :

- Standing (debout)
- Sitting (s'asseoir)
- Ground sit (s'asseoir par terre)
- Standing up (debout)
- Crouching (accroupi)
- Walk (marche)
- Crouch walk (marche accroupie)
- Striding (grandes enjambées)
- Running (courrir)
- Turning right (tourner à droite)
- Turning left (tourner à gauche)
- Jumping (sauter)
- Pre-jumping ("pré-saut")
- Taking Off (décoller)
- Hovering (planer)
- Hovering up (planer vers le haut)
- Hovering Down (planer vers le bas)
- Flying (voler)
- Flying Slow (voler lentement)
- Falling Down (tomber / chuter)
- Landing (atterrir)
- Soft Landing (aterrir en douceur)


Les appels LSL pour AO

Les appels LSL suivants ont été définis pour une utilisation avec les animations ci-dessus

llSetAnimationOverride(string anim_state, string anim)

• Règle l'animation qui sera jouée pour un état d'AO donné, string anim_state étant le nom de l'état d'animation remplacé (par exemple "Walking") et string anim, l'animation à utiliser
• Nécessite une nouvelle autorisation d'exécution : PERMISSION_OVERRIDE_ANIMATIONS
• Une fois un remplacement d'animation défini pour un état donné, il est conservé pour le reste de la session, à moins de réinitialiser (voir ci-dessous)
• Comme les états d'animation sont strictement coté serveur, ils sont effacés lors d'un relog.

llGetAnimationOverride(string anim_state)

• Récupère le nom de l'aniation actuellement fixée pour l'état
• Nécessite soit PERMISSION_OVERRIDE_ANIMATIONS ou PERMISSION_TRIGGER_ANIMATIONS.
   

llResetAnimationOverride(string anim_state)

• Réinitialise l'animation pour l'état donné à la valeur par défaut
• Inclus un état spécial "ALL" qui réinitialisera tous les remplacements d'animation à la valeur par défaut
• Nécessite de nouvelles autorisations d'exécution PERMISSION_OVERRIDE_ANIMATIONS.

Ces nouvelles fonctionnalités sont actuellement disponibles pour les tests sur un certain nombre de régions sur Aditi (CCMTEST17, CCMTEST22, CCMTEST23, CCMTEST26 et CCMTEST29, toutes celles du projet DRTSIM-201) et devraient arriver sur la Release Candidate la semaine prochaine. Tous les problèmes rencontrés devront être signalés par un ticket JIRA et, si c'est jugé opportun, seront évoqués lors de la réunion du Simulator User Group du mardi 26 mars.

Il semble que les informations concernant cette nouvelle fonctionnalité ne sont encore pas toute sur le Wiki SL. Il faut donc s'attendre à voir apparaître d'autres informations pertinentes prochainement.