メインコンテンツまでスキップ

Resource Pack Manager FAQ

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

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

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

  • /rspm setup — ゲーム内のGUIセットアップメニューを開きます（プラグインの更新状況、推奨プラグイン、自動更新トグル、wiki／Discord／Nightbreakアカウントへのリンク）
  • /rspm recommendedplugins — 共有のNightbreak推奨プラグインメニューを表示します（コンソールではテキスト一覧）
  • /rspm downloadpluginupdate — 利用可能なResourcePackManagerの更新を次回の再起動用にダウンロードします
  • /rspm downloadall — このプラグインが公開しているすべての利用可能な更新をダウンロードします（現時点ではResourcePackManagerの更新）
  • /rspm applypluginupdate — 共有のNightbreakコマンドセットの一部です。RSPMの更新にはサーバーの再起動が必要なため（Geyser拡張はGeyserの起動時にしか読み込まれません）、RSPMは常にこのコマンドを拒否します
  • /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コマンドです。

MagmaCoreは、/rspm のサブコマンドではない次のトップレベルコマンドも登録します：

  • /nightbreaklogin <token> と /nightbreaklogout は、サーバーの共有Nightbreakアカウントトークンを保存または消去します。どちらも nightbreak.login（既定はOP）が必要です。Nightbreakアカウントの連携を参照してください。
  • /nightbreak plugins はNightbreakのプラグインカタログを閲覧し、nightbreak.plugins（既定はOP）が必要です。
  • /logify は現在のサーバーログを mclo.gs にアップロードし、logify.*（既定はOP）が必要です。
  • /resourcepackmanagerchangelog [dismiss|disable] は、管理者がまだ読んでいないResourcePackManagerのリリースノートを表示します。変更履歴通知を参照してください。

/nightbreaklogin、/nightbreaklogout、/nightbreak、/logify は、最初に読み込まれたNightbreakプラグインがサーバー全体に対して登録します。

バックエンドの権限：

  • /rspm setup と /rspm recommendedplugins には resourcepackmanager.setup が必要です。/rspm setup はインベントリGUIを開くためプレイヤー専用です。
  • /rspm downloadpluginupdate、/rspm downloadall、/rspm applypluginupdate、/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 を実行し、RSPMが再生成されたエクスポートをマージするのを待ちます（マージの成功・失敗は報告されます。RSPMはリロードされません）
  • /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 が採用され、宣言されたフォーマット範囲が統合されます。異なるディレクトリのオーバーレイはまとめて保持され、同じディレクトリの場合は優先度の高いエントリが採用されます。各オーバーレイの formats、min_format、max_format と追加メタデータは作者の指定どおりに保持されます。唯一の追加処理があります。Minecraft 1.21.9以降は、パックフォーマット64以下に達するオーバーレイと formats を宣言していないオーバーレイが混在するオーバーレイリストを拒否するため、マージ後のリストにそのようなオーバーレイが含まれる場合、RSPMは min_format／max_format だけを宣言している各エントリに同等の formats 範囲を付与します。それ以外でRSPMがオーバーレイの範囲を書き換えることはありません。pack、overlays、トップレベルオブジェクトの追加フィールドも、優先度の高い値と競合しない限り保持されます。

すべてのパックをマージした後、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を再公開します。少しでも疑わしい要素 — 出力の欠落、読み取れないフィンガープリント、SHA-1が一致しなくなったマージ済みZIP — があれば、フルミックスへ落ちます。何も変わらない /rspm reload がほぼ即座に完了し、既存のホスティング登録を再利用できるのはこのためです。

Javaの入力は変わっていないもののBedrock側をやり直す必要がある場合（Bedrock変換が有効なのにBedrockパックがディスクにない、bedrockConversionEnabled やBedrockの対象が変わった、コンバーターの更新でBedrockの出力が変わる、など）、RSPMは検証済みのJava ZIPを維持してBedrockの手順だけをやり直すため、Javaパックのバイト列とSHA-1は変わりません。

起動時、RSPMは監視対象のプラグインが初期化を終える前に、保存済みのフィンガープリントとマージ済みZIPのSHA-1を確認します。一致すれば、保存済みのパックからすぐにJavaのホスティングを開始します。その後ソースパックが変更された場合は、ウォッチドッグが引き続き再ミックスします。

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

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

  • 監視対象のすべてのプラグインがMagmacoreの初期化を終えるまで、安定性チェックを開始せずに待機します。
  • 実行中にプラグインが INITIALIZING 状態になると、ウォッチドッグは一時停止して安定性の追跡をリセットし、初期化の完了を待ちます。失敗した、または初期化されていない任意の統合が、ミキサー全体を無期限に待たせることはありません。
  • これにより、通常のプラグイン起動やリロードのシーケンス中に発生してしまう誤った「不安定」検出を防ぎます。

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

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

  1. selfHostForce: true の場合、プローブなしでセルフホストを試します。主にテスト用で、URL検証とHTTPリスナーの起動には成功する必要があります。
  2. それ以外で preferSelfHost: true（既定）かつ selfHostEnabled: true の場合、ホストアドレスを確認し、localhostとプレイヤー用の正確なURLから取得したパックのサンプルを比較し、magmaguy.com経由の外部到達性も要求します。すべての検証に合格したときだけセルフホストを選びます。
  3. セルフホストが失敗または無効の場合、magmaguy.com/rsp/ のパックを再利用するかアップロードし、そのURLを通知します。リモート失敗後も、有効ならセルフホストを試せますが、同じ検証が必要です。外部プローブを利用できない場合は自動セルフホストを拒否し、両経路が失敗すると新しい配信URLを通知しません。

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

