Crear, borrar y mover

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

En el texto	Qué pasa al aplicar
Un bloque o una línea furni sin #id	Se compra ese furni y se coloca en su stack (x, y) con su rot (o 0); si lleva z, la altura se ajusta justo después de colocarlo
Un #id (de wired o de furni normal) que está en la sala pero ya no en el texto	Se recoge al inventario, como :pickall/recogerlo con el ratón
Un #id bajo una stack (x, y) distinta de la que trae de la sala	Se mueve a esa baldosa
Una línea furni con #id y z distinto del que trae	Se cambia su altura, como :setz
Una línea furni con #id y rot distinto del que trae	Se rota
Un bloque con #id y algo cambiado	Se guarda, como siempre

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 #id

Crear solo exige derechos en la sala (ver Permisos) — 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: el furni que se compra es el classname que ves en la referencia y en el hover del selector para ese familia.nombre.
• La baldosa es la del stack (x, y) que lo contiene. La altura no se elige: cada pieza se apoya encima de lo que ya haya en su casilla, 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.
• La rotación de un bloque nuevo es siempre 0 (la primera posición que admite el furni).

En el margen izquierdo del editor, los bloques nuevos 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 (ℹ), no errores: no bloquean.

Qué puede referenciar un bloque nuevo

• ✅ 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 sala

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

Mensaje	Cuándo
nombre de variable repetido 'a': ya lo declara el bloque de la línea L	Dos cajas de variable del documento (nuevas, o con #id y el campo name cambiado) declaran el mismo nombre. Sale en la segunda
nombre de variable repetido 'a': ya lo usa #N en la sala	Una caja del documento (nueva, o renombrada) declara un nombre que ya tiene, con otra id, una variable que ya está en la sala

Declara cada variable una sola vez para toda la sala

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 tipo

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 Conector de texto (extra.var_text_connector) que deba aplicarse a una sola variable: esa caja va sola, en su propia pila, junto con su conector.

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 X

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 copiar

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_antenna1" 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ón

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 usarla

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ínea

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 el mismo :pickall/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»).

Es exactamente lo mismo que recogerlo con el ratón, con lo que eso implica:

• El furni vuelve a su dueño, que puede no ser quien está aplicando. Si está conectado, le aparece en el inventario en el momento.
• Las referencias que otros wireds tuvieran a él se limpian solas, como en cualquier recogida.
• Solo puedes recogerlo si es tuyo, o si puedes gestionar el furni del grupo de la sala (su dueño, staff con control de salas, o administrador del grupo) — la misma condición que con el ratón (ver Permisos). Si no, el bloque se queda tal cual: la vista previa saca la fila suelta #N no es tuyo y Aplicar queda apagado.

Borrar el bloque no es lo mismo que dejarlo vacío

condition.has_furni_on #48213 { } sigue siendo el wired, con todos sus campos a su valor por defecto. Para que desaparezca hay que quitar el bloque entero.

Recoger una caja de variable permanente o compartida

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 mismo respiro por fase de siempre (ver La vista previa)— y esta vez la trae ya confirmada.

No hay vuelta atrás

Borrar los valores de una variable permanente o compartida afecta a todo el hotel, no solo a quien aplica: si cien usuarios tenían puntos guardados en esa caja, los cien los pierden. Revisa los #id que lista la casilla antes de marcarla.

Mover: cambiar la casilla

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.

• Mover solo exige derechos en la sala (ver Permisos), como 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) sigue la misma regla que al crear: 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 con el ratón.
• 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, wired o normal — mover a otra sala queda fuera (ver Qué no hace).

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 (ℹ), 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 normales

Una línea furni (ver Sintaxis) no es un wired —no tiene familia ni ventana propia—, pero se edita igual que con el ratón: recoger, mover, subir/bajar o rotar un furni normal por texto hace exactamente lo mismo que :pickall, arrastrarlo, :setz o rotarlo a mano.

En el texto	Qué pasa al aplicar
Una línea furni con #id, sin cambios	Es el furni real de la sala: no pasa nada, solo sirve para referenciarlo
Una línea furni sin #id	Se compra y se coloca en su stack (x, y) con su rot (o 0), igual que un wired nuevo. Si lleva z, la altura se ajusta justo después de colocarlo
Quitar del texto una línea furni con #id	Se recoge al inventario, como :pickall
Cambiar de pila una línea furni con #id	Se mueve a esa baldosa, como arrastrarlo
Cambiar el z de una línea furni con #id	Cambia su altura, como :setz
Cambiar el rot de una línea furni con #id	Se rota. rot es el índice de posición (0, 1, 2…) que ves en el infostand; uno que el furni no tenga se rechaza con la rotación N no existe en este furni (0 a M)

