跳至主要內容

Resource Pack Manager 疑難排解

此頁面僅涵蓋目前 ResourcePackManager 程式碼中已確認的行為。

對任何 RSPM 問題而言，最有用的第一步是：

/rspm status

它會印出版本、佈署模式（獨立 vs 網路後端）、一段簡短且不含機密的網路金鑰指紋以及該金鑰的來源、Java + Bedrock 資源包狀態、目前啟用的交付路徑及其 URL、解析後的外部主機 + 自動偵測的公開 IP、所有相關的設定旗標、一則代理佈署提醒（網路代理 jar 就是同一個 ResourcePackManager.jar），以及 Floodgate / Geyser-Spigot 的偵測結果。當該 jar 在代理上執行時也有同樣的指令，可印出代理端的對應資訊（後端清單、各後端的擷取結果、合併後的資源包狀態）。

主控台預設只顯示少量訊息​

RSPM 在每次重新初始化交付路徑時只會印出一行——也就是結果：

[ResourcePackManager] Resource pack is live via self-hosting — http://play.example.com:25566/rspm.zip
[ResourcePackManager] Resource pack is live via automatic hosting — https://magmaguy.com/rsp/<uuid>

其餘的一切——每個被暫存的資源包、每個被合併的叢集、每次穩定性檢查、每次自我託管探測及其結果——預設都會被抑制。RSPM 自己就能恢復的狀況不會被回報為警告。 若某次自我託管探測失敗、RSPM 靜默切換到遠端託管，那是成功而非故障，主控台對此不會有任何訊息。

結果行表示 RSPM 已選擇並發布派送 URL，不能證明某個用戶端已下載或顯示資源包。請讓玩家加入並檢查一個已知的自訂物品或模型。回報託管或合併問題前，先啟用詳細日誌：

/rspm verbose on

然後執行 /rspm reload。該指令會替你把 verboseLogging: true 寫入 plugins/ResourcePackManager/config.yml，且此設定會在重啟後保留，所以完成後請執行 /rspm verbose off。手動編輯該設定鍵的效果完全相同。Bedrock 轉換器有另一個獨立的開關 bedrockConverterDebug，它只能透過設定檔調整。

你確實可能看到的警告都是真正的故障：對特定玩家反覆的資源包交付失敗、用戶端回報 INVALID_URL、HTTP 連接埠無法綁定、兩條交付路徑皆失敗，或代理已輪詢數個週期卻沒有任何後端產出內容。

玩家沒有收到資源包​

請先檢查以下事項：

  • 若你希望正常的自動交付運作，必須啟用 autoHost（selfHostForce 則是明確的測試用覆寫）
  • 合併後的資源包必須存在，且至少一條交付路徑（自我託管或遠端）必須已成功
  • 玩家會在加入時收到資源包。在沒有已發布資源包時加入的玩家，會在託管就緒時收到它，包括託管在工作階段後段重新註冊的情況（例如遠端工作階段過期之後）
  • Java 交付會刻意略過 Floodgate 玩家，因為他們的 Bedrock 資源包工作階段由 Geyser 掌管

如有需要：

  1. 執行 /rspm status 並查看「Hosting」區段。Active delivery 會顯示目前正在使用自我託管、遠端或兩者皆未使用。
  2. 若顯示「active delivery: not yet ready」——混合或上傳仍在進行中。當玩家過早加入時，外掛會在主控台以大字橫幅顯示警示，並在交付就緒的當下自動發送資源包。
  3. 若顯示「active delivery: none — hosting disabled or failed」——表示 autoHost 已停用，或自我託管探測與遠端上傳皆失敗。請參閱下方的「自我託管健全性檢查失敗」與「自動託管無法連線到遠端伺服器」。
  4. 設定 verboseLogging: true、執行 /rspm reload，觀察主控台上的上傳 / 自我託管探測結果，然後用測試玩家重新加入。（若未開啟該旗標，探測步驟不會被印出——只會印出最終的「Resource pack is live via ...」結果行。）

