Resource Pack Manager FAQ

ここに回答がない場合は、まずサイドバーのResourcePackManagerの他のページを確認してください。

ResourcePackManagerが現在公開しているコマンドは？

バックエンド（Paper／Spigot）でコードに裏付けられているコマンド一覧は次のとおりです：

• /rspm setup — ゲーム内のGUIセットアップメニューを開きます（プラグインの更新状況、推奨プラグイン、自動更新トグル、wiki／Discord／Nightbreakアカウントへのリンク）
• /rspm recommendedplugins — 共有のNightbreak推奨プラグインメニューを表示します（コンソールではテキスト一覧）
• /rspm downloadpluginupdate — 利用可能なResourcePackManagerの更新を次回の再起動用にダウンロードします
• /rspm downloadall — このプラグインが公開しているすべての利用可能な更新をダウンロードします（現時点ではResourcePackManagerの更新）
• /rspm reload — マージされたパックを再構築し、再ホストします
• /rspm status — 完全な診断ダンプ（パックの状態、ホスティングモード、ネットワークキーのフィンガープリント、統合）
• /rspm verbose [on|off] — 詳細な診断ログをオン／オフします。引数なしの場合はトグルします。結果は config.yml の verboseLogging に書き戻されるため、再起動をまたいで保持されます。/rspm verboselogging としても受け付けられます。
• /rspm itemsadder configure — RSPMによるホスティング向けにItemsAdderを設定します
• /rspm itemsadder dismiss — あなたのプレイヤーUUIDに対してItemsAdderの警告を恒久的に非表示にします
• /rspm data_compliance_request — このサーバー向けにリモートで保存されているデータをすべてダウンロードします

ルートコマンドは /resourcepackmanager で、エイリアスとして /rspm が使えます。上記の更新系コマンドと推奨プラグインのコマンドは、RSPMが登録する共有のMagmaCore／Nightbreakコマンドです。

バックエンドの権限：

• /rspm setup と /rspm recommendedplugins には resourcepackmanager.setup が必要です。/rspm setup はインベントリGUIを開くためプレイヤー専用です。
• /rspm downloadpluginupdate、/rspm downloadall、/rspm reload、/rspm status、/rspm verbose、/rspm itemsadder <configure|dismiss>、/rspm data_compliance_request には resourcepackmanager.* が必要です。

プロキシプラグイン（Velocity／BungeeCord）には診断コマンドのみがあります：

• /rspm status — プロキシ側のスナップショット：バックエンド一覧、バックエンドごとの取得結果、マージされたパックの状態、Geyser／Floodgateの検出
• /rspm debug bedrock [on|off] — VelocityおよびBungeeCord向け。GeyserBinder が出力する詳細な [RSPM-BedrockDebug] ログ行を切り替えます。「Bedrockプレイヤーが参加したのにパックが見えない」ケースの診断に使います。プロキシ再起動でオフにリセットされます。引数なしで実行すると現在の状態を表示します。

Velocityでは、プロキシコマンドは resourcepackmanager.command.status または resourcepackmanager.* を受け付けます。BungeeCordは resourcepackmanager.command.status ノードを正確に登録しますが、権限プラグインによってはワイルドカード展開でこれを満たせます。コンソールからも実行できます。出力は共有しても安全です — ネットワークキーは短い一方向ハッシュのフィンガープリントとしてのみ現れ、キーそのものが出ることはなく、トークンも出力されません — そのため寛容に付与して構いません。

現在サポートされているプラグインは？

ResourcePackManagerには、以下のプラグイン向けの統合エントリがあらかじめ用意されています：

• BackpackPlus
• BetterHUD
• BetterStructures
• CannonRTP
• EliteMobs
• EternalTD
• FreeMinecraftModels
• InfiniteVehicles
• ItemsAdder
• MegaBlockSurvivors
• MMOInventory
• ModelEngine
• Nexo
• Nova
• Oraxen
• RealisticSurvival
• ResurrectionChest
• ValhallaMMO
• vane-core