• 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 pide altura libre igual que :setz, y con su mismo rango: de -4000 a 8000, o sea de -40 (hundido bajo el suelo) a 80 (el tope de apilado de la sala).
• Los cambios de altura y rotación de furnis normales cuentan en la misma pastilla ↔ N movidos que los movimientos de casilla (el texto pasa a «N movidos/alturas» si hay de las dos cosas), y en la vista previa salen como su propia fila ↕ N alturas, con el detalle #id etiqueta z 250 → 300 — 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.

Declara los furnis normales con z y rot explícitos

Regla práctica al escribir o generar un script, junto a las de organización de más abajo: 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.

Copiar un script a otra sala

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. Además de quitar el #id de las cabeceras, reescribe dentro de las listas [ … ] cada #id desconocido por la etiqueta del bloque al que pertenece, para que la referencia no se rompa. Todo lo que se queda sin #id pasa a tratarse como nuevo: se compra (si es un furni) o se compra y coloca (si es un wired), y las referencias por etiqueta se resuelven solas en cuanto se crea.

El botón puede salir deshabilitado, con el motivo debajo:

Motivo	Cuándo
#N no tiene etiqueta y otros bloques lo referencian	Un bloque con #id desconocido no tiene etiqueta, pero alguna lista lo referencia: sin etiqueta no hay por qué reescribir la referencia. Ponle una etiqueta al bloque
#N no está declarado en el documento	Un #id desconocido aparece dentro de una lista [ … ] pero no es ningún bloque del texto (por ejemplo, un furni de pared, que no se puede declarar)

En los dos casos hay que arreglarlo a mano: pon la etiqueta que falte o quita esa referencia de la lista.

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 previa

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 tile1 z 250 → 300

Los wireds nuevos reciben su #id al aplicar; hasta entonces se referencian por etiqueta.

                                  [ Cancelar ]  [ Aplicar · 45 créditos ]

• Cada fila de compra, recogida, movimiento o cambio de altura/rotación salta a su línea en el editor si la pulsas.
• Si alguna recogida borraría valores de variable permanente o compartida, justo debajo de las recogidas sale una fila propia con la casilla de confirmación — ver Recoger una caja de variable permanente o compartida.
• 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 mientras el panel está abierto.

Si confirmas: pieza a pieza

Al pulsar Aplicar, el servidor no ejecuta la tanda de golpe: la construye pieza a pieza, una operación por paquete, 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 (↕), uno por paquete, 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; un silencio del servidor sí la para —esa compra no se reintenta— y el editor recarga solo para que veas lo que quedó hecho.

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; al terminar, el editor recarga y enseña los resultados.

Si te sales de la sala a mitad de la construcción

La tanda se aborta en el cliente y sale cancelado: cambio de sala, pero eso es lo que hace el editor: el servidor no se entera y puede haber recogido y colocado los furnis igualmente. Lo que se pierde es la configuración, que viaja después con los #id nuevos — así que puedes encontrarte los wireds nuevos en la sala, comprados y en su sitio, pero en blanco. Vuelve a la sala, recarga y míralo antes de aplicar otra vez: si ya están puestos, lo que toca es rellenarlos, no volver a comprarlos.

Dos segundos por fase

El servidor tiene un respiro de 2 segundos por fase: uno para las vistas previas y otro para las construcciones reales. Si vas demasiado rápido, contesta «Espera un momento antes de volver a aplicar.». Una vista previa no te quema el respiro de la construcción.

Cuando una fila no se puede hacer

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:

Fila ⚠	Qué significa	¿Bloquea?
#N no se va a recoger: ya no está en la sala o no se puede recoger	Quitaste ese bloque o línea del texto, pero el servidor no va a recoger nada: ese #id ya no está en la sala, o es un furni que no se puede recoger (sin CanTakeItem, la misma condición que mira :pickall). Solo sale cuando el servidor no ha dado su propio motivo: si lo ha dado (el tablón de puntuación, por ejemplo), manda el suyo	No
#N no es tuyo	Quitaste del texto un bloque o línea que no es tuyo, ni puedes gestionar el furni del grupo de la sala: la misma condición que hace falta para recogerlo con el ratón (ver Permisos)	Sí
#N guarda valores permanentes: confírmalo en la vista previa	Ese #id es una caja variable.* con availability = permanent o permanent_shared: recogerla borra su definición y todos los valores guardados, de todo el mundo, sin vuelta atrás. Marca la casilla de confirmación que aparece con las recogidas y vuelve a pedir la vista previa (ver Recoger una caja de variable permanente o compartida)	Sí
sin respuesta del servidor para este bloque	El servidor no dijo ni sí ni no sobre esa compra. Su fila sale con ? en vez del precio, porque nadie ha dado uno	Sí
¿borraste el #N de este bloque? Se crearía uno nuevo y se recogería el existente	Hay una compra y una recogida en la misma casilla y del mismo familia.nombre: casi siempre es el mismo wired al que se le fue el #id por delante. Si lo aplicas tal cual, el furni estrena #id y pierde todo lo que no esté escrito en el texto	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:

