Crear, borrar y mover

El documento no es solo una vista de lo que hay: es la lista de lo que quieres que haya.

Siempre que haya compras, recogidas, movimientos o cambios de altura/rotación, el botón de la barra pasa a llamarse Vista previa… y antes de tocar nada sale una vista previa que hay que confirmar. Aunque el total sean 0 créditos, y aunque lo único que haya sea un movimiento o un cambio de altura.

Crear: un bloque sin #idCopiar enlace

Crear pide los permisos comunes (ver Permisos) y, además, no tener activado el modo de prueba. No hace falta ser dueño de nada, porque el furni todavía no existe.

Lo escribes igual que cualquier otro, pero sin el #id:

stack (3, 1) {
    trigger.says #48211 {
        text = "abre"
    }
    effect.teleport_to {
        furnis = [ #48360 ]
        delay = 2
    }
}

La forma más rápida de crear uno es duplicar un bloque que ya funciona y quitarle el #id.

Lo que hace falta:

• No se elige el furni por texto: lo decide el familia.nombre del bloque. Qué wired es cada nombre lo dice la referencia, con el nombre con el que sale en el juego, y la vista previa te enseña qué se compra y cuánto cuesta antes de confirmar.
• La baldosa es la del stack (x, y) que lo contiene. La altura no se elige: cada pieza cae a la altura a la que caería si la soltaras con el ratón, encima de lo más alto que haya en las casillas que ocupa, y si creas varias en la misma casilla se apilan en este orden: primero las líneas furni, luego las cajas variable.* y por último el resto de bloques, y dentro de cada grupo en el orden en que están escritas. Entre efectos, por tanto, el orden del texto es el de la pila — lo que cuenta para Ejecutar en orden.
• Como con el ratón, cuenta todo lo que ocupa: un furni de varias casillas se apoya en lo más alto de todas ellas, y sobre una silla o una cama la pieza queda encima, no metida dentro. Sobre una baldosa mágica, cada pieza cae a la altura de la baldosa, aunque ya haya otras encima. En una línea furni puedes fijar otra altura escribiendo su z, que se aplica al final de la construcción.
• La rotación de un bloque nuevo es siempre 0 (la primera posición que admite el furni).
• Un campo que no escribes vale su valor por defecto, que es el de una caja recién colocada en el juego (ver Campos).
• Una caja variable.* nueva sin name solo se compra: sin nombre todavía no es ninguna variable, así que ningún bloque la puede nombrar y lo demás que escribas en ella no se guarda. El panel lo avisa con un ℹ, la caja se compra sin nombre: no registra ninguna variable hasta que le pongas `name` (si escribes otros campos, el aviso añade «; los demás campos que escribes tampoco se guardan hasta entonces»), y al aplicar su fila es la de la compra (wf_var_context → #N). Para que cuente como variable, dale un name.
• Con user_source = clicked o user_source = reached, su causante (trigger.click_user o trigger.bot_reached_avtr) tiene que estar en la misma pila. Puede ser nuevo también, del mismo texto. Si falta, el editor da un error (ver De los campos).

En el margen izquierdo del editor, los bloques nuevos y las líneas furni sin #id llevan un + verde. En la barra sale la pastilla +N nuevos y en el panel un aviso por cada uno («nuevo wired familia.nombre en (3, 1)»). Son avisos con su propio icono, +, no errores: no bloquean.

Qué puede referenciar un bloque nuevoCopiar enlace

• ✅ Puede referenciar furnis que ya existen: furnis = [ #48360, #48361 ].
• ✅ Puede referenciar por nombre una variable que declara otra caja variable.* nueva del mismo documento: variable = "a". El editor guarda esas cajas de variable antes que el resto y, en cuanto tienen su #id real, rellena la referencia con él — no hace falta escribir el #id a mano ni recargar. Mientras tanto, esa fila del panel sale como un aviso … que no bloquea: 'campo': se resolverá al crear 'a'.
• ✅ Puede referenciar por etiqueta un furni o un wired nuevo del mismo documento: furnis = [ tile1 ], antennas = [ ant ]. Se guarda vacío hasta que ese bloque se crea y el editor rellena el #id solo (aviso …: 'furnis': se resolverá al crear 'tile1') — ver Etiquetas.
• ❌ No puede ser referenciado por su #id, porque todavía no lo tiene: usa su etiqueta.

Es lo que recuerda la propia vista previa: los wireds nuevos reciben su #id al aplicar; hasta entonces se referencian por etiqueta (o por nombre, si son cajas de variable: ver la regla de abajo). Si prefieres la referencia por #id, aplica, deja que el editor recargue —los bloques nuevos ya salen con su #id real— y entonces escríbela.

Nombres de variable únicos por salaCopiar enlace

El servidor solo admite un nombre por sala para las siete cajas: el nombre de una variable.context/furni/room/user, el nombre local de una variable.echo, el alias de una variable.reference y el nombre de una variable.pointer no pueden repetirse entre sí. Escribir el mismo nombre dos veces en el documento es un error:

Si la sala ya traía dos cajas con el mismo nombre y tu texto no toca ninguna de las dos, no es un error y puedes aplicar lo demás: sale un aviso ℹ nombre de variable repetido 'a' (ya venía repetido en la sala; no bloquea): ya lo declara el bloque de la línea L. El servidor conserva las dos cajas, pero cuando algo busca "a" por su nombre se queda con la primera que registró. Para arreglarlo, renombra una de las dos: el aviso desaparece.

Una caja que quitas del texto se recoge antes de que se creen las nuevas, así que su nombre queda libre en ese mismo Aplicar. Por eso puedes rehacer una caja de una vez: quitas variable.user #N { name = "a" }, escribes variable.furni { name = "a" } y aplicas. Los bloques que nombran "a" pasan a la caja nueva. Si la caja nueva es de otro tipo, como en el ejemplo, cambia también el ámbito de esos bloques (scope, reference_scope…). Ese nombre también se lo puedes dar a otra caja de la sala, renombrándola: los bloques pasan a ella. Ojo: si la vieja guarda valores permanentes, se pierden igual (ver Recoger una caja de variable permanente o compartida).

Una caja que renombras se puede nombrar ya por su nombre nuevo, en el mismo texto.

Siguen siendo un error dos cajas nuevas con el mismo nombre. También lo es renombrar una caja y crear otra con su nombre en el mismo texto: la nueva se guarda antes que el cambio de nombre, y ese nombre todavía está ocupado.

Declara cada variable una sola vez para toda la salaCopiar enlace

Regla práctica al escribir un script: una caja de variable por nombre, en una sola pila, y el resto de pilas la referencian por nombre (variable = "a") sin volver a declararla. Las variables no son de la pila que las declara, son de la sala entera: cuatro pilas que hacen cuatro operaciones distintas sobre a, b y res llevan las tres cajas variable.* solo en la primera, y las otras tres solo trigger, effect y extra. Repetir variable.context { name = "a" } en cada pila no añade nada —el nombre ya existe en la sala en cuanto se guarda la primera— y es exactamente el error de arriba.

Las cajas de variable van en pilas aparte, agrupadas por tipoCopiar enlace

Las cajas variable.* no se mezclan con los causantes y efectos que las usan: van en sus propias pilas, y agrupadas por tipo — una pila con las variable.user, otra con las variable.furni, otra con las variable.context… El motivo es que los complementos (extra.*) de una pila se aplican a todas las cajas de esa pila, así que meter una variable.* junto a un trigger o un effect la deja expuesta a un complemento que no le corresponde.

La única excepción es un complemento que deba aplicarse a una sola variable: esa caja va sola, en su propia pila, junto con su complemento. Pasa con un Conector de texto (extra.var_text_connector), con Compartir (extra.var_addon_share), que va con su caja compartida entre salas, y con Importar (extra.var_addon_import), que va con su variable.reference.

stack (1, 1) {
    variable.user #48301 {
        name = "puntos"
    }
    variable.user #48302 {
        name = "vidas"
    }
}

