Archivo de la categoría: Software

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

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

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

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

Second Life: problemas de pantalla con Windows 10 Actualización Mayo 2019

A raíz de una consulta técnica/comentario de mi fanblog sobre un problema a partir de actualizar su notebook a la versión 1903 de windows 10 (conocida como Actualización Mayo 2019), recurrí a mi notebook banquillo de pruebas para verificar si era un caso aislado o general.

Luego de tener que forzar dicha actualización, al tener ya actualizado el windows de esa PC, procedo a ejecutar el visor oficial de Second Life y, llegado a ese punto, iba todo bien, el problema se da al cerrar sesión en el mismo provocando la distorsión del gamma y brillos de la pantalla, haciendo que la misma sea ilegible, como se puede ver en la siguiente imagen: Leer Mas...

Second Life: Acerca de la desconexión durante el mantenimiento de la red

Esta semana Linden Lab había programado un mantenimiento integral en la red de Second Life, esto, según lo explicado por April Linden en el blog oficial de SL, implicaba la actualización de routers para mejorar la conectividad de la plataforma y prepararla para la futura migración total a la nube.

Es bien sabido por todos que el primer día de este mantenimiento fue un tanto caótico y, a poco de comenzado el mismo, el grid desconectó a los usuarios en línea y, posteriormente, LL procedió a bloquear los inicios de sesión para trabajar en el problema no previsto. Todo esto implicó no poder acceder a Second Life durante unas horas (unas 4 hs, poco mas, poco menos). Algo que no sucedía desde la época de los famosos mantenimientos de los miércoles. Leer Mas...

No la vemos ni cuadrada

Antes de empezar con el artículo debo decir que iba a escribirlo esta mañana (mi mañana) pero, al mejor estilo Linden Lab, al despertarme me encontré con mi servidor con algunos problemas. Investigando, descubro que había un defecto en uno de los discos del servidor. Bien, empiezo a preparar otro, instalarle sistema operativo servicios (mysql, apache, KVM para virtualización, etc. etc.) y preparo otro disco adicional para backups. Arreglo con el datacenter para ir a hacer los cambios. Se me complica la preparación de los discos, quién sabe porqué, pero lo hago, voy al datacenter, se hace el cambio, servidor no arranca, o se cuelga o no se conecta. Leer Mas...

Second Life: Problema con los teleportes, algunos consejos

Al día de hoy parece ser que el problema se agudiza y afecta a muchos más usuarios que cuando escribí los anteriores artículos.

Se ha podido notar que el problema afecta temporalmente a grupos de usuarios en forma aleatoria. Es decir, puede ser que durante uno, dos o tres días, uno sea afectado y luego, por un tiempo no tenga mas problemas. O tener momentos de estabilidad y momentos de desconexiones constantes.

Además, noto que también está pasando algo nuevo, me ha pasado a mi y ya algunos usuarios también me comentaron les ha pasado lo mismo. Son desconectados o su visor crashea en momentos en que están ausentes o simplemente leyendo alguna nota o mirando algún objeto. Pero esto puede ser casualidad o efecto colateral del problema global de los teleportes (presumiblemente alguna falla en el manejo del protocolo de comunicaciones). Leer Mas...

Second Life: Problemas con Teleportes, Anexos y Entorno

Desde hace un tiempo a esta parte muchos usuarios, tarde o temprano, comienzan a tener problemas de desconexiones al realizar un teleport a otra región, perder objetos anexados durante un teleporte o, mas recientemente, visualizar mal el entorno climático en algunas regiones.

Yendo por orden de aparición:

Anexos perdidos en un teleport

Este es el más antiguo de los problemas, lleva mas de un año ocurriendo y tiene a mal traer a muchos usuarios, especialmente a quienes utilizan productos que son no copiables ya que éstos se pierden indefectiblemente y hay que recurrir a sus creadores para recuperarlos o, en el peor de los casos, comprarlos de nuevo. Leer Mas...