Guides / Building & Resources

Um pacote de skins Bedrock tem quatro arquivos, e dois de seus modos de falha são silenciosos

Dois UUIDs que devem ser diferentes, um arquivo de idioma que não é opcional e chaves de skin que removem pontuação — assim, 'Minha Skin!' e 'Minha Skin?' se tornam uma única skin sem 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 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 e mais sutil consequência: 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 requer um novo download, em vez de um re-zip do antigo.

O arquivo de idioma 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 de idioma 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 pontuação, e duplicatas são colapsadas

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

seu nomechave
My Skin!MySkin
My Skin?MySkin
Skin #2Skin2
!!!Skin1 (fallback, por posição)

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 em uma única skin no jogo. Você envia doze skins, recebe onze, e nada lhe diz qual delas desapareceu.

O construtor aqui se defende disso anexando um contador a qualquer chave que já tenha usado, então o segundo MySkin se torna MySkin1. Vale a pena saber se você montar 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 robustos de Steve. A textura está boa; o modelo é o que está sendo solicitado. O construtor do pacote infere isso amostrando a quarta coluna do braço, mas um skins.json escrito à mão precisa dizer 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 da mesma entrada — a capa viaja dentro do pacote de skins, em vez de ser um download separado.

Criador de pacotes de skins →

More guides

Browse all →

Procurando mais ferramentas de Minecraft?

Um conjunto de geradores, visualizadores e conversores que rodam no navegador — tudo grátis.