Cinco errores de complementos de Bedrock que fallan sin dar error

Los peores errores de un complemento de Bedrock no son los que hacen que el juego se cierre. Son los que dejan que el juego siga como si nada: ningún error en pantalla, ningún cierre, solo una criatura que se volvió invisible o una función que dejó de funcionar sin avisar. Aquí van cinco con los que me topé haciendo LLS Equestrian y el Magic Pack, cómo se veía cada uno y cómo los atrapo ahora.

Si eres jugador y no haces mods, quédate con esto: cuando un complemento se porta raro, activa el registro de contenido (Ajustes → Creador). Cada uno de estos deja un rastro ahí, y en ningún otro lado. Hay una guía para leerlo.

1. math.max con tres argumentos vuelve invisible a toda la criatura

Qué pasó: después de agregar una animación de salto nueva, todos los caballos del mundo se volvieron invisibles. El huevo generador del caballo también. Todos los objetos del mismo pack se seguían viendo bien.

La causa: una línea de animación usaba math.max(a, b, c). Las funciones matemáticas de Molang aceptan un número fijo de argumentos: math.max acepta exactamente dos. Con tres, Bedrock registra “Unexpected number of parameters… expected 2, found 3” y tira toda la entidad del cliente: el modelo, las texturas, las animaciones y, de paso, el ícono del huevo.

Por qué se me pasó: hago las animaciones con un script, y las previsualiza traduciendo el Molang a JavaScript. El Math.max de JavaScript acepta cualquier cantidad de argumentos, así que la vista previa funcionaba perfecto.

El arreglo: anidar las llamadas, math.max(math.max(a, b), c). El script de construcción ahora revisa el número de argumentos de cada llamada a una función de Molang antes de escribir nada.

2. Leer una variable antes de asignarla detiene todo lo que viene después

Qué pasó: algunos caballos se veían rosas, otros invisibles, y el juego iba muy lento. El registro de contenido mostraba miles de errores de “unknown variable” por segundo.

La causa: en el script pre_animation de una entidad, una línea leía una variable que solo se asignaba más abajo. En Bedrock, leer una variable sin asignar no te da cero: lanza un error que detiene el resto del script, en cada cuadro. Así que ninguna variable después de esa línea se asignaba nunca, incluida la que elige la textura del pelaje. Sin índice de textura, salía el color rosa de “textura faltante”.

Por qué se me pasó: en JavaScript un valor faltante solo es undefined. Y una prueba se saltó esa línea, porque estaba detrás de una condición (el caballo acostado) que la prueba nunca cumplió.

El arreglo: cualquier variable que se lea arriba de la línea que la asigna necesita un valor inicial en initialize. La construcción ahora lo revisa de forma estática: recorre las líneas en el orden en que las ejecuta el juego (initialize, luego pre_animation, luego las animaciones) y se niega a construir si algo se lee antes de escribirse.

Consejo: cuando veas una avalancha de errores de “unknown variable”, busca la variable que se asigna primero en el script. La línea rota está justo arriba.

3. modified_distance_moved no está en bloques

Qué pasó: en las vistas previas, el paso y el trote se veían bien. En el juego, las patas iban como máquina de coser. Conté seis cabeceos por cada uno o dos de un caballo real. Cada cambio de “hazlo más lento” que probé dejaba mal las vistas previas y casi no tocaba el juego.

La causa: la zancada se medía con q.modified_distance_moved, como si contara bloques recorridos. No lo hace. Es el contador de balanceo de extremidades del juego normal: corre a más o menos cuatro veces la distancia recorrida y tiene un tope de 20 por segundo, que alcanza a unos cinco bloques por segundo. Así que el paso y el trote iban cuatro veces demasiado rápido, y el medio galope y el galope más o menos el doble (por el tope).

Por qué se me pasó: las vistas previas le daban a la animación la velocidad real, no lo que el juego reporta de verdad. La vista previa y el juego no coincidían, sin decir nada.

El arreglo: medir la animación ligada a la zancada con q.ground_speed, que de verdad son bloques por segundo. La lección más grande: una vista previa fuera del juego tiene que simular los números del juego tal como el juego los produce, escalas raras incluidas, o se va a ver bien mientras el juego se ve mal.

4. Quitar un grupo de componentes borra cosas que ese grupo no agregó

Qué pasó: caballos que nunca se habían puesto un arnés de trabajo perdían el salto después de acostarse, revolcarse o ser cepillados. Salir y volver a entrar al mundo lo arreglaba.

La causa: en un archivo de entidad de Bedrock, los grupos de componentes se agregan uno encima de otro, pero quitar uno borra todos los componentes que nombra, sin más. No vuelve a la versión de los componentes base, ni a la de otro grupo que siga activo.

La lista de quitar del evento “acostarse” incluía el grupo del arnés de trabajo “por si acaso”. Ese grupo pone la fuerza del salto en cero, así que nombra el componente de salto. Quitarlo le quitaba el salto al caballo, se le hubiera puesto el arnés alguna vez o no. Volver a entrar lo arreglaba solo porque un script vuelve a aplicar la fuerza del salto al cargar.

El arreglo:

• Mantener cada componente compartido en un solo grupo a la vez.
• Cambiar de grupo en un solo evento: quitar el viejo y agregar el nuevo juntos.
• Nunca poner un grupo en una lista de quitar “por si acaso”. Quitar un grupo que la criatura no tiene igual borra los componentes que nombra.

5. Una actualización que no hiciste rompe un pack que no tocaste

Qué pasó: el Magic Pack estaba terminado y funcionando. Unos días después el báculo de escarcha dejó de pegarle a cualquier cosa, las revisiones de curación siempre fallaban y el empuje dejó de funcionar por completo. Nadie había cambiado una línea de su código.

La causa: el Magic Pack sale como un solo pack combinado hecho con varios mods, y el pack combinado corre todos sus scripts con una sola versión de la API de scripts de Bedrock, la más alta que pida cualquiera de ellos. Cuando otro mod del paquete pasó a la versión 2.x, el código de magia más viejo empezó a correr también con la 2.x. Dos cosas cambiaron en la 2.0:

• isValid pasó de ser un método a ser una propiedad. Llamar a entity.isValid() ahora lanza “not a function”.
• applyKnockback(dirX, dirZ, strength, up) cambió de forma a applyKnockback({ x, z }, up). La forma vieja lanza un error.

Las dos llamadas estaban envueltas en try/catch, así que en vez de cerrarse el juego, las funciones simplemente se detuvieron. El registro tenía 170,000 líneas de “not a function” solo del báculo de escarcha.

El arreglo: un pequeño archivo de compatibilidad con funciones auxiliares alive() y knockback() que funcionan con las dos versiones. Y una regla: después de subir la versión de scripts de cualquier cosa en un paquete, buscar not a function en el registro de contenido, y .isValid() y applyKnockback( en el código más viejo.

El patrón

Los cinco tienen la misma forma: algo que revisa mi trabajo estuvo de acuerdo conmigo, y el juego no. Una vista previa en JavaScript, una prueba que se saltó una rama, un try/catch que se tragó un error. Lo que los atrapa:

1. Leer el registro de contenido después de cada cambio, no solo cuando algo se rompe.
2. Hacer que las vistas previas y las pruebas se comporten como el juego, incluidas sus partes estrictas y raras.
3. Revisar de forma estática lo que se pueda. El número de argumentos y leer antes de asignar ya se atrapan antes de escribir un solo archivo.

Los caballos en los que terminó todo esto están en LLS Equestrian, y los báculos en el Magic Pack. Los dos son descargas gratis para Bedrock.