Réunion du 05-03-2024

Changements du code de la semaine

• Courts changements de code
  • Encodage AES [1],
  • Correction du dernier patch : [2]
  • Correction de mantis 9118 : osGet/SetPrimitiveParams -régression[3]
  • Remplacement du nom de fonction osget*InventoryKey en osget*inventoryItemKey.
  • Ajout des fonctions osGetSitTargetPos(), osGetSitTargetRot() [4] ( Auteur Jeff Kelley)

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

Scripts

• La fonction OsGetPrimitiveParams a été corrigée.
• La fonction osgetInventoryKey devient osgetinventoryItemKey : la clé renvoyée est la clé de l'objet, pas la clé de l'asset comme avec la fonction LlGetInventoryKey.
• Ajout des fonctions osGetSitTargetRot() et osGetSitTargetPos()

Archivage

AOR : assignation des propriétaires et des créateurs

• Question : Comment les noms des créateurs Hypergrid sont-ils trouvés au chargement d'un OAR ?
• Réponse : Le code actuel essaie de préserver le créateur. L'UUID et le nom du créateur et l'URL de sa grille d'origine sont sauvegardées dans l'OAR. C'est ce qui est nécessaire pour interroger un profil. Le chargement de l'OAR appelle la grille distante et obtient le nom de l'avatar. Seule la photo est récupérée avec quelques données de profil.
• Question : Mais si l'OAR a été fait sur la grille où l'OAR est chargé, est-ce qu'il conserve aussi l'uuid, le nom et l'url de la grille ?
• Réponse : Cela devrait être ainsi mais, il est possible que localement ce ne soit pas le cas. Il est même probable que pour le créateur local l'OAR ne stocke que l'UUID et donc quand un OAR est déplacé, les données ne correspondent pas à un compte local. Il y a aussi le cas des installations non hypergrid, dans ce cas, les OAR ne peuvent pas avoir toutes les informations sur le créateur.Les données des créateurs devraient être conservées et stockées pour chaque primitive, en théorie, on pourrait construire des objets avec des pièces créées par d'autres.
• Problème : La seule chose qui modifie les données du créateur est le paramètre home de la commande save oar, mais cela devrait tout stocker, donc peut-être que la fonction restore n'extrait pas les données correctement. À résoudre (TODO).
• Question : est-ce que de la même façon l'uuid et le nom du propriétaire et l'url de sa grille d'origine sont sauvegardés dans l'OAR.?
• Réponse : le propriétaire peut être remplacé. Les OAR sont conçus pour les sauvegardes, moins pour le partage.
• Propriété intellectuelle : le code peut donc être contourné, les options permettent de remplacer toutes les données originales du créateur ce qui est aussi faisable au niveau du serveur. Mais, les données d'un créateur d'objets liés sont cachées en XML dans le blob dans la base de données, ce n'est pas aussi simple à faire.
• Informations complémentaires : aide sur les commandes save OAR et load OAR

save oar [-h|--home=<url>] [--noassets] [--publish] [--perm=<permissions>] [--all] [<chemin OAR>]
Sauvegarde les données d'une région dans une archive OAR.

-h|--home=<url> ajoute l'url du service de profil aux informations utilisateur enregistrées.
--noassets empêche l'enregistrement des assets dans l'OAR.
--publish enregistre un OAR dépourvu des informations relatives au propriétaire et au dernier propriétaire.
   Lors du rechargement, le propriétaire du domaine sera le propriétaire de tous les objets.
   Ceci est utile si vous mettez à disposition des OAR qui pourraient être rechargés sur la même grille que celle à partir de laquelle vous avez publié.
--perm=<permissions> empêche les objets dont les permissions sont insuffisantes d'être enregistrés dans l'OAR.
   <permissions> peut contenir un ou plusieurs de ces caractères : "C" = Copier, "T" = Transférer
--all enregistre toutes les régions du simulateur, au lieu de la région actuelle.
Le chemin OAR doit être un chemin de système de fichiers. S'il n'est pas indiqué, le fichier OAR est sauvegardé dans region.oar dans le répertoire courant.