stack (2, 1) {
    variable.context #48303 {
        name = "mensaje"
    }
    extra.var_text_connector #48304 {
        table = "1=hola\n2=adiós"
    }
}

stack (3, 1) {
    trigger.says #48211 {
        text = "puntos"
    }
    effect.change_var #48230 {
        variable = "puntos"
        scope = user
        operation = add
        literal_value = 1
    }
}

Las pilas nuevas van en el eje XCopiar enlace

Cuando escribes o generas varias pilas nuevas, colócalas en fila por defecto: misma y, x creciente — stack (1, 1), stack (2, 1), stack (3, 1)… Usa otra disposición solo si quien te pide el script especifica una en concreto, o si la sala no tiene sitio en esa fila.

Declara los furnis con etiqueta y sin #id si el script se va a copiarCopiar enlace

Si escribes o generas un script pensado para aplicarse en más de una sala, no lo ates a los #id de esta: declara cada furni con su etiqueta y sin #id, y referencia siempre por etiqueta (furnis = [ tile1 ]), nunca por #id. Así el documento compra y coloca lo que haga falta en cualquier sala donde lo apliques — ver Copiar un script a otra sala.

Las antenas de effect.send_signal van igual: antennas = [ ant ] con la antena declarada como furni ant "wf_antenna2" sin #id, y el mismo documento la compra, la coloca y la engancha al envío y al trigger.recv_signal — ver Antenas y señales.

