« Réunion du 02-01-2024 » : différence entre les versions
Aller à la navigation
Aller à la recherche
Ligne 58 : | Ligne 58 : | ||
* '''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. | * '''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 ''' : | * '''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 Bullet. | ** La téléportation a échoué quelque part, un UDP a été perdu. Il y aurait du lag ou un problème avec Bullet. 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 à Bullet ? | ||
** La vitesse doit être maintenue au passage entre deux régions, il se peut qu'il faille indiquer que l'avatar a arrêté de bouger. 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. | ** La vitesse doit être maintenue au passage entre deux régions, il se peut qu'il faille indiquer que l'avatar a arrêté de bouger. 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 OpneSim doivent être identiques et sur le même datacenter (et/ou faible latence). | ** 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 OpneSim doivent être identiques et sur le même datacenter (et/ou faible latence). |
Version du 3 janvier 2024 à 08:30
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 |
Code général
Scripts
Base de données/Stockage /fsassets
Modules
Statistiques
Temps de fonctionnement d'une région
- Question de Kayaker : J'essaie d'afficher le temps de fonctionnement sur une grille 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 un 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 [2]
Touver la chaîne JSON des statistiques d'une la région
- Ubit Umarov dit qu'il faut utiliser regionurl/jsonstats ou regionurl/jsonSimStats pour obtenir une chaîne JSON du type :
<source lang="json">
{"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"}.
</source>
- 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 [3]
Exemple : <source lang="php">
<?php $json = '{"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"}'; $result = json_decode($json, true); echo $result['Uptime'];
</source> 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 du activer jsonSimStats dans les fichiers ini mais, 'linterface est peut-être activée par défaut.
On peut aussi activer Webstats dans OpenSim.ini [4]. 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
- 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 Bullet. 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 à Bullet ?
- La vitesse doit être maintenue au passage entre deux régions, il se peut qu'il faille indiquer que l'avatar a arrêté de bouger. 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 OpneSim 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 de script 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".