Bedrockには単体のケープパックが存在しない — ケープはスキンに付属してのみ配布される
ケープ専用の.mcpack形式は存在しません。すべてのケープはそれを指定するスキンエントリと対にする必要があり、だからこそケープパックは実質的に、エントリごとにPNGを1枚追加したスキンパックなのです。
Javaではケープはスキンとは別のものです。Bedrockではそうではありません: ケープパックという形式は存在しません。ケープはスキンエントリのフィールドの一つであり、ケープを配布するということは、それを身に着けたスキンを配布するということです。
そこから強いられること
ケープパックとは、各エントリがケープテクスチャを指定するスキンパックです。マニフェスト、skins.json、langファイルは他のどのスキンパックとも同一で、唯一の違いはエントリごとにキーが1つ増えることと、zip内にPNGが1枚増えることだけです。
その帰結は見た目の話ではなく、構造上のものです:
- ケープを単体で配布することはできません。 すべてのケープは、たとえどうでもよいスキンであっても、ぶら下がる先のスキンを必要とします。
- ケープはゲーム内で独立して選択できません。 ケープを選ぶということは、それが属するスキンエントリを選ぶということです。1つのスキンに2つのケープ、という表現はできません。
- N個のスキン × M個のケープは、N + MではなくN × M個のエントリになります。 4つのスキンに対して3つのケープを提供するなら、パック内のエントリは12個で、それぞれに独自のキー、langファイル内の独自の名前、そして独自のPNGのペアが必要です。
最後の点は、パックが大きくなると効いてきます。ケープパックはあっという間に肥大化し、そのサイズは加算ではなく乗算で増えていきます。
2つのテクスチャはサイズが異なる
スキンは64 × 64(またはレガシーの64 × 32)です。ケープは常に64 × 32です。両者は互換できません。ビルダーはケープスロットに64 × 64のスキンを入れても拒否しますが、逆はすり抜けます: スキンスロットに64 × 32のケープを入れるとレガシースキンとして読み込まれるので、この2つは自分できちんと区別してください。
その64 × 32のケープファイルの中で、見える面は(1, 1)にある10 × 16のブロックです — それ以外はすべて背面、側面、そして余白です。ここでのプレビューがどのケープがどれかを示すときに正確にその矩形へ切り出すのは、サムネイルサイズでは周囲の余白が画像の大部分を占め、何も教えてくれないからです。
スリムとクラシックもやはり適用される
各エントリは独自のモデルを持ち、それは通常のスキンパックと同じ方法で推測されます — スリムな腕が空ける2列(x 54–55、y 20–31)からです — そして各エントリには、その推測が外れるスキン(たとえばそれらの列をほとんど塗らないクラシックなスキン)のためにClassic/Slimトグルがあります。つまりケープパックは、エントリごとにスリム/クラシックの号令も正しく下す必要があります — ケープは腕の読み取り方を変えませんし、ここでのモデルの誤りは他のどこでもと同じ形で現れます: スティーブの腕を持つAlexのスキンが、正しいケープを身に着けているのです。
実践的な形
もしあなたの目的が本当に「このケープを配る」ことなら、パックは製品ではなく配送手段です。意味の通る最も地味なスキンと組み合わせ、エントリにはスキンではなくケープの名前を付け、それを選ぶプレイヤーは両方を選んでいるのだと受け入れてください。
もしあなたの目的が揃いの見た目 — 一緒にデザインされたスキンとケープ — のセットなら、Bedrockのモデルは実のところ正しいものであり、制約のように感じられるその対の関係こそが機能なのです。