# ItemsAdder tasks Task guides and troubleshooting for ItemsAdder. Check the installed release before changing configuration or data. # Organise ItemsAdder content without changing existing namespaces Moving a content pack between folders can break references if you also change its namespace. Treat file organisation and item identity as separate changes. ## Check the installed content ItemsAdder content uses namespaced identifiers for items and other assets. A definition, its generated resource pack and the copy downloaded by a player are different checkpoints. Keep content IDs stable and consult the documentation matching your ItemsAdder and Minecraft releases. ## Work through the change 1. Download the relevant contents subfolder and list the namespaces declared in its YAML files. Record several existing namespaced item IDs that players already own. 2. Choose one of the folder layouts supported by the installed-release documentation. Keep the namespace declaration and the model or texture paths compatible with that one layout. 3. Move a small self-contained content group on a staging copy. Avoid mixing layout methods inside the same sub-pack or renaming its IDs during the move. 4. Generate the staging pack through the documented procedure, then inspect the original test items and obtain fresh copies of the same IDs for comparison. ## Verify the result Existing and newly obtained test items should retain their identity and appearance. The pack build should resolve each referenced asset from its new organised location without missing-file warnings. ## If the result differs If only existing items fail, inspect updater or item-version behaviour separately from the folder layout. If both copies fail, compare the namespace and asset path against the downloaded known-working files. ## Keep a recovery path Restore the entire moved content group and its matching pack output if the layout trial fails. Do not delete generated identity mappings or replace player items to make a directory reorganisation appear successful.
![CloudExa game panel file browser](https://help.cloudexa-hosting.com/cloudexa/guides/20261108/game-files.png)
Use the CloudExa file browser to inspect the relevant plugin folder. This is the panel interface, not a third-party plugin editor.
## References and related help Check the maintainer reference: [ItemsAdder documentation](https://wiki.itemsadder.com/plugin-usage/beginners/configs-and-resourcepack/). Before changing live data, read [how to keep a completed recovery copy](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes). For startup errors, use [the log collection guide](https://help.cloudexa-hosting.com/books/game-hosting/page/find-minecraft-logs-and-send-useful-troubleshooting-details). # Find an ItemsAdder item that loads under the wrong namespace An item can exist but appear under an unexpected identifier when its namespace declaration differs from the folder you expected. Inspect the loaded identity before renaming anything. ## Check the installed content ItemsAdder content uses namespaced identifiers for items and other assets. A definition, its generated resource pack and the copy downloaded by a player are different checkpoints. Keep content IDs stable and consult the documentation matching your ItemsAdder and Minecraft releases. ## Work through the change 1. Record the full item ID shown by the installed plugin, including the namespace before the colon. Compare it with recipe, loot and menu references that try to use the item. 2. Open the relevant content YAML and inspect its namespace declaration. Check the complete sub-pack rather than assuming the folder name alone determines every supported layout. 3. On a staging copy, correct references to the intended existing ID. If you actually need a new namespace, plan it as a content migration with preserved old definitions. 4. Load the staging content and test one direct item retrieval, one recipe or reward reference and one existing player-held copy. Keep each result in the change record. ## Verify the result The same intended identifier should resolve through all tested references. Existing items should remain recognisable; a successful fresh give is not sufficient evidence that old inventory content survived. ## If the result differs If an ID remains missing, inspect the first YAML or asset-loading error for that pack. A file that never loaded can look like a namespace problem even when its declaration is correct. ## Keep a recovery path Restore previous references if the change makes existing content unreachable. Keep the old namespace available until a deliberate migration has a tested recovery path; do not remove it just to tidy tab completion. ## References and related help Check the maintainer reference: [ItemsAdder documentation](https://wiki.itemsadder.com/plugin-usage/beginners/configs-and-resourcepack/). Before changing live data, read [how to keep a completed recovery copy](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes). For startup errors, use [the log collection guide](https://help.cloudexa-hosting.com/books/game-hosting/page/find-minecraft-logs-and-send-useful-troubleshooting-details). # Check ItemsAdder texture path case after a Linux move A texture reference that worked on another machine may fail on a case-sensitive filesystem. Compare exact filenames before changing the resource-pack host or replacing item IDs. ## Check the installed content ItemsAdder content uses namespaced identifiers for items and other assets. A definition, its generated resource pack and the copy downloaded by a player are different checkpoints. Keep content IDs stable and consult the documentation matching your ItemsAdder and Minecraft releases. ## Work through the change 1. Choose one affected item and follow its definition to the model and texture files. Record the full relative path at each step rather than searching only by display name. 2. Compare upper-case and lower-case characters in the model references with the real filenames. Also check extensions and nested directory names in the content sub-pack. 3. Correct one mismatch on the staging copy while preserving the namespaced item ID. Rebuild the pack and verify that the generated archive contains the expected asset path. 4. Download the exact staging pack as a client, then inspect a fresh test item and an existing copy. Keep unrelated shader or texture-pack changes out of this test. ## Verify the result The intended texture should appear when the client uses the newly generated pack. The server-side item should keep its original behaviour and identity throughout the path correction. ## If the result differs If the archive contains the asset but the client still shows a missing texture, examine the model reference and client resource-pack log. If the asset is absent, investigate content layout or pack-generation errors first. ## Keep a recovery path Restore the previous file names and references as one set if the test affects other models. Preserve the working archive for comparison; deleting the whole content folder hides the evidence you need. ## References and related help Check the maintainer reference: [ItemsAdder documentation](https://wiki.itemsadder.com/plugin-usage/beginners/configs-and-resourcepack/). Before changing live data, read [how to keep a completed recovery copy](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes). For startup errors, use [the log collection guide](https://help.cloudexa-hosting.com/books/game-hosting/page/find-minecraft-logs-and-send-useful-troubleshooting-details). # Add a test recipe without replacing a live ItemsAdder recipe A new custom-item recipe should use a separate identity and inexpensive ingredients while you test it. Keep the existing production recipe available until the replacement behaves as intended. ## Check the installed content ItemsAdder content uses namespaced identifiers for items and other assets. A definition, its generated resource pack and the copy downloaded by a player are different checkpoints. Keep content IDs stable and consult the documentation matching your ItemsAdder and Minecraft releases. ## Work through the change 1. Read the recipe section for your installed ItemsAdder release and identify which recipe type matches the design. Record its output ID and the identities of any custom ingredients. 2. Create a staging recipe under a new internal name in the appropriate content YAML. Use an existing test item as the output so asset creation does not obscure recipe errors. 3. Try the exact ingredient layout, then deliberately change one ingredient and one slot. Test with an ordinary player who has only the permissions the design requires. 4. Craft several outputs, restart the staging server in an orderly way and test again. Inspect whether another plugin or vanilla recipe claims the same crafting pattern. ## Verify the result The recipe should consume the intended inputs and return the expected quantity only for a valid combination. Its registration should survive a normal restart without replacing an unrelated recipe. ## If the result differs If crafting fails, confirm that each custom ingredient ID exists before editing the shape. If the wrong result appears, inspect recipe-key or pattern collisions rather than adding more broad permissions. ## Keep a recovery path Remove the new staging recipe or restore its previous file before production rollout. Keep a record of test outputs and never use valuable live ingredients to diagnose a recipe that may consume them without the expected return. ## References and related help Check the maintainer reference: [ItemsAdder documentation](https://wiki.itemsadder.com/plugin-usage/beginners/configs-and-resourcepack/), [ItemsAdder documentation](https://wiki.itemsadder.com/adding-content/recipes/). Before changing live data, read [how to keep a completed recovery copy](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes). For startup errors, use [the log collection guide](https://help.cloudexa-hosting.com/books/game-hosting/page/find-minecraft-logs-and-send-useful-troubleshooting-details). # Test an ItemsAdder furniture hitbox before placing it at spawn A furniture model can look correct while its interaction area blocks a doorway or fails to match the visible object. Check placement geometry in an expendable test area first. ## Check the installed content ItemsAdder content uses namespaced identifiers for items and other assets. A definition, its generated resource pack and the copy downloaded by a player are different checkpoints. Keep content IDs stable and consult the documentation matching your ItemsAdder and Minecraft releases. ## Work through the change 1. Record the furniture ID and copy its definition, model and texture into the staging content set. Preserve the original ID in your backup before adjusting any placement properties. 2. Consult the installed-release furniture and size reference. Start with a model whose intended footprint fits a small marked area, keeping decorative commands or storage actions disabled. 3. Place the test furniture in several orientations beside a wall, doorway and open floor. Try walking past it, interacting from each side and breaking it using an ordinary permitted account. 4. Repeat after leaving and reloading the test area. Check that one placement produces one intended interaction target and that removal clears the complete test object. ## Verify the result Players should be able to interact with the visible furniture in its intended footprint, without an invisible obstruction remaining after removal. The orientation should not create an unexpected larger collision area. ## If the result differs If the model alone looks displaced, compare model origin and display transforms. If the interaction target is wrong, inspect the furniture placement and size settings for this release instead of changing its texture. ## Keep a recovery path Restore the prior furniture definition and remove only the disposable placements. Keep a world backup before editing furniture already used in public builds, especially if it includes storage or multiple underlying entities. ## References and related help Check the maintainer reference: [ItemsAdder documentation](https://wiki.itemsadder.com/plugin-usage/beginners/configs-and-resourcepack/), [ItemsAdder documentation](https://wiki.itemsadder.com/adding-content/furnitures/). Before changing live data, read [how to keep a completed recovery copy](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes). For startup errors, use [the log collection guide](https://help.cloudexa-hosting.com/books/game-hosting/page/find-minecraft-logs-and-send-useful-troubleshooting-details). # Check a custom ItemsAdder sound before adding it to rewards A silent custom sound can result from a missing pack asset, a mismatched identifier or client audio settings. Test the sound on its own before connecting it to a quest or reward. ## Check the installed content ItemsAdder content uses namespaced identifiers for items and other assets. A definition, its generated resource pack and the copy downloaded by a player are different checkpoints. Keep content IDs stable and consult the documentation matching your ItemsAdder and Minecraft releases. ## Work through the change 1. Record the sound identifier, source audio file and the content pack that owns it. Check the supported audio format and sound definition requirements in the installed-release documentation. 2. On a staging copy, add or correct one sound entry without changing item IDs. Build the pack and inspect that its sound definition and audio asset appear in the generated archive. 3. Join using that exact pack and confirm the relevant client sound categories are audible. Trigger the sound through the documented test or usage method for your release. 4. Repeat with a second client, then connect the verified sound to one low-value test action. Compare direct playback with playback through that action. ## Verify the result Both test clients should hear the intended sound through the direct test and the dependent action. A failure only in the action points to its reference or trigger rather than the resource-pack download. ## If the result differs If no client hears it, inspect the client log and generated archive before increasing volume. If one client fails, compare pack acceptance and client audio settings; avoid changing the server definition to compensate for a muted category. ## Keep a recovery path Restore the previous sound definition and keep the action on its original feedback until playback works. Retain source audio and generated files together so a later pack rebuild does not discard the working asset. ## References and related help Check the maintainer reference: [ItemsAdder documentation](https://wiki.itemsadder.com/plugin-usage/beginners/configs-and-resourcepack/), [ItemsAdder documentation](https://wiki.itemsadder.com/adding-content/adding-sounds/). Before changing live data, read [how to keep a completed recovery copy](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes). For startup errors, use [the log collection guide](https://help.cloudexa-hosting.com/books/game-hosting/page/find-minecraft-logs-and-send-useful-troubleshooting-details). # Limit an ItemsAdder custom block to the intended test world Custom blocks can affect world storage and mining behaviour, so test their availability in the intended world before including them in a public build kit or reward. ## Check the installed content ItemsAdder content uses namespaced identifiers for items and other assets. A definition, its generated resource pack and the copy downloaded by a player are different checkpoints. Keep content IDs stable and consult the documentation matching your ItemsAdder and Minecraft releases. ## Work through the change 1. Choose a disposable custom-block ID and record the worlds where you want it available. Back up the affected world and content definitions as one checkpoint. 2. Check the installed-release custom-block world controls and placement permissions. Configure the staging rule for one test world rather than changing every world at once. 3. Try placing, breaking and obtaining the block in the allowed world with a normal player. Repeat those actions in a world that should remain excluded. 4. Restart the staging server and inspect the placed test block again. Test adjacent vanilla blocks so a block-state conflict does not go unnoticed. ## Verify the result The allowed world should support the expected placement and break behaviour, while the excluded world should follow the chosen restriction. Existing nearby vanilla blocks should keep their normal appearance and drops. ## If the result differs If the rule affects only item giving, distinguish acquisition from placement checks. If a block changes after restart, inspect storage and mapping errors before editing the model or assigning a different ID. ## Keep a recovery path Restore the matching world and content checkpoint if persistent block data changes incorrectly. Do not remove a live custom-block definition while its blocks remain in player builds; plan and test a migration first. ## References and related help Check the maintainer reference: [ItemsAdder documentation](https://wiki.itemsadder.com/plugin-usage/beginners/configs-and-resourcepack/), [ItemsAdder documentation](https://wiki.itemsadder.com/adding-content/blocks/enable-disable-custom-blocks-in-worlds/). Before changing live data, read [how to keep a completed recovery copy](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes). For startup errors, use [the log collection guide](https://help.cloudexa-hosting.com/books/game-hosting/page/find-minecraft-logs-and-send-useful-troubleshooting-details). # Validate an ItemsAdder font image in chat and a menu title A font image may work in chat but fail in a menu title because the consumer handles text differently. Compare the same glyph through two controlled display paths. ## Check the installed content ItemsAdder content uses namespaced identifiers for items and other assets. A definition, its generated resource pack and the copy downloaded by a player are different checkpoints. Keep content IDs stable and consult the documentation matching your ItemsAdder and Minecraft releases. ## Work through the change 1. Record the font-image ID and its texture path. Confirm the generated pack includes the font definition and image before editing the chat or menu plugin. 2. Use the installed-release font-image reference to select its supported text notation. Test a simple message with that notation and a client using the current pack. 3. Put the same image into a staging menu title that supports the documented integration. Keep the title short and remove other formatting while checking the image. 4. Compare alignment, size and permissions between the two displays with an ordinary account. Test a second client before changing global font spacing. ## Verify the result The same intended image should appear in both supported display contexts, with no raw placeholder or missing-character box. A correctly rendered glyph can still need a separate title-spacing adjustment. ## If the result differs If chat works but the menu does not, verify that the menu plugin supports the required placeholder or font format. If both fail, inspect pack generation and font-image identity before changing permissions. ## Keep a recovery path Restore the original title and font entry if the test makes other text unreadable. Keep the previous pack available, because changing shared font metrics can affect several interfaces even when only one title prompted the change. ## References and related help Check the maintainer reference: [ItemsAdder documentation](https://wiki.itemsadder.com/plugin-usage/beginners/configs-and-resourcepack/), [ItemsAdder documentation](https://wiki.itemsadder.com/adding-content/font-images/). Before changing live data, read [how to keep a completed recovery copy](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes). For startup errors, use [the log collection guide](https://help.cloudexa-hosting.com/books/game-hosting/page/find-minecraft-logs-and-send-useful-troubleshooting-details). # Check an ItemsAdder consumable before distributing it to players A custom food or drink can display correctly while consuming the wrong amount or applying an unintended effect. Test its behaviour with disposable items and an ordinary account. ## Check the installed content ItemsAdder content uses namespaced identifiers for items and other assets. A definition, its generated resource pack and the copy downloaded by a player are different checkpoints. Keep content IDs stable and consult the documentation matching your ItemsAdder and Minecraft releases. ## Work through the change 1. Copy the consumable definition to a staging ID and record the intended stack size, consumption result and effect. Consult the installed Minecraft and ItemsAdder component requirements. 2. Start with one supported consumable behaviour and omit command rewards or chained actions. Obtain a small number of test items rather than adding the item to live shops. 3. Consume the item while hungry and under the other conditions the design allows. Check the remaining stack, returned container and any effect duration. 4. Repeat after relogging and after a normal staging restart. Compare a fresh copy with one obtained before the definition change to identify updater differences. ## Verify the result The player should consume the intended quantity and receive only the planned effect or return item. The action should not leave a reusable reward loop or duplicate containers. ## If the result differs If the appearance works but use does not, inspect behaviour or component loading errors rather than pack delivery. If only older copies differ, check the release-supported item update policy before replacing player inventory. ## Keep a recovery path Restore the previous consumable definition and withdraw the staging item from test rewards. Record any test copies already distributed; a configuration rollback does not reverse effects or remove consumables from inventories. ## References and related help Check the maintainer reference: [ItemsAdder documentation](https://wiki.itemsadder.com/plugin-usage/beginners/configs-and-resourcepack/), [ItemsAdder documentation](https://wiki.itemsadder.com/adding-content/items/consumable/). Before changing live data, read [how to keep a completed recovery copy](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes). For startup errors, use [the log collection guide](https://help.cloudexa-hosting.com/books/game-hosting/page/find-minecraft-logs-and-send-useful-troubleshooting-details). # Prepare an ItemsAdder content update with a stable ID inventory A content update can rename or remove items that already exist in player storage. Build an ID inventory before merging a new pack so you can identify destructive changes. ## Check the installed content ItemsAdder content uses namespaced identifiers for items and other assets. A definition, its generated resource pack and the copy downloaded by a player are different checkpoints. Keep content IDs stable and consult the documentation matching your ItemsAdder and Minecraft releases. ## Work through the change 1. Export the current content folder and list the namespaces and item IDs used by recipes, shops, rewards and placed objects. Include content supplied by third-party add-ons. 2. Compare the incoming pack in a separate directory. Mark removed IDs, reused IDs, changed asset paths and changes to persistent blocks or furniture rather than merging it over production. 3. Apply the update to a staging copy with representative old items, placed objects and containers. Generate its pack and inspect the first load errors before inviting testers. 4. Test old and new copies of selected items, crafting, placement and a clean restart. Record any migration method the pack author requires for your installed release. ## Verify the result Existing content should retain its intended identity and behaviour after the update. Every removed or changed persistent ID should have a documented migration decision before the production maintenance window. ## If the result differs If the pack loads but old items fail, inspect updater and migration behaviour. If a new ID reuses an old purpose, stop the merge; changing a texture alone cannot resolve conflicting persistent identities. ## Keep a recovery path Recover the previous content, generated pack and affected world or inventory state from the same checkpoint if the migration fails. Restoring only the plugin JAR can leave incompatible updated data behind. ## References and related help Check the maintainer reference: [ItemsAdder documentation](https://wiki.itemsadder.com/plugin-usage/beginners/configs-and-resourcepack/). Before changing live data, read [how to keep a completed recovery copy](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes). For startup errors, use [the log collection guide](https://help.cloudexa-hosting.com/books/game-hosting/page/find-minecraft-logs-and-send-useful-troubleshooting-details).