Archivo de la categoría: Problemas y Soluciones

Second Life: Problemas con los chats de grupo

En estos últimos 2 o 3 días recrudeció un problema que ya existe desde hace unos años: el chat de grupos.

Básicamente, para algunos grupos no funciona, para otros funciona de manera intermitente y, por si fuera poco, en otros grupos funciona para algunos usuarios y no funciona para otros. Difícil entonces poder determinar cuál puede ser la causa al enfrentarnos a un problema que, a primera vista, pareciera ser aleatorio y sin una lógica determinada (aunque la tenga).

Haciendo un poco de historia, los primeros grupos que comenzaron a tener problemas con el chat fueron los de soporte de Firestorm, hace ya casi dos años. en un principio pensamos que este problema era porque eran grupos con muchos usuarios (aunque el de mayor cantidad de usuarios es del idioma inglés, con unos 33,000 usuarios, mientras que el resto no superan los 5.000) pero, cuando comenzó a notarse el mismo problema en otros grupos que tenían pocos usuarios (apenas un par de cientos) dicha teoría quedó descartada. Leer Mas...

Visor Firestorm: problemas con inicio de sesión

En estas últimas semanas, especialmente después de la última actualización del visor Firestorm, muchos usuarios se han quejado de varios problemas que dicen padecer, entre ellos, quizás el más grave es el de no poder iniciar sesión en SL con este visor. Y, este problema, solo les afecta a una cuenta mientras otras cuentas del mismo usuario pueden ingresar sin problema.

En el foro de SL y en los grupos en el mundo, mucha gente declara tener este problema y consulta como solucionarlo, también he recibido de manera privada, mensajes preguntándome como poder solucionar este fallo. A la fecha no hay una aclaración sobre el mismo, mucho menos conocer que es lo que causa este problema y, por supuesto, tampoco hay una solución para el mismo. Leer Mas...

Second Life: fallo en grupos y caída de fps en el visor, desconexiones

Hoy, a raíz de una charla en el grupo singularity en discord, he podido enterarme de un nuevo fallo en SL que afecta principalmente al visor Firestorm y, en menor medida al visor Oficial de LL.

El fallo se encuentra en el manejo de los avisos en los grupos haciendo que, en vez de purgar los avisos viejos, dejando solamente los correspondiente a los últimos 14 días, no se borren los anteriores y la lista se haga mas extensa con la consiguiente sobrecarga en el visor al tener que recuperar de los servidores todos los avisos de cada grupo. Obviamente, el problema se agrava cuando hablamos de grupos con mucho tráfico de avisos, como los de tiendas o spam. Leer Mas...

Visores: pantalla azul

Con idas y vueltas, luego de un año complicado, tanto en RL como en SL, retomamos este blog e iniciamos el 2021 (recuerden: 2021 es el año en donde se ambientó la película futurista/apocalíptica Mad Max) con un problema que ha aparecido en estos días y afecta a varios usuarios de este mundo virtual.

Desde hace unos días muchos usuarios vienen experimentando el problema de ver su visor de color azul, tanto a la interfaz del mismo como el mundo virtual en si.

cuando me comentaron y consultaron por este problema, lo primero que vino a mi mente fue el ya viejo y conocido problema del «bug rosa» que afectó a los visores hace varios años atrás (interesante inversión de números 2012 -> 2021). Leer Mas...

Second Life: Errores en el Marketplace

Desde hace unos días a esta parte muchos usuarios están teniendo problemas al intentar comprar productos en el marketplace de Second Life. En el caso mas notorio, al querer hacer el pago, la página retorna un «internal server error».

Esto es producto de un fallo en el sistema y, aparentemente, se da por un problema de en la base de datos o en las rutinas de manejo de idiomas, ya que el error se produce en aquellos productos que no tienen descripción. Pero, aquí lo interesante, las descripciones faltantes solo ocurren en los idiomas que no son inglés. 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: 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...

Visor Firestorm y Complejidad de Renderizado del Avatar

Hace poco informábamos que Linden Lab había incorporado una nueva característica en su visor oficial, llamada Complejidad de Renderizado del Avatar o, también, «JellyDoll». La particularidades de esta nueva característica ya han sido detalladas en ESTE ARTICULO, por lo cual aquí solo nos vamos a limitar a mostrar como manejarla con el visor Firestorm, ya que en el lanzamiento de la última versión 4.7.9, esta función ha sido incorporada en el mismo y los usuarios de este visor se encuentran con la sorpresa y muchas veces no saben que hacer ante esta situación. Leer Mas...

Visor Firestorm: Vestuarios vacíos

Desde hace un tiempo a esta parte he recibido varias consultas y pedidos de ayuda por un problema que, originalmente ocurría solamente con el visor Firestorm, pero a partir de la última versión del visor Singularity, también ocurre con este último, por lo tanto, no es de descartar que pueda ocurrir con otros visores actualizados con las últimas modificaciones del visor oficial de Linden Lab.

Básicamente el fallo está en el manejo del AISv3, nuevo sistema de inventarios del visor, fallo que impide crear nuevos vestuarios. En realidad, cuando intenta guardar un vestuario, la carpeta del mismo se crea sin problemas, pero vacía. Leer Mas...

Second Life: Complejidad de Renderizado del Avatar

Desde hace un par de semanas a esta parte, muchos usuarios del visor oficial de Linden Lab se sorprenden (y hasta asustan temiendo algún problema con su tarjeta gráfica) por el hecho de comenzar a algunos avatares de un color fijo en vez de verlos de forma normal como hasta ahora.

jellybell

El motivo es simple, tal como lo adelantara en un artículo anterior, la empresa lanzó su última actualización del visor oficial incorporando la Complejidad de Renderizado del Avatar o, como lo llaman de manera familiar «JellyDoll» (que es una forma avanzada del sistema de Avatares Impostados). Leer Mas...