参加時のパック提示は約1秒遅延します。FAILED_DOWNLOAD や DISCARDED の応答は自動的に再試行され、そのプレイヤーセッションについて最大3回まで試みられます。プレイヤーが拒否した場合、無効なURLの場合、FAILED_RELOAD（クライアント自身のリソースのリロードに失敗した。そのクライアントの latest.log を確認してください）の場合は再試行されません。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で公開されているトグルと同じものです。プラグインの自動ダウンロードには、有効なNightbreakアカウントトークンと有効なPatreonサポーターメンバーシップが必要です。RSPMのGeyser拡張はGeyserの起動時にしか読み込まれないため、RSPMは共有の nightbreak.applyPluginUpdatesWithoutRestart キーを書き込まず、ダウンロードした更新を再起動なしで適用することもありません。

セルフホスト

  • selfHostEnabled — 組み込みのHTTPサーバーを使用してよいか（boolean、既定 true）
  • selfHostPort — セルフホスト用HTTPポート。-1（既定）は mcPort + networkHttpOffset-v2 で計算します。明示ポートも計算結果も 1～65535 である必要があります。
  • networkHttpOffset-v2 — selfHostPort = -1 のときにMinecraftサーバーポートに加算されるフォールバックオフセット。既定 1（例：MC 25565 → HTTP 25566）。ネットワークでは、これをプロキシと同期させ続ける必要はもうありません：バックエンドが実際にバインドした正確なHTTPポートをプロキシへ自動通知し、プロキシは通知が届くまでの間、自身の network-http-offset-v2 を推測としてのみ使用します。
  • selfHostExternalHost — クライアントがセルフホストサーバーに接続するための公開ホスト名またはIP。空（既定）の場合は自動検出します。
  • selfHostExternalUrl — リバースプロキシ用の、パスを含む完全な公開HTTPまたはHTTPSのパックURL。既定は空です。ローカルのリスナーを変更せず、公開するURLを上書きします。認証情報やフラグメントを含むURLは拒否されます。
  • 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 という別名の同じスイッチがあります。

以前のバージョンには、手持ちアイテムのオフセット設定を持つ plugins/ResourcePackManager/bedrock_display_offsets.yml もありました。このファイルは現在読み込まれません。Bedrockの手持ちアイテムのポーズは、Javaモデルの display トランスフォームから作られるようになりました。手持ちアイテムのポーズを参照してください。

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

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

  • プロキシはまず保存済みの有効な network-key を読み、なければ plugins/floodgate/key.pem からの導出を試し、どちらも使えなければランダムなキーを生成します。結果はデータフォルダーに保存されます。その後は有効な間そのキーを再利用します。失われた場合は同じ手順を繰り返すため、Floodgateから同じキーが再現される場合があります。ネットワークキーの復旧を参照してください。
  • 各バックエンドは、最初にプレイヤーが接続した時点で rspm:network プラグインチャンネル経由でそのキーを受け取り、自身の data.yml に永続化します。すでにキーを持っているバックエンドは、その後の付与を無視します — バックエンドを別のネットワークへ向け直すのはオペレーターの操作であって、メッセージがやることではありません。
  • RSPMの連携にFloodgateは不要です。Bedrockの認証はGeyserで選択した認証モードに従います。Floodgateとオンライン認証を参照してください。
  • スタンドアロン（プロキシなし）のサーバーは、自分自身が1台構成のネットワークであるため、自前のキーを生成して保持します。

どちら側の /rspm status も、キーそのものではなく短い一方向ハッシュのフィンガープリントを表示します。一致は同じネットワーク識別情報を共有していることを示します。接続性とパック配信は、取得結果を別途確認して検証してください。

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

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

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

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

この行は配信用URLの公開を示します。クライアントで参加し、既知のカスタムコンテンツを確認して、ダウンロードと描画を検証してください。

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でパックをセッションごとに配信します。カスタムアイテムのマッピングが変わった場合や、新しいカスタムエンティティ識別子・プロパティ型の登録が必要な場合は、Geyserを実行するプロセスを再起動してください。これらは起動時に登録されます。登録済みの識別子を、プロパティ型を変えずに再出力するだけなら、再起動は不要です。

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

はい。プロキシとリソースパックを提供する各バックエンドに、同じ ResourcePackManager.jar を配置します。jarにはBukkit、Velocity、BungeeCordのエントリーポイントが含まれます。プロキシ配下のバックエンドは、ネットワークキーを受け取っていない場合に plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar にコピーを用意します。他の登録済みサーバーはRSPMなしで動作できます。バックエンドの検出により、それらがパック同期を遅らせることはありません。

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

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