Bedrockのアドオンがzipである理由と、manifestで失敗する原因
拒否される.mcaddonインポートの多くは、有効なzipのヘッダー1行が間違っているだけであり、エラーメッセージは壊れたフィールドを決して名指ししません。header UUIDとモジュールUUIDの重複が典型的な原因です。
.mcaddonは拡張子が異なるzipアーカイブであり、ゲームがそれを拒否する理由はzipとは何の関係もありません。よくある原因はmanifest.jsonです。これはヘッダーUUIDとモジュール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のリソースパックは、対応するフォーマット(min_formatと現在のバージョンではmax_format)を宣言するpack.mcmetaを同梱します。BedrockはUUIDとモジュールリストを持つmanifest.jsonを同梱します。どちらのファイルももう一方のエディションには読まれず、アーカイブの名前を変えるだけではパックを移植できません。
インポートする前に確認する
アーカイブを解凍して最上位を見てください。1つ深いフォルダにネストされたパック — manifest.jsonではなくMyPack/manifest.json — は、エラーもなく何もインポートされません。manifestは各パックのルート、それが記述するフォルダの隣に置く必要があります。
ブロックモデルは別のフォーマット
JavaのブロックモデルJSONはBedrockのジオメトリファイルではなく、両者は互換性がありません。Javaのモデルは通常、parentとtexturesマップだけです — elementsの直方体リストはカスタム形状にのみ必要です — 一方Bedrockは独自のminecraft:geometryフォーマットで形状を記述します。どちらも1ブロックを16単位で測るため、あるエディションでは正しく見えるモデルが、もう一方では何もインポートされないことがあります。
レジストリ名は互換性がない
BedrockとJavaは同じコンテンツに対して異なる識別子を使用します。エンチャント、効果、バイオームにJavaの名前を参照するパックは、読み込まれた後に何も起こりません。名前がどのエントリにも解決されないためです。レジストリ自体もエディション間でサイズが異なるため、あるエディションのリストに対して作成されたパックがもう一方で完全であると仮定することはできません。
manifestを検証し、アーカイブのレイアウトを確認し、Bedrock & Pack Toolsでブロックモデルを生成してください。