加入時的資源包提示會延遲約一秒。若某個 Java 用戶端回報 FAILED_DOWNLOAD 或 DISCARDED，RSPM 會針對該玩家工作階段自動重試，最多三次。它不會針對玩家主動拒絕、INVALID_URL 或 FAILED_RELOAD 重試；重試次數耗盡與無效 URL 會被記錄為真正的故障。

FAILED_RELOAD 表示用戶端已下載資源包，但其本身的資源重新載入失敗，因此再次下載同一個資源包也無濟於事。RSPM 會記錄 Client <name> reported FAILED_RELOAD for the resource pack. Check that client's latest.log for the resource reload error; not retrying.。請閱讀該玩家用戶端的 latest.log，找出用戶端拒絕的資源或資源包中繼資料。

若另一套系統負責託管與派送（autoHost: false），RSPM 不會推送 URL。若在 RSPM 前部署 HTTPS 反向代理，請保留 autoHost: true 並使用 selfHostExternalUrl。這樣可以保留自動派送與遠端託管備援。

已安裝 ItemsAdder，但其內容未出現在最終資源包中​

這通常表示 ItemsAdder 仍以某種方式設定，導致 ResourcePackManager 無法讀取或託管其輸出。

使用：

/rspm itemsadder configure

該指令目前會：

  • 啟用 resource-pack.hosting.no-host.enabled
  • 停用 protection_1、protection_2 與 protection_3
  • 設定 resource-pack.zip.compress-json-files: false
  • 執行 /iareload，然後 /iazip
  • 等待 RSPM 合併重新產生的 ItemsAdder 匯出內容，並回報合併是否成功

它不會重新載入 ResourcePackManager。看到合併訊息後，請以 /rspm status 檢查託管狀態。

若該指令告知你 ItemsAdder 已在託管自己的資源包，請先手動停用 ItemsAdder 託管，再執行一次指令。

合併後的資源包無效或無法上傳​

ResourcePackManager 的自動託管整合會明確處理下列伺服器端錯誤類型：

  • 缺少必要檔案
  • 檔案過大
  • 檔案格式無效
  • 缺少工作階段
  • 遠端伺服器無法使用

RSPM 會在上傳前自行檢查檔案大小上限：超過 50,000 KiB（51,200,000 位元組）的 Java 資源包不會上傳，主控台會印出 Automatic hosting skipped: resource pack is <size> bytes; the limit is 51200000 bytes.。之後 RSPM 會改為嘗試經過驗證的自我託管。請參閱自我託管。

若遇到上述情況：

  1. 執行 /rspm reload 重新建置資源包。
  2. 檢查是否某個來源資源包已損毀、加密或無法讀取。
  3. 檢查最終合併的資源包根目錄是否仍包含有效的 pack.mcmeta 與 pack.png。

若某個已啟用的資源包無法解壓或暫存，當次混合會中止，主控台會指出是哪個資源包失敗。請修復該資源包、移除手動加入的 ZIP，或在其自動整合設定中將 isEnabled: false 之後再重新載入。

覆蓋層中繼資料與壓縮檔結構​

最終合併保留作者的覆蓋層格式宣告，包括 formats、min_format、max_format 及其他中繼資料。多個資源包共用覆蓋層目錄時，採用優先順序較高的項目。

只有一項改寫。當清單中任一覆蓋層涵蓋 pack format 64 或更低、而另一個覆蓋層未宣告 formats 時，Minecraft 1.21.9 及更新版本會拒絕整個 pack.mcmeta。兩個各自有效的資源包，在覆蓋層清單合併後就可能違反這條規則。當合併後的清單包含下限為 64 或更低的覆蓋層時，RSPM 會為每個只宣告 min_format 與 max_format 的項目加上 formats 範圍。該範圍涵蓋的用戶端與項目本身的邊界相同，若起點為 64 或更低則上限為 64。衝突日誌會記錄 Added the formats range to N overlay entries。已宣告 formats 或邊界無法解析的項目會保持原樣。除此之外，RSPM 不會統一不同世代用戶端的格式範圍，也不會修復無效宣告；請在來源資源包修正不相容的中繼資料。