load oar [-m|--merge] [-s|--skip-assets] [--default-user "Nom d'utilisateur"] [--merge-terrain] [--merge-parcels] [--mergeReplaceObjects] [--no-objects] [--rotation degrés] [--bounding-origin "<x, y,z>"] [--bounding-size "<x,y,z>"] [--displacement "<x,y,z>"] [-d|--debug] [<Chemin OAR>]
Charge les données d'une région à partir d'une archive OAR.

--merge fusionne l'OAR avec la scène existante (supprime le chargement du terrain et des informations sur les parcelles).
 Options avec --merge
  --merge-terrain charge également le terrain, en remplaçant l'original
  --merge-parcels charge également les parcelles, en les fusionnant avec l'original
  --mergeReplaceObjects si la scène contient un objet avec le même identifiant, le remplace
       sans cette option, le chargement de cet objet est ignoré
--skip-assets chargera l'OAR mais ignorera les assets qu'il contient.
--default-user utilisera cet utilisateur pour tous les objets ayant un propriétaire dont l'UUID n'est pas trouvé dans la grille.
--no-objets supprime l'ajout d'objets (bon pour charger uniquement le terrain).
--rotation spécifie la rotation à appliquer à l'aor . Spécifiée en degrés.
--bounding-origin ne place que les objets qui, après déplacement et rotation, se trouvent à l'intérieur du cube de délimitation dont la position commence à <x,y,z>. La valeur par défaut est <0,0,0>.
--bounding-size spécifie la taille du cube de délimitation. La valeur par défaut est la taille de la région de destination et ne peut être supérieure à celle-ci.
--displacement ajoute cette valeur à la position de chaque objet chargé.
--debug oblige l'archiveur à afficher des messages sur l'emplacement de chaque objet.

Le chemin peut être un emplacement du système de fichiers ou un URI.
  S'il n'est pas indiqué, la commande recherche un OAR nommé region.oar dans le répertoire courant.  [--rotation-center "<x,y,z>"] était une option, maintenant elle ne fait rien et sera bientôt supprimée. Lorsqu'un OAR est chargé, les opérations sont appliquées dans cet ordre :
1 : Rotation (autour du centre de la région de l'OAR entrant)
2 : Recadrage (un cube de délimitation avec origine et taille)
3 : Déplacement (définition des coordonnées de décalage dans la région de destination)

Tests

Nouveaux Xunit

• Vincent.Sylvester pense que les tests s'exécuteront sur linux et qu'ils fonctionnent certainement très bien sur windows. Il ne peut pas tester sur Mac. Il va affiner cela dans les semaines à venir et écrire quelques tests.

vérification des migrations

• Il a terminé une routine de vérification des migrations qui vérifie les tables de la base de données existante par rapport à un bon schéma connu et qui pique une colère s'il y a divergence. Actuellement, la routine s'exécute à la fin de chaque migration. C'est une vérification finale qui test si tout est comme il se doit avant le démarrage.
• C'est pour éviter qu'un problème de migration ne casse des choses et n'alerte l'utilisateur sur le fait qu'il doit peut-être corriger manuellement ses tables.

Viewers

Sharpview

• Nouvelle version disponible pour Linux et Windows : http://animats.com/sharpview/releases/release-0.6.0.html
• Pour télécharger, nom d'utilisateur "devs", mot de passe "thread".
• En cas de panne, envoyez un mail à "info@animats.com".
• À utiliser avec un avatar léger. Cette version du viewer permet les passages entre deux régions mais, sur une simulation OpenSim récente comme les régions Ubittest (OpenSim 0.9.3.0 Nessie Dev 854f672 mardi 6 mars ) Ubittest2 d'Osgrid ( OpenSim 0.9.3.0 Nessie Dev 0d73a81 mardi 6 mars).
• Joe Magarac est prêt à travailler pour rendre Sharpview compatible avec OpenSimulator. Mais il a besoin de savoir avec quelle version d'OpenSimulator son viewer doit être compatible. Actuellement, Sharpview ne supporte que les simulateurs affiliés à OSGrid, cela permet une certaine standardisation.
• Réponse : Si cela fonctionne avec les versions release et master dev et que les anciennes versions ne fonctionnent pas, c'est à l'administrateur de la région d'y remédier. Les administrateurs d'Osgrid ont décidé de suivre le code des développeurs. Mais, il est possible que certains simulateurs 0.7 essaient encore de se connecter sur Osgrid.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-03-05