En estos últimos días me han llegado reportes, quejas, consultas y comentarios sobre el famoso bridge del visor Firestorm. Debido a esto y a problemas que han surgido, en forma directa o indirecta, por su existencia, es que decidí escribir esta nota, incluyendo algunas pruebas e investigaciones que he realizado para documentarla.

Como primer aspecto y consecuencia de consejos que se dan en los grupos de ayuda, es importante dejar claro que es lo que hace el bridge y para que sirve y si es válido o no atribuirle todos los méritos o culpas cuando algo va bien o muy mal.

Entonces, para comenzar, podemos decir que el bridge está diseñado para asistir al visor en determinadas funciones que el mismo no puede realizar o bien, las realiza en forma incompleta, estas funciones son:

Según el wiki del visor Firestorm: (traducción muy google, pero se entiende)

• Teleporte con doble click
• Asistente de Vuelo
• Contador de Scripts
• Radar

Ahora bien, si revisamos el código fuente del bridge (Versión 2.4, Visor Firestorm V4.4.2), también podremos ver otras funciones:

• Ver el tag de otros visores (imagino que esta función es para OpenSim, ya que en SL está prohibido)
• Soporte de AO
• Soporte de Opencollar

Como podemos ver, estas 7 funciones son las que están incluídas en el bridge actual del visor Firestorm. Ahora, ¿a que viene todo esto?

Desde la existencia del viejo visor Emerald y su bridge, mucho se ha discutido sobre el mismo, si es útil, si impacta en la perfomance del visor, si es molesto, incluso, por sus características de anexión y permanencia aunque se cambie de visor, si no atenta contra el TOS de visores de terceros,etc.

No es intención de este artículo discutir u opinar sobre si el uso del bridge cumple o no con el TOS de visores de terceros, sino intentar dilucidar si el mismo afecta o no al funcionamiento de otros visores y, de por si, el mismo visor Firestorm.

Para comenzar, en el mismo wiki del visor Firestorm, se detallan algunos problemas (creo que no todos, ya que el artículo del wiki es antiguo) y, básicamente, se reconoce que el bridge puede quedar mal anexado, viéndose que nuestro avatar lleva vestida una roca o que el pelo se muestra anexado a cualquier parte del cuerpo menos a la cabeza o que el bridge se crea múltiples veces sin razón. Esto indica de por si una molestia y, lógicamente, que, en cierta medida, el bridge interfiere con el normal funcionamiento del visor (en este caso con el visor nativo del bridge).

Respecto de otros visores, y aquí me voy a concentrar en el visor Singularity, ya que es el que utilizo, en estas últimas semana he recibido muchas consultas y he podido ver, tanto en el grupo oficial (en inglés) del visor, como en Visores en Castellano, quejas referidas a la lentitud «repentina» en la carga del visor Singularity. Nada había cambiado para el usuario, es decir, misma versión del visor, mismas configuraciones, pero, de un día para otro, era lento. O, en otra situación, usuarios de Firestorm que, por las características de sus PCs buscaban un visor mas liviano, terminaban viendo que Singularity o Cool VL eran mas lentos que el propio Firestorm (o, como decían, mas pesados). En la mayoría de los casos, investigando, he podido notar que este aluvión de quejas coincidió con la aparición de la versión 4.4.2 de Firestorm.

A raíz de un caso abierto en el issue tracker de Singularity, me he enterado que desde la aparición de la versión 4.4.2 de Firestorm, la funcionalidad de Singularity de quitar el bridge ya no funciona como lo hacía con versiones anteriores de Firestorm. ¿Qué significa esto?

Veamos, si somos usuarios de ambos visores (Firestorm y Singularity), al usar Firestorm, por defecto y sin nuestro consentimiento/conocimiento, el visor nos vestirá el bridge, el cual se anexa en un punto ficticio, inexistente, sólo reconocido por el propio Firestorm. Cuando, cerramos Firestorm y usamos Singularity, éste visor tiene la funcionalidad de detectar si llevamos vestido dicho bridge y quitarlo de nuestro vestuario. Pero, como dije, a partir de la versión 4.4.2 de Firestorm, esta funcionalidad de Singularity ya no, valga la redundancia, funciona más. Lo que no sabemos es porqué. ¿Qué ha cambiado en el código para que suceda esto? ¿es algo casual o intencional?, realmente, no lo sabemos.

Ahora, el punto es que, iniciada la sesión con Singularity, nos puede dar un mensaje de error indicando que el visor no puede vestirnos un objeto del vestuario porque está utilizando un punto de anexado desconocido, sin embargo, el bridge insiste en vestirse y lo hace (al menos en mi caso y en las pruebas que realicé) en el pecho.