RSPM 會檢查覆蓋層目錄是否為非空的相對路徑，且不會超出組裝後資源包的根目錄。絕對路徑、正規化後超出根目錄的路徑及無效路徑會被拒絕。通過這項檢查不代表 Minecraft 一定接受覆蓋層名稱或格式中繼資料。

若 ZIP 內有 Pack Name/assets/ 和 Pack Name/pack.mcmeta，表示多了一層外部目錄。RSPM 會發出提示；請重新壓縮，讓 assets/ 和 pack.mcmeta 位於 ZIP 根目錄。內容經過去重的壓縮檔會透過中央目錄讀取，保留共用壓縮資料的項目，包括材質動畫中繼資料。

方塊圖集材質​

合併後的方塊圖集會將目錄來源展開成資源包內的個別 PNG 資源，保留來源順序與精靈 ID。若動畫影格尺寸不適合所需的 mip 層級，系統會以最近鄰縮放在 resourcepackmanager_internal:mip_safe/ 下產生結果固定的副本。原始檔案保持不變，供字型等其他載入器使用。

不要在保留的 resourcepackmanager_internal 命名空間內建立內容；衝突會被拒絕。這個過程不是 Java 到 Bedrock 的轉換，也不保證支援所有自訂用戶端著色器或圖集擴充。

損壞的資源包不會永久阻塞派送​

無法暫存的資源包在每次重試時都會以相同方式失敗，因此放著不管會讓交付永久卡死——合併永遠無法完成，同一個錯誤無止盡地重複。在同一個檔案連續失敗三次之後，RSPM 會把該資源包從合併中剔除，好讓其餘資源包能順利發佈，並大聲地說明一次：

[ResourcePackManager] Resource pack X.zip failed to stage 3 times in a row and has been excluded
from the merge so the remaining packs can be delivered. The merged pack is now INCOMPLETE ...

請照字面理解這段訊息：玩家現在拿到的資源包缺少該外掛的內容。常見原因是損毀或寫入不完整的 zip。

這個排除狀態會自行解除。失敗紀錄是以檔案的大小與修改時間為鍵，因此修復或替換該檔案就會自動解除隔離，該資源包會重新加入下一次合併——不需要指令、也不需要重啟。/rspm reload 同樣會把所有隔離紀錄從頭重置。未達三次的失敗計數會在任何一次成功的混合之後被清除，因此在長時間運行中零星、互不相關的短暫故障不會累積成排除。

當遠端自動託管回傳 SESSION_NOT_FOUND 錯誤時，RSPM 會清除其工作階段 UUID，並在下一次 keep-alive tick 重新初始化——無需手動介入。

某個外掛的資源覆蓋了另一個外掛的資源​

這由下列檔案中的 priorityOrder 控制：

plugins/ResourcePackManager/config.yml

較高的條目會勝過較低的條目。

對於不可合併的檔案，ResourcePackManager 會取代較低優先級的檔案；對於可合併的 JSON 檔案，則會合併內容。目前可合併的 JSON 類別為：

  • sounds.json
  • 語言檔
  • minecraft/models/item 下的原版物品模型 JSON（非遞迴合併：只有 overrides 陣列會跨資源包合併，檔案其餘部分則遵循「最高優先級勝出」）
  • atlas 檔
  • font 檔
  • items/ 下的 1.21.4+ 物品模型定義（格式感知合併，會尊重 predicate-tree 結構）

