Todas las entradas de: Damián Zhaoying

Residente de Second Life desde 2006 y de Opensim desde 2008. Miembro del equipo de soporte del visor Singularity y traductor al castellano del mismo.

Con las cartas sobre la mesa

En esta última semana, Hamlet Au (Wagner James en la vida real, y ex empleado de Linden Lab), en su blog New World Notes publicó un par de artículos hablando del visor oficial y el visor Firestorm, y lo que él llama «probablemente la más extraña relación simbiótica en Sillicon Valley«.

Dentro de este  contexto, se muestra una realidad, que es que el visor Firestorm, desde hace tiempo a esta parte, se lleva la parte del león en cuanto a base de usuarios que utilizan un cliente de Second Life para conectarse a dicho entorno virtual. Se calcula, según datos que Jessica Lyon dice haber recibido de Linden Lab, que hay alrededor de un 90% de usuarios de Second Life utilizando dicho visor (esto es real, aunque hay muchas consideraciones a tener en cuenta a la hora de evaluar estos datos). Leer Mas...

Second Life: Novedades y avances de proyectos

Es hora de ponernos al día con la información de los distintos proyectos que lleva adelante Linden Lab en su plataforma virtual Second Life. Si bien muchos de estos proyectos pueden ser transparentes al usuario y no deberíamos siquiera darnos cuenta de su implementación, son importantes para mejorar el funcionamiento de la plataforma y, otros proyectos si nos puede interesar (y mucho) en que fase se encuentran y cuando se preeve podrán ser aplicados en Second Life.

Apellidos:

Quizás este proyecto sea uno de los mas esperados por la comunidad de usuarios. A la fecha poco ha cambiado sobre lo que se sabe sobre su implementación y se puede consultar en Este Artículo. Aunque es necesario mencionar los puntos principales de esta característica que ya está siendo denominada «Cambio de Nombre», ya que no solo apunta al regreso de los apellidos sino que va mas lejos y, como se puede ver en el artículo referido, apunta a permitir que los usuarios puedan cambiar el nombre de su cuenta. Leer Mas...

Second Life: Problema de comunicación entre scripts

La semana pasada el grid se vió afectado por un problema en la ejecución de scripts, específicamente cuando un objeto rezea otro y se establece una comunicación entre ambos (parent-child). Este problema, surgido luego de la actualización habitual de martes y miércoles, debió ser revertido por Linden Lab, de manera apurada, el pasado fin de semana (viernes y sábado) tuvo que reiniciar el grid para revertir los cambios y aplicar correcciones para solucionar el problema suscitado.

Ayer, en su blog oficial, Linden Lab emitió un comunicado explicando dicho problema, el cual se transcribe (traducido) a continuación:

Comunicaciones entre scripts  principal/secundario

Como parte de nuestros esfuerzos continuos para mejorar el rendimiento de los sctripts, recientemente realizamos cambios en cómo se programan los mismos y se entregan los eventos. Desafortunadamente, encontramos que esos cambios causaron la ruptura de algunos scripts ampliamente utilizados, lo que llevó a la reversión del estado del grid el sábado pasado. (Aparentemente tuvimos mala suerte en que hubiera poca cantidad de esos scripts en las regiones Release Candidate la semana anterior). Ahora hemos realizado mejoras adicionales que deberían evitar la mayoría de esos problemas, pero incluso con esas soluciones habrá algunos cambios en el tiempo y el orden de cómo se ejecutan los scripts. En general, esos cambios mejorarán el rendimiento, pero hay algunas mejores prácticas de secuencias de comandos que el usuario debería utilizar. Esto le ayudará a evitar depender de un orden o sincronización particular de entrega de eventos y ejecución de script.

Una causa común de problemas es la comunicación entre objetos inmediatamente después de que uno crea el otro. Cuando un objeto rezea a otro objeto en el mundo usando llRezObject o llRezAtRoot, los dos objetos con frecuencia necesitan comunicarse, ya sea a través de llamadas a llRegionSayTo o llGiveInventory. El objeto principal recibe un evento object_rez() cuando se ha creado el nuevo objeto, pero nunca es seguro asumir que los scripts en el nuevo objeto han tenido la oportunidad de ejecutarse cuando se entrega el evento object_rez. Esto significa que el nuevo objeto puede no haber inicializado su evento listen() o haber llamado llAllowInventoryDrop, por lo que cualquier intento de enviarle mensajes o inventario podría fallar. El objeto principal no debe comenzar a enviar mensajes ni a hacer un inventario del evento object_rez(), ni siquiera debe esperar un tiempo después de ese evento. En cambio, el objeto padre (rezzer) y el objeto hijo (rezzee) deben realizar una comunicación previa para confirmar que ambos lados están listos para cualquier transferencia.

La secuencia para este proceso es:

El objeto padre registra un evento de escucha usando llListen en un canal.
El objeto padre llama a llRezObject y pasa ese número de canal al nuevo objeto en start_param.
El objeto hijo crea un evento de escucha usando llListen en su controlador on_rez en el canal pasado como start_param.
El objeto hijo realiza cualquier otra configuración requerida para estar listo para cualquier comunicación que necesite con el objeto padre.
El objeto hijo envía un mensaje «listo» usando llRegionSayTo() en el canal asignado al objeto padre.
El objeto padre transfiere inventario o envía comandos de configuración a través de llRegionSayTo al objeto niño.
El objeto padre envía un mensaje de «hecho» al objeto hijo y ahora puede cerrar el canal de comunicaciones.
El objeto hijo recibe el mensaje «hecho» y ahora puede desmontar cualquier configuración que haya hecho para habilitar la configuración (como llamar a llAllowInventoryDrop( FALSE ) ).

Puedes ver el código de ejemplo de comunicación entre objetos padre e hijo a continuación.

Vale la pena señalar que este patrón de comunicación siempre ha sido la mejor manera de escribir tus scripts. Incluso sin los cambios en el planificador, el orden de cuándo se ejecutan los scripts en el nuevo objeto y cuándo se entregó el evento object_rez al rezzer no fue determinista. Parece cierto que hacer que el planificador sea más rápido ha hecho que esta condición de secuencia  sea algo menos predecible, pero hacer que todos los scripts se ejecuten con menos sobrecarga de programación vale la pena que el pedido sea un poco menos predecible, especialmente porque no estaba asegurado antes de todos modos. ¡Esperamos que estos nuevos cambios ayuden al mundo de todos a funcionar un poco más tranquilo! Para compartir tus pensamientos sobre esto, utiliza esta publicación del foro (En inglés).

Rezzer.lsl //////////////////////// // Rezzer script. // Rez' an object from inventory, establishes a communication channel and // gives the rezzed object inventory. // (Rezea un objeto desde su inventario (pestaña Contenido), establece un canal de comunicaciones y // entrega del inventario del objeto rezeado.) integer COM_CHANNEL=-17974594; // chat channel used to coordinate between rezzer and rezzee string REZZEE_NAME="Rezzee"; string CMD_REZZEE_READY = "REZZEE_READY"; string CMD_REZZER_DONE = "REZZER_DONE"; key rezzee_key; default { //... touch_start(integer count) { state configure_child; } //... } // rez and configure a child state configure_child { state_entry() { // where to rez vector position = llGetPos() + <0.0, 0.0, 1.0>; // establish rezzer's listen on the command channel llListen( COM_CHANNEL, "", "", "" ); // rez the object from inventory. Note that we are passing the // communication channel as the rez parameter. llRezObject(REZZEE_NAME, position, ZERO_VECTOR, ZERO_ROTATION, COM_CHANNEL); } object_rez(key id) { // the object has been rezzed in world. It may not have successfully // established its communication yet or done anything that it needs to // in order to be ready for config. Don't do anything till we get the signal rezzee_key = id; } listen(integer channel, string name, key id, string message) { if (message == CMD_REZZEE_READY) { // the rezzee has told us that they are ready to be configured. // we can sanity check id == rezzee_id, but in this trivial case that is // not necessary. integer count = llGetInventoryNumber(INVENTORY_NOTECARD); // give all note cards in our inventory to the rezzee (we could // do scripts, objects, or animations here too) while(count) { string name = llGetInventoryName(INVENTORY_NOTECARD, --count); llGiveInventory(id, name); } // And now tell the rezzee that we have finished giving it everything. llRegionSayTo(id, COM_CHANNEL, CMD_REZZER_DONE); // And we can leave configure child mode. state default; } } } Leer Mas...

Second Life Blogger Network

El pasado 26 de Setiembre Linden Lab anunció en su blog oficial el lanzamiento de la Red de bloggers Second Life. Este proyecto busca integrar a los bloggers particulares a la estructura de difusión de Second Life extendiendo, de esta manera, el alcance de la publicidad sobre esta plataforma.

Quienes deseen participar en esta red deben completar un formulario y respetar las normas y el tipo de contenidos establecidos por la empresa para ser aceptados en el proyecto. A su vez, ser participe de esta red no implica asociación ni relación contractual alguna con la empresa y el blogger acepta que la empresa pueda utilizar el contenido de su blog para difusión y publicidad. Tampoco implica que el contenido de su blog será necesariamente utilizado por Linden Lab, ya que la empresa se dedicará a revisar diariamente el contenido de cada blog inscripto y seleccionará lo que considere apto para su difusión y publicidad. Leer Mas...

Visor Firestorm con soporte BoM