これらの統合は、そのプラグインがインストールされていて、設定されたローカルパスまたはリモートURLが利用可能な場合にのみ有効になります。

各統合は plugins/ResourcePackManager/compatible_plugins/ 配下に独自のYAML設定ファイルを持ちます。そこでプラグインごとに isEnabled、pluginName、localPath、url、zips、cluster、additionalLocalPath、reloadCommand をカスタマイズできます。cluster オプションを有効にすると、ResourcePackManagerはそのローカルパスを複数のリソースパックサブフォルダーが収められたディレクトリとして扱い、それらをすべてまとめてマージします。

自動プラグイン統合を1つだけ除外するには？

plugins/ResourcePackManager/compatible_plugins/ にあるその統合のファイルで isEnabled: false を設定し、/rspm reload を実行（または再起動）してください。RSPMは、その統合のために生成・登録したリソースパック入力を、生成されたミキサー用コピーも含めて取り除きます。priorityOrder からプラグインを削除しても除外にはなりません。そのパックが最低優先度に移るだけです。手動で追加したZIPを除外したい場合は、そのZIPを mixer フォルダーから削除するか移動してください。

ResourcePackManagerはItemsAdderと互換性がありますか？

はい。ResourcePackManagerはItemsAdder向けの組み込みヘルパーと警告フローを備えています。

ItemsAdderがインストールされていて、まだResourcePackManagerでホストできるように調整されていない場合、OPプレイヤーは参加から数秒後にクリック可能な警告を受け取ります。警告を恒久的に非表示にしたプレイヤーには再表示されません。そこから次の操作が可能です：

• /rspm itemsadder configure を実行して resource-pack.hosting.no-host.enabled: true を設定し、3つの protect-file-from-unzip 設定をすべて無効化し、compress-json-files: false を設定し、/iareload に続いて /iazip を実行してから、ResourcePackManagerをリロードします（約15秒後）
• /rspm itemsadder dismiss を実行すると、あなたのプレイヤーUUIDに対してその警告が恒久的に非表示になります

ItemsAdderが自身のホスティングモードのいずれかで既にパックをホストするよう設定されている場合、ヘルパーコマンドはそれを自動では上書きしません。先に手動でItemsAdderのホスティングを無効化するよう案内します。

自分のパックをマージに加えることはできますか？

はい。手元にあるものに応じて、置き場所は2か所あります。

完成した .zip はここに置きます：

plugins/ResourcePackManager/mixer

ファイル衝突時にどのパックが勝つかを制御したい場合は、plugins/ResourcePackManager/config.yml の priorityOrder に、.zip を含む正確なファイル名を追加してください。

未圧縮のパックフォルダー（assets/ ツリーと pack.mcmeta）はここに置きます：

plugins/ResourcePackManager/resource_pack

RSPMがそのフォルダーを自分でzip化し、priorityOrder の ResourcePackManager エントリとしてマージします。このエントリは既定リストの先頭にあるため、既定ではそのファイルがすべてのプラグインパックとの衝突で勝ちます。負けてほしい場合は、ResourcePackManager をリストのもっと下に移動してください。

関連する plugins/ResourcePackManager/blueprint フォルダーには、RSPMがすべてのマージに提供する pack.png と pack.mcmeta が入っています。マージされたパックのアイコンやメニュー内の説明を変えたいときは、この2つのファイルを編集してください。フォルダーは起動のたびに blueprint.zip へ再圧縮されます。

例：

priorityOrder:
  - ResourcePackManager
  - EliteMobs
  - MyCustomPack.zip

優先順位はどのように決まりますか？

priorityOrder は、上が最も優先度が高く、下が最も低くなります。

マージ不可能なファイルでは、優先度の高いパックが低いパックのファイルを置き換えます。マージ可能なJSONファイルでは、ResourcePackManagerは単純に置き換えるのではなく内容をマージします。

現在、コード上で次のものがマージ可能として扱われています：

