Réunion du 19-04-2022

De OSWiki
Aller à la navigation Aller à la recherche

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

[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 ?

[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.

[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: ive no idea what animations issues he was havign [11:52] Ubit Umarov: lets see later [11:53] Ubit Umarov: well we stil try to hold then at llclientview, if not needed [11:53] Ubit Umarov: i may just let them go deeper [11:53] Ubit Umarov: they are a relevant timt tick [11:54] Ubit Umarov: viwers to change their rate as needed already [11:54] Ubit Umarov: like about 1 per sec when idle [11:54] Ubit Umarov: to like 90(?) when moving [11:55] Ubit Umarov: some issues we have is bc we do kill then 2 soon [11:55] Andrew Hellershanks: 90(?) per sec when moving still seems a bit excessive. [11:55] Ubit Umarov: 90 fps is minimal for 3d vision [11:55] Ubit Umarov: so 90 is "normal" [11:56] Ubit Umarov: bur can be 80.. :p [11:56] Ubit Umarov: a lot [11:57] Ubit Umarov: ahh also made the avatar have 2 speeds [11:57] Ubit Umarov: it starts moving at half spped now [11:57] Ubit Umarov: again as viewers do comand [11:57] Vincent.Sylvester @hg.zetaworlds.com:8002: I asked Gavin a while ago as to what the gameplan for Dayturn is, if he was making a OpenSim-first viewer or if it was just another universal viewer. Also what operating system the focus was on as he is a primary Mac user. I did not really get an answer and the development seems to be branching more towards universal viewer compatibility. We certainly don't develop OpenSim for a specific viewer, but rather to handle what viewers send us properly and even reject data sent that doesn't make sense or cannot be processed based on the structures we have, see BoM. I tried a few SL viewers in the past to see which were compatible, but not many were and some were downright detrimental to OpenSim, like Kirsten viewer breaking inventory and malforming logins. We hold these meetings to allow viewer developers to express what they have to say in regards to OpenSim support, but outside of Hippo I have not seen a fully committed OpenSim-first viewer yet. I'm all for Dayturn being that, as I rather a [11:57] Vincent.Sylvester @hg.zetaworlds.com:8002: relationship we have in regards to OpenSim changes, which is why I am rather bewildered to see Gavin thinks we don't care and only develop for Firestorm, which is not the case at all. [11:58] Ubit Umarov: protocol has another flag to spec fast speed [11:58] Andrew Hellershanks: We are almost at the top of the hour once again. Does anyone have another topic to discuss before we start losing people? [11:58] Ubit Umarov: so im using it also now [11:58] Cuga.Rajal @rajal.org:9000: like an ease-in? [11:58] Ubit Umarov: on that have a timing issue [11:58] Ubit Umarov: in fact on the double tap to run [11:59] Ubit Umarov: to support double tap to run, region needs to keep avatar moving for at least 100ms [11:59] Ubit Umarov: 200 currentk [11:59] Ubit Umarov: but the timer to do that is region heartbeat of 90.9 ms [11:59] Ubit Umarov: so errors is more than large [12:00] Andrew Hellershanks: VIncent, part of your comment was cut off due to limit in text chat length. It cut off part way through the sentence starting "I'm all for Dayturn" [12:00] Misterblue Waves: RL calls so I'm off... take care everyone [12:00] Ubit Umarov: this has also impact on a single step [12:00] Andrew Hellershanks: ok, Misterblue. Thanks for coming. [12:00] Cuga.Rajal @rajal.org:9000: Have a Great Day Take Care [12:00] Cuga.Rajal @rajal.org:9000: MrBlue [12:00] Ubit Umarov: like a fast touck on fw key [12:01] Ubit Umarov: as you can see the size of the step changes [12:01] Ubit Umarov: this is because the heartbeat as timer [12:01] Ubit Umarov: that adds a error that can be 90.9 ms [12:01] Vincent.Sylvester @hg.zetaworlds.com:8002: I played around with the velocity constants and actually found a bad test, not really using very sane logic, that code hasn't been merged yet though. We might see that fail at some point. [12:02] Ubit Umarov: this timing is irritating :( [12:02] Ubit Umarov: ofc having a heartbeat of 90.9 ms is just BAD [12:02] Ubit Umarov: but, most regions with just dances, are fine [12:03] Cuga.Rajal @rajal.org:9000: my avi is having issues with default walk anim, but not sure if its my viewer [12:03] Ubit Umarov: increasing the harbeat does increase cpu usage.. almost on same propotion [12:03] Selby.Evans @grid.kitely.com:8002: bye all [12:03] Ubit Umarov: yeh ai also see the walk fail [12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: There is a minor glitch with walking now that under specific conditions causes walking animation to not play [12:03] Ubit Umarov: but see it also at sl [12:03] Andrew Hellershanks: Bye, Selby. [12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: Really hard to reproduce though [12:04] Ubit Umarov: cya selby [12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: Happens when you start walking with rotation and tap walking just right [12:04] Cuga.Rajal @rajal.org:9000: is that the 1/2 speed "feature"? [12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: It was happening before as well, just got higher chances of happening now [12:05] Ubit Umarov: you only see that on first 2 os so steps [12:05] Cuga.Rajal @rajal.org:9000: ah [12:05] Ubit Umarov: but no relation with the walk [12:05] Ubit Umarov: no idea why walk fails [12:05] Ubit Umarov: region does send it .. i think [12:05] Cuga.Rajal @rajal.org:9000: I was seeing it continuously when walking, but not sure if related [12:06] Vincent.Sylvester @hg.zetaworlds.com:8002: Some overlapping in the data sent by viewer blocking proper logical execution of "play animation now" or something along those lines. Voodoo as Ubit likes to call it, needle in a haystack to find the cause [12:06] Cuga.Rajal @rajal.org:9000: I bet it wont happen outside [12:07] Vincent.Sylvester @hg.zetaworlds.com:8002: If I got a dollar for every timing and locking issue I could buy quite a bit of icecream [12:07] Ubit Umarov: i also see that fail at sl [12:07] Vincent.Sylvester @hg.zetaworlds.com:8002: Yeah it is overlapping packets of some sort [12:07] Cuga.Rajal @rajal.org:9000: when there are other forces on the avi like collisions [12:07] Andrew Hellershanks: There are some timing issues that bother me but I don't know if they are due to changes in the OS code or the viewer. [12:08] Vincent.Sylvester @hg.zetaworlds.com:8002: They are hard to pinpoint at times [12:08] Andrew Hellershanks: So true [12:08] Andrew Hellershanks: We are almost 10 past the hour. If there is nothing more for today I'll wrap up this meeting. [12:09] Vincent.Sylvester @hg.zetaworlds.com:8002: The whole getting stuck thing we had a few months ago took weeks to resolve and a bunch of debug added to code to even figure out what it was [12:09] Vincent.Sylvester @hg.zetaworlds.com:8002: End result was a single missing lock [12:09] Cuga.Rajal @rajal.org:9000: My guess is thast Im taller than all of you and hitting my head [12:10] Vincent.Sylvester @hg.zetaworlds.com:8002: Will be some more changes to movement I'm sure, but so far no regressions I can see [12:10] Cuga.Rajal @rajal.org:9000: on some bouding box [12:10] Andrew Hellershanks: That is definitely the sort of thing that can be very hard to find. [12:10] Andrew Hellershanks: I'm usually the short one in the crowd. [12:10] Andrew Hellershanks: I think we are done for today. Thank you all for coming. See you again next week.

Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_19-04-2022&oldid=5422 »