MOD作成関連のまとめ
開発環境(1.2.5)
- Minecraft version 1.2.5
- Minecraft Code Pack(MCP) 6.2
- ModLoader 1.2.5
- Minecraft Forge 3+
- Java6 SDK
予定開発環境(1.3)
- Minecraft Forge 1.3.2
- Minecraft Code Pack(MCP) 7.2
- Forge ModLoader (Forgeに同梱)
- Minecraft Forge 4.0.0.200(8/19現在)
- Java6 SDK
環境構築
バージョンによって前提Modが異なったり, 機能が統合されていたりするので注意.
3.1.3.109以前(ModLoaderが必要)
- mcroot/jarsにバニラのminecraft_server.jar, バニラのminecraft.jarを含むbinフォルダ, resourcesフォルダをコピー
- minecraft.jarにModLoaderを導入(META-INFは削除しなくてよい)
- decompile.batでデコンパイル
- Minecraft Forge Sourceにあるforgeフォルダをmcroot直下にコピー
- mcroot/forge/にあるinstall.cmdでforgeをインストール
- MOD作成へ
3.1.3.109以降(ModLoaderは不要)
- mcroot/jarsにバニラのminecraft_server.jar, バニラのminecraft.jarを含むbinフォルダ, resourcesフォルダをコピー
- decompile.baでコンパイル
- Minecraft Forge Sourceにあるforgeフォルダをmcroot直下にコピー
- mcroot/forge/にあるinstall.cmdでforgeをインストール
- MOD作成へ
3.3.8.160時点
- AudioModの機能が統合
- mDiyo's 4096ID方式によるブロックIDの拡張を実装
- より簡単な新しい鉱石辞書が追加, 従来のIOreHandlerも互換性のために存在するが, 使用は推奨されない
- ModLoaderとは完全に互換性があるわけではなく, 現行のModLoaderで作られたModが必ずしもForgeModLoaderで動くわけではない
3.4.9.171(1.2.5最終安定版)
- ModLoader, ModLoaderMpの機能を統合したForgeModLoaderがMinecraftForgeの前提Modに(ただしMinecraftForgeに同梱されている)
- AudioMod, HDTextureFix(128xまで)を実装
- 4096ブロックIDをmDiyo's4096IDで実装(したがって, 実質拡張ID数は4096-256ではないことに注意)
- 新しい鉱石辞書, IOreHandlerによるものではなく, 文字列によって管理される辞書形式
MCPのコマンド
- decompile.bat
- mcp/jars以下にあるminecraft.jar, minecraft_server.jarをデコンパイル
- recompile.bat
- mcp/src以下にあるソースファイルを再コンパイル
- cleanup.bat
- デコンパイルで追加されたファイル, フォルダを削除
- startclient.bat
- 再コンパイルされたクライアントを起動
- startserver.bat
- 再コンパイルされたサーバーを起動
- updatemcp.bat
- MCPをアップデート
- updatemd5.bat
- 再コンパイルされたjarファイルのMD5を更新
- updatenames.bat
- updatemcp.batで更新されたメソッド名を, 現在デコンパイル済みのソースコードに反映させる
- updateids.bat
- updatemcp.batで更新されたidを, 現在デコンパイル済みのソースコードに反映させる
- getchangedsrc.bat
- mcroot/modsrc以下に追加されたソースを出力
- reobfuscate.bat
- mcroot/reobf以下に配布用のclassファイルを出力
- reformat.bat
- (おそらくだが)src以下にあるjavaファイルを特定のスタイルに整形する
チュートリアル
非公式フォーラムにあるチュートリアルをまとめたもの. Forge利用の場合はBaseModではなくNetworkModから継承する.
初級
中級
バニラの内部データ
バニラのデータ構造
クラス
- Block
- ブロックの基本クラス, ブロックを追加する際は基本的にこのクラスを継承する.
- Item
- アイテムの基本クラス, アイテムを追加する際は基本的にこのクラスを継承する.
- Entity
- エンティティ(動体)クラス, Mob, ボート, トロッコなどの「動くもの」の基本クラス, エンティティを追加する際は基本的にこのクラスを継承する.
- BlockContainer
- ブロックの派生クラス, GUI, 内部インベントリを持つブロックを追加する際はこのクラスを継承する.
- TileEntity
- ブロックに「貼り付けて」特殊な機能を持たせたり, 特殊なレンダリングを定義するクラス. 竈のようなブロックで使う.
mDiyo's 4096IDについて
- 256~4095はアイテムIDとのハイブリッド
- アイテムIDと重複している場合, アイテム作成でブロックが作成されるようになるので重複は避ける
- とはいえバニラのアイテムIDは256~385, 2256~2266しか使っていないので, 思う存分使用可能
- Modで追加されるアイテムIDもブロックIDと重複しないようにする
- Modで追加されるアイテムIDは4096以降にすればひとまずブロックIDとの競合を避けられる
各種詳細
GUI追加
GUIを追加するにはGui自体の描画を管理するGuiHogeHoge(GuiContainerを継承)と, 内部のスロットを管理するContainerHogeHoge(Containerを継承)が必要.
GUIを呼び出す処理についてはForgeインタフェースのIGuiHandlerを参照のこと.
Forge ModLoader Modding
BaseModではなくNetworkModから継承する. サーバー用MODに必要なクラスは, クライアント用MODからレンダー, モデル, GUIが不要. またグラフィックスの指定も不要.
Entity追加
ModLoader.registerEntityID(Entity_.class, "name", entity_id);
MinecraftForge.registerEntity(Entity_.class, NetworkMod, entity_id, 160, 5, true);
ModLoader.registerEntityIDは従来のEntityID登録と同じ. ただしSMP用はgetUniqueEntityIDよりも, 自明なID(0~255?)を使うほうがいい.
MinecraftForge.registerEntityの引数のうち, 後半3つは
- 範囲, SMP上でEntityの情報を更新するかどうかの範囲
- 更新頻度, MLMPと同じ?何tickごとに更新するかなので, 5なら1秒(20tick)に4回更新
- 更新に速度が含まれるかどうか, addVelocityのようなメソッドを持つクラスの場合true, そうでないならfalse
GUI追加
IGuiHandlerを実装する.
ModLoader API
独自モデルのブロック追加
基本的なブロックの追加とほとんど同じだが, BaseMod(NetworkMod)クラスのコンストラクタで新しいrenderTypeを取得する必要がある.
newRenderType = ModLoader.getUniqueBlockModelID(this, true)
ブロックのレンダリング自体は, BaseModのrenderInvBlock(), renderWorldBlock()をオーバーライドすることで適用される.
public void renderInvBlock(RenderBlocks renderblocks, Block block, int metadata, int renderType)
public boolean renderWorldBlock(RenderBlocks renderblocks, IBlockAccess iblockasscess, int x, int y, int z, Block block, int renderType)
renderInvBlock()はインベントリ内のブロックを描画するメソッド, renderWorldBlock()はワールドに設置されたブロックを描画するメソッドである.
modding for 1.3
公式側のクライアント側とサーバー側のコードの統一にならい, FML, Forgeでもクライアントとサーバーのコードはほぼ統一されている.
moddingにおいても, 入出力, 描画以外はcommon下に置かれる.
以下現在のmoddingメモ(forge4.0.0.200)
- ForgeはもはやModLoaderを必要としない, BaseMod(NetworkMod)を継承する必要はない
- FMLはModLoaderとの互換性のためにBaseModやModLoaderなどを提供しているが, FMLのメソッドを呼び出すためのラッパークラスでしかない
- BaseModやModLoaderに依存していた箇所はインタフェースやプロクシパターンによって完全に独立している
- フォルダ構成の例
common以下にrgn, rgn/mods/modnameに共通のコードを, rgn/mods/modname/clientにクライアント専用のコードを置いている.
- GUIはIGuiHandlerをCommonProxyで実装
- カスタムパケットはIPacketHandlerをPacketHandlerで実装
- ブロックのカスタムレンダリングはISimpleBlockRenderingHandlerを実装し, ClientProxyでRendererRegistryに登録
- ModLoaderの機能は細分化され別々のクラスになっている
たとえばModLoader.registerBlock()はGameRegistry.registerBlock(Block)
ModLoader.addRecipe()はGameRegistry.addRecipe()
ModLoader.addName()はLanguageRegistry.addNameForObject()
- BaseModを継承せずアノテーションで作成した場合, 実環境ではmcmod.infoファイルが必要になる
- mcmod.infoのサンプルはcpw氏のironchestにある
最終更新:2012年08月18日 17:00