# Nexo tasks Task guides and troubleshooting for Nexo. Check the installed release before changing configuration or data. # Check a Nexo item stack-size change before updating inventories A stack-size change can affect storage and item handling even when the model looks unchanged. Compare new and existing copies before applying the change to items players already own. ## Check the installed content Nexo manages custom content through item definitions, resource-pack files and optional mechanics. A correct item identifier does not prove that the client received the matching pack. Follow the documentation for your installed build and keep its generated assets with the source definitions. ## Work through the change 1. Record the item ID, base material and existing stack size on your installed Minecraft and Nexo versions. Back up the item definition and a staging inventory containing representative copies. 2. Check the matching version tab in the component reference. Create a temporary item ID with the intended maximum stack size and no unrelated mechanics. 3. Obtain fresh test copies and combine or divide stacks in an ordinary inventory and a chest. Include one stack near the intended limit and one transfer through your normal shop or menu. 4. Compare the new test item with an old copy after a staging restart. Check the supported item-update behaviour before expecting stored copies to inherit the new component. ## Verify the result Stacks should respect the intended limit without disappearing, duplicating or losing the Nexo identity. Shops and rewards should handle quantities that cross the new boundary correctly. ## If the result differs If only a third-party menu behaves incorrectly, test normal inventory handling first and report the integration difference. If the component does not load, inspect version support rather than repeatedly regenerating the resource pack. ## Keep a recovery path Restore the saved definition and test inventory checkpoint if the new limit is unsuitable. Do not force a mass inventory conversion while stack behaviour is uncertain; document any required migration separately. ## References and related help Check the maintainer reference: [Nexo documentation](https://docs.nexomc.com/configuration/items/components). 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 Nexo durability and repair materials on expendable tools A tool can have the right appearance while wearing out or repairing incorrectly. Separate maximum damage, current damage and allowed repair materials during a controlled trial. ## Check the installed content Nexo manages custom content through item definitions, resource-pack files and optional mechanics. A correct item identifier does not prove that the client received the matching pack. Follow the documentation for your installed build and keep its generated assets with the source definitions. ## Work through the change 1. Record the tool ID and expected durability and repair policy. Check the component reference against the exact Minecraft version, because available item components differ between releases. 2. Create a disposable staging tool with only the relevant durability settings. Obtain a fresh copy and perform a repeatable task that normally consumes durability. 3. Test the intended repair material through the supported vanilla interaction. Include a material that should fail, and check whether the repaired tool keeps its name and other components. 4. Repeat with a copied older tool and inspect the difference. Add other custom mechanics only after the simplified tool wears and repairs as designed. ## Verify the result The tool should lose the intended amount of durability and accept only the planned repair path. Its identity and unrelated enchantments should remain intact after a valid repair. ## If the result differs If the tool never takes damage, inspect its unbreakable or conflicting component settings. If repairs remove custom identity, isolate the anvil or integration behaviour before increasing durability values. ## Keep a recovery path Restore the previous definition and retain the disposable comparison tools for diagnosis. Keep valuable player equipment out of the test; editing a definition does not necessarily reverse damage already stored on an item. ## References and related help Check the maintainer reference: [Nexo documentation](https://docs.nexomc.com/configuration/items/components). 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). # Make a Nexo consumable return the intended container A consumable that returns a bowl or bottle needs both correct consumption and correct remainder behaviour. Test a small disposable stack before connecting it to a shop or quest reward. ## Check the installed content Nexo manages custom content through item definitions, resource-pack files and optional mechanics. A correct item identifier does not prove that the client received the matching pack. Follow the documentation for your installed build and keep its generated assets with the source definitions. ## Work through the change 1. Write down when the item may be consumed, how many units it should use and which container should remain. Check the installed-version component examples for food, consumption and remainder support. 2. Create a separate staging item with the minimum required components. Avoid command rewards or extra mechanics until the basic consumption cycle works. 3. Consume one item from a single-item slot and then from a larger stack. Repeat with a nearly full inventory so you can observe how the returned container is handled. 4. Test after relogging and after an orderly staging restart. Compare fresh items with existing copies to identify updater behaviour rather than assuming the definition rewrites every stored item. ## Verify the result Each use should consume the intended amount and produce only the planned container and effect. Players should not receive an endlessly reusable reward or unexpected extra stack. ## If the result differs If the item displays correctly but cannot be used, inspect component compatibility and consumption conditions. If it works only with a fresh copy, review the supported update policy before replacing anything in production. ## Keep a recovery path Restore the previous consumable definition and remove the disposable item from test rewards. Keep a record of distributed test copies because configuration rollback cannot undo already applied effects or returned containers. ## References and related help Check the maintainer reference: [Nexo documentation](https://docs.nexomc.com/configuration/items/components). 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). # Preserve selected item components in a Nexo upgrade recipe An upgrade recipe may need to keep a tool name or enchantments instead of replacing them with a clean output. Check which input supplies each preserved component before enabling valuable upgrades. ## Check the installed content Nexo manages custom content through item definitions, resource-pack files and optional mechanics. A correct item identifier does not prove that the client received the matching pack. Follow the documentation for your installed build and keep its generated assets with the source definitions. ## Work through the change 1. Record the intended input, output and components that must survive. Confirm that your installed release supports the preserve behaviour documented for the selected recipe type. 2. Copy the recipe under a staging identity and use expendable named or damaged tools. Preserve only the specific components required by the design rather than treating the input as an unrestricted template. 3. Craft with one eligible input and compare its name, damage and enchantments with the output. Include an input lacking one selected component to inspect the documented fallback behaviour. 4. If several inputs could supply the same component, test their order explicitly. The current recipe reference describes selection from the first matching grid input, which matters for ambiguous upgrades. ## Verify the result The output should retain exactly the selected input state and use the configured defaults elsewhere. The recipe should consume the intended inputs once and return the correct Nexo item ID. ## If the result differs If the wrong state survives, inspect ingredient selection and grid order. If nothing survives, check feature support and recipe type before changing the item definition or resource pack. ## Keep a recovery path Restore the previous recipe and stop offering the upgrade until the component comparison passes. Keep the pre-test inventory checkpoint because changing a recipe cannot reconstruct components lost by an earlier craft. ## References and related help Check the maintainer reference: [Nexo documentation](https://docs.nexomc.com/general-usage/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). # Restrict a Nexo recipe to the intended crafting station A recipe designed for automation should not automatically become available in every crafting interface. Test the intended station and the interfaces that must reject it. ## Check the installed content Nexo manages custom content through item definitions, resource-pack files and optional mechanics. A correct item identifier does not prove that the client received the matching pack. Follow the documentation for your installed build and keep its generated assets with the source definitions. ## Work through the change 1. Identify whether the design requires an ordinary shaped recipe, a shapeless recipe or a crafter-only recipe. Check the installed-release recipe reference before choosing a folder or type. 2. Build a disposable staging recipe with a distinct low-value output. Keep its ingredients simple so a failed match is distinguishable from a station restriction. 3. Try the same ingredients in the intended station, a crafting table and the player inventory grid where they fit. Record the actual result from every applicable interface. 4. Test an automated cycle only after manual station behaviour is correct. Count ingredients and outputs across several cycles to catch repeated processing or an unrelated recipe collision. ## Verify the result The intended station should produce the configured output while excluded interfaces reject it. Existing recipes using similar ingredients should retain their original results. ## If the result differs If every interface accepts it, inspect the loaded recipe type and check for a duplicate ordinary recipe. If no interface accepts it, verify the ingredient identity and initial load errors before changing station rules. ## Keep a recovery path Remove the disposable recipe from the staging load and restore the saved recipe files if necessary. Keep automation disconnected during diagnosis so a mistake cannot process a stockpile before you notice it. ## References and related help Check the maintainer reference: [Nexo documentation](https://docs.nexomc.com/general-usage/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). # Check a Nexo furniture hitbox independently of its model A furniture model can look correct while blocking the wrong space or accepting clicks in an unexpected area. Use an empty test plot to compare appearance and interaction boundaries. ## Check the installed content Nexo manages custom content through item definitions, resource-pack files and optional mechanics. A correct item identifier does not prove that the client received the matching pack. Follow the documentation for your installed build and keep its generated assets with the source definitions. ## Work through the change 1. Record the furniture ID and the intended placement and collision area. Follow the hitbox documentation linked from the mechanic index for the installed release and supported entity type. 2. Back up the test world and furniture definition. Place a single expendable copy on a clear floor without region protection or nearby decorative entities obscuring the result. 3. Approach from every side and test movement, targeting and the intended interaction. Compare the visible edges with the area that actually blocks or accepts the player action. 4. Change only the selected hitbox property on staging and retest a freshly placed copy. Include removal and replacement so an old placed instance does not hide the effect of the definition change. ## Verify the result The furniture should occupy the intended space and remain usable and removable through its documented interaction. The test should leave no unexpected invisible obstacle after normal removal. ## If the result differs If the visual model is wrong, troubleshoot pack delivery separately. If only protected plots differ, inspect the protection integration before enlarging a hitbox or granting players bypass permissions. ## Keep a recovery path Restore the previous definition and the small staging-world checkpoint if the trial leaves inconsistent placed objects. Avoid editing live decorative areas or deleting nearby entity types as a shortcut to removing one test object. ## References and related help Check the maintainer reference: [Nexo documentation](https://docs.nexomc.com/mechanics). 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 Nexo tooltip change without hiding important item state A cleaner tooltip should still tell players enough to identify and use an item. Test the relevant tooltip component on supported clients before removing all information from valuable equipment. ## Check the installed content Nexo manages custom content through item definitions, resource-pack files and optional mechanics. A correct item identifier does not prove that the client received the matching pack. Follow the documentation for your installed build and keep its generated assets with the source definitions. ## Work through the change 1. Record which tooltip lines should remain visible and which should be hidden. Check the component reference for your Minecraft version instead of mixing older item flags with newer tooltip fields. 2. Create a temporary copy of the item and change only its tooltip settings. Keep the original identity, damage and enchantments represented in the comparison inventory. 3. Inspect both items on supported clients and at ordinary interface scales. Check anvils, shops and custom menus that may display their own version of the item information. 4. Test the ordinary player workflow for identifying a damaged, enchanted or restricted item. Confirm that necessary information remains available before adopting the shorter presentation. ## Verify the result The item should show the intended lines consistently and retain its actual server-side behaviour. A hidden tooltip should not be mistaken for removal of the underlying enchantment or component. ## If the result differs If a line remains in one custom menu, inspect that menu output separately. If the component fails to load, review the selected version tab and first configuration warning rather than regenerating unrelated textures. ## Keep a recovery path Restore the earlier tooltip settings and keep the original item definition. Do not replace player items to repair a presentation-only issue until you have confirmed the release-supported update behaviour. ## References and related help Check the maintainer reference: [Nexo documentation](https://docs.nexomc.com/configuration/items/components). 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). # Audit Nexo references before retiring a custom item Removing a definition can break recipes, rewards and placed content that still reference it. Build a dependency list before deciding whether a custom item can safely be retired. ## Check the installed content Nexo manages custom content through item definitions, resource-pack files and optional mechanics. A correct item identifier does not prove that the client received the matching pack. Follow the documentation for your installed build and keep its generated assets with the source definitions. ## Work through the change 1. Export the Nexo item definitions and search the downloaded configuration copy for the exact item ID. Include recipes, shop files, quest rewards and other plugin integrations in the search. 2. Classify references as new-item creation, existing-item use or placed content. Keep a separate note of items that players may own even when no configuration currently distributes them. 3. Disable new distribution on staging while retaining the definition. Test that existing copies still display and interact correctly and that dependent recipes do not fail during startup. 4. Plan a separate migration only if the definition must be removed. Decide how existing inventories and placed instances will be handled before changing the persistent ID or deleting its assets. ## Verify the result The audit should identify every configured creation path and the known persistent uses. Stopping new distribution should leave existing legitimate items usable unless a documented migration deliberately changes them. ## If the result differs If an unknown reference appears in logs, add its owning plugin to the inventory rather than immediately removing the warning-producing content. A renamed display label does not resolve a missing internal ID. ## Keep a recovery path Restore the saved distribution files if the retirement trial breaks progression. Keep the definition and assets available until the dependency and player-data migration is complete and a recovery copy has been verified. ## References and related help Check the maintainer reference: [Nexo documentation](https://docs.nexomc.com/configuration/items). 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).