.nbtストラクチャーファイルはブロック名を保存せず、パレットインデックスを保存する — だからファイルサイズが小さい
ビルド全体は、サイズ、パレット、ブロックという3つのキーで構成されています。各ブロックはパレットを指す整数なので、32³の石のボリュームは1つの文字列と32,768個の数値で済みます。
.nbtストラクチャーファイル — ストラクチャーブロックが保存し、データパックが配布するファイル — は、外見から想像するよりもはるかにシンプルな形式です。ビルドに必要なすべての情報は、いくつかのトップレベルキーに格納されており、ある設計上の決定が、ファイルサイズがこれほど小さい理由を説明しています。
ビルドを構成する3つのキー
size [x, y, z] — a list of exactly three integers
palette [ { Name, Properties } … ] — every DISTINCT block state, once
blocks [ { pos, state, nbt } … ] — one entry per placed blockpaletteには、個々のブロックの状態が正確に1回だけ格納されます。 エントリはName — minecraft:oak_stairsのようなブロックID — と、オプションでPropertiesコンパウンド（facing: northやhalf: bottomのようなブロック状態を保持する）で構成されます。
blocksは名前を繰り返しません。 各エントリは3つの整数からなるposとstateを保持し、stateはブロックIDではなく、パレットへのインデックスです。北向きのオークの階段は一度だけ文字列データとして保存され、それ以降はすべて小さな整数として扱われます。
これが全体の仕組みです。32 × 32 × 32のプレーンな石のボリュームは、1つのパレットエントリと32,768個のインデックス番号で構成されます — minecraft:stoneという単語が32,768回コピーされるわけではありません。パレットは、ビルドに使用した異なるものの数に応じて増え、ブロックリストは、ビルドの大きさに応じて増えます。これらは非常に異なる数値であり、通常は後者のみが大きくなります。
設計で考慮すべき2つの結果
ブロック状態はブロックリストではなく、パレットを増やします。 オークの階段は1つのパレットエントリではありません — 実際に使用した向きごとに1つずつです。4方向、上下半分、直線、内側と外側の両方の角：同じブロックが十数個のパレットスロットを占めることがあります。したがって、詳細なビルドはサイズに関係なく大きなパレットを持ち、シンプルなビルドはそうではありません。
配置されたブロックのみがエントリを取得します。 ブロックリストはリストであり、密な3D配列ではありません。存在しないエントリは単に存在しません — このページのビューアはグリッドを-1で埋め、欠落している座標は何も配置されていないものとして扱います。中空のビルドは、同じ寸法のソリッドなビルドよりもストレージコストが実際に安くなります。
nbtはブロックごとでオプション
blocksの各エントリは、独自のnbtコンパウンドを保持することができ、ほとんどはそうではありません。ここにチェストの内容、看板のテキスト、スポナーのモブ、旗のパターンが格納されます — パレットではなく、個々のブロックにアタッチされます。
この区別は重要です：パレットデータは共有され、ブロックデータは共有されません。 2つのチェストは同じブロック状態であるため、1つのパレットエントリになります — しかし、それぞれが独自のnbtに独自のインベントリを保持します。ブロック状態を変更するとパレットに影響し、中身を変更するとブロックリストの1つのエントリに影響します。
レイヤーごとに読み取る
ここにあるビューアは意図的に2Dです。レイヤーyを描画するために、ブロックリストを走査し、pos[1]がyに等しいエントリを保持し、それぞれのstateをパレットで検索します。これがアルゴリズム全体であり、自分でこれらのファイルを検査する方法でもあるため、知っておく価値があります：構築する空間インデックスはなく、gzipラッパー以外の解凍もありません。この形式は、フィルタリングするフラットなリストです。
これはまた、ストラクチャーファイルがワールド内のどこに属するかについては何も教えてくれないことも意味します。sizeはバウンディングボックスであり、posの値はその角からの相対値です。配置はストラクチャーブロックの役割であり、ファイルの役割ではありません。