O Bedrock não tem pacote de capa independente — a capa só vem junto com uma skin
Não existe um formato .mcpack só de capas. Toda capa precisa estar vinculada a uma entrada de skin que a nomeie, e é por isso que um pacote de capas é, na verdade, um pacote de skins com um PNG extra por entrada.
No Java, a capa é uma coisa separada da skin. No Bedrock, não: não existe um formato de pacote de capas. A capa é um campo de uma entrada de skin, então distribuir uma capa significa distribuir uma skin que a usa.
O que isso impõe
Um pacote de capas é um pacote de skins cujas entradas nomeiam, cada uma, uma textura de capa. O manifest, o skins.json e o arquivo de idioma são idênticos aos de qualquer outro pacote de skins — a única diferença é uma chave extra por entrada e um PNG extra no zip.
As consequências são estruturais, não cosméticas:
- Você não pode distribuir uma capa sozinha. Toda capa precisa de uma skin à qual se vincular, mesmo que seja uma skin com a qual você não se importa.
- A capa não é selecionável de forma independente no jogo. Escolher a capa significa escolher a entrada de skin à qual ela pertence. Duas capas em uma mesma skin não é algo que dá para expressar.
- N skins × M capas são N × M entradas, não N + M. Oferecer três capas em quatro skins significa doze entradas no pacote, cada uma com sua própria chave, seu próprio nome no arquivo de idioma e seu próprio par de PNGs.
Esse último ponto é o que dói quando um pacote cresce. Pacotes de capas ficam grandes rápido, e o tamanho é multiplicativo, não aditivo.
As duas texturas têm tamanhos diferentes
Uma skin é 64 × 64 (ou 64 × 32 no formato legado). Uma capa é 64 × 32, sempre. Elas não são intercambiáveis. O construtor rejeita uma skin 64 × 64 colocada no espaço da capa, mas o contrário passa batido: uma capa 64 × 32 colocada no espaço da skin é lida como skin legada, então não misture as duas.
Dentro desse arquivo de capa 64 × 32, a face visível é o bloco de 10 × 16 em (1, 1) — todo o resto é a parte de trás, as bordas e o preenchimento. A prévia aqui recorta exatamente esse retângulo ao mostrar qual capa é qual, porque, em tamanho de miniatura, o preenchimento ao redor é a maior parte da imagem e não diz nada.
Slim e classic continuam valendo
Cada entrada carrega seu próprio modelo, deduzido da mesma forma que em um pacote de skins comum — a partir das duas colunas que um braço slim deixa vazias (x 54–55, y 20–31) — e cada entrada tem um botão Classic/Slim para as skins em que essa dedução erra, como uma skin classic que quase não pinta essas colunas. Então um pacote de capas também precisa acertar a escolha slim/classic por entrada — a capa não muda como os braços são lidos, e um modelo errado aqui aparece exatamente como em qualquer outro lugar: uma skin Alex com os braços do Steve, vestindo a capa certa.
Na prática
Se o seu objetivo é realmente "dar essa capa para as pessoas", o pacote é um meio de entrega, não o produto. Combine-a com a skin mais simples que fizer sentido, nomeie a entrada com o nome da capa em vez do da skin e aceite que o jogador que a escolher está escolhendo as duas coisas.
Se o seu objetivo é um conjunto de visuais combinados — uma skin e uma capa criadas juntas —, então o modelo do Bedrock é justamente o certo, e o pareamento que parece uma limitação é, na verdade, o recurso.