Aller au contenu

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

De OSWiki
(Différence entre les pages)
Page créée avec « =Introduction= <pre> [11:01] Andrew Hellershanks : Bonjour à tous. [11:01] Gavin.Hird @grid.xmir.org:8002 : Bonjour Andrew. [11:02] Andrew Hellershanks : Je vois qu'Ubit est à l'une des autres tables en train de déguster une boisson savoureuse aujourd'hui. [11:02] Andrew Hellershanks : :) [11:03] Gavin.Hird @grid.xmir.org:8002 : Salut Kayaker [11:03] Andrew Hellershanks : Bonjour, Kayaker. [11:04] Kayaker Magic : Salut Gavin, Andrew. [11:04] Kayaker Magic chuc... »
 
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... »
 
Ligne 1 : Ligne 1 :
=Introduction=
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>
<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] Andrew Hellershanks : Bonjour à tous.
[11:01] Gavin.Hird @grid.xmir.org:8002 : Bonjour Andrew.
[11:01] Gavin.Hird @grid.xmir.org:8002 : Je pensais à la question des assets osg.
[11:02] Andrew Hellershanks : Je vois qu'Ubit est à l'une des autres tables en train de déguster une boisson savoureuse aujourd'hui.
[11:02] Gavin.Hird @grid.xmir.org:8002 : pas la région.
[11:02] Andrew Hellershanks : :)
[11:02] Ubit Umarov : salut andrew et selby.Evans
[11:03] Gavin.Hird @grid.xmir.org:8002 : Salut Kayaker
[11:02] Gavin.Hird @grid.xmir.org:8002 : :-)
[11:03] Andrew Hellershanks : Bonjour, Kayaker.
[11:02] Ubit Umarov : ahh bien cela prendra du temps.
[11:04] Kayaker Magic : Salut Gavin, Andrew.
[11:02] Ubit Umarov : estimé à 1 mois
[11:04] Kayaker Magic chuchote : Et Shelby !
[11:02] Gavin.Hird @grid.xmir.org:8002 : donc l'année prochaine.
[11:04] Gavin.Hird @grid.xmir.org:8002 : Salut Selby
[11:02] Ubit Umarov : jusqu'à la fin de l'opération.
[11:04] Andrew Hellershanks : Bonjour, Selby.
[11:03] Gavin.Hird @grid.xmir.org:8002 : Salut Jagga
[11:04] Selby.Evans @grid.kitely.com:8002 : bonjour à tous.
[11:03] Andrew Hellershanks : Bonjour, Jagga.
[11:04] Ubit Umarov : Bonjour.
[11:03] Jagga Meredith : Bonjour.
[11:05] Andrew Hellershanks : Bonjour, Ubit.
[11:03] Ubit Umarov : yeha pas sûr que les vacances aient été prises en compte dans cette estimation du temps.
[11:05] Gavin.Hird @grid.xmir.org:8002 : Bonsoir
[11:03] Andrew Hellershanks : Le temps pour faire quoi ?
[11:05] Ubit Umarov : est-ce que l'heure a changé aux Etats-Unis aussi ?
[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:05] Gavin.Hird @grid.xmir.org:8002 : bien sûr.
[11:04] Ubit Umarov : pour ceux qui ne comprennent pas, osgrid a déplacé les services d'assets vers un autre datacenter.
[11:05] Kayaker Magic : Oui, suppression de l'heure d'été.
[11:04] Ubit Umarov : depuis quelques mois maintenant, les nouveaux services fonctionnent, récupérant les assets manquants des anciens services.
[11:05] Ubit Umarov : Bien, nous sommes de nouveau en phase.
[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:06] Ubit Umarov : bien pour une terre non plate.
[11:04] Ubit Umarov : maintenant cela a été arrêté.
[11:06] Andrew Hellershanks : oui. Les heures ont changé le week-end dernier en Amérique du Nord.
[11:05] Andrew Hellershanks : Oh. Copier les données va prendre un certain temps...
[11:06] Andrew Hellershanks : Vous êtes tous sur la piste cette fois. Nous n'avons perdu personne ou quelqu'un s'est présenté en avance. Habituellement, quelqu'un se fait surprendre par le changement d'heure.
[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>
=OpenSim s'oppose à Meta sur CNN =
=Viewer & Glow =
[https://en.wikipedia.org/wiki/Michael_Smerconish Michael Smerconish]
[https://www.dayturn.com/viewer/index.php?resources/ Les viewers Dayturn7 pour macOS et pour Windows]
<pre>
<pre>
[11:06] Ubit Umarov : alors quoi de neuf sur opensim ?
[11:09] Jamie.Jordan @grid.kitely.com:8002 : Bonjour tout le monde, je n'ai pas réussi à charger la viewer aujourd'hui.
[11:07] Jagga Meredith : J'ai mentionné opensimulator dans l'émission de Michael Smerconish ce matin.
[11:09] Gavin.Hird @grid.xmir.org:8002 : ok...
[11:07] Ubit Umarov : michael qui"
[11:10] Ubit Umarov : la visionneuse a fonctionné correctement pour moi ici.
[11:07] Ubit Umarov : ?
[11:10] Gavin.Hird @grid.xmir.org:8002 : en parlant de viewer, j'ai posté une nouvelle version il y a quelques jours.
[11:07] Gavin.Hird @grid.xmir.org:8002 : qui est-ce ?
[11:10] Andrew Hellershanks : Jamie, np. Tu as quand même réussi à venir ici.
[11:07] Jagga Meredith : Le journaliste de CNN, il a un programme sur SiriusXM.
[11:10] Ubit Umarov : seul sl a des problèmes.
[11:07] Andrew Hellershanks : Rien à signaler concernant les changements dans la base de code d'OpenSim. Juste un couple de commits mentionnant qu'il s'agit de sauvegardes.
[11:10] Andrew Hellershanks : Gavin, quelque chose de nouveau et d'excitant ?
[11:08] Gavin.Hird @grid.xmir.org:8002 : Ne regardez pas CNN...
[11:10] Gavin.Hird @grid.xmir.org:8002 : oui.
[11:08] Ubit Umarov : Michael A. Smerconish est un animateur de radio et de télévision, commentateur politique, chroniqueur de presse, auteur et avocat américain. Wikipedia
[11:10] Selby.Evans @grid.kitely.com:8002 : Bonjour Jamie.
[11:08] Andrew Hellershanks : oui, je ne regarde pas CNN et je ne reçois pas SiriusXM.
[11:10] Ubit Umarov : il faut se souvenir de l'url de Gavin :)
[11:08] Ubit Umarov : celui-là ?
vous pouvez définir des objets lumineux (glow) pour qu'ils soient 100 % transparents et qu'ils conservent leur luminosité.
[11:08] Jagga Meredith : yep
[11:11] Ubit Umarov : je veux dire l'url de téléchargement du viewer.
[11:08] Ubit Umarov : ok
[11:11] Gavin.Hird @grid.xmir.org:8002 : excellent pour faire des fantômes et d'autres choses.
[11:08] Kayaker Magic : Comment OpenSim se retrouve dans une émission de nouvelles en RL ?
[11:11] Jamie.Jordan @grid.kitely.com:8002 : Salut Selby
[11:09] Andrew Hellershanks : Jagga, était-ce un programme d'appel ? Comment en es-tu arrivé à mentionner OpenSim ?
[11:11] Andrew Hellershanks : Il ne se conservait pas du réglage du glow avant maintenant ?
[11:09] Gavin.Hird @grid.xmir.org:8002 : Meta
[11:11] Gavin.Hird @grid.xmir.org:8002: https://www.dayturn.com/viewer/index.php?resources/
[11:09] Ubit Umarov : dit que nous sommes meilleurs que zuck meta ?
[11:11] Gavin.Hird @grid.xmir.org:8002 : non.
[11:09] Jagga Meredith : oui, appelé dans le programme. J'étais en train de contester Zukerbucks.
[11:11] Ubit Umarov : ohh comme la lumière de la lune noire sur l'océan ?
[11:09] Jagga Meredith : exactement.
[11:12] Ubit Umarov : ils ont oublié de vérifier le glow sur les prims transp ?
[11:09] Gavin.Hird @grid.xmir.org:8002 : super
[11:12] Gavin.Hird @grid.xmir.org:8002 : c'est un type différent de glow Ubit.
[11:09] Gavin.Hird @grid.xmir.org:8002 : Les commentaires sur l'ARS n'ont pas vraiment été favorables.
[11:12] Ubit Umarov : mais une classe de bugs similaire :P
[11:10] Gavin.Hird @grid.xmir.org:8002 : pour Meta
[11:12] Gavin.Hird @grid.xmir.org:8002 : ils l'ont fait.
[11:10] Andrew Hellershanks : excellent, Jagga.
[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.
[11:10] Ubit Umarov : bien peur que Zuck touche un public qui n'a peut-être jamais rien su de SL, opensim, sansar, space, etc...
[11:12] Ubit Umarov : ( mais la lune ne devrait pas être sombre )
[11:10] Ubit Umarov : donc on pourrait penser que c'est une nouvelle création courageuse de Zuck.
[11:13] Gavin.Hird @grid.xmir.org:8002 : La configuration minimale requise est maintenant Windows 10, c'était XP....
[11:11] Gavin.Hird @grid.xmir.org:8002 : je crois que les gens pensent que c'est plus effrayant que courageux.
[11:13] Kayaker Magic : Hmm, j'ai profité de l'absence de lumière sur la transparence pour faire des lumières clignotantes !
[11:13] Andrew Hellershanks : Gavin, c'est un grand saut. Cela peut exclure un certain nombre d'utilisateurs.
[11:13] Gavin.Hird @grid.xmir.org:8002: oui
[11:14] Ubit Umarov : ça fait sauter 7 et 8 :)
[11:14] Gavin.Hird @grid.xmir.org:8002 : j'ai aussi monté la version macOS d'un cran.
[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" =
= Fork FireStorm, Oculus Quest et réalité virtuelle =
[https://blog.inf.ed.ac.uk/atate/ Blog d'Austin Tate]
 
[https://blog.inf.ed.ac.uk/atate/2020/12/11/firestorm-vr-mod-6-4-12/ Firestorm VR Mod 6.4.12 ]
 
[https://fr.wikipedia.org/wiki/CATIA CATIA : Conception Assistée Tridimensionnelle Interactive Appliquée de la coompagnie Dassault Systèmes]
<pre>
<pre>
[11:11] Ubit Umarov : je me demande si Maria a réussi à faire fonctionner ce fork fs (firestorm) sur l'Oculus Quest de Zuck.
[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:12] Gavin.Hird @grid.xmir.org:8002 : est-ce qu'elle l'a forké ?
[11:15] Gavin.Hird @grid.xmir.org:8002 : Il existe un script de lumières clignotantes dans la bibliothèque LSL.
[11:12] Ubit Umarov : joker :P
[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:12] Ubit Umarov : quelqu'un a ajouté le support 3D d'Oculus.
[11:15] Gavin.Hird @grid.xmir.org:8002 : donné*.
[11:12] Kayaker Magic : Ça s'appelait le fork ctrl-alt-del, n'est-ce pas ? Et ça n'a  pas été fait par Maria.
[11:15] Ubit Umarov : l'asset sera là en 2022 :)
[11:13] Ubit Umarov : ai austin en parle sur son blog.
[11:15] Andrew Hellershanks : Kayaker, l'article du forum dit que vous devrez peut-être attendre un mois.
[11:13] Kayaker Magic : J'ai entendu dire qu'il était dépassé par la FS actuelle.
[11:16] Ubit Umarov : un script clignotant ?
[11:13] Gavin.Hird @grid.xmir.org:8002 : donc, cela redémarre en permanence ?
[11:16] Gavin.Hird @grid.xmir.org:8002 : oui.
[11:13] Selby.Evans @grid.kitely.com:8002 : Zuck touche un public naïf, mais beaucoup d'autres personnes s'adressent également à ce public.
[11:16] Ubit Umarov : oui, j'ai l'asset.
[11:13] Gavin.Hird @grid.xmir.org:8002 : n'est-ce pas à cela que sert ctrl-alt-del ?
[11:16] Gavin.Hird @grid.xmir.org:8002 : il utilise le glow.
[11:14] Andrew Hellershanks : :)
[11:16] Ubit Umarov : qui en a besoin ?
[11:14] Ubit Umarov : j'ai bien peur que ce ne soit pas une chose facile et fiable à utiliser... mais cela montre des choses sur l'univers  google.
[11:16] Ubit Umarov:  
[11:15] Ubit Umarov: https://blog.inf.ed.ac.uk/atate/
  timer()
[11:15] Ubit Umarov : c'est le blog d'ai.
    {
[11:15] Ubit Umarov: https://blog.inf.ed.ac.uk/atate/2020/12/11/firestorm-vr-mod-6-4-12/
        isOn = !isOn;
[11:15] Ubit Umarov : il semble être à jour par rapport à fs, en quelque sorte.
        if( isOn ) llSetLinkPrimitiveParamsFast( LINK_THIS,[PRIM_GLOW,faceNo,glowAmount] );
[11:16] Ubit Umarov : bien entendu, l'ajout d'éléments de RV en 3D est une chose possible du côté du viewer.
        else llSetLinkPrimitiveParamsFast( LINK_THIS,[PRIM_GLOW,faceNo,0.0] );
[11:17] Ubit Umarov : non pas que je veuille particulièrement utiliser de telles choses :)
    }
[11:18] Gavin.Hird @grid.xmir.org:8002 : LL pense qu'il n'est pas possible pour le moteur de rendu actuel de générer les FPS nécessaires pour éviter le mal de mer.
[11:16] Ubit Umarov: c'est ça
[11:18] Ubit Umarov : oui, c'est loin d'être le cas.
[11:17] Andrew Hellershanks : Un script simple et agréable.
[11:19] Ubit Umarov : l'industrie veut au moins 90fps.
[11:17] Gavin.Hird @grid.xmir.org:8002: url de téléchargement du viewer : https://www.dayturn.com/viewer/index.php?resources/
[11:19] Gavin.Hird @grid.xmir.org:8002: pui
[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:19] Andrew Hellershanks: 90??
[11:18] Gavin.Hird @grid.xmir.org:8002 : mettez-le dans un cube Ubit.
[11:19] Ubit Umarov: Oui
[11:18] Ubit Umarov : les clignotants peuvent être un bon tueur de région.
[11:19] Ubit Umarov : même avec cela, il y a encore beaucoup de problèmes.
[11:18] Kayaker Magic : Donc le viewer fait tout le travail.
[11:19] Gavin.Hird @grid.xmir.org:8002 : en fait 90x2
[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:19] Ubit Umarov : les gens ne peuvent pas les supporter trop longtemps.
[11:18] Andrew Hellershanks : Ubit, cela dépend en partie du timer utilisé.
[11:20] Gavin.Hird @grid.xmir.org:8002 : les images par œil sont légèrement différentes.
[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:20] Ubit Umarov : c'est les raisons pour lesquelles Phil a abandonné son projet de haute fidélité.
[11:19] Ubit Umarov: il semble que les régions soient complètement hors service à cause de cela
[11:20] Ubit Umarov : si je me souviens...
[11:19] Ubit Umarov: flood complet sur lludp
[11:20] Gavin.Hird @grid.xmir.org:8002 : ça doit être exact.
[11:19] Ubit Umarov: llSetTextureAnim est une bonne façon d'éviter cela
[11:20] Ubit Umarov : l'industrie du bâtiment les utilise depuis longtemps.
[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:20] Gavin.Hird @grid.xmir.org:8002 : c'est probablement pour cela que Sansar a aussi disparu.
[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:21] Ubit Umarov : si je me souviens bien, Catia dispose de la visualisation 3D depuis longtemps.
[11:20] Jagga Meredith: kewl
[11:21] Gavin.Hird @grid.xmir.org:8002 : bon sang !
[11:21] Ubit Umarov : j'espère que toutes les lumières de Noël utiliseront une animation de texture ou similaire.
[11:21] Ubit Umarov : ( catia est un CAD industriel etc )
[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:21] Gavin.Hird @grid.xmir.org:8002 : Les stations de travail Catia...
[11:22] Ubit Umarov : ce n'est pas seulement le CPU.
[11:22] Gavin.Hird @grid.xmir.org:8002 : on les vendait pour une fortune...
[11:22] Ubit Umarov : c'est une utilisation massive de lludp.
[11:22] Ubit Umarov : je pense que Catia coûte encore une fortune :)
[11:22] Objet : Script en cours d'exécution
[11:22] Gavin.Hird @grid.xmir.org:8002 : Je parie
[11:22] Gavin.Hird @grid.xmir.org:8002 : il est probable que la licence soit la plus coûteuse de nos jours.
[11:23] Ubit Umarov : créé par dassault pour faire des mirages ? :)
[11:23] Gavin.Hird @grid.Qbit.org:8002 : et les riches commerciaux d'IBM.
[11:23] Ubit Umarov : les systèmes de soudure et les autres systèmes industriels de CAO et d'intégration ont une vue 3D depuis des années...
[11:24] Gavin.Hird @grid.xmir.org:8002 : Je pense que le Catia original fonctionnait sur les mainframes IBM.
[11:24] Ubit Umarov : je pense que leurs lunettes ne coûtent pas 300$ comme l'oculus quest :p
[11:25] Jamie.Jordan @grid.kitely.com:8002 : J'adore l'Oculus Quest
[11:25] Ubit Umarov : mais pour opensim, les viewers ont besoin de magie pour se rapprocher des 90fps.
[11:25] Ubit Umarov : et les gens qui ont des rtx 3090 :p
[11:26] Ubit Umarov : correctement, il garde un oeil sur le vrai matériel que les gens ont.
[11:27] Ubit Umarov : cela inclut les petits gpus intégrés.
[11:27] Gavin.Hird @grid.xmir.org:8002 : Il a été créé sur l'ordinateur central IBM System/370.
[11:27] Andrew Hellershanks : Le meilleur résultat que j'ai obtenu était d'environ 60 FPS avec une vieille carte Nvidia 8600GT. Dès que vous commencez à vous déplacer et que la vue change beaucoup, le taux de rafraîchissement chute toujours. Je ne sais pas ce qu'il faudrait pour obtenir 90 ou 90x2 pour utiliser un casque.
[11:27] Ubit Umarov : à l'époque, je suppose que ces IBM étaient la meilleure option :)
[11:28] Ubit Umarov : les fps dépendent du contenu de la région.
[11:28] Ubit Umarov : j'obtiens 60 ici.
[11:28] Ubit Umarov : en fait, c'est limité.
[11:28] Ubit Umarov : je limite la fps à 60.
[11:28] Andrew Hellershanks : oh, les bons vieux systèmes IBM 360 et 370.  Ça me rappelle des souvenirs.
[11:29] Andrew Hellershanks : Rien qu'en étant assis ici, j'en ai environ 40.
[11:29] Ubit Umarov : mais ce n'est pas la limite, c'est ce que je peux obtenir ici :)
[11:29] Ubit Umarov : J'ai fixé la limite à 65.
[11:30] Gavin.Hird @grid.xmir.org:8002 : Je n'obtiens que 26 FPS, mais le rendu est à 4x la résolution normale à cause de l'écran Retina.
[11:31] Gavin.Hird @grid.xmir.org:8002 : la résolution est de 3360 x 2088.
[11:31] Jagga Meredith : Le kayakiste avait une question.  J'en ai une aussi.
[11:31] Ubit Umarov : il faut juste mentionner que Google fait des choses, parce que c'est un truc du côté des viewers.
[11:31] Ubit Umarov : les serveurs SL et opensim peuvent tous les deux servir ce genre viewer.
[11:32] Ubit Umarov : ( amusant comment mon F et mon D sont devenus si différents )
[11:32] Ubit Umarov : (kinf od == kind of)
</pre>
</pre>
 
= Incidence des scripts sur une région =
= Stockage des meshes, avatars maillés et animeshes ? =  
[http://wiki.secondlife.com/wiki/Mesh/Mesh_Asset_Format Format de mesh / asset mesh]
 
<pre>
<pre>
[11:27] Kayaker Magic : Question sur la façon dont les assets sont stockés : J'ai entendu ici que les meshes sont stockés en tant que fichiers LLM. Quand je regarde le format de fichier LLM, il ne permet que 2 poids de bones par vertex, alors que je pensais que les meshes dans OpenSim pouvaient avoir jusqu'à 4 bones par vertex. Si c'est le cas, vous ne pouvez pas utiliser LLM. Comment sont stockés les meshes dans la base de données des assets ?
[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:31] Andrew Hellershanks : Kayaker, je pense que LLM sert juste pour les corps des avatars mais je n'ai pas regardé comment les données sont stockées.
[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:32] Andrew Hellershanks : Kayaker, est-ce que vous travaillez sur quelque chose à faire avec un avatar basé sur un mesh  ou sur un autre objet basé sur un mesh ?
[11:23] Gavin.Hird @grid.xmir.org:8002 : voici le script blink.
[11:33] Ubit Umarov: llm?
[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:33] Ubit Umarov : les fichiers avatars du système ?
[11:24] Jagga Meredith : non copiable
[11:33] Kayaker Magic : J'ai écrit du code pour vider les fichiers LLM des avatars du système, j'ai écrit du code pour en créer de nouveaux. Oui, OK pour les avatars par défaut, ça ne devrait pas fonctionner sur les avatars maillés ou animesh. Donc la question reste posée : Comment les avatars  en mesh et les animesh sont stockés dans les assets ?
[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:34] Ubit Umarov : nous avions un code partiel sur libopenmetaverse.
[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:34] Ubit Umarov : il n'y a pas de support pour les morphs.
[11:24] Ubit Umarov : en fait, ils le peuvent.
[11:34] Gavin.Hird @grid.xmir.org:8002 : il est stocké comme n'importe quel autre mesh.
[11:24] Gavin.Hird @grid.xmir.org:8002 : l'aspect est un peu étrange lorsque la transparence est de 100%.
[11:34] Andrew Hellershanks : Ubit, les meshes Collada sont-ils stockés tels quels lors du téléchargement ou sont-ils convertis dans un autre format ?
[11:24] Ubit Umarov : mais pas la source.
[11:34] Ubit Umarov : hmmm c'est le format ll.
[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:35] Ubit Umarov : non
[11:25] Ubit Umarov : mais lludp est là en plus des stats.
[11:35] Ubit Umarov : en fait, il semble que Collada ne supporte pas toutes les choses nécessaires.
[11:25] Ubit Umarov : ( ce qu'on ne voit pas c'est http, sauf sur singularity =
[11:35] Kayaker Magic : OK, comment est stocké tout autre mesh ? Quel format ? On m'a dit qu'ils sont convertis en LLM. Cela ne peut pas être vrai pour animesh.
[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:35] Ubit Umarov murmure : quelle est la relation avec animesh ?
[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:35] Gavin.Hird @grid.xmir.org:8002 : pourquoi cela ne peut-il pas être vrai ?
[11:26] Ubit Umarov : singularity a un truc sympa sur l'utilisation de la bande passante http.
[11:35] Ubit Umarov : les viewers savent comment lire et utiliser ces fichiers.
[11:26] Ubit Umarov : maintenant je vois que j'utilise 50Mo tout seul :p
[11:36] Gavin.Hird @grid.xmir.org:8002 : animehs est juste un flag sur le mesh quand il est lu depuis le serveur.
[11:26] Ubit Umarov : sur une région
[11:36] Ubit Umarov : qui ont été créés exclusivement comme des choses de visualisation locale.
[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:36] Kayaker Magic : Animesh est un mesh qui a une armature et des poids. Avant  animesh, seuls les avatars en mesh avaient ces éléments.
[11:28] Ubit Umarov : j'ai changé la restriction http sur les assets.
[11:37] Kayaker Magic : Alors répondez à cette question : Comment les avatars en meshes de Ruth/Roth sont-ils stockés dans les assets ?
[11:28] Andrew Hellershanks : :)
[11:37] Ubit Umarov : c'est un peu la logique inverse : seuls les avatars en mesh peuvent être animés.
[11:28] Gavin.Hird @grid.xmir.org:8002 : maintenant le cube avec le script peut être copié.
[11:37] Gavin.Hird @grid.xmir.org:8002 : un flag  indique au viewer de commencer à traiter le mesh différemment.
[11:29] Ubit Umarov : remplacé throttle par autre chose, juste plus intéressé par l'utilisation raisonnable.
[11:37] Ubit Umarov : les avatars du système ne SONT pas stockés dans les assets.
[11:29] Jagga Meredith : *regarde le cube, hypnotisée*.
[11:37] Ubit Umarov : ils sont locaux pour les viewers.
[11:29] Ubit Umarov : et avec le type de priorité des données.
[11:37] Gavin.Hird @grid.xmir.org:8002 : vous définissez vous-même le flag après avoir téléchargé un mesh riggé.
[11:29] Ubit Umarov : au cas où vous n'auriez pas remarqué, les avatars se rechargent beaucoup plus vite maintenant :p
[11:37] Kayaker Magic chuchote : Ruth n'est pas un avatar du système. Répondez à la question : Comment est-elle stockée dans les assets ?
[11:29] Andrew Hellershanks : hm... je me demande si quelqu'un a déjà fabriqué une lampe à lave ?
[11:37] Ubit Umarov : quoi Ruth ?
[11:29] Ubit Umarov : si vous et votre région avez de la bande passante...
[11:38] Kayaker Magic : Ruth est un avatar maillé disponible gratuitement.
[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:38] Gavin.Hird @grid.xmir.org:8002 : Ruth EST l'avatar du système
[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:38] Ubit Umarov : certains appellent Ruth à l'avatar du système
[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:38] Kayaker Magic : Ruth2.0 est un avatar maillé open-source.
[11:31] Ubit Umarov : a
[11:38] Gavin.Hird @grid.xmir.org:8002 : le fait que quelqu'un ait appelé un avatar en mesh de la même façon est trompeur.
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : Bonne mesure de l'horloge du processeur en voyant à quelle vitesse la lumière change.
[11:38] Andrew Hellershanks : Il y a de nouveaux avatars Ruth et Roth basés sur les meshes.
[11:38] Ubit Umarov : c'est un MESH comme les autres avatars mesh.
[11:38] Kayaker Magic : Un peu comme Athena mais avec environ 300 000 vertex en moins.
[11:38] Ubit Umarov : aucun rapport avec l'avatar du système.
[11:39] Kayaker Magic : Je sais.
[11:39] Ubit Umarov : juste un autre modèle d'avatar maillé.
[11:39] Kayaker Magic : Comment sont stockés les avatars maillés hors système ?????
[11:39] Kayaker Magic : en tant que XML ?
[11:39] Gavin.Hird @grid.xmir.org:8002 : comme n'importe quel mesh que vous téléchargez.
[11:39] Kayaker Magic : En tant que LLM ?
[11:39] Ubit Umarov : non.
[11:39] Ubit Umarov : en tant que assets mesh.
[11:39] Kayaker Magic : en tant que DAE
[11:39] Ubit Umarov murmure : NON
[11:39] Kayaker Magic : Ok, comment sont stockés les assets maillés ?
[11:39] Ubit Umarov : DAE est seulement le format que les viewers comprennent pour importer anc covert.
[11:40] Kayaker Magic : Pourquoi est-ce si difficile d'obtenir une réponse ?
[11:40] Ubit Umarov : les meshes sont stockés dans un autre format de ressource ll.
[11:40] Gavin.Hird @grid.xmir.org:8002 : en tant que format binaire compressé.
[11:40] Ubit Umarov : pas difficile, je l'ai dit plusieurs fois.
[11:40] Kayaker Magic : C'est un format binaire ou texte spécifique à LL ?
[11:40] Gavin.Hird @grid.xmir.org:8002 : binaire.
[11:40] Kayaker Magic : où se trouve la documentation sur la façon de le lire ?
[11:40] Gavin.Hird @grid.xmir.org:8002 : Dans le code du visualisateur
[11:41] Ubit Umarov : en fait ll a le format public, contrairement aux autres.
[11:41] Ubit Umarov : http://wiki.secondlife.com/wiki/Mesh/Mesh_Asset_Format
[11:41] Kayaker Magic : J'ai trouvé la documentation pour LLM, il n'est pas capable de stocker des avatars maillés.
[11:41] Ubit Umarov : encore une fois llm est un format pour les viewers locaux seulement.
[11:42] Kayaker Magic : OK, ce document semble prometteur. Merci !
[11:42] Ubit Umarov : ce qu'on appelle le mesh de prims (qui inclut le mesh avatar) est importé par les viewers depuis Collada et converti dans le format décrit dans le lien ci-dessus.
[11:43] Ubit Umarov : et ce format n'a aucune utilité pour vous.
[11:43] Ubit Umarov : à moins que vous ne prévoyiez de créer un tout nouveau téléchargeur/éditeur  de meshes.
[11:43] Kayaker Magic : Vous ne pouvez pas le savoir.
[11:43] Ubit Umarov : c'est un peu le cas :)
[11:44] Ubit Umarov : mais plusieurs choses sur ce site aident à comprendre certaines limitations.
[11:44] Kayaker Magic : Voici une utilisation : Je veux faire un lecteur de mesh qui calcule un hash des données des vertex dans les assets, pour les comparer avec les données vertext dans un DAE. Pour détecter les violations de copyright.
[11:45] Ubit Umarov : pas aussi clair ailleurs, comme la résolution de 16bits.
[11:45] Andrew Hellershanks : Si vous connaissez le format de stockage des données du mesh dans la table des assets, il est possible d'en faire quelque chose.
[11:45] Ubit Umarov : ce hash est 100% inutile.
[11:45] Ubit Umarov : mais bon, je ne vais pas revenir là dessus.
[11:45] Gavin.Hird @grid.xmir.org:8002 : pour essayer de mettre un scanner de photos Apple sur les données opensim ?
[11:46] Kayaker Magic : les photos sont un problème différent.
[11:47] Gavin.Hird @grid.xmir.org:8002 : pas vraiment Kayaker.
[11:47] Gavin.Hird @grid.xmir.org:8002 : une autre chose est qu'il n'y a pas de relation biunivoque entre la base de données et ce qui est stocké.
[11:48] Gavin.Hird @grid.xmir.org:8002 : le dae est transformé de toutes sortes de façons selon les paramètres de téléchargement choisis par l'uploader.
[11:48] Ubit Umarov : DAE est juste un format d'importation
[11:48] Ubit Umarov : cela pourrait être FBX
[11:49] Gavin.Hird @grid.xmir.org:8002 : oui, c'est le cas.
[11:49] Ubit Umarov : et ce n'est pas seulement pour les droits
[11:49] Ubit Umarov : et aucun développeur de viewer n'a pris soin de faire un tel importateur.
 
[11:49] Ubit Umarov : (bien sûr, un projet "amusant")
[11:50] Ubit Umarov : je ne suis pas sûr de l'état actuel des droits fbx, qui étaient auparavant restreints.
[11:51] Gavin.Hird @grid.xmir.org:8002 : probablement des restrictions sur les versions FBX les plus récentes.
[11:52] Kayaker Magic : Quand vous écrirez un importateur FBX pour la visionneuse Ubit, je serai impressionné. Jusque-là, il n'est pas pertinent.
[11:53] Ubit Umarov : et bien, rien  de spécial.
[11:53] Ubit Umarov : DAE était un autre échec
[11:53] Ubit Umarov : comme jpeg2000
[11:53] Ubit Umarov : ils ont parié que ce serait des standards industriels.
[11:53] Gavin.Hird @grid.xmir.org:8002 : toujours un échec relativement réussi.
[11:54] Ubit Umarov : et ils n'ont pas réussi à le faire... personne ne les utilise.
[11:54] Andrew Hellershanks : J'aurais aimé avoir un format autre que DAE car mon principal programme de modélisation 3D ne le supporte pas. Je dois exporter puis importer dans Blender pour convertir en DAE.
[11:54] Ubit Umarov : fbx et jpeg se sont avérés être les standards pour ces choses.
[11:54] Gavin.Hird @grid.xmir.org:8002 : Je suis impatient de voir quels formats Meta va utiliser...
[11:55] Ubit Umarov : mais bon, nous ne pouvons pas blâmer les décisions prises en 2003 ou plus tard.
[11:55] Ubit Umarov : je suppose que fbx n'était pas une chose à l'époque... au moins ouvert à l'utilisation.
[11:55] Ubit Umarov : mais collada a des limitations.
[11:56] Ubit Umarov : comme vous l'avez constaté kayaker
[11:56] Ubit Umarov : ( et des conneries xml insensées )
[11:56] Gavin.Hird @grid.xmir.org:8002 : En 1996, Kaydara a publié un nouveau format de fichier natif avec Filmbox 1.5 appelé FBX.
[11:57] Gavin.Hird @grid.xmir.org:8002 : En 2003, Kaydara a lancé FBX pour QuickTime Viewer d'Apple.
[11:57] Ubit Umarov : ok, donc FBX existait déjà.
[11:57] Gavin.Hird @grid.xmir.org:8002 : Oui.
[11:57] Ubit Umarov : mais je pense que vous deviez payer des droits.
[11:57] Gavin.Hird @grid.xmir.org:8002 : bien sûr.
[11:57] Ubit Umarov : comme jpeg etc.
[11:57] Ubit Umarov : les choses ne sont pas libres d'utilisation.
[11:58] Ubit Umarov : mpeg etc...
[11:59] Gavin.Hird @grid.xmir.org:8002 : Apple paie un tas de licences pour toutes sortes de formats supportés par leurs SDK. Mais évidemment pas étendus à d'autres plateformes,
</pre>
</pre>


= Stockage du nom d'un groupe ? =
= Nouvelles d'OpenSim cette semaine =
* 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:46] Jagga Meredith : dans quelle table le nom du groupe est-il stocké ? où est-ce documenté ?    Ce n'est pas ici http://opensimulator.org/wiki/Database:Documentation
[11:31] Ubit Umarov : ok, et quelles sont les nouvelles que vous avez sur opensim ?
[11:47] Ubit Umarov : quel nom de groupe ?
[11:31] Ubit Umarov: :)
[11:47] Ubit Umarov : et nous avons environ 3 modules de groupes, 2 utilisables.
[11:32] Andrew Hellershanks : Pas beaucoup de changements cette semaine mais quelques uns.
[11:47] Ubit Umarov : chacun avec sa propre base de données.
[11:33] Andrew Hellershanks : Certains paramètres qui étaient auparavant uniquement disponibles pour XEngine sont maintenant disponibles dans YEngine.
[11:47] Jagga Meredith : celui avec UUID dans la table des terrains.
[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:48] Jagga Meredith : pour les terrains appartenant à un groupe.
[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:48] Ubit Umarov : l'uuid du groupe de terrain est stocké dans les données des parcelles.
[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:48] Jagga Meredith : ok, et le nom ?
[11:34] Ubit Umarov: jezzz
[11:50] Andrew Hellershanks : Jagga, il y a plusieurs tables pour les groupes. Si vous utilisez les groupes de base, les noms des groupes sont dans os_groups_groups. Si vous utilisez le système de groupe basé sur phpxmlrpc, c'est osgroup.
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : Demande à une vache Andrew, ils en font beaucoup j'ai entendu.
[11:51] Jagga Meredith : Andrew, ce sont des tables ?
[11:34] Jagga Meredith : de l'essence ? (Je sais, "ne démarre pas")
[11:52] Andrew Hellershanks : Jagga, oui.
[11:34] Andrew Hellershanks : Vincent, je pensais que c'était du méthane.
[11:52] Jagga Meredith : ok.
[11:34] Andrew Hellershanks : :)
[11:52] Andrew Hellershanks : J'utilise le système de groupes phpxmlrpc donc j'ai l'ensemble des tables de groupes dans une base de données séparée. Si vous utilisez les groupes de base, les tables seront dans les tables principales d'opensim, AFAIK.
[11:34] Ubit Umarov : c'est plutôt du méthane Vincent :)
[11:55] Kayaker Magic : Jagga, tu as eu la réponse à ta question ?
[11:35] Gavin.Hird @grid.xmir.org:8002 : Vous produisez tous beaucoup de CO2
[11:55] Jagga Meredith : yep
[11:35] Gavin.Hird @grid.xmir.org:8002 : chaque expiration contient 40 fois plus de CO2 que votre inspiration.
[11:35] Ubit Umarov : oui, mais notre CO2 est équilibré.
[11:35] Ubit Umarov : les plantes ont tout capturé au cours de notre vie.
[11:36] Ubit Umarov : donc notre co est en quelque sorte "neutre".
[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: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:36] Ubit Umarov: :p
[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:37] Ubit Umarov : "essayez de sauver quelques zeptogrammes de CO2"
[11:37] Ubit Umarov : pas optimiste sur l'impact réel sur le co2 :p
[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:37] Andrew Hellershanks : Ubit, j'ai lu ça et je n'ai aucune idée de ce que cela signifie.
[11:37] Ubit Umarov : vous le savez maintenant :p
[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:38] Andrew Hellershanks cherche la définition de zeptogramme.
[11:38] Andrew Hellershanks : Aucun mot de ce type n'a été trouvé dans le dictionnaire.
[11:38] Gavin.Hird @grid.xmir.org:8002: :-)
[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:38] Ubit Umarov : tu as un mauvais dictionnaire lol
[11:39] Ubit Umarov : c'est 10^-21 gramme :p
[11:39] Gavin.Hird @grid.xmir.org:8002: yeah
[11:39] Gavin.Hird @grid.xmir.org:8002 : 1 zeptogramme = 0,001 attogramme
[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:39] Gavin.Hird @grid.xmir.org:8002 : ou 1 000 yoctogrammes.
[11:40] Andrew Hellershanks : Je n'ai jamais vu zepto avant en termes d'unité de mesure.
[11:40] Ubit Umarov : en fait, les mantis 7896 et 7910 étaient un bug que nous avions depuis toujours.
[11:40] Ubit Umarov : j'espère que c'est corrigé maintenant.
[11:40] Ubit Umarov : en fait, je l'ai fait aujourd'hui.
[11:40] Andrew Hellershanks : Jagga, j'utilise souvent pico.
[11:40] Jagga Meredith : exactement.
[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:41] Ubit Umarov : difficile d'économiser le même picogramme de CO2 en changeant quelques lignes de code :p
[11:41] Ubit Umarov : difficile d'économiser...
[11:42] Jagga Meredith : c'est vieux.
[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:43] Ubit Umarov : actuellement le code LSLapi les recherche dans les moteurs respectifs.
[11:43] Ubit Umarov : j'ai donc fait une copie de ces fichiers.
[11:44] Ubit Umarov : possible dans le futur qu'ils aient leur propre section.
[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: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:45] Ubit Umarov : pas pour gavin.Hird.
[11:46] Ubit Umarov : mais c'est sûr pour les serveurs en Pologne par exemple.
[11:47] Gavin.Hird @grid.xmir.org:8002 : ne pas économiser du CO2, mais réduire la facture d'électricité.
[11:47] Ubit Umarov : j'envisage d'underclocker ma machine :)
[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.
[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.
[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 ?
[11:49] Andrew Hellershanks : Bonjour, Dennis.
[11:50] Gavin.Hird @grid.xmir.org:8002 : Salut Dennis
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pourrais écrire un test comme ça, je suppose.
[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.
[11:50] Andrew Hellershanks : J'ai trouvé des problèmes de timing avec KFM et/ou llTargetOmega.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Techniquement, on peut exécuter n'importe quel script et vérifier le résultat.
[11:51] Gavin.Hird @grid.xmir.org:8002 : LL n'a-t-il pas publié un grand nombre de tests de script ?
[11:51] Ubit Umarov : celui que j'ai partagé avec Vincent est l'un de ceux-là gavin.Hird
[11:52] Gavin.Hird @grid.xmir.org:8002: http://wiki.secondlife.com/wiki/LSL_Test_Harness
[11:52] Ubit Umarov : mais utile pour vérifier l'ordre des évènements.
[11:52] Gavin.Hird @grid.xmir.org:8002: ok
</pre>
</pre>


= La table Userdata des profils =
= Timer et précision =
<pre>
[11:56] Kayaker Magic : Alors ma prochaine question est : En regardant la base de données robuste d'OpenSim, je vois une table nommée userdata qui ressemble à un magasin clé=valeur pour les avatars. Mais elle semble inutilisée. Y a-t-il du code quelque part pour configurer cela ?
[11:58] Andrew Hellershanks : Kayaker, userdata ? Je ne vois pas de table avec ce nom dans mes bases de données.
[11:59] Kayaker Magic : La dernière fois que j'ai créé une grille, la base de données Robust était fournie avec une table nommée 'userdata' (aussi userpicks, userprofile, usersettings, etc.).
[11:59] Andrew Hellershanks : Kayaker, je vérifie les fichiers de migration qui ont été créés dans la version 5 du système de base ( ?) des profils utilisateurs.
[12:00] Ubit Umarov : je ne vois pas de table appelée userdata.
[12:00] Gavin.Hird @grid.xmir.org:8002 : une grille complète possède une table userdata.
[12:00] Gavin.Hird @grid.xmir.org:8002 : une connexion osg n'en a pas.
[12:00] Andrew Hellershanks : Je n'utilise pas les profils de base donc je n'ai pas cette table.
[12:00] Ubit Umarov : ohh ok c'est là dans les profils.
[12:00] Gavin.Hird @grid.xmir.org:8002 : car osg héberge cette table.
[12:01] Kayaker Magic : 'userdata' un mot, juste avant 'usernotes' qui semble avoir des données du profil de l'utilisateur dans le monde.
[12:01] Kayaker Magic : Oui, toutes les données robustes dans OSG sont sur leurs serveurs, mais si vous créez une grille locale, vous obtenez votre propre base de données robuste.
[12:01] Gavin.Hird @grid.xmir.org:8002 : exact.
[12:02] Gavin.Hird @grid.xmir.org:8002 : il n'y a pas d'enregistrement sur ma grille, donc...
[12:02] Kayaker Magic : Même chose ici.
[12:02] Kayaker Magic : Je me demandais si je pouvais l'utiliser pour implémenter un key-value store pour mes utilisateurs.
[12:02] Kayaker Magic : Même ajouter une fonction OSSL pour le faire.
[12:03] Gavin.Hird @grid.xmir.org:8002 : à en juger par les noms des fichiers, c'est possible.
[12:03] Ubit Umarov : peut-être une fonctionnalité importée d'avn sans utilité
[12:03] Kayaker Magic : Mais comme la table est là, je me demandais si quelqu'un l'avait déjà fait.
[12:03] Kayaker Magic : Un module pour ça ?
[12:04] Andrew Hellershanks : Kayaker, je vois beaucoup de références à cette table dans Region/CoreModules/Framework/UserManagement/UserManagementModule.cs.
[12:04] Ubit Umarov : non, la 0.8.2 l'avait déjà.
[12:04] Gavin.Hird @grid.xmir.org:8002 : ça ressemble à une intention.
[12:06] Kayaker Magic : je suppose que je vais essayer de lire le code de ce module.
[12:07] Kayaker Magic : (RTFC : Read The Fing Code, au lieu de RTFM)
[12:07] Andrew Hellershanks : Je l'ai juste regardé. Je ne peux pas vraiment dire si/comment il est utilisé.
[12:08] Andrew Hellershanks : Un champ est HasGridUserTried. Aucune idée de ce que c'est.
[12:08] Gavin.Hird @grid.xmir.org:8002 : Il était probablement destiné à être utilisé d'une manière intelligente, mais a été oublié.
[12:08] Kayaker Magic : Intelligent !
[12:08] Ubit Umarov : ouais ça ressemble à un truc "intelligent" très peu performant.
[12:08] Ubit Umarov : j'espère que nous ne l'utiliserons pas vraiment.
</pre>
= Activer et désactiver la fonctionnalité animesh ? =  
[http://wiki.secondlife.com/wiki/LlStartObjectAnimation LlStartObjectAnimation]
<pre>
<pre>
[12:08] Kayaker Magic : J'ai manqué quelques réunions, j'ai beaucoup de questions aujourd'hui ! La prochaine : Y a-t-il un moyen d'activer et de désactiver l'animesh ? Comme il y en a un pour 'phantom' et 'physics', etc. ? ?
[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:09] Gavin.Hird @grid.xmir.org:8002 : il y a un switch dans la viewer.
[11:52] Ubit Umarov : une affaire qui a fait fumer un peu le cerveau de Vincent :)
[12:09] Gavin.Hird @grid.xmir.org:8002 : sous l'onglet "Features" dans le menu flottant "tools".
[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:09] Kayaker Magic : Y a-t-il un moyen de le faire à partir d'un script, comme 'phantom' et 'phyics' etc. ?
[11:53] Andrew Hellershanks : Dans certains cas, le viewer peut être (en partie ?) la cause des problèmes de timing.
[12:10] Gavin.Hird @grid.xmir.org:8002 : avez-vous vérifié s'il existe une fonction lsl qui permette de faire cela ?
[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:10] Ubit Umarov : il suffit de ne pas lancer d'animation dessus.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sur la plupart des régions, sauf les plus chargées, cela fonctionne assez bien.
[12:11] Kayaker Magic : Je pensais que cela devrait être dans llSetStatus ou des fonctions similaires, mais il n'y a pas de nouvelles constantes.
[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:11] Andrew Hellershanks : Je ne trouve aucune mention d'une fonction LSL avec le mot "mesh" dedans.
[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:11] Ubit Umarov : et pourquoi une telle chose ?
[11:55] Ubit Umarov : (jesus non :P )
[12:11] Kayaker Magic : J'aimerais qu'un script se souvienne de l'activer à ma place quand j'oublie, comme on le fait avec la physique des véhicules.
[11:55] Dennis Ravnsholm : Merci.
[12:11] Kayaker Magic : J'aimerais voir si je peux contourner certains bugs du viewer en l'activant et en la désactivant.
[11:56] Ubit Umarov : ne fais pas ça :p
[12:11] Ubit Umarov : la physique permet de ménager le cpu quand il n'est pas requis.
[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:12] Kayaker Magic : le désactiver et l'activer lors du passage d'une région par exemple.
[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:12] Ubit Umarov : cela n'économiserait aucun cpu.
[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:12] Andrew Hellershanks : Je n'ai pas vu de moyen de contrôler l'animation des meshes dans les paramètres des primitives.
[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:13] Ubit Umarov : et aucune idée de l'impact d'un changement de flag sur les viewers en continu.
[11:57] Andrew Hellershanks : Vous partez, kayakiste ?
[12:13] Andrew Hellershanks : Je n'ai fait qu'une recherche rapide donc j'ai pu le manquer ou il est caché quelque part ailleurs dans les fonctions LSL.
[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:13] Kayaker Magic : Je ne le trouve pas non plus... :(
[11:58] Kayaker Magic : Pas moi ! Quelqu'un a atterri sur ma tête pourtant...
[12:13] Ubit Umarov : je pense qu'on n'y a jamais pensé, parce que ce n'est pas utile.
[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:14] Andrew Hellershanks : Peut-être avons-nous besoin d'une fonction os pour faire cela.
[11:58] Andrew Hellershanks : oh, ok. On aurait dit que tu étais debout.
[12:14] Andrew Hellershanks regarde Ubit.
[11:59] Kayaker Magic : Bienvenue Dennis !
[12:14] Gavin.Hird @grid.xmir.org:8002 : http://wiki.secondlife.com/wiki/LlStartObjectAnimation
[11:59] Kayaker Magic murmure : Tu as une heure de retard pour la réunion !
[12:14] Kayaker Magic : Cela nécessite que vous définissiez le bit d'abord, seulement disponible dans le viewer.
[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:15] Kayaker Magic : Cela ne fait rien si vous avez oublié.
[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:15] Gavin.Hird @grid.xmir.org:8002 : oui, cela fait partie de la préparation de l'animesh.
[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:15] Gavin.Hird @grid.xmir.org:8002 : donc ça ne devrait pas être un fardeau énorme.
[12:02] Gavin.Hird @grid.xmir.org:8002 : le code du timing du viewer  est dans llcommon/llfasttimer.cpp/h
[12:15] Andrew Hellershanks : Gavin, on dirait que ça pourrait être ce que Kayaker veut. Facile à trouver quand on connaît le nom de ce que l'on cherche ;)
[12:02] Gavin.Hird @grid.xmir.org:8002 : parce que vous avez aussi llcommon/llframetimer.cpp/h.
[12:15] Ubit Umarov : si et quand vous me montrez comment un tel changement de flag pourrait être utile, je l'ajouterai :p
[12:02] Andrew Hellershanks : Gavin, merci. Je vais devoir chercher l'équivalent dans OS.
[12:15] Gavin.Hird @grid.xmir.org:8002 : J'ai simplement duckducké pour ça.
[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:15] Kayaker Magic : De plus en plus, je trouve qu'animesh n'est qu'un autre gros coup de LL, hacké sur des choses déjà faites au lieu d'être conçu.
[12:03] Gavin.Hird @grid.xmir.org:8002 : et llcommon/llheartbeat.cpp/h
[12:15] Gavin.Hird @grid.xmir.org:8002: duckduckwent*
[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:16] Andrew Hellershanks : Gavin, ok. Je regardais la liste des fonctions LSL dans le wiki.
[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:16] Gavin.Hird @grid.xmir.org:8002 : Qu'est-ce qui vous a pris si longtemps pour le réaliser Kayaker ?
[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:16] Kayaker Magic: LOL
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : Encore une fois, plus l'intervalle de temps est faible, plus c'est mauvais.
[12:16] Gavin.Hird @grid.xmir.org:8002 : c'était assez clair lors de son développement :-)
[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:17] Ubit Umarov : je ne vois pas de relation entre le démarrage de l'animation et le changement du flag de l'objet animesh, mais ok.
[12:05] Andrew Hellershanks : Vincent, pas si c'est bien fait.
[12:17] Gavin.Hird @grid.xmir.org:8002 : Je suppose que vous ne pouvez pas le changer à partir d'un script intentionnellement.
[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:17] Ubit Umarov : ahh une bonne raison...
[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:18] Ubit Umarov : la région n'a aucune idée si un mesh peut l'avoir.
[12:05] Gavin.Hird @grid.xmir.org:8002 : Il est probable que ce ne soit pas le cas, Andrew.
[12:18] Gavin.Hird @grid.xmir.org:8002 : Ce ne serait pas amusant si vous pouviez changer n'importe quel mesh qui contient une animation (comme un vendeur) en un animesh ?
[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:18] Ubit Umarov : et avoir la région pour récupérer l'asset, le décoder et voir s'il peut être  animé, bien sûr, c'est un NON NON.
[12:07] Gavin.Hird @grid.xmir.org:8002 : bien sûr.
[12:20] Ubit Umarov : tu as eu ta réponse sur pourquoi ne pas jouer avec ce drapeau avec les scripts kayak ?
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:21] Ubit Umarov : c'est un élément de construction à définir après le téléchargement.
[12:08] Jagga Meredith : *a un mal de tête récursif*.
[12:21] Kayaker Magic : Non, mais j'ai supposé que c'était caché dans le viewer.
[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:21] Kayaker Magic : Comme la physique.
[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:21] Kayaker Magic : Tout comme le fantôme
[12:08] Jagga Meredith : Temps GPS
[12:21] Kayaker Magic : Comme beaucoup de choses.
[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:21] Ubit Umarov : non, ce n'est PAS le cas.
[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:21] Ubit Umarov : des choses très différentes.
[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:21] Gavin.Hird @grid.xmir.org:8002 : caché dans le viewer ?
[12:12] Jagga Meredith : vous supposez que la transmission des "tics d'horloge" est instantanée.
[12:22] Gavin.Hird @grid.xmir.org:8002 : le viewer n'exécute pas de scripts.
[12:12] Gavin.Hird @grid.xmir.org:8002 : et que les tics de l'horloge sont une constante.
[12:22] Kayaker Magic : Le viewer a un bouton pour activer ou désactiver l'animesh.
[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:22] Gavin.Hird @grid.xmir.org:8002 : le serveur utilise des scripts.
[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:22] Ubit Umarov : et la plupart d'entre eux devraient rester prédéfinis.., mais ils sont en fait plus légers que le flag.
[12:13] Gavin.Hird @grid.xmir.org:8002 : oui pour les horloges en temps réel.
[12:22] Kayaker Magic : La façon dont le viewer le fait pourrait être liée à la façon dont un script peut le faire.
[12:13] Gavin.Hird @grid.xmir.org:8002 : mais l'horloge du processeur n'est pas constante.
[12:23] Ubit Umarov : le mesh doit avoir quelque chose avant que le flag soit autorisé.
[12:13] Jagga Meredith : ...comme d'autres choses qui se passent au niveau du serveur.
[12:23] Kayaker Magic : Je résiste à poser plus de questions, étant donné le temps.
[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:23] Ubit Umarov : et je le répète, Regins ne peut pas ne pas aller vérifier ça sur le maillage.
[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:23] Kayaker Magic : Je résiste à poser plus de questions, étant donné le temps.
[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.
[12:23] Ubit Umarov : et je le répète, 'Regins' ne peut pas ne pas aller vérifier ça sur le mesh.
[12:24] Ubit Umarov : la physique et le phanton ne devraient pas non plus être modifiés en permanence.
[12:25] Ubit Umarov : ils peuvent être très lourd aussi bien sûr.
[12:25] Ubit Umarov : même si c'est plus léger que d'analyser la mesh.
[12:26] Ubit Umarov : dans le futur opensim devrait parser et valider les meshes pour plusieurs utilisations.
[12:26] Ubit Umarov : l'idée originale d'opensim de juste faire confiance aux viewers est bien sûr MAUVAISE.
[12:27] Ubit Umarov : cela rend juste la vie beaucoup plus simple :)
[12:27] Ubit Umarov : spécialement quand les développeurs d'opensim n'ont aucune idée des détails des choses ;)
[12:28] Ubit Umarov : mais c'est aussi le genre de travail que personne ne considère... totalement invisible...
 
</pre>
</pre>
 
=Conclusion=
= OSCC 2021 et conclusion=  
[https://conference.opensimulator.org/ OSCC : 11-12 décembre 2021]
<pre>
<pre>
[12:17] Andrew Hellershanks : Avant que tout le monde commence à disparaître, j'ai une annonce à faire.
[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:17] Andrew Hellershanks : Marquez vos calendriers pour le week-end du 11 et 12 décembre. Ce sont les dates de la conférence de la communauté Open Simulator de cette année. Les détails peuvent être trouvés sur https://conference.opensimulator.org/
[12:21] Andrew Hellershanks : S'il n'y a rien d'autre, ce sera tout pour cette semaine.
[12:19] Jamie.Jordan @grid.kitely.com:8002 : Je vais sortir, bonne réunion, merci à tous.
[12:21] Andrew Hellershanks : Merci à tous d'être venus. Nous vous reverrons la semaine prochaine.
[12:19] Andrew Hellershanks : ok, Jamie. Merci d'être venu.
[12:19] Ubit Umarov : Merci Andrew.
[12:20] Ubit Umarov : c'est de nouveau l'heure de l'oscc... jezz le temps passe vite...
[12:21] Gavin.Hird @grid.xmir.org:8002 : La nouvelle version du viewer a été postée sur http://wiki.secondlife.com/wiki/LlStartObjectAnimation il y a quelques jours.
12:22] Andrew Hellershanks : Ubit, oui. Ça revient vite. Le fait de ne pas pouvoir aller où que ce soit ou de ne pas pouvoir faire grand chose donne l'impression que le temps cache le passage du temps :)
[12:24] Selby.Evans @grid.kitely.com:8002 : je dois y aller -- bye all
[12:24] Gavin.Hird @grid.xmir.org:8002 : Bye Selby
[12:24] Kayaker Magic : Au revoir Selby !
[12:24] Ubit Umarov : au revoir Selby.Evans
[12:25] Kayaker Magic : Pouf, il était déjà parti.
[12:26] Andrew Hellershanks : Je vais devoir partir dans environ 5 minutes.
[12:27] Andrew Hellershanks : :)
[12:29] Gavin.Hird @grid.xmir.org:8002 : As-tu fait ton annonce Andrew ?
[12:29] Ubit Umarov : il l'a fait lol
[12:29] Gavin.Hird @grid.xmir.org:8002 : Oh !
[12:30] Andrew Hellershanks : Gavin, j'ai annoncé la date de l'OSCC de cette année.
[12:31] Gavin.Hird @grid.xmir.org:8002 : ok.
[12:31] Andrew Hellershanks : Les 11 et 12 décembre.
[12:31] Gavin.Hird @grid.xmir.org:8002 : comme je l'ai dit l'année dernière, le moment n'est pas idéal au milieu des préparatifs de Noël.
[12:32] Andrew Hellershanks : Quels préparatifs ?
[12:32] Andrew Hellershanks : :)
[12:32] Gavin.Hird @grid.xmir.org:8002 : toutes sortes d'activités RL se déroulant tout au long du mois de décembre.
[12:32] Gavin.Hird @grid.xmir.org:8002 : y compris les fêtes d'avant Noël.
[12:33] Andrew Hellershanks : La seule chose qui est également prévue (bientôt ?) est le Black Friday et le Cyber Monday.
[12:33] Gavin.Hird @grid.xmir.org:8002 : faire de la nourriture, brasser de la bière, goûter de la bière, faire du shopping, planifier, décorer.....
[12:34] Gavin.Hird @grid.xmir.org:8002 : montrer de la neige
[12:34] Gavin.Hird @grid.xmir.org:8002 : J'ai oublié ça.
[12:34] Andrew Hellershanks : meh. Il ne se passe pas grand-chose chez moi. Quelques cartes électroniques à envoyer et quelques cadeaux pour la famille.
[12:34] Gavin.Hird @grid.xmir.org:8002 : Ai-je mentionné le pelletage de la neige ?
[12:34] Andrew Hellershanks : Il faut que j'y aille.
[12:35] Andrew Hellershanks : Je vais clore la réunion d'aujourd'hui. Merci à tous d'être venus. Nous nous reverrons la semaine prochaine.
</pre>
</pre>

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

Traduction prochaine.

Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2021-11-30

Introduction & Migration des assets sur Osgrid

Migration des assets sur Osgrid

[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 à la question des assets osg.
[11:02] Gavin.Hird @grid.xmir.org:8002 : pas la région.
[11:02] Ubit Umarov : salut andrew et selby.Evans
[11:02] Gavin.Hird @grid.xmir.org:8002 : :-)
[11:02] Ubit Umarov : ahh bien cela prendra du temps.
[11:02] Ubit Umarov : estimé à 1 mois
[11:02] Gavin.Hird @grid.xmir.org:8002 : donc l'année prochaine.
[11:02] Ubit Umarov : jusqu'à la fin de l'opération.
[11:03] Gavin.Hird @grid.xmir.org:8002 : Salut Jagga
[11:03] Andrew Hellershanks : Bonjour, Jagga.
[11:03] Jagga Meredith : Bonjour.
[11:03] Ubit Umarov : yeha pas sûr que les vacances aient été prises en compte dans cette estimation du temps.
[11:03] Andrew Hellershanks : Le temps pour faire quoi ?
[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:04] Ubit Umarov : pour ceux qui ne comprennent pas, osgrid a déplacé les services d'assets vers un autre datacenter.
[11:04] Ubit Umarov : depuis quelques mois maintenant, les nouveaux services fonctionnent, récupérant les assets manquants des anciens services.
[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.

Viewer & Glow

Les viewers Dayturn7 pour macOS et pour Windows

[11:09] Jamie.Jordan @grid.kitely.com:8002 : Bonjour tout le monde, je n'ai pas réussi à charger la viewer aujourd'hui.
[11:09] Gavin.Hird @grid.xmir.org:8002 : ok...
[11:10] Ubit Umarov : la visionneuse a fonctionné correctement pour moi ici.
[11:10] Gavin.Hird @grid.xmir.org:8002 : en parlant de viewer, j'ai posté une nouvelle version il y a quelques jours.
[11:10] Andrew Hellershanks : Jamie, np. Tu as quand même réussi à venir ici.
[11:10] Ubit Umarov : seul sl a  des problèmes.
[11:10] Andrew Hellershanks : Gavin, quelque chose de nouveau et d'excitant ?
[11:10] Gavin.Hird @grid.xmir.org:8002 : oui.
[11:10] Selby.Evans @grid.kitely.com:8002 : Bonjour Jamie.
[11:10] Ubit Umarov : il faut se souvenir de l'url de Gavin :)
 vous pouvez définir des objets lumineux (glow) pour qu'ils soient 100 % transparents et qu'ils conservent leur luminosité.
[11:11] Ubit Umarov : je veux dire l'url de téléchargement du viewer.
[11:11] Gavin.Hird @grid.xmir.org:8002 : excellent pour faire des fantômes et d'autres choses.
[11:11] Jamie.Jordan @grid.kitely.com:8002 : Salut Selby
[11:11] Andrew Hellershanks : Il ne se conservait pas du réglage du glow avant maintenant ?
[11:11] Gavin.Hird @grid.xmir.org:8002: https://www.dayturn.com/viewer/index.php?resources/
[11:11] Gavin.Hird @grid.xmir.org:8002 : non.
[11:11] Ubit Umarov : ohh comme la lumière de la lune noire sur l'océan ?
[11:12] Ubit Umarov : ils ont oublié de vérifier le glow sur les prims transp ?
[11:12] Gavin.Hird @grid.xmir.org:8002 : c'est un type différent de glow Ubit.
[11:12] Ubit Umarov : mais une classe de bugs similaire :P
[11:12] Gavin.Hird @grid.xmir.org:8002 : ils l'ont fait.
[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.
[11:12] Ubit Umarov : ( mais la lune ne devrait pas être sombre )
[11:13] Gavin.Hird @grid.xmir.org:8002 : La configuration minimale requise est maintenant Windows 10, c'était XP....
[11:13] Kayaker Magic : Hmm, j'ai profité de l'absence de lumière sur la transparence pour faire des lumières clignotantes !
[11:13] Andrew Hellershanks : Gavin, c'est un grand saut. Cela peut exclure un certain nombre d'utilisateurs.
[11:13] Gavin.Hird @grid.xmir.org:8002: oui
[11:14] Ubit Umarov : ça fait sauter 7 et 8 :)
[11:14] Gavin.Hird @grid.xmir.org:8002 : j'ai aussi monté la version macOS d'un cran.
[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 )

Lumières clignotantes "J'espère que toutes les lumières de Noël utiliseront une animation de texture"

[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:15] Gavin.Hird @grid.xmir.org:8002 : Il existe un script de lumières clignotantes dans la bibliothèque LSL.
[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:15] Gavin.Hird @grid.xmir.org:8002 : donné*.
[11:15] Ubit Umarov : l'asset sera là en 2022 :)
[11:15] Andrew Hellershanks : Kayaker, l'article du forum dit que vous devrez peut-être attendre un mois.
[11:16] Ubit Umarov : un script clignotant ?
[11:16] Gavin.Hird @grid.xmir.org:8002 : oui.
[11:16] Ubit Umarov : oui, j'ai l'asset.
[11:16] Gavin.Hird @grid.xmir.org:8002 : il utilise le glow.
[11:16] Ubit Umarov : qui en a besoin ?
[11:16] Ubit Umarov: 
   timer()
    {
        isOn = !isOn;
        if( isOn ) llSetLinkPrimitiveParamsFast( LINK_THIS,[PRIM_GLOW,faceNo,glowAmount] );
        else llSetLinkPrimitiveParamsFast( LINK_THIS,[PRIM_GLOW,faceNo,0.0] );
    }
[11:16] Ubit Umarov: c'est ça
[11:17] Andrew Hellershanks : Un script simple et agréable.
[11:17] Gavin.Hird @grid.xmir.org:8002: url de téléchargement du viewer : https://www.dayturn.com/viewer/index.php?resources/
[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:18] Gavin.Hird @grid.xmir.org:8002 : mettez-le dans un cube Ubit.
[11:18] Ubit Umarov : les clignotants peuvent être un bon tueur de région.
[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

Incidence des scripts sur une région

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

Nouvelles d'OpenSim cette semaine

  • 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 7896 et 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
  • LSL Test Harness
[11:31] Ubit Umarov : ok, et quelles sont les nouvelles que vous avez sur opensim ?
[11:31] Ubit Umarov: :)
[11:32] Andrew Hellershanks : Pas beaucoup de changements cette semaine mais quelques uns.
[11:33] Andrew Hellershanks : Certains paramètres qui étaient auparavant uniquement disponibles pour XEngine sont maintenant disponibles dans YEngine.
[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:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : On ne peut pas vraiment établir de statut "à tester" ou "ne peut pas être corrigé maintenant".
[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:34] Ubit Umarov: jezzz
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : Demande à une vache Andrew, ils en font beaucoup j'ai entendu.
[11:34] Jagga Meredith : de l'essence ? (Je sais, "ne démarre pas")
[11:34] Andrew Hellershanks : Vincent, je pensais que c'était du méthane.
[11:34] Andrew Hellershanks : :)
[11:34] Ubit Umarov : c'est plutôt du méthane Vincent :)
[11:35] Gavin.Hird @grid.xmir.org:8002 : Vous produisez tous beaucoup de CO2
[11:35] Gavin.Hird @grid.xmir.org:8002 : chaque expiration contient 40 fois plus de CO2 que votre inspiration.
[11:35] Ubit Umarov : oui, mais notre CO2 est équilibré.
[11:35] Ubit Umarov : les plantes ont tout capturé au cours de notre vie.
[11:36] Ubit Umarov : donc notre co est en quelque sorte "neutre".
[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: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:36] Ubit Umarov: :p
[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:37] Ubit Umarov : "essayez de sauver quelques zeptogrammes de CO2"
[11:37] Ubit Umarov : pas optimiste sur l'impact réel sur le co2 :p
[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:37] Andrew Hellershanks : Ubit, j'ai lu ça et je n'ai aucune idée de ce que cela signifie.
[11:37] Ubit Umarov : vous le savez maintenant :p
[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:38] Andrew Hellershanks cherche la définition de zeptogramme.
[11:38] Andrew Hellershanks : Aucun mot de ce type n'a été trouvé dans le dictionnaire.
[11:38] Gavin.Hird @grid.xmir.org:8002: :-)
[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:38] Ubit Umarov : tu as un mauvais dictionnaire lol
[11:39] Ubit Umarov : c'est 10^-21 gramme :p
[11:39] Gavin.Hird @grid.xmir.org:8002: yeah
[11:39] Gavin.Hird @grid.xmir.org:8002 : 1 zeptogramme = 0,001 attogramme
[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:39] Gavin.Hird @grid.xmir.org:8002 : ou 1 000 yoctogrammes.
[11:40] Andrew Hellershanks : Je n'ai jamais vu zepto avant en termes d'unité de mesure.
[11:40] Ubit Umarov : en fait, les mantis 7896 et 7910 étaient un bug que nous avions depuis toujours.
[11:40] Ubit Umarov : j'espère que c'est corrigé maintenant.
[11:40] Ubit Umarov : en fait, je l'ai fait aujourd'hui.
[11:40] Andrew Hellershanks : Jagga, j'utilise souvent pico.
[11:40] Jagga Meredith : exactement.
[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:41] Ubit Umarov : difficile d'économiser le même picogramme de CO2 en changeant quelques lignes de code :p
[11:41] Ubit Umarov : difficile d'économiser...
[11:42] Jagga Meredith : c'est vieux.
[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:43] Ubit Umarov : actuellement le code LSLapi les recherche dans les moteurs respectifs.
[11:43] Ubit Umarov : j'ai donc fait une copie de ces fichiers.
[11:44] Ubit Umarov : possible dans le futur qu'ils aient leur propre section.
[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: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:45] Ubit Umarov : pas pour gavin.Hird.
[11:46] Ubit Umarov : mais c'est sûr pour les serveurs en Pologne par exemple.
[11:47] Gavin.Hird @grid.xmir.org:8002 : ne pas économiser du CO2, mais réduire la facture d'électricité.
[11:47] Ubit Umarov : j'envisage d'underclocker ma machine :)
[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.
[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.
[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 ?
[11:49] Andrew Hellershanks : Bonjour, Dennis.
[11:50] Gavin.Hird @grid.xmir.org:8002 : Salut Dennis
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pourrais écrire un test comme ça, je suppose.
[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.
[11:50] Andrew Hellershanks : J'ai trouvé des problèmes de timing avec KFM et/ou llTargetOmega.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Techniquement, on peut exécuter n'importe quel script et vérifier le résultat.
[11:51] Gavin.Hird @grid.xmir.org:8002 : LL n'a-t-il pas publié un grand nombre de tests de script ?
[11:51] Ubit Umarov : celui que j'ai partagé avec Vincent est l'un de ceux-là gavin.Hird
[11:52] Gavin.Hird @grid.xmir.org:8002: http://wiki.secondlife.com/wiki/LSL_Test_Harness
[11:52] Ubit Umarov : mais utile pour vérifier l'ordre des évènements.
[11:52] Gavin.Hird @grid.xmir.org:8002: ok

Timer et précision

[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.
[11:52] Ubit Umarov : une affaire qui a fait fumer un peu le cerveau de Vincent :)
[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.
[11:53] Andrew Hellershanks : Dans certains cas, le viewer peut être (en partie ?) la cause des problèmes de timing.
[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.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sur la plupart des régions, sauf les plus chargées, cela fonctionne assez bien.
[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.
[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.
[11:55] Ubit Umarov : (jesus non :P )
[11:55] Dennis Ravnsholm : Merci.
[11:56] Ubit Umarov : ne fais pas ça :p
[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.
[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é.
[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.
[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.
[11:57] Andrew Hellershanks : Vous partez, kayakiste ?
[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.
[11:58] Kayaker Magic : Pas moi ! Quelqu'un a atterri sur ma tête pourtant...
[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.
[11:58] Andrew Hellershanks : oh, ok. On aurait dit que tu étais debout.
[11:59] Kayaker Magic : Bienvenue Dennis !
[11:59] Kayaker Magic murmure : Tu as une heure de retard pour la réunion !
[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: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: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:02] Gavin.Hird @grid.xmir.org:8002 : le code du timing du viewer  est dans llcommon/llfasttimer.cpp/h
[12:02] Gavin.Hird @grid.xmir.org:8002 : parce que vous avez aussi llcommon/llframetimer.cpp/h.
[12:02] Andrew Hellershanks : Gavin, merci. Je vais devoir chercher l'équivalent dans OS.
[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.

Conclusion

[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:21] Andrew Hellershanks : S'il n'y a rien d'autre, ce sera tout pour cette semaine.
[12:21] Andrew Hellershanks : Merci à tous d'être venus. Nous vous reverrons la semaine prochaine.