Bedrock Edition/Levelフォーマット

提供: Minecraft Wiki
移動先: 案内検索
Cleanup.svg
この記事はスタイルガイドの基準を満たす必要があります。 [議論]
この項目を整理してくださる協力者を求めています
議論ページには提案があるかもしれません。
Information icon.svg
この項目はBedrock Edition限定の要素です。

Bedrock Edition には、Google 社の LevelDB に変更などを加えた独自の LevelDB を使用している。この LevelDB というのは、データをストレージ内に Zlib 形式で圧縮し保存するシステムである。

1.0[編集 | ソースを編集]

1.0 では、各サブチャンクはそれぞれ異なる leveldb キーで保存されている[1]

オーバーワールド: | x: 32 | z: 32 | tag: 8 | (optional) subchunk id: 8 |

異なるディメンション: | x: 32 | z: 32 | dimension: 32 | tag: 8 | (optional) subchunk id: 8 |

使用可能なタグは以下の通りである

   enum class Tag : char {
       Data2D = 45,
       Data2DLegacy = 46,
       SubChunkPrefix = 47,
       LegacyTerrain = 48,
       BlockEntity = 49,
       Entity = 50,
       PendingTicks = 51,
       BlockExtraData = 52,
       BiomeState = 53,
       FinalizedState = 54,
       Version = 118
   };

特定のサブチャンクを出すには、上記の Tag に 47 を入れて Subchunk ID に0~15までの数字を入れる必要がある。この場合サブチャンクは存在しないことに注意すること。 しかしそれらは存在するように動作する。 チャンクがあれば、その下のチャンクもそこにあるはずだからだ。

サブチャンクのフォーマットは以下の通りである。

  • Version: 1B
  • Block IDs: 4KB, 8 ビット/ブロック
  • Block Data: 2KB, 4 ビット/ブロック
  • Sky Light: 2KB, 4 ビット/ブロック
  • Block Light: 2KB, 4 ビット/ブロック

0.9.0[編集 | ソースを編集]

LevelDB format[編集 | ソースを編集]

Mojangによって翻案されたLevelDBのソースコードは https://github.com/Mojang/leveldb-mcpe から入手でき、そのビルドに必要なビルドパラメータは、Tommasoによって https://twitter.com/_tomcc/status/477950809427427328 にてドキュメント化されている。公式のLevelDBのページは https://code.google.com/p/leveldb/ 。Bedrock EditionのLevelDBのソースコードを読む場合は、 https://github.com/tinfoiled/leveldb を見るとよい。

Bedrock Editionでは、データベースは db/ サブフォルダーに保存されている。このサブフォルダーには、生成された地形も保存されているようである。これは、古いワールドをInfinite Worldの db フォルダーによって置き換えることで、Inifinite Worldに切り替えられるようにするためである。

データベースに保存できるデータには3つの種類がある: 地形データ、エンティティデータ、タイルエンティティデータである。

データベースのキーの形式は、9バイトで、以下のものから成る:

  • チャンクのX座標で、リトルエンディアンの整数。
  • チャンクのZ座標で、リトルエンディアンの整数。
  • 残った一つのバイトはデータの種類を表す:
    • 0x30 (十進数で48, アスキーコードで'0') ならば、地形データ。
    • 0x31 (十進数で49, アスキーコードで'1') ならば、タイルエンティティデータ。
    • 0x32 (十進数で50, アスキーコードで'2') ならば、エンティティデータ。
    • 0x76 (十進数で118, アスキーコードで'v') ならば、1バイトデータ。

バージョン0.12.1でのネザーの導入により、現在はネザーのチャンクを表すための特別なキーが存在する。これは長さ13バイトで、以下のものから成る:

  • チャンクのX座標で、リトルエンディアンの整数。
  • チャンクのZ座標で、リトルエンディアンの整数。
  • リトルエンディアンの整数で、値は「1」 (0x01 0x00 0x00 0x00)
  • 残った一つのバイトはデータの種類を表す:
    • 0x30 (十進数で48, アスキーコードで'0') ならば、地形データ。
    • 0x31 (十進数で49, アスキーコードで'1') ならば、タイルエンティティデータ。
    • 0x32 (十進数で50, アスキーコードで'2') ならば、エンティティデータ。
    • 0x76 (十進数で118, アスキーコードで'v') ならば、1バイトデータ。