• sounds.json
• lang または languages 配下の言語ファイル
• minecraft/models/item 配下のバニラのアイテムモデルJSON（これらは非再帰的にマージされます：パックをまたいで overrides 配列のみが結合され、ファイルの残りの部分は最優先のパックが勝ちます）
• アトラスファイル
• フォントファイル
• items/ 配下の1.21.4以降のアイテムモデル定義（フォーマット対応のマージ：predicateツリーをそのまま残し、異なるノードタイプに無理に再帰しません）

pack.mcmeta は特別にマージされます：最も高い pack_format が採用され、supported_formats の範囲はすべてのパックを覆うように拡張されます（整数、2要素の配列、{min_inclusive, max_inclusive} オブジェクト形式に対応）。オーバーレイエントリは統合され、sodium のような非標準のトップレベルキーも保持されます。オーバーレイエントリは1.21.9以降との互換のために min_format／max_format フィールドが欠けていれば追加されて正規化されます。

すべてのパックをマージした後、ResourcePackManagerはベースのアトラスソースをオーバーレイのアトラスファイルにマージします。これにより、Minecraftがオーバーレイを有効化したとき（例：ItemsAdderの ia_overlay_modern_atlas ／ ia_overlay_legacy_atlas）に、オーバーレイがベースのアトラスエントリを意図せず隠してしまうのを防ぎます。

それ以外のJSONファイルはマージではなく置換されます。

priorityOrder に記載されていないパックもマージには含まれますが、優先度は最低として扱われます。

バイト単位で同一な完全なZIP入力は、マージ前に重複排除され、最初（最も優先度の高い）コピーが残されます。マージ後、RSPMはよくあるJavaモデルの不具合を2つ修復します：可能な場合はモデルの最初の具体的なテクスチャから欠落した particle テクスチャを補い、不正なモデルのUV座標をMinecraftの 0..16 の範囲にクランプします。

ResourcePackManagerはパックが変わったときに自動で再構築しますか？

はい。対応するパックのソースの変更を監視します。

監視対象のパックが3秒間変更されなかったとき、ResourcePackManagerはそれを安定したとマークします。すべての監視対象パックが安定したら、ただちに再ミックスが行われます。その移行中、オンラインのOPプレイヤーには「All resource packs are stable. Mixing and sending now.（すべてのリソースパックが安定しました。ミックスして送信します。）」と通知されます。

入力が前回とバイト単位で完全に同一な再ミックスでは、再マージは行われません。RSPMはソースパックの順序付きリスト（名前、サイズ、コンテンツハッシュ）のフィンガープリントを取り、出力の隣に .rspm_mix_fingerprint として保存します。フィンガープリントが一致し、期待されるすべての出力ファイルが残っている場合は、再構築するのではなく既存のzipを再公開します。少しでも疑わしい要素 — 出力の欠落、読み取れないフィンガープリント、Bedrock変換が有効なのにBedrockパックがディスクにない — があれば、フルミックスへ落ちます。何も変わらない /rspm reload がほぼ即座に完了し、既存のホスティング登録を再利用できるのはこのためです。

ウォッチドッグはプラグインの初期化を考慮しますか？

はい。ウォッチドッグはMagmacoreのプラグイン初期化状態を認識します。

• 監視対象のすべてのプラグインがMagmacoreの初期化を終えるまで、安定性チェックを開始せずに待機します。
• ウォッチドッグの実行中にプラグインがリロードされた場合、状態の変化を検出して一時停止し、安定性のトラッキングをすべてリセットし、そのプラグインの再初期化が完了するのを待ちます。
• これにより、通常のプラグイン起動やリロードのシーケンス中に発生してしまう誤った「不安定」検出を防ぎます。

プレイヤーは最終的なパックをどのように受け取りますか？

autoHost が有効（既定）のとき、または selfHostForce が明示的にそれを上書きしているとき、RSPMは配信経路を選び、そのURLを参加してきたすべてのJavaプレイヤーにプッシュします。判定ツリーは次のとおりです：

