Cinco bugs de complementos do Bedrock que falham sem dar erro

Os piores bugs de um complemento do Bedrock não são os que fecham o jogo. São os que deixam o jogo seguir como se nada tivesse acontecido: nenhum erro na tela, nenhum fechamento, só uma criatura que ficou invisível ou um recurso que parou de funcionar calado. Aqui estão cinco que encontrei fazendo o LLS Equestrian e o Magic Pack, como cada um aparecia e como eu pego eles agora.

Se você é jogador e não faz mods, guarde só isto: quando um complemento se comporta estranho, ative o registro de conteúdo (Configurações → Criador). Cada um destes deixa um rastro lá, e em nenhum outro lugar. Tem um guia para ler o registro.

1. math.max com três argumentos deixa a criatura inteira invisível

O que aconteceu: depois de adicionar uma animação de pulo nova, todos os cavalos do mundo ficaram invisíveis. O ovo gerador do cavalo também. Todos os itens do mesmo pacote continuavam aparecendo normal.

A causa: uma linha de animação usava math.max(a, b, c). As funções matemáticas do Molang aceitam um número fixo de argumentos: math.max aceita exatamente dois. Com três, o Bedrock registra “Unexpected number of parameters… expected 2, found 3” e joga fora a entidade inteira do cliente: o modelo, as texturas, as animações e, junto, o ícone do ovo.

Por que passou batido: eu faço as animações com um script, e ele mostra a prévia traduzindo o Molang para JavaScript. O Math.max do JavaScript aceita qualquer quantidade de argumentos, então a prévia rodava perfeita.

A correção: aninhar as chamadas, math.max(math.max(a, b), c). O script de build agora confere a quantidade de argumentos de toda chamada de função do Molang antes de escrever qualquer coisa.

2. Ler uma variável antes de definir para tudo o que vem depois

O que aconteceu: alguns cavalos apareciam rosa, outros invisíveis, e o jogo ficava muito lento. O registro de conteúdo mostrava milhares de erros de “unknown variable” por segundo.

A causa: no script pre_animation de uma entidade, uma linha lia uma variável que só era definida mais abaixo. No Bedrock, ler uma variável não definida não dá zero: dá um erro que para o resto do script, em todo quadro. Então nenhuma variável depois daquela linha era definida, inclusive a que escolhe a textura da pelagem. Sem índice de textura, aparecia a cor rosa de “textura faltando”.

Por que passou batido: em JavaScript um valor faltando é só undefined. E um teste pulou aquela linha, porque ela estava atrás de uma condição (o cavalo deitado) que o teste nunca atingiu.

A correção: toda variável lida acima da linha que define ela precisa de um valor inicial em initialize. O build agora confere isso de forma estática: ele percorre as linhas na ordem em que o jogo roda (initialize, depois pre_animation, depois as animações) e se recusa a montar se algo é lido antes de ser escrito.

Dica: quando aparecer uma enxurrada de erros de “unknown variable”, procure a variável que é definida primeiro no script. A linha quebrada está logo acima.

3. modified_distance_moved não é em blocos

O que aconteceu: nas prévias, o passo e o trote pareciam certos. No jogo, as pernas iam como máquina de costura. Contei seis balançadas de cabeça para cada uma ou duas de um cavalo de verdade. Toda mudança de “deixa mais lento” que eu tentava estragava as prévias e quase não mexia no jogo.

A causa: a passada era medida por q.modified_distance_moved, como se ele contasse blocos andados. Não conta. É o contador de balanço dos membros do jogo normal: ele corre a mais ou menos quatro vezes a distância andada e tem um limite de 20 por segundo, que ele atinge a uns cinco blocos por segundo. Então o passo e o trote iam quatro vezes rápido demais, e o meio galope e o galope mais ou menos o dobro (por causa do limite).

Por que passou batido: as prévias davam para a animação a velocidade real, não o que o jogo informa de verdade. A prévia e o jogo discordavam calados.

A correção: medir a animação presa à passada com q.ground_speed, que é de verdade blocos por segundo. A lição maior: uma prévia fora do jogo precisa simular os números do jogo do jeito que o jogo produz, escalas estranhas incluídas, ou ela vai parecer certa enquanto o jogo parece errado.

4. Remover um grupo de componentes apaga coisas que ele não adicionou

O que aconteceu: cavalos que nunca tinham usado um arreio de trabalho perdiam o pulo depois de deitar, rolar ou serem escovados. Sair e entrar de novo no mundo resolvia.

A causa: num arquivo de entidade do Bedrock, os grupos de componentes são adicionados um por cima do outro, mas remover um apaga todo componente que ele cita, direto. Não volta para a versão dos componentes base, nem para a de outro grupo ainda ativo.

A lista de remoção do evento “deitar” incluía o grupo do arreio de trabalho “só por garantia”. Esse grupo coloca a força do pulo em zero, então ele cita o componente de pulo. Remover o grupo removia o pulo do cavalo, tivesse ele usado o arreio alguma vez ou não. Entrar de novo resolvia só porque um script aplica de novo a força do pulo ao carregar.

A correção:

• Manter cada componente compartilhado em um grupo só de cada vez.
• Trocar de grupo em um evento só: remover o antigo e adicionar o novo juntos.
• Nunca colocar um grupo numa lista de remoção “só por garantia”. Remover um grupo que a criatura não tem continua apagando os componentes que ele cita.

5. Uma atualização que você não fez quebra um pacote que você não mexeu

O que aconteceu: o Magic Pack estava pronto e funcionando. Alguns dias depois o cajado de gelo parou de acertar qualquer coisa, as verificações de cura sempre falhavam e o empurrão parou de funcionar de vez. Ninguém tinha mudado uma linha do código dele.

A causa: o Magic Pack sai como um pacote combinado montado com vários mods, e o pacote combinado roda todos os scripts deles sob uma versão só da API de scripts do Bedrock, a mais alta que qualquer um deles pede. Quando outro mod do conjunto passou para a versão 2.x, o código de magia mais antigo começou a rodar sob a 2.x também. Duas coisas mudaram na 2.0:

• isValid deixou de ser um método e virou uma propriedade. Chamar entity.isValid() agora dá “not a function”.
• applyKnockback(dirX, dirZ, strength, up) mudou de formato para applyKnockback({ x, z }, up). O formato antigo dá erro.

As duas chamadas estavam dentro de try/catch, então em vez de o jogo fechar, os recursos só pararam. O registro tinha 170.000 linhas de “not a function” só do cajado de gelo.

A correção: um arquivinho de compatibilidade com funções auxiliares alive() e knockback() que funcionam nas duas versões. E uma regra: depois de subir a versão de scripts de qualquer coisa num conjunto, procurar not a function no registro de conteúdo, e .isValid() e applyKnockback( no código mais antigo.

O padrão

Os cinco têm o mesmo formato: alguma coisa que confere o meu trabalho concordou comigo, e o jogo não. Uma prévia em JavaScript, um teste que pulou um caminho, um try/catch que engoliu um erro. O que pega eles:

1. Ler o registro de conteúdo depois de toda mudança, não só quando algo quebra.
2. Fazer as prévias e os testes se comportarem como o jogo, inclusive nas partes rígidas e estranhas dele.
3. Conferir de forma estática o que der. A quantidade de argumentos e ler antes de definir agora são pegos antes de um único arquivo ser escrito.

Os cavalos em que tudo isso foi parar estão no LLS Equestrian, e os cajados no Magic Pack. Os dois são downloads grátis para o Bedrock.