0x30で表される地形データのエントリは、チャンク内のブロックのデータを持つために使われる。それは x*z*y = 16*16*128 個のブロックのデータを含む。データの種類が0x30(地形データ)のキーに対する値は、つねに長さ83,200バイトであり、以下のデータから成る:

  • 32,768バイトの長さで、チャンク内のブロック x*z*y = 16*16*128 個ぶんのデータ。
  • 16,384バイトの長さのデータ(上記のブロックデータ1バイトに対して、4ビットのデータ)。
  • 16,384バイトの長さで、日光のデータ(上記のブロックデータ1バイトに対して、4ビットのデータ)。
  • 16,384バイトの長さで、ブロックの明るさのデータ(上記のブロックデータ1バイトに対して、4ビットのデータ)。
  • 256バイトの長さの追加データで、z*x = 16*16 バイトの配列であり、"dirty"な(変更のあった)ブロックの柱の情報を含む。各x,z座標におけるすべてのy座標のデータが含まれ、したがってブロックデータにおける128バイトに対して1バイトのデータが対応する。
  • 1,024バイトの長さの追加データで、16*16*4バイトの配列であり、草の色を含む。各x,z座標におけるすべてのy座標のデータが含まれ、したがってブロックデータにおける128バイトに対して4バイトのデータが対応する。

32,768ブロックのチャンクを含むLevelDBエントリ内のブロックの位置と、全世界の対応するブロックの位置との間のマッピングを明確にするために、次の定義が提供されている

  • LevelDBキーに含まれる値をXとZとする
  • C []をLevelDBエントリ内に含まれる32,768ブロックのチャンクの3次元配列とする。 最初の2つのインデックスiとjの範囲は0〜15で、3番目のインデックスyの範囲は0〜127である
  • W []を全世界に含まれるブロックの3次元配列とする
    • 古いスタイルの世界では、最初の2つのインデックスxとzの範囲は両方とも0~255である。無限の世界では、最初の2つのインデックスxとzは両方とも4バイト整数の値の範囲で、正と同様に負の場合もある。
    • 3番目のインデックスyは、古いスタイルと無限の世界の両方で0~127の範囲である

上記の定義を仮定すると、キー値XおよびZを持つLevelDBエントリを持つブロックの場所は、次のように全世界内のブロックの対応する場所にマッピングされる

  • x = 16 * X + iおよびz = 16 * Z + jにおいてC [i、j、y] <-> W [x、z、y]

xインデックスは、xの小さい値がxの大きい値よりも北にある北から南の場所を指定する。 zインデックスは、zの値が小さい値がzの値が大きい値よりも東にある東から西の場所を指定する。 yインデックスは、yの小さい値がyの大きい値よりも低い高さにある垂直位置を指定する。古いスタイルの世界では、世界の北東の隅の下部にあるブロックはW [0、0、0]である。

上記の0x31タイルエンティティおよび0x32エンティティデータエントリはNBTでエンコードされており、ルートレベルで0、1、または複数連結された複合タグを含むことができる。 0複合タグの場合、LevelDBはキーに関連付けられた値の長さとして0を示す。チャンクごとに複数のエンティティが存在する可能性があるため、複数連結タグがサポートされる。すべての0x31タイルエンティティと0x32エンティティエントリには、関連付けられた0x30地形エントリがあるが、0x30地形エントリには、関連付けられた0x31タイルエンティティまたは0x32エンティティエントリがないことがある。

0x30地形エントリと0x76 1バイトデータエントリの数は常に同じであり、これらのエントリ間に1対1の関係があり、対応するエントリの両方が同じxおよびz値を持つ。バイナリ値0、1、および2を含む1バイトデータに対して3つの値が観察される。値0は古いスタイルの世界で観察され、値1および2は無限の世界で観察された。

ローカルプレイヤーエンティティを持つエンティティデータエントリ用の特別なキー〜local_playerもある。ここにエンティティデータが存在する場合、level.datに保存されているプレーヤーデータよりも優先される。 〜local_playerキーに関連付けられた値はNBTでエンコードされ、ルートレベルに単一の複合タグのみがある。

2つの部分で構成されるリモートプレーヤー用の特別なキーもある。最初の部分はプレフィックス「player _」(引用符なし)で、2番目の部分はリモートプレーヤーのclientid.txtファイルに含まれるクライアントIDである。たとえば、player_-12345678は、クライアントIDが-12345678のリモートクライアントのキーになる。 「player_」プレフィックスキーに関連付けられた値はNBTでエンコードされ、ルートレベルに単一の複合タグのみがある。

