« Réunion du 31-10-2023 » : différence entre les versions

De OSWiki
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Balise : wikieditor
Aucun résumé des modifications
Balise : wikieditor
 
(25 versions intermédiaires par le même utilisateur non affichées)
Ligne 2 : Ligne 2 :
* Aucun changement dans le code cette semaine.
* Aucun changement dans le code cette semaine.
* Le master va bientôt être  mis à jour vers dotnet6.
* Le master va bientôt être  mis à jour vers dotnet6.
= Avertissement =
{{Avertissement_résumé|fond=pink |bord=red |message = Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux [http://opensimulator.org/wiki/Office_hours réunions du mardi] ou  sur [http://opensimulator.org/wiki/IRC le canal IRC]}}
= Modules =
=== Test sur les cartes de région ===
* Génération d'une carte avec 13 niveaux de zoom au lieux de 9 niveaux, 12000 tuiles de région en 20 minutes environ (10 tuiles par seconde).
* Système beaucoup plus rapide que l'ancien système utilisé actuellement. La tuile est chargée en mémoire et affichée directement dans le niveau de zoom choisi. Cela semble fonctionner correctement dans les tests. Les tuiles  sont  verrouillées et ajoutées ensuite pour qu'elles ne puissent pas  entrer en conflit  avec elles-mêmes comme elles le font actuellement. Lorsqu'une région s'enregistre, cela peut prendre un certain temps pour qu'elle apparaisse à tous les niveaux de zoom, mais la carte dans le viewer est lente à se mettre à jour au premier chargement, donc ce n'est pas un gros problème. Ensuite le chargement est rapide.
* Le plus gros problème du système actuel est qu'il ne rend pas correctement les varregions.


= Noyau=
= Base de données =
= Modules =
= Bugs =
= Bugs =
== Non prise en compte des modifications des primitives ==
=== Non prise en compte des modifications des primitives ===
* Problème de [https://fr.wikipedia.org/wiki/S%C3%A9rialisation sérialisation ].
* Problème de [https://fr.wikipedia.org/wiki/S%C3%A9rialisation sérialisation ].
* Il serait utile d'avoir des tests pour vérifier que la suppression d'une prim d'une scène soit effective et ne laisse pas un fantôme de la prim.
* Il serait utile d'avoir des tests pour vérifier que la suppression d'une prim d'une scène soit effective et ne laisse pas un fantôme de la prim.
Ligne 17 : Ligne 21 :


= Tests =
= Tests =
== Tests unitaires ==
=== Tests unitaires ===
* '''Si quelqu'un veut aider à écrire des tests  il ou elle est  bienvenu.e.'''  
* '''Si quelqu'un veut aider à écrire des tests  il ou elle est  bienvenu.e.'''  
* Nunit et Xunit semblent être les deux solutions les plus utilisées actuellement. Xunit est recommandé pour l'utilisation de dotnet, Nunit étant le deuxième de la liste.
* Nunit et Xunit semblent être les deux solutions les plus utilisées actuellement. Xunit est recommandé pour l'utilisation de dotnet, Nunit étant le deuxième de la liste.
* La configuration pour faire fonctionner Xunit a réussi donc maintenant, il existe une écriture pour utiliser Xunit. Des test de Xunit sont en cours en cours et un  travail de préparation de la base de données a été réalisé.
* La configuration pour faire fonctionner Xunit a réussi donc maintenant, il existe une écriture pour utiliser Xunit. Des test de Xunit sont en cours et un  travail de préparation de la base de données a été réalisé.
* Voir [[Réunion_du_17-10-2023#Tests_unitaires | la réunion du 17-10-2023]]
* Voir [[Réunion_du_17-10-2023#Tests_unitaires | la réunion du 17-10-2023]]
* Certains anciens tests ne sont plus utiles mais d'autres ont signalé des bogues dans le passé, donc ils ne sont pas tous inutiles. Certains changements sur dotnet6 peuvent altérer les tests, car ce que les tests attendaient a changé.
* Certains anciens tests ne sont plus utiles mais d'autres ont signalé des bogues dans le passé, donc ils ne sont pas tous inutiles. Certains changements sur dotnet6 peuvent altérer les tests car les réultats attendus par les tests ont changé.
* Le but n'est pas de  les réécrire un par un les test, juste d'avoir des idées sur les parties à tester et peut-être sur les outils qui existent comme le moteur de script fictif, les aides de scène et autres.   
* Le but n'est pas de  les réécrire un par un les tests, juste d'avoir des idées sur les parties à tester et peut-être sur les outils qui existent comme le moteur de script fictif, les aides de scène et autres.   
* Le plan est de documenter les tests qui existaient, de définir les tests les plus importants et de comprendre comment ils  fonctionnaient. Cela pourrait donner une idée de ce qu'il faut encore tester comme :
* Le plan est de documenter les tests qui existaient, de définir les tests les plus importants et de comprendre comment ils  fonctionnaient. Cela pourrait donner une idée de ce qu'il faut encore tester comme :
** 🔹 les connexions,  
** 🔹 les connexions,  
Ligne 37 : Ligne 41 :
* Priorité : passer en revue les changements de dotnet à partir de master et écrire des tests pour ces changements.
* Priorité : passer en revue les changements de dotnet à partir de master et écrire des tests pour ces changements.


= viewer =
= [http://opensimulator.org/wiki/Compatible_Viewers Viewer] =
== Demande des développeurs de viewers ==
=== Demande des développeurs de viewers ===
* Si OpenSimulator veut obtenir le support des viewers, il est essentiel que toutes les différences avec SL soient documentées. Les développeurs de viewers, ont VRAIMENT BESOIN de cela.
* Si OpenSimulator veut obtenir le support des viewers, il est essentiel que toutes les différences avec SL soient documentées. Les développeurs de viewers, ont VRAIMENT BESOIN de cela.
* C'est une chose plus facile à dire qu'à faire car SL ne documente correctement pas ses protocoles et tous le reste.
* C'est une chose plus facile à dire qu'à faire car SL ne documente correctement pas ses protocoles et tous le reste. Si les développeurs ont  des questions, ils peuvent les poser sur la liste de diffusion et sur irc toute la journée et toute la semaine.
== Nouveautés côté SL ==
* Les différences  pour OpenSim :
* Mise à jour de l'AIS qui est une véritable rupture pour le code des viewers et il y en aura d'autres.
** le baking de l'avatar  qui se fait côté viewer,
** Les profils
** Hypergrid
** la gestion des varregions,
** la longueur autorisée du fichier son,
** la hauteur de construction, la taille maximale de la prim, le nombre de groupes autorisés, etc.
** pas de limite pour la longueur des identifiants de groupe et tout le reste en dehors des limites de la taille des champs de la base de données,
** alias d'url,
** [https://wiki.secondlife.com/wiki/AIS AIS] V3 n'arrivera peut-être jamais. AIS : moyen pour le Second Life Viewer de récupérer la liste des articles d'inventaire.
 
=== Nouveautés côté SL ===
* Mise à jour de l'[https://wiki.secondlife.com/wiki/AIS AIS] qui est une véritable rupture pour le code des viewers et il y en aura d'autres.
* Voir [[Réunion_du_03-10-2023#Viewers| Réunion du 03-10-2023]]


==Cool Vl viewer ==
===[http://sldev.free.fr/ Cool Vl viewer] ===
* supporte AIS.
* supporte AIS.
=== Sharpview ===
Le support des varrégions fonctionne dans Sharpview. En grande partie. Les jonctions entre  régions ne fonctionnent pas encore.


= Projets en cours / Infos=
= Projets en cours / Infos=
* [https://wiki.secondlife.com/wiki/AIS AIS] V3: changements de code sur tout ce qui concerne le stockage... toutes les bases de données et l'enregistrement des régions pour SL.
= Source=
= Source=
* http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2023-10-31
* http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2023-10-31
<!--
[11:57 AM PT]  Gavin.Hird @grid.xmir.org:8002: not really. I have noticed LL have seemingly taken a good pause in posting updates. Anyone heard if they are up to something special?
[11:57 AM PT]  Joe Magarac: A final comment. If Open Simulator wants viewer support, it's essential that all differences from SL be documented. Us viewe developers REALLY NEED THAT.
[11:58 AM PT]  Ubit Umarov: tell ll to no change things :p
[11:58 AM PT]  Ubit Umarov: to not..
[11:58 AM PT]  Vincent.Sylvester @hg.zetaworlds.com: Easier said than done with SL doesn't have their protocols and things properly documented in the first place
[11:58 AM PT]  Gavin.Hird @grid.xmir.org:8002: the AIS update is a real break for the viewer code, and there is more in the offing
[11:58 AM PT]  Joe Magarac: I'm pushing on the SL side. I make updates on their wiki. But, since OS is #2, you have to try harder.
[11:59 AM PT]  Gavin.Hird @grid.xmir.org:8002: plus they now build everything on github, which in itself is a challenge
[11:59 AM PT]  Joe Magarac: I have to implement both sides, from scratch. Document it and I will try to keep up.
[11:59 AM PT]  Gavin.Hird @grid.xmir.org:8002: unless you want to to the same and pay Microsoft a fortune for build time there
[11:59 AM PT]  Joe Magarac: If I have to reverse engineer it, it takes too long.
[12:00 PM PT]  Gavin.Hird @grid.xmir.org:8002: we already have to reverse engineer
[12:00 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Joe, we have one person doing most of the code and just a handful of others that come even close to understanding it, documenting things in our free time when we have time
[12:00 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: If you have questions you can ask on mailing list and irc all day all week
[12:01 PM PT]  Andrew Hellershanks: yup. Just remember that if you ask a question on IRC you may have to wait quite a while for an answer. Don't ask, wait a couple of minutes, then leave.
[12:01 PM PT]  Ubit Umarov: why leave? :)
[12:01 PM PT]  Joe Magarac: I need something to code against where there are major differences.
[12:02 PM PT]  Andrew Hellershanks: :)
[12:02 PM PT]  Ubit Umarov: there are major diferences already
[12:02 PM PT]  Ubit Umarov: like avatar baking that needs to be viewer side
[12:02 PM PT]  Gavin.Hird @grid.xmir.org:8002: there absolutely is Ubit
[12:02 PM PT]  Ubit Umarov: this is now a old example
[12:02 PM PT]  Joe Magarac: I'm pushing SL for more documentation, and getting some results.
[12:03 PM PT]  Gavin.Hird @grid.xmir.org:8002: loads of code to handle VAR regions in teh UI for instance
[12:03 PM PT]  Ubit Umarov: and the new ll changes liek aisv3 will possible never happen, as i said
[12:03 PM PT]  Joe Magarac: I have varregion support working in Sharpview. Mostly. Region seams don't work yet.
[12:03 PM PT]  Ubit Umarov: really not up to look to that nonsense bloat
[12:04 PM PT]  Joe Magarac: Anyway, need to go. Next meeting.
[12:04 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Yeah but SL also gets paid to sit down and write docs along with having more people for that. You are currently looking at everyone that is available for even writing such documentation
[12:04 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Profiles, bakes, hypergrid, var regions, some small inventory things apparently, what else...
[12:05 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Suppose he could just search FS source code for all the opensim switches they have as well
[12:05 PM PT]  Ubit Umarov: vincent AISv3 is not a small thing :)
[12:05 PM PT]  Orbert.Tatham @hg.zetaworlds.com: My head aches even glancing that way
[12:06 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Not that inventory thing, the thing with the parent folder
[12:06 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: inventory uuid all lowercase and my inventory parent folder is null key not avatar key
[12:06 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Kirsten, looking at you
[12:06 PM PT]  Ubit Umarov: even the stupid little pictures they are adding to inventory is really code changes on all things storage.. all dbs and region store
[12:07 PM PT]  Gavin.Hird @grid.xmir.org:8002: there are also small differences in things such as allowed length of sound file, built height, max prim size, number of allowed groups, etc etc
[12:07 PM PT]  Ubit Umarov: well our handly of inventory uuid.zero may still be a bit odd
[12:07 PM PT]  Ubit Umarov: ..handling..
[12:08 PM PT]  Ubit Umarov: for now thing we just refuse it
[12:08 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: There is also technically not a limit on group tag lengths and all that, well outside of db field size limits
[12:08 PM PT]  Ubit Umarov: even so a lot better than AIS  "current"
[12:08 PM PT]  Ubit Umarov: whatever crap current means
[12:08 PM PT]  Kayaker Magic: RL calling, gota run.
[12:09 PM PT]  Ubit Umarov: we so send many of those little changes now
[12:09 PM PT]  Ubit Umarov: on extraparameters
[12:10 PM PT]  Ubit Umarov: i mean prim size etc
[12:10 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: The url aliases as well
[12:10 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: For the stupid hop link mess
[12:10 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Give it another decade those might just start working heh
[12:11 PM PT]  Ubit Umarov: :)
[12:11 PM PT]  Gavin.Hird @grid.xmir.org:8002: :_)
[12:11 PM PT]  Andrew Hellershanks: hehe
[12:13 PM PT]  Andrew Hellershanks: It is now almost quarter past the hour. Last chance for any questions/comments for today.
[12:13 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: I have one thing, small thing
[12:13 PM PT]  Andrew Hellershanks: Go ahead, Vincent.
[12:13 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Did more tests this week on map tile stuff, added more zoom levels and ran a full refresh
[12:13 PM PT]  Ubit Umarov: don't forget about the hour change again next week !!
[12:14 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: 2023/10/30 12:59:58 - [MAP IMAGE WORKER]: Finished generating zoom levels of 11754 tiles in 1096.596511 seconds!
[12:14 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: That's 13 zoom levels instead of the normal 9
[12:14 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: 12000 region tiles in about 20 minutes
[12:14 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Not as fast as I would like, but damn side quicker than the old system currently in the code
[12:15 PM PT]  Andrew Hellershanks: If my brain isn't failing me that is 600 region tiles per minute or about 10 per second. Sounds good.
[12:16 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Roughly yes
[12:17 PM PT]  Andrew Hellershanks: Any idea roughly how long the current code takes to handle that many tiles?
[12:17 PM PT]  Ubit Umarov: think current code does it on a messy ondemand
[12:17 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Each region registration comes with a fixed one minute delay so much longer if they all register, but the bigger issue is that it doesn't properly render var regions
[12:18 PM PT]  Ubit Umarov: ie when a region does update mapt
[12:18 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Leaving spots empty and so on, when registrations overlap in the minute delay things get really messy
[12:18 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Current code uses fixed memory heavy functions to place each pixel, I just combined the images in memory via pointers, much faster that way, slightly unsafe tho
[12:19 PM PT]  Ubit Umarov: current code uses pointers also
[12:19 PM PT]  Ubit Umarov: i think...
[12:20 PM PT]  Andrew Hellershanks: I would take unsafe with it generating a tile that isn't 100% accurate as along as it won't cause a crash of the code.
[12:20 PM PT]  Ubit Umarov: wel or jsut calls draw things that do use pointers
[12:21 PM PT]  Ubit Umarov: those on win use fast directx things...
[12:21 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: bitmap get and set pixel is what it currently uses. I just load the tile into memory and dump it into whichever zoom level directly. It seems to work fine in my testing thus far. It's technically unsafe as pointers, but unless something internally breaks then it should be fine
[12:21 PM PT]  Ubit Umarov: and should use similar on linux
[12:21 PM PT]  Ubit Umarov: no those not actually the issues
[12:21 PM PT]  Ubit Umarov: we do not use bitmap set
[12:21 PM PT]  Ubit Umarov: ( i think )
[12:22 PM PT]  Ubit Umarov: when we do hard pixel xhanges we do use pointers
[12:22 PM PT]  Ubit Umarov: like on local region map draw
[12:22 PM PT]  Ubit Umarov: in fact that is the heavy work
[12:23 PM PT]  Ubit Umarov: grid side is mostly rescale and merge
[12:23 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: bm.SetPixel(x, y, c);
[12:24 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: vs just doing pointers for pixel to pixel
[12:24 PM PT]  Ubit Umarov: private void FillImage(Bitmap bm, Color c)
        {
            for (int x = 0; x < bm.Width; x  )
                for (int y = 0; y < bm.Height; y  )
                    bm.SetPixel(x, y, c);
        }
[12:24 PM PT]  Ubit Umarov: one function LOL
[12:24 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Does some heavy lifting that thing
[12:25 PM PT]  Ubit Umarov: called on one place, to fill water with a fixed color if there is no def texture
[12:25 PM PT]  Ubit Umarov: guess not even used :)
[12:25 PM PT]  Ubit Umarov: but in fact bad code
[12:26 PM PT]  Ubit Umarov: bitmap creatiosn does even has a option to do that
[12:26 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Setpixel is also in the resampled thing that writes the tiles, output.SetPixel on that
[12:26 PM PT]  Ubit Umarov: ( ofc all that bitmap code is officialy not supported by ms on dotnet )
[12:26 PM PT]  Orbert.Tatham @hg.zetaworlds.com: Ok, folks, my turn to bail out
[12:26 PM PT]  Orbert.Tatham @hg.zetaworlds.com: Srr you next week
[12:27 PM PT]  Orbert.Tatham @hg.zetaworlds.com: 8see
[12:27 PM PT]  Andrew Hellershanks: ok, Orbert. See you next week. Keep in mind the time change.
[12:27 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Getpixel and setpixel slow, pointers fast
[12:27 PM PT]  Ubit Umarov: well yeah that is officiall very slow
[12:28 PM PT]  Ubit Umarov: hm and think bitmap has native comands do so it
[12:29 PM PT]  Ubit Umarov: wle i did change region side code mostly on warp3d
[12:29 PM PT]  Ubit Umarov: not much grid side
[12:30 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Think once I am done with that entire setup it'll be a nice addition to speed up and more importantly fix up maptiles being less messy when regions register quickly one after the other
[12:30 PM PT]  Andrew Hellershanks nods
[12:30 PM PT]  Andrew Hellershanks: Sounds good, Vincent.
[12:30 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Cause I lock the set of tiles robust has and then add them so it can't get into conflicts with itself as it currently does
[12:31 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Course does mean when a region registers it might take however long the check interval is set for region to show up on all zoom levels, but map in viewer is slow to update anyhow so not a big deal
[12:31 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: Anyway that's all from my side for this week
[12:31 PM PT]  Andrew Hellershanks: ty, Vincent.
[12:32 PM PT]  Andrew Hellershanks: On that note I will call this gathering to a close.
[12:32 PM PT]  Andrew Hellershanks: Thank you all for coming. See you again next week.
[12:32 PM PT]  Motoko.Karu @login.digiworldz.com:8002: Thanks everyone
[12:32 PM PT]  Gavin.Hird @grid.xmir.org:8002: map in viewer should only be slow on initial load. On subsequent accesses it is fast
-->

Dernière version du 5 novembre 2023 à 15:42

Changements du code de la semaine

  • Aucun changement dans le code cette semaine.
  • Le master va bientôt être mis à jour vers dotnet6.

Avertissement

Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC


Modules

Test sur les cartes de région

  • Génération d'une carte avec 13 niveaux de zoom au lieux de 9 niveaux, 12000 tuiles de région en 20 minutes environ (10 tuiles par seconde).
  • Système beaucoup plus rapide que l'ancien système utilisé actuellement. La tuile est chargée en mémoire et affichée directement dans le niveau de zoom choisi. Cela semble fonctionner correctement dans les tests. Les tuiles sont verrouillées et ajoutées ensuite pour qu'elles ne puissent pas entrer en conflit avec elles-mêmes comme elles le font actuellement. Lorsqu'une région s'enregistre, cela peut prendre un certain temps pour qu'elle apparaisse à tous les niveaux de zoom, mais la carte dans le viewer est lente à se mettre à jour au premier chargement, donc ce n'est pas un gros problème. Ensuite le chargement est rapide.
  • Le plus gros problème du système actuel est qu'il ne rend pas correctement les varregions.

Bugs

Non prise en compte des modifications des primitives

  • Problème de sérialisation .
  • Il serait utile d'avoir des tests pour vérifier que la suppression d'une prim d'une scène soit effective et ne laisse pas un fantôme de la prim.
  • Mise en évidence :
    • Si vous déconnectez, reliez et supprimez rapidement certains éléments de la base de données, même si la région semble vide, redémarrez-la et les prims réapparaissent.
    • Prendre un objet lié, éditer les parties liées, délier une partie, dupliquer cette partie par shift drag, puis tout lier à nouveau et la charger dans l'inventaire. Au prochain redémarrage, la partie non liée est de nouveau sur le sol. Si on fait ça, on peut voir dans la base de données l'objet lié puis la prim non liée est ajoutée, ensuite le nouvel objet lié, l'objet lié d'origine qui est supprimé et ensuite quand on fait l'inventaire le nouvel objet lié est supprimé, la prim non liée reste par contre.
  • Explication possible: la façon asynchrone dont ces tâches sont planifiées pour ne pas retarder les choses et c'est si rapide que le résultat est perdu.
  • Solution : les mises à jour de la DB DOIVENT être retardées.

Tests

Tests unitaires

  • Si quelqu'un veut aider à écrire des tests il ou elle est bienvenu.e.
  • Nunit et Xunit semblent être les deux solutions les plus utilisées actuellement. Xunit est recommandé pour l'utilisation de dotnet, Nunit étant le deuxième de la liste.
  • La configuration pour faire fonctionner Xunit a réussi donc maintenant, il existe une écriture pour utiliser Xunit. Des test de Xunit sont en cours et un travail de préparation de la base de données a été réalisé.
  • Voir la réunion du 17-10-2023
  • Certains anciens tests ne sont plus utiles mais d'autres ont signalé des bogues dans le passé, donc ils ne sont pas tous inutiles. Certains changements sur dotnet6 peuvent altérer les tests car les réultats attendus par les tests ont changé.
  • Le but n'est pas de les réécrire un par un les tests, juste d'avoir des idées sur les parties à tester et peut-être sur les outils qui existent comme le moteur de script fictif, les aides de scène et autres.
  • Le plan est de documenter les tests qui existaient, de définir les tests les plus importants et de comprendre comment ils fonctionnaient. Cela pourrait donner une idée de ce qu'il faut encore tester comme :
    • 🔹 les connexions,
    • 🔹 l'inventaire,
    • 🔹 la sérialisation de la base de données,
    • 🔹 les téléports et
    • 🔹 les franchissements de régions.
    • 🔹 Les tests sur les permissions sont les plus récents, les règles de permissions de SL sont déroutantes. Le code de permission, l'accès aux parcelles et aux domaines sont un sac d'embouilles pour le moment, écrire des tests pour cela sera amusant.
    • 🔹 Idéalement il faudrait tester chaque module en lui envoyant des données et en vérifiant si le test réussit comme prévu ou échoue.
    • 🔹 Le problème des sensor est un peu plus difficile à tester. Un sensor qui ne fonctionne pas est ennuyeux, mais pas immédiatement dangereux. L'inventaire se corrompt à cause d'une mauvaise sérialisation, c'est un peu plus grave.
  • La prochaine chose à faire est de trouver comment enregistrer les résultats des tests et les intégrer à jenkins.
  • Jenkins peut tout à fait faire du dotnet, il suffit de changer quelques commandes, le reste est identique.
  • Priorité : passer en revue les changements de dotnet à partir de master et écrire des tests pour ces changements.

Viewer

Demande des développeurs de viewers

  • Si OpenSimulator veut obtenir le support des viewers, il est essentiel que toutes les différences avec SL soient documentées. Les développeurs de viewers, ont VRAIMENT BESOIN de cela.
  • C'est une chose plus facile à dire qu'à faire car SL ne documente correctement pas ses protocoles et tous le reste. Si les développeurs ont des questions, ils peuvent les poser sur la liste de diffusion et sur irc toute la journée et toute la semaine.
  • Les différences pour OpenSim :
    • le baking de l'avatar qui se fait côté viewer,
    • Les profils
    • Hypergrid
    • la gestion des varregions,
    • la longueur autorisée du fichier son,
    • la hauteur de construction, la taille maximale de la prim, le nombre de groupes autorisés, etc.
    • pas de limite pour la longueur des identifiants de groupe et tout le reste en dehors des limites de la taille des champs de la base de données,
    • alias d'url,
    • AIS V3 n'arrivera peut-être jamais. AIS : moyen pour le Second Life Viewer de récupérer la liste des articles d'inventaire.

Nouveautés côté SL

  • Mise à jour de l'AIS qui est une véritable rupture pour le code des viewers et il y en aura d'autres.
  • Voir Réunion du 03-10-2023

Cool Vl viewer

  • supporte AIS.

Sharpview

Le support des varrégions fonctionne dans Sharpview. En grande partie. Les jonctions entre régions ne fonctionnent pas encore.

Projets en cours / Infos

  • AIS V3: changements de code sur tout ce qui concerne le stockage... toutes les bases de données et l'enregistrement des régions pour SL.

Source