Réunion du 02-01-2024

De OSWiki
Aller à la navigation Aller à la recherche

Changements du code de la semaine

Commit cc6a2d

  • Commit : [1]
  • Message : ajout d'un champ optionnel pour l'url du profil web dans gridinfo, avant que nous n'oubliions à nouveau comment le faire.
  • Il suffit d'ajouter dans Robust.ini
 http://webprofilesurl:ItsPort?name=[AGENT_NAME]
  • Les viewers convertissent [AGENT_NAME] en firstname.lastname. Ubit Umarov suppose que seul Osgrid l'utilise.

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


Modules

Modules de physique

  • Modules de physique : BulletSim [2] et UbODE[3]
  • Question : pourquoi les utilisateurs d'OpenSim privilégient très souvent BulletSim ?
  • Raisons invoquées :
    • Les meshs
    • Les véhicules sont configurés pour BulletSim : cela signifie qu'ils ont été testés et réglés pour BulletSim.
  • UbODE
    • apporte plus de fonctionnalités pour les véhicules que BulletSim.
    • Il faut simplement que les scripts soient réglés pour ne pas se comporter de manière érronée.
    • Il y a aussi des différences dans la dynamique, parce que l'interprétation des mêmes paramètres est différente ( sur tous les moteurs ).UbODE, Bullet et Halcyon ont tous leurs propres conceptions des véhicules.
  • Les meshs :
    • La facilité d'utilisation des meshs est due à la façon dont ils ont été téléchargés plus qu'au moteur physique. L'utilisateur est la source des problèmes.
    • Une bonne option pour utiliser des meshes mal chargés est de mettre le mesh fantôme et d'utiliser les prims pour les collisions, ce qui pourrait même être moins contraignant pour la physique.
    • Comment charger un mesh : http://opensimulator.org/wiki/How_To_Upload_Mesh
    • On peut aussi utiliser des tutoriels pour réaliser de bons maillages (Ndlr : pas de trou, nombre de vertex faible, régularité, supprimer les doublons etc.).

Statistiques

Temps de fonctionnement d'une région

  • Question de Kayaker : J'essaie d'afficher le temps de fonctionnement sur une page WEB et j'ai utilisé regions.last_seen mais ce nombre semble se réinitialiser souvent. Est-ce qu'il y a un moyen de savoir depuis combien de temps une région est en ligne sans avoir à plonger dans la console ?
  • Regions.last_seen est mis à jour à chaque fois que la région envoie une maptile.
  • Il suffit d'ajouter un champ d'horodatage automatique dans la table lorsque l'entrée est créée, si la région est fermée correctement, l'entrée sera supprimée.
  • Il existe quelques interfaces de statistiques, comme Webstats, jsonsimstats et datasnapshot, le temps de fonctionnement d'une région est sans doute dans l'une d'entre-elles. Les deux premières doivent être activées dans le fichier ini.
  • Code proposé sur le wiki OpenSimulator [4]

Touver la chaîne JSON des statistiques d'une la région

  • Information : il faut utiliser regionurl/jsonstats ou regionurl/jsonSimStats pour obtenir une chaîne JSON du type :
 {"Dilatn" : "1", "SimFPS" : "55", "PhyFPS" : "55", "AgntUp" : "0", "RootAg" : "0", "ChldAg" : "0", "NPCAg" : "0", "Prims" : "1547","AtvPrm":"0","AtvScr":"60","ScrLPS":"0","ScrEPS":"1","PktsIn":"61","PktOut":"17","PendDl":"0","PendUl":"0","UnackB":"0","TotlFt":"18. 18","NetFt":"0","PhysFt":"0.01","OthrFt":"0. 01", "AgntFt" : "0", "ImgsFt" : "0", "FrameDilatn" : "1", "Logging in Users" : "0", "GeoPrims" : "1099", "Mesh Objects" : "448", "Script Engine Thread Count" : "0", "RegionName" : "UbitTest2", "Util Thread Count" : "0", "System Thread Count" : "69", "System Thread Active" : "1", "ProcMem" : "450768", "Memory" : "50", "Uptime" : "14. 20:14:54.5251042", "Version" : "OpenSim 0.9.3.0 Nessie Dev dce2f13"}.
  • Ndlr : mes tests dans la console d'un serveur Ubuntu:
curl <domaine>:<port de la région>/jsonstats

Ne donne rien 

curl <domaine>:<port de la région>/jsonSimStats

J'obtiens le même type de chaîne JSON que 'Ubit Umarov

Ensuite, par exemple en php, on peut obtenir le temps depuis la connexion de la région en décodant la chaîne JSON avec json_decode [5]

Exemple : 

 <?php 
//Renseigner domaine et port comme il se doit
 $domaine = "<domaine du simulateur>";
 $port = "<port du simulateur>";
 $url = "http://".$domaine.":".$port."/jsonSimStats"; 
 $json = file_get_contents($url);
 $result = json_decode($json, true);
 if(isset($result))
  {
      echo "Temps de connexion de la région ".$result['RegionName']." : ". $result['Uptime'];
  }else{
      echo "Erreur";
  }

Résultat : "14. 20:14:54.5251042"

Pour une région que je viens de relancer j'obtiens : "00:00:48.5444650"

Donc 14 devrait être le nombre de jours et ensuite on a les heures, les minutes les secondes. Je n'ai pas dû activer jsonSimStats dans les fichiers ini mais, l'interface est peut-être activée par défaut.

On peut aussi activer Webstats dans OpenSim.ini [6]. On obtient une page web de statistiques sur la région à l'adresse <domaine>:<port de la région>/SStats/.

Bugs

Passage de frontière entre deux régions

  • Problème : Si l'on passe une frontière entre deux régions, l'avatar continue de se déplacer sans intervention du clavier. Firestorm et Sharpview montrent tous deux ce comportement. Aucune mise à jour ne serait envoyée au viewer depuis la région d'origine pour arrêter l'avatar.
  • Raisons invoquées  :
    • La téléportation a échoué quelque part, un UDP a été perdu. Il y aurait du lag ou un problème avec BulletSim. Ubode ne provoque pas de problème au-delà de ce qui l'est par défaut, la question est, pourquoi certains utilisateurs s'en tiennent toujours à BulletSim ?
    • La vitesse doit être maintenue au passage entre deux régions, il se peut qu'il faille indiquer que l'avatar ne bouge plus. Si vous lancez un objet au-dessus d'une frontière, il continuera aussi à se déplacer. La vitesse ne tombe pas à zéro, même chose avec les avatars, cela aide la transition. Si l'on repart d'une vitesse nulle, chaque traversée sera assez brutale.
    • Pour les tests il faut donc choisir des ordinateurs de test qui fonctionnent sur le même datacenter. Car, dans certains cas, les passages de frontière ne peuvent jamais fonctionner. Pour que les passages de frontière fonctionnent, les versions OpenSim doivent être identiques et sur le même datacenter (et/ou faible latence).
    • Les croisements de véhicules fonctionnent suffisamment bien pour que l'on puisse traverser des centaines de régions en bateau sans trop de problèmes.
    • Les HUD peuvent faire échouer un passage de frontière.
  • Scripts : Les états des scripts entre simulateurs sont toujours problématiques, il y a des moyens de forcer une réinitialisation pour les faire fonctionner après une traversée vers une région "inconnue".

Projets en cours / Infos

Vidéos de l'OSCC 2023

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-01-02

Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_02-01-2024&oldid=7667 »