Motivo	Qué significa
no existe ese furni	Ningún furni del hotel se llama así
solo se pueden crear furnis de suelo	Un furni con el classname de un furni de pared: no se compra. Los furnis de pared no se pueden declarar ni referenciar por #id
#N no está en la sala	Se pidió mover (o subir/rotar) un #id que ya no está en la sala, o que es un furni de pared
la casilla (x,y) no existe en la sala	Esa baldosa cae fuera de la rejilla del modelo
la casilla (x,y) no es suelo	La baldosa existe en la rejilla pero es un hueco del modelo (una x del mapa de alturas): ahí no se puede colocar nada
el furni ocupa la casilla (x,y), que no es suelo	El wired es más grande de 1x1 y, con esa rotación, alguna de las baldosas que ocuparía es un hueco
la pila de la casilla (x,y) pasa del tope de 80 de altura	Lo que ya hay apilado en esa baldosa llega al tope de altura: el wired no cabe encima

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.

Con :setz encendido no salen

Las tres últimas (no es suelo, el furni ocupa…, la pila…) no se aplican mientras tengas activo el modo de altura libre :setz, exactamente igual que al colocar (o mover) un furni a mano: en ese modo sí se puede plantar sobre un hueco del modelo y por encima del tope de 80.

| la sala está llena (máx N furnis) | Se llegó al tope de furnis de suelo. Las recogidas se descuentan antes, así que quitar cosas hace hueco | | índice repetido | Dos bloques nuevos con el mismo índice (no debería pasar; es una salvaguarda) | | índice no válido | Un bloque nuevo llegó con un índice negativo. Tampoco debería pasar: es una salvaguarda interna, y la fila sale suelta (⚠) porque no hay bloque al que engancharla | | #N se recoge en esta misma tanda | Ese #id está a la vez en las recogidas y en los movimientos: gana la recogida y el movimiento no se hace |

Y los que vienen del catálogo, los mismos cuatro que aplica «Coloca más» y el aplicador de W-Presets (llegan tal cual, sin acentos):

Motivo	Qué significa
no esta a la venta en el catalogo	Ese furni no tiene oferta de compra para ti
es un rare o tiene existencias limitadas	Un LTD o algo con contador de existencias: no se compra por este camino
cuesta X pixeles + Y specialcoins + Z esmeraldas ademas de creditos, y este flujo solo compra a creditos	Se paga con otra moneda además de créditos
su contenido lo pone el catalogo al comprarlo (placa, trofeo, grupo, disco...) y hay que comprarlo desde alli	Su contenido lo rellena el catálogo: hay que comprarlo desde allí
el furni base ya no existe en este hotel	El furni base desapareció

Si algo falla entre la vista previa y la ejecución (te quedas sin créditos, la oferta cambia, la sala se llena por otro camino), esa fila sale luego en el panel de resultados con el motivo exacto que dio el servidor —no se pudo comprar (saldo o disponibilidad), por ejemplo— y 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 tiene su propia versión de esa misma carrera: si la sala cambió entre la vista previa y la construcción real (alguien apiló algo en la casilla destino, por ejemplo), la fila cae en no se pudo mover a (x,y) y el resto de la tanda sigue adelante.

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

Mensaje	Qué significa
comprado pero no cabía en (x,y): está en tu inventario	La compra sí se hizo y el furni no cupo: lo tienes en el inventario. Solo puede pasar por una carrera (alguien apiló algo en esa baldosa entre la vista previa y el Aplicar)
comprado pero no se pudo colocar	La compra sí se hizo, pero el furni no se pudo colocar por algo que no era la casilla (un fallo al entregarlo). Aquí no se promete el inventario porque puede que no haya llegado a existir: si te ha pasado, avísanos

Mensajes de la tanda entera

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

