Guias / Construção e recursos

Um pacote de skins para Bedrock tem quatro arquivos, e duas de suas falhas são silenciosas

Dois UUIDs que precisam ser diferentes, um arquivo de idioma obrigatório e chaves de skin que descartam a pontuação: assim, 'Minha Skin!' e 'Minha Skin?' viram a mesma skin sem mostrar erro.

2026-08-01

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 devem ser diferentes

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 separadas — o pacote e o item dentro do pacote — e reutilizar um valor para ambos é um erro real, embora nada reclame no momento da construção.

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á possui. Editar um pacote, reconstruí-lo com os mesmos identificadores e reimportá-lo parece não ter feito nada. Cada construção desta página obtém novos UUIDs exatamente por essa razão, que é também o motivo pelo qual reimportar um pacote editado exige um novo download, em vez de um re-zip do antigo.

O arquivo lang não é opcional

skins.json nunca contém um nome de exibição. Ele contém uma chave, e texts/en_US.lang mapeia essa chave para texto:

skinpack.<PackKey>=My Pack
skin.<PackKey>.<SkinKey>=My First Skin

Envie o pacote sem o arquivo lang e nada dará erro — cada skin simplesmente aparecerá no jogo sob sua chave bruta. Esta é a razão mais comum pela qual um pacote montado manualmente parece quebrado, embora seja validado corretamente.

As chaves removem a pontuação, e duplicatas entram em conflito

Uma chave deve ser alfanumérica. Todo o resto é removido:

As duas primeiras linhas são a armadilha. Duas skins nomeadas distintamente por um humano se tornam uma chave, e uma chave duplicada não gera erro — ela simplesmente se colapsa silenciosamente em uma única skin no jogo. Você envia doze skins, recebe onze, e nada lhe diz qual delas sumiu.

O construtor aqui se defende disso anexando um contador a qualquer chave que já tenha usado, então a segunda MySkin se torna MySkin1. Vale a pena saber se você monta um pacote manualmente: a verificação que você precisa é nos nomes removidos, não nos que você digitou.

Um nome que é inteiramente pontuação não deixa nada, então ele retorna para Skin mais sua posição na lista.

Slim precisa da string de geometria correta

Cada entrada nomeia um modelo, e há dois:

• geometry.humanoid.custom — clássico, braços de 4 pixels
• geometry.humanoid.customSlim — slim, braços de 3 pixels

Errar isso é a causa usual de uma skin com proporções de Alex aparecer com os braços largos do Steve. A textura está correta; o problema é o modelo solicitado. O criador do pacote infere o modelo analisando a quarta coluna do braço, mas um skins.json escrito à mão precisa declará-lo explicitamente, e as duas strings diferem por quatro caracteres no final.

As entradas também carregam "type": "free", e uma capa é um PNG extra opcional referenciado da mesma entrada — a capa viaja dentro do pacote de skins, em vez de ser um download separado.

Criador de pacotes de skins →