« Réunion du 03-12-2024 » : différence entre les versions
Aller à la navigation
Aller à la recherche
| Ligne 28 : | Ligne 28 : | ||
Le mode débogage inclut des informations utiles pour le développement, alors que le mode release se concentre sur la performance. | 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 === | |||
* 🏗️ | * 🏗️ | ||
Version du 5 décembre 2024 à 07:16
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.😉 |
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 :
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
- 🏗️
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 )
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[1] 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 : 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