Hello, Avatar!

Second Life et Programmation Créative

Aller au contenu | Aller au menu | Aller à la recherche

Hypergrid : la revue de Justincc

Pour compléter le billet de LeoMaxx sur l'Hypergrid avec des informations plus techniques, voici tel quel une revue du fonctionnement de l'hypergrid, brut de décoffrage droit sortie de la mailing list des developpeurs d'OpenSim.

Cool, the patch in http://opensimulator.org/mantis/view.php?id=2640 now builds and passes tests (for what that's worth, currently) against r7391 right now.

Having read Cristina's wiki page and the code, I think the hypergrid is a neat architecture. Essentially, a hypergrid is a confederation of grids. Each user has their own home grid or standalone, which is where their user profile, inventory and assets are stored. When they travel to a different grid via a hyperlink (set up via some funky map and region handle manipulation), the new grid is told the address of that user's home asset and inventory services. Thus

1. If a user rezzes an object from their inventory, the assets for that object are fetched from the home asset service and permanently inserted into the foreign asset service. So when that user goes away or logs off, the assets are still available to be seen by everybody else.

2. If a user copies/takes an object from a foreign grid, then the relevant inventory and asset data gets sent to their own home services.

Please correct me if I'm wrong, Diva.

As I see it, on a conceptual level, some of the pros are:

  • Effectively distributes asset and inventory load over multiple services on multiple grids. This is a really good

alternative to scaling up a central service to internet scale.

  • Allows grids to seamlessly linked to others yet retain control over their own services.

And the cons:

  • Assets are liberally spread around grids. I don't think that this is much of an issue in view of the client hole, but

this is merely my own opinion.

  • Regions must be manually linked and appear in a grid's map. One can't just enter an address in a url bar to go to