長さ20のフラットワールド用の特別な「game_flatworldlayers」キーもある。このキーに関連付けられている値は、ASCIIテキスト形式の数字のセットである。 「game_flatworldlayers」キーに関連付けられている値の例は「[7,3,3,2]」である。この例の値の長さは9である。

level.dat[編集 | ソースを編集]

建造物[編集 | ソースを編集]

  • ワールドデータ
    •  Dimension: プレーヤーがいるディメンション。オーバーワールドは0である。
    •  GameType: サバイバルモード(0)かクリエイティブモード(1)か。
    •  Generator: ワールドタイプ:古い、無限、フラット
    •  LastPlayed: プレーヤーがゲームを保存した時のUnixタイムスタンプ(秒単位)を格納する
    •  LevelName: 世界の名前を指定する
    • LimitedWorldOrigin 古いタイプのワールドにのみ適用される
      •  LimitedWorldOriginX: 世界の生成が開始されたX座標
      •  LimitedWorldOriginY: 世界の生成が開始されたY座標
      •  LimitedWorldOriginZ: 世界の生成が開始されたZ座標
    •  Platform: 世界が生成されるプラットフォームを保存する。現在観察されている値は2である
    •  RandomSeed: 世界のシード
    •  SizeOnDisk: 世界の推定サイズ(バイト単位)
    • 世界のスポーン地点の座標
      •  SpawnX: プレイヤーのスポーン位置のX座標。デフォルトは0である
      •  SpawnY: プレイヤーのスポーン位置のY座標。デフォルトは64である
      •  SpawnZ: プレイヤーのスポーン位置のZ座標。デフォルトは0である
    •  StorageVersion:Bedrock Edirionストレージツールのバージョン。現在は4である
    •  Time: 現在の「時刻」をティックで保存する。実際の1秒あたり20ティック、およびMinecraftの昼夜サイクルごとに14400ティックがあり、サイクル全体の長さは12分である。0は昼間の開始、7200は日没の開始、8280は夜間の開始、13320は日の出の開始、14400は再び昼間の開始である。level.datに格納されている値は常に増加し、14400を超えることがあるが、「時刻」は常に「時刻」フィールド値のモジュロ14400である。
    •  dayCycleStopTime: 8.0で追加された。デフォルトは18446744073709552000である
    •  spawnMobs: Mobのスポーンを無効(0)または有効(1)にする

LOG[編集 | ソースを編集]

LOGファイルは世界の/ dbパスにあり、leveldb形式の一部であり、LDBファイルの圧縮の間に使用される。これは、プログラムのログファイルに似ている。形式は次のとおりである。

YYYY /MM/DD-Hour/Minute/Second.StepName "Info"

例:

2014/07/24-22:20:08.400488 4a3638 Recovering log #3

0.8.1以前[編集 | ソースを編集]

level.dat[編集 | ソースを編集]

level.datファイルは、デスクトップ環境のlevel.datの形式に基づいたNBT形式です。level.datは、圧縮されていないリトルエンディアンのNBTファイルで、環境データ(たとえば、時刻)と、プレーヤーの健康状態、インベントリ、速度、マップ内の位置を保存する。

ファイルは8バイトのヘッダーで始まり、ファイルのタイプを示すリトルエンディアンの4バイト整数で構成される。これは、level.datの場合は3(最新の更新前は2)であった。ファイルの長さからヘッダーを除いた別の整数が続く。[2]

