Geyser拡張とカスタムBedrockエンティティ
リソースパックを変換すれば、Bedrockプレイヤーはアイテムの正しいテクスチャとモデルを見られるようになります。しかし、真のカスタムエンティティ — アーマースタンドとして表示されるのではなく、モデル化されたボスがきちんと描画されアニメーションする状態 — を実現するには、Geyser自身の内部で動作するコードが必要です。それを担うのがRSPMのGeyser拡張です。
これは別途ダウンロードするものではありません。プラグインとしてインストールするのと同じ ResourcePackManager.jar が、そのまま拡張機能でもあります。
1つのJar、3つの役割
ResourcePackManager.jar は同時に次の3つです：
- Bukkit/Paperのバックエンドプラグイン
- VelocityおよびBungeeCord/Waterfallのプロキシプラグイン
- Geyser拡張
どのローダーが開いたかに応じて、適合するエントリポイントが選ばれます。旧バージョンでは別途 ResourcePackManager-GeyserBridge.jar を配布していましたが、このファイルは廃止されており、RSPMが残存ファイルを自動的に片付けます。
インストールの仕組み
RSPMは可能な場合に拡張を自動でインストールします。動作はGeyserがどこにあるかによって変わります：
| 構成 | RSPMの動作 |
|---|---|
| 同じサーバー上のGeyser-Spigot | 実行中のjarを plugins/Geyser-Spigot/extensions/ResourcePackManager.jar にコピーします。すでに別のバージョンが置かれている場合は、代わりにGeyser自身の更新キュー extensions/update/ に新しいものをステージングします。いずれの場合も、一度再起動するよう促すコンソール行が出力されます。 |
| プロキシ上のGeyser（Geyser-Velocity / Geyser-BungeeCord） | プロキシ側の役割が、プロキシの Geyser-*/extensions/ フォルダに対して同じ処理を行います。 |
| Floodgateがローカル、Geyserが外部（Geyserが別プロセスで動作） | RSPMはそのプロセスに手が届きません。plugins/ResourcePackManager/geyser-extension/ にコピーを書き出し、そのjarを外部Geyserの extensions/ フォルダにコピーしてGeyserを再起動するよう警告します。 |
| GeyserもFloodgateも存在しない | 何もすることがありません — RSPMは情報行をログに出し、インストールをスキップします。 |
すでに extensions/ にある新しいバージョンが、古いバージョンで上書きされることはありません。
インストールには必ず一度の再起動が必要です。 Geyserは起動時に拡張を読み込むため、コピーまたはステージングされたばかりのjarは、サーバーまたはプロキシが再起動するまで何も行いません。
自動インストールをオフにする
役割ごとに独立したスイッチがあります：
| 場所 | 設定 | 既定 |
|---|---|---|
バックエンド plugins/ResourcePackManager/config.yml | geyserExtensionAutoInstall | true |
プロキシ config.yml | geyser-extension-auto-install | true |
どちらかを false にすると、その役割は拡張のインストールや更新のステージングを行わなくなり、その旨をログに出力します。意味を正確に読み取ってください：
- 今後のインストールと更新のステージングを防ぎます。
- すでに
extensions/にある拡張jarを削除することはありません。Geyserがそのファイルを開いているためです。ブリッジを実際に無効化するには、フラグをfalseにし、Geyserを停止し、extensions/からRSPMのjarを手で削除してから、再度起動してください。 - オフにしてもパックの変換や配信には影響しません。アイテム、テクスチャ、モデルは引き続き変換・配信されます。止まるのはカスタムBedrockエンティティだけです。
バックエンドでこれをオフにすると、ダウンロードしたRSPMの更新をローカルのGeyser-Spigotの更新キューへステージングする処理もスキップされるため、拡張とプラグインのバージョンが乖離しうるようになります — 下記の互換性ガードは、まさにこの状態を捕捉するために存在します。
拡張が実際に行うこと
- RSPMのカスタムBedrockエンティティ定義をGeyserに登録します。起動時に、生成されたBedrockパックからエンティティ識別子を読み取ります。
- スポーンするエンティティのBedrock定義を差し替え、モデル化されたエンティティがバニラのフォールバックではなく、専用のカスタムBedrockエンティティとしてスポーンするようにします。
- エンティティが存在する間、ライブのエンティティデータとプロパティのオーバーライドを適用します。
- GeyserのレシピネットワークIDを早期に初期化します。これによりGeyser 2.11で発生しうるレシピID衝突の問題を回避できます。
これらの定義が参照するBedrock側のアセットは、Bedrock変換で説明しているエンティティバンドルに由来します — プラグインが assets/<namespace>/rspm_bedrock_pack/ 配下にネイティブのBedrockエンティティファイルを同梱し、RSPMがそれらを生成パックへ取り込みます。
Geyserのバージョン要件
拡張はGeyser 2.11以降を対象としています。
その記述子は意図的に低めのGeyser APIレベル（2.9.0）を宣言しています。そのため、古いGeyserはjarを即座に拒否するのではなく、素直に読み込みます。本当の要件は実行時に強制されます：拡張は必要なクラスの有無をプローブし、それらが存在しなければ自分を無効化します。これにより、オペレーターには解釈しようのないロード時の拒否ではなく、明確なメッセージが得られます。
クラスやリンケージの非互換が起きてもGeyser本体を巻き添えにして落とすことがないよう、フェイルクローズで設計されています。拡張のシェル自体は長期間安定しているGeyser APIの型しか参照せず、バージョン依存のクラスはコアの起動前にプローブされます。使用中のGeyserビルドにブリッジが必要とするクラスが含まれていない場合、ブリッジは自分自身を無効化し、その旨を通知します：
Disabled the RSPM custom Bedrock entity bridge: this Geyser build does not ship
<class>. Geyser itself is unaffected, but custom Bedrock entities will not appear until a ResourcePackManager update matches this Geyser version.
その状態でもアイテム、テクスチャ、モデルは通常どおり変換・配信されます。影響を受けるのはカスタムエンティティだけです。対処法はGeyserを更新するか、使用中のGeyserビルドに対応したRSPMのリリースを待つことです。
以前のRSPMバージョンでは、Geyserの内部パケットトランスレーターをベンダリングしたコピーをGeyserのレジストリに差し込むことで同じ結果を実現していました。このトランスレーター置き換えは廃止され、拡張は登録とスポーン定義の差し替えにGeyser 2.11の公開エンティティライフサイクル／イベントを使うようになりました。それでもコアは、定義インスタンスの構築と下流のプラグインメッセージ受信に使う一部のGeyser内部をプローブします。互換性ガードと、RSPM／Geyserのバージョンを正確に揃えることが依然として重要なのはこのためです。
順序の問題：再起動が必要になる場合がある理由
Geyserは自身の起動ウィンドウ中にエンティティ定義を登録します。RSPMがBedrockパックの生成を終えるのがそのウィンドウが閉じた後になった場合 — 新規インストール直後、つまり起動時点でまだパックが存在しないケースがまさにこれです — 定義の到着が遅すぎて、凍結済みのGeyserのレジストリに入れなくなります。RSPMはそれらを次回の起動用に保持し、次のように警告します：
RSPM custom Bedrock entity definitions became available after Geyser closed its startup registration windows ... restart the proxy once to activate the newly generated custom models.
最初のパック生成が成功した後に、Geyserをホストしているサーバーまたはプロキシのプロセスを一度再起動してください。再接続するだけでは、起動ウィンドウを逃した定義を有効化できません。以降の起動では、Geyserが登録ウィンドウを開く時点で既にパックが存在するため、順序は正しくなります。
動作確認の方法
- 対象の
extensions/フォルダに実際にResourcePackManager.jarが存在するか確認します。 - 起動時に、Geyserが拡張を読み込み済みとして一覧表示し、RSPMが登録したカスタムBedrockエンティティ定義の数をログに出力するはずです。
- Bedrockで参加し、モデル化されたエンティティを見てください。モデルではなくアーマースタンドが表示される場合は、拡張が読み込まれていないか、パックがクライアントに届いていないか、定義の到着が遅れたかのいずれかです — 上記の警告をこの順で確認してください。
トラブルシューティング
「拡張は読み込まれているのに、エンティティが依然としてアーマースタンドのまま」 パックと拡張は別々の半分です。まずBedrockパック自体がクライアントに届いているかを確認してください（Bedrock変換を参照）。パックのエンティティアセットがなければ、定義が描画すべき対象が存在しません。
「動いていたのに、Geyserを更新したらエンティティが壊れた」 上記の自己無効化メッセージを探してください。Geyserの更新により、ブリッジがプローブするAPIの構成が変わることがあります。
「extensions/ に何もインストールされたことがない」 コンソールで Automatic Geyser extension installation is disabled by geyserExtensionAutoInstall（バックエンド）または ... by geyser-extension-auto-install（プロキシ）を探してください。誰かがスイッチをオフにしています。GeyserとFloodgateの両方がローカルに存在しない場合は、代わりに Geyser-Spigot and Floodgate were not detected locally; skipping automatic Geyser extension installation が表示されます — これは、インストール先が何もないとRSPMが正しく判断した結果です。
「RSPMを更新したのに、拡張が古いバージョンのまま」 拡張が置き換わるのは再起動時のみです。RSPMがGeyserの更新キュー経由でステージングした場合は、差し替えのために一度の再起動が必要です。プラグインjarと拡張jarのバージョンは揃えておいてください — 両者は同じファイルなので、プラグインを再度コピーするだけで十分です。
Velocityでは、Geyserの自動的な拡張サブスクリプションが他のプラットフォームと同じようには発火しないため、プロキシプラグインがライフサイクルイベントを自前で中継します。これは内部で処理されるため、設定は不要です。
次に読むページ
- Bedrock / Geyser変換 — 何が変換され、パックがどのように配信されるか
- プロキシネットワーク — プロキシ上のGeyser
- トラブルシューティング