提供: Minecraft Modding Wiki
移動先: 案内、 検索
(下書きとして。)
 
細
 
(同じ利用者による、間の5版が非表示)
1行目: 1行目:
 +
英語が読めるのであれば、[https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a williewillus氏による1.13指南書]が参考になるだろう。
 +
 
== Minecraft本体 ==
 
== Minecraft本体 ==
−
=== BlockID、ItemIDの平坦化・無限化 ===
+
=== [https://minecraft-ja.gamepedia.com/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%91%E3%83%83%E3%82%AF データパック] ===
 +
ついにデータパックが正式実装。<br>
 +
1.12では不完全だったが、いよいよ使えるものになった。<br>
 +
ディレクトリ階層もすこし変更されているので注意が必要。
 +
 
 +
=== BlockID、ItemIDの平坦化 ===
 
要は、metaだとかdamageだとか言われていたものが削除された。<br>
 
要は、metaだとかdamageだとか言われていたものが削除された。<br>
 
羊毛は色それぞれが別ブロックとなり、ツールのダメージはNBTに保存されるようになった。<br>
 
羊毛は色それぞれが別ブロックとなり、ツールのダメージはNBTに保存されるようになった。<br>
−
Stateの上限もなくなっているので、ある程度自由になったと言えるかも。
+
Stateの16上限もなくなっているので、ある程度自由になったと言えるかも。<br>
 +
<s>IDの無限化はまだ[https://github.com/MinecraftForge/MinecraftForge/issues/5135 夢幻]。</s> <u>無事1.13.2で解決</u>
  
 
=== 水、溶岩の挙動に手が入った ===
 
=== 水、溶岩の挙動に手が入った ===
9行目: 17行目:
 
インターフェースによる処理なので、Modであっても実装は容易だろう。<br>
 
インターフェースによる処理なので、Modであっても実装は容易だろう。<br>
 
水の流れに関する複雑な処理は<code>Block</code>ではなく<code>Fluid</code>(1.13にて追加)が担うようだ。<br>
 
水の流れに関する複雑な処理は<code>Block</code>ではなく<code>Fluid</code>(1.13にて追加)が担うようだ。<br>
−
実装だけ読んだ限りだと、溶岩を保持するのも可能……っぽい？
+
実装だけ読んだ限りだと、溶岩を保持するのも可能……[https://twitter.com/Dinnerbone/status/988386661661925377 かもしれない？]
  
 
=== タグの概念 ===
 
=== タグの概念 ===
 
バニラでは、<code>Block</code>と<code>Item</code>と<code>Fluid</code>に用いられている模様。<br>
 
バニラでは、<code>Block</code>と<code>Item</code>と<code>Fluid</code>に用いられている模様。<br>
−
レシピの材料判定とかそういう感じのところで包括的に扱うための仕組みっぽい。<br>
+
レシピの材料判定などの幅広い部分で要素を包括的に扱うための仕組み。<br>
−
Jsonで自由にいじることができる。<br>
+
Jsonで自由にいじることができる。要はJson版鉱石辞書。
−
空気を水扱いにして泳げるようにした実験的データパックとか見た気がする。<br>
 
−
もとからあるタグはラッパーを用いてコード内でもJsonでもいい感じに使えるようになってる。
 
  
 
=== 精錬レシピがJson化された ===
 
=== 精錬レシピがJson化された ===
30行目: 36行目:
  
 
=== コマンドの実装が一新された ===
 
=== コマンドの実装が一新された ===
−
構文解析のためにいろいろやってる。
+
構文解析のためにいろいろやっている。<br>
 +
コードの見通しも良くなったため、複雑な構文も比較的容易に追加できるようになった。
  
 
=== ツールのTierがインターフェースで管理されるようになった ===
 
=== ツールのTierがインターフェースで管理されるようになった ===
42行目: 49行目:
 
当たり判定は前まで<code>AxisAlignedBB</code>のリストで扱われていたが、<code>VoxelShape</code>を使うようになった。
 
当たり判定は前まで<code>AxisAlignedBB</code>のリストで扱われていたが、<code>VoxelShape</code>を使うようになった。
  
−
=== <code>IDataProvider</code> ===
+
=== リソースパック ver.4 ===
−
Mojangはこれであの大量のJsonを用意していたんですね。<br>
+
==== Jsonモデル ====
−
Mojangの開発環境で使われているだけなので無視してOK、それだけが言いたかった。
 
−
 
 
−
=== Jsonモデル ===
 
 
パスの省略部分が変更された。<br>
 
パスの省略部分が変更された。<br>
 
ある程度一括で置換できる部分なのでそう影響はないはず……。
 
ある程度一括で置換できる部分なのでそう影響はないはず……。
 +
 +
==== 言語ファイル ====
 +
これまでJavaのproperties形式であったが、Json形式に変更された。<br>
 +
コメント機能が無いのが大きな違いといえば違いだが、未割り当てキーの使用等で対処可能。
  
 
== MinecraftForge ==
 
== MinecraftForge ==
−
9/30現在。<br>
+
2019/02/24現在。<br>
−
大体方向性ははっきりしているだろうというところに絞っているが、まだまだ変更が見込まれる部分なので実際のコードを見てほしい。
+
大体方向性ははっきりしているだろうというところに絞っているが、まだまだ変更が見込まれる部分なので実際のコードを見てほしい。<br>
 +
闇深でレガシーなコードを整理するために大規模な改修が行われ、多くの部分が影響を受けることになる。
  
 
=== Modの認識方法の変更 ===
 
=== Modの認識方法の変更 ===
−
META-INF/mods.tomlとかいうのでこれまでModアノテーションでやってきたことの大半をやるっぽい。<br>
+
これまでModアノテーションで指定してきたことはMETA-INF/mods.tomlに移動した。<br>
−
CoremodもJsonから認識するようになるらしい？
+
ModアノテーションはエントリクラスをFMLに示すための純粋なマーカーとなるようだ。<br>
 +
CoremodもJSから認識するようになるとか。
  
−
=== EventHandlerアノテーションが非推奨に ===
+
=== Config ===
−
代替は不明。まだ作られてない？
+
刷新され、独自フォーマットではなくtoml形式が用いられるようになった。<br>
 +
ロードセーブまわりの仕様も変わり、よりConfigGUIなどのオンゲームでの変更に強いものとなった。<br>
 +
書き方の作法も当然様変わりしている。<br>
 +
ファイル形式を自由にしようとしている形跡があるが、どうなるかは不明。
 +
 
 +
=== LifecycleEvent ===
 +
これまで<code>EventHandler</code>アノテーションを用いていたEvent群が再編された。<br>
 +
それに伴い<code>EventHandler</code>アノテーションは削除された。<br>
 +
代わりにコンストラクタで、FMLJavaModLoadingContextを通じて取得したEventBusにメソッドを登録していく。
 +
# <code>FMLCommonSetupEvent</code>
 +
# <code>FML(Client|DedicatedServer)SetupEvent</code>
 +
# <code>InterModEnqueueEvent</code>
 +
# <code>InterModProcessEvent</code>
 +
 
 +
の順で呼び出される。アイテムやブロックの登録イベントはこれらより前に発火される。<br>
 +
並列に処理されるようになったため、Modのロード順などの概念はなくなった。<br>
 +
SetupEvent時点でブロック等は登録されている '''はず''' なため、連携する上では問題ない。
  
 
=== <code>GameRegistry</code> ===
 
=== <code>GameRegistry</code> ===
−
なんかスッキリしてる。(findRegistryというメソッド一つになってる)<br>
+
findRegistryというメソッド以外は削除された。<br>
−
WIPなのか、もうEvent/Json使ってくれやってことなのかは不明。
+
登録処理は主にイベントを通じてアクセスすることになる。
  
 
=== Forge Service Provider Interfaces ===
 
=== Forge Service Provider Interfaces ===
72行目: 98行目:
  
 
==== <code>DistExecutor</code> ====
 
==== <code>DistExecutor</code> ====
−
<code>SidedProxy</code>の代わり？
+
<code>SidedProxy</code>の代替。<br>
 +
ラムダ式等を用いてよりモダンに蔵鯖の分岐処理をかけるようになる。
  
 
=== <code>OreDictionary</code> ===
 
=== <code>OreDictionary</code> ===
−
ほとんどの機能がタグに移行した。<br>
+
タグに機能が移行した。<br>
−
というか、現時点では全範囲がコメントアウトされている。
+
クラスは削除され、もはや使用することはできない。
 +
 
 +
== ForgeGradle ==
 +
version3.xとなり、環境構築手順が変わった。

2019年3月28日 (木) 00:58時点における最新版

英語が読めるのであれば、williewillus氏による1.13指南書が参考になるだろう。

Minecraft本体[編集]

データパック[編集]

ついにデータパックが正式実装。
1.12では不完全だったが、いよいよ使えるものになった。
ディレクトリ階層もすこし変更されているので注意が必要。

BlockID、ItemIDの平坦化[編集]

要は、metaだとかdamageだとか言われていたものが削除された。
羊毛は色それぞれが別ブロックとなり、ツールのダメージはNBTに保存されるようになった。
Stateの16上限もなくなっているので、ある程度自由になったと言えるかも。
IDの無限化はまだ夢幻。 無事1.13.2で解決

水、溶岩の挙動に手が入った[編集]

水源を特定のブロックが保持できるようになった。
インターフェースによる処理なので、Modであっても実装は容易だろう。
水の流れに関する複雑な処理はBlockではなくFluid(1.13にて追加)が担うようだ。
実装だけ読んだ限りだと、溶岩を保持するのも可能……かもしれない？

タグの概念[編集]

バニラでは、BlockとItemとFluidに用いられている模様。
レシピの材料判定などの幅広い部分で要素を包括的に扱うための仕組み。
Jsonで自由にいじることができる。要はJson版鉱石辞書。

精錬レシピがJson化された[編集]

同時に精錬レシピがIRecipe傘下入り。
まぁある意味では扱いやすくなったとも言えるかも……？

Item、Blockのコンストラクタの変更[編集]

ビルダーパターンが採用され、setHardnessとか言ったプロパティ的なものは初期化時に全部指定して固定化されるようになった。

IItemProvider[編集]

BlockとItemを一緒くたに扱えるようになった。
色んな所でいちいちItemStackにしなきゃいけなくてめんどくさかったのが解消する。

コマンドの実装が一新された[編集]

構文解析のためにいろいろやっている。
コードの見通しも良くなったため、複雑な構文も比較的容易に追加できるようになった。

ツールのTierがインターフェースで管理されるようになった[編集]

前まではいろいろ分散したりしていたのが、インターフェースにまとめられた。

BlockstateのPropertyが共通化された[編集]

これまでは同じ内容を表すものであっても個別に宣言されていたが、統一された。
ある程度包括的にブロックを扱えるようになった。

VoxelShape[編集]

当たり判定は前までAxisAlignedBBのリストで扱われていたが、VoxelShapeを使うようになった。

リソースパック ver.4[編集]

Jsonモデル[編集]

パスの省略部分が変更された。
ある程度一括で置換できる部分なのでそう影響はないはず……。

言語ファイル[編集]

これまでJavaのproperties形式であったが、Json形式に変更された。
コメント機能が無いのが大きな違いといえば違いだが、未割り当てキーの使用等で対処可能。

MinecraftForge[編集]

2019/02/24現在。
大体方向性ははっきりしているだろうというところに絞っているが、まだまだ変更が見込まれる部分なので実際のコードを見てほしい。
闇深でレガシーなコードを整理するために大規模な改修が行われ、多くの部分が影響を受けることになる。

Modの認識方法の変更[編集]

これまでModアノテーションで指定してきたことはMETA-INF/mods.tomlに移動した。
ModアノテーションはエントリクラスをFMLに示すための純粋なマーカーとなるようだ。
CoremodもJSから認識するようになるとか。

Config[編集]

刷新され、独自フォーマットではなくtoml形式が用いられるようになった。
ロードセーブまわりの仕様も変わり、よりConfigGUIなどのオンゲームでの変更に強いものとなった。
書き方の作法も当然様変わりしている。
ファイル形式を自由にしようとしている形跡があるが、どうなるかは不明。

LifecycleEvent[編集]

これまでEventHandlerアノテーションを用いていたEvent群が再編された。
それに伴いEventHandlerアノテーションは削除された。
代わりにコンストラクタで、FMLJavaModLoadingContextを通じて取得したEventBusにメソッドを登録していく。

  1. FMLCommonSetupEvent
  2. FML(Client|DedicatedServer)SetupEvent
  3. InterModEnqueueEvent
  4. InterModProcessEvent

の順で呼び出される。アイテムやブロックの登録イベントはこれらより前に発火される。
並列に処理されるようになったため、Modのロード順などの概念はなくなった。
SetupEvent時点でブロック等は登録されている はず なため、連携する上では問題ない。

GameRegistry[編集]

findRegistryというメソッド以外は削除された。
登録処理は主にイベントを通じてアクセスすることになる。

Forge Service Provider Interfaces[編集]

SideがDistというものに変わった。

OnlyInアノテーション[編集]

SideOnlyアノテーションの代わり。

DistExecutor[編集]

SidedProxyの代替。
ラムダ式等を用いてよりモダンに蔵鯖の分岐処理をかけるようになる。

OreDictionary[編集]

タグに機能が移行した。
クラスは削除され、もはや使用することはできない。

ForgeGradle[編集]

version3.xとなり、環境構築手順が変わった。

「https://mcmodding.jp/modding/index.php?title=1.12から1.13への変更点&oldid=3747」から取得