NBT Structure[編集 | ソースを編集]

  • ワールドデータ
    •  GameType: サバイバルモード(0)かクリエイティブモード(1)か。
    •  LastPlayed: プレーヤーがゲームを保存した時のUnixタイムスタンプ(秒単位)を格納する
    •  LevelName: 世界の名前を指定する
    •  Platform: 世界が生成されるプラットフォームを保存する。現在観察されている値は2である
    •  Player: プレイヤーエンティティ情報。詳細については、「エンティティ形式」および「Mobエンティティ形式」を参照。idタグがなく、追加の要素がある:
      •  Armor: このリストの各TAG_Compoundは、プレイヤーが着ている防具を定義する。これは、ヘルメット、チェストプレート、レギンス、ブーツの長さ4のリストである。
        • インベントリアイテムデータ
          •  id: アイテム・ブロックID
          •  Count: このインベントリスロットにスタックされたアイテムの数。ツールを含むあらゆるアイテムをスタックすることができる。範囲は1〜255である。255を超える値はゲーム内に表示されない。
          •  Damage: 防具の場合、それらが被ったダメージの量。防具の耐久性が最大であれば、損傷がないことを意味する。ダメージが0に達すると、破損して消える。
      •  Dimension: プレーヤーがいるディメンション。オーバーワールドは0である。
      •  Inventory: このリストの各TAG_Compoundは、プレーヤーが携帯または保持しているアイテムを定義する
        • インベントリアイテムデータ
          •  Slot: アイテムが存在するインベントリスロットを示す
          •  id:アイテム・ブロックID
          •  Count: このインベントリスロットにスタックされたアイテムの数。ツールを含むあらゆるアイテムをスタックすることができる。範囲は1〜255である。255を超える値はゲーム内に表示されない。
          •  Damage: ツールの場合、被った摩耗量。防具の耐久性が最大(例えば、金のツールは33)であれば、損傷がないことを意味する。ダメージが0に達すると、破損して消える。
      •  Score: プレーヤーのスコア。
      •  Sleeping: 1または0(true/false)-このタグが保存されたときにプレイヤーがベッドにいた場合はtrue。ログイン時にプレイヤーがベッドにいるかどうかには影響しない。
      •  SleepTimer: このタグが保存されたときにプレイヤーがベッドにいたティック数。無効。
      •  SpawnX: プレイヤーのスポーン位置のX座標。デフォルトは0である。
      •  SpawnY: プレイヤーのスポーン位置のY座標。デフォルトは64である。
      •  SpawnZ: プレイヤーのスポーン位置のZ座標。デフォルトは0である。
      •  abilities: このプレイヤーが持っている能力。
        •  mayfly: 1または0(true / false)-プレイヤーが飛行できる場合はtrue。
        •  flying: 1または0(true / false)-プレイヤーが現在飛行している場合はtrue。
        •  invulnerable: 1または0(true / false)-奈落でのダメージを除くすべてのダメージと有害な影響に対してプレイヤーが免疫がない場合はtrue 。
        •  mayBuild: 1または0(true / false)-プレーヤーがブロックを配置および破壊できる場合はtrue。
        •  instabuild: 1または0(true / false)-プレイヤーがブロックを即座に破壊できる場合はtrue。
    •  RandomSeed: 地形にランダムシードを提供する乱数。
    •  SizeOnDisk: 全世界の推定サイズ(バイト単位)。
    •  SpawnX: ワールドのスポーン位置のX座標。デフォルトは0である。
    •  SpawnY: ワールドのスポーン位置のY座標。デフォルトは64である。
    •  SpawnZ: ワールドのスポーン位置のZ座標。デフォルトは0である。
    •  StorageVersion: Bedrock Edition NBTのバージョンは3である。
    •  Time: 現在の「時刻」をティックで保存する。実際の1秒あたり20ティック、およびMinecraftの昼夜サイクルごとに14400ティックがあり、サイクル全体の長さは12分である。0は昼間の開始、7200は日没の開始、8280は夜間の開始、13320は日の出の開始、14400は再び昼間の開始である。level.datに格納されている値は常に増加し、14400を超えることがあるが、「時刻」は常に「時刻」フィールド値のモジュロ14400である。
    •  dayCycleStopTime: 8.0で追加された。デフォルトは18446744073709552000である
    •  spawnMobs: Mobのスポーンを無効(0)または有効(1)にする

chunks.dat[編集 | ソースを編集]

このファイルには、世界を構成するすべての地形データが保存される。これは、地形の16x16x128(XZY)ブロックセクションであるチャンクで構成されている。最大1024チャンク(32x32)および512x512x128(33,554,432)ブロックを格納できるが、ゲームはデフォルトで256チャンク(16x16)および256x256x128(8,388,608)ブロックのみを生成する。

ファイルは4kbセクター(4,096バイト)に分割される。最初のセクターは「チャンクインデックス」で、特定のチャンクがファイルとワールドのどこにあるかを定義しり。チャンクインデックスの4バイトごとに1つのチャンクが表される。チャンクインデックスの128バイトごとに、Z軸(北から南)に沿った32チャンクの列が表される。後続の各128バイトセクションは、X軸(西から東)に沿った1行のチャンクを表す。しかし、ゲームによって生成されたデフォルトの世界では、各列と行に16のチャンクのみが定義されている。