Esto provoca varios inconvenientes, primero, el lógico, si tenemos algo anexado al pecho, el bridge lo quitará para anexarse el mismo. Luego, anexado a nuestro cuerpo, el bridge, a pesar que los desarrolladores de Firestorm insisten en que no interfiere ni trabaja si detecta a otros visores, sigue trabajando, estableciendo comunicación con los servidores de Linden Lab y provocando efectos no deseados en el funcionamiento de nuestro visor. Por ejemplo, en las pruebas que he realizado: disminución en la velocidad de carga del inventario, retraso en la carga de nuestro avatar, incluso, no cargarlo y hacer que nos veamos como nube, luego de realizar varios Teleports por el grid (no mas de 2 o 3) he podido observar que:

• El bridge envía mensajes al servidor entrante del nuevo sim al que llegamos.
• Desaparece la opción de consultar los scripts de la parcela y nuestro avatar en las propiedades de Parcela.

Esto solo ocurre cuando llevamos vestido (contra nuestro consentimiento) el bridge de Firestorm. Por lo cual tengo que concluir que, intencionalmente o no, dicho bridge si interfiere con el normal funcionamiento de otros visores, en este caso específico, con Singularity.

En las pruebas que hice, las realicé con esta configuración:

• Procesador i5 (Intel 4 núcleos)
• Memoria RAM: 12 GB
• Video: Nvidia GTX210, 1GB de RAM
• Sistema Operativo: Linux Ubuntu 64 Bits (Kubuntu = Ubuntu con KDE)
• Firestorm 4.4.2, 32 bits.
• Singularity Alpha (1.8.0 – últimas 3 Alphas a la fecha), 64bits.

A pesar de tener una configuración respetable que me permite abrir 3 sesiones simultáneas en Second Life y/o Opensim, sin perder rendimiento en ninguna de ellas, al tener el bridge de Firestorm cuando uso Singularity, se nota una baja notoria en el rendimiento de mi visor Singularity, baja que desaparece cuando me lo quito e inicio sesión sin dicho aditamento.

Entonces, como sugerencia para los usuarios de ambos visores o para quienes quieran probar migrar desde Firestorm a otro visor, lo que deben hacer es lo siguiente:

• Iniciar sesión con Firestorm
• Ir a Preferencias -> Firestorm -> General y desmarcar «Activar el LSL-Client Bridge»
• Abrir nuestro Inventario, buscar el bridge vestido y quitarnoslo.
• Cerrar sesión con Firestorm
• Abrir sesión con otro visor
• Abrir el inventario y verificar que no tenemos vestido el bridge.

Siguiendo estos pasos, nos aseguramos que el bridge de Firestorm no nos causará problemas en otros visores.

Me quedan dos temas mas para comentar al respecto:

1) ¿Interfiere o no el bridge con el normal funcionamiento del visor?

En mi opinión sí interfiere. Esto lo he podido comprobar ya en la época del visor Emerald y confirmar con el visor Phoenix y comentarlo con el resto del equipo en su momento (para quienes no lo sepan, fui miembro y soporte oficial de los equipos Emerald y Phoenix). Si bien el equipo sigue insistiendo en que no interfiere y que, incluso, con el bridge, las cosas se hacen más rápido y con menos consumo de recursos que con un scritp normal o ¡hasta con las propias funciones server-side de Second Life! (Kadah Coba dixit), disiento con esta posición y la práctica me ha demostrado que el bridge puede y causa problemas de funcionalidad en el propio visor Firestorm y mucho mas en otros visores no preparados para utilizarlo.

2) ¿Es importante tener activado el bridge cuando usamos Firestorm?

Todo depende de que uso le demos al visor Firestorm. Como hemos visto, es útil para hacer Teleportes con doble click en lugares no permitidos, su asistente de vuelo (no activado por defecto), algunas funciones del radar que pocos conocen a fondo y el contador de scripts (que se puede hacer sin necesidad del bridge en otros visores). Fuera de esto, tener el bridge activado no marca ninguna diferencia, por el contario, en mi opinión personal, solo implica un mayor consumo de recursos y que el visor, eventualmente, tenga un funcionamiento errático e inesperado.

Para terminar, se que muchos estarán en contra de esta opinión personal, pero dejenme recordarles que fui usuario de visores con bridge desde sus comienzos e, incluso, colaboré con su diseño y mejoramiento, realizando pruebas y mas pruebas a pedido de los desarrolladores (especialmente con el visor Emerald), por lo cual, me considero lo suficientemente capacitado e informado sobre el mismo como para emitir una opinión.

Ahora, si alguien está interesado en un sano debate e intercambio de opiniones y conocimientos, puede participar en ESTE TEMA de nuestro foro Argentinos en SL.

SaludOS/2