Réunion du 19-04-2022

Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2022-04-19

Introduction

[11:01] Andrew Hellershanks : Bonjour à tous.

[11:02] Ubit Umarov : Bonjour Andrew.

[11:02] Selby.Evans @grid.kitely.com:8002 : Oui -- Peut-être un internet lent - bien que le mien soit assez rapide.

[11:02] Andrew Hellershanks : J'espère que tout le monde a profité du week-end de Pâques.

[11:02] Ubit Umarov murmure : oh c'était Pâques ?

[11:02] Ubit Umarov : :)

[11:02] Selby.Evans @grid.kitely.com:8002 : Bonjour Andrew.

[11:04] Ubit Umarov : wc gavin.Hird, assieds-toi

[11:04] Ubit Umarov : oups

[11:05] Ubit Umarov : wc gavin.Hird , assieds-toi (take 2 )

[11:05] Andrew Hellershanks : :)

[11:05] Gavin.Hird @grid.xmir.org:8002 : mon viewer ne se comporte pas comme il le devrait ici.

[11:05] Andrew Hellershanks : Que fait-il (ne fait pas ?) ?

[11:05] Ubit Umarov : ou pas... c'est sur un mac.

[11:05] Gavin.Hird @grid.xmir.org:8002 : les animations ne démarrent pas.

[11:05] Ubit Umarov : :p

[11:06] Gavin.Hird @grid.xmir.org:8002 : tu as probablement cassé quelque chose.

[11:06] Ubit Umarov : ou tu l'as fait.

[11:06] Ubit Umarov : :)

[11:06] Gavin.Hird @grid.xmir.org:8002 : Je n'ai pas beaucoup modifié cette version depuis des semaines, mais la version 3.0 est en cours d'élaboration.

[11:07] Ubit Umarov : J'ai fait quelques changements dans le mouvement de l'avatar.

