Um pacote de skins para Bedrock é feito de quatro arquivos, e dois de seus modos de falha são silenciosos
Dois UUIDs que precisam ser diferentes, um arquivo lang que não é opcional e chaves de skin que removem a pontuação — então 'My Skin!' e 'My Skin?' viram uma única skin sem nenhum erro.
Um .mcpack é um zip com uma extensão diferente, e um pacote de skins dentro dele precisa de exatamente quatro tipos de arquivo:
manifest.json a header and a skin_pack module, each with its own UUID
skins.json one entry per skin: texture, geometry, and a KEY
texts/en_US.lang the display names — skins.json holds only keys
*.png the textures themselves
Três dos quatro são fáceis de acertar. As falhas interessantes vêm todas da relação entre eles.
Os dois UUIDs precisam ser diferentes
O manifest.json carrega um UUID em seu header e outro em seu módulo skin_pack:
{
"format_version": 1,
"header": { "name": "…", "uuid": "…", "version": [1, 0, 0] },
"modules": [ { "type": "skin_pack", "uuid": "…", "version": [1, 0, 0] } ]
}
São duas identidades distintas — o pacote e o que está dentro dele — e reutilizar um mesmo valor para ambos é um erro de verdade, mesmo que nada reclame na hora de compilar.
Há uma segunda consequência mais sutil: uma reimportação com os mesmos UUIDs é tratada como o mesmo pacote, e o Minecraft silenciosamente mantém a cópia que já tem. Editar um pacote, recompilá-lo com os mesmos identificadores e reimportá-lo dá a impressão de que nada aconteceu. É exatamente por isso que toda compilação gerada nesta página recebe UUIDs novos — e também por isso que reimportar um pacote editado exige um download novo, e não apenas recompactar o antigo em zip.
O arquivo lang não é opcional
O skins.json nunca contém um nome de exibição. Ele contém uma chave, e o texts/en_US.lang mapeia essa chave para um texto:
skinpack.<PackKey>=My Pack
skin.<PackKey>.<SkinKey>=My First Skin
Distribua o pacote sem o arquivo lang e nada dará erro — cada skin simplesmente aparece no jogo com sua chave bruta. Esse é o motivo mais comum de um pacote montado à mão parecer quebrado mesmo passando na validação.
As chaves removem a pontuação, e duplicatas se fundem
Uma chave precisa ser alfanumérica. Todo o resto é removido:
| seu nome | chave |
|---|---|
My Skin! | MySkin |
My Skin? | MySkin |
Skin #2 | Skin2 |
!!! | Skin1 (fallback, pela posição) |
As duas primeiras linhas são a armadilha. Duas skins com nomes bem distintos para um humano viram uma única chave, e uma chave duplicada não gera erro — ela silenciosamente se funde em uma só skin no jogo. Você envia doze skins, recebe onze, e nada lhe diz qual delas sumiu.
O gerador desta página se protege disso acrescentando um contador a qualquer chave que já tenha usado, de modo que a segunda MySkin vira MySkin2. Vale a pena saber disso se você monta um pacote à mão: a verificação necessária é feita sobre os nomes sem a pontuação, não sobre os que você digitou.
Um nome que é só pontuação não deixa nada, então ele cai no Skin mais sua posição na lista.
Slim precisa da string de geometria correta
Cada entrada nomeia um modelo, e existem dois:
geometry.humanoid.custom— clássico, braços de 4 pixelsgeometry.humanoid.customSlim— slim, braços de 3 pixels
Errar isso é a causa habitual de uma skin com proporções de Alex aparecer com os braços quadrados do Steve. A textura está certa; o modelo é que é o solicitado. O gerador de pacotes deduz o modelo a partir das duas colunas que um braço slim deixa vazias (x 54–55) e permite corrigir por entrada, mas um skins.json escrito à mão precisa declarar isso explicitamente, e as duas strings diferem em quatro caracteres no final.
As entradas também carregam "type": "free", e uma capa é um PNG extra opcional referenciado na mesma entrada — a capa viaja dentro do pacote de skins, e não como um download separado.