プロキシネットワーク（BungeeCord／Waterfall／Velocity）
ResourcePackManagerはプロキシネットワークで動作します。バックエンドプラグインを各バックエンドで実行し、別のプロキシプラグイン（VelocityまたはBungeeCordのどちらか一方、両方は不可）をプロキシで実行します。両者は共有された plugins/floodgate/key.pem ファイルを介して自動的に互いを認識します。
プロキシプラグインの役割
プロキシプラグインの仕事は、Bedrockパックのマージと配信です。複数のバックエンドがあるネットワークでは、各バックエンドが独自のBedrockパック（マージされたJavaパックの変換版）を生成します。プロキシプラグインは：
- 各バックエンドの小さなHTTPサーバーから
/bedrock.zipと/mappings.jsonを5秒ごとにポーリングします。If-Modified-Sinceを使うため、変更のないファイルの帯域コストはほぼゼロです。 - インボックスの状態が連続2回のポーリングで安定するのを待ちます。
- すべてのバックエンドのBedrockパックを1つのネットワーク全体パックにマージします。
- マージされたGeyserカスタムマッピングファイルをプロキシの
plugins/Geyser-*/custom_mappings/にコピーします。 - 接続時にGeyserの
SessionLoadResourcePacksEventを通じてマージされたパックをBedrockクライアントに配信します。
プロキシプラグインはBedrockプレイヤーにのみ有用です。 ネットワーク上のJavaパック配信は、依然として通常の setResourcePack ／ addResourcePack API を通じてバックエンドごとに行われます — Javaクライアントには、接続中のバックエンドが送ることを選んだパックが表示されます。ネットワークがJava専用なら、プロキシプラグインは不要です。
セットアップ — 2ステップ
ステップ1：プロキシとすべてのバックエンドにFloodgateをインストールする
Bedrockプレイヤーがプロキシで認証するためにFloodgateが必要です。RSPMはFloodgateの plugins/floodgate/key.pem に乗ってネットワークアイデンティティを導出します — そのファイルはプロキシとすべてのバックエンドでバイト単位で同一でなければなりません。FloodgateはBedrock認証のためにこれを既に要求しているので、現在Bedrockプレイヤーがネットワーク全体で動作しているなら、これはすでに完了しています。
まだFloodgateがない場合は、各コンポーネントにインストールし、続行する前に1つの正本 key.pem を他のすべてのコンポーネントにコピーしてください。
ステップ2：任意のバックエンドから対応するプロキシ用jarをコピーする
バックエンドのRSPMが少なくとも一度起動した後、次のフォルダーを確認してください：
plugins/ResourcePackManager/proxy-extension/
そのフォルダーには以下が含まれています：
ResourcePackManager-Velocity.jar
ResourcePackManager-BungeeCord.jar
README.md （加えて9言語の翻訳README）
バックエンドは検出されたトポロジーにかかわらず起動のたびに両方のjarを展開するため、いつでも利用できます。ちょうど1つだけをプロキシの plugins/ フォルダーにコピーしてください：
| プロキシソフトウェア | 使用するjar |
|---|---|
| Velocity | ResourcePackManager-Velocity.jar |
| BungeeCord | ResourcePackManager-BungeeCord.jar |
| Waterfall（Bungeeフォーク） | ResourcePackManager-BungeeCord.jar |
両方を入れないでください — 対応するものだけです。両方を入れると、間違ったプラットフォームで読み込もうとしたほうで起動エラーが発生します。
プロキシを再起動します。これだけです。
編集すべき設定もなく、貼り付けるべきキーもありません。プロキシプラグインは起動時にプロキシ上の plugins/floodgate/key.pem を読み、そこからネットワークアイデンティティを導出します。Floodgateはそのファイルがすべてのバックエンドとプロキシで同じであることを既に要求しているため、導出されたキーは各バックエンドのものと自動的に一致します。
最初のマージは通常、すべてのバックエンドが起動してから ~10 秒以内に完了します。
動作確認
プロキシコンソール
再起動から ~10 秒以内（バックエンドが起動中であると仮定）に、次のような出力が見えるはずです：
[ResourcePackManager] Network-key auto-derived from Floodgate key.pem ✓
[ResourcePackManager] NetworkSync starting (poll interval 5000 ms, ...)
[ResourcePackManager] Merged pack ready at .../merged/Bedrock.zip (sha1 ...)
[ResourcePackManager] Geyser mappings deployed to .../custom_mappings
[ResourcePackManager] ✔ Network resource pack is now ready (... KB, sha1ABCD1234)
プロキシでの /rspm status
スナップショットを表示します：バックエンド一覧、バックエンドごと／パスごとの取得結果（200／304／404／CONNECT_FAILED）、連続空ポーリングカウンター、現在のマージ済みパックのパスとサイズ、network-http-offset、プロキシでのFloodgate／Geyserの有無。resourcepackmanager.command.status または resourcepackmanager.* が必要です。コンソールは常に両方を持ちます。プレイヤーに実行させたい場合は、権限プラグイン経由でいずれかを付与してください。出力には秘密情報が現れない（ネットワークキーはマスクされ、認証トークンもありません）ため、寛容に付与しても安全です。
バックエンドでの /rspm status
Deploy mode 行が network-backend になっているはずです。Network key 行にはマスクされたキー（末尾4文字が見える）が表示されます — それをプロキシのマスクされたキーと突き合わせて、両側が一致しているか確認してください。
Bedrockクライアント
Bedrockで接続します。ワールドに到達する前にリソースパックのダウンロードプロンプトが表示されるはずです。カスタムアイテムは、ただのアーマースタンドではなく意図したモデルで描画されます。
設定リファレンス
バックエンド plugins/ResourcePackManager/config.yml
ネットワークモードは自動検出されます — networkMode: true のようなフラグを設定する必要はありません。検出シグナル（いずれか1つで十分）：
- Floodgateが存在し、Geyser-Spigotが存在しない — Bedrock-via-proxyケースの最強シグナルです。
spigot.yml: settings.bungeecord: true— 旧来のBungeeCord／Waterfall IP転送スイッチです。paper-global.yml: proxies.velocity.enabled: true— モダンなVelocity転送です。
ネットワークモード固有で重要な唯一のつまみは networkHttpOffset-v2 で、プロキシが各バックエンドでポーリングするHTTPポートを制御します。既定 1 はほぼすべてのホスティングで動作します。完全なポート解決の話はセルフホストを参照してください。
プロキシ plugins/ResourcePackManager/config.yml
プロキシプラグインは初回起動時に最小限の既定設定を書き出します：
# クライアントにパックの受け入れを強制する（拒否したらキック）。既定: false。
force-resource-pack: false
# 各バックエンドのMinecraftポートに加算してHTTPポートを導出するオフセット。
# このプロキシは /bedrock.zip と /mappings.json をそのポートに対してヒットします。既定 1。
# 各バックエンドの networkHttpOffset-v2 と一致させる必要があります。
network-http-offset-v2: 1
network-key エントリは意図的にありません — それは手動貼り付けが誤設定（タイポでサイレントにプロキシ↔バックエンドのリンクが壊れる）の主原因だったため、プレリリース段階で廃止されました。キーは plugins/floodgate/key.pem から自動導出されます。
安定性とマージのケイデンス
プロキシはマージ前に、インボックスの状態が連続2回のポーリングで安定するのを待ちます。既定の5秒間隔では、最初のマージはプロキシが少なくとも1つのバックエンドがコンテンツを生成しているのを見ることができるようになってから ~10 秒後に行われます。それ以降のマージは、インボックスファイルのSHA-1集合が変わったときだけ再ZIP化されるので、長い静寂期間のコストはほぼゼロです。
直接取得 vs リレーフォールバック
既定の経路は直接取得です：プロキシは各バックエンドに対して http://<backend-host>:<mcPort + offset><path> にHTTP GETを行います。
プロキシがバックエンドのHTTPポートに直接到達できない場合（共有／マネージドのMinecraftホスティングでMCポートは公開されているが隣接ポートはファイアウォール越し、というケースが典型）、バックエンドは自分の bedrock.zip と mappings.json を、ネットワークのネームスペース下（Floodgateキーから導出される）にある magmaguy.com のリレーエンドポイントにプッシュします。直接取得がハード失敗したとき、プロキシはリレーを一覧してダウンロードします。
両方の経路が同じマージステップにフィードされるため、オペレーターが選ぶ必要はありません — 直接取得が優先（magmaguy.com への帯域コストゼロ）で、必要なときにリレーが透過的に動作します。
リレーのサーバー側TTLは30分です。バックエンドはエントリを生かしておくため25分ごとにプッシュします。クリーンシャットダウンではTTLを待たずに即座にエントリを落とします。
よくある問題のトラブルシューティング
起動時に「Floodgate key.pem missing」と表示される
プロキシプラグインが plugins/floodgate/key.pem を見つけられず、アイドル状態になりました。RSPMはそれなしではどのバックエンドにもリンクできません。
修正：プロキシにFloodgateをインストールし、プロキシの plugins/floodgate/key.pem がすべてのバックエンドの同名ファイルとバイト単位で同一であることを確認してください。Floodgateは既定でインストールごとに異なるキーを自動生成するため — 任意のバックエンドから1つの正本 key.pem を他のすべてのコンポーネントにコピーし、すべてを再起動してください。
~20秒後に「No merged pack content」警告が出る
連続4回の空ポーリングサイクルの後、プロキシはポーリングしたすべてのバックエンド、試行したURL、結果を列挙する1回限りの複数行警告をログ出力します。警告は最もよくある修正方法を説明します：
- すべてのバックエンドで
CONNECT_FAILED— プロキシがバックエンドのHTTPポートにまったく到達できません。velocity.toml／config.ymlのアドレスがプロキシから実際に到達可能なもの（プロキシのネットワークから解決できないDockerの内部名ではない）であること、そしてmcPort + networkHttpOffset-v2がプロキシとバックエンド間で開いていることを確認してください。そのポートを開く手段がない（マネージドホスティング）場合は、上記のリレーフォールバックセクションを参照してください — バックエンドが自動でリレーにアップロードしているはずです。 - すべてのバックエンドで
NOT_FOUND_404— バックエンドは起動していますが、Bedrockパックを生成していません。各バックエンドで/rspm statusを実行してください。Bedrock Packの診断ブロックが理由を教えてくれます（最も多いのは、マージされたパックにアイテム定義がない、または最初のミックスサイクルがまだ完了していない、です）。
警告は詰まった期間ごとに1回発火します。少なくとも1つのバックエンドがコンテンツを返し始めると NetworkSync: recovered 行がログに出力されます。
初回プロキシ起動時にBedrockプレイヤーにカスタムモデルが見えない
Geyserはプロキシ起動時にだけカスタムアイテムテーブルを登録します。Bedrockパックを生成したバックエンドより先にプロキシが起動した場合、Geyserは空のマッピングテーブルで動作し、そのセッションの残り時間ずっとそのままになります。
修正：バックエンドが最初の Merged Bedrock pack published 行をログに出した後、プロキシを一度再起動してください。RSPMはプロキシ起動のたびに前回実行時のマッピングを事前デプロイするので、これが噛むのは新規インストール時のみです — 以降の起動では、Geyserがスキャンする前に何かが用意されています。
起動時に「Duplicate bedrock_identifier」警告が出る
2つのバックエンドが同じベースアイテムに対して同じBedrock識別子を出力しました。後勝ち；そのアイテムを提供するバックエンドが1つだけでよいなら無害です。両方のバックエンドが同じベースアイテムで別々のカスタムアイテムをホストすべきなら、自動生成されるハッシュが異なるように、ソースとなるJavaモデルのいずれかをリネームしてください。
Bedrockプレイヤーが接続したのにパックが見えない
プロキシは、Bedrockセッションが使用可能なRSPMパックなしでロードされたとき、オンラインのすべてのJavaプレイヤーにチャットバナーを発火します：
⚠ [RSPM] Bedrock player Alice connected before the resource pack was ready — they're seeing plain armor stands instead of custom models. Tell them to disconnect and reconnect; the pack will load on their next session. (Cause: ...)
Bedrockプレイヤー自身もモーダルポップアップを受け取り、プロキシコンソールにもバナーが表示されます。さらに深く調査する必要がある場合は、デバッグストリームを有効にしてください（VelocityとBungeeCordの両方で利用可能）：
/rspm debug bedrock on
これは GeyserBinder からの詳細な [RSPM-BedrockDebug] ログ行をオンにします。問題を再現したら、オフにしてください：
/rspm debug bedrock off
設定はプロキシ再起動でオフにリセットされるため、誤って付けっぱなしになることはありません。
ネットワーク上でのRSPMの更新
バックエンドのRSPM jarをアップした後、任意のバックエンドの plugins/ResourcePackManager/proxy-extension/ から対応するプロキシ用jarも再コピーし、プロキシを再起動してください。バックエンドはこれらのjarを起動のたびに再生成するので、常にバックエンドのバージョンと同期しています。
まだサポートされていないこと
- プロキシプラグイン経由でのネットワーク上のJavaパック。 Javaクライアントは、通常のAPIを通じて各バックエンドから直接パックを受け取ります。プロキシ側のJavaパックミキサーはありません。
- バックエンドをまたいだJavaパックマージ。 各バックエンドのJavaパックは独立しています。プレイヤーがバックエンドを切り替えると、新しいバックエンドのパックを受け取ります。
- ネットワークキーのライブ再構成。 キーはFloodgateの
key.pemに紐付いています。変更にはプロキシとすべてのバックエンドの再起動が必要です（これはFloodgateキーをローテーションするときに行うことと同じです）。