pack.mcmeta 也有專用的合併處理：採用最高的 pack_format，並合併宣告的資源包格式範圍。覆蓋層項目保留作者設定的範圍與其他中繼資料；目錄重複時，採用優先順序較高的項目。唯一的補充，是為需要的項目加上 formats 範圍，讓合併後的清單能在 1.21.9+ 用戶端上載入（請參閱覆蓋層中繼資料）。除此之外，RSPM 不會修復不相容的作者中繼資料。其他沒有衝突的中繼資料也會保留。基礎圖集來源會合入覆蓋層圖集，避免基礎項目被遮蔽。

若需檢視上一次合併期間的細節，請查看：

plugins/ResourcePackManager/collision_log.txt

GUI 文字或字型元素顯示錯誤​

字型檔是 ResourcePackManager 會合併的其中一個 JSON 類別，但這並不保證兩種不同的字型系統在 Minecraft 中能良好共存。

若字型驅動的選單或 HUD 顯示異常：

  1. 調整 priorityOrder，讓你想保留的資源包排在更高位置。
  2. 執行 /rspm reload。
  3. 檢查 collision_log.txt，確認衝突是否如預期發生。

資源包變更未立即顯示​

ResourcePackManager 對受支援的資源包來源有一個監視器。

它會等待某個變動的資源包 3 秒內未再變動，然後一旦所有受監視的資源包都穩定，重新混合便會立即發生。

若你正在主動重新產生其他外掛的資源包，請在檔案寫入停止後再等幾秒。若有疑慮，可在上游外掛完成後執行 /rspm reload。

/rspm status 顯示遠端託管，但我預期是自我託管​

當 preferSelfHost: true（預設）且自我託管檢查失敗時，可能出現這種情況。可達性檢查記錄在詳細日誌層級，未啟用 verboseLogging: true 就不顯示；部分訊息包含「This is OK.」。遠端託管成功時，結果為 Resource pack is live via automatic hosting — ...。無效設定、監聽器故障和遠端通訊失敗仍可能產生警告。

請執行 /rspm verbose on（或設定 verboseLogging: true）並執行 /rspm reload，即可看到是三層中的哪一層失敗：

  1. 第 1 層（heuristic） — 解析後的外部主機為 RFC1918 / loopback / link-local。請將 selfHostExternalHost 設為你的實際公開主機名稱，或確保外掛能連到 api.ipify.org / checkip.amazonaws.com。
  2. 第 2 層（本機與公告 URL 下載） — RSPM 從 http://127.0.0.1:<port>/rspm.zip 和玩家確切 URL 下載開頭最多 1 KiB，分別與本機資源包比較。要求 HTTP 200 或 206、回報長度相符，且 206 具有預期的 Content-Range。重新導向、錯誤位元組、檔案缺失和伺服器端 NAT loopback 故障會拒絕自我託管。
  3. 第 3 層（外部可達性探測） — magmaguy.com 必須回報公告 URL 可達且回傳 HTTP 200 或 206。HTTP 連接埠關閉、請求失敗或探測服務無法使用，都會拒絕自動自我託管。狀態與任何原因代碼可透過 verboseLogging 查看。

依建議順序處理：在防火牆與路由器上開放 HTTP 連接埠，將 selfHostExternalHost 設為可連線的主機名稱，或設定 preferSelfHost: false 以優先嘗試遠端託管。若連備援也不能使用自我託管，另設 selfHostEnabled: false，並保持 selfHostForce: false。

探測服務無法連線時，自我託管維持未驗證狀態，RSPM 會嘗試遠端託管。遠端失敗後的後備也必須通過相同的自我託管檢查。只有 selfHostForce: true 可略過驗證；兩條自動路徑皆失敗時，RSPM 無法公告新的交付 URL。探測成功也不能證明每位玩家網路上的完整下載和資源包接受都成功。

完整的決策樹請參閱自我託管。

自動託管無法連線到遠端伺服器​

ResourcePackManager 的內建遠端託管會與以下位址通訊：

https://magmaguy.com/rsp/

