Fix ItemsAdder resource-pack delivery before changing item files
If several ItemsAdder items appear as vanilla materials or missing textures, first identify whether the client received the right pack. Rebuilding item definitions or clearing data can make a download problem harder to diagnose and can affect items players already own.
Keep the failing example intact
Record the server's Minecraft version, ItemsAdder build and the affected player's exact client version. Check the selected ItemsAdder release and dependency requirements against the official documentation. A client admitted through protocol translation can still interpret a resource pack differently from the server's native client version. Start with a matching Java client before investigating translated or Bedrock connections.
Keep copies of the ItemsAdder configuration, content definitions, generated pack and any ID data that your release maintains. Save the current pack delivery settings too. Choose one existing item with a known internal ID and make a note of its expected appearance. Do not rename its namespace or regenerate mappings during this investigation.
Find the failed stage
- Read the first pack-generation error in the console. An invalid model or content configuration needs a generation fix before any hosting change can help.
- If generation completed, identify the exact pack URL that the configured hosting method sends. Check the installed release's hosting documentation; a file in the server directory does not establish that players can download it.
- Open that URL in a private browser window without panel login. It should deliver the intended archive, rather than a sign-in page, sharing preview or security challenge.
- Compare the downloaded archive with the generated output you intended to publish. Inspect its top-level pack metadata and assets without editing the only copy.
Check the client request
Ask the test player to enable server resource packs for this server entry, reconnect and record whether a download prompt or error appears. Open the client's resource-pack or latest log and capture the relevant failure around that time. Redact private paths and unrelated account information before sending it to support.
If the download works outside Minecraft but the game rejects it, check pack format, archive structure and the release-specific ItemsAdder notes for that Minecraft version. A successful HTTP response only proves delivery. A valid ZIP can still contain an incompatible model or assets in the wrong folder.
Check whether the proxy, server properties or another plugin also sends a resource pack. Document which component owns pack delivery. Test one intended sender on a copy or during maintenance rather than disabling several systems on a live network. Custom-item functionality can depend on the pack you temporarily stop sending.
Repair one layer and verify
Correct the generation error, direct-download hosting setting or client compatibility issue you identified. If you self-host, request an allocated TCP port from support; the examples in plugin documentation do not reserve that port for your service. Keep hosting credentials private and use the documented publishing procedure for your installed release.
Reconnect with the matching Java client and inspect the original test item plus a second custom item. Keep the previous pack available until those checks pass. Restore the saved pack and settings if the change fails, without deleting custom blocks or players' inventories.
Related CloudExa guides
check Java resource-pack delivery · back up the server files · collect the relevant Minecraft logs
No comments to display
No comments to display