MC Toolkit

Guias / Construção e recursos

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 nomechave
My Skin!MySkin
My Skin?MySkin
Skin #2Skin2
!!!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 pixels
  • geometry.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.

Criador de pacotes de skins →

Mais guias

Ver todos →