スポンジとストラクチャーブロックは同じファイルではない
.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] であり、もう片方では順序の異なる状態セットであることがあります。
反転するのは階段、ハーフブロック、フェンス、壁、ドア、レッドストーン部品です。変換後に階段が逆さまに表示されるのは、状態の順序の不一致であり、壊れたファイルではありません。
ストラクチャーブロックは思っているものを保存しない
ストラクチャーブロックが .nbt に保存するとき、バウンディングボックスを書き込み、そのボックスには軸ごとに厳格なサイズ制限があります。ボックスより大きな建築物は1つのファイルとして保存されず、ゲームは分割するか拒否します。変換された建築物の遠端が欠けている場合は、コンバーターを疑う前に元のボックスを確認してください。
エンティティはこれらのフォーマットすべてでブロックとは別に保存されます。額縁、防具立て、絵画、モブはブロックではなく、ブロックパレットだけを走査するコンバーターはそれらを黙って捨ててしまいます。
信頼する前にプレビューする
素材リストが最も手早い健全性チェックです。変換されたファイルのブロック数が元と一致しなければ、何かが置換されています。レイヤープレビューはそれを即座に、建築物をワールドに読み込むことなく、水平スライスを1枚ずつ表示します。
.litematic、.schem、Java structure .nbt、Bedrock .mcstructure の間で変換できます。レイヤープレビューと素材リスト付きで、Schematic Converter にて。