Mensaje	Cuándo
En modo de prueba no se compra nada: quítalo para crear bloques nuevos.	La sala está en modo de prueba: puedes editar, mover y recoger, pero no comprar; desactívalo para aplicar bloques nuevos
No estás en una sala.	Se aplicó fuera de una sala
No puedes colocar furnis en esta sala ahora mismo.	Sin derechos, sala en venta o en modo prueba
No tienes permiso para modificar los wireds de esta sala.	Falta el permiso de wired
Espera un momento antes de volver a aplicar.	El respiro de 2 s de esa fase
Demasiados bloques nuevos de una vez. / Demasiadas recogidas de una vez. / Demasiados movimientos de una vez. / Demasiadas alturas de una vez. / Demasiados cambios de una vez (tope 2000).	Más de 2000 creaciones, recogidas, movimientos o alturas en una sola tanda (la sala sigue teniendo su propio tope de furnis)
Solo una operación por packet.	El servidor solo acepta una recogida, un movimiento o una creación por paquete. Solo lo verás con un cliente modificado: el editor siempre manda uno
Demasiado rápido.	Menos de 100 ms desde la última pieza construida. Solo lo verás con un cliente modificado o una conexión muy rara: el editor ya deja 150 ms entre piezas, y si le toca reintenta esa misma pieza una vez
el servidor rechazó la construcción	El servidor dijo que no sin dar motivo
Paquete malformado.	El servidor no pudo leer la petición entera (no debería pasar desde el editor: es una salvaguarda interna). No se toca nada
sin respuesta del servidor	La vista previa no contestó a tiempo. No se ha tocado nada: vuelve a pulsar y ya está
sin respuesta: puede que ya se haya construido; recargando…	La construcción real no contestó a tiempo. Aquí sí puede estar hecho — el servidor pudo comprar, colocar y recoger y ser la respuesta lo que se perdió —, así que el editor recarga solo. Mira lo que hay antes de volver a pulsar Aplicar, o comprarás los mismos wireds dos veces
sin respuesta del servidor para este bloque	El servidor no dijo ni que sí ni que no sobre esa creación
cancelado: cambio de sala	Saliste de la sala en mitad de la tanda
recogido al inventario	✓ Ese wired o furni se recogió (una fila por cada #id borrado)
no se recogió (el servidor no lo aceptó)	Ese #id se pidió recoger y el servidor no lo hizo. Su bloque ya no está en el texto, así que sin esta fila parecería recogido. Igual que en la vista previa, no sale si el servidor ya dio su propio motivo
↕ #id z 250 → 300	✓ Esa altura/rotación se guardó
↕ #id: motivo	✗ Esa altura/rotación se rechazó, con el motivo del servidor (por ejemplo, un #id que dejó de estar en la sala entre la vista previa y el Aplicar, o una z fuera de rango)

Permisos

Crear, mover y recoger piden más que editar un bloque con #id, y no todas piden lo mismo:

Acción	Quién puede
Editar un bloque con #id, sin moverlo	Lo de siempre: ver Editar y aplicar
Crear	Derechos en la sala (ni en venta ni en modo prueba) y permiso para modificar los wireds — los mismos que «Coloca más» y que aplicar un W-Preset
Mover	Lo mismo que crear. No hace falta que el wired o el furni sea tuyo — igual que arrastrarlo con el ratón
Cambiar altura o rotación de un furni	Lo mismo que mover. No hace falta que sea tuyo — igual que :setz/rotar con el ratón
Recoger	Lo mismo que crear, y además ser tú el dueño del furni, o poder gestionar el furni del grupo de la sala (su dueño, staff con control de salas, o administrador del grupo) — igual que recogerlo con el ratón
Recoger una caja variable.* permanente o compartida	Lo mismo que recoger, y además marcar en la vista previa la casilla «Entiendo que se borrarán los valores permanentes de estas variables»

Sin el permiso que toque, ese cambio no se aplica: una recogida sin ser tuya sale como la fila suelta #N no es tuyo, y una caja permanente sin confirmar como #N guarda valores permanentes: confírmalo en la vista previa — las dos con Aplicar apagado (ver Cuando una fila no se puede hacer).

Lo que no se puede hacer

Rotar un wired por texto	Los wireds no llevan rot en el DSL: los bloques nuevos salen siempre con rotación 0 y mover un bloque existente conserva la que ya tenía. Un furni sí se rota — ver Furnis normales
Duplicar repitiendo un #id	Es un error (el wired #N aparece dos veces). Para duplicar, quita el #id
Referenciar un bloque nuevo por su #id	Todavía no lo tiene: ponle una etiqueta y referéncialo por ella (ver Qué puede referenciar un bloque nuevo)
Construir en otra sala	El documento es siempre el de la sala en la que estás
Aplicar todo o nada	Si algo falla a mitad, lo anterior queda hecho

Y un caso que no es una limitación sino una salvaguarda: un wired cuyo i_type el editor no conoce sale como comentario y no se toca. No cuenta como borrado aunque no haya bloque suyo en el texto.