Réunion du 03-12-2024

Changements du code de la semaine

Correction de bogues sur la nouvelle fonction llRezObjectWithParams

• Ajout de la fonction la semaine dernière
• Commit cd6efb : persistance du paramètre de chaîne de départ (de llRezObjectWithParams).
• Commit ecf2e0 : effacement du paramètre de chaîne de départ dans les autres cas de rez.
• Commit b1f573 : Correction de RezzerID
• Commit 49a428 : corriger le paramètre de vitesse lors d'un rezz avec paramètres.
• Commit e1dd99 : correction de la vérification de la distance d'un objet rezzé.

Croisement de région avec UbODE

• Commit 4b993d : modifier le point de chute des avatars lorsqu'ils sortent des limites de la région dans UbODE.
• Lorsqu'un avatar sort du cadre, ubode le place près du bord. Le code vérifie si le prochain mouvement à la vitesse courante l'enverra dans une autre région.
• Dans une direction, sans savoir pourquoi, l'avatar était placé trop loin du bord, ce qui l'empêchait de traverser la frontière en marchant.

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

Distance de rezz

Question de Cuga Rajal

• Est-ce que les changements de code de la semaine dernière vont entrainer des changements dans la distance de rez maximale ?
• Spécifications : https://wiki.secondlife.com/wiki/LlRezAtRoot

Réponse

• La nouvelle fonction utilise les mêmes critères. Ce qui a changé, c'est un bug dans le calcul de llRezObjectWithParams. récemment ajoutée.
• Les fonctions existantes n'ont pas été modifiées.
• La distance maximale de rez est de 10m

Configuration

Variables d'environnement Mono obsolètes

• Ubit Umarov a supprimé la variable d'environnement MONO_GC_PARAMS utilisée pour configurer le comportement du ramasse miettes de Mono. Elle n'est plus nécessaire dans le cadre de dotnet.
• De la même façon MONO_THREADS_PER_CPU ne peut plus être utilisé.

Variable d'environnement DOTNET_CLI_TELEMETRY_OPTOUT

NDLR  : DOTNET_CLI_TELEMETRY_OPTOUT permet aux utilisateurs de contrôler la collecte de données de télémétrie par les outils .NET. En définissant DOTNET_CLI_TELEMETRY_OPTOUT à 1 ou à true, vous indiquez que vous ne souhaitez pas participer à la collecte de télémétrie. Cela signifie que les outils .NET ne collecteront pas de données sur votre utilisation. Configuration sous Linux et macOS depuis le terminal : export DOTNET_CLI_TELEMETRY_OPTOUT=1 Configuration sous Windows : vous pouvez définir la variable d'environnement via les paramètres système ou en utilisant la commande suivante dans l'invite de commandes : set DOTNET_CLI_TELEMETRY_OPTOUT=1

Modules

Moteur physique : UbODE

Le problème

• Vincent Sylvester et Ubit Umarov se sont amusés à sauter dans des murs de briques la tête la première pendant un moment pour essayer de déboguer un crash physique.
• Ce crash semble causé par la configuration de la compilation . Depuis Dotnet la compilation en mode débogage semble faire apparaître des problèmes alors que la configuration en mode release semble correcte et ne provoque pas de crash.
• Le crash se produit alors que le système semble boucler à l'infini en interne et plante lors de l'allocation de la mémoire.

Mode débogage et mode release

NDLR  : La compilation de code est le processus de transformation du code source écrit par un développeur en un programme exécutable par un ordinateur. En mode débogage, le code est préparé pour faciliter le test et la correction des erreurs. En mode release, le code est optimisé pour être plus rapide et prêt à être distribué aux utilisateurs. Le mode débogage inclut des informations utiles pour le développement, alors que le mode release se concentre sur la performance.

Analyse du problème

• Ubit Umarov pense qu'Opensim devrait être compilé et exécuté en mode Release, même sur mono 6.x. Le mode débogage est très lent maintenant et le code est même très différent dans certains cas.
• Vincent Sylvester dit qu'il n'y a pas de backtrace[1], juste une terminaison du simulateur avec what() bad_alloc. Le problème se situe quelque part dans le code de bas niveau d'UbODE qui recevrait de mauvaises données du simulateur en provoquant un crash. C'est très loin, donc sans plus d'informations, il est presque impossible à déboguer, à moins de vouloir parcourir tout le code d'UbODE ligne par ligne. Maintenant il utilise les deux types de compilation (debug et release) et n'utilise le mode debug que lorsqu'il y a un problème.

NDLR  : bad_alloc : le programme a tenté d'allouer de la mémoire, mais cette allocation a échoué.

• Garbage Collector" (GC)[2] en mode debug n'est pas le même qu'en mode release.

La pile et limite de fichiers ouverts

