Réunion du 26-03-2024
Changements du code de la semaine
osGetLinkInventoryKey
- Nouvelle fonction OSSL développée par Jeff Kelley [1][2][3]
- Plus d'informations au chapitre Script
Avertissement
| Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉 |
Noyau
Scripts
osGetLinkInventoryKey
- Cette fonction est apparentée à la fonction LSL llGetInventoryKey qui renvoie l'UUID de l'objet de l'inventaire à partir de son nom.
- Prototype de la fonction osGetLinkInventoryKey déduit du code donc il faut peut être attendre la documentation sur le wiki 😉 :
key osGetLinkInventoryKey(integer linkNumber, string name, integer type);
- Problème possible de la fonction SL llGetInventoryKey : plusieurs éléments de l'inventaire peuvent avoir le même nom mais, un type différent.
- La fonction a été renommée deux fois. Au départ, Jeff Kelley l'a nommée osGetLinkInventoryAssetKey. Ubit Umarov l'a renommée osGetLinkInventoryItemAssetKey. Finalement, il l'a (re)renommée osGetLinkInventoryKey pour être cohérent avec le nom de la fonction llGetInventoryKey de LSL.
Problème de nommage des fonctions OSSL
- Vincent Sylvester rappelle qu'Opensim doit suivre les spécifications de LSL au fur et à mesure qu'elle change même si elles n'ont pas toujours de sens.
- Problème de nommage des les fonctions OSSL en cohérence avec le nommage des fonctions LSL.
- Solution envisagée par Vincent Sylvester : ajouter une surcharge de langage plus concise dans le shéma de nommage, en supprimants les préfixes "ll" et "os" dans les noms des fonctions et en les remplaçants par autre chose avec un nom de fonction logique. Mais, il ne pense pas que cela puisse être adopté partout et que tout le monde arrive à se mettre d'accord sur un schéma. L'ancien code pourrait rester en place, il suffirait d'ajouter un nouveau stub (morceau de code qui convertit les paramètres passés entre le client et le serveur lors d'un appel de procédure à distance [4] ) et de pointer vers l'ancien code.
Base de données
Système de migration
- Nouvelle avancée : la version de la table est déterminée à partir des fichiers de schéma de version et les migrations sont appliquées en conséquence. Vincent Sylvester pense que c'est la solution la plus susceptible de fonctionner.
Modules
Bugs
Tests
Projets en cours / Infos
Viewers
Sharpview
- Il y a encore quelques problèmes de traversé de frontière de région avec un véhicule sur OpenSim. Parfois, des parties du véhicule disparaissent jusqu'au prochain croisement de régions, certaines mises à jour d'objets sont perdues.
- Sharpview effectue une reconstruction complète chaque fois qu'un objet traverse des régions alors que Firestorm doit recopier les objets à partir de la simulation quittée. Joe Magarac signal que Sharview fonctionne actuellement avec des données provisoires, elles seront bientôt plus fournies. Avec une bonne collecte de données du côté du serveur et utilisateur, les problèmes devraient être résolus dans ce domaine. Il aimerait aller jusqu'au bout de cette démarche.
- Si les régions ne sont pas sur le même serveur, la latence accentuent les problèmes. En utilisant un délai réseau sur un système GNU/Linux pourrait simuler cet état. Dans Sharpview l'échange permet au maximum 5 secondes d'échange de connexion et certains serveurs sont très lents.
- Le nouveau Sharpview devrait sortir la semaine prochaine et dvrait permettre de s'asseoir. D'autres personnes pourront le tester.
Source
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-03-26