Bedrockアドオンはzipであり、失敗する原因はmanifestにある
拒否される.mcaddonインポートのほとんどは、有効なzipでありながらヘッダー1行が間違っているだけであり、エラーメッセージは壊れたフィールド名を決して教えてくれない。
.mcaddonは拡張子が異なるzipアーカイブであり、ゲームがそれを拒否する理由はzipとは何の関係もない。よくある原因はmanifest.jsonだ。これは小さなファイルで、そのヘッダーに含まれる2つのUUIDは互いに異なる必要があり、またformat_versionが対象としているゲームバージョンでなければならない。
2つのUUID、決して同じにしてはいけない
manifestにはheaderとmodules配列が含まれる。それぞれに固有のuuidが必要であり、両方で1つを使い回すのが最もよくある拒否理由だ:
{
"format_version": 2,
"header": {
"name": "My Pack",
"description": "Example",
"uuid": "aaaaaaaa-0000-0000-0000-000000000000",
"version": [1, 0, 0],
"min_engine_version": [1, 21, 0]
},
"modules": [
{
"type": "data",
"uuid": "bbbbbbbb-0000-0000-0000-000000000001",
"version": [1, 0, 0]
}
]
}
UUIDは128ビットの値で、5つのハイフン区切りグループに分けた32桁の16進数として記述される。生成器は何でもよいが、重複は許されない。versionとmin_engine_versionは文字列ではなく3つの整数の配列だ——"1.0.0"は一部のビルドでサイレントに失敗する。
Javaにはmanifestが存在しない
これがエディション間を移動する人々がつまずく分岐点だ。Javaのリソースパックはpack_format整数を含むpack.mcmetaを同梱する。BedrockはUUIDとモジュールリストを含むmanifest.jsonを同梱する。どちらのファイルももう一方のエディションには読まれず、アーカイブの名前を変えてもパックを移植することはできない。
インポートする前に確認する
アーカイブを解凍して最上位を見る。1つ深くネストされたパック——manifest.jsonではなくMyPack/manifest.json——は、エラーも出ずに何もインポートされない。manifestは、それが記述するtextures/またはbehavior_packs/のコンテンツの隣に置かれなければならない。
ブロックモデルは別のフォーマットだ
JavaのブロックモデルJSONはBedrockのジオメトリファイルではなく、両者は互換性がない:
| Javaブロックモデル | Bedrockジオメトリ | |
|---|---|---|
| ルートキー | elements | minecraft:geometry |
| 座標 | ブロックあたり0~16 | ブロックあたり0~16 |
| テクスチャ | texturesマップ | materialsマップ |
どちらも1ブロックあたり16単位のキューブグリッドを表現している。だからこそ、生成されたモデルが一方では正しく見え、もう一方では空の形状としてインポートされるのだ。
レジストリ名は互換性がない
BedrockとJavaは同じコンテンツに対して異なる識別子を使う。エンチャント、エフェクト、バイオームにJavaの名前を参照するパックは、読み込まれた後に何も起こらない——名前がどのエントリにも解決されないからだ。レジストリ自体もエディション間でサイズが異なるため、一方のエディションのリストに基づいて作成されたパックがもう一方で完全であると仮定することはできない。
manifestを検証し、アーカイブのレイアウトを確認し、Bedrock & Pack Toolsでブロックモデルを生成しよう。