• Ubit Umarov demande si Vincent Sylvester a déjà augmenter la taille de la pile pour UbODE. Il indique que dotnet utilise aussi beaucoup de pile pour éviter les allocations de GC[3], ce qui pourrait aggraver le problème de débordement de pile.
• Sous Linux, on peut augmenter la taille de la pile dans le script opensim.sh placé dans le dossier bin d'OpenSim. On peut aussi le faire dans la configuration générale de la machine quelque part dans le dossier /etc.
• Il est conseillé d'augmenter la pile quand il y a beaucoup de collisions. UbODE met toutes les données concernant les collisions sur la pile.
• On pourrait également augmenter la limite du nombre de fichiers ouverts en même temps par une application [4].

NDLR  : Dans les environnements de programmation, la pile [5]est une zone de mémoire utilisée pour stocker des informations temporaires, comme les variables locales et les adresses de retour des fonctions. Afficher les limites sous Linux ulimit -a Dans opensim.sh augmenter 1048576 pour augmeneter la taille de la pile à la ligne ulimit -s 1048576 On peut également changer la taille de la pile et la limite de fichiers ouverts dans le fichier /etc/security/limits.conf. Il est préférable de placer les configurations personnalisées dans le dossier limits.d/ plutôt que de modifier directement limits.conf. Cela permet de conserver les configurations par défaut intactes et de faciliter les mises à jour futures. Pour cela copiez et renommez le fichier limits.conf dans limits.d et modifier suivant les besoins.

Informations

OSCC 2024

• Programme des conférences : https://conference.opensimulator.org/schedule/. Deux sessions sont encore en cours de programmation au moment de la réunion.
• Les développeurs d'Opensim interviendront samedi 07 à 7h pour le plateau Core Dev et à 11h45 pour le Q&R VIP (Fuseau horaire PST )

NDLR  : Traduction du programme de l'OSCC 2024 en français et conversion des horaires à l'heure de Paris

Maintenance d'Osgrid

• Situation de la grille la semaine dernière.
• La grille est à nouveau hors ligne. Les services d'assets d'OSGrid sont toujours hors service et la grille a dû arrêter l'utilisation des assets par le public, la migration n'a pas aimé se dérouler en parallèle. Il semblerait qu'il y ait eu un problème avec la taille du cluster.
• OSgrid utilise Ceph[6] pour stocker ses données. Tous les assets sont dans un système de fichiers.
• En ce moment personne ne peut se connecter à Osgrid à part les utilisateurs qui ont le mode dieu (god). Les développeurs d'opensim ont le mode dieu sur Osgrid par tradition. Cela devrait apparaître sur le profil.

NDLR  : Extraits de l'article posté sur le site d'Osgrid [7] traduits avec DeepL[8]. Retour à la maintenance par Osgrid|Publié le 30 novembre 2024 Malheureusement, la nuit dernière, la restauration incrémentale a échoué, poussant le cluster dans un état inutilisable. Il a commencé à refuser activement toute nouvelle connexion et pour éviter des dommages, la grille a été à nouveau mise hors ligne et mise en mode maintenance. [...]. Questions et réponses : Pourquoi ne pouvez-vous pas nous dire immédiatement ce qui a échoué ? ===================================================================== Parce que nous sommes des techniciens et non des médiums informatiques. Nous observons un problème, essayons d'en trouver la cause et voyons si nous pouvons le résoudre. Mais tout n'est pas simple et évident, et même si les pannes sont évidentes, il faut parfois du temps pour en trouver l'origine. Le réseau s'éteint et nous envoyons un message d'alerte. Nous savons que le cluster est très sollicité. Il est arrivé que des problèmes soient dus à cette charge de travail, alors que l'écriture d'un processus s'interrompait. Mais la raison d'une défaillance n'est pas toujours évidente. Il peut s'agir d'un manque de ressources, d'une fuite de mémoire, d'une attaque contre nos serveurs, d'une panne de réseau, d'un code cassé, d'un problème de système ou de configuration, ou d'un tas d'autres choses. Mais ce sont des actifs que nous traitons. La priorité numéro 1 est donc de protéger vos « biens ». Nous ne mettons pas le réseau hors service si nous n'en ressentons pas le besoin. Combien de temps cela prendra-t-il ? ==================================== Nous ne pouvons pas répondre à cette question. L'hypothèse la plus plausible est que nous avons probablement rouvert le site trop tôt. [...] Il ne s'agit pas d'un nouveau problème. Nous ne pouvons que vous demander de tenir bon. [...]

Réunion

• La réunion de ce jour s'est déroulée sur http://hg.zetaworlds.com/OpenSim
• La réunion de la semaine prochaine c'est à dire du 10 décembre 2024 aura lieu au même endroit si Osgrid est encore hors-ligne.

Source

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