スポンジとストラクチャーブロックは同じファイルではない
.schem、.litematic、そしてBedrockの.mcstructureは一見互換性があるように見えますが、変換した途端にチェスト、エンティティ、ブロック状態がすべて消え去ります。看板の文字も保持されないことがあります。
.schem と .litematic はどちらも建築物を保持しますが、両者間の変換でほとんどのプレイヤーが気づくのは、この2つのフォーマットが「建築物とは何か」について一度も合意していなかったという事実です。一方は単一のブロック領域を保存します。もう一方は複数の名前付き領域を保持でき、それぞれに独自のパレットを持ちます。両者間で街を移動すると、家屋は残るのに中身は残りません。
各フォーマットが実際に保持するもの
| フォーマット | 動作環境 | ブロック状態 | ブロックエンティティ | エンティティ |
|---|---|---|---|---|
.schem | Java、WorldEdit/Sponge | あり | あり | あり |
.litematic | Java、Litematica | あり | あり | あり |
.nbt structure | Java、ストラクチャーブロック | あり | あり | あり |
.mcstructure | Bedrock | あり | あり | あり |
列だけを見ると同一に見えますが、これが罠です。違いは機能一覧ではなく、パレットの扱いと座標空間にあります。
パレットが壊れやすい部分
これらのフォーマットはすべて、ブロックをパレットへのインデックスとして保存します。パレットとはファイルが使用する一意のブロック種別のリストで、各位置はそのリストを指す数値を保持します。数百種類の異なるブロックを使う建築物は、そのサイズのパレットを持ち、位置は単なる整数です。
つまり、ファイルが読めるのは、読み手がすべてのパレット項目を解決できる場合だけです。新しいJavaリリースで追加されたブロックにはBedrock相当がまったく存在しないため、JavaからBedrockへの変換ではそれを置換するか削除する必要があります。通常は空気が代替となり、不可解にブロックが欠けた壁はほぼ常にこれが原因であり、破損ではありません。
JavaとBedrockでは同じブロックの名前が異なる
ここがJavaとBedrockが真に分岐する点です。Bedrockはブロック状態を block_type とキーと値の状態セットとして書き込み、Javaは名前空間付きIDと状態マップを書き込みます。同じ物理ブロックが、片方では minecraft:oak_stairs[facing=east,half=bottom]、もう片方では weirdo_direction と upside_down_bit になることがあります。状態名と値が異なるのであり、同じものを並べ替えたわけではありません。
反転するのは階段、ハーフブロック、フェンス、壁、ドア、レッドストーン部品です。変換後に逆さまに表示される階段は、状態マッピングのミスであり、ファイルの不良ではありません。
ストラクチャーブロックは思っているものを保存しない
.nbt に保存するストラクチャーブロックはバウンディングボックスを書き込み、そのボックスは各軸48ブロックに制限されます。ゲームはより大きな建築物を分割しません。ボックスの外にあるものは単にファイルに含まれません。変換後の建築物の遠端が欠けている場合は、コンバーターを疑う前に元のボックスを確認してください。
エンティティはこれらのフォーマットすべてでブロックとは別に保存されます。額縁、防具立て、絵画、モブはブロックではなく、ブロックパレットだけを走査するコンバーターはそれらを黙って落とします。
信頼する前にプレビューする
最も手早い健全性チェックは素材リストです。変換後のファイルのブロック数が元と一致しなければ、何かが置換されています。レイヤープレビューはそれを即座に、建築物をワールドに読み込むことなく、水平スライスを1枚ずつ表示します。
.litematic、.schem、Java structure .nbt、Bedrock .mcstructure の間で、レイヤープレビューと素材リスト付きで変換できます。Schematic Converterにて。