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; } } }