若連線失敗，外掛會記錄通訊警告，且在重新連線成功前無法使用遠端回退。

你的選擇有：

  1. 修正伺服器對外 HTTPS 連線
  2. 等待遠端服務恢復可用
  3. 停用 autoHost，改由自己託管產生的 zip
  4. 開放 HTTP 連接埠，將 selfHostExternalHost 設為公開主機名稱，並保持 preferSelfHost: true。明確名稱略過公開 IP 自動偵測，但本機、公告 URL 和外部檢查仍須通過。探測服務無法連線會阻止自動選擇自我託管。

我想透過自己的網頁伺服器自我託管合併後的資源包​

由程式碼支援的設定方式為：

  1. 設定 autoHost: false。
  2. 若希望 ResourcePackManager 將額外副本寫入已存在的資料夾，請設定 resourcePackRerouting。
  3. 自行託管 ResourcePackManager_RSP.zip。

resourcePackRerouting 路徑會以 plugins 目錄為基準解析，目標資料夾必須已存在。

若你想改為使用 RSPM 內建的自我託管 HTTP 伺服器（這是不同的東西——與外掛位於同一 JVM 中），請參閱自我託管。

我需要檢視為此伺服器儲存了哪些遠端資料​

使用：

/rspm data_compliance_request

若有作用中的遠端託管工作階段，ResourcePackManager 會將回應下載至：

plugins/ResourcePackManager/data_compliance/data.zip

RSPM 也會在同一個 data_compliance 資料夾中寫入 ReadMe.md。

若沒有遠端工作階段（例如你正在使用自我託管），該指令會回報沒有遠端資料可索取。

沒有產生 Bedrock 資源包​

bedrockConversionEnabled 預設為 true，因此應會自動執行。請先執行 /rspm status——Bedrock Pack 區段會告訴你為何磁碟上沒有資源包：

  • 「No Bedrock target detected」——本地沒有 Geyser-Spigot、沒有 Floodgate，也不在網路模式中。轉換是刻意被略過的。請安裝 Floodgate（用於代理設定）或 Geyser-Spigot（用於獨立設定），然後執行 /rspm reload。
  • 「Network mode is active so this backend SHOULD produce a Bedrock pack. The file is missing」——通常表示首次混合週期尚未完成（啟動後等約 30 秒），或轉換既找不到可轉換的物品對應也找不到允許的實體套組，或轉換過程拋出例外。在主控台搜尋 [BedrockConverter] 警告。啟用 bedrockConverterDebug: true 時，掃描器也會記錄 Generic scanner: discovered N item definitions；數量為 0 表示合併後的資源包沒有可轉換的物品定義。（狀態診斷引用此行時寫作 discovered 0 items definition files。）

若 Geyser 自動偵測失敗：

  1. 在 config.yml 中將 bedrockGeyserFolder 設為你的 Geyser 資料夾路徑（例如 Geyser-Spigot）。
  2. 絕對路徑可用。相對路徑會先從伺服器工作目錄嘗試，接著再以相對於 plugins 目錄嘗試。

轉換器會自動偵測 plugins/Geyser-Spigot/、任何 plugins/Geyser-*/ 變體，或 Fabric/NeoForge 環境下的 config/Geyser-*/。

如需逐物品 / 逐 bone 的日誌輸出，請設定 bedrockConverterDebug: true 並重新載入。

Bedrock：因為存在舊版資源包而略過即時提供者​

若主控台回報 Legacy RSPM Bedrock pack detected，表示 Geyser 在啟動時已從其資源包目錄掃描過一個舊的 ResourcePackManager_Bedrock.zip。在行程執行期間刪除該檔案，會讓 Geyser 對一個已不存在的路徑持有記憶體中的 codec，因此 RSPM 會刻意在該次啟動中略過它的即時資源包提供者。