Hace minutos el equipo del visor Firestorm informó, en su blog, el lanzamiento de la versión 6.3.2.58052 con soporte de Bake on Mesh. Esta nueva versión, según lo expresado por el equipo de desarrollo de dicho visor, se considera como actualización importante.

Si bien el motivo principal de esta actualización es la incorporación de Bake on Mesh, no es la única característica nueva en este visor, por lo tanto, se detallan a continuación las mejoras mas importantes en esta nueva versión:

  • Bake On Mesh (que es BoM)
  • Love Me Render. Este proyecto de Linden Lab es una mejora en el sistema de pipelines (tuberías) de renderizado del avatar.
  • Umeshu. Un conjunto de correcciones de errores, ajustes y mejoras,
  • Posibilidad de poder editar notas con un editor externo.
  • Capacidad para duplicar roles de grupo.
  • Incremento en la duración de los clips de sonido de 10s a 30s. Se agrega soporte al visor para poder subir y ejecutar clips de sonidos de hasta 30 segundos de duración. Actualmente no es posible subir sonidos de mas de 10 segundos, pero proximamente, esta característica será incorporada del lado del servidor por Linden Lab.
  • Se ha removido la posibilidad de subir fotos a Facebook. Ya que esta opción, por cambios en las políticas de Facebook, dejó de funcionar hace tiempo ya y no puede ser corregida, se ha suprimido la misma.

Esta versión es exclusiva para usar en Second Life, ya que, si bien se había anunciado que se unificaban nuevamente las versiones de SL y OS, en esta versión no es posible ya que el código de BoM, al iniciar sesión con este visor, provoca un crash en la región de inicio de sesión en Opensim. Por lo tanto, los usuarios de esta plataforma deberán continuar utilizando la versión 6.0.2. Leer Mas...

Second Life: Bake on Mesh

Si bien esta noticia ya tiene su tiempo, hace ya mas de un mes, el pasado 26 de agosto, Linden Lab culminó el proceso de implementación del proyecto Bake on Mesh en todo el grid al promover a la condición de estable su visor (Versión 6.3.1), con el cual los usuarios ya pueden utilizar esta nueva característica en el mundo virtual.

Desde su implementación a la fecha se hablado y explicado bastante sobre este tema, sin embargo aun muchos usuarios siguen preguntando de que se trata esta característica, por lo cual intentaré resumir aquí lo básico y referirlos a enlaces con explicaciones mas detalladas. Leer Mas...

Visor Firestorm: Opensim y Antivirus

Un par de noticias acerca del visor Firestorm:

1: Antivirus:

Recientemente se ha podido comprobar que, luego de ser actualizados, los antivirus Avast y AVG (ambos propiedad de la misma compañía) detectan los ejecutables del visor Firestorm como potenciales virus y los borran (falsos positivos). Por lo cual se sugiere a los usuarios de este visor que procedan a desactivar el antivirus y luego, descargar el instalador de la página oficial de Firestorm, instalarlo, agregar la carpeta donde se ha instalado a la lista de excepciones del antivirus y, recién en ese momento, volver a activar el antivirus. Leer Mas...

De regreso

Como dijera en mi artículo anterior, problemas de salud me han tenido alejado de Second Life, la virtualidad y este blog. Además, a esto se han sumado problemas con el datacenter donde tenía alojado mi servidor, por lo cual apenas volví a mi casa del hospital donde estuve internado por un par de semanas al complicarse mi cuadro respiratorio, me he visto obligado a buscar otro proveedor para alojar mis servidores.

Y aqui estoy, de vuelta en mi casa, por un lado, y estrenando servicio nuevo en otro proveedor (aún estoy moviendo todos los dominios que están alojados en mi servidor). Leer Mas...

Second Life: Regreso de los Apellidos (Actualización)

Hace poco mas de un año Linden Lab nos informaba que tenía en sus planes el regreso del uso de los Apellidos en las cuentas de Second Life. Sin embargo, luego de transcurrido este año, no se ha producido aún novedad alguna al respecto.

No obstante, en el transcurso de este nuevo cumpleaños de SL (SL16B), en el evento denominado «Meet the Lindens» (Conociendo a los Linden), Oz y April Linden realizaron algunos comentarios y precisiones sobre este tema y respondieron preguntas de los usuarios. Leer Mas...

OSGid: cumpleaños 12 OSG12B

Entre los días 22 al 25 de Julio del corriente año, OSGrid, el grid oficial del proyecto Opensim) festeja sus 12 años de vida y lo hará como siempre, con eventos y creaciones de sus usuarios.

Quien quiera ser expositor en este evento deberá contactar con los administradores de OSGrid para obtener su parcela y las normas para participar son las siguientes:

1. No se permiten insultos, material para adultos, desnudos u ofensivos, ya sea en temática o texturas. Esto incluye cualquier objeto, texturas, avatares. Leer Mas...