1. selfHostForce: true の場合、常にセルフホストします（すべてのプローブをスキップ — 主にテスト用）。
2. それ以外で preferSelfHost: true（既定）の場合、まずセルフホストを試し、3つの健全性チェック（非LANに解決されるホスト、localhostセルフプローブ、magmaguy.com経由の外部到達性プローブ）を実行し、3つすべてが通ればセルフホストに確定します。
3. セルフホストが失敗または無効の場合、パックを magmaguy.com/rsp/ にアップロードし、そのURLを通知します。

URLが手に入ると、RSPMはマルチパックAPIを使用するため、他のサーバー送信パックと共存できます。現在のBukkitプラグイン記述子はMinecraft 1.21.4以降を要求します。

参加時のパック提示は約1秒遅延します。FAILED_DOWNLOAD や DISCARDED の応答は自動的に再試行され、そのプレイヤーセッションについて最大3回まで試みられます。プレイヤーが拒否した場合や無効なURLの場合は再試行されません。Floodgateのプレイヤーはここではスキップされます。彼らのBedrockパックは代わりにGeyser経由で配信されるためです。

autoHost: false かつ selfHostForce: false の場合、RSPMはURLをプッシュしません — plugins/ResourcePackManager/output/ からzipを取得して、自分のパイプラインで配信することが期待されます。

完全な配信判定ツリーはセルフホストを参照してください。

組み込みの自動ホストの代わりにセルフホストできますか？

はい — そしてRSPM v2以降、組み込みのHTTPサーバーが推奨されるセルフホスト経路になっています。selfHostEnabled: true と preferSelfHost: true はどちらも既定でオンです。

組み込みのどちらの経路でもなく、自前の既存Webサーバーでzipをホストしたい場合：

• autoHost: false に設定します。
• 任意で resourcePackRerouting を plugins ディレクトリからの相対パスで既存フォルダーに設定します。
• plugins/ResourcePackManager/output/ResourcePackManager_RSP.zip のマージ済みパックを取得して、自分でホストします。

resourcePackRerouting が設定されている場合、RSPMはそのzipのコピーを再ルート先のフォルダーにも書き込みます。再ルート先のパスは plugins ディレクトリからの相対として解決され、対象フォルダーは事前に存在している必要があります。

保存されたホストデータをリクエストするコマンドはありますか？

はい。次を使用します：

/rspm data_compliance_request

magmaguy.com のリモート自動ホストにアクティブなセッションがあれば、ResourcePackManagerは応答を次の場所にダウンロードします：

plugins/ResourcePackManager/data_compliance/data.zip

RSPMは同じ data_compliance フォルダーに ReadMe.md も書き出します。

アクティブなリモートセッションがない場合（例：セルフホスト中）、コマンドはリクエストできるリモートデータがないことを伝えます。

どのような設定項目がありますか？

plugins/ResourcePackManager/config.yml で次の項目を利用できます：

全般

• priorityOrder — ファイル衝突時にどのパックが勝つかを制御するリスト（最も優先度の高いものを上に）
• autoHost — ResourcePackManagerがマージされたパックを自動ホストして送信するか（boolean、既定 true）
• forceResourcePack — プレイヤーにパックの受け入れを強制するか（boolean、既定 false）
• resourcePackPrompt — パックを提示する際に表示するメッセージ（既定 "Use recommended resource pack?"）
• resourcePackRerouting — マージされたzipの追加コピーを書き込む任意のフォルダーパス（plugins からの相対）
• verboseLogging — パック準備とホスティングのハンドシェイクの各ステップをすべて出力する（boolean、既定 false）。既定でオフのため、コンソールには最終的な結果だけが表示されます。マージやホスティングの問題を診断するときに有効化してください。/rspm verbose on|off は実行時にこの同じキーを切り替えて保存します。Bedrockパイプラインを対象とする bedrockConverterDebug とは別物です。
• nightbreak.autoDownloadPluginUpdates — RSPMが起動時に自身のプラグイン更新を自動でダウンロードするか（boolean、既定 false。ダウンロードした更新を適用するには再起動が必要です）。これは nightbreak: セクション配下のネストされたキーであり、トップレベルのキーではありません — config.yml で素の autoDownloadPluginUpdates 行を検索しても、nightbreak: の下にインデントされた状態でしか見つかりません。これは /rspm setup のGUIで公開されているトグルと同じものです。