Las variables de contexto solo viven durante una ejecuciónCopiar enlace

Una variable de contexto existe solo mientras dura la ejecución de la pila que la usa, y se descarta al terminar. Para el script eso tiene una consecuencia directa: no hace falta —ni conviene— crear un juego de variables de contexto por pila; se declaran una sola vez (la regla de arriba) y las usan todas las pilas que las necesiten.

Si el valor tiene que sobrevivir entre ejecuciones o entre usuarios, no es una variable de contexto: es de usuario, de furni o de sala.

Una variable de contexto hay que darla antes de usarlaCopiar enlace

La caja variable.context { name = "res" } solo declara el nombre. Dentro de la ejecución la variable no existe hasta que algo la crea: un Dar variable (effect.give_var) al principio de la pila, o un Capturador de variables (extra.text_input_variable) que la rellena con lo que dijo el usuario. Un Cambiar valor de variable (effect.change_var) sobre una variable de contexto que nadie ha dado no hace nada: no la crea.

Así que en toda pila que calcule algo en una variable de contexto, el primer efecto es darla:

stack (3, 1) {
    trigger.says {
        text = "#(a)+#(b)"
        match_type = exact
    }
    effect.give_var {
        scope = context
        variable = "res"
        initial_value = 0
    }
    effect.change_var {
        scope = context
        variable = "res"
        operation = assign
        use_reference = true
        reference_variable = "a"
        reference_scope = context
    }
}

a y b no necesitan su effect.give_var porque las crea el capturador al leer el chat; res sí.

Borrar: quitar el bloque o la líneaCopiar enlace

