More Player Modelsを使ってみた。

ぼーっとMinecraftの動画を見ていたら、プレイヤーのスキンやモデルを変更できるMOD「More Player Models」の紹介動画を見つけました。
http://www.youtube.com/watch?v=-CBm25HWkS4

人間の女性、エルフ、ドワーフ、モンスター、ケモノ等・・結構いろんなモデルが用意されています。
オプションも豊富で キャラの大きさ、翼、尻尾、爪、マズル、ケモノ耳 等、色々変更できちゃう。
さらに 座る、寝る、踊る、抱きつき(ゾンビの手を前にだすあれ) の4種類のモーションも用意されています。

なによりケモノのモデルが使用できるのが魅力的だったのですw

早速、自分のスキンをこのMODに対応させてみる。

スキンの設定は、ケモノ男、モデルサイズ2(標準が3)、マズル、ケモノ耳、尻尾。
うん、前よりわんk・・いやウェアウルフっぽくなりましたw

モーションはカート、ボート、ベッド等、既存の物を使用していない状態で使用可能。

モデルサイズ2の大きさ比較。

ちなみに、サイズによって視点の高さが変わるので視界がちょっと新鮮。
当たり判定は縦2ブロックのまま。
続きを読む

Minecraft v1.3.2用 Selectable Paintingsを公開

ようやくv.1.3用のSelectable Paintingsを公開する事ができました。
といっても、今までのModLoader+ModLoaderMPではなく、Forge専用としてのMODですが・・・
[ダウンロードはフォーラムへ]

なぜModLoader+ModLoaderMPじゃなくなったかというと・・
Entity関連のスポーン/デスポーンに問題があるからなんですよねー

EntityLivingとIAnimalsを継承しているEntityならスポーンしてくれるんだけれど、MobじゃないEntityはEntityLivingを継承するのは好ましくない・・・
ModLoaderMPにはそれを補うISpawnableという物があるけれど、外部サーバー⇔クライアントのものであり、内部サーバー⇔クライアントでは全く機能しないのです。
既存のEntityPaintingとPacket25EntityPaintingの書き換えとかも見当しましたが、NetClientHandler等の重要クラスの書き換えが発生するので却下。

 
そこで目を付けたのがMinecraftForge。
以前Selectable PaintingsをForgeに対応させた時に気づいたのだけれど、ForgeにもModLoaderMPと同じようなEntityのスポーンを補う機能があります。

 
丁度良くv4.0.0.204がリリースされたので早速使ってみました。
Forgeなら・・内部/外部サーバー⇔クライアント間のスポーンを補ってくれているはず・・・という期待を込めてAPIを見ていると・・・
・‥…━(゚∀゚)━━━☆

EntityRegistry.registerModEntityと言う物でネットワーク用のEntityを登録できるようです。
これはISpawnableにかわるもので、EntityにIEntityAdditionalSpawnDataを継承させることで使用可能に。

早速使ってみることにしましたが・・・ぬるぽ連発ヽ(`Д´)ノ
今までのBaseModを継承したMODの制作方法ではダメなんです。

で、これがその新しいMODの最小限のコード↓。

package Kerberos.SelectablePaintings;
 
import java.io.*;
import java.util.*;
import cpw.mods.fml.common.*;
import cpw.mods.fml.common.event.*;
import cpw.mods.fml.common.network.*;
import net.minecraft.src.*;
 
@Mod(modid = "SelectablePaintings", name="Selectable Paintings", version="1.0.6 Beta1 for MC1.3.2")
@NetworkMod(clientSideRequired = true, serverSideRequired = true, channels = {"SelectablePaint"})
public class SelectablePaintingsCore implements IPacketHandler {
    @SidedProxy(clientSide = "Kerberos.SelectablePaintings.ClientProxy", serverSide = "Kerberos.SelectablePaintings.CommonProxy")
    public static CommonProxy proxy;
 
    @Mod.Instance
    public static SelectablePaintingsCore instance;
 
    public static final String modChannel = "SelectablePaint";
 
    @Mod.Init
    public void Init(FMLInitializationEvent event) {
        proxy.registerRenderInformation();
        NetworkRegistry.instance().registerChannel(this, modChannel);
 
        System.out.println("mod loaded");
    }
 
    // abstract IPacketHandler
    public void onPacketData(NetworkManager manager, Packet250CustomPayload packet, Player player) {
    }
}

@Modで普通のModとして登録し、@NetworkModでregisterModEntity等で必要なネットワーク用Modとして登録を行います。
更にIPacketHandlerを継承する事で、独自のパケットを送受信できるようになります。

コードを見てアレ?って思った方が多いんじゃないでしょうか・・
そう、もうmod_xxxという形式に捕らわれず、パッケージも変更でき、クラス名も独自クラスとして独立した物となっています。
loadやgetVersion等の固定メゾットが必要ありません。

そしてもう一つ・・・
クライアントとサーバー用のMODリソースは共通なんです。
1つ作ればクライアントとサーバーの両方で使えるMODが出来上がり!

ただし、EntityやTileEntity等の同期が必要なものはちゃんと同期できるようにパケットを送ってやる必要があります。
これは今までと同じですねー

今現在のForge 4.0.0.204はサーバー側に問題があって、アイテムの登録時にクライアント側のコードが呼び出されクラッシュします。
シングルからのLANで公開できるマルチプレイは使用可能。

 

いやーそれにしても、リソースの管理楽すぎ。
全MODをForgeに移行しちゃおうかしら・・・

新しいMODを公開。


そう、フェンスとフェンスゲートに使用した木材と同じ色がつくように(`・ω・)b
[ダウンロードはフォーラムへ]

