Changements du code de la semaine

Ajout de nouvelles fonctions Linden LSL

llmapbeacon

Function: llMapBeacon( string region_name, vector pos, list options );
Demande au viewer de créer une balise pour l'utilisateur et ouvre éventuellement la carte du monde centrée sur l'emplacement.

Commit f79e04 : Ajout d'un support pour llMapBeacon.
Voir Linden Lab prépare de nouveaux changements

llGetRenderMaterial

Function: string llGetRenderMaterial( integer face ); 
Renvoie une chaîne qui correspond au matériau de la face.

Commit Commit 0197ff : Ajout de llGetRenderMaterial.

llIsLinkGLTFMaterial

Function: integer llIsLinkGLTFMaterial( integer link, integer face );
Renvoie une valeur booléenne (un entier) qui est TRUE si le matériau  de la face est PBR et FALSE s'il s'agit d'une texture diffuse Blinn-Phong(en).

Commit 4ec624 : Ajout de llIsLinkGLTFMaterial.

llWorldPosToHUD

Function: vector llWorldPosToHUD( vector world_pos );
Retourne une position vectorielle qui indique où le centre d'un HUD devrait être positionné afin qu'il apparaisse directement au-dessus de world_pos dans le monde.

Commit 392d32 : Ajout de llWorldPosToHUD.
Commit 15dc81 : Quelques modifications apportées à llWorldPosToHUD. D'autres modifications pourraient être nécessaires.

Bug de téléportation

[Mantis 9212 ] : Un bug empêche la téléportation entre deux régions adjacentes.
La téléportation ne fonctionnait pas entre deux régions sur différentes instances si la cible était dans le champ de vision.
[Commit 614623 : mantis 9212 : quelques modifications apportées à LureModule et au transfert de messages.

ubODE moteur physique par défaut

ubODE devient le moteur physique par défaut dans bin/OpenSim.ini.example et bin/OpenSimDefaults.ini
Commit 988501 : Définir ubODE comme moteur physique par défaut

Mise à jour de libomv

Mantis 9213 : message d'erreur [SCENEGRAPH]: Problem processing action in ForEachSOG (Problème lors du traitement de l'action dans ForEachSOG).
Commit 676d76 : mantis 9213: mise à jour de libomv.

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.😉

Base de données

Traitement des UUID des objects pendant l'hypergrid

Questions

Si la prim possède un ensemble de données dans la base de données Asset de la grille d'origine et un ensemble de données différent dans la base de données de la grille d'arrivée, est-ce que les données de la grille d'arrivée remplaceraient celles de la grille de départ si on rezze la prim sur la grille d'arrivée ?
Lorsque vous réinitialisez quelque chose à partir de l'inventaire sur une autre grille, cela modifie le groupe auquel il appartient pour correspondre à l'endroit où vous le réinitialisez. Le code de réinitialisation pourrait-il également extraire le champ « propriétaire précédent » de la base de données OSGrid plutôt que celui de l'inventaire ?

Problème observé

Modification des UUID sur la grille d'arrivée, changement de propriétaire : L'UUID du « Propriétaire précédent » d'un objet appartenant à Obert Taham était celui d'une personne qui pourrait revendre l'idée dans sa boutique sur OSGrid. L'objet original est « non transférable », mais il est très facile de contourner cette restriction.
Le problème pourrait-il être causé par quelqu'un qui en a pris possession en mode Dieu ?

Réponses

Le code suppose que les UUID sont uniques dans l'univers, c'est une limitation de l'hypergrid.
Normalement, toutes les informations nécessaires sont dans l'inventaire. Les objets sont sérialisés dans l'inventaire. C'est en gros le même code que pour les OAR.
Toutefois Vincent Sylvester signale que la table inventoryitems ne comporte pas de champ lastownerID, seulement owner et creator. La table inventoryitems enregistre les détails relatifs aux biens personnels de l'avatar (assets). Le code du rezze est compliqué, il récupère en quelque sorte les données de l'inventaire et des assets pour construire le SOP, mais il n'y a pratiquement aucun code qui interagit réellement avec le dernier propriétaire pour le définir comme quelqu'un d'autre, cela n'apparaît que dans le contexte de l'identifiant de groupe. Vincent Sylvester dit qu'il peut se tromper mais ils pense que lors d'une téléportation hypergrid, l'utilisateur ne conserve pas les informations relatives aux assets provenant de la région d'où ils proviennent. Il se demande si les données de transfert sont extraite de la région où l'objet est rezzé. Parce que l'objet doit extraire le dernier propriétaire à partir d'autre chose que l'inventaire utilisateur.
Il y aurait 3 possibilités pour que l'UUID du dernier propriétaire change :

soit la région d'origine rapporte des données erronées,
soit il y a une interaction avec l'identifiant du groupe,
soit il s'agit potentiellement d'un objet dont le dernier propriétaire de la partie racine est corrompu d'une manière ou d'une autre.

Ce sont vraiment les seuls endroits qui interagissent pour construire le SOP qui sert de base à la demande de données du viewer.

Ubit Umarov a fait un test pendant la réunion avec un alt et il n'a pas observé de problème.
🏗️

Tests

Suppression de System.Drawing pour le remplacer par SkiaSharp

Vincent Sylvester a fait un test, il a supprimé System.Drawing et l'a remplacé par SkiaSharp. Il prépare une éventuelle suppression à venir de System.Drawing . SkiaSharp est ce que Microsoft recommande d'utiliser à la place mais cela semble moins facile à mettre en œuvre.
Cela semble fonctionner bien que cela va impliquer pas mal d'ajuster dans libomv. Les modification du code sont assez minimes. System.Drawing peut disparaître, tout ira bien.
Actuellement aucune raison de le remplacer System.Drawing tant que cela fonctionne correctement.
system.draw a en fait moins de dépendances que SkiaSharp. Les dépendances de SkiaSharp sont répertoriées sur Nuget : https://www.nuget.org/packages/SkiaSharp/#dependencies-body-tab
Seuls Windows et macOS sont pris en charge, il ne semble pas y avoir Linux.
🏗️

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-08-19