Luego de varios de ausencia en este blog (y en Second Life en general) por acumulación de trabajo en RL (Blogs, páginas webs, servidores y otras yerbas que decidieron tener problemas o ser atacados, todos juntos a la vez), intento retomar las noticias y novedades sobre el mundo virtual. Por lo tanto, aquí va el resumen de lo mas interesante (a mi juicio) que debe destacarse de estos últimos días:

⋅

Lista de Grupos en Second Life:

Desde hace un tiempo los nuestros visores no pueden cargar la lista completa de miembros de los grupos con mayor cantidad de usuarios inscriptos. Seguramente casi nadie se ha dado cuenta de ello, pero todo indica que el constante envío de esa información a cada usuario en línea provoca una recarga y saturación en la conexión entre los servidores y cada visor. Por este motivo, en los próximos días, Linden Lab, como solución temporaria y hasta tanto puedan aplicar una solución definitiva, implementará la solución de capar la cantidad de usuarios de la listas a enviar al visor cliente en aquellos grupos numerosos, lease, grupos de aproximadamente 5000 o más miembros.

Se ha podido determinar que para poder cargar realmente la lista completa de estos grupos numerosos, el proceso puede demandar (estando en un sim vacío y dejando el avatar quieto) entre 15 y 20 minutos.

Por lo tanto, mientras los desarrolladores de Linden Lab trabajan en la solución final, se aplicará la transitoria ya indicada. Se supone que esta medida no afectará a aquellos usuarios que tengan en los grupos el rol de administrador (con permisos para expulsar y/o prohibir usuarios y administrar el grupo) no se verán afectados por esta limitación.

Paralelamente, bien al estilo Linden Lab, se ha pedido que no se brinde mayor información sobre los cambios a aplicar hasta que se hayan aplicado los mismos el próximo martes 9 de junio durante la actualización de servidores (este pedido fue realizado a Inara Pey presente en la reunión).

⋅

Próxima versión del Visor Firestorm y el VMM (Viewer Managed Marketplace – Administración del Mercado en línea desde el visor):

El equipo de desarrollo del visor Firestorm, tal como lo anticipara cuando lanzó como beta su última versión (4.7.1) intenta decidir cuando comenzará el período de 30 días de congelamiento (no agregar más características) de la futura versión y se supone que esto sucederá en las próximas 2 semanas, en la próxima reunión de desarrolladores opensource. La razón de esta indecisión radica en que el equipo Firestorm no quiere lanzar la versión final sin el añadido de la característica VMM (modificación en el manejo del mercado en línea que está desarrollando y por implementar en las próxmas semanas Linden Lab) ya que es de suma importancia y dejaría al visor sin una herramienta importante por mucho tiempo, en el peor de los casos o, por un par de semanas obligando al equipo a trabajar full time para agregarlo y lanzar una nueva versión, en el mejor de los casos.

Por lo tanto, en la supocisión de que Oz Linden, dentro de estas dos semanas, anuncie el lanzamiento como estable de esta funcionalidad, el equipo Firestorm, estará en condiciones de tomar el código correspondiente para incorporarlo a su visor, hacer los cambios de UI necesarios, eventualmente personalizarlo, probarlo y tenerlo listo para su lanzamiento junto a la próxima versión estable (¿4.7.2 o 4.7.3 tal vez?). Por lo tanto, lo más probable es que este lanzamiento no sea antes de mediados o fines de Julio próximo.

⋅

Bug en las Tarjetas de Llamadas:

Y siguen apareciendo fallos y errores que provocan mal funcionamiento en nuestros visores y, debido a la decrepitud (por decirlo de alguna manera) del diseño de Second Life, tanto a nivel servidor como a nivel visor, precisamente, si bien los fallos son provocados por errores de código, la fuente de los mismos procede, en realidad, de errores de diseño (más bien, de falta de modularidad o visión de futuro a la hora de haber diseñado la plataforma).

Pues bien, se ha podido comprobar que el sistema de tarjetas de llamada puede provocar problemas de carga y lag en el visor si el usuario tiene en su inventario una cantidad alta (o exagerada) de ellas. Sabemos que, por defecto, cuando agregamos a otro usuario en nuestra lista de contactos, automáticamente se agrega en nuestro inventario una tarjeta de llamada de ese usuario. Ahora, si borramos a ese usuario de nuestros contactos, la tarjeta de llamada, salvo que la borremos manualmente, quedará durmiendo el sueño de los justos en nuestro inventario. Además, si, pasado el enojo que hizo que se borrar a ese usuario, volvemos a añadirlo a nuestra lista, el sistema volverá a poner una copia de la tarjeta de llamada en nuestro inventario provocando duplicidad de la misma (como anécdota ruisieña, alguna vez alguien me comentó que podía determinar cuantas veces se peleo y reconcilió con un amigo simplemente contando la cantidad de tarjetas de llamada del mismo).