請完整停止伺服器，只刪除 RSPM 印出的那個確切舊檔路徑，然後再啟動伺服器。請勿用 /reload 進行這項遷移。目前的資源包仍位於 plugins/ResourcePackManager/output/ 並以每個工作階段的方式提供；它不應該放在 Geyser 的 packs/ 目錄裡。

Bedrock 玩家看到的手持物品位置不正確​

先確認預期模型和最新資源包已載入：讓 Bedrock 用戶端重新連線，以接收目前的資源包。RSPM 會從 Java 模型的 display.firstperson_righthand 與 display.thirdperson_righthand 變換推導手持姿勢，因此若姿勢在 Java 上也不正確，請在 Java 模型中修正。若 Java 看起來正確而 Bedrock 不正確，請附上模型檔案回報問題。

bedrock_display_offsets.yml 及其偏移設定已被移除，不再被讀取；編輯舊的副本不會有任何效果。請參閱手持物品姿勢。

Bedrock 玩家缺少自訂盔甲材質​

自訂盔甲在 Bedrock 上的呈現是結合原版盔甲幾何與 Java 材質作為可見圖層。要使其正常運作，來源外掛的資源包必須在 assets/<namespace>/equipment/<material>.json 下定義一個與物品定義並列的裝備檔。若轉換日誌顯示該物品但遊戲中沒有盔甲材質，請確認該檔案存在於合併後的資源包中。

代理：某個後端表示它沒有網路金鑰​

在該後端上，/rspm status 顯示 Network key source: not set — the proxy sends one when a player next connects here，而主控台不斷重複「This backend is behind a proxy but has no network key yet」。

缺少 plugins/floodgate/key.pem 並不是原因——該檔案現在是選用的。金鑰由代理持有：它會載入自己的 network-key 檔案，或在 Floodgate 的 key.pem 存在時一次性地從中衍生種子，或產生一把全新金鑰，然後在有玩家連線到某個後端時把金鑰推送過去。

請依序檢查：

  1. 代理啟動之後，有玩家連線過那個後端嗎？授予是搭著玩家連線一起送出的。
  2. ResourcePackManager.jar 真的在代理上嗎？後端會替你在 plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar 預備一份自身 jar 的副本並印出該路徑——把它複製到代理的 plugins/ 並重新啟動代理。
  3. 在使用現代轉發的 Velocity 上，後端的轉發密鑰與代理的一致嗎？設定為現代轉發的後端會刻意拒絕未簽章或簽章錯誤的授予，其日誌會指出是哪一種。在兩側修正密鑰後，下一次玩家連線就會自行重試。
  4. 比對兩端 /rspm status 的 Network key fingerprint。指紋相同代表使用相同的網路身分；仍需檢查擷取結果來確認連線。金鑰本身不會顯示。

完整順序請參閱代理網路。

若 /rspm status 顯示 NetworkSync isn't running 並提示缺少 Floodgate 的 key.pem，請查看之前的啟動錯誤。這項提示已過時：目前代理可在沒有 Floodgate 的情況下產生並保存自己的金鑰。請依初始化錯誤、檔案權限及後端連線狀態決定下一步。若代理的 /rspm 指令完全不存在，請在啟動日誌中檢查是否有網路身分失敗。

發佈回滾不完整​

如果 Bedrock 資源包、代理接收的資料或合併資源包發佈失敗，且無法完整還原先前的檔案，RSPM 會保留復原副本，並記錄其目錄及受影響的目標。它也會嘗試停止使用這組不完整的檔案。請保留日誌中指定的復原目錄，解決檔案系統錯誤，並檢查資源包與對應的一致性後再重試。回滾失敗並不表示發佈成功。

代理：「Could not establish persistent RSPM network identity」​

目前的版本不會以未儲存的金鑰執行。若代理無法將新確定的金鑰儲存至 network-key，或無法讀取既有的 network-key 檔案，代理角色會在啟動期間以 Could not establish persistent RSPM network identity: ... 或 Cannot read established RSPM network identity 停止。網路同步、Bedrock 交付與代理的 /rspm 指令都不會啟動，因此後端會保留其既有金鑰，而不會被連結到一個可能在下次重啟時改變的金鑰。