セルフホスト

• selfHostEnabled — 組み込みのHTTPサーバーを使用してよいか（boolean、既定 true）
• selfHostPort — セルフホスト用HTTPサーバーのポート。-1（既定）の場合は mcPort + networkHttpOffset-v2 から自動導出します。正の整数を指定すると明示的なポートを強制します。
• networkHttpOffset-v2 — selfHostPort = -1 のときにMinecraftサーバーポートに加算されるフォールバックオフセット。既定 1（例：MC 25565 → HTTP 25566）。ネットワークでは、これをプロキシと同期させ続ける必要はもうありません：バックエンドが実際にバインドした正確なHTTPポートをプロキシへ自動通知し、プロキシは通知が届くまでの間、自身の network-http-offset-v2 を推測としてのみ使用します。
• selfHostExternalHost — クライアントがあなたのセルフホストサーバーに到達するために使用する公開ホスト名またはIP。空（既定）の場合は api.ipify.org ／ checkip.amazonaws.com 経由で自動検出します。
• selfHostForce — すべての健全性チェックおよびリモートアップロードをスキップし、常にセルフホストします（boolean、既定 false — テスト用）。
• preferSelfHost — リモートアップロードへのフォールバック前に、健全性チェックを伴うセルフホストを先に試します（boolean、既定 true）。

Bedrock

• bedrockConversionEnabled — マージされたJavaパックをGeyserMC向けのBedrockパックに変換するか（既定 true）
• bedrockAutoDeployToGeyser — 検出されたGeyserフォルダーにGeyserのカスタムマッピングファイルをコピーするか（既定 true）
• bedrockGeyserFolder — Geyserフォルダーへの手動パス上書き。空の場合は自動検出します
• bedrockConverterDebug — Bedrockパイプラインからのアイテム単位／ボーン単位の詳細ログ行（既定 false）
• geyserExtensionAutoInstall — カスタムBedrockエンティティが描画されるように、ユニバーサルな ResourcePackManager.jar をGeyser拡張としてインストールし更新するか（既定 true）。false にすると今後のインストールと更新のステージングが止まりますが、すでに置かれている拡張jarが削除されることはありません — それはGeyserを停止した状態で手動で削除してください。プロキシプラグインには geyser-extension-auto-install という別名の同じスイッチがあります。

2つ目のファイル plugins/ResourcePackManager/bedrock_display_offsets.yml には、Bedrockプレイヤーの手に対する持ち物アイテムの表示位置を微調整するための、ユーザーが調整可能な12個のつまみが公開されています（一人称用に6個、三人称用に6個）。詳細はBedrock変換を参照してください。

バックエンド側にもプロキシ側にも、network-key の設定項目は意図的にありません。キーを手で貼り付ける方式は設定ミスの最大の原因でした — タイポひとつで、どこにもエラーを出さないままプロキシ↔バックエンドのリンクが壊れてしまうのです。

代わりに、プロキシがネットワークキーを保有し、それを配布します：

• プロキシはキーを一度だけ解決します：保存済みの network-key ファイルがあればそれを読み、なければ plugins/floodgate/key.pem が存在する場合にそこから値をシードし（これにより既存のネットワークはアップグレードをまたいでアイデンティティを保ちます）、それもなければ新しいキーを生成します。いずれの場合も結果はプロキシプラグイン自身のデータフォルダーの network-key に保存され、以後 key.pem を見に行くことはありません。
• 各バックエンドは、最初にプレイヤーが接続した時点で rspm:network プラグインチャンネル経由でそのキーを受け取り、自身の data.yml に永続化します。すでにキーを持っているバックエンドは、その後の付与を無視します — バックエンドを別のネットワークへ向け直すのはオペレーターの操作であって、メッセージがやることではありません。
• これにFloodgateは必要ありません。FloodgateはBedrockプレイヤーがプロキシに到達するために必要ですが、Java専用のネットワークならFloodgateなしでRSPMのプロキシ機能を利用できます。
• スタンドアロン（プロキシなし）のサーバーは、自分自身が1台構成のネットワークであるため、自前のキーを生成して保持します。

