Skip to main content

Resource Pack Manager FAQ

If your question is not answered here, check the other ResourcePackManager pages in the sidebar first.

What commands does ResourcePackManager currently expose?​

On the backend (Paper / Spigot), the code-backed command surface is:

  • /rspm setup — opens an in-game GUI setup menu (plugin update status, recommended plugins, automatic-updates toggle, links to wiki / Discord / Nightbreak account)
  • /rspm reload — rebuilds and re-hosts the merged pack
  • /rspm status — full diagnostic dump (pack state, hosting mode, network key, integrations)
  • /rspm itemsadder configure — configures ItemsAdder for RSPM hosting
  • /rspm itemsadder dismiss — permanently dismisses the ItemsAdder warning for your player UUID
  • /rspm data_compliance_request — downloads all remotely stored data for this server

The root command is /resourcepackmanager, with /rspm as its alias. A handful of shared MagmaCore/Nightbreak subcommands (e.g. /rspm recommendedplugins, /rspm downloadall) are also registered and are what the setup menu's buttons link to.

Backend permissions:

  • /rspm setup requires resourcepackmanager.setup and is player-only (it opens an inventory GUI).
  • /rspm reload, /rspm status, /rspm itemsadder <configure|dismiss>, and /rspm data_compliance_request all require resourcepackmanager.*.

On the proxy plugin (Velocity / BungeeCord), only diagnostic commands exist:

  • /rspm status — proxy-side snapshot: backend list, per-backend fetch outcomes, merged pack state, Geyser/Floodgate detection
  • /rspm debug bedrock [on|off] — Velocity and BungeeCord. Toggles verbose [RSPM-BedrockDebug] log lines from GeyserBinder for diagnosing "Bedrock player joined but didn't see the pack" cases. Resets to off on proxy restart. Running it with no argument prints the current state.

Proxy commands check resourcepackmanager.command.status or resourcepackmanager.*. Console always has both; players need them granted through your permission plugin. The output is safe to share — the network key is masked and no tokens are printed — so liberal grants are fine.

What plugins are currently supported?​

ResourcePackManager ships with premade integration entries for these plugins:

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

These integrations only take effect if the plugin is installed and its configured local path or remote URL is usable.

Each integration has its own YAML config file under plugins/ResourcePackManager/compatible_plugins/. You can customize isEnabled, pluginName, localPath, url, zips, cluster, additionalLocalPath, and reloadCommand per plugin there. The cluster option tells ResourcePackManager to treat the local path as a directory of multiple resource pack sub-folders that should all be merged together.

Is ResourcePackManager compatible with ItemsAdder?​

Yes. ResourcePackManager includes a built-in helper and warning flow for ItemsAdder.

If ItemsAdder is installed and still needs to be adjusted for ResourcePackManager hosting, OP players get a clickable warning a few seconds after joining. Players who permanently dismissed the warning do not see it again. From there you can:

  • run /rspm itemsadder configure to set resource-pack.hosting.no-host.enabled: true, disable all three protect-file-from-unzip settings, set compress-json-files: false, run /iareload then /iazip, and then reload ResourcePackManager (~15s later)
  • run /rspm itemsadder dismiss to permanently dismiss that warning for your player UUID

If ItemsAdder is already configured to host its own pack through one of its hosting modes, the helper command does not override that automatically. It tells you to disable ItemsAdder hosting yourself first.

Can I add my own pack to the merge?​

Yes. Put your .zip file in:

plugins/ResourcePackManager/mixer

If you want to control which pack wins file conflicts, add the exact filename, including .zip, to priorityOrder in plugins/ResourcePackManager/config.yml.

Example:

priorityOrder:
  - ResourcePackManager
  - EliteMobs
  - MyCustomPack.zip

How does priority work?​

priorityOrder is highest priority at the top and lowest priority at the bottom.

For non-mergeable files, the higher-priority pack replaces the lower-priority file. For mergeable JSON files, ResourcePackManager merges the contents instead of blindly replacing them.

