Guides / Building & Resources

Un paquete de skins de Bedrock son cuatro archivos, y dos de sus modos de fallo son silenciosos

Dos UUID que deben ser diferentes, un archivo de idioma que no es opcional, y claves de skin que eliminan la puntuación — así que '¡Mi Skin!' y '¿Mi Skin?' se convierten en una sola skin sin error.

2026-08-01

Un .mcpack es un archivo zip con una extensión diferente, y un paquete de skins dentro de él necesita exactamente cuatro tipos de archivos:

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

Tres de los cuatro son fáciles de hacer bien. Los fallos interesantes provienen de la relación entre ellos.

Los dos UUID deben ser diferentes

manifest.json lleva un UUID en su header y otro en su módulo skin_pack:

{
  "format_version": 1,
  "header":  { "name": "…", "uuid": "…", "version": [1, 0, 0] },
  "modules": [ { "type": "skin_pack", "uuid": "…", "version": [1, 0, 0] } ]
}

Son dos identidades separadas —el paquete y lo que hay dentro del paquete— y reutilizar un valor para ambos es un error real, aunque nada se queje en tiempo de compilación.

Hay una segunda consecuencia, más sutil: una reimportación con los mismos UUID se trata como el mismo paquete, y Minecraft mantiene silenciosamente la copia que ya tiene. Editar un paquete, reconstruirlo con los mismos identificadores y reimportarlo parece que no hizo nada. Cada compilación de esta página obtiene nuevos UUID por esa misma razón, que es también por lo que reimportar un paquete editado necesita una nueva descarga en lugar de volver a comprimir el antiguo.

El archivo de idioma no es opcional

skins.json nunca contiene un nombre de visualización. Contiene una clave, y texts/en_US.lang mapea esa clave a texto:

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

Si se envía el paquete sin el archivo de idioma, no hay errores — cada skin simplemente aparece en el juego bajo su clave original. Esta es la razón más común por la que un paquete ensamblado a mano parece roto mientras que se valida correctamente.

Las claves eliminan la puntuación, y los duplicados se colapsan

Una clave debe ser alfanumérica. Todo lo demás se elimina:

Las dos primeras filas son la trampa. Dos skins nombradas de forma distinta por un humano se convierten en una clave, y una clave duplicada no genera un error — simplemente se colapsa silenciosamente en una sola skin en el juego. Subes doce skins, obtienes once, y nada te dice cuál falta.

El constructor aquí se defiende de eso añadiendo un contador a cualquier clave que ya haya usado, así que el segundo MySkin se convierte en MySkin1. Vale la pena saberlo si ensamblas un paquete a mano: la comprobación que necesitas es sobre los nombres limpios, no los que escribiste.

Un nombre que es completamente puntuación no deja nada en absoluto, por lo que recurre a Skin más su posición en la lista.

Slim necesita la cadena de geometría correcta

Cada entrada nombra un modelo, y hay dos:

• geometry.humanoid.custom — clásico, brazos de 4 píxeles
• geometry.humanoid.customSlim — delgado (slim), brazos de 3 píxeles

Equivocarse en esto es la causa habitual de que una skin con proporciones de Alex aparezca con los brazos voluminosos de Steve. La textura está bien; el modelo es el que se solicita. El constructor del paquete lo infiere muestreando la cuarta columna del brazo, pero un skins.json escrito a mano tiene que decirlo explícitamente, y las dos cadenas difieren en cuatro caracteres al final.

Las entradas también llevan "type": "free", y una capa es un PNG extra opcional referenciado desde la misma entrada — la capa viaja dentro del paquete de skins en lugar de como una descarga separada.

Creador de packs de skins →