チャンクインデックスの各チャンクの形式は4バイトのみである。例:15 51 01 00 。最初のバイトは、チャンクのデータを構成する4kbセクターの数を示す。実際には、これは常に21(0x15)である。次の3バイトは、ファイルの先頭からチャンクデータが始まるまでの4kbセクターの数を表すリトルエンディアンの数値である。チャンクが存在しない場合、4バイトすべてがゼロになる00 00 00 00

例として、1,0(X、Z)のチャンクインデックスのチャンク15 51 01 00 が読み取られた場合、ファイル内のチャンクデータを見つけることができる。最初に、リトルエンディアンで10進数337に等しい最後の3バイトの10進数表現51 01 00を取得する。次に、結果にセクターのサイズを掛けてオフセットを計算する337 * 4,096。最後に、常に21(0x15)である最初のバイトの10進表現を取得し、それにセクターのサイズを掛ける21 * 4,096。その結果、このチャンクは10進オフセットに位置し、サイズ1,380,35286,016バイトであることがわかる。

実際のチャンクデータには、すべての地形データが格納される。これには、ブロック、データ、日光、明るさ、バイオームが含まれる。

チャンクの最初の4バイトは常に04 41 01 00になる。これは、後続のデータが実際にチャンクデータであることを確認するためのマジックヘッダーであると考えられている。

次の32,768バイトにはブロックデータが含まれる。ブロックの順序はYZXである。1バイトごとに、Y軸に沿って垂直に上がることに相当する。128バイトの後、世界の高さの制限に到達したため、Z軸に沿って南1ブロックを移動して繰り返す。2,048バイト(128 * 16)後、チャンクの1列が終了したため、X軸に沿って東1ブロックを移動して繰り返す。ほとんどのプログラミング言語では、これは基本的な3D配列blocks[16][16][128]([x] [z] [y])にすぎない。繰り返すが、128ブロックごとにZ軸の列があり、16列ごとにX軸の行がある。

次の16,384バイトには「data」データが含まれる。それ以外の場合、損傷、メタ、または補助データで知られている。それは羊毛に色を与え、チェストに方向などを与える。ブロックデータと同様に、順序はYZXである。データ値の範囲は0〜15であるため、1ブロックを表すのに必要なのは半バイトのみである。したがって、1バイトは実際には2ブロックを表す。したがって、データセクションはブロックセクションの半分の大きさである。このデータはビッグエンディアンなので、実際の2fのようなバイトは、この場所の最初のブロックのデータ値がfであり、この場所の2番目のブロックのデータ値が2であることを意味する。

次の16,384バイトには、日光のデータが含まれる。形式は、以前の「data」形式と同じである。日光の値がfの場合、太陽光がそのブロック(空気やガラスなど)を完全に照らしていることを意味する。そのブロックに存在する日光が少ないほど、値が低くなる(葉や水などの半透明のブロックのように)。また、天窓の値が0の場合、そのブロックには日光が当たっていない(石や土など)。ゲームは照明を自動的に生成するため、外部プログラムを介してワールドを生成するときにファイルのこの部分を変更することは重要ではない。

次の16,384バイトにはブロックの明るさのデータが含まれる。この形式は、以前の日光の形式と同じである。ブロックの明るさの値がfの場合、ブロックが最大量の光(グローストーンなど)を放出していることを意味する。ブロックが発する光が少ないほど、値が低くなる(オンのレッドストーンなど)。また、ブロックの明るさの値が0の場合、そのブロックからは光が放射されていない。ゲームは照明を自動的に生成するため、外部プログラムを介してワールドを生成するときにファイルのこの部分を変更することは重要ではない。

最後の256バイトには、バイオームデータが含まれる。各バイトは、特定のバイオームタイプに対応している。順序はXZである。16バイトごとに新しい行がある。

entities.dat[編集 | ソースを編集]

このファイルは、修正されたリトルエンディアンの非圧縮NBT形式を使用する。Alpha Level Chunk Formatに基づく形式を使用して、エンティティ情報を保存している。また、ブロックエンティティ情報も保存する。