どちら側の /rspm status も、キーそのものではなく短い一方向ハッシュのフィンガープリントを表示します。プロキシとバックエンドでフィンガープリントが一致していれば、リンクは良好です。

コンソールが静かすぎますが、ちゃんと動いているのですか？

意図的な設計です。パックの準備は長いパイプラインです — 提供元プラグインごとのパックをステージングし、クラスターをマージし、変化が止まるのを待ち、ミックスし、Bedrock向けに変換し、結果をホストに引き渡します。これらをすべて実況すると、起動あたり約60行のコンソール出力になり、誰もが読みたい2点、つまり「プレイヤーにパックが届くのか」と「届かない場合はどうすればよいのか」が埋もれてしまいます。

そのため、通常の起動では1行だけを出力します：

[ResourcePackManager] Resource pack is live via self-hosting — http://play.example.com:25566/rspm.zip

この行が見えていれば、成功しています。

RSPMはまた、自力で解決した状況について意図的に警告を出しません。セルフホストのプローブが失敗してRSPMがリモートホスティングにフォールバックしたなら、それは成功です — コンソールは回り道ではなく結果を報告します。すでに処理済みのことを警告すると障害のように読まれ、存在しない問題を追いかけさせてしまいます。

すべての実況を見たい場合は、/rspm verbose on を実行（または config.yml で verboseLogging: true に設定）してから /rspm reload を実行してください。Bedrockコンバーターに特化した内容には、代わりに bedrockConverterDebug: true を使います。

他のプラグインがコードからパックを登録できますか？

はい。ResourcePackManagerは、プログラム的なパック登録のためのJava APIを公開しています。詳細はAPIページを参照してください。

Bedrock変換はFreeMinecraftModelsでしか動かないのですか？

いいえ、もうそうではありません。現在のコンバーターは、assets/<namespace>/items/**/*.json に1.21.4以降のアイテム定義を含むパックであれば、どのプラグインのものでも再帰的に処理できます。これにはFreeMinecraftModelsのボーンモデル、EliteMobsの装備、Oraxen／Nexoのカスタムアイテム、カスタム防具セット、その他あなた自身がこの形式で組み立てたパックが含まれます。素の2DカスタムアイテムはフラットなBedrockアイコンとして出力され、3Dカスタムアイテムにはジオメトリ／アタッチャブルとソフトウェアレンダリングされたインベントリアイコンが出力されます。

Bedrockパックが変わるたびにサーバーを再起動する必要がありますか？

既存のカスタムアイテムのテクスチャやモデルの調整は、次にBedrockプレイヤーが参加した時点で反映されます。RSPMはGeyserのAPIを使ってBedrockパックをセッション単位でライブ配信します。再起動が必要なのは、カスタムアイテムの集合自体が変わるとき（新しいアイテムの追加や既存アイテムの削除）だけです。これはGeyserがカスタムアイテム識別子を起動時に登録するためです。

ResourcePackManagerはBungeeCord／Velocityで動きますか？

はい — ファーストクラスでサポートされるトポロジーです。どこでも同じ ResourcePackManager.jar を使います：すべてのバックエンドに置き、プロキシにもそのコピーを置いてください。1つのjarにBukkit、Velocity、BungeeCord／Waterfallのエントリーポイントがすべてまとめられているため、ホストがバックエンドでもプロキシでも正しく読み込まれます。ビルドしたり展開したりするプラットフォーム別のプロキシ用jarはありません — そして、プロキシへのコピーを忘れた場合は、プロキシ配下のバックエンドが plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar にコピーを用意し、その旨をコンソールに表示します。

プロキシプラグインとして動作するとき、各バックエンドの変換済みBedrockパックをマージし、プロキシのGeyser経由でBedrockクライアントに配信します。Javaのパック配信は依然として各バックエンドが直接処理します — Javaクライアントにはバックエンドごとのパックが表示されます。

セットアップ、トラブルシューティング、検証手順はプロキシネットワークを参照してください。