Guía para generar scripts

Esta página es para quien escribe scripts enteros —a mano o con una IA que lea esta documentación— y no para quien retoca un campo. Son convenciones, no reglas de la gramática: un script que no las siga compila igual, pero cuesta más aplicarlo, leerlo y mantenerlo. Las reglas que sí son de la gramática están en Sintaxis y las del flujo de aplicar en Crear, borrar y mover.

1. La antena es siempre wf_antenna2Copiar enlace

Para señales entre pilas usa la Antena Wired Pequeña, wf_antenna2. Como antena vale cualquier furni —la señal se empareja por el furni concreto, no por su tipo (ver La antena)—, pero en un script generado usa siempre wf_antenna2: es 1x1, no hace nada por sí misma, cada señal solo la hace parpadear y se reconoce a simple vista como "canal de señal". Con wf_antenna2 como única opción no hay nada que decidir.

Declárala con etiqueta y sin #id al final de la pila que la emite (punto 5), y referénciala por esa etiqueta desde antennas (Enviar Señal) y desde furnis (Recibir Señal):

stack (3, 1) {
    trigger.says {
        text = ":empezar"
    }
    effect.send_signal {
        antenna_source = selected
        users_to_advance = triggering
        antennas = [ ant_ronda ]
    }
    furni ant_ronda "wf_antenna2"
}

Si la pila receptora tiene que actuar sobre quien habló, no te dejes users_to_advance = triggering: omitido, la señal lleva los usuarios que haya elegido un selector de la pila (ninguno, si no hay).

2. Todas las pilas en una sola filaCopiar enlace

Las pilas de wireds del sistema van en fila: misma y, x creciente de una en una —stack (1, 1), stack (2, 1), stack (3, 1)…—. No repartas el sistema en varias filas ni lo dobles en un rectángulo: una fila se recorre de izquierda a derecha con el cursor y cada pila está donde se espera. Cambia de disposición solo si quien pide el script te da una, o si la sala no tiene sitio en esa fila.

No hay excepciones: las antenas no ocupan pila propia —van dentro de la pila que las emite (punto 5)— y las pilas de cajas de variable (punto 4) van en esa misma fila, a la izquierda del todo.

3. Orden de apilado por tipoCopiar enlace

Dentro de cada pila escribe los bloques en este orden:

1. Causantes (trigger.*)
2. Complementos (extra.*)
3. Selectores (selector.*)
4. Condiciones (condition.*)
5. Efectos (effect.*)
6. Efectos negativos (effect.neg_*)

Es un orden de lectura, no de ejecución: estén como estén apilados, al dispararse el servidor resuelve los selectores, aplica los complementos, evalúa las condiciones y ejecuta los efectos, y los efectos no corren en el orden en que los apilas sino por escalones: Dar variable, por ejemplo, corre después de los movimientos de furnis (ver Orden de ejecución). Ordenar por tipo es solo una convención para que todas las pilas se lean igual.

La excepción es Ejecutar en orden (extra.exec_in_order). Con ese complemento en la pila, los efectos se ejecutan en el orden en que están apilados —de abajo arriba en la sala, que en el texto es el orden en que los escribes—, así que ahí el orden de los efectos entre sí ya no es cosmético: escríbelos en el orden en que tienen que pasar. Los bloques que no son efectos siguen la regla general.

4. Cada tipo de caja de variable en su propia pila; el conector aíslaCopiar enlace

Las cajas de variable van en pilas aparte, agrupadas por tipo: una pila para las de sala, otra para las de usuario, otra para las de furni, otra para las de contexto — nunca mezcladas con los wireds que las usan (ver las cajas de variable van en pilas aparte).

Y una caja que lleve Conector de texto va sola en su pila, con el conector: el conector se aplica a todas las cajas de variable de la baldosa que comparte (salvo a las variable.reference y a las variable.pointer, que no lo usan), así que si la dejas con las demás, todas heredan su tabla. Lo mismo con Compartir (extra.var_addon_share), que sincroniza todas las compartidas entre salas de su baldosa y va sola con la suya, y con Importar (extra.var_addon_import), que se aplica a todas las variable.reference de su baldosa y va sola con la suya.

stack (1, 1) {
    variable.room { name = "fase" }
    variable.room { name = "ronda" }
}

stack (2, 1) {
    variable.room { name = "color" }
    extra.var_text_connector {
        table = "1=rojo\n2=verde\n3=azul"
    }
}

Y cuando una condición compruebe una variable de furni, de usuario o de contexto, escribe siempre su ámbito: condition.has_var y condition.neg_has_var miran furni si no escribes scope, así que para una variable de usuario o de contexto pon scope = user o scope = context (las de sala no se comprueban con has_var: no tiene ámbito para ellas). Si el ámbito no es el de la caja, el editor lo marca como error.

Una Variable puntero (variable.pointer) es una caja más: va en su propia pila, con su scope y con accessor_variable apuntando a una variable.context que tenga has_value = true. Su ámbito cuenta como el de cualquier otra caja para la regla de arriba. Y la variable de acceso se da en la pila que manda la señal, con el @id de la caja de destino; el puntero se usa en la pila que la recibe. Dársela en la misma pila que usa el puntero no lo apunta.

stack (3, 1) {
    variable.context {
        name = "caja_equipo"
        has_value = true
    }
}

