Resource Pack Manager FAQ

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

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

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

• /rspm setup — ゲーム内のGUIセットアップメニューを開きます（プラグインの更新状況、推奨プラグイン、自動更新トグル、wiki／Discord／Nightbreakアカウントへのリンク）
• /rspm reload — マージされたパックを再構築し、再ホストします
• /rspm status — 完全な診断ダンプ（パックの状態、ホスティングモード、ネットワークキー、統合）
• /rspm itemsadder configure — RSPMによるホスティング向けにItemsAdderを設定します
• /rspm itemsadder dismiss — あなたのプレイヤーUUIDに対してItemsAdderの警告を恒久的に非表示にします
• /rspm data_compliance_request — このサーバー向けにリモートで保存されているデータをすべてダウンロードします

ルートコマンドは /resourcepackmanager で、エイリアスとして /rspm が使えます。共有のMagmaCore／Nightbreakサブコマンド（例：/rspm recommendedplugins、/rspm downloadall）もいくつか登録されており、これらはセットアップメニューのボタンがリンクする先になっています。

バックエンドの権限：

• /rspm setup には resourcepackmanager.setup が必要で、プレイヤー専用です（インベントリGUIを開きます）。
• /rspm reload、/rspm status、/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プレイヤーが参加したのにパックが見えない」ケースの診断に使います。プロキシ再起動でオフにリセットされます。引数なしで実行すると現在の状態を表示します。

プロキシコマンドは resourcepackmanager.command.status または resourcepackmanager.* をチェックします。コンソールは常に両方を持ちます。プレイヤーには権限プラグイン経由で付与する必要があります。出力に秘密情報は含まれないため（ネットワークキーはマスクされ、トークンは出力されません）、寛容に付与しても安全です。

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

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はそのローカルパスを複数のリソースパックサブフォルダーが収められたディレクトリとして扱い、それらをすべてまとめてマージします。

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のホスティングを無効化するよう案内します。

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

はい。.zip ファイルを次の場所に置いてください：

plugins/ResourcePackManager/mixer

ファイル衝突時にどのパックが勝つかを制御したい場合は、plugins/ResourcePackManager/config.yml の priorityOrder に、.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 に記載されていないパックもマージには含まれますが、優先度は最低として扱われます。

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

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

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

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

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

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

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

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

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

URLが手に入ると、Minecraft 1.20.3以降ではマルチパックAPIを使用するため、他のサーバー送信パックと共存できます。それより古いバージョンでは、既存のサーバーリソースパック割り当てを置き換える従来の単一パック方式にフォールバックします。

autoHost: 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

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

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

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

全般

• priorityOrder — ファイル衝突時にどのパックが勝つかを制御するリスト（最も優先度の高いものを上に）
• autoHost — ResourcePackManagerがマージされたパックを自動ホストして送信するか（boolean、既定 true）
• forceResourcePack — プレイヤーにパックの受け入れを強制するか（boolean、既定 false）
• resourcePackPrompt — パックを提示する際に表示するメッセージ（既定 "Use recommended resource pack?"）
• resourcePackRerouting — マージされたzipの追加コピーを書き込む任意のフォルダーパス（plugins からの相対）
• 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）

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

network-key の設定項目は意図的にありません。プロキシとバックエンドを結びつけるキーは、各JVM上で plugins/floodgate/key.pem から自動導出されます。Floodgateはすでにそのファイルがネットワーク全体で同じであることをBedrock認証のために要求しているため、導出されたキーも自動的にどこでも一致します。

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

はい。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はなく、proxy-extension/ フォルダーももうありません。

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

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