[11:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Allez, pas de blagues sur les Mac, soyons gentils, au moins ce n'est pas arch linux xD

[11:07] Gavin.Hird @grid.xmir.org:8002 : Je le savais.

[11:07] Ubit Umarov : à savoir le traitement des paquets de mise à jour de l'agent.

[11:07] Gavin.Hird @grid.xmir.org:8002 : Ne faites pas ça.

[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002 :En fait, le dernier essai est bon, les premières tentatives étaient un peu bancales.

[11:08] Andrew Hellershanks : non, Ubit. Ca arrive.

Discussion à propos de llSetForce et llSetBuoyancy

• 0008990: llSetForce() has no effect on avatar when wearing a scripted attachment
• llSetForce/fr : Applique une force à l’objet contenant le script (si l’objet est physique)
• llSetBuoyancy : Paramètre la capacité de flottaison d’une prim ou d’un objet. L’objet doit être physique.
• Convoar : Application en ligne de commande pour convertir les fichiers OAR d'OpenSimulator en fichier de scène GLTF.
• GlTF : format de fichier scènes et modèles 3D utilisant le format JSON (JavaScript Object Notation).
• llPushObject : Applique l'impulsion et l'impulse_ang à l'objet cible

[11:08] Ubit Umarov : à propos de cette réunion et aussi sur mantis, il y a eu une discussion à propos de llSetForce sur les avatars.

[11:09] Ubit Umarov : également llBuoyancy et similaires.

[11:09] Ubit Umarov : en fait ces fonctions ne peuvent pas fonctionner aussi bien sur opensim.

[11:10] Ubit Umarov : parce que l'avatar est presque tout le temps sous l'effet d'un moteur qui essaie soit de le faire bouger à une vitesse constante ( incrémentée de zéro si on peut dire) ou de lui faire garder la même position.

[11:10] Ubit Umarov : donc l'idée d'une force constante comme llSetForce l'implique, ne peut pas fonctionner.

[11:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : Pas sans retravailler le code de la physique ou faire des modifications.

[11:11] Ubit Umarov : en fait, en regardant sur SL, cela ne fonctionne pas non plus très bien là-bas.

[11:11] Misterblue Waves : Je suis en train de construire une nouvelle version de Convoar -- la validation GLTF est plutôt stricte et MesherizerR crée des sculptures avec des sommets dont les normales sont toutes nulles :-(

[11:11] Ubit Umarov : simplement faire "quelque chose", ce n'est pas très fiable.

[11:11] Andrew Hellershanks : Il n'y a pas un moyen d'additionner les forces ?

[11:12] Andrew Hellershanks : Bonjour, Cuga.

[11:12] Ubit Umarov : il semble que le moteur de l'avatar SL ait des moments de repos, où une telle force peut faire bouger les choses.

[11:12] Misterblue Waves : additionner les deux, c'est ce que les moteurs physiques essaient de faire.

[11:12] Ubit Umarov : nous ne commandons pas l'avatar par la force.

[11:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Andrew, c'est aussi ce que j'ai pensé en premier lieu, mais ce n'est pas aussi logique qu'on pourrait le croire.

[11:12] Cuga.Rajal @rajal.org:9000 : Bonjour.

[11:12] Ubit Umarov : nous lui disons que nous voulons une certaine vitesse.

[11:13] Ubit Umarov : il utilisera la force dont il a besoin :)

[11:13] Ubit Umarov : dans le monde réel, nos mouvements sont essentiellement déterminés par des forces.

[11:13] Vincent.Sylvester @hg.zetaworlds.com:8002 : L'explication la plus simple est que l'avatar essaie constamment de s'échapper et que nous le mettons essentiellement en cage, c'est l'objectif principal. Ajouter ensuite un objectif secondaire ou une cible signifierait aller à l'encontre de tout ce qui est conçu pour garder l'avatar sous contrôle.

[11:14] Ubit Umarov : la friction est ce qui permet aux choses de rester stables, comme lorsqu'on est arrêté etc. etc.

[11:14] Ubit Umarov : malheureusement la friction sur les moteurs n'est pas bonne, elle ne peut pas être utilisée comme ça.

[11:15] Vincent.Sylvester @hg.zetaworlds.com:8002 : Nous disons à l'avatar, va là, reste là, lui dire de "se déplacer" quelque part signifie mettre à jour la cible constamment alias llPushObject.

[11:15] Ubit Umarov : pour avoir un avatar facile à contrôler, il faut utiliser un moteur plus simple et qui se comporte bien.

[11:15] Ubit Umarov: llpushobject agit sur les avatars

[11:15] Misterblue Waves : l'avatar est soit en mouvement (marche ou vol), soit immobile. Quand il est immobile, il y a beaucoup de mécanismes logiques dans tous les moteurs physiques qui essaient d'empêcher l'avatar de glisser.

[11:16] Ubit Umarov : parce qu'il y a des hacks pour désactiver temporairement un tel moteur...

[11:16] Misterblue Waves : un avatar debout sur une surface inclinée ne devrait pas glisser.

[11:16] Misterblue Waves : mais il devrait bouger lorsqu'il se tient sur une surface en mouvement.

[11:16] Andrew Hellershanks : Cela devrait dépendre du degré d'inclinaison :)

[11:16] Ubit Umarov : bien mais la friction des moteurs est mauvaise pour en dépendre comme nous le faisons dans la vie réelle.

[11:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : et aussi, cela désactive également tous les moteurs, donc vous ne pouvez pas bouger l'un ou l'autre ou très mal.

[11:16] Misterblue Waves : et appliquer des forces après toute cette logique est délicat.

[11:17] Ubit Umarov : surtout llSforce qui est supposé être une force constante.

[11:17] Ubit Umarov : llSetForce...

[11:17] Ubit Umarov : pareil pour les choses angulaires [1]

[11:18] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce serait bien que llSetForce fonctionne comme spécifié étant donné ce que cela permettrait de faire, mais cela signifierait beaucoup de travail pour essayer de trouver une meilleure façon d'intégrer une force constante dans un système conçu pour les empêcher.

[11:18] Ubit Umarov : en fait les régions ont peu de contrôle sur les angles des avatars.

[11:18] Ubit Umarov : il n'y a pas de spécification[2] pour les avatars.

[11:18] Vincent.Sylvester @hg.zetaworlds.com:8002 : llPushObject fonctionne un peu et on peut en tirer quelques fonctionnalités minimales, mais à moins de vouloir recoder un moteur physique entier, llSetForce est un peu hors de portée.

[11:19] Ubit Umarov : comme je le disais, il semble que la fonction agisse sur SL quand le moteur de leur avatar ne regarde pas.

[11:19] Misterblue Waves : ce sont tous des arguments défensifs, cependant... le vrai problème est que LL (Linde Lab) a défini un fouillis de fonctions de force pour les objets et les avatars et nous sommes coincés à essayer d'implémenter ce qu'ils ont mis ensemble.

Modification du mouvement de l'avatar

• BulletSim (en) : BulletSim est le module pour OpenSimulator qui crée la physique du monde virtuel en utilisant le moteur physique Bullet. Ce module fournit une physique de haute performance ainsi que des performances de véhicules physiques compatibles avec Second Life.
• udODE : moteur physique
• Journal des commits OpenSim

[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002 : L'examen de cette question a apporté d'autres améliorations.

[11:19] Ubit Umarov : je suppose que c'est parce qu'ils ont oublié de couper le fil de l'attachement.

[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002 : Une modification du mouvement est attendue, surtout dans master dev, le comportement actuel semble plus précis qu'avant.

[11:20] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai eu un peu de mal avec les valeurs des constantes, mais nous y sommes arrivés à la fin.

[11:20] Ubit Umarov : comme je l'ai dit, j'ai changé (encore) le traitement de la mise à jour de l'agent.

[11:20] Ubit Umarov : c'est ainsi que le viewer commande les mouvements de l'avatar.

[11:21] Ubit Umarov : c'était pour que l'animation de pré-saut fonctionne enfin comme prévu.

[11:21] Misterblue Waves : Je n'ai pas joué avec les constantes de BulletSim -- elles sont "assez bonnes" mais pas aussi bonnes que dans ubODE.

[11:21] Ubit Umarov : amusant j'ai fait ça maintenant que fs (Firestorm)[3] a une option par défaut pour ne pas faire de pré-saut :)

[11:21] Ubit Umarov : ok, je vais voir si je peux le montrer.

[11:22] Ubit Umarov : prêt ?

[11:22] Ubit Umarov : regarde-moi.

[11:22] Ubit Umarov : C'est ça.

[11:22] Ubit Umarov : lol

[11:22] Ubit Umarov : Vous avez remarqué une différence ?

[11:22] Cuga.Rajal @rajal.org:9000 : le pré-saut a l'air bien !

[11:22] Andrew Hellershanks : Recommence pour voir ?

[11:23] Ubit Umarov : oui, comme prévu, les genoux se sont pliés en même temps que nous nous sommes arrêtés.

[11:23] Ubit Umarov : le mouvement vers le haut ne se produit qu'après cela.

[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Avant, on sautait instantanément et l'animation de l'accroupissement et de l'accumulation d'énergie se faisait en plein vol. Maintenant, il fait d'abord l'animation et ensuite il saute, donc l'animation et le mouvement réel sont synchronisés.

[11:23] Andrew Hellershanks : Bien. Flexion du genou avant le saut.

[11:23] Cuga.Rajal @rajal.org:9000 : Est-ce que vous devez ajuster les préférences de FS pour faire ça ?

[11:23] Ubit Umarov : sur le code précédent, le pré-saut avait lieu alors que nous étions déjà en train de monter.

[11:23] Ubit Umarov : laid

[11:24] Ubit Umarov : il faut juste désactiver le quickjump.

[11:24] Cuga.Rajal @rajal.org:9000 : ah

[11:24] Ubit Umarov : c'est avec quickjump :

[11:24] Ubit Umarov : voir ? direct simple jump

[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ubit a dit qu'il y a un paramètre de saut rapide dans Firestorm qui est activé par défaut, mais j'ai réinitialisé mon dossier %appdata% firestorm hier et pour moi le paramètre n'est pas activé donc je ne suis pas sûr de ce qui se passe ici, mais je pense qu'il peut ne pas être activé par défaut.

[11:25] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suis sûr qu'un utilisateur ou un développeur de Firestorm peut vérifier cela mieux que moi.

[11:25] Cuga.Rajal @rajal.org:9000 : J'essaye de le trouver dans les préférences.

[11:25] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sous Mouvement de l'avatar

[11:25] Ubit Umarov : pour supporter cela, j'ai dû changer un peu la logique.

[11:25] Ubit Umarov : j'ai même ajouté une commande Jump à la physique.

[11:26] Ubit Umarov : c'est une simple poussée.

[11:26] Ubit Umarov : avec ses propres constantes d'échelle.

[11:26] Cuga.Rajal @rajal.org:9000: Move & View -> Movement? ( Déplacement et vue -> Mouvement ?)

[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : Dans Firestorm c'est sous Avatar->Mouvement->Saut rapide (Avatar->Movement->Quick jump), d'autres viewers peuvent l'avoir ailleurs.

[11:27] Ubit Umarov : oui, il y en a aussi dans les préférences.

[11:27] Cuga.Rajal @rajal.org:9000 : Je l'ai, dans le menu et non dans les préférences.

[11:27] Ubit Umarov : j'ai aussi changé la façon dont certaines animations spéciales s'arrêtent.

[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : FSIgnoreFinishAnimation dans les paramètres de débogage.

[11:28] Ubit Umarov : en fait les viewers doivent envoyer une information sur la fin de l'animation.

[11:28] Ubit Umarov : NON

[11:28] Ubit Umarov : pas cela

[11:28] Ubit Umarov : arrêtez de deviner :p

[11:28] Vincent.Sylvester @hg.zetaworlds.com:8002 : FSIgnoreFinishAnimation : Désactiver l'attente pour le pré-saut ou l'atterrissage. Crédit à Zwagoth Klaar pour avoir codé ceci.

[11:28] Ubit Umarov : en fait il l'utilise mais c'est tordu.

[11:29] Ubit Umarov : le saut rapide tue aussi certaines animations d'atterrissage.

[11:29] Ubit Umarov : comme celle où on se retrouve à plat sur le sol lors d'un atterrissage difficile.

[11:29] Andrew Hellershanks : pourquoi est-ce que ça tue l'animation d'atterrissage ?

Bug détecté dans certains viewers ?

• Firestorm Viewer
• Viewers compatibles
• BOM

[11:29] Gavin.Hird @grid.xmir.org:8002 : est-ce un paramètre spécifique à FS ?

[11:30] Ubit Umarov : je pense que oui gavin.Hird

[11:30] Gavin.Hird @grid.xmir.org:8002 : alors pourquoi concevons-nous pour FS ?

[11:30] Ubit Umarov : en fait, j'ai fait en sorte que cela fonctionne aussi.

[11:30] Gavin.Hird @grid.xmir.org:8002 : est-ce que c'est le viewer officiel d'Opensim ?

[11:30] Misterblue Waves : le meilleur que nous ayons aujourd'hui.

[11:30] Gavin.Hird @grid.xmir.org:8002 : Je m'en vais

[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il n'y en a pas d'officiel

[11:30] Ubit Umarov : comme je l'ai dit, les viewers envoient une information lorsqu'ils terminent certaines animations.

[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : Nous avions Hippo

[11:31] Ubit Umarov : comme le pré-saut, et ceux qui servent à l'atterrissage.

[11:31] Ubit Umarov : opensim avait un hard timer, en fait jamais correct.

[11:32] Ubit Umarov : ce timer est maintenant une limite supérieure, cet ordre du viewer arrête l'animation.

[11:32] Cuga.Rajal @rajal.org:9000 : en faisant des allers-retours entre SL et OS, le mouvement de saut est l'une des choses les plus visibles.

[11:33] Cuga.Rajal @rajal.org:9000 : Je pense que c'était un bon choix pour travailler dessus.

[11:33] Ubit Umarov : donc c'est quelque chose qui nous manquait aussi.

[11:33] Ubit Umarov : en faisant ça, et pour répondre à Gavin, le hack FS pour quickjump a aussi fonctionné.

[11:34] Ubit Umarov : pas à cause du hack de fs, mais parce que nous ne le faisions pas correctement.

[11:34] Andrew Hellershanks : et pourquoi ?

[11:34] Ubit Umarov : En fait, je me suis plaint à FS.

[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce que je pense qu'il se passe avec FS, c'est que le comportement par défaut est celui du "saut rapide", à moins que vous ne gériez les paquets correctement, auquel cas vous devez utiliser le saut rapide pour revenir à ce que vous avez vu avant ces changements.

[11:34] Ubit Umarov : parce qu'avec quickjump FS envoie simplement ce drapeau de fin d'animation sur tous les paquets.

[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : Donc non, nous ne développons pas pour FS, nous analysons juste les paquets correctement en fonction de ce qui est reçu, ce que les viewers envoient dépend toujours d'eux.

[11:35] Ubit Umarov : cela dépend de l'activité et peut aller de 1 par seconde à 90 par seconde par avatar.

[11:35] Ubit Umarov : cela a tué nos accélérateurs.

[11:36] Ubit Umarov : je me suis plaint... ce drapeau ne devrait être activé que si nécessaire.

[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002 : Eh bien, une toute autre série d'amusements menant à l'ensemble de trucs liés au battement de cœur, ce qui me préoccupe toujours un peu...

[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suis d'accord avec le raisonnement, mais mon instinct me dit d'être prudent.

[11:37] Ubit Umarov : aussi à propos de FS ; et les viewers qui ont utilisé son support BOM pour opensim, j'ai remarqué qu'il faisait des rebakes tout le temps.

[11:37] Ubit Umarov : après un téléport, même si ce n'est pas nécessaire.

[11:38] Ubit Umarov : il se trouve que c'était une petite faute de frappe de Beq, un '!' supplémentaire.

[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Modifications mineures du code avec un impact important

[11:38] Ubit Umarov : cela s'est propagé même aux autres viewers :)

[11:39] Ubit Umarov : aussi le support de BOM de région a été fait en lisant simulatorFeatures[4] fgla ( flag?).

[11:39] Ubit Umarov : cela pourrait causer des problèmes de timing.

[11:40] Ubit Umarov : il est possible que les meilleurs viewers utilisent le flag que nous avons envoyé sur lludp regionhanskake

[11:40] Ubit Umarov : et hancshake

[11:40] Ubit Umarov : ufff et cela

[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sur ce point, maintenant que vous me le rappelez, je dois encore faire un fichier pour que le Grid Status RSS[5] soit activé, j'ai envoyé un mail à Beq pour savoir si cela était prêt à être testé maintenant qu'OpenSim l'envoie dans le cadre de gridinfo.

[11:41] Ubit Umarov : les deux FS et l'alchimie maintenant que maintenant, j'espérais voir Gavin aujourd'hui... mais il est parti.

[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pense que nous fournissons maintenant toutes les informations sauf une, la dernière étant gérée par les modules d'argent.

[11:41] Ubit Umarov : non on le dira plus tard.

[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tout ce que je fais depuis des mois, c'est de pousser les spécifications.

[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je me sens mal d'avoir fait travailler Ubit autant :)

[11:43] Jamie.Jordan @grid.kitely.com:8002 : Bonjour, tout le monde était afk.

[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a encore une tonne de choses à faire, je trouve régulièrement du code très pauvre qui a des années et le retravailler est une douleur, mais cela doit être fait pour l'efficacité et la fiabilité globale.

Autres changements dans OpenSim

• llGetParcelDetails : Renvoie un list correspondant à l’information demandée dans paramètres concernant le terrain situé à la position pos.
• Dayturn Viewer

[11:44] Ubit Umarov : quoi d'autre ?

[11:44] Ubit Umarov : :)

[11:44] Ubit Umarov : bien plus de changements de code, les habituelles "cosmétiques".

[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai supprimé l'autre jour quelques injures que quelqu'un avait laissées dans le code il y a des années.

[11:44] Ubit Umarov : en essayant d'économiser quelques ns(nano secondes) ici et là.

[11:45] Ubit Umarov : ( à l'occasion envoyez plus de ns :P )

[11:46] Vincent.Sylvester @hg.zetaworlds.com:8002 : Modifications apportées à llGetParcelDetails bien que j'aie encore des choses à corriger, je ne suis pas sûr qu'elles seront intégrées au noyau.

[11:46] Vincent.Sylvester @hg.zetaworlds.com:8002 : L'ensemble de l'Api LSL a besoin d'un coup d'œil pour corriger du code ancien, mais les jours ne sont pas infiniment longs, malheureusement.

[11:47] Andrew Hellershanks : Je ne pense pas que Gavin ait apprécié les commentaires qui donnent l'impression que nous ne nous préoccupons que de faire fonctionner les choses pour FS.

[11:47] Ubit Umarov : Robert a corrigé quelque chose sur ce qui a été fait sur prebuild :)

[11:48] Ubit Umarov : je pense qu'il a ajouté un ForceForceFramwork :)

[11:49] Ubit Umarov : donc pour remplacer le forceframewrok que j'avais ajouté :)

[11:49] Cuga.Rajal @rajal.org:9000 : ce code de saut est une nouveauté dans master ?

[11:49] Misterblue Waves : oui, j'ai dû forcer le passage :)

[11:49] Misterblue Waves : les changements de prebuild ne devraient pas changer quoi que ce soit pour une utilisation normale.

[11:49] Ubit Umarov : oui, le master a un nouveau code de saut.

[11:49] Cuga.Rajal @rajal.org:9000: yay

[11:50] Andrew Hellershanks : Vincent, est-ce que ton travail se fait dans une branche de l'OS ?

[11:50] Misterblue Waves : vous ne le verrez que si vous essayez d'ajouter des projets qui sont netstandard2.0 ou net6.

[11:50] Ubit Umarov: SHA-1: aa862fa658e30227264bac79b53b03595eb8c680

• current FS sends a flood of AGENT_CONTROL_FINISH_ANIM

[11:50] Ubit Umarov : j'ai aussi essayé de contrer le flood.

[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Andrew, je ne suis pas un core dev, j'envoie juste à Ubit des patchs qu'il intègre ensuite dans ses typos :D

[11:51] Andrew Hellershanks: ok :)

[11:51] Ubit Umarov : parce que nous ne voulons pas traiter entièrement la mise à jour de 90 agents par seconde quand ils n'ont rien de nouveau.

[11:51] Misterblue Waves : et il me semble que j'ai mal parlé alors Gavin est parti... il faut peut-être donner aux autres viewers un peu d'amour, au moins, verbal :)

[11:51] Ubit Umarov : err typos ? quelles typos ?

[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : hehe je les fais aussi, mais tu ne peux pas les voir.

[11:52] Andrew Hellershanks : Toutes ces mises à jour d'agents feraient perdre beaucoup de temps dans une région avec beaucoup d'avatars.

[11:52] Ubit Umarov : je n'ai aucune idée des problèmes d'animations qu'il (Gavin ?) avait.

[11:52] Ubit Umarov : on verra plus tard

[11:53] Ubit Umarov : Bon, nous pouvons toujours essayer de les bloquer au niveau de llclientview, si cela n'est pas nécessaire.

[11:53] Ubit Umarov : je vais peut-être les laisser s'enfoncer davantage.

[11:53] Ubit Umarov : ils constituent un tic-tac temporel pertinent.

[11:54] Ubit Umarov : les viewers peuvent déjà changer leur taux selon leurs besoins.

[11:54] Ubit Umarov : environ 1 par seconde au repos.

[11:54] Ubit Umarov : jusqu'à 90( ?) en mouvement.

[11:55] Ubit Umarov : certains problèmes que nous avons sont dûs au fait que nous en tuons 2 rapidement.

[11:55] Andrew Hellershanks : 90( ?) par seconde quand on bouge encore semble un peu excessif.

[11:55] Ubit Umarov : 90 fps [6] est le minimum pour la vision 3d.

[11:55] Ubit Umarov : donc 90 est "normal".

[11:56] Ubit Umarov : ou peut être 80... :p

[11:56] Ubit Umarov : beaucoup.

[11:57] Ubit Umarov : ahh aussi fait l'avatar a 2 vitesses

[11:57] Ubit Umarov : il commence à bouger à la moitié du temps maintenant.

[11:57] Ubit Umarov : encore une fois quand les viewers en font la commande

[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai demandé à Gavin il y a quelques temps quel était ses projets pour Dayturn, s'il faisait une viewer OpenSim-first ou si c'était juste une autre viewer universelle. J'ai également demandé sur quel système d'exploitation il se concentrait, car c'est un utilisateur de Mac. Je n'ai pas vraiment obtenu de réponse et le développement semble se diriger davantage vers la compatibilité avec les viewers universels. Nous ne développons certainement pas OpenSim pour une viewer spécifique, mais plutôt pour traiter correctement ce que les viewers nous envoient et même rejeter les données envoyées qui n'ont pas de sens ou ne peuvent pas être traitées en fonction des structures que nous avons, voir BoM. J'ai essayé quelques viewers SL dans le passé pour voir lesquels étaient compatibles, mais peu l'étaient et certains étaient carrément nuisibles à OpenSim, comme le viewer Kirsten qui cassait l'inventaire et malformait les logins. Nous organisons ces réunions pour permettre aux développeurs de viewers d'exprimer ce qu'ils ont à dire en ce qui concerne le support d'OpenSim, mais en dehors d'Hippo, je n'ai pas encore vu de viewer entièrement dédiée à OpenSim. Je suis tout à fait d'accord pour que Dayturn le soit, car je préfère une relation

[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002: que nous avons en ce qui concerne les changements d'OpenSim, c'est pourquoi je suis plutôt déconcerté de voir que Gavin pense que nous nous en fichons et que nous ne développons que pour Firestorm, ce qui n'est pas du tout le cas.

Course et marche des avatars

[11:58] Ubit Umarov : le protocole a un autre flag pour spécifier la vitesse rapide.

[11:58] Andrew Hellershanks : Nous sommes presque à la fin de l'heure une fois de plus. Est-ce que quelqu'un a un autre sujet à discuter avant que nous commencions à perdre des gens ?

[11:58] Ubit Umarov : je l'utilise aussi maintenant.

[11:58] Cuga.Rajal @rajal.org:9000 : comme une facilité ?

[11:58] Ubit Umarov : sur ce point, il y a un problème de timing.

[11:58] Ubit Umarov : en fait sur le double tap pour courir.

[11:59] Ubit Umarov : pour supporter le double tap pour courir, la région doit garder l'avatar en mouvement pendant au moins 100ms.

[11:59] Ubit Umarov : 200 courants

[11:59] Ubit Umarov : mais le timer pour faire cela est le heartbeat de la région de 90.9 ms.

[11:59] Ubit Umarov : donc les erreurs sont plus que grandes.

[12:00] Andrew Hellershanks : Vincent, une partie de ton commentaire a été coupée à cause de la limite de la longueur du chat. Il a été coupé au milieu de la phrase commençant par "Je suis tout à fait pour Dayturn".

[12:00] Misterblue Waves : La RL m'appelle donc je m'en vais... Prenez soin de vous.

[12:00] Ubit Umarov : cela a aussi un impact sur une seule étape.

[12:00] Andrew Hellershanks : ok, Misterblue. Merci d'être venu.

[12:00] Cuga.Rajal @rajal.org:9000 : Passez une bonne journée et prenez soin de vous.

[12:00] Cuga.Rajal @rajal.org:9000 : MisterBlue

[12:00] Ubit Umarov : comme une touche rapide sur la touche fw.

[12:01] Ubit Umarov : comme vous pouvez le voir, la taille du pas change.

[12:01] Ubit Umarov : c'est parce que le battement de coeur est un timer.

[12:01] Ubit Umarov : cela ajoute une erreur qui peut être de 90.9 ms.

[12:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai joué avec les constantes de vitesse et j'ai effectivement trouvé un mauvais test, n'utilisant pas vraiment une logique très saine, ce code n'a pas encore été fusionné cependant. Nous pourrions voir cet échec à un moment donné.

[12:02] Ubit Umarov : ce timing est irritant :(

[12:02] Ubit Umarov : bien sûr, avoir un battement de cœur de 90,9 ms est tout simplement MAUVAIS.

[12:02] Ubit Umarov : mais, la plupart des régions qui n'ont que des danses, sont bien.

[12:03] Cuga.Rajal @rajal.org:9000 : à mon avis il y a des problèmes avec l'animation de marche par défaut, mais je ne suis pas sûr que ce soit à cause du viewer.

[12:03] Ubit Umarov : l'augmentation du hartbeat augmente l'utilisation du cpu... presque dans la même proportion.

[12:03] Selby.Evans @grid.kitely.com:8002 : au revoir à tous.

[12:03] Ubit Umarov : oui, j'ai aussi vu la marche défaillante.

[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a un petit problème avec la marche qui, dans certaines conditions, empêche l'animation de la marche d'être jouée.

[12:03] Ubit Umarov : mais on peut aussi le voir sur sl.

[12:03] Andrew Hellershanks : Au revoir, Selby.

[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : Très difficile à reproduire cependant

[12:04] Ubit Umarov : salut selby

[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela se produit lorsque vous commencez marcher en tournant et que vous tapez pour marcher tout droit.

[12:04] Cuga.Rajal @rajal.org:9000 : Est-ce que c'est la "fonctionnalité" de la 1/2 vitesse ?

[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela arrivait aussi avant, mais il y a plus de chances que cela arrive à ce moment.

[12:05] Ubit Umarov : On ne voit cela que sur les 2 premières étapes

[12:05] Cuga.Rajal @rajal.org:9000: ah

[12:05] Ubit Umarov : mais pas de relation avec la marche.

[12:05] Ubit Umarov : aucune idée de la raison pour laquelle la marche échoue

[12:05] Ubit Umarov : la région envoie cela ... je pense.

[12:05] Cuga.Rajal @rajal.org:9000 : Je le voyais continuellement en marchant, mais je ne suis pas sûr que ce soit lié.

[12:06] Vincent.Sylvester @hg.zetaworlds.com:8002 : Un chevauchement dans les données envoyées par le viewer bloque l'exécution logique de "play animation now"(jouer l'animation maintenant) ou quelque chose de ce genre. Du vaudou comme Ubit aime l'appeler, une aiguille dans une botte de foin pour trouver la cause.

[12:06] Cuga.Rajal @rajal.org:9000 : Je parie que cela n'arrivera pas à l'extérieur.

[12:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si je recevais un dollar pour chaque problème de synchronisation et de verrouillage, je pourrais m'acheter une bonne quantité de glace.

[12:07] Ubit Umarov : j'ai aussi vu ce probmlème sur Sl.

[12:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, c'est une sorte de chevauchement de paquets.

[12:07] Cuga.Rajal @rajal.org:9000 : quand il y a d'autres forces sur l'avatar comme des collisions.

[12:07] Andrew Hellershanks : Il y a quelques problèmes de timing qui me dérangent mais je ne sais pas s'ils sont dus à des changements dans le code du système d'exploitation ou du viewer.

[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ils sont parfois difficiles à cerner.

[12:08] Andrew Hellershanks : C'est vrai.

Conclusion

[12:08] Andrew Hellershanks : Nous avons presque atteint l'heure 10. S'il n'y a rien de plus à faire aujourd'hui, je vais clore cette réunion.

[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le problème de blocage que nous avons eu il y a quelques mois a pris des semaines à résoudre et un tas de débogage a été ajouté au code pour comprendre ce que c'était.

[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le résultat final était un seul verrou manquant

[12:09] Cuga.Rajal @rajal.org:9000 : Je pense que je suis plus grand que vous tous et que je me cogne la tête.

[12:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y aura d'autres changements dans les mouvements, j'en suis sûr, mais pour l'instant, je ne vois aucune régression.

[12:10] Cuga.Rajal @rajal.org:9000: sur des bouding box

[12:10] Andrew Hellershanks : C'est définitivement le genre de chose qui peut être très difficile à trouver.

[12:10] Andrew Hellershanks : Je suis généralement le plus petit dans la foule.

[12:10] Andrew Hellershanks : Je pense que nous avons terminé pour aujourd'hui. Merci à tous d'être venus. Nous vous reverrons la semaine prochaine.