Pues bien, por ahora, se ha podido determinar que el sistema monitorea constantemente el estado en línea de todos los usuarios de los que tengamos una tarjeta de llamada, por lo cual, para nosotros no es lo mismo tener 10 tarjeta de llamada que 100 o 1000. Y aquí, uno de los fallos es que, a diferencia de nuestra lista de contactos, el sistema monitorea a TODOS los usuarios de los que tengamos tarjeta de llamada en nuestro inventario, estén o no en nuestra lista de contactos. Como se podrán imaginar, esto provoca una sobrecarga en la trasferencia de datos constante entre nuestro visor y los servidores de Linden Lab, generándonos el consabido lag (si a esto le sumamos el problema de la lista de contactos ya comentado y un día con problemas con nuestro ISP, ya tenemos el combo perfecto para tirarnos de los pelos por culpa de Second Life).

Linden Lab se encuentra trabajando en la solución de este problema, la cual consistirá, en una primera etapa en limitar el control del estado en línea a aquellos usuarios de los que tengamos tarjeta de llamada y se encuentren en nuestra lista de contactos. Para el caso que no estén en nuestra lista de contactos, el sistema descartará de plano la revisión del estado en línea (en mi opinión personal, como siempre debió haber sido).

⋅

Chrome Embedded Framework:

Otro aspecto que pone los pelos de punta a mas de un usuario (y Linden Lab y los desarrolladores de visores de terceros) es el multimedia dentro del visor. Actualmente, los visores de SL (y opensim) trabajan con un navegador embebido basado en Mozilla Firefox, por lo cual, al igual que el navegador, para poder reproducir videos principalmente requiere del uso del plugin de Flash Player (o quicktime en algunos casos). El gran problema lo está dando la plataforma Flash por diversos motivos, incluso, desde hace ya bastante tiempo, a partir de la versión 11.18 para OSX este plugin no es compatible con Second Life para el Sistema Operativo de MAC y no hay esperanzas de que Adobe corrija esta situación. Al margen de esto, todo usuario que no instale firefox en su pc y su correspondiente plugin de Flash (windows o linux) también tendrá problemas para reproducir videos, especialmente los de Youtube.

Con este problema en mente, desde hace tiempo Linden Lab, con cuentagotas y a paso lento, venía trabajando en un cambio radical que implica dejar de lado el motor Gecko de Firefox para adoptar el motor de Chrome y su soporte de html5 para multimedia (Chrome Embedded Framework). Ahora, debido a que los problemas ya son constantes y graves, pareciera ser que la empresa ha decidido apurar el desarrollo de esta nueva plataforma y su aplicación al visor lo más pronto posible.

Esto es una buena noticia para los usuarios de Window y OSX, pero, los usuarios de Linux deberemos esperar un poco más, ya que Linden Lab no trabajará en esta solución para aplicarla a la plataforma Linux, por el contrario, ha lanzado un pedido a la comunidad opensource para que, quien lo desee, haga el trabajo por ellos (con suerte, le darán las gracias).

⋅

Esto último viene emparentado con otro tema: la nueva plataforma Sansar (o SL2 o como lo quieran llamar). Debido a que Linden Lab, por un lado, ya indicó que no va a trabajar en incorporar nuevas (complicadas) características en su visor para linux, pidiéndole a los desarrolladores opensource que lo hagan por la empresa, y, por otro lado, el hecho concreto que ya ha declarado que la nueva plataforma Sansar será de código cerrado, muchos desarrolladores, especialmente los de plataforma linux, han comenzado a sentir una fuerte falta de motivación para seguir colaborando y desarrollando código para los distintos visores de Second Life.

Esto es entendible, ya que el saber que la empresa descartará de plano todo aporte externo de código libre (dicho sea de paso, con argumentos tirados de los pelos, como el de decir que si es código libre no permite a la empresa explotarlo como quisieran ¿?) para, en cambio, apoyarse exclusivamente en desarrollos de código cerrado de terceras empresas, le quita las ganas de colaborar a cualquiera.

⋅

SaludOS/2