The code currently treats these as mergeable:

  • sounds.json
  • language files under lang or languages
  • vanilla item model JSON under minecraft/models/item (these get a non-recursive merge: only the overrides array is combined across packs, while the rest of the file follows highest-priority-wins)
  • atlas files
  • font files
  • 1.21.4+ item model definitions under items/ (format-aware merging: leaves predicate trees intact, doesn't blindly recurse into different node types)

pack.mcmeta is merged specially: the highest pack_format wins, supported_formats ranges are widened to cover all packs (supports the integer, two-int array, and {min_inclusive, max_inclusive} object forms), overlay entries are combined, and non-standard top-level keys (e.g. sodium) are preserved. Overlay entries are normalized for 1.21.9+ compatibility by adding min_format/max_format fields when missing.

After all packs are merged, ResourcePackManager merges base atlas sources into overlay atlas files. This prevents overlays from accidentally shadowing base atlas entries when Minecraft activates an overlay (e.g. ItemsAdder's ia_overlay_modern_atlas / ia_overlay_legacy_atlas).

Other JSON files are replaced instead of merged.

Packs that are not listed in priorityOrder are still included in the merge but receive the lowest priority.

Does ResourcePackManager rebuild automatically when packs change?​

Yes. It watches supported pack sources for changes.

When a watched pack stops changing for 3 seconds, ResourcePackManager marks it as stable. Once all watched packs are stable, the remix happens immediately. During that transition, online OP players are notified: "All resource packs are stable. Mixing and sending now."

Does the watchdog account for plugin initialization?​

Yes. The watchdog is aware of Magmacore plugin initialization states.

  • It waits for all monitored plugins to finish their Magmacore initialization before starting stability checks.
  • If a plugin reloads while the watchdog is running, the watchdog detects the state change, pauses, resets all stability tracking, and waits for the plugin to finish re-initializing.
  • This prevents false "unstable" detections that would otherwise occur during normal plugin startup or reload sequences.

How do players receive the final pack?​

When autoHost is enabled (default), RSPM picks a delivery path automatically and pushes that URL to every joining player. The decision tree is:

  1. If selfHostForce: true, always self-host (skips all probes — mainly for testing).
  2. Otherwise if preferSelfHost: true (default), try self-host first, run three sanity checks (non-LAN resolved host, localhost self-probe, external reachability probe via magmaguy.com), commit to self-host if all three pass.
  3. If self-host fails or is disabled, upload the pack to magmaguy.com/rsp/ and announce that URL.

Once a URL is in hand, RSPM uses the multi-pack API on Minecraft 1.20.3+ so it coexists with other server-sent packs. On older versions it falls back to the older single-pack method, which replaces any existing server resource pack assignment.

If autoHost: false, RSPM does not push any URL — you're expected to take the zip from plugins/ResourcePackManager/output/ and serve it through your own pipeline.

See Self-hosting for the full delivery decision tree.

Can I self-host instead of using the built-in auto-host?​

Yes — and as of RSPM v2, the built-in HTTP server is the recommended self-host path. selfHostEnabled: true and preferSelfHost: true are both on by default.

If you want to host the zip through your own existing web server instead of either built-in path:

  • Set autoHost: false.
  • Optionally set resourcePackRerouting to an existing folder path relative to the plugins directory.
  • Take the merged pack from plugins/ResourcePackManager/output/ResourcePackManager_RSP.zip and serve it yourself.

If resourcePackRerouting is set, RSPM also writes a copy of that zip to the reroute folder. That reroute path is resolved relative to the plugins directory, and the target folder must already exist.

Is there a command to request stored host data?​

Yes. Use:

/rspm data_compliance_request

If the magmaguy.com remote auto-host has an active session, ResourcePackManager downloads the response into:

plugins/ResourcePackManager/data_compliance

If there is no active remote session (e.g. you're self-hosting), the command tells you there is no remote data to request.

What config options are available?​

plugins/ResourcePackManager/config.yml exposes the following:

General

  • priorityOrder — list controlling which packs win file conflicts (highest priority first)
  • autoHost — whether ResourcePackManager auto-hosts and sends the merged pack (boolean, default true)
  • forceResourcePack — whether to force players to accept the pack (boolean, default false)
  • resourcePackPrompt — the prompt shown when the pack is offered (default "Use recommended resource pack?")
  • resourcePackRerouting — optional folder path (relative to plugins) to write an extra copy of the merged zip
  • nightbreak.autoDownloadPluginUpdates — whether RSPM downloads its own plugin updates automatically on startup (boolean, default false; a restart is still required to apply a downloaded update). This is a nested key under the nightbreak: section, not a top-level key — searching config.yml for a bare autoDownloadPluginUpdates line will only find it indented beneath nightbreak:. This is the same toggle exposed in the /rspm setup GUI.

Self-hosting

  • selfHostEnabled — whether the built-in HTTP server may be used (boolean, default true)
  • selfHostPort — port for the self-host HTTP server. -1 (default) auto-derives as mcPort + networkHttpOffset-v2. Set to any positive integer to force an explicit port.
  • networkHttpOffset-v2 — fallback offset added to the Minecraft server port when selfHostPort = -1. Default 1 (e.g. MC 25565 → HTTP 25566). On a network you no longer have to keep this in sync with the proxy: the backend auto-announces the exact HTTP port it actually bound to the proxy, and the proxy only uses its own network-http-offset-v2 as a guess before that announcement arrives.
  • selfHostExternalHost — public hostname or IP that clients use to reach your self-host server. Empty (default) = auto-detect via api.ipify.org / checkip.amazonaws.com.
  • selfHostForce — skips all sanity checks AND the remote upload, always self-hosts (boolean, default false — for testing).
  • preferSelfHost — try self-hosting first with sanity checks before falling back to remote upload (boolean, default true).

Bedrock

  • bedrockConversionEnabled — convert the merged Java pack into a Bedrock pack for GeyserMC (default true)
  • bedrockAutoDeployToGeyser — copy the Geyser custom mappings file into the detected Geyser folder (default true)
  • bedrockGeyserFolder — manual path override for the Geyser folder; empty = auto-detect
  • bedrockConverterDebug — verbose per-item / per-bone log lines from the Bedrock pipeline (default false)

A second file, plugins/ResourcePackManager/bedrock_display_offsets.yml, exposes twelve user-tunable knobs for fine-tuning where Bedrock players see held items relative to their hand (six for first-person, six for third-person). See Bedrock conversion for details.

There is intentionally no network-key config option. The key that links the proxy to its backends is auto-derived from plugins/floodgate/key.pem on every JVM. Floodgate already requires that file to be the same across the network for Bedrock auth, so the derived key matches everywhere automatically.

Can other plugins register their packs through code?​

Yes. ResourcePackManager exposes a Java API for programmatic pack registration. See the API page for details.

Does the Bedrock conversion only work for FreeMinecraftModels?​

No, not anymore. The current converter handles any plugin whose pack ships 1.21.4+ items definitions under assets/<namespace>/items/*.json. That covers FreeMinecraftModels bone models, EliteMobs gear, Oraxen/Nexo custom items, custom armor sets, and any pack you assemble yourself in that format. Plain 2D custom items are emitted as flat Bedrock icons; 3D custom items emit Bedrock geometry/attachables and a software-rendered inventory icon.

Do I need to restart the server every time the Bedrock pack changes?​

Texture and model tweaks to existing custom items take effect for the next Bedrock player to join — RSPM serves the Bedrock pack live per-session via Geyser's API. A restart is only required when the set of custom items changes (adding new ones or removing existing ones), because Geyser registers its custom-item identifiers at boot.

Does ResourcePackManager work on BungeeCord / Velocity?​

Yes — it's a first-class supported topology. It's the same ResourcePackManager.jar everywhere: put it on every backend, and put a copy on the proxy. The one jar bundles the Bukkit, Velocity, and BungeeCord/Waterfall entry points, so it loads correctly whether the host is a backend or a proxy. There are no separate proxy jars and no proxy-extension/ folder anymore.

Running as a proxy plugin, it merges every backend's converted Bedrock pack and serves it to Bedrock clients via the proxy's Geyser. Java pack delivery is still handled by each backend directly — Java clients see per-backend packs.

Setup, troubleshooting, and verification steps are in Proxy networks.