Aller au contenu

« Réunion du 30-11-2021 » et « Réunion du 07-12-2021 » : différence entre les pages

De OSWiki
(Différence entre les pages)
Page créée avec « Traduction prochaine. Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2021-11-30 =Introduction & Migration des assets sur Osgrid = [https://forums.osgrid.org/viewtopic.php?f=8&t=6836 Migration des assets sur Osgrid] <pre> [11:01] Selby.Evans @grid.kitely.com:8002 : bonjour à tous. [11:01] Gavin.Hird @grid.xmir.org:8002 : Salut Selby, Andrew [11:01] Andrew Hellershanks : Bonjour à tous. [11:01] Gavin.Hird @grid.xmir.org:8002 : Je pensais... »
 
Page créée avec « Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2021-12-07 = Introduction = <pre> [11:02] Ubit Umarov : bonjour [11:03] Selby.Evans @grid.kitely.com:8002 : Salut Jamie [11:04] Gavin.Hird @grid.xmir.org:8002 : Salut Jamie [11:04] Jamie.Jordan @grid.kitely.com:8002 : Salut tout le monde [11:04] Selby.Evans @grid.kitely.com:8002 : Salut Jamie [11:07] Ubit Umarov : Eh bien, Andrew semble un peu en retard. [11:08] Vincent.Sylvester @hg.zetaworlds.... »
 
Ligne 1 : Ligne 1 :
Traduction prochaine.
Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2021-12-07
= Introduction =
<pre>
[11:02] Ubit Umarov : bonjour
[11:03] Selby.Evans @grid.kitely.com:8002 : Salut Jamie
[11:04] Gavin.Hird @grid.xmir.org:8002 : Salut Jamie
[11:04] Jamie.Jordan @grid.kitely.com:8002 : Salut tout le monde
[11:04] Selby.Evans @grid.kitely.com:8002 : Salut Jamie
[11:07] Ubit Umarov : Eh bien, Andrew semble un peu en retard.
[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je vais lui jeter des cacahuètes
</pre>
= Sortie de la version 0.9.2.0 le 05-12-2021 =
[http://opensimulator.org/wiki/0.9.2.0_Release Notes de version 0.9.2.0]
<pre>
[11:08] Ubit Umarov : comme vous le savez certainement, dimanche dernier, la version 0.9.2.0 est sortie.
[11:08] Gavin.Hird @grid.xmir.org:8002 : /clap
[11:09] Gavin.Hird @grid.xmir.org:8002 : quand est-ce que la soirée de lancement aura lieu ?
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ubit Umarov est en train de le regarder lol
[11:09] Ubit Umarov : ouais lol
[11:09] Ubit Umarov : http://opensimulator.org/wiki/0.9.2.0_Release
[11:10] Ubit Umarov : la version de développement est maintenant 0.9.2.1 Dev
[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le Changelog est assez long comparé au précédent, si long que même après avoir parcouru l'historique git, je n'ai toujours pas trouvé tout ce qui vaut la peine d'être mentionné.
[11:10] Ubit Umarov : comme déjà sur ces régions
[11:10] Gavin.Hird @grid.xmir.org:8002 : aussi festif que le booster covide
[11:10] Ubit Umarov : oups
[11:10] Ubit Umarov : la version devel est maintenant 0.9.2.1 Yeti Dev.
[11:10] Ubit Umarov : :)
[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai éliminé quelques bogues qui traînaient depuis des années.
[11:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : L'une des versions les plus productives, je dirais.
[11:11] Ubit Umarov : presque deux ans depuis la 0.9.1.1.
[11:11] Gavin.Hird @grid.xmir.org:8002 : Il y travaille jour et nuit (avec de l'aide bien sûr).
[11:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a aussi beaucoup d'anticipation dans les arrières plans alors que les choses évoluent vers de nouveaux standards, ce qui est toujours utile pour réduire les coûts et éviter que certaines choses ne fonctionnent plus.
[11:13] Vincent.Sylvester @hg.zetaworlds.com:8002 : YEngine devient la valeur par défaut et fournit une base de référence bien plus agréable pour les scripts.
[11:13] Ubit Umarov: :)
[11:13] Ubit Umarov : bien sûr, vous le savez tous déjà.
[11:13] Ubit Umarov : vous l'utilisez ou un dérivé.
[11:14] Ubit Umarov : comme zeta et kitely
[11:14] Ubit Umarov : ou xmir :)
[11:14] Gavin.Hird @grid.xmir.org:8002 : xmir est entièrement en Y
[11:14] Gavin.Hird @grid.xmir.org:8002 : pas de changement ici, seulement quelques omissions.
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai inondé la boîte de messagerie d'Ubits de correctifs récemment qui devraient, je l'espère, apporter des changements utiles pour la prochaine version, une fois qu'il les aura lus.
[11:15] Ubit Umarov : oh je parlais de la version 0.9.2.0.
[11:15] Gavin.Hird @grid.xmir.org:8002 : 0.9.2.0 sans EEP
[11:15] Ubit Umarov : :)
[11:16] Gavin.Hird @grid.xmir.org:8002 : donc si quelqu'un veut une version dé-eep-isée...
[11:16] Ubit Umarov : zeta suit habituellement Dev.
[11:16] Ubit Umarov : kitely attend habituellement une version, mais cette fois-ci, la version 0.9.2.0 a été incorporée il y a quelque temps.
[11:16] Ubit Umarov : parce que c'est nécessaire pour les nouveaux viewers.
[11:17] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je compile les patchs directement sur le noyau pour ne pas avoir à fusionner chaque changement, ce qui me rendait fou.
[11:17] Ubit Umarov : merci à tous pour votre aide :)
[11:18] Vincent.Sylvester @hg.zetaworlds.com:8002 : D'après les changements apportés aux notes de publication, il semble que le plan consiste à publier plus régulièrement des versions maintenant ?
[11:18] Gavin.Hird @grid.xmir.org:8002 : hehe - ce n'était pas aussi le plan la dernière fois ?
[11:19] Ubit Umarov : J'avais prévu de sortir la version 0.9.2.0 l'année dernière.
[11:19] Ubit Umarov : donc... nous verrons bien :)
</pre>
 
= Version de développement 0.9.2.1  et première modification =
[http://opensimulator.org/wiki/0.9.2.1_Release Notes de version 0.9.2.1]


Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2021-11-30
[http://opensimulator.org/wiki/0.9.2.1_Release/fr#Changements_et_corrections Paramètre AllowLoginFallbackToAnyRegion]


=Introduction & Migration des assets sur Osgrid =
[https://forums.osgrid.org/viewtopic.php?f=8&t=6836 Migration des assets sur Osgrid]
<pre>
<pre>
[11:01] Selby.Evans @grid.kitely.com:8002 : bonjour à tous.
[11:19] Ubit Umarov : comme pour la 0.9.1.1, la 0.9.2.1 sera bientôt disponible.
[11:01] Gavin.Hird @grid.xmir.org:8002 : Salut Selby, Andrew
[11:20] Ubit Umarov : cela dépend du nombre de problèmes que les gens signaleront maintenant.
[11:01] Andrew Hellershanks : Bonjour à tous.
[11:20] Ubit Umarov : j'ai déjà fait un changement à ce propos :)
[11:01] Gavin.Hird @grid.xmir.org:8002 : Je pensais à la question des assets osg.
[11:21] Ubit Umarov : en 0.9.2.0, même les simples standalones doivent définir une région avec des flags par défaut.
[11:02] Gavin.Hird @grid.xmir.org:8002 : pas la région.
[11:21] Ubit Umarov : cette information est seulement dans les notes de version.
[11:02] Ubit Umarov : salut andrew et selby.Evans
[11:21] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a toujours beaucoup de problèmes sur Mantis, mais beaucoup d'entre eux représentent des problèmes qu'il faut essayer de reproduire, donc ils sont là depuis des années, il faut vraiment plus de types de statut pour trier les choses comme étant périmées, nécessitant des tests, etc....
[11:02] Gavin.Hird @grid.xmir.org:8002 : :-)
[11:21] Ubit Umarov : donc en 0.9.2.1 ce ne sera plus nécessaire, en fonction d'une nouvelle option que j'ai ajoutée.
[11:02] Ubit Umarov : ahh bien cela prendra du temps.
[11:23] Ubit Umarov : le truc c'est que si à la connexion aucune région "officielle" n'est trouvée pour envoyer l'utilisateur, le code envoie juste vers n'importe quelle région qu'il trouve en ligne.
[11:02] Ubit Umarov : estimé à 1 mois
[11:23] Ubit Umarov : comme vous pouvez l'imaginer cela peut constituer une grande violation de la vie privée, etc...
[11:02] Gavin.Hird @grid.xmir.org:8002 : donc l'année prochaine.
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il peut également échouer si la région est mal configurée.
[11:02] Ubit Umarov : jusqu'à la fin de l'opération.
[11:23] Ubit Umarov : donc la 0.9.2.0 ne permettra pas cela ...
[11:03] Gavin.Hird @grid.xmir.org:8002 : Salut Jagga
[11:24] Gavin.Hird @grid.xmir.org:8002 : ou un grand embarras selon...
[11:03] Andrew Hellershanks : Bonjour, Jagga.
[11:24] Ubit Umarov : 0.9.2.1 le permet avec cette nouvelle option.
[11:03] Jagga Meredith : Bonjour.
[11:24] Ubit Umarov : ouais
[11:03] Ubit Umarov : yeha pas sûr que les vacances aient été prises en compte dans cette estimation du temps.
[11:24] Ubit Umarov : un vieux problème d'opensim
[11:03] Andrew Hellershanks : Le temps pour faire quoi ?
[11:24] Ubit Umarov : mais pour bloquer totalement l'option comme je l'ai fait en 0.9.2.0.
[11:03] Gavin.Hird @grid.xmir.org:8002 : Je suppose que l'ordinateur fonctionne aussi vite que n'importe quel autre jour, férié ou non.
[11:25] Ubit Umarov : donc... j'ai ajouté l'option, avec la recommandation de ne la laisser à true que lorsque cela n'a pas d'importance.
[11:04] Ubit Umarov : pour ceux qui ne comprennent pas, osgrid a déplacé les services d'assets vers un autre datacenter.
[11:26] Ubit Umarov : donc c'est le premier code ajouté à la 0.9.2.1 :)
[11:04] Ubit Umarov : depuis quelques mois maintenant, les nouveaux services fonctionnent, récupérant les assets manquants des anciens services.
[11:26] Ubit Umarov : un jour et quelques bits après la sortie ;)
[11:04] Gavin.Hird @grid.xmir.org:8002 : et (ndlr : OSGrid) a posté un message indiquant que les ressources qui n'ont pas été récemment utilisées ne seront plus dans l'inventaire pendant environ un mois
[11:04] Ubit Umarov : maintenant cela a été arrêté.
[11:05] Andrew Hellershanks : Oh. Copier les données va prendre un certain temps...
[11:05] Ubit Umarov : les services vont signaler les manquants, comme manquants.
[11:05] Ubit Umarov : le reste des assets est en train d'être copié.
[11:05] Ubit Umarov : et cela va prendre beaucoup de temps.
[11:05] Andrew Hellershanks : Où cela est-il affiché sur le site Web d'osgrid ? Je ne le vois pas sous "News".
[11:05] Ubit Umarov : car il y a environ 5 To de données.
[11:06] Ubit Umarov : C'est sur le forum.
[11:06] Ubit Umarov : gavin l'a trouvé :)
[11:06] Gavin.Hird @grid.xmir.org:8002: https://forums.osgrid.org/viewtopic.php?f=8&t=6836
[11:07] Ubit Umarov : il semble que la recherche des assets manquants par les nouveaux services sur les anciens services ait  perturbé le processus de copie, provoquant ainsi beaucoup de retard.
[11:07] Ubit Umarov : à ce qu'on m'a dit :)
[11:07] Andrew Hellershanks : Oh. Ils l'ont enterré dans le forum ? Je lis rarement les forums.
[11:07] Gavin.Hird @grid.xmir.org:8002 : cela signifie probablement que les couronnes de Noël qu'on n'a pas utilisées depuis Noël dernier devront être oubliées cette année.
[11:08] Andrew Hellershanks : Bonjour, Jamie
[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il est assez difficile de régler le déplacement des données concernant les assets, même lorsqu'il s'agit de fichiers, car le déplacement d'une grandes quantités de petits fichiers n'est pas ce pour quoi la plupart des systèmes de transfert sont optimisés. Avec rsync, j'ai commencé à tester les paramètres des tampons et du cache ainsi que l'exécution de plusieurs instances sur une partie de l'ensemble des données, car un seul rsync, même avec le multithreading intégré, ne se comporte pas bien lorsqu'il s'agit de déplacer 300 000 fichiers de quelques Ko chacun.  La structure de données des assets, même dans une configuration imbriquée, est un cauchemar, sans parler d'essayer de faire des sauvegardes par version sous une forme raisonnable sans vraiment repousser les limites de ce que la compression peut faire.
[11:09] Ubit Umarov : bien entendu, vous, les gens de l'hypergrid, ne devriez pas constater le problème.
</pre>
</pre>
=Viewer  & Glow =
= Cycle des versions dans OpenSimulator=
[https://www.dayturn.com/viewer/index.php?resources/ Les viewers Dayturn7 pour macOS et pour Windows]
[http://opensimulator.org/wiki/Release_Cycle Cycle des versions pour OpenSimulator]
 
https://bitbucket.org/opensimulator/opensim/commits/  
<pre>
<pre>
[11:09] Jamie.Jordan @grid.kitely.com:8002 : Bonjour tout le monde, je n'ai pas réussi à charger la viewer aujourd'hui.
[11:26] Vincent.Sylvester @hg.zetaworlds.com:8002: post fixes partout
[11:09] Gavin.Hird @grid.xmir.org:8002 : ok...
[11:26] Gavin.Hird @grid.xmir.org:8002 : Je pensais que l'incrémentation du numéro de version était la première étape.
[11:10] Ubit Umarov : la visionneuse a fonctionné correctement pour moi ici.
[11:27] Ubit Umarov : bien j'arrête de poursuivre le nom postfixes sur les versions.
[11:10] Gavin.Hird @grid.xmir.org:8002 : en parlant de viewer, j'ai posté une nouvelle version il y a quelques jours.
[11:27] Ubit Umarov : un numéro mineur sur la version, signifie des petits changements ou des corrections de bugs.
[11:10] Andrew Hellershanks : Jamie, np. Tu as quand même réussi à venir ici.
[11:27] Ubit Umarov : je n'ai jamais compris comment on pouvait avoir seulement une version xxx-postfixes.
[11:10] Ubit Umarov : seul sl a  des problèmes.
[11:27] Ubit Umarov : un peu trop optimiste :p
[11:10] Andrew Hellershanks : Gavin, quelque chose de nouveau et d'excitant ?
[11:28] Ubit Umarov : comme vous l'avez remarqué, l'étape de la version candidate (release candidate) a aussi été arrêtée.
[11:10] Gavin.Hird @grid.xmir.org:8002 : oui.
[11:28] Ubit Umarov : elles ne donnent pas retour supplémentaire.
[11:10] Selby.Evans @grid.kitely.com:8002 : Bonjour Jamie.
[11:28] Ubit Umarov : donc c'est  juste une perte de temps.
[11:10] Ubit Umarov : il faut se souvenir de l'url de Gavin :)
[11:29] Gavin.Hird @grid.xmir.org:8002 : comment peut-on avoir une release candidate pour quelque chose qui est en beta ?
vous pouvez définir des objets lumineux (glow) pour qu'ils soient 100 % transparents et qu'ils conservent leur luminosité.
[11:29] Gavin.Hird @grid.xmir.org:8002: :-)
[11:11] Ubit Umarov : je veux dire l'url de téléchargement du viewer.
[11:29] Gavin.Hird @grid.xmir.org:8002 : ou est-ce alpha ?
[11:11] Gavin.Hird @grid.xmir.org:8002 : excellent pour faire des fantômes et d'autres choses.
[11:29] Ubit Umarov: http://opensimulator.org/wiki/Release_Cycle
[11:11] Jamie.Jordan @grid.kitely.com:8002 : Salut Selby
[11:29] Ubit Umarov : eh bien, nous les avons eus.
[11:11] Andrew Hellershanks : Il ne se conservait pas du réglage du glow avant maintenant ?
[11:29] Ubit Umarov : même RC1, RC2... etc...
[11:11] Gavin.Hird @grid.xmir.org:8002: https://www.dayturn.com/viewer/index.php?resources/
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : A ce stade, si vous voulez toujours l'appeler une alpha, alors je me demande ce qu'est Win11, car il fonctionne de manière beaucoup moins fiable.
[11:11] Gavin.Hird @grid.xmir.org:8002 : non.
[11:30] Ubit Umarov : les numéros de version simples et normaux suffisent.
[11:11] Ubit Umarov : ohh comme la lumière de la lune noire sur l'océan ?
[11:30] Gavin.Hird @grid.xmir.org:8002 : Win11 est un virus du secteur de démarrage
[11:12] Ubit Umarov : ils ont oublié de vérifier le glow sur les prims transp ?
[11:30] Ubit Umarov : comme je l'ai dit, les chiffres mineurs signifient des changements mineurs etc...
[11:12] Gavin.Hird @grid.xmir.org:8002 : c'est un type différent de glow Ubit.
[11:30] Ubit Umarov : comme la plupart des logiciels.
[11:12] Ubit Umarov : mais une classe de bugs similaire :P
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je considère comme une bêta quelque chose que vous pouvez exécuter et qui ne décidera pas aléatoirement d'exploser si vous le laissez seul.
[11:12] Gavin.Hird @grid.xmir.org:8002 : ils l'ont fait.
[11:32] Ubit Umarov : comme vous pouvez le voir sur l'ancien cycle de publication, la version à publier a été même placé
[11:12] Andrew Hellershanks : IIRC, je n'utilise pas de glow supérieur à environ 30%, au delà, la texture est effacée sur la prim et tout ce que vous voyez est blanc.
[12] Ubit Umarov : sur une branche appelée... xxx.postfixes
[11:12] Ubit Umarov : ( mais la lune ne devrait pas être sombre )
[11:33] Ubit Umarov : comme brak 0.9.2.0 sur git a le code release.
[11:13] Gavin.Hird @grid.xmir.org:8002 : La configuration minimale requise est maintenant Windows 10, c'était XP....
[11:33] Ubit Umarov : branck
[11:13] Kayaker Magic : Hmm, j'ai profité de l'absence de lumière sur la transparence pour faire des lumières clignotantes !
[11:33] Gavin.Hird @grid.xmir.org:8002 :J'appelle cela une bêta quand il ne prend pas encore conscience qu'il fonctionne dans une machine virtuelle, et  vient avec toutes sortes de recommandations erronées basées sur le moment où le système fonctionne - comme le meilleur moment pour appliquer les mises à jour.
[11:13] Andrew Hellershanks : Gavin, c'est un grand saut. Cela peut exclure un certain nombre d'utilisateurs.
[11:33] Ubit Umarov : oui, je ne sais pas taper... branche 0.9.2.0 :)
[11:13] Gavin.Hird @grid.xmir.org:8002: oui
[11:34] Ubit Umarov : et sur un point similaire du master, il y a le tag0.9.2.1Dev pour marquer le début du travail sur la 0.9.2.1.
[11:14] Ubit Umarov : ça fait sauter 7 et 8 :)
[11:34] Ubit Umarov : Je pense que ceci est plus "propre", et vous ?
[11:14] Gavin.Hird @grid.xmir.org:8002 : j'ai aussi monté la version macOS d'un cran.
[11:35] Ubit Umarov: https://bitbucket.org/opensimulator/opensim/commits/
[11:14] Ubit Umarov: et vista!
[11:14] Gavin.Hird @grid.xmir.org:8002: Vista
[11:14] Gavin.Hird @grid.xmir.org:8002: :-)
[11:14] Ubit Umarov : opensim supporte vista !
[11:14] Ubit Umarov : pas XP :(
[11:15] Ubit Umarov : ( vista peut utiliser .net 4.6, XP ne le peut pas, c'est juste ça )
</pre>
</pre>
= Lumières clignotantes "J'espère que toutes les lumières de Noël utiliseront une animation de texture" =  
= Mantis et attente de rapport de bogues : à vos tests ! =
[http://opensimulator.org/mantis/my_view_page.php Suivi des bogues : Mantis]
 
[http://opensimulator.org/wiki/Bugs Comment reporter un Bug? ]
<pre>
<pre>
[11:14] Kayaker Magic : Hmm, je donnerais bien à Gavin une copie de mes lumières clignotantes, mais cet asset ne peut pas être trouvé dans l'inventaire :(
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'attends l'afflux de problèmes sur la mantis et d'autres personnes qui vont faire exploser le canal IRC. La sortie a été d'une certaines manière tellement calme que personne ne l'a remarquée jusqu'à présent.
[11:15] Gavin.Hird @grid.xmir.org:8002 : Il existe un script de lumières clignotantes dans la bibliothèque LSL.
[11:36] Ubit Umarov : Beaucoup de gens ne regardent que la sortie d'une version.
[11:15] Gavin.Hird @grid.xmir.org:8002 : J'ai donné à Ubit une copie, donc peut-être qu'il l'a dans sa librairie ?
[11:36] Ubit Umarov : et il y a des gens avec d'autres cas d'utilisation, etc.
[11:15] Gavin.Hird @grid.xmir.org:8002 : donné*.
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002 : Mantis a besoin d'un peu d'amour je pense, un peu plus de balises d'état et la mise à jour des numéros de version.
[11:15] Ubit Umarov : l'asset sera là en 2022 :)
[11:36] Ubit Umarov : il est donc normal de recevoir plus de rapports de bogues.
[11:15] Andrew Hellershanks : Kayaker, l'article du forum dit que vous devrez peut-être attendre un mois.
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui reste sur les problèmes non résolus a besoin d'une meilleure structure pour voir ce qui existe et pourquoi.
[11:16] Ubit Umarov : un script clignotant ?
[11:37] Ubit Umarov : nous allons voir comment ça se passe et si nous avons besoin de sortir  une version même ce mois-ci lol.
[11:16] Gavin.Hird @grid.xmir.org:8002 : oui.
[11:37] Ubit Umarov : si un problème majeur est trouvé (et que nous pouvons le résoudre).
[11:16] Ubit Umarov : oui, j'ai l'asset.
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'aimerais juste une étiquette "needs testing"(besion de test)  pour signaler les problèmes à revoir, soit après avoir été corrigés, soit après avoir réalisé une tonne de travail.
[11:16] Gavin.Hird @grid.xmir.org:8002 : il utilise le glow.
[11:38] Ubit Umarov: sur mantis?
[11:16] Ubit Umarov : qui en a besoin ?
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: Oui
[11:16] Ubit Umarov:
[11:38] Gavin.Hird @grid.xmir.org:8002 : les commentaires des utilisateurs sont nécessaires.
  timer()
[11:38] Ubit Umarov : Eh bien, beaucoup de gens négligent tout cela.
    {
[11:39] Ubit Umarov : quelqu'un m'a dit qu'il ne voyait que les versions jusqu'à 0.9,1,1 à installer.
        isOn = !isOn;
[11:39] Ubit Umarov : j'ai ajouté 0.9.2.0 et 0.9.2.1Dev et je les vois.
        if( isOn ) llSetLinkPrimitiveParamsFast( LINK_THIS,[PRIM_GLOW,faceNo,glowAmount] );
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux juste y apporter plus de structure pour qu'il soit plus facile de voir ce qui est encore un problème maintenant et pour que les gens qui cherchent à aider sachent clairement ce qu'ils peuvent faire pour aider.
        else llSetLinkPrimitiveParamsFast( LINK_THIS,[PRIM_GLOW,faceNo,0.0] );
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a probablement quelques douzaines de problèmes enfouis dedans qui devraient être examinés, mais les trouver et les confirmer demande beaucoup de travail.
    }
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Comme tous les problèmes de freeswitch, reproduire cela est presque impossible maintenant que freeswitch devient de plus en plus difficile à configurer, semble-t-il.
[11:16] Ubit Umarov: c'est ça
[11:40] Ubit Umarov : J'espère que tout va bien pour Andrew.
[11:17] Andrew Hellershanks : Un script simple et agréable.
[11:40] Ubit Umarov : ou son chat.
[11:17] Gavin.Hird @grid.xmir.org:8002: url de téléchargement du viewer : https://www.dayturn.com/viewer/index.php?resources/
[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il s'est probablement endormi quelque part
[11:17] Kayaker Magic : Ce n'est pas un script clignotant, il utilise llSetTextureAnim pour déplacer la couleur et la TRANSPARENCE entre les parties du mesh.
[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : l'hiver vous fait ça.
[11:18] Gavin.Hird @grid.xmir.org:8002 : mettez-le dans un cube Ubit.
[11:43] Vincent.Sylvester @hg.zetaworlds.com:8002 : Avec le nettoyage que j'ai fait, j'ai enterré quelques problèmes importants qui ont été soumis, je dois les retrouver et les remettre en haut de la liste je pense.
[11:18] Ubit Umarov : les clignotants peuvent être un bon tueur de région.
[11:44] Gavin.Hird @grid.xmir.org:8002 : comme ?
[11:18] Kayaker Magic : Donc le viewer fait tout le travail.
[11:19] Gavin.Hird @grid.xmir.org:8002 : Le CPU de la région est à 0.11% donc je suis sûr qu'un script de clignotant ne la tuera pas.
[11:18] Andrew Hellershanks : Ubit, cela dépend en partie du timer utilisé.
[11:19] Ubit Umarov: définir une lumière (ou glow) est unc mise à jour complète de la prim prim envoyée à tous les viewers dans la vue
[11:19] Ubit Umarov: il semble que les régions soient complètement hors service à cause de cela
[11:19] Ubit Umarov: flood complet sur lludp
[11:19] Ubit Umarov: llSetTextureAnim est une bonne façon d'éviter cela
[11:19] Gavin.Hird @grid.xmir.org:8002: CPU for the region is 0.11% so I am sure one blinker script will not kill it
[11:19] Kayaker Magic : Ouais, j'ai vu des gens mettre une région à genoux avec des lumières de Noël ! C'est pourquoi j'ai écrit ce clignotant orienté  client.
[11:20] Jagga Meredith: kewl
[11:21] Ubit Umarov : j'espère que toutes les lumières de Noël utiliseront une animation de texture ou similaire.
[11:22] Andrew Hellershanks : J'en ai vu plusieurs qui utilisent des timers courts (ou presque) pour que les scripts affichent un nombre élevé de temps d'exécution.
[11:22] Ubit Umarov : ce n'est pas seulement le CPU.
[11:22] Ubit Umarov : c'est une utilisation massive de lludp.
[11:22] Objet : Script en cours d'exécution
</pre>
= Incidence des scripts sur une région =
<pre>
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce n'est pas aussi mauvais que vous le pensez, j'ai eu près de 40 personnes sur une région avec environ 30 lumières de chaque couleur et une lumière ponctuelle ainsi que quelques changeurs de couleur supplémentaires, etc., ça a mieux fonctionné qu'il y a 5 ans, c'est certain.
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Nous avons parcouru un bon bout de chemin depuis l'époque où trop de mises à jour de prims  faisaient planter les régions.
[11:23] Gavin.Hird @grid.xmir.org:8002 : voici le script blink.
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Maintenant, vous obtenez juste des échecs dans la file d'attente de mise à jour des scènes, ce qui donne l'impression que les scripts se sont arrêtés.
[11:24] Jagga Meredith : non copiable
[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je reçois ça de temps en temps quand les gens décident de placer des scripts de 800 lignes dans quelque chose juste pour aligner une porte.
[11:24] Andrew Hellershanks : La première indication qu'un script peut causer des problèmes est le temps d'exécution élevé du script. Les utilisateurs ne peuvent pas voir de statistiques sur le trafic UDP.
[11:24] Ubit Umarov : en fait, ils le peuvent.
[11:24] Gavin.Hird @grid.xmir.org:8002 : l'aspect est un peu étrange lorsque la transparence est de 100%.
[11:24] Ubit Umarov : mais pas la source.
[11:25] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai pas mal d'éclairage avec des fonctions normalement gourmandes, avec quelques astuces vous pouvez réduire l'impact sur la région, mais un faux mouvement et le processeur s'en va...
[11:25] Ubit Umarov : mais lludp est là en plus des stats.
[11:25] Ubit Umarov : ( ce qu'on ne voit pas c'est http, sauf sur singularity =
[11:26] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je n'ai pas vu un seul utilisateur consommer plus de 3mbit après que la région soit chargée pour lui, à moins que vous ne fassiez du DSL sur un morceau de ficelle mouillée, vous êtes généralement bien sur le front du réseau.
[11:26] Kayaker Magic : En parlant de mauvais scripts, Discovery Grid a découvert qu'un de ses utilisateurs utilisait un script qui sauvegardait une carte chaque seconde, et en a faisait plusieurs copies.
[11:26] Ubit Umarov : singularity a un truc sympa sur l'utilisation de la bande passante http.
[11:26] Ubit Umarov : maintenant je vois que j'utilise 50Mo tout seul :p
[11:26] Ubit Umarov : sur une région
[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si nous entrons dans une discussion sur les déficiences du protocole, nous en aurons pour des jours, il y a tellement d'appels redondants et de choses qui se produisent, au final, cela fonctionne comme par magie, même si cela ne devrait probablement pas fonctionner.
[11:28] Ubit Umarov : j'ai changé la restriction http sur les assets.
[11:28] Andrew Hellershanks : :)
[11:28] Gavin.Hird @grid.xmir.org:8002 : maintenant le cube avec le script peut être copié.
[11:29] Ubit Umarov : remplacé throttle par autre chose, juste plus intéressé par l'utilisation raisonnable.
[11:29] Jagga Meredith : *regarde le cube, hypnotisée*.
[11:29] Ubit Umarov : et avec le type de priorité des données.
[11:29] Ubit Umarov : au cas où vous n'auriez pas remarqué, les avatars se rechargent beaucoup plus vite maintenant :p
[11:29] Andrew Hellershanks : hm... je me demande si quelqu'un a déjà fabriqué une lampe à lave ?
[11:29] Ubit Umarov : si vous et votre région avez de la bande passante...
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : Les fondus de couleurs lents sont faciles à réaliser dans Yengine grâce à une meilleure gestion des délais de script.
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il faut juste trouver le bon point d'équilibre pour la complexité de la fonction et la chose s'écrit toute seule.
[11:31] Ubit Umarov : (notez que cela n'a rien à voir avec certaines forks qui ont simplement supprimé les étranglements sans aucun code de remplacement).
[11:31] Ubit Umarov : a
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : Bonne mesure de l'horloge du processeur en voyant à quelle vitesse la lumière change.
</pre>
</pre>
= Problème de cache d'objet =
[http://opensimulator.org/mantis/view.php?id=8934 issue 8934]
[https://www.youtube.com/watch?v=BvbwM_7ZGaM Vidéo montrant le bogue]


= Nouvelles d'OpenSim cette semaine =
[https://www.youtube.com/watch?v=pYmTDf76jcw Autre vidéo sur le bogue]
* Certains paramètres qui étaient auparavant uniquement disponibles pour XEngine sont maintenant disponibles dans YEngine.
* Certains problèmes de longue date ont finalement été pris en compte,
* Une correction de bogue effectuée la semaine dernière empêche certaines prims de changer de type lorsqu'elles sont configurées en flex avec llSetPrimitiveParams. (mantis [http://opensimulator.org/mantis/view.php?id=7896 7896] et [http://opensimulator.org/mantis/view.php?id=7910 7910]).
* optimisations dans le code pour économiser quelques cycles d'horloge.
* écriture d'un test qui fonctionne sur les deux moteurs de scripts [[XEngine]] et [[YEngine]]
* [http://wiki.secondlife.com/wiki/LSL_Test_Harness LSL Test Harness]
<pre>
<pre>
[11:31] Ubit Umarov : ok, et quelles sont les nouvelles que vous avez sur opensim ?
[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002 : Surtout ce comportement bizarre du cache d'objet  qui devient ennuyeux quand il se produit.
[11:31] Ubit Umarov: :)
[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002 :Je dois revenir aux tests, j'ai désactivé ce cap pour la région où cela se passait le plus mal pour voir si cela donne de meilleurs résultats.
[11:32] Andrew Hellershanks : Pas beaucoup de changements cette semaine mais quelques uns.
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : Désactiver le côté viewer semble aider, mais ce n'est pas idéal.
[11:33] Andrew Hellershanks : Certains paramètres qui étaient auparavant uniquement disponibles pour XEngine sont maintenant disponibles dans YEngine.
[11:45] Gavin.Hird @grid.xmir.org:8002 : Je ne vois jamais de mise en cache bizarre des objets
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : La plupart des corrections de bogues que j'aime voir, certains problèmes de longue date ont finalement été pris en compte, mais j'aimerais que mantis soit un peu plus flexible avec tout cela.
[11:45] Gavin.Hird @grid.xmir.org:8002 :es-tu sûr que ce n'est pas un problème de viewer ?
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : On ne peut pas vraiment établir de statut "à tester" ou "ne peut pas être corrigé maintenant".
[11:45] Ubit Umarov : certaines options du côté de la viewer sont brisées.
[11:33] Andrew Hellershanks : Il y a eu des changements liés au CO2 mais je ne sais pas ce qu'est le CO2.
[11:45] Ubit Umarov : jamais utilisé chez SL, donc ignoré.
[11:34] Ubit Umarov: jezzz
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pense que c'est le viewer qui ne comprend pas les données qu'il reçoit.
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : Demande à une vache Andrew, ils en font beaucoup j'ai entendu.
[11:46] Gavin.Hird @grid.xmir.org:8002 : ok, est-ce que ça enregistre quelque chose ?
[11:34] Jagga Meredith : de l'essence ? (Je sais, "ne démarre pas")
[11:46] Ubit Umarov : voici Andrew le dormeur.
[11:34] Andrew Hellershanks : Vincent, je pensais que c'était du méthane.
[11:46] Ubit Umarov : :)
[11:34] Andrew Hellershanks : :)
[11:46] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai un journal de débogage que je dois mettre et voir ce qu'il fait, mais je soupçonne qu'il dira que tout va bien tel quel.
[11:34] Ubit Umarov : c'est plutôt du méthane Vincent :)
[11:46] Gavin.Hird @grid.xmir.org:8002 : Bonjour Andrew
[11:35] Gavin.Hird @grid.xmir.org:8002 : Vous produisez tous beaucoup de CO2
[11:47] Andrew Hellershanks : Bonjour, tout le monde.
[11:35] Gavin.Hird @grid.xmir.org:8002 : chaque expiration contient 40 fois plus de CO2 que votre inspiration.
[11:47] Vincent.Sylvester @hg.zetaworlds.com:8002 : Soit l'appel est malformé en chemin vers le viewer, soit le viewer ne le comprend pas.
[11:35] Ubit Umarov : oui, mais notre CO2 est équilibré.
[11:47] Andrew Hellershanks : J'étais en train de travailler sur mon ordinateur portable et j'ai oublié quel jour on était.
[11:35] Ubit Umarov : les plantes ont tout capturé au cours de notre vie.
[11:47] Gavin.Hird @grid.xmir.org:8002 : mais que se passe-t-il ?
[11:36] Ubit Umarov : donc notre co est en quelque sorte "neutre".
[11:47] Ubit Umarov: oups
[11:36] Gavin.Hird @grid.xmir.org:8002 : Le CO2 n'est absolument pas pertinent pour toute discussion. C'est un gaz à l'état de trace qui représente 0,04% de l'atmosphère.
[11:47] Ubit Umarov : j'ai oublié la réunion :)
[11:36] Ubit Umarov : mais oui, sur les commits, il s'agit d'économiser un peu de travail du processeur, donc de l'énergie, donc du CO2 dans la plupart des régions.
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : En fait, ce qui se passe, c'est que les anciennes prims qui sont en cache dans le viewer peuvent être éditées sans problème du point de vue de la région.
[11:36] Ubit Umarov: :p
[11:48] Gavin.Hird @grid.xmir.org:8002 : maintenant nous devons recommencer à zéro.
[11:37] Andrew Hellershanks : Une correction de bogue effectuée la semaine dernière empêche certaines prims de changer de type lorsqu'elles sont configurées en flex avec llSetPrimitiveParams. (mantis 7896 et 7910).
[11:48] Ubit Umarov : ok andrew peut faire un résumé de ce que nous avons dit :)
[11:37] Ubit Umarov : "essayez de sauver quelques zeptogrammes de CO2"
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : Mais quand on force le viewer à redessiner la prim, il utilise la version en cache qui montre toujours l'état précédent de la prim.
[11:37] Ubit Umarov : pas optimiste sur l'impact réel sur le co2 :p
[11:48] Gavin.Hird @grid.xmir.org:8002 : forcer le viewer à redessiner le prim ?
[11:37] Gavin.Hird @grid.xmir.org:8002 : toute l'énergie de mes régions est générée par des centrales hydroélectriques.
[11:49] Vincent.Sylvester @hg.zetaworlds.com:8002 : Zoomer très loin et revenir en arrière
[11:37] Andrew Hellershanks : Ubit, j'ai lu ça et je n'ai aucune idée de ce que cela signifie.
[11:49] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai posté une vidéo sur la façon de le reproduire sur Mantis qui montre ce qui se passe.
[11:37] Ubit Umarov : vous le savez maintenant :p
[11:49] Gavin.Hird @grid.xmir.org:8002 : à quelle fréquence faites-vous le flush des changements vers le stockage persistant ?
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : La mémoire a été moins un problème avec OpenSim, mais étant donné que vous ne pouvez utiliser qu'un ou deux cœurs par instance, je pense que le maximum que j'ai vu est de 330% de cpu, économiser de petits morceaux ici et là est utile.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sur la région, tout va bien, tu édites, ce changement est pris en compte lorsqu'on supprime le cache du viewer, tout semble correct, c'est certainement le cache du viewer qui est en cause.
11:38] Andrew Hellershanks cherche la définition de zeptogramme.
[11:50] Andrew Hellershanks: merci, Ubit.
[11:38] Andrew Hellershanks : Aucun mot de ce type n'a été trouvé dans le dictionnaire.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui est étrange, c'est qu'il semble y avoir du code pour dire au viewer de purger l'objet du cache.
[11:38] Gavin.Hird @grid.xmir.org:8002: :-)
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sans parler du fait que le viewer lui-même modifie la prim, il devrait donc savoir qu'il faut la purger du cache et récupérer une nouvelle copie à la place.
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Certains des changements que je peux imaginer dans certaines situations où il est beaucoup utilisé pourraient avoir un impact plus important, mais rien que l'on puisse vraiment mesurer étant donné le flux de cpu et de threading.
[11:50] Gavin.Hird @grid.xmir.org:8002 : pourquoi est-ce bizarre ?
[11:38] Ubit Umarov : tu as un mauvais dictionnaire lol
[11:51] Gavin.Hird @grid.xmir.org:8002 : le cache peut être purgé ou invalidé à tout moment.
[11:39] Ubit Umarov : c'est 10^-21 gramme :p
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est probablement là pour s'assurer que les choses sont purgées, mais en ce qui concerne le test de ce problème, il est étrange que le viewer ne le fasse pas lui-même, sachant quelle prim est éditée et sachant qu'il ne devrait pas utiliser la version du cache local par la suite, mais il le fait quand même.
[11:39] Gavin.Hird @grid.xmir.org:8002: yeah
[11:52] Gavin.Hird @grid.xmir.org:8002 : si le changement n'a pas été écrit dans le stockage persistant et que vous faites quelque chose qui force le viewer à invalider le cache et à aller chercher dans le stockage persistant, tu perds les modifications.
[11:39] Gavin.Hird @grid.xmir.org:8002 : 1 zeptogramme = 0,001 attogramme
[11:52] Gavin.Hird @grid.xmir.org:8002 : tu dois donc configurer ta région pour qu'elle écrive plus souvent les changements dans la base de données.
[11:39] Jagga Meredith : *Se souvient du professeur de mathématiques du lycée qui disait "oh oui, il y a des choses comme Tera- et pico- mais vous ne les utiliserez jamais".
[11:53] Vincent.Sylvester @hg.zetaworlds.com:8002 : L'édition sur la région fonctionne correctement, ce n'est pas le problème, tu peux le vérifier en utilisant la physique.
[11:39] Gavin.Hird @grid.xmir.org:8002 : ou 1 000 yoctogrammes.
[11:53] Gavin.Hird @grid.xmir.org:8002 : alors où est-ce que ça ne marche pas ?
[11:40] Andrew Hellershanks : Je n'ai jamais vu zepto avant en termes d'unité de mesure.
[11:53] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai réduit l'échelle d'une prim pour révéler le terrain en dessous et quand j'ai fait redessiner la prim par le Viewer en montrant la taille originale, la partie que j'ai réduite est devenue fantôme.
[11:40] Ubit Umarov : en fait, les mantis 7896 et 7910 étaient un bug que nous avions depuis toujours.
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: https://www.youtube.com/watch?v=pYmTDf76jcw
[11:40] Ubit Umarov : j'espère que c'est corrigé maintenant.
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ubit m'a dit de laisser le cache objet activé pour des raisons de performance, bien qu'en dehors des régions particulièrement lentes, je ne vois pas vraiment de différence, peut-être que je suis plus patient que d'autres quand il s'agit d'attendre qu'une région se charge.
[11:40] Ubit Umarov : en fait, je l'ai fait aujourd'hui.
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est juste que ça me rend fou quand on fait des changements sur quelque chose, qu'on se retourne pour les annuler et qu'on doit vider le cache et se reconnecter à chaque fois.
[11:40] Andrew Hellershanks : Jagga, j'utilise souvent pico.
[11:57] Ubit Umarov : je vois que la mise en cache fonctionne bien la plupart du temps.
[11:40] Jagga Meredith : exactement.
[11:57] Gavin.Hird @grid.xmir.org:8002 : Je ne pense pas que cela ait été annulé dans ton exemple, parce que lorsque tu t'es promené après le zoom, tu es arrivé à l'endroit où tu t'es approché de la prim redimensionnée.
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002: En début de semaine je me suis intéressé à un problème qui concerne des items supprimés qui ne sont pas supprimés quand c'est demandé. Mais il semble que ces items "persitent"  seulement jusqu'à ce que vous vous reconnectiez. Je n'en suis pas sûr mais, je pense que c'est un problème inexistant ou du moins auto-correctif.
[11:58] Gavin.Hird @grid.xmir.org:8002 : il s'agit d'un problème de transcription dans la viewer.
[11:41] Ubit Umarov : difficile d'économiser le même picogramme de CO2 en changeant quelques lignes de code :p
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, comme je l'ai dit, sur la région elle-même, le montage colle parfaitement, mais le viewer ne suit pas parce qu'il prend la version en cache.
[11:41] Ubit Umarov : difficile d'économiser...
[11:58] Ubit Umarov : ouais bien sûr, ce clip est irritant
[11:42] Jagga Meredith : c'est vieux.
[11:58] Gavin.Hird @grid.xmir.org:8002 : mais je ne vois pas l'intérêt de ces zooms ?
[11:43] Ubit Umarov : certains paramètres lsl sur le [xengine] sont nécessaires sur le [yengine] comme l'a dit andrew certains paramètres qui n'étaient présents que sur X sont nécessaires aussi sur Y.
[11:59] Vincent.Sylvester @hg.zetaworlds.com:8002 : forcer la mise à jour
[11:43] Ubit Umarov : actuellement le code LSLapi les recherche dans les moteurs respectifs.
[11:59] Gavin.Hird @grid.xmir.org:8002 : dans quel but ?
[11:43] Ubit Umarov : j'ai donc fait une copie de ces fichiers.
[11:59] Vincent.Sylvester @hg.zetaworlds.com:8002 : Donc, ce cela déclenche la récupération du cache
[11:44] Ubit Umarov : possible dans le futur qu'ils aient leur propre section.
[11:59] Ubit Umarov : et ce n'est même pas le cache du viewer.
[11:45] Andrew Hellershanks : Je pense avoir enfin compris la référence au CO2 dans le commentaire. C'était la façon légèrement cryptique d'Ubits de dire qu'il a fait quelques optimisations dans le code pour économiser quelques cycles d'horloge.
[11:59] Gavin.Hird @grid.xmir.org:8002: pourquoi ?
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai fini de corriger les tests de moteur de script précédemment cassés et désactivés pour X et je les ai rendus disponibles en tant que copies pour Y. Ubit m'a remis un script de test de conformité qui semble fonctionner presque complètement dans Y. Il se comporte un peu plus mal pour X. J'ai écrit un test à partir de ce script pour qu'il fonctionne sur les deux, de sorte que les changements apportés aux moteurs de script peuvent maintenant être testés pour les régressions.
[11:59] Ubit Umarov: c'est lié à la mémoire
[11:45] Ubit Umarov : pas pour gavin.Hird.
[11:59] Gavin.Hird @grid.xmir.org:8002 : exactement Ubit
[11:46] Ubit Umarov : mais c'est sûr pour les serveurs en Pologne par exemple.
[12:00] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est le souci, la désactivation du cache des objets du viewer directement dans le viewer supprime entièrement ce comportement.
[11:47] Gavin.Hird @grid.xmir.org:8002 : ne pas économiser du CO2, mais réduire la facture d'électricité.
[12:00] Gavin.Hird @grid.xmir.org:8002 : pourquoi veux-tu déclencher la récupération du cache ?
[11:47] Ubit Umarov : j'envisage d'underclocker ma machine :)
[12:00] Vincent.Sylvester @hg.zetaworlds.com:8002 : Après avoir fait cela, plus aucune prim n'avait se comporte.
[11:47] Gavin.Hird @grid.xmir.org:8002 : comme l'Europe est dans une telle situation de pénurie d'énergie, nous lui vendons toute notre énergie, donc mon prix par kWh a été multiplié par 11 le mois dernier.
[12:00] Gavin.Hird @grid.xmir.org:8002 : as-tu testé cela uniquement dans FS ?
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : En travaillant sur les tests, j'ai trouvé quelques problèmes avec les changements qui se déclenchent de manière aléatoire alors qu'ils ne sont pas commandés en tant que tels, bien que je ne sois pas entièrement sûr que ce soit vraiment le cas, je me gratte encore la tête sur ce point.
[12:01] Gavin.Hird @grid.xmir.org:8002 : ou d'autres viewers se comportent-ils de la même façon ?
[11:49] Andrew Hellershanks : Vincent, c'est bien d'avoir un ensemble de tests appropriés pour le moteur de script. Est-ce qu'ils testent la précision du timing de certaines fonctions de script ?
[12:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je n'ai pas encore testé avec d'autres viewers.
[11:49] Andrew Hellershanks : Bonjour, Dennis.
[12:01] Gavin.Hird @grid.xmir.org:8002 : ok, mais FS a une implémentation de cache très particulière.
[11:50] Gavin.Hird @grid.xmir.org:8002 : Salut Dennis
[12:01] Gavin.Hird @grid.xmir.org:8002 : il pourrait donc s'agir d'un problème à ce niveau.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pourrais écrire un test comme ça, je suppose.
[12:02] Gavin.Hird @grid.xmir.org:8002 : je ne comprends toujours pas la nécessité de déclencher une récupération du cache.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il existe un test pour l'exécution d'un script simple, j'ai copié une grande partie de ce code et j'ai simplement inséré le script de test de conformité pour l'exécuter.
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002 : Parce que lorsque vous travaillez sur quelque chose, il le fait aléatoirement pendant que vous ne regardez pas et ensuite vous vous retournez pour voir tous les changements que vous avez fait il y a une demi-heure apparemment annulés alors qu'ils ne le sont pas.
[11:50] Andrew Hellershanks : J'ai trouvé des problèmes de timing avec KFM et/ou llTargetOmega.
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai douté de ma santé mentale les premières fois que j'ai vu ça.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Techniquement, on peut exécuter n'importe quel script et vérifier le résultat.
[12:03] Gavin.Hird @grid.xmir.org:8002 : jamais, jamais expérimenté cela.
[11:51] Gavin.Hird @grid.xmir.org:8002 : LL n'a-t-il pas publié un grand nombre de tests de script ?
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le ticket mantis existe simplement pour suivre ce problème du côté d'OpenSim et pour obtenir la vérification qu'OpenSim envoie bien les informations appropriées.
[11:51] Ubit Umarov : celui que j'ai partagé avec Vincent est l'un de ceux-là gavin.Hird
[12:03] Gavin.Hird @grid.xmir.org:8002 : quelle est la taille de la région sur laquelle tu travailles ?
[11:52] Gavin.Hird @grid.xmir.org:8002: http://wiki.secondlife.com/wiki/LSL_Test_Harness
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : var ou normal n'a pas d'importance, cela arrive sur les deux.
[11:52] Ubit Umarov : mais utile pour vérifier l'ordre des évènements.
[12:04] Gavin.Hird @grid.xmir.org:8002: ok
[11:52] Gavin.Hird @grid.xmir.org:8002: ok
[12:04] Gavin.Hird @grid.xmir.org:8002 : as-tu modifié les paramètres d'occlusion dans votre visionneuse ?
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'en ai parlé aux développeurs de FS, mais je n'ai pas eu de réponse, je pense que je vais ouvrir un ticket de leur côté à ce sujet pour faire avancer les choses.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai désactivé l'occlusion ambiante
[12:05] Gavin.Hird @grid.xmir.org:8002 : ce n'est pas ce que je voulais dire.
[12:06] Gavin.Hird @grid.xmir.org:8002 : les objets hors caméra peuvent être occultés pour accélérer le rendu.
[12:06] Gavin.Hird @grid.xmir.org:8002 : typiquement les objets derrière vous
[12:06] Gavin.Hird @grid.xmir.org:8002 : mais aussi des objets cachés par d'autres personnes.
[12:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : En dehors de la désactivation du cache des objets, je n'ai pas encore modifié les paramètres de débogage du viewer.
[12:07] Gavin.Hird @grid.xmir.org:8002: ok
[12:08] Gavin.Hird @grid.xmir.org:8002 : combien de mémoire GPU as-tu alloué pour le viewer ?
[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a un paramètre pour cela ?
[12:08] Gavin.Hird @grid.xmir.org:8002 : il y a de la mémoire pour les textures.
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est réglé sur 512 mo
[12:09] Gavin.Hird @grid.xmir.org:8002: ok
[12:09] Gavin.Hird @grid.xmir.org:8002 : combien de mémoire GPU as-tu ?
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je ne suis pas sûr que cela ait un rapport avec le problème, mais je pense que cela vaut la peine d'essayer.
[12:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Une Nvidia 1080 normale, donc pas tant que ça, et elle doit piloter 4 écrans, donc il lui reste probablement 2 à 4 Go pour jouer.
[12:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : Comme je l'ai dit, j'ai simplement ouvert la mantis pour que nous puissions exclure OpenSim de la cause de ce problème s'il envoie effectivement une notification appropriée pour invalider un objet qui a été modifié.
[12:11] Gavin.Hird @grid.xmir.org:8002 : Je pense avoir entendu LL dire que le code du viewer n'est pas particulièrement heureux avec une mémoire GPU au-delà de 4 Go, mais je peux me tromper.
[12:12] Ubit Umarov : opensim a envoyé la bonne information, vous avez vu le changement de taille de la Prim.
[12:12] Ubit Umarov : et le zoom est de 100% du côté de l'utilisateur.
[12:12] Gavin.Hird @grid.xmir.org:8002 : oui, c'est bien ça.
[12:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, en parcourant le code de support du cache objet, je n'ai rien trouvé qui puisse être une cause potentielle de ce problème s'il ne fonctionne pas correctement.
[12:13] Ubit Umarov : alors... vodoo
[12:13] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je vais prendre note de demander à FS via un ticket car je n'ai pas encore reçu de réponse à mon email.
[12:13] Ubit Umarov : je suppose qu'il n'est pas facile d'essayer de repo des circonstances similaires chez sl.
[12:13] Gavin.Hird @grid.xmir.org:8002 : Je pense que cela peut être dû au fait que le viewer n'invalide pas l'élément mis en cache lorsqu'il est persistant dans la région,
[12:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est ce que je pense aussi.
[12:14] Ubit Umarov : si tu te reconnectes, la prim est tel qu'elle a été éditée.
[12:14] Ubit Umarov : non ?
[12:14] Vincent.Sylvester @hg.zetaworlds.com:8002: Pas toujours, mais c'est le plus souvent le cas, si je supprime le cache, c'est toujours le cas car, il le récupère depuis la région.
[12:15] Gavin.Hird @grid.xmir.org:8002 : mais il y a du cache dans le viewer, mais aussi dans flotsam, non ?
[12:15] Ubit Umarov : donc la région a juste fait son truc...
[12:15] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai fait quelques expériences en laissant le cache et en désactivant simplement le système de mise en cache, les résultats sont mitigés et je ne sais pas non plus ce qui cause l'invalidation du cache.
[12:15] Ubit Umarov : rien à voir avec flotsam
[12:15] Ubit Umarov : les prims ne sont même pas dessus
[12:15] Gavin.Hird @grid.xmir.org:8002: ok
[12:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce problème existe depuis des années maintenant, j'ai vu cela la première fois en 2017 et depuis, tout le temps.
[12:16] Ubit Umarov : ( à moins que le rez depuis l'inventaire soit possible )
[12:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il doit s'agir d'une petite chose, juste une ligne manquante quelque part dans le code du viewer, mais les chances que je trouve cela dans la décennie sont minces.
[12:17] Gavin.Hird @grid.xmir.org:8002 : mais dans tous les cas, cela devrait être invalidé dans le cache du viewer dès qu'il y a persistance dans la région.
[12:17] Ubit Umarov : je me souviens qu'il y avait une option de cache du viewer qui affichait les prims. Si on s'éloignait et revenait... tout disparaissait jusqu'au relog :)
[12:18] Ubit Umarov : j'ai montré à un dev fs... la réponse était "pourquoi avez-vous mis cette option... elle n'est pas utilisée...".
[12:18] Ubit Umarov : fait :)
</pre>
</pre>


= Timer et précision =
= Problème de chargement de texture =  
<pre>
<pre>
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002 : Les timers sont étranges, mais en interne, en fonction de la façon dont ils opèrent, vous pouvez faire des changements mineurs dans la façon dont vous appelez le timer, ce qui augmente la précision, mais il ne sera pas, même dans SL, précis dans le temps.
[12:18] Andrew Hellershanks : Comme vous parlez du comportement des viewer et de la mise en cache, je vais ajouter un commentaire/une question au cas où cela pourrait être lié.
[11:52] Ubit Umarov : une affaire qui a fait fumer un peu le cerveau de Vincent :)
[12:19] Andrew Hellershanks : J'ai remarqué l'autre jour qu'après m'être connecté à une région, certaines textures étaient floues (parce qu'elles n'étaient pas encore complètement chargées ?). J'ai forcé un rafraîchissement de texture et elles se sont entièrement chargées et avaient l'air bien. Quelques instants plus tard, les textures sont redevenues floues, puis se sont chargées complètement et ont eu l'air correct.
[11:52] Andrew Hellershanks : Vincent, le problème avec ça, c'est que ce n'est pas fiable. Vous copiez le script sur une grille différente et vous devez recalculer les ajustements.
[12:20] Andrew Hellershanks : C'est un peu bizarre qu'une texture complète se "décharge" et doive être chargée une deuxième fois.
[11:53] Andrew Hellershanks : Dans certains cas, le viewer peut être (en partie ?) la cause des problèmes de timing.
[12:20] Gavin.Hird @grid.xmir.org:8002 : la texture est détruite.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : Eh bien, tu peux presque toujours réduire de 0,3% le temps que tu veux, donc 10 devient 9,7 puis tu t'assures de 9,7f ou le double 9,777777f et tu obtiens environ deux fois plus de précision sur dix minutes qu'avant.
[12:20] Gavin.Hird @grid.xmir.org:8002 : trop peu de mémoire de texture probablement.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sur la plupart des régions, sauf les plus chargées, cela fonctionne assez bien.
[12:21] Vincent.Sylvester @hg.zetaworlds.com:8002 : Dayturn me faisait souvent ça, mais cela s'est arrêté il y a quelques versions.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'avais l'habitude de calculer la différence de temps et, une fois la seconde passée, de réinitialiser l'événement timer.
[12:21] Andrew Hellershanks : Je n'avais pas bougé. C'était comme si une texture donnée n'était pas complètement chargée, puis chargée et affichée correctement, puis revenait à un état partiellement chargé, puis se stabilisait à un état complètement chargé.
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ou utiliser un timer plus petit dans la plage de précision que vous voulez, disons toutes les 5 minutes pour une vérification horaire.
[12:22] Andrew Hellershanks : La seule chose que je faisais pendant ce temps était d'utiliser Tex Refresh dans le viewer pour l'aider à charger une texture partiellement chargée.
[11:55] Ubit Umarov : (jesus non :P )
[12:22] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le viewer charge d'abord les objets proches, puis tout ce qui est plus éloigné, de sorte qu'elle peut éventuellement charger une prim de la région suivante, ce qui entraîne le remplissage de la mémoire de texture.
[11:55] Dennis Ravnsholm : Merci.
[12:22] Gavin.Hird @grid.xmir.org:8002 : Il y a eu beaucoup de corrections sur l'allocation de la mémoire de texture, donc cela a permis de s'en débarrasser.
[11:56] Ubit Umarov : ne fais pas ça :p
[12:23] Andrew Hellershanks : Vincent, ok. On dirait que c'est le côté viewer. J'utilise la dernière version de FS.
[11:56] Andrew Hellershanks : Je soupçonne que le code de la grille ou celui du viewer ne suit pas correctement la différence de temps lorsque certaines fonctions sont appelées.
[12:23] Gavin.Hird @grid.xmir.org:8002 : de plus si vous avez des textures surdimensionnées, c'est à dire plus grandes que 1024x1024, ça devient fou.
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire qu'il y a aussi le problème suivant : plus vous remplissez l'événement timer, plus il sera lent dans l'ensemble et il ne redémarre le compte qu'une fois l'événement terminé, pas quand il est déclenché.
[12:23] Ubit Umarov : regardez ce qui se passe.
[11:56] Andrew Hellershanks : Lorsque j'ai écrit une routine pour déterminer les impulsions par seconde, j'ai pris en compte le fait que le temps entre les appels pouvait ne pas être de 1 seconde. J'ai pris le nombre d'impulsions et l'ai divisé par le temps réel écoulé depuis l'appel précédent.
[12:23] Ubit Umarov : si une prim est vieille pour être cachable...
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002 : Par exemple, si vous voulez que quelque chose s'exécute deux fois par seconde, ne mettez pas une ligne unique qui fait dix choses, mais dix lignes qui font toutes la même chose, ce qui réduit le nombre de "sous-routines" pour ainsi dire.
[12:23] Andrew Hellershanks : Ce n'était pas ma région ou mes objets donc je n'ai aucune idée de la taille de la ou des textures.
[11:57] Andrew Hellershanks : Vous partez, kayakiste ?
[12:24] Ubit Umarov : ( simple boîte )
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002 : En fin de compte, vous ne faites qu'appliquer des astuces et des solutions de contournement, le timing précis est une industrie d'un milliard de dollars pour les marchés boursiers dans le monde entier, le petit ole OpenSim ne leur donnera pas une course pour leur argent de sitôt.
[12:24] Ubit Umarov : on se connecte... on redimensionne... on dézoome complètement... le changement de taille disparaît...
[11:58] Kayaker Magic : Pas moi ! Quelqu'un a atterri sur ma tête pourtant...
[12:24] Gavin.Hird @grid.xmir.org:8002 : les anciens objets peuvent avoir des textures 2048x2048 appliquées à eux.
[11:58] Gavin.Hird @grid.xmir.org:8002 : il y a toutes sortes de blocages dans le viewer en fonction de ce qui se passe, donc je suppose qu'il ne peut pas fournir un timing précis.
[12:24] Ubit Umarov : fs montre la prim telle qu'elle était à la connexion, même dans l'onglet d'édition.
[11:58] Andrew Hellershanks : oh, ok. On aurait dit que tu étais debout.
[12:25] Ubit Umarov : on se reconnecte et on va chercher la prim modifiée.
[11:59] Kayaker Magic : Bienvenue Dennis !
[12:25] Ubit Umarov : donc... fs fait un peu n'importe quoi
[11:59] Kayaker Magic murmure : Tu as une heure de retard pour la réunion !
[12:25] Ubit Umarov : Je ne peux pas tester su sl
[11:59] Andrew Hellershanks : N'y a-t-il aucun moyen de savoir quelle était l'heure actuelle et de la comparer à l'heure qu'il est maintenant ? Ce n'est peut-être pas une seconde. Il peut s'agir de 1,04 seconde. Le chronométrage peut être précis si vous utilisez le temps réel entre les appels.
[12:25] Gavin.Hird @grid.xmir.org:8002 : c'est toujours possible de le faire, mais il faut que la texture de cette taille soit téléchargée directement dans la base de données.
[12:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : On peut obtenir des temps précis dans des mesures plus grandes, mais en dessous de 10 secondes, il n'y a plus de chiffres avant la virgule.
[12:25] Ubit Umarov : parce qu'on ne peut pas recharger une boîte pendant 30 minutes ou plus.
[12:01] Andrew Hellershanks : Je n'ai pas creusé dans la partie du code qui traite du passage du temps. Je pourrais le faire si je peux me libérer d'un autre travail que je dois faire.
[12:25] Ubit Umarov : ou alors...
[12:02] Gavin.Hird @grid.xmir.org:8002 : le code du timing du viewer est dans llcommon/llfasttimer.cpp/h
[12:26] Ubit Umarov chuchote : tester un rez de cube sur sl et le laisser là pendant un certain temps ( 30min) ?
[12:02] Gavin.Hird @grid.xmir.org:8002 : parce que vous avez aussi llcommon/llframetimer.cpp/h.
[12:26] Ubit Umarov : alors, il est marqué comme cachable.
[12:02] Andrew Hellershanks : Gavin, merci. Je vais devoir chercher l'équivalent dans OS.
[12:27] Ubit Umarov : puis connectez-vous et répétez le changement de taille : zoom arrière, zoom avant...
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suppose que l'on pourrait suivre en interne si l'événement est désynchronisé et le reprogrammer, de la même manière que l'on teste si l'événement de la minuterie s'est produit à modulo zéro du temps fixé ou non, mais cela ajoute de la complexité, ce qui signifie moins de vitesse globale.
[12:03] Gavin.Hird @grid.xmir.org:8002 : et llcommon/llheartbeat.cpp/h
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : Lorsque vous devez exécuter des choses toutes les minutes, vous ne vous souciez généralement pas beaucoup de quelques secondes.
[12:03] Andrew Hellershanks : Le  timing était autrefois un peu plus précis qu'il ne l'est aujourd'hui. C'est quelque chose que j'ai remarqué et qui affecte une chose sur laquelle je travaillais, donc je vais peut-être devoir creuser la question.
[12:04] Andrew Hellershanks : Vincent, non, mais quand tu fais des choses basées sur le temps, comme des choses qui sont déplacées via KFM, ça compte.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : Encore une fois, plus l'intervalle de temps est faible, plus c'est mauvais.
[12:05] Andrew Hellershanks : Je viens de remarquer que nous sommes au début de l'heure. Est-ce que quelqu'un a une question à poser à quelqu'un qui doit partir bientôt ?
[12:05] Andrew Hellershanks : Vincent, pas si c'est bien fait.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il faut aussi modifier le code de l'événement lui-même pour qu'il soit moins lourd et que l'événement puisse se terminer rapidement.
[12:05] Andrew Hellershanks : Le code ne devrait pas être appelé une fois par seconde. Il devrait vérifier combien de temps réel s'est écoulé entre les appels et agir en conséquence.
[12:05] Gavin.Hird @grid.xmir.org:8002 : Il est probable que ce ne soit pas le cas, Andrew.
[12:06] Andrew Hellershanks : Gavin, peut-être pas. Je fais juste des suppositions sur la ou les causes des problèmes que je rencontre.
[12:07] Gavin.Hird @grid.xmir.org:8002 : bien sûr.
07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le problème est que le changer pour qu'il soit plus précis signifie probablement un code plus lourd en interne, ce qui signifie que les timers sont moins bons pour les performances de la région qu'ils ne le sont déjà, ce qui signifie à son tour moins d'utilisation et potentiellement des gens qui vont en sommeil, ce qui provoque une foule d'autres problèmes.
[12:08] Jagga Meredith : *a un mal de tête récursif*.
[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire que je suppose que l'on peut toujours utiliser une variante d'ossl qui utilise des horloges atomiques ou quelque chose comme ça.
[12:08] Andrew Hellershanks : Non, ça n'a pas besoin d'être beaucoup plus lourd. Il s'agit vraiment de savoir comment le code détermine le temps qui s'est écoulé.
[12:08] Jagga Meredith : Temps GPS
[12:09] Kayaker Magic : Entre le serveur, l'internet et le viewer, je suppose toujours que les timers ne seront JAMAIS précis et je code en conséquence.
[12:11] Andrew Hellershanks : Par exemple, si vous pouvez obtenir le nombre de ticks d'horloge qui se sont écoulés depuis la dernière fois que votre code a été exécuté et que vous savez combien de ticks d'horloge il y a par seconde, alors vous saurez si une seconde s'est écoulée depuis la dernière fois que votre code a été exécuté. S'il y a plus ou moins de ticks que le nombre de secondes, vous pouvez en tenir compte.
[12:12] Andrew Hellershanks : Il se peut qu'il y ait encore quelques dérapages, mais dans l'ensemble, c'est un moyen simple de suivre le passage du temps.
[12:12] Jagga Meredith : vous supposez que la transmission des "tics d'horloge" est instantanée.
[12:12] Gavin.Hird @grid.xmir.org:8002 : et que les tics de l'horloge sont une constante.
[12:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Vous savez, cela semble correct à l'écrit mais dans le code, c'est une autre histoire.
[12:13] Andrew Hellershanks : Les tics d'horloge au niveau du système doivent être constants, sinon vous avez de sérieux problèmes.
[12:13] Gavin.Hird @grid.xmir.org:8002 : oui pour les horloges en temps réel.
[12:13] Gavin.Hird @grid.xmir.org:8002 : mais l'horloge du processeur n'est pas constante.
[12:13] Jagga Meredith : ...comme d'autres choses qui se passent au niveau du serveur.
[12:16] Andrew Hellershanks : Vous devez utiliser une source d'horloge fiable. Je l'ai fait sur des systèmes embarqués sans matériel spécial. .
[12:16] Ubit Umarov : J'ai déjà parlé des problèmes de kfm et de timing lors de plusieurs réunions, donc je ne le fais pas maintenant.
[12:18] Andrew Hellershanks : Ubit, je sais que tu as dit que tu avais fait des changements dans le code. Je sais juste que le timing n'est plus aussi précis qu'avant.
</pre>
</pre>
=Conclusion=
= Conclusion=
[https://conference.opensimulator.org/ Programme des événements OSCC 2021]
<pre>
<pre>
[12:20] Andrew Hellershanks : Il est presque l'heure et demie. Y a-t-il d'autres sujets à aborder avant de conclure la réunion d'aujourd'hui ?
[12:04] Andrew Hellershanks : Permettez-moi de faire un petit rappel. La conférence de la communauté Open Simulator a lieu ce week-end. Consultez le site Web à l'adresse https://conference.opensimulator.org/ pour connaître le programme des événements.
[12:21] Andrew Hellershanks : S'il n'y a rien d'autre, ce sera tout pour cette semaine.
[12:29] Andrew Hellershanks : Nous sommes à environ une heure et demie. Est-ce que quelqu'un a d'autres questions à poser avant la fin de cette réunion ?
[12:21] Andrew Hellershanks : Merci à tous d'être venus. Nous vous reverrons la semaine prochaine.
[12:30] Andrew Hellershanks : Je ne vois personne en train de taper, je vais donc considérer que c'est tout pour aujourd'hui.
[12:30] Selby.Evans @grid.kitely.com:8002: https://www.reddit.com/r/metaverse/
[12:30] Andrew Hellershanks : J'espère voir certains d'entre vous à l'événement OSCC ce week-end.
[12:30] Jamie.Jordan @grid.kitely.com:8002 : grande réunion.
[12:31] Andrew Hellershanks : Profitez des événements de l'OSCC. Nous pourrons en parler mardi prochain.
[12:31] Andrew Hellershanks : Merci à tous d'être venus. Nous vous reverrons la semaine prochaine.
</pre>
</pre>

Dernière version du 29 novembre 2024 à 17:07

Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2021-12-07

Introduction

[11:02] Ubit Umarov : bonjour
[11:03] Selby.Evans @grid.kitely.com:8002 : Salut Jamie
[11:04] Gavin.Hird @grid.xmir.org:8002 : Salut Jamie
[11:04] Jamie.Jordan @grid.kitely.com:8002 : Salut tout le monde
[11:04] Selby.Evans @grid.kitely.com:8002 : Salut Jamie
[11:07] Ubit Umarov : Eh bien, Andrew semble un peu en retard.
[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je vais lui jeter des cacahuètes

Sortie de la version 0.9.2.0 le 05-12-2021

Notes de version 0.9.2.0 

[11:08] Ubit Umarov : comme vous le savez certainement, dimanche dernier, la version 0.9.2.0 est sortie.
[11:08] Gavin.Hird @grid.xmir.org:8002 : /clap
[11:09] Gavin.Hird @grid.xmir.org:8002 : quand est-ce que la soirée de lancement aura lieu ?
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ubit Umarov est en train de le regarder lol
[11:09] Ubit Umarov : ouais lol
[11:09] Ubit Umarov : http://opensimulator.org/wiki/0.9.2.0_Release
[11:10] Ubit Umarov : la version de développement est maintenant 0.9.2.1 Dev
[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le Changelog est assez long comparé au précédent, si long que même après avoir parcouru l'historique git, je n'ai toujours pas trouvé tout ce qui vaut la peine d'être mentionné.
[11:10] Ubit Umarov : comme déjà sur ces régions
[11:10] Gavin.Hird @grid.xmir.org:8002 : aussi festif que le booster covide
[11:10] Ubit Umarov : oups
[11:10] Ubit Umarov : la version devel est maintenant 0.9.2.1 Yeti Dev.
[11:10] Ubit Umarov : :)
[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai éliminé quelques bogues qui traînaient depuis des années.
[11:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : L'une des versions les plus productives, je dirais.
[11:11] Ubit Umarov : presque deux ans depuis la 0.9.1.1.
[11:11] Gavin.Hird @grid.xmir.org:8002 : Il y travaille jour et nuit (avec de l'aide bien sûr).
[11:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a aussi beaucoup d'anticipation dans les arrières plans alors que les choses évoluent vers de nouveaux standards, ce qui est toujours utile pour réduire les coûts et éviter que certaines choses ne fonctionnent plus.
[11:13] Vincent.Sylvester @hg.zetaworlds.com:8002 : YEngine devient la valeur par défaut et fournit une base de référence bien plus agréable pour les scripts.
[11:13] Ubit Umarov: :)
[11:13] Ubit Umarov : bien sûr, vous le savez tous déjà.
[11:13] Ubit Umarov : vous l'utilisez ou un dérivé.
[11:14] Ubit Umarov : comme zeta et kitely
[11:14] Ubit Umarov : ou xmir :)
[11:14] Gavin.Hird @grid.xmir.org:8002 : xmir est entièrement en Y
[11:14] Gavin.Hird @grid.xmir.org:8002 : pas de changement ici, seulement quelques omissions.
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai inondé la boîte de messagerie d'Ubits de correctifs récemment qui devraient, je l'espère, apporter des changements utiles pour la prochaine version, une fois qu'il les aura lus.
[11:15] Ubit Umarov : oh je parlais de la version 0.9.2.0.
[11:15] Gavin.Hird @grid.xmir.org:8002 : 0.9.2.0 sans EEP
[11:15] Ubit Umarov : :)
[11:16] Gavin.Hird @grid.xmir.org:8002 : donc si quelqu'un veut une version dé-eep-isée...
[11:16] Ubit Umarov : zeta suit habituellement Dev.
[11:16] Ubit Umarov : kitely attend habituellement une version, mais cette fois-ci, la version 0.9.2.0 a été incorporée il y a quelque temps.
[11:16] Ubit Umarov : parce que c'est nécessaire pour les nouveaux viewers.
[11:17] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je compile les patchs directement sur le noyau pour ne pas avoir à fusionner chaque changement, ce qui me rendait fou.
[11:17] Ubit Umarov : merci à tous pour votre aide :)
[11:18] Vincent.Sylvester @hg.zetaworlds.com:8002 : D'après les changements apportés aux notes de publication, il semble que le plan consiste à publier plus régulièrement des versions maintenant ?
[11:18] Gavin.Hird @grid.xmir.org:8002 : hehe - ce n'était pas aussi le plan la dernière fois ?
[11:19] Ubit Umarov : J'avais prévu de sortir la version 0.9.2.0 l'année dernière.
[11:19] Ubit Umarov : donc... nous verrons bien :)

Version de développement 0.9.2.1 et première modification

Notes de version 0.9.2.1

Paramètre AllowLoginFallbackToAnyRegion 

[11:19] Ubit Umarov : comme pour la 0.9.1.1, la 0.9.2.1 sera bientôt disponible.
[11:20] Ubit Umarov : cela dépend du nombre de problèmes que les gens signaleront maintenant.
[11:20] Ubit Umarov : j'ai déjà fait un changement à ce propos :)
[11:21] Ubit Umarov : en 0.9.2.0, même les simples standalones doivent définir une région avec des flags par défaut.
[11:21] Ubit Umarov : cette information est seulement dans les notes de version.
[11:21] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a toujours beaucoup de problèmes sur Mantis, mais beaucoup d'entre eux représentent des problèmes qu'il faut essayer de reproduire, donc ils sont là depuis des années, il faut vraiment plus de types de statut pour trier les choses comme étant périmées, nécessitant des tests, etc....
[11:21] Ubit Umarov : donc en 0.9.2.1 ce ne sera plus nécessaire, en fonction d'une nouvelle option que j'ai ajoutée.
[11:23] Ubit Umarov : le truc c'est que si à la connexion aucune région "officielle" n'est trouvée pour envoyer l'utilisateur, le code envoie juste vers n'importe quelle région qu'il trouve en ligne.
[11:23] Ubit Umarov : comme vous pouvez l'imaginer cela peut constituer une grande violation de la vie privée, etc...
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il peut également échouer si la région est mal configurée.
[11:23] Ubit Umarov : donc la 0.9.2.0 ne permettra pas cela ...
[11:24] Gavin.Hird @grid.xmir.org:8002 : ou un grand embarras selon...
[11:24] Ubit Umarov : 0.9.2.1 le permet avec cette nouvelle option.
[11:24] Ubit Umarov : ouais
[11:24] Ubit Umarov : un vieux problème d'opensim
[11:24] Ubit Umarov : mais pour bloquer totalement l'option comme je l'ai fait en 0.9.2.0.
[11:25] Ubit Umarov : donc... j'ai ajouté l'option, avec la recommandation de ne la laisser à true que lorsque cela n'a pas d'importance.
[11:26] Ubit Umarov : donc c'est le premier code ajouté à la 0.9.2.1 :)
[11:26] Ubit Umarov : un jour et quelques bits après la sortie ;)

Cycle des versions dans OpenSimulator

Cycle des versions pour OpenSimulator

https://bitbucket.org/opensimulator/opensim/commits/ 

[11:26] Vincent.Sylvester @hg.zetaworlds.com:8002: post fixes partout
[11:26] Gavin.Hird @grid.xmir.org:8002 : Je pensais que l'incrémentation du numéro de version était la première étape.
[11:27] Ubit Umarov : bien j'arrête de poursuivre le nom postfixes sur les versions.
[11:27] Ubit Umarov : un numéro mineur sur la version, signifie des petits changements ou des corrections de bugs.
[11:27] Ubit Umarov : je n'ai jamais compris comment on pouvait avoir seulement une version xxx-postfixes.
[11:27] Ubit Umarov : un peu trop optimiste :p
[11:28] Ubit Umarov : comme vous l'avez remarqué, l'étape de la version candidate (release candidate) a aussi été arrêtée.
[11:28] Ubit Umarov : elles ne donnent pas retour supplémentaire.
[11:28] Ubit Umarov : donc c'est  juste une perte de temps.
[11:29] Gavin.Hird @grid.xmir.org:8002 : comment peut-on avoir une release candidate pour quelque chose qui est en beta ?
[11:29] Gavin.Hird @grid.xmir.org:8002: :-)
[11:29] Gavin.Hird @grid.xmir.org:8002 : ou est-ce alpha ?
[11:29] Ubit Umarov: http://opensimulator.org/wiki/Release_Cycle
[11:29] Ubit Umarov : eh bien, nous les avons eus.
[11:29] Ubit Umarov : même RC1, RC2... etc...
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : A ce stade, si vous voulez toujours l'appeler une alpha, alors je me demande ce qu'est Win11, car il fonctionne de manière beaucoup moins fiable.
[11:30] Ubit Umarov : les numéros de version simples et normaux suffisent.
[11:30] Gavin.Hird @grid.xmir.org:8002 : Win11 est un virus du secteur de démarrage
[11:30] Ubit Umarov : comme je l'ai dit, les chiffres mineurs signifient des changements mineurs etc...
[11:30] Ubit Umarov : comme la plupart des logiciels.
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je considère comme une bêta quelque chose que vous pouvez exécuter et qui ne décidera pas aléatoirement d'exploser si vous le laissez seul.
[11:32] Ubit Umarov : comme vous pouvez le voir sur l'ancien cycle de publication, la version à publier a été même placé
[12] Ubit Umarov : sur une branche appelée... xxx.postfixes
[11:33] Ubit Umarov : comme brak 0.9.2.0 sur git a le code release.
[11:33] Ubit Umarov : branck
[11:33] Gavin.Hird @grid.xmir.org:8002 :J'appelle cela une bêta quand il ne prend pas encore conscience qu'il fonctionne dans une machine virtuelle, et  vient avec toutes sortes de recommandations erronées basées sur le moment où le système fonctionne - comme le meilleur moment pour appliquer les mises à jour.
[11:33] Ubit Umarov : oui, je ne sais pas taper... branche 0.9.2.0 :)
[11:34] Ubit Umarov : et sur un point similaire du master, il y a le tag0.9.2.1Dev pour marquer le début du travail sur la 0.9.2.1.
[11:34] Ubit Umarov : Je pense que ceci est plus "propre", et vous ?
[11:35] Ubit Umarov: https://bitbucket.org/opensimulator/opensim/commits/

Mantis et attente de rapport de bogues : à vos tests !

Suivi des bogues : Mantis

Comment reporter un Bug? 

[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'attends l'afflux de problèmes sur la mantis et d'autres personnes qui vont faire exploser le canal IRC. La sortie a été d'une certaines manière tellement calme que personne ne l'a remarquée jusqu'à présent.
[11:36] Ubit Umarov : Beaucoup de gens ne regardent que la sortie d'une version.
[11:36] Ubit Umarov : et il y a des gens avec d'autres cas d'utilisation, etc.
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002 : Mantis a besoin d'un peu d'amour je pense, un peu plus de balises d'état et la mise à jour des numéros de version.
[11:36] Ubit Umarov : il est donc normal de recevoir plus de rapports de bogues.
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui reste sur les problèmes non résolus a besoin d'une meilleure structure pour voir ce qui existe et pourquoi.
[11:37] Ubit Umarov : nous allons voir comment ça se passe et si nous avons besoin de sortir  une version même ce mois-ci lol.
[11:37] Ubit Umarov : si un problème majeur est trouvé (et que nous pouvons le résoudre).
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'aimerais juste une étiquette "needs testing"(besion de test)  pour signaler les problèmes à revoir, soit après avoir été corrigés, soit après avoir réalisé une tonne de travail.
[11:38] Ubit Umarov: sur mantis?
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: Oui
[11:38] Gavin.Hird @grid.xmir.org:8002 : les commentaires des utilisateurs sont nécessaires.
[11:38] Ubit Umarov : Eh bien, beaucoup de gens négligent tout cela.
[11:39] Ubit Umarov : quelqu'un m'a dit qu'il ne voyait que les versions jusqu'à 0.9,1,1 à installer.
[11:39] Ubit Umarov : j'ai ajouté 0.9.2.0 et 0.9.2.1Dev et je les vois.
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux juste y apporter plus de structure pour qu'il soit plus facile de voir ce qui est encore un problème maintenant et pour que les gens qui cherchent à aider sachent clairement ce qu'ils peuvent faire pour aider.
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a probablement quelques douzaines de problèmes enfouis dedans qui devraient être examinés, mais les trouver et les confirmer demande beaucoup de travail.
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Comme tous les problèmes de freeswitch, reproduire cela est presque impossible maintenant que freeswitch devient de plus en plus difficile à configurer, semble-t-il.
[11:40] Ubit Umarov : J'espère que tout va bien pour Andrew.
[11:40] Ubit Umarov : ou son chat.
[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il s'est probablement endormi quelque part
[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : l'hiver vous fait ça.
[11:43] Vincent.Sylvester @hg.zetaworlds.com:8002 : Avec le nettoyage que j'ai fait, j'ai enterré quelques problèmes importants qui ont été soumis, je dois les retrouver et les remettre en haut de la liste je pense.
[11:44] Gavin.Hird @grid.xmir.org:8002 : comme ?

Problème de cache d'objet

issue 8934

Vidéo montrant le bogue

Autre vidéo sur le bogue 

[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002 : Surtout ce comportement bizarre du cache d'objet  qui devient ennuyeux quand il se produit.
[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002 :Je dois revenir aux tests, j'ai désactivé ce cap pour la région où cela se passait le plus mal pour voir si cela donne de meilleurs résultats.
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : Désactiver le côté viewer semble aider, mais ce n'est pas idéal.
[11:45] Gavin.Hird @grid.xmir.org:8002 : Je ne vois jamais de mise en cache bizarre des objets
[11:45] Gavin.Hird @grid.xmir.org:8002 :es-tu sûr que ce n'est pas un problème de viewer ?
[11:45] Ubit Umarov : certaines options du côté de la viewer sont brisées.
[11:45] Ubit Umarov : jamais utilisé chez SL, donc ignoré.
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pense que c'est le viewer qui ne comprend pas les données qu'il reçoit.
[11:46] Gavin.Hird @grid.xmir.org:8002 : ok, est-ce que ça enregistre quelque chose ?
[11:46] Ubit Umarov : voici Andrew le dormeur.
[11:46] Ubit Umarov : :)
[11:46] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai un journal de débogage que je dois mettre et voir ce qu'il fait, mais je soupçonne qu'il dira que tout va bien tel quel.
[11:46] Gavin.Hird @grid.xmir.org:8002 : Bonjour Andrew
[11:47] Andrew Hellershanks : Bonjour, tout le monde.
[11:47] Vincent.Sylvester @hg.zetaworlds.com:8002 : Soit l'appel est malformé en chemin vers le viewer, soit le viewer ne le comprend pas.
[11:47] Andrew Hellershanks : J'étais en train de travailler sur mon ordinateur portable et j'ai oublié quel jour on était.
[11:47] Gavin.Hird @grid.xmir.org:8002 : mais que se passe-t-il ?
[11:47] Ubit Umarov: oups
[11:47] Ubit Umarov : j'ai oublié la réunion :)
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : En fait, ce qui se passe, c'est que les anciennes prims qui sont en cache dans le viewer peuvent être éditées sans problème du point de vue de la région.
[11:48] Gavin.Hird @grid.xmir.org:8002 : maintenant nous devons recommencer à zéro.
[11:48] Ubit Umarov : ok andrew peut faire un résumé de ce que nous avons dit :)
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : Mais quand on force le viewer à redessiner la prim, il utilise la version en cache qui montre toujours l'état précédent de la prim.
[11:48] Gavin.Hird @grid.xmir.org:8002 : forcer le viewer à redessiner le prim ?
[11:49] Vincent.Sylvester @hg.zetaworlds.com:8002 : Zoomer très loin et revenir en arrière
[11:49] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai posté une vidéo sur la façon de le reproduire sur Mantis qui montre ce qui se passe.
[11:49] Gavin.Hird @grid.xmir.org:8002 : à quelle fréquence faites-vous le flush des changements vers le stockage persistant ?
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sur la région, tout va bien, tu édites, ce changement est pris en compte lorsqu'on supprime le cache du viewer, tout semble correct, c'est certainement le cache du viewer qui est en cause.
[11:50] Andrew Hellershanks: merci, Ubit.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui est étrange, c'est qu'il semble y avoir du code pour dire au viewer de purger l'objet du cache.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sans parler du fait que le viewer lui-même modifie la prim, il devrait donc savoir qu'il faut la purger du cache et récupérer une nouvelle copie à la place.
[11:50] Gavin.Hird @grid.xmir.org:8002 : pourquoi est-ce bizarre ?
[11:51] Gavin.Hird @grid.xmir.org:8002 : le cache peut être purgé ou invalidé à tout moment.
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est probablement là pour s'assurer que les choses sont purgées, mais en ce qui concerne le test de ce problème, il est étrange que le viewer ne le fasse pas lui-même, sachant quelle prim est éditée et sachant qu'il ne devrait pas utiliser la version du cache local par la suite, mais il le fait quand même.
[11:52] Gavin.Hird @grid.xmir.org:8002 : si le changement n'a pas été écrit dans le stockage persistant et que vous faites quelque chose qui force le viewer à invalider le cache et à aller chercher dans le stockage persistant, tu perds les modifications.
[11:52] Gavin.Hird @grid.xmir.org:8002 : tu dois donc configurer ta région pour qu'elle écrive plus souvent les changements dans la base de données.
[11:53] Vincent.Sylvester @hg.zetaworlds.com:8002 : L'édition sur la région fonctionne correctement, ce n'est pas le problème, tu peux le vérifier en utilisant la physique.
[11:53] Gavin.Hird @grid.xmir.org:8002 : alors où est-ce que ça ne marche pas ?
[11:53] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai réduit l'échelle d'une prim pour révéler le terrain en dessous et quand j'ai fait redessiner la prim par le Viewer en montrant la taille originale, la partie que j'ai réduite est devenue fantôme.
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: https://www.youtube.com/watch?v=pYmTDf76jcw
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ubit m'a dit de laisser le cache objet activé pour des raisons de performance, bien qu'en dehors des régions particulièrement lentes, je ne vois pas vraiment de différence, peut-être que je suis plus patient que d'autres quand il s'agit d'attendre qu'une région se charge.
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est juste que ça me rend fou quand on fait des changements sur quelque chose, qu'on se retourne pour les annuler et qu'on doit vider le cache et se reconnecter à chaque fois.
[11:57] Ubit Umarov : je vois que la mise en cache fonctionne bien la plupart du temps.
[11:57] Gavin.Hird @grid.xmir.org:8002 : Je ne pense pas que cela ait été annulé dans ton exemple, parce que lorsque tu t'es promené après le zoom, tu es arrivé à l'endroit où tu t'es approché de la prim redimensionnée.
[11:58] Gavin.Hird @grid.xmir.org:8002 : il s'agit d'un problème de transcription dans la viewer.
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, comme je l'ai dit, sur la région elle-même, le montage colle parfaitement, mais le viewer ne suit pas parce qu'il prend la version en cache.
[11:58] Ubit Umarov : ouais bien sûr, ce clip est irritant 
[11:58] Gavin.Hird @grid.xmir.org:8002 : mais je ne vois pas l'intérêt de ces zooms ?
[11:59] Vincent.Sylvester @hg.zetaworlds.com:8002 : forcer la mise à jour
[11:59] Gavin.Hird @grid.xmir.org:8002 : dans quel but ?
[11:59] Vincent.Sylvester @hg.zetaworlds.com:8002 : Donc, ce cela déclenche la récupération du cache
[11:59] Ubit Umarov : et ce n'est même pas le cache du viewer.
[11:59] Gavin.Hird @grid.xmir.org:8002: pourquoi ?
[11:59] Ubit Umarov: c'est lié à la mémoire
[11:59] Gavin.Hird @grid.xmir.org:8002 : exactement Ubit
[12:00] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est le souci, la désactivation du cache des objets du viewer directement dans le viewer supprime entièrement ce comportement.
[12:00] Gavin.Hird @grid.xmir.org:8002 : pourquoi veux-tu déclencher la récupération du cache ?
[12:00] Vincent.Sylvester @hg.zetaworlds.com:8002 : Après avoir fait cela, plus aucune prim n'avait se comporte.
[12:00] Gavin.Hird @grid.xmir.org:8002 : as-tu testé cela uniquement dans FS ?
[12:01] Gavin.Hird @grid.xmir.org:8002 : ou d'autres viewers se comportent-ils de la même façon ?
[12:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je n'ai pas encore testé avec d'autres viewers.
[12:01] Gavin.Hird @grid.xmir.org:8002 : ok, mais FS a une implémentation de cache très particulière.
[12:01] Gavin.Hird @grid.xmir.org:8002 : il pourrait donc s'agir d'un problème à ce niveau.
[12:02] Gavin.Hird @grid.xmir.org:8002 : je ne comprends toujours pas la nécessité de déclencher une récupération du cache.
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002 : Parce que lorsque vous travaillez sur quelque chose, il le fait aléatoirement pendant que vous ne regardez pas et ensuite vous vous retournez pour voir tous les changements que vous avez fait il y a une demi-heure apparemment annulés alors qu'ils ne le sont pas.
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai douté de ma santé mentale les premières fois que j'ai vu ça.
[12:03] Gavin.Hird @grid.xmir.org:8002 : jamais, jamais expérimenté cela.
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le ticket mantis existe simplement pour suivre ce problème du côté d'OpenSim et pour obtenir la vérification qu'OpenSim envoie bien les informations appropriées.
[12:03] Gavin.Hird @grid.xmir.org:8002 : quelle est la taille de la région sur laquelle tu travailles ?
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : var ou normal n'a pas d'importance, cela arrive sur les deux.
[12:04] Gavin.Hird @grid.xmir.org:8002: ok
[12:04] Gavin.Hird @grid.xmir.org:8002 : as-tu modifié les paramètres d'occlusion dans votre visionneuse ?
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'en ai parlé aux développeurs de FS, mais je n'ai pas eu de réponse, je pense que je vais ouvrir un ticket de leur côté à ce sujet pour faire avancer les choses.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai désactivé l'occlusion ambiante
[12:05] Gavin.Hird @grid.xmir.org:8002 : ce n'est pas ce que je voulais dire.
[12:06] Gavin.Hird @grid.xmir.org:8002 : les objets hors caméra peuvent être occultés pour accélérer le rendu.
[12:06] Gavin.Hird @grid.xmir.org:8002 : typiquement les objets derrière vous
[12:06] Gavin.Hird @grid.xmir.org:8002 : mais aussi des objets cachés par d'autres personnes.
[12:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : En dehors de la désactivation du cache des objets, je n'ai pas encore modifié les paramètres de débogage du viewer.
[12:07] Gavin.Hird @grid.xmir.org:8002: ok
[12:08] Gavin.Hird @grid.xmir.org:8002 : combien de mémoire GPU as-tu alloué pour le viewer ?
[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a un paramètre pour cela ?
[12:08] Gavin.Hird @grid.xmir.org:8002 : il y a de la mémoire pour les textures.
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est réglé sur 512 mo
[12:09] Gavin.Hird @grid.xmir.org:8002: ok
[12:09] Gavin.Hird @grid.xmir.org:8002 : combien de mémoire GPU as-tu ?
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je ne suis pas sûr que cela ait un rapport avec le problème, mais je pense que cela vaut la peine d'essayer.
[12:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Une Nvidia 1080 normale, donc pas tant que ça, et elle doit piloter 4 écrans, donc il lui reste probablement 2 à 4 Go pour jouer.
[12:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : Comme je l'ai dit, j'ai simplement ouvert la mantis pour que nous puissions exclure OpenSim de la cause de ce problème s'il envoie effectivement une notification appropriée pour invalider un objet qui a été modifié.
[12:11] Gavin.Hird @grid.xmir.org:8002 : Je pense avoir entendu LL dire que le code du viewer n'est pas particulièrement heureux avec une mémoire GPU au-delà de 4 Go, mais je peux me tromper.
[12:12] Ubit Umarov : opensim a envoyé la bonne information, vous avez vu le changement de taille de la Prim.
[12:12] Ubit Umarov : et le zoom est de 100% du côté de l'utilisateur.
[12:12] Gavin.Hird @grid.xmir.org:8002 : oui, c'est bien ça.
[12:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, en parcourant le code de support du cache objet, je n'ai rien trouvé qui puisse être une cause potentielle de ce problème s'il ne fonctionne pas correctement.
[12:13] Ubit Umarov : alors... vodoo
[12:13] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je vais prendre note de demander à FS via un ticket car je n'ai pas encore reçu de réponse à mon email.
[12:13] Ubit Umarov : je suppose qu'il n'est pas facile d'essayer de repo des circonstances similaires chez sl.
[12:13] Gavin.Hird @grid.xmir.org:8002 : Je pense que cela peut être dû au fait que le viewer n'invalide pas l'élément mis en cache lorsqu'il est persistant dans la région,
[12:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est ce que je pense aussi.
[12:14] Ubit Umarov : si tu te reconnectes, la prim est tel qu'elle a été éditée.
[12:14] Ubit Umarov : non ?
[12:14] Vincent.Sylvester @hg.zetaworlds.com:8002: Pas toujours, mais c'est le plus souvent le cas, si je supprime le cache, c'est toujours le cas car, il le récupère depuis la région.
[12:15] Gavin.Hird @grid.xmir.org:8002 : mais il y a du cache dans le viewer, mais aussi dans flotsam, non ?
[12:15] Ubit Umarov : donc la région a juste fait son truc...
[12:15] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai fait quelques expériences en laissant le cache et en désactivant simplement le système de mise en cache, les résultats sont mitigés et je ne sais pas non plus ce qui cause l'invalidation du cache.
[12:15] Ubit Umarov : rien à voir avec flotsam
[12:15] Ubit Umarov : les prims ne sont même pas dessus
[12:15] Gavin.Hird @grid.xmir.org:8002: ok
[12:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce problème existe depuis des années maintenant, j'ai vu cela la première fois en 2017 et depuis, tout le temps.
[12:16] Ubit Umarov : ( à moins que le rez depuis l'inventaire soit possible )
[12:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il doit s'agir d'une petite chose, juste une ligne manquante quelque part dans le code du viewer, mais les chances que je trouve cela dans la décennie sont minces.
[12:17] Gavin.Hird @grid.xmir.org:8002 : mais dans tous les cas, cela devrait être invalidé dans le cache du viewer dès qu'il y a persistance dans la région.
[12:17] Ubit Umarov : je me souviens qu'il y avait une option de cache du viewer qui affichait les prims. Si on s'éloignait et revenait... tout disparaissait jusqu'au relog :)
[12:18] Ubit Umarov : j'ai montré à un dev fs... la réponse était "pourquoi avez-vous mis cette option... elle n'est pas utilisée...".
[12:18] Ubit Umarov : fait :)

Problème de chargement de texture

[12:18] Andrew Hellershanks : Comme vous parlez du comportement des viewer et de la mise en cache, je vais ajouter un commentaire/une question au cas où cela pourrait être lié.
[12:19] Andrew Hellershanks : J'ai remarqué l'autre jour qu'après m'être connecté à une région, certaines textures étaient floues (parce qu'elles n'étaient pas encore complètement chargées ?). J'ai forcé un rafraîchissement de texture et elles se sont entièrement chargées et avaient l'air bien. Quelques instants plus tard, les textures sont redevenues floues, puis se sont chargées complètement et ont eu l'air correct.
[12:20] Andrew Hellershanks : C'est un peu bizarre qu'une texture complète se "décharge" et doive être chargée une deuxième fois.
[12:20] Gavin.Hird @grid.xmir.org:8002 : la texture est détruite.
[12:20] Gavin.Hird @grid.xmir.org:8002 : trop peu de mémoire de texture probablement.
[12:21] Vincent.Sylvester @hg.zetaworlds.com:8002 : Dayturn me faisait souvent ça, mais cela s'est arrêté il y a quelques versions.
[12:21] Andrew Hellershanks : Je n'avais pas bougé. C'était comme si une texture donnée n'était pas complètement chargée, puis chargée et affichée correctement, puis revenait à un état partiellement chargé, puis se stabilisait à un état complètement chargé.
[12:22] Andrew Hellershanks : La seule chose que je faisais pendant ce temps était d'utiliser Tex Refresh dans le viewer pour l'aider à charger une texture partiellement chargée.
[12:22] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le viewer charge d'abord les objets proches, puis tout ce qui est plus éloigné, de sorte qu'elle peut éventuellement charger une prim de la région suivante, ce qui entraîne le remplissage de la mémoire de texture.
[12:22] Gavin.Hird @grid.xmir.org:8002 : Il y a eu beaucoup de corrections sur l'allocation de la mémoire de texture, donc cela a permis de s'en débarrasser.
[12:23] Andrew Hellershanks : Vincent, ok. On dirait que c'est le côté viewer. J'utilise la dernière version de FS.
[12:23] Gavin.Hird @grid.xmir.org:8002 : de plus si vous avez des textures surdimensionnées, c'est à dire plus grandes que 1024x1024, ça devient fou.
[12:23] Ubit Umarov : regardez ce qui se passe.
[12:23] Ubit Umarov : si une prim est vieille pour être cachable...
[12:23] Andrew Hellershanks : Ce n'était pas ma région ou mes objets donc je n'ai aucune idée de la taille de la ou des textures.
[12:24] Ubit Umarov : ( simple boîte )
[12:24] Ubit Umarov : on se connecte... on redimensionne... on dézoome complètement... le changement de taille disparaît...
[12:24] Gavin.Hird @grid.xmir.org:8002 : les anciens objets peuvent avoir des textures 2048x2048 appliquées à eux.
[12:24] Ubit Umarov : fs montre la prim telle qu'elle était à la connexion, même dans l'onglet d'édition.
[12:25] Ubit Umarov : on se reconnecte et on va chercher la prim modifiée.
[12:25] Ubit Umarov : donc... fs fait un peu n'importe quoi
[12:25] Ubit Umarov : Je ne peux pas tester su sl
[12:25] Gavin.Hird @grid.xmir.org:8002 : c'est toujours possible de le faire, mais il faut que la texture de cette taille soit téléchargée directement dans la base de données.
[12:25] Ubit Umarov : parce qu'on ne peut pas recharger une boîte pendant 30 minutes ou plus.
[12:25] Ubit Umarov : ou alors...
[12:26] Ubit Umarov chuchote : tester un rez de cube sur sl et le laisser là pendant un certain temps ( 30min) ?
[12:26] Ubit Umarov : alors, il est marqué comme cachable.
[12:27] Ubit Umarov : puis connectez-vous et répétez le changement de taille : zoom arrière, zoom avant...

Conclusion

Programme des événements OSCC 2021 

[12:04] Andrew Hellershanks : Permettez-moi de faire un petit rappel. La conférence de la communauté Open Simulator a lieu ce week-end. Consultez le site Web à l'adresse https://conference.opensimulator.org/ pour connaître le programme des événements.
[12:29] Andrew Hellershanks : Nous sommes à environ une heure et demie. Est-ce que quelqu'un a d'autres questions à poser avant la fin de cette réunion ?
[12:30] Andrew Hellershanks : Je ne vois personne en train de taper, je vais donc considérer que c'est tout pour aujourd'hui.
[12:30] Selby.Evans @grid.kitely.com:8002: https://www.reddit.com/r/metaverse/
[12:30] Andrew Hellershanks : J'espère voir certains d'entre vous à l'événement OSCC ce week-end.
[12:30] Jamie.Jordan @grid.kitely.com:8002 : grande réunion.
[12:31] Andrew Hellershanks : Profitez des événements de l'OSCC. Nous pourrons en parler mardi prochain.
[12:31] Andrew Hellershanks : Merci à tous d'être venus. Nous vous reverrons la semaine prochaine.
Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_30-11-2021&oldid=107 »