Guides / Construction et ressources
Bedrock n'a pas de pack de capes autonome — une cape n'est livrée qu'attachée à un skin
Il n'existe pas de format .mcpack contenant uniquement des capes. Chaque cape doit être associée à une entrée de skin qui la nomme, c'est pourquoi un pack de capes est en réalité un pack de skins avec un PNG supplémentaire par entrée.
Sur Java, une cape est une chose distincte d'un skin. Sur Bedrock, ce n'est pas le cas : il n'existe pas de format de pack de capes. Une cape est un champ d'une entrée de skin, donc distribuer une cape revient à distribuer un skin qui la porte.
Ce que cela impose
Un pack de capes est un pack de skins dont chaque entrée nomme une texture de cape. Le manifeste, le skins.json et le fichier de langue sont identiques à ceux de n'importe quel autre pack de skins — la seule différence est une clé supplémentaire par entrée et un PNG supplémentaire dans le zip.
Les conséquences sont structurelles, pas cosmétiques :
- Vous ne pouvez pas livrer une cape seule. Chaque cape a besoin d'un skin auquel s'accrocher, même si ce skin ne vous intéresse pas.
- Une cape n'est pas sélectionnable indépendamment en jeu. Choisir la cape signifie choisir l'entrée de skin à laquelle elle appartient. Deux capes sur un seul skin n'est pas quelque chose que l'on peut exprimer.
- N skins × M capes, c'est N × M entrées, pas N + M. Proposer trois capes sur quatre skins signifie douze entrées dans le pack, chacune avec sa propre clé, son propre nom dans le fichier de langue et sa propre paire de PNG.
Ce dernier point est celui qui fait mal quand un pack grossit. Les packs de capes deviennent vite volumineux, et la taille est multiplicative plutôt qu'additive.
Les deux textures sont de tailles différentes
Un skin fait 64 × 64 (ou 64 × 32 pour les anciens). Une cape fait 64 × 32, toujours. Elles ne sont pas interchangeables. Le constructeur rejette un skin 64 × 64 déposé dans l'emplacement de cape, mais l'inverse passe inaperçu : une cape 64 × 32 déposée dans l'emplacement de skin est lue comme un ancien skin, alors gardez vous-même les deux bien distinctes.
Dans ce fichier de cape 64 × 32, la face visible est le bloc de 10 × 16 en (1, 1) — tout le reste est le dos, les bords et le remplissage. L'aperçu ici recadre exactement sur ce rectangle lorsqu'il vous montre quelle cape est laquelle, car à la taille d'une vignette, le remplissage environnant constitue la majeure partie de l'image et ne vous apprend rien.
Fin et classique s'appliquent toujours
Chaque entrée porte son propre modèle, deviné de la même manière qu'un pack de skins ordinaire — à partir des deux colonnes qu'un bras fin laisse vides (x 54–55, y 20–31) — et chaque entrée dispose d'un bouton Classique/Fin pour les skins que cette déduction rate, comme un skin classique qui peint à peine ces colonnes. Un pack de capes doit donc aussi trancher fin/classique correctement pour chaque entrée — la cape ne change pas la façon dont les bras sont lus, et un mauvais modèle ici se manifeste exactement comme partout ailleurs : un skin Alex avec les bras de Steve, portant la bonne cape.
Forme pratique
Si votre objectif est vraiment de « donner cette cape aux gens », le pack est un mécanisme de livraison plutôt que le produit. Associez-la au skin le plus simple qui ait du sens, nommez l'entrée d'après la cape plutôt que d'après le skin, et acceptez qu'un joueur qui la choisit choisit les deux.
Si votre objectif est un ensemble de looks assortis — un skin et une cape conçus ensemble — alors le modèle de Bedrock est en fait le bon, et l'association qui ressemble à une limitation est la fonctionnalité.