ついでというか、棒(Stick)も使用した木材の色によって色が違う棒ができるように。
地味にこの色違いの棒を作るのに苦労しましたw
既にレシピが存在していたので、どの色の木材を使っても普通の棒ができるから・・・

なのでCraftingManagerからレシピの一覧を引っ張ってきて、既存の棒を作成するためのレシピを削除。
削除といっても、削除用のメゾットは用意されていないので自作。

棒のレシピを削除するサンプルは↓

List recipes = CraftingManager.getInstance().getRecipeList();
for (int i=0;i<recipes.size();i++) {
    ShapedRecipes recipe = null;
    try {
        recipe = (ShapedRecipes)recipes.get(i);
    } catch (Exception e) {
        continue;
    }
 
    ItemStack itemstack = recipe.getRecipeOutput();
    if (itemstack.itemID == 280) {
        recipes.remove(i);
        break;
    }
}

いやー短いコードww
ItemStackの所で参照する部分を間違えていたので、それに気づくのに30分以上かかりましたw

MinecraftのMODを作ってる方ならわかると思いますが、itemstack.itemID == 280の式があるところで削除しています。
棒のIDは24だけど、アイテムなのでID+256で280。

Minecraft v1.3.1 MOD公開!

フォーラムの方で、Minecraft v1.3.1用のMODを公開しました。
前提MODはModLoader+ModLoaderMP。

なぜModLoaderMPが前提になっているかというと、
公式に内蔵されているPacket250CustomPayloadだけでパケットは自由にできるのですが、
外部サーバーにはModLoaderが用意されていないので外部サーバーはModLoaderMPでMODを使用できるようにするしかないのです。

じゃあ外部サーバーだけModLoaderMPを使えばいいんじゃない!と思うかもですが、クライアント側も同じBaseModMpを継承したMODがないと接続できない・・
なので、ModLoader+ModLoaderMP。

ちなみに、Selectable PaintingsはレンダリングするためのRenderが呼び出されない謎の症状で難航中・・・_| ̄|○
どうなってるのーヽ(`Д´)ノ

Minecraft v1.3.1 MOD作成開始。

Minecraft v1.3.1がリリースされてから暫く経ちましたねー。
すぐにv1.3.2が来ると思っていたけれど来る気配がないし、ModLoaderとModLoaderMPもリリースされたのでv1.2.5のMODをv1.3.1に対応させて行くことにしました。

v1.3からのシングルプレイはクライアントの内部にマルチプレイサーバーとほぼ同じサーバーを建てて、そこに接続しプレイする感じになったのです。
この仕様変更で、TileEntityを多用しているうちのMODは結構大幅な更新が必要に・・・_| ̄|○

v1.3以前にもマルチに対応させていたので、TileEntityの同期には「TileEntityのデータ転送パケットを送ってやらないといけない」のは知っていましたが、
内部サーバーとクライアントの同期にもパケットを送ってやらないと、正常に同期してくれない・・・

幸い公式でForgeと全く同じ仕様のPacket250CustomPayloadを実装してくれているので、内部サーバーとクライアントの同期は取れる。
しかし外部サーバー用のModLoaderは公開されていないので、外部サーバーは必然的にModLoaderMPのPacket230ModLoaderを使用して同期する必要がある。

てことは、サーバーとクライアント間で双方向にパケットを送っている場合は、
内部サーバーとクライアント用に、clientCustomPayload と serverCustomPayloadを。
外部サーバーとクライアント用に、handlePacket と handleTileEntityPacketをOverrideしなきゃいけなくなるのです。

やる事は簡単なんだけれど、これ非常にめんどくさい。
なので、もしかすると全MODをForge前提にするかもしれません。
Forgeが出るまではModLoaderを使用しシングルプレイのみの対応です。

他のMODは近いうちに公開します。