Le 16 décembre 2009, lors de sa permanence, Babbage Linden a fait des déclarations sur les futurs développements du serveur de Second Life. Linden Lab envisagerait d'ajouter deux nouvelles fonctions au script, dont au moins une était largement attendue.

Lisons ce que dit exactement Babbage :
[3:14]  Babbage Linden : Nous avons aussi sorti les spécifs pour l'API scripts 
[3:14]  Babbage Linden : Nous avons le premier jet prévu et ça commencera aujourd'hui dès que nous aurons passé en revue l'API
[3:15]  Babbage Linden : J'espère que ça sera mis dans la 1.38 
[3:15]  Babbage Linden : Il s'agit des fonctions llSetLinkedPrimitiveParamsFast et llGetLinkedPrimitiveParams functions 
[3:16]  Babbage Linden : Fast signifie Delay = 0 ainsi vous pourrez utiliser les deux fonctions dans une boucle économique au lieu d'avoir à utiliser 1 script par prim
[3:16]  Babbage Linden : Dans une coiffure de 100 prims ça permet de sauver environ 1,5 Mo de mémoire script 
[3:17]  Babbage Linden : Ça va fonctionner avec les paramètres actuels de llSetPrimitiveParams
[3:18]  Babbage Linden : Je vous en dirai plus sur l'API final après examen, après Noël.

Voilà une nouvelle intéressante pour les scripteurs qui réclamaient depuis toujours une fonction comparable à llGetPrimitiveParams mais compatible avec un objet multiprim.
llGetLinkedPrimitiveParams va permettre de lire les caractéristiques d'une prim liée sans être obligé de recopier un même script dans chaque prim ; c'est très valable pour ajuster par menu la taille des attachements comme les vêtements, les armes ou autres accessoires. Cela fera des économies de scripts et de mémoire ; c'est très mode à un moment où l'on parle beaucoup de limiter la mémoire utilisée par les scripts, même si pas grand monde n'a vraiment compris ce que cela implique vraiment. (De toute façon Linden Lab ayant déjà pris sa décision, ça ne sert à rien d'en discuter, attendons l'annonce définitive pour voir ce que cela donne pour chaque cas particulier).
L'autre instruction llSetLinkedPrimitiveParamsFast est prévue comme identique à llSetLinkedPrimitiveParams, le Fast signifiant que le délai (la pause) de 0.2 seconde après exécution de l'instruction sera supprimé, ce qui est peu pour une instruction, mais beaucoup pour une boucle imposante.

Attention : le fait que Linden Lab fasse état d'une nouvelle instruction ne veut pas dire que cela fonctionnera un jour ; que l'on garde bien à l'esprit llTextBox(...) qui non seulement a été annoncée, mais inscrite dans la liste des fonctions (ce qui n'est pas encore le cas de celles de l'annonce), qui plus est compilable mais qui après plus d'un an ne fonctionne pas ... dans le viewer officiel en tout cas! (Je veux dire par là que cela fonctionne dans un viewer alternatif comme Emerald, mais risqué à mettre en production pour des raisons de compatibilité).
Et re-Attention : nous en sommes à la version de serveur 1.34, alors quand la 1.38 pointera le bout de son nez? Va savoir, les sorties de versions majeures n'ont pas un rythme astronomique.
Et re-re-Attention : la fonction llGetLinkedPrimitiveParams avait toujours été refusée par Linden Lab car elle est supposée être une aide à ces diaboliques copieurs d'objets! Pourquoi Linden Lab a changé d'avis? Le vent? Non, le vent pose trop de problèmes aux développeurs! Va savoir!

Dans la même réunion nous avons aussi appris :
[3:18]  Babbage Linden : En plus nous espérons ajouter PRIM_TEXT ainsi vous pourrez utiliser ces méthodes pour lire et écrire du texte flottant
[3:18]  Babbage Linden : Le système de particules est dans nos projets en retard
[3:20]  Babbage Linden : Nous avons aussi fait quelques progrès dans notre prototype interne C#, fixé certains bugs et quelques fonctionalités du langage fonctionnent
[3:29]  Babbage Linden : Bien, des outils importants vont se trouver dans la prochaine version du viewer
[3:30]  Babbage Linden : Il ya aussi plus d'informations ajoutées à l'onglet Objets de A propos du terrain...
[3:30]  Babbage Linden : Elles montreront la taille et l'emplacement de chaque objet scripté sur votre terrain et dans les attachements
[3:31]  Babbage Linden : Cela fonctionnera pour les propriétaires de terrains
[3:37]  Babbage Linden : Pour le moment nous envisageons de montrer le nom et l'emplacement de chaque objet scripté ainsi que sa taille plus les boutons pour mettre une balise sur l'objet et le retourner
[3:38]  Babbage Linden : mais cela peut changer puisque ce n'est pas encore finalisé
[3:49]  Babbage Linden : Nous discutons sur le stockage persistant de données mais il y a du chemin à parcourir. Notre feuille de route ne va pas aussi loin que cela.

C# : la possibilité d'utiliser ce langage de programmation en place et lieu du LSL ; il y a du retard sur la concurrence.

Scripts et terrains : les propriétaires auront ainsi le même avantage que les propriétaires d'Estates ; ils pourront ainsi éliminer les objets qui génèrent trop de lag (et éventuellement ceux qui consomment toute la mémoire allouée au terrain proportionnellement à sa surface.)

Persistance des données : faire en sorte que les données acquises par un objet restent disponibles même après un reset de l'objet (actuellement en écrivant de courtes informations dans la description voire le nom de l'objet ou en recourrant à une base de données externe).

Voilà, ce furent quelques informations intéressantes sur les projets de Linden Lab.

Garmin Kawaguichi,
llChroniqueurFast