ファイルには12バイトのヘッダーがある。ASCII文字「ENT」で始まり、ゼロバイトが1つ、値が1のリトルエンディアンの整数、ヘッダーのないファイルの長さをバイト単位で示す別のリトルエンディアンの整数が続く。[3]

NBT Structure[編集 | ソースを編集]

Clock JE2 BE2.gif
この記事は内容の更新を必要とします。
情報の一部は、現在の最新バージョンには適用されません。

Entity Format[編集 | ソースを編集]

すべてのエンティティは、チャンクファイルのエンティティリストに含まれる名前のないTAG_Compoundである。唯一の例外は、level.datに保存されているPlayerエンティティである。

すべてのエンティティはこれが基本である:
  • エンティティ
    •  id: エンティティタイプID。既知の値は、羊の場合は13、ゾンビの場合は32、ドロップアイテムの場合は64である。
    •  Pos: エンティティの現在のX、Y、Z位置を記述する3つのTAG_Float。
    •  Motion: エンティティの現在のdX、dY、dZ速度を記述する3つのTAG_Float。(注:0,0,0はモーションなしである。)
    •  Rotation: 回転を度単位で表す2つのTAG_Float。
      • : エンティティのY軸を中心とした時計回りの回転(yawと呼ばれる)。Due westは0である。ゲーム全体でエンティティの横方向の回転がすべて蓄積されるため、大きな値を持つことができる。
      • : 地平線からのエンティティの偏角(ピッチと呼ばれる)。水平は0である。正の値は下向きに見える。正または負の90度を超えない。
    •  FallDistance: エンティティが落ちた距離。値が大きいほど、エンティティが着地したときにダメージが大きくなる。
    •  Fire: 火が消されるまでのティック数。負の値は、エンティティが燃える前に火の中に立つことができる時間を反映している。
    •  Air: エンティティが持つ空気の量(ティック単位)。空気で最大300まで充填する。水中では減少する。
    •  OnGround: エンティティが地面に触れている場合は1。

ZombieFace.png Mob[編集 | ソースを編集]

  • モブの追加フィールド:
    •  AttackTime: エンティティが最後に攻撃された後、エンティティの「無敵状態」が持続するティック数。
    •  DeathTime: エンティティが死んだティックの数。死のアニメーションを制御する。
    •  Health: エンティティの体力の量。プレイヤーと敵は通常最大20の体力を持っている。家畜の体力は最大10である。
    •  HurtTime: 不明、攻撃後の無敵かもしれない
  • 羊などの動物用の追加フィールド:
    •  Age: 動物の年齢。

SheepFace.png には2つの追加フィールドがある。

    •  Sheared: 1または0(true / false)-羊が刈られている場合はtrue。
    •  Color: 0〜15-色の割り当てについては、羊毛のデータ値を参照。この値は羊のレンダリングには影響しないが、羊毛のドロップには影響する。[4]
  • Cobblestone.png アイテムの追加フィールド:
    •  Health: 5から始まり、現在アイテムが火炎ダメージを受けると減少する。体力が0に達すると、アイテムは破棄される
    •  Age: アイテムが地上で「手つかず」になった時間。2400の「ティック」、つまり2分後に、アイテムは破棄される。
    •  Item: アイテムデータ
      •  id: アイテム・ブロックID
      •  Damage: 各アイテムが被った摩耗量。0は破損していないことを意味する。ダメージがアイテムの耐久性を超えると、破損して消滅する。ツールと防具のみが通常ダメージを蓄積する。
      •  Count: このドロップアイテムエンティティに含まれるアイテムの数。ツール、防具、乗り物など、あらゆるアイテムをスタックすることができる。範囲は1〜255である。

歴史[編集 | ソースを編集]

Pocket Edition Alpha
0.2.0level.datファイルが NBTフォーマット形式になった。
player.datファイルの情報が level.dat ファイルに記述されるようになった。
entities.datファイルが追加された。
0.3.2entities.dat ファイルにタイルエンティティの情報が書き込まれるようになった。
0.9.0?LevelDB 1.17 をベースとする新しいワールド保存方法が追加された。これはワールド情報をZlib形式で保存する。以前のワールドは自動的に変換され、新しいフォーマットで読み込まれる。
Pocket Edition
1.0.0?各サブチャンクが、それぞれ異なる Leveldb キーとして保存されるようになった。
Bedrock Edition
1.2.13?Subchunks are now palleted.[5]

脚注[編集 | ソースを編集]