請修正代理外掛資料夾的檔案系統權限（Velocity 上為 plugins/resourcepackmanager/，BungeeCord 上為 plugins/ResourcePackManager/），然後重新啟動代理。可以讀取但格式錯誤的 network-key 檔案會自動被取代。

代理：經過數次輪詢仍顯示「no merged pack」​

先在 /rspm status 檢查已確認參與 RSPM 的後端數量。沒有確認參與者的新代理會繼續探索後端，不會將每個已註冊伺服器都視為故障的 RSPM 後端。未確認的伺服器不會延誤資源包同步。

有已確認參與者時，連續四輪沒有內容會觸發診斷，列出參與者、嘗試的 HTTP URL 與結果。預設間隔為五秒，網路操作可能延長實際經過的時間。診斷會說明常見的修復方式：

  • 每個後端皆顯示 CONNECT_FAILED → 代理無法連到後端的 HTTP 連接埠。請檢查 velocity.toml / config.yml 中設定的位址是否為代理實際可達的位址（而非例如代理網路中無法解析的 Docker 內部名稱），並確認後端通報的 HTTP 連接埠在代理與後端之間是開放的。該橫幅會印出它嘗試的確切 URL；在某個後端通報其連接埠之前，代理會回退至 mcPort + network-http-offset-v2，因此早期的 CONNECT_FAILED 也可能表示該後備連接埠尚不可達。
  • 每個後端皆顯示 NOT_FOUND_404 → 後端正在運作但未產生 Bedrock 資源包。請在每個後端執行 /rspm status；Bedrock Pack 診斷區塊會告訴你原因。

該橫幅在每次「卡住」期間只會觸發一次，當至少一個後端開始重新回傳內容時，會記錄一行「NetworkSync: recovered」。更多資訊請參閱代理網路。

代理：首次代理啟動時 Bedrock 玩家看不到模型​

Geyser 只在代理啟動時才會註冊其自訂物品表。如果代理在任何後端產出 Bedrock 資源包之前啟動，Geyser 會在空對應表的狀態下運行，並維持整個工作階段不變。

在代理記錄 Merged Bedrock pack published at ... 後重新啟動代理。RSPM 會在啟動時預先部署上次執行保存的對應資料，讓後續啟動可以註冊它們。啟動後加入的新識別碼可能再次需要這個步驟。

後端：「Backend HTTP server failed to bind on port X」​

在網路模式下，後端會透過一個小型 HTTP 伺服器公開其 Bedrock 輸出。若連接埠被佔用或無法使用，主控台會出現多行的 [ERROR] 區塊。修復方式：

  • 在 config.yml 中將 selfHostPort 設為另一個正整數。
  • 或變更 networkHttpOffset-v2，讓自動衍生的連接埠避開衝突（例如 RCON 在 mcPort + 1？將其設為 2 或 3）。你不需要更新代理以保持一致：一旦後端成功綁定，它就會自動向代理通報其實際的 HTTP 連接埠，因此代理本身的 network-http-offset-v2 只在通報之前作為猜測才有意義。

當後端 HTTP 伺服器停擺時，此後端的 Bedrock 資源包無法透過直接擷取送到代理。但 magmaguy.com 中繼回退仍能運作（後端會將檔案推送到中繼端點，代理則從那裡擷取）。

清理過時的 v1 設定​

從 RSPM v1 升級的操作員，其 config.yml 中可能還留有失效的 networkHttpOffset（沒有 -v2）鍵。RSPM v2 刻意不讀取舊鍵——下次啟動時會自動將 v2 預設值（1）寫入設定。失效的 v1 鍵會作為無害的殘留留在設定中，直到你手動清理為止。