Borras el bloque o la línea furni del texto (o comentas sus líneas) y al aplicar ese furni se recoge al inventario — un wired o un furni normal, da igual: es como recogerlo con el ratón, solo que decidido por lo que falta en el texto. En la barra sale la pastilla −N quitados y en el panel un aviso por cada uno («#48213 (condition.has_furni_on) se recogerá al inventario»).

Lo que conviene saber:

• El furni vuelve siempre a su dueño, que puede no ser quien está aplicando (con el ratón, en una sala sin grupo, lo ajeno se lo queda quien lo recoge). Si el dueño está conectado, le aparece en el inventario en el momento.
• Las selecciones de furnis que otros wireds tuvieran sobre él se limpian solas, como en cualquier recogida, salvo en las listas que el wired guarda aparte: ahí el wired sigue guardando el #N recogido (y, como el furni conserva su #id, si vuelve a la sala mientras siga ahí, esas listas lo nombran otra vez). Si editas una lista que todavía lo nombra en el texto, el editor da 'campo': el furni #N no está en la sala. El panel ofrece entonces Quitar los #id desconocidos: saca de la lista solo los #id que ya no están en la sala, y el resto se queda. Lo que ves depende del wired:
  • En antennas y secondary_furnis de effect.send_signal y effect.neg_send_signal, y en furnis y secondary_furnis de effect.furni_to_furni, condition.stuff_is y condition.not_stuff_is, el #N deja de salir en el texto en cuanto recargas, aunque el wired lo guarda hasta la próxima vez que se guarda.
  • En furnis y secondary_furnis de effect.init_transaction, condition.chest_has_item_type, extra.custom_contract y extra.scan_chest_furni_by_type, sigue en el texto hasta la próxima vez que se guarda ese wired.
  • En furnis y secondary_furnis de effect.change_var, effect.modify_highscore, condition.var_val_match y extra.mov_physics, en reference_furnis de effect.give_var y condition.var_age_match, y en secondary_furnis de effect.place_furni y effect.move_furni_as_group (en estos cuatro, su otra lista sí se limpia), se queda hasta que lo quitas tú.
• Las variables no se limpian: si recoges una caja variable.* que otros bloques usan, esos bloques se quedan apuntando a una variable que ya no existe. El panel te lo avisa antes con un ℹ: la variable 'puntos' se recoge en esta tanda y la usan 2 bloques. Si el mismo texto da ese nombre a otra caja (una nueva o una renombrada), esos bloques pasan a ella y el aviso no sale (ver Nombres de variable únicos por sala).
• Solo puedes recogerlo si es tuyo, o si eres el dueño de la sala, staff con control de salas o administrador del grupo de la sala — la misma condición que con el ratón (ver Permisos). Los cofres son la excepción: solo los recoge el dueño de la sala, ni siquiera el staff. Si no puedes, el bloque se queda tal cual: la vista previa saca la fila suelta #N no es tuyo (con un cofre, #N: Solo el dueño de la sala puede recoger los cofres.) y Aplicar queda apagado.
• Por texto tampoco se recoge un Espacio Alquilable mientras esté alquilado, ni un furni de Builders Club: la vista previa lo dice con su propia fila suelta (ver Cuando una fila no se puede hacer) y Aplicar queda apagado, igual que con #N no es tuyo.

Recoger una caja de variable permanente o compartidaCopiar enlace

Una caja variable.* con availability = permanent o permanent_shared guarda su valor fuera de la sesión (ver Variable de usuario, Variable de furni y Variable global): sobrevive a que te vayas de la sala, y con permanent_shared es un dato de todo el hotel. Pero incluso permanent a secas guarda un valor por cada usuario o furni que la haya usado, todos bajo la misma definición. Recogerla no solo la manda al inventario: borra esa definición, y con ella todos esos valores guardados —los de todo el mundo, no solo los tuyos—, y no hay vuelta atrás.

Por eso, además de la regla de dueño de arriba, solo puede recogerla quien podría recogerla con el ratón (tú, o quien gestiona el furni del grupo) y la vista previa pide, aparte, una confirmación explícita: sale una fila propia con la casilla «Entiendo que se borrarán los valores permanentes de estas variables», seguida de los #id afectados. Hasta que la marcas, Aplicar está apagado y la fila suelta del panel dice #N guarda valores permanentes: confírmalo en la vista previa. En cuanto la marcas, el editor vuelve a pedir la vista previa —puede tardar un par de segundos, el respiro de siempre entre dos vistas previas (ver La vista previa)— y esta vez la trae ya confirmada.

Recoger el complemento Web API de variablesCopiar enlace

Quitar del texto el bloque extra.var_web_api recoge el complemento. Recogerlo borra sus claves de lectura y de escritura sin vuelta atrás: dejan de valer y, si lo vuelves a colocar, serán otras (ver Web API de variables). El panel lo avisa con un ℹ en cuanto quitas el bloque.

La vista previa pide la misma casilla de confirmación, con su propia frase: «Entiendo que las claves de la API de estos complementos se borran sin vuelta atrás (al volver a colocarlos serán otras)», seguida de los #id afectados. Hasta que la marcas, Aplicar está apagado. Sin cajas permanentes o compartidas en la tanda, al marcarla no hay que esperar a otra vista previa. Si en la misma tanda recoges también una caja de variable permanente o compartida, es una sola casilla con las dos frases, cada una con sus #id.

Mover: cambiar la casillaCopiar enlace

Cambias el stack (x, y) que envuelve un bloque con #id y al aplicar ese wired se mueve a la baldosa nueva:

stack (5, 7) {
    trigger.says #48211 {
        text = "abre"
    }
}

Mover la cabecera de una pila mueve todos sus bloques a la vez, a la baldosa nueva; mover un solo bloque a otra pila —dejando el resto donde estaba— también vale. Las piezas de la pila que salen como comentario no tienen bloque, así que se quedan en su casilla.