another grid, the grid owner must set up the link. As far as I can see this is a limitation of what we have to work with in the client. There may be some arguments for restriction (you don't want someone coming to your pg grid from an adult grid and depositing god knows what).

  • Services need to be exposed to other grids. So malicious grids could possibly fetch and put things they shouldn't. I

think Diva already has some proposals for dealing with this. This may also be another good argument for controlling who can link to you, for now.

I've read the code but I don't intend to actually run it right now - I was more concerned about trying to identify any nasty architectural problems. As far as I can see there is nothing too significant. However, I do see some implementation weaknesses.

1. Assets associated with worn attachments and appearance are not uploaded to a foreign grid from the home grid on teleport in. For other users without cache copies, such avatars will always appear gray and I don't think that any attachments would appear. This is fixable.

2. Prim inventory inspection does not go deep enough. As far as I can see, in the 'asset mapper' you look for contained textures when rezzing an item, but not any other contained assets (including contained objects, clothing, notecards, scripts, etc.). This will result in an incomplete rez. However, this is fixable. Indeed, I've already written all the code required to do this for the OpenSim archiver. If this patch goes in then this should be reused.

3. Better class and method documentation. From what I've seen, what appears to be there at the moment is probably a result of initial copy and paste from existing code. I know this is the pot calling the kettle black to some extent, but I feel that proper class and method documentation is something that we ought to be working towards, to help prevent parts of the code from turning into the private fiefdom of whoever originally wrote it. Also, logging messages are not quite correctly formatted (colons are missing after the <log name> section and copyrights are missing or inconsistent.

4. The code exists in separate Hypergrid packages from all the existing OpenSim packages. This is very understandable due to its origin as a forge module. And I think we can take it as is, but these separate packages should probably go away over time.

Items 1, 2 and 4 could be fixed up after an initial patch goes in. However, I really would like to see more documentation, license fixes and log message uniformity (3). Please could you do this, Cristina?

If this is done then in my opinion the hypergrid facility would be a +1 addition to what is currently in the core. However, I'm not an expert on various areas (map, teleport) so would greatly appreciate another pair of eyes if anyone can spare them. Therefore, if we are to commit this patch I think we should hold off until Monday of next week to give anybody else a chance to look at it.

I'd also quite like to know who intends to support this in the future. It would be a shame if we took it in and then nobody was prepared to keep it going (which I think would mean eventual removal).

Sorry for the long post.

Regards,

justincc

SLTris fonctionne sur OpenSim

C'est une bonne soirée : mon jeu fétiche, SLTris, écrit il y'a plus d'un an fonctionne (enfin) sur un OpenSim.

OSTris.png

Il a été rebaptisé pour l'occasion "OSTris" :)

Dans la foulée, je travaille sur une version édulcorée de Bubble Breaker (27 prims...) qui exploitera une nouvelle fonction de LSL, llDetectedTouchFace, qui permet d'obtenir le numéro de la face sur un prim qui vient d'être touché... Malheureusement, cette dernière n'est pas encore implémentée dans les moteurs de scripts d'OpenSim, ce qui ne saurait tarder.

Les évolutions d'opensim.ini

Pas mal de temps sans remplir Hello, Avatar, pour plusieurs raisons : nouveau travail, nouvelle organisation, quelques projets d'ordre privé donc prioritaires... A présent je commence juste à toucher terre et on va pouvoir y retourner !

Ca faisait un bout que je n'avais pas repris mon opensim.ini pour y intégrer les évolutions et les changements. Parce que l'air de rien, si ce fichier de paramètres n'a pas bougé depuis un bout de temps, le petit fichier opensim.ini.example qui l'accompagne bouge drôlement, lui...

De ce fait, un beau jour, mon moteur de scripting (XEngine) s'est mis à rechigner, parce qu'un nouveau paramètre a été ajouté par melanie pour son bon fonctionnement.
Melanie l'a donc ajouté dans opensim.ini.example, mais comme il n'est pas venu tout seul dans opensim.ini, ça a fait "kerboom" comme dirait l'autre (que je salue au passage).

Pour refaire un opensim.ini à jour, il y'a deux manière :

  • Soit on copie opensim.ini.example, on le renomme en opensim.ini et on remet un par un tous les paramètres spécifiques à son installation.
    • Ca c'est la solution dernière chance en cas de gros gros changements. C'est parfois assez pénible
  • Soit on ouvre opensim.ini d'un côté, opensim.ini.example de l'autre, et puis on fait les modifications.
    • Quand il y'a un tout petit paramètre, ça va encore. Mais quand une floppée de fonctionalités s'ajoutent, ça devient une catastrophe et on est tenté d'en venir à la première solution.

Heureusement, pour ceux qui utilisent TortoiseSVN, il y'a un outil appelé TortoiseMerge que j'ai découvert il y'a pas deux jours, permettant d'ouvrir deux fichiers côte à côte, de prendre l'un ou l'autre côté, et d'éditer le résultat final.

tortue.png

Dans tous les cas, j'ouvre mon fichier opensim.ini, le fichier opensim.example.ini avec TortoiseMerge. Les différences et les ajouts apparaissement alors de façon claire et lisible, et il ne me reste plus qu'à les intégrer en quelque clics.

OpenSimForge : toutes les annexes d'OpenSimulator

codesource.png

Un nouveau référentiel de code source a vu le jour pour OpenSimulator : OpenSimForge.

Le but de ce référentiel (repository) est de répertorier l'ensemble des annexes à OpenSimulator, histoire de ne pas polluer le code actuel.

Il est prévu d'y ranger :

  • Les implémentations de serveur de grille UGAI alternatifs
    On devrait y trouver d'ici peu l'implémentations en PERL ainsi que celle qui existe actuellement dans le Trunk, en *love* Python *love*. On trouve déja, DeepServers qui est une implémentation en C# pour ASP.NET. Voilà qui devrait interresser G2 Proto...
  • Les Plugins pour OpenSim
    Un plugin, c'est un module (un peu comme les modules région) ajoutant des possibilités supplémentaires à OpenSim, comme la sauvegarde des terrains sur un serveur SVN, l'archivage complet d'une région (en cours...), ou des moyens différents de persister les données (oracle, myssql, postgres, sqlite, mssql... etc...). Bien sûr, on retrouve comme Plugin des moteurs de physique de tout poil.
  • Les applications dérivées d'OpenSim
    Je ne vois pas bien si Adam Frisby veut parler des Forks existants pour OpenSim, comme RealXtend de Jani Pirkola ou LiteSim de Gareth Nelson, ou bien alors des applications externes pour OpenSim. Dans ce cas, je pourrais peut être y ranger l'InterCom et le WhiteBoard. On pourrait y trouver le lanceur que Vinc Sonic est en train de fabriquer pour la Francogrid. Et pourquoi pas une bibliothèque de scripts ?
  • Les branches OpenSim non-officielles
    Quelques variantes existent, et provoquent ce qu'on appelle "une branche" dans le code source. Le module d'interopérabilité en cours de développement est une branche spéciale qui servira aux tests d'intéropérabilité qui débuteront fin du mois de Juillet.

Voilà donc une initiative d'Adam Frisby à saluer, qui nous permettra de retrouver nos morceaux de codes bien rangés !

L'InterCom en PHP, et Google AppEngine

Grâce à la gentillesse et aux efforts de Sbach, nous avons à présent la partie serveur de l'InterCom en PHP ! ^^ Merci à toi, Sbach !

La partie client en LSL ce dernier a déja été réutilisée et modifiée par Sun Payne, pour fabriquer un InterChatTW qui permet de communiquer avec une région depuis une page Web !

Quand à la suite de l'InterCom, je suis en train de porter la partie Serveur en Python en utilisant Google AppEngine. On fait pas mal de foin autour de Lively, mais ce Google AppEngine est une petite révolution silencieuse dont je n'avais encore jamais entendu parler, jusqu'à ce que Keru m'inonde de ses lumières, béni soit-il.

Google AppEngine, en deux mots, c'est pour héberger des applications en Python en bénéficiant de la puissance de l'infrastructure de Google. On peut le faire gratuitement moyennant quelques limitations dont on s'affranchit avec la version payante.

Perso, je me réjouis de voir comment Google apporte sa pierre à l'édifice Internet autrement qu'en le transformant en espace publicitaire géant.

Et d'ailleurs, je ne me peux pas m'empêcher de faire le rapprochement entre tous ces scripts en Python qui moulinent sur la grille géante de Google, et ces milliards de scripts en LSL qui animent les grilles de notre Metaverse préféré. Et ça me laisse entrevoir avec enthousiasme un bout de ce qu'il y'aura derrière le rideau du Web de demain.

Retrouvez ici l'intégralité des codes sources

- page 1 de 7