stack (4, 1) {
    variable.pointer {
        name = "puntos_equipo"
        scope = global
        accessor_variable = "caja_equipo"
    }
}

5. La antena, al final de la pila que la emiteCopiar enlace

No pongas las antenas todas juntas en un rincón ni en una fila aparte: cada antena va en la misma pila que la emite —la del effect.send_signal o del effect.neg_send_signal que la selecciona—, escrita al final del bloque, después de los wireds. Así no queda ningún furni suelto por la sala que haya que ir a buscar, y en el texto se ve de un vistazo qué pila dispara qué señal.

La pila que recibe no necesita nada: el trigger.recv_signal referencia esa antena por su etiqueta, esté en la pila que esté.

Si una misma pila emite por dos antenas (el envío positivo y el negativo, por ejemplo), las dos van al final de esa pila.

6. Los saltos de línea de un conector se escriben \nCopiar enlace

En la tabla de un Conector de texto las parejas van en una sola cadena separadas por los dos caracteres \n. Un salto de línea de verdad dentro de las comillas rompe el script (Cadena sin cerrar en cascada):

table = "0=blanco\n1=amarillo\n2=naranja"      // así

Ver Escapes dentro de las comillas.

7. El estilo del mensaje dice algoCopiar enlace

effect.show_message tiene un notification_style con un significado visual cada uno. No uses el mismo para todo: elige el que corresponde a lo que el mensaje cuenta.

Las variantes "(círculo)" son el mismo icono dentro de un círculo: sirven para distinguir dos mensajes de la misma familia (por ejemplo, acierto normal y acierto final).

8. La menor cantidad de pilas posibleCopiar enlace

Monta el sistema con las menos pilas que puedas: menos pilas es menos furnis, menos antenas, menos coste al aplicar y un sistema que se entiende de un vistazo. Antes de añadir otra pila, busca el wired que te ahorra el rodeo: casi siempre hay uno que hace en un bloque lo que ibas a montar en tres —una condición en vez de una pila que comprueba y reenvía, un selector en vez de una cadena de señales, un contador o una variable en vez de tres pilas encadenadas.

Con el sistema escrito, repásalo una vez con esta pregunta: ¿qué pilas se pueden fundir? Dos pilas con el mismo causante y condiciones compatibles son una; una señal que solo existe para saltar a otra pila sobra si los efectos caben en la primera; una cadena de tres señales suele poder ser de una o dos. Si una pila no se puede fundir sin exec_in_order ni sin romper el orden que el juego necesita, déjala.

9. Los límites de una pilaCopiar enlace

A diferencia de las convenciones de arriba, estos límites son de verdad: si un script se pasa, o el editor no te deja aplicar, o el wired se guarda y no hace lo que esperas. Con un solo error en el documento, Aplicar no se activa para ningún bloque. Las nueve primeras filas las comprueba el editor y dan error; las demás las decide el servidor, al aplicar o al ejecutarse la pila, y el editor, como mucho, avisa.

RecomendacionesCopiar enlace

Si vas a generar un sistema entero a partir de esta wiki, estas son las recomendaciones a seguir:

1. Que la antena a utilizar en los sistemas de wired sea la wf_antenna2.
2. Que las pilas de wired siempre vayan en una sola fila y que no crees varias filas.
3. Que el orden sugerido para apilar wireds sea por tipo, de esta forma: causantes, complementos, selectores, condiciones, efectos, efectos negativos. El orden sugerido solo es para pilas que no tienen el complemento Ejecutar en orden, ya que cuando se usa este complemento la ejecución de los efectos cambia según cómo estén apilados en la pila.
4. Que las cajas de variable se apilen en pilas diferentes según su tipo, pero recordando que si se usa un conector de texto hay que aislar esa caja de variable en otra pila. Y recordando que el conector de texto afecta a todas las cajas de variable de la pila, salvo a las variable.reference y a las variable.pointer; Compartir, a todas las compartidas entre salas de la pila, e Importar, a todas las variable.reference. Y que condition.has_var y condition.neg_has_var lleven siempre su scope, porque sin él miran furni. Y que la variable de contexto que apunta un variable.pointer se dé en la pila que manda la señal, no en la que usa el puntero.
5. Que las antenas a utilizar vayan al final de la misma pila, así no las tenemos en otro lado y las podemos identificar correctamente.
6. Que en los conectores de texto los saltos de línea de verdad pueden romper el código, por lo que se usa \n para los saltos de línea.
7. Que se usen lógicamente los estilos del wired Mensaje, ya que hay varios tipos y cada uno tiene un significado visual diferente.
8. Que se use la menor cantidad de pilas posible para armar el sistema propuesto, y que siempre se busquen wireds que puedan optimizar más el proceso en vez de alargarlo.
9. Que se respeten los límites del punto 9: listas de hasta 30 furnis (50 con Super Wired; en un bloque nuevo, el máximo que diga el editor), retardos válidos, mensajes de hasta 400 caracteres y 8 líneas, nombres de variable de 1 a 40 letras sin tildes, como mucho cinco Variable FX por baldosa y un uso wired por debajo de 20.000, y sin effect.give_reward, effect.bot_follow_avatar, condition.conditionstatepos ni condition.conditionuserhasfurni, ni líneas furni nuevas de cofres, teletransportadores o Nexos de Sala.