• Mover pide los permisos comunes (ver Permisos) —el modo de prueba no lo frena— y, igual que al arrastrarlo con el ratón, no hace falta que el wired sea tuyo: con derechos, mueves también el que colocó otra persona.
• Un bloque movido puede además tener campos distintos: se mueve primero (es parte de la construcción) y se guarda después, igual que si lo guardaras desde su propia ventana. Ese cambio de configuración cuenta como cualquier otra edición.
• La altura (Z) la pone el destino, como al arrastrarlo con el ratón: se apoya encima de lo que ya haya en la casilla destino, y si mueves varios bloques a la misma pila se apilan en el orden en que están escritos — como arrastrarlos uno a uno. En una línea furni en la que además cambias la z o la rot, al final manda la z de la línea, o la que tenía si no la escribes (ver Furnis normales). Si no cambias ninguna de las dos, la z de la línea no se aplica. Si no es 0, el panel te lo recuerda con un ℹ, por ejemplo #48300 tile1: al moverlo a (5, 7) queda en la cima de esa casilla y no se aplica z = 250; para fijarla, vuelve a escribirla después de aplicar.
• La rotación no cambia: los wireds no llevan rot en el DSL, así que mover un bloque de wired conserva la que ya tenía. Un furni sí cambia de rotación por texto — ver Furnis normales más abajo.
• Se mueve cualquier furni de suelo del documento, wired o normal (los temporales no salen en él: ver Furnis normales) — mover a otra sala queda fuera (ver Qué no hace).
• Las zonas de Furnis en área y Usuarios en Área (area_x, area_y…) son casillas de la sala, no de la pila: mover el bloque no las mueve. El panel te lo recuerda con un ℹ en la línea de la pila: stack (x, y): selector.furni_area #N cambia de casilla, pero su zona (area_x, area_y) se queda en las mismas casillas de la sala; cámbiala si quieres que lo acompañe.

En el margen izquierdo el bloque movido lleva un ↔ azul, en la barra sale la pastilla ↔N movidos y en el panel un aviso por cada uno (↔ #id (x1, y1) → (x2, y2)). Son avisos con su propio icono, ↔, no errores: no bloquean.

Las reglas que ya conocías siguen igual: un #id repetido es un error, el i_type que no casa con ese #id es un error, y un #id que no está en la sala es un error (ver Editar y aplicar).

Furnis normalesCopiar enlace

Una línea furni (ver Sintaxis) no es un wired —no tiene familia ni ventana propia—, pero se edita como con el ratón: por texto lo recoges, lo mueves, lo subes o lo bajas y lo rotas. Hay tres diferencias: lo recogido vuelve siempre a su dueño (ver Borrar), la z es la altura exacta del furni y rotarlo por texto no lo sube a la cima de su pila, como sí hace el ratón al girarlo en su sitio.

• La compra sale en la vista previa como cualquier otra compra (classname (x, y) · N c), mezclada con las de los wireds nuevos, no en una lista aparte.
• La rotación se escribe con rot, índice de posición (0, 1, 2…, el del infostand): furni tile1 "dice_wired_grey" { z = 0, rot = 2 }. El volcado lo escribe siempre, aunque sea 0.
• La altura se escribe con z, entero en centésimas (250 = 2,50): furni tile1 "dice_wired_grey" \{ z = 250, rot = 0 \}. El volcado también la escribe siempre. Cambiarla en un furni existente lo deja a esa altura exacta, sin apoyarlo en lo que tenga debajo, de -4000 a 8000: de -40 (hundido bajo el suelo) a 80 (el tope de apilado de la sala). Es la altura del furni en la sala, no la de :setz, que admite de -40 a 100 y, al colocar o mover, cuenta desde el suelo de la casilla.
• Los cambios de altura y rotación de furnis normales tienen su propia pastilla, ↕N alturas; la de ↔N movidos cuenta solo los cambios de casilla. En el margen llevan un ↕ azul, y en la vista previa salen en su propio grupo, ↕ N alturas, con el detalle #id classname z 250 → 300 · rot 0 — ver La vista previa.
• Un #id que no está en la sala: el furni #N no está en la sala.
• Un #id que en realidad es un wired: #N es un wired: escríbelo como familia.nombre.
• Dos líneas furni con el mismo #id: el furni #N aparece dos veces. Copiaste y pegaste sin quitar el id, igual que con un wired.
• Un furni sin #id cuyo classname es en realidad un wired: "classname" es un wired: escríbelo como familia.nombre. Un wired no se compra ni se coloca como furni normal.
• Un furni sin #id cuyo classname empieza por wf_trg_, wf_act_, wf_cnd_, wf_slc_, wf_xtra_ o wf_var_ y que el editor no conoce: "classname" es un wired que Wired Code todavía no conoce: no se puede crear con una línea furni (ver Un wired que el editor no conoce). Los demás furnis que empiezan por wf_, como interruptores, baldosas o antenas, se compran igual que cualquier otro.

Los furnis temporales que ponen los wireds (ver Furnis temporales) no salen en el documento: no tienen línea furni, así que por texto no se recogen, ni se mueven, ni cambian de altura. Los ponen y los quitan sus wireds. Si tu texto lleva la línea furni de uno (un texto viejo, a veces con el comentario // temporal al final), esa línea no hace nada y no da error; si el temporal ya no está en la sala, el panel lo dice con el aviso #N era temporal y ya no está en la sala: se ignora esta línea.

Declara los furnis normales con z y rot explícitosCopiar enlace

Regla práctica al escribir o generar un script, junto a las de organización de más arriba: escribe siempre z y rot en cada línea furni, aunque sean 0. Es lo que hace el propio volcado, y evita ambigüedad entre «no me importa la altura/rotación de este furni» y «quiero que quede a 0» — sobre todo en un furni nuevo, donde la z se aplica tras colocarlo. En un furni que ya está en la sala y que cambias de pila, en cambio, la z solo se aplica si cambias la z o la rot: si dejas las dos como estaban, se apoya en lo que haya en el destino; si lo giras al moverlo, escribe la z que quieres que tenga allí.

Copiar un script a otra salaCopiar enlace

Los #id son de una sala: un documento que traes de la sala A no se puede aplicar tal cual en la sala B, porque ninguno de sus #id existe ahí.

Para llevarlo, quita todos los #id. El panel ofrece el botón «Quitar los #id desconocidos (N)» en cuanto detecta alguno que no es de la sala en la que estás, así que no hace falta hacerlo a mano. El botón quita de las cabeceras los #id que no son de esta sala. Dentro de las listas [ … ], cambia cada #id desconocido por la etiqueta de su bloque, para que la referencia no se rompa. Si ese #id no es de ningún bloque que se vaya a crear (un furni de pared de la sala de origen, por ejemplo), lo saca de la lista. Todo lo que se queda sin #id pasa a tratarse como nuevo: se compra y se coloca, sea un furni o un wired. Las referencias por etiqueta se resuelven solas en cuanto se crea.

El botón puede salir deshabilitado, con el motivo a la derecha, en la misma fila:

Lo que no viaja. Un wired lleva su configuración en el texto, pero de una línea furni solo viajan el tipo, la casilla, la altura y el giro: el furni que se crea sale de fábrica, como recién comprado. Así que en la sala nueva tienes que repetir a mano la zona de una Zona Oculta, el texto de una Etiqueta WIRED, el color de un bloque recoloreable, la configuración de los contratos y la de la Tabla de Puntuación - Variable; los tablones de puntuación empiezan sin resultados. Además:

• Las piezas que salen como comentario no se crean: no tienen bloque.
• Los cofres no se crean por texto: los compra y los coloca a mano el dueño de la sala.
• Los teletransportadores y los Nexos de Sala tampoco se crean por texto: se compran por parejas, así que la vista previa rechaza su línea furni con es un teletransportador: se compra por parejas, cómpralo y colócalo a mano (o es un Nexo de Sala: …). Cómpralos y colócalos a mano.
• De cada controlador solo cabe uno por tipo en la sala (ver Controladores de sala): si la sala nueva ya tiene uno, o el texto trae dos, la vista previa rechaza el que sobra con solo cabe uno de este tipo por sala y ya hay uno puesto (o … y esta tanda ya crea otro). Quitar del texto el de la sala y escribir otro del mismo tipo sí vale: se recoge antes de crear el nuevo. La Zona Oculta no cuenta: de esa caben varias.
• Las zonas de Furnis en área y Usuarios en Área son casillas de la sala: no se mueven aunque cambies el stack (x, y) de su pila. Revísalas: aquí el editor no avisa, porque los bloques llegan sin #id.
• A cero y Posición o Estado Coincide (y su versión NO Coincide) no se llevan su foto: la vuelven a sacar al aplicar, con los furnis tal como estén entonces en la sala nueva.

Regla para quien genera scripts: si el documento está pensado para copiarse a otra sala (o para varias), declara los furnis con etiqueta y sin #id, y referencia siempre por etiqueta, nunca por #id — ver Declara los furnis con etiqueta y sin #id si el script se va a copiar.

La vista previaCopiar enlace

Con compras o recogidas por medio, Vista previa… no guarda: le pregunta al servidor cuánto cuesta y qué se puede hacer sin tocar la sala, y abre un panel titulado Aplicar cambios encima del editor:

Aplicar cambios

✎ 3 modificados
+ 2 nuevos → 2 compras · 45 créditos
    wf_act_teleport_to (3, 1)            · 25 c
    wf_trg_periodically (5, 7)           · 20 c
− 1 quitados → al inventario
    #48213 condition.has_furni_on (3, 1)
↔ 1 movidos
    #48211 trigger.says (3, 1) → (5, 7)
↕ 1 alturas
    #48300 dice_wired_grey z 250 → 300 · rot 0

Los wireds nuevos reciben su #id al aplicar; hasta entonces los demás bloques los referencian por su etiqueta.

                                  [ Cancelar ]  [ Aplicar · 45 créditos ]

• Cada fila de compra, movimiento o cambio de altura/rotación salta a su línea en el editor si la pulsas. Las de recogida no: su bloque ya no está en el texto.
• Si alguna recogida borraría valores de variable permanente o compartida, o las claves de un complemento Web API de variables, justo debajo de las recogidas sale una fila propia con la casilla de confirmación — ver Recoger una caja de variable permanente o compartida y Recoger el complemento Web API de variables.
• El botón dice Aplicar · X créditos, o solo Aplicar cuando el total es 0 (no se enseña «· 0 créditos», que solo mete ruido).
• Cancelar, cerrar la ventana o pulsar Escape cancelan sin haber tocado nada.
• Mientras el editor está esperando al servidor, el texto queda bloqueado y aparece Aplicando… junto a los botones. Durante esa fase Cancelar, Escape y Recargar están apagados: el servidor ya está comprando y recogiendo, y no hay vuelta atrás.
• La barra de estado enseña Vista previa: +N −N ↔N ↕N mientras el panel está abierto (el ↕N, solo si hay cambios de altura o rotación).

Si confirmas: pieza a piezaCopiar enlace

Al pulsar Aplicar, el servidor no ejecuta la tanda de golpe: la construye pieza a pieza, una operación cada vez, a un ritmo de unas 7 por segundo. El orden es siempre el mismo: primero se recoge, después se mueve, luego se crea —dentro de las creaciones, primero los furnis normales, luego las cajas de variable y por último el resto— y al final se aplican los cambios de altura y rotación (↕), de uno en uno, en el orden en que están escritos —incluidos los de los furnis recién creados, con su #id nuevo—. Recoger libera casillas y altura antes de mover, y los movidos y creados ya están en su sitio nuevo cuando se cambia la altura o la rotación de lo último.

El motivo: así es el servidor quien fija el ritmo, así que una tanda grande nunca lo satura, y si algo falla se ve en la pieza exacta en la que pasó, no perdido dentro de un bloque de 200 a la vez.

Mientras dura, la vista previa sigue abierta y su texto pasa a Construyendo 12/47… (el mismo progreso sale también en la barra de estado). Una pieza rechazada se anota y el barrido sigue con la siguiente, no para la tanda. Lo que sí la corta es un silencio del servidor —esa pieza no se reintenta, porque puede que ya esté hecha— o un rechazo de la tanda entera, como perder los derechos a mitad: lo hecho hasta ahí se queda y el resto sale en el panel como no hecho (ver Mensajes de la tanda entera).

Con los #id nuevos ya en la mano, la vista previa se cierra y la configuración de todo lo tocado (lo modificado, lo nuevo y lo movido) se guarda igual de despacio, un wired detrás de otro —también tras un corte, con lo que llegó a colocarse—; al terminar, el editor recarga y enseña los resultados.

Si alguna fila sale con ✗ o ⚠, tu texto no se pierde: la recarga enseña la sala como quedó y bajo la barra sale, en ámbar, «Parte de tu texto no se aplicó» con el botón Recuperar lo no aplicado (ver Si sales de la sala o algo falla). Si la tanda llegó a crear bloques nuevos, o pudo crearlos, sale además en ámbar «Ya se crearon bloques nuevos: aplicarlo tal cual los compraría otra vez»: en el texto recuperado siguen sin #id, así que ponles el que tienen en la sala o sigue sobre el texto recargado (quitarlos no sirve: Aplicar los recogería).

Cuando una fila no se puede hacerCopiar enlace

El motivo sale en la fila en vez del precio, y Aplicar queda deshabilitado: basta con que haya un solo rechazo para que la tanda entera no se pueda confirmar. Hay que quitar o cambiar ese bloque y volver a pedir la vista previa. Un rechazo que no pertenece a ninguna compra (una recogida imposible, por ejemplo) sale como una fila ⚠ suelta al final del panel.

Y en esas filas ⚠ sueltas caben también avisos que no bloquean, que son información y no un no:

Las recogidas del panel son las que el servidor dice que haría de verdad, no las que pediste: por eso un #id que ya no está en la sala no sale como fila de recogida sino como el aviso de arriba.

Los que decide el editor de wireds al validar la tanda:

Un movimiento falla por estos mismos tres motivos de casilla: la del destino puede no existir, no ser suelo o estar ya en el tope de 80 — exactamente igual que si estuvieras colocando ahí un furni nuevo.

Y los de la compra, los mismos que aplica el aplicador de W-Presets (llegan tal cual, sin acentos):

La vista previa mira tu saldo: si lo que compra la tanda cuesta más créditos de los que tienes, sale la fila ⚠ suelta no tienes créditos suficientes: la tanda cuesta X créditos y tienes Y y Aplicar queda apagado mientras sea así. Aun así, cada pieza se vuelve a comprobar justo antes de hacerse: si algo cambia entre la vista previa y la ejecución (gastas créditos en otra cosa, la oferta cambia, la sala se llena por otro camino), su fila sale en el panel de resultados con el motivo exacto que dio el servidor —una compra que ya no puedes pagar, con no se pudo comprar (saldo o disponibilidad)—; solo cae en no se pudo comprar o colocar cuando no dio ninguno. Lo que ya se colocó se queda: no es todo o nada.

Un movimiento también se vuelve a comprobar antes de hacerse: si la casilla destino cambió desde la vista previa (alguien apiló algo hasta el tope, por ejemplo), la fila sale con ese motivo y el resto de la tanda sigue adelante. no se pudo mover a (x,y) solo sale si la casilla cambia en ese mismo instante.

Un caso se pinta aparte, en ámbar y con ⚠ en vez de ✗:

Mensajes de la tanda enteraCopiar enlace

Cuando el servidor rechaza la petición completa, la fila del panel lleva su texto:

PermisosCopiar enlace

Crear, mover y recoger piden más que editar un bloque con #id. Los permisos comunes a las tres son: derechos de decoración en la sala (ser su dueño, estar en su lista de derechos, ser administrador de su grupo o, si el grupo lo permite, miembro; también el staff con control de salas), permiso para modificar los wireds y que la sala no esté en venta ni bloqueada por el staff. Solo comprar exige, además, no tener activado el modo de prueba (Enable playtesting mode, en tus preferencias de las herramientas de creador). «Coloca más» y los W-Presets piden lo mismo para comprar, salvo el permiso para modificar los wireds.

Sin el permiso que toque, ese cambio no se aplica. Si falta uno de los comunes, el servidor rechaza la tanda entera con su mensaje (ver Mensajes de la tanda entera). Una recogida sin ser tuya sale como la fila suelta #N no es tuyo (la de un cofre, como #N: Solo el dueño de la sala puede recoger los cofres.), y una caja permanente sin confirmar como #N guarda valores permanentes: confírmalo en la vista previa — todas con Aplicar apagado (ver Cuando una fila no se puede hacer).

Lo que no se puede hacerCopiar enlace

Y un caso que no es una limitación sino una salvaguarda: una pieza que el editor no sabe leer, una nueva del servidor que todavía no conoce, sale como comentario y no se toca, igual que un Dar Premio que no puedes ver sin permiso de Super Wired. No cuenta como borrado aunque no haya bloque suyo en el texto, y si mueves o borras la pila en la que está, se queda en su casilla.