基岩版没有独立的披风包——披风只能附着在皮肤上
基岩版没有单独的 .mcpack 披风格式。每个披风都必须与一个指定了它的皮肤条目配对，这就是为什么披风包实际上是一个皮肤包，只是每个条目多了一个 PNG 文件。
在 Java 版中，披风与皮肤是分开的。但在基岩版中并非如此：没有披风包格式。披风是皮肤条目中的一个字段，因此分发披风意味着分发一个穿着它的皮肤。
这带来了什么限制
披风包是一个皮肤包，其每个条目都指定了一个披风纹理。清单文件、skins.json 和语言文件与任何其他皮肤包都相同——唯一的区别是每个条目多了一个键，并且 zip 文件中多了一个 PNG 文件。
这些后果是结构性的，而非外观上的：
- 你不能单独发布披风。 每个披风都需要一个皮肤来附着，即使你并不关心这个皮肤。
- 披风在游戏中不能独立选择。 选择披风意味着选择它所属的皮肤条目。一个皮肤上带两个披风是无法实现的。
- N 个皮肤 × M 个披风等于 N × M 个条目，而不是 N + M。如果想为四款皮肤提供三款披风，这意味着包中将有十二个条目，每个条目都有自己的键、在语言文件中有自己的名称，以及自己的一对 PNG 文件。
当包体量增大时，最后一点会变得很麻烦。披风包会迅速变大，而且大小是乘法关系而非加法关系。
两种纹理尺寸不同
皮肤是 64 × 64（或旧版 64 × 32）。披风始终是 64 × 32。它们不可互换，构建器会拒绝尺寸为披风大小的皮肤，反之亦然。
在 64 × 32 的披风文件中，可见面是位于 (1, 1) 的 10 × 16 像素块——其余部分是背面、边缘和填充。这里的预览图在显示哪个披风是哪个时，会精确裁剪到这个矩形，因为在缩略图大小下，周围的填充占据了图像的大部分，无法提供任何信息。
纤细和经典模型仍然适用
每个条目都带有自己的模型，检测方式与普通皮肤包相同，都是根据皮肤的第四个手臂列来判断。因此，披风包也必须为每个条目正确处理纤细/经典模型的呼唤——披风不会改变手臂的读取方式，如果模型错误，其表现与在其他任何地方一样：一个 Alex 皮肤却有着 Steve 的手臂，但穿着正确的披风。
实际形式
如果你的目标真的是“把这个披风给人们”，那么披风包是一种交付机制，而不是产品本身。将它与最简单的皮肤配对，用披风的名称而不是皮肤的名称来命名条目，并接受玩家选择它时是同时选择了两者。
如果你的目标是一套搭配好的外观——一个皮肤和一个披风是共同设计的——那么基岩版的模型实际上是正确的，这种看似限制的配对反而成了特色。