# Multiverse-NetherPortals tasks Task guides and troubleshooting for Multiverse-NetherPortals. Check the installed release before changing configuration or data. # Correct a Nether portal pair that only works in one direction An explicit NetherPortals link is directional. A working journey from the overworld does not prove the return world points back. Inspect both arrows before rebuilding portals or adjusting coordinates, especially when a custom Nether name prevents automatic matching. ## Work through the change 1. Record the source and destination managed world names and confirm both worlds are loaded. Use the documented link listing to inspect the Nether links in each direction. 2. Check whether each arrow comes from an explicit link or the naming convention. Preserve any existing custom reverse destination before replacing it with a bidirectional pair. 3. Use the link syntax for the installed release to create the intended reverse direction or a verified bidirectional link. Change only the Nether portal type during this trial. 4. Travel out and back with an expendable account from known portal coordinates. Test another portal in the source world because the link applies to that world’s portal type, not just one frame. ## Check the result Both directions should arrive in the intended managed worlds. Coordinate placement still depends on scaling and counterpart portal search, so a correct reverse world can produce a different physical frame. Keep link policy and coordinate alignment as separate acceptance checks. Draw both arrows in the maintenance notes rather than writing only that the worlds are linked. Testing the outward trip proves one direction. Keep existing arrow destinations before using a bidirectional operation because updating the return link can replace another route that players already depend on. ## Recover or stop safely Restore the earlier arrows if the trial breaks a custom resource-world route. An unlink can return a world to automatic naming rather than disabling travel entirely. Retain the old listing and verify it again before reopening the route to regular players. ## Related guidance and maintainer reference For the broader setup, read [Link Nether and End worlds with Multiverse-NetherPortals](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/link-nether-and-end-worlds-with-multiverse-netherportals). Check the installed plugin version before applying syntax from the [official Multiverse-NetherPortals documentation](https://mvplugins.org/netherportals/fundamentals/commands-usage/). # Check Nether coordinate scaling before moving a portal network World scale controls the coordinate ratio between linked worlds. Changing it does not move old portals or terrain. Inspect the existing scales and link arrows before rebuilding a transport network that appears to exit too far from its intended location. ## Work through the change 1. Record both managed worlds, their scale properties and the source portal coordinates. Confirm the destination link points to the world you actually intend to use. 2. Calculate the documented source-scale to destination-scale ratio for a test coordinate. For an ordinary overworld and Nether pair, compare that expectation with the installed world properties rather than assuming their defaults. 3. Use a staging copy or isolated portal area to trial one corrected scale if needed. Keep the original values and do not change both worlds at once while diagnosing the result. 4. Travel each direction and record the requested and actual destination coordinates. Inspect nearby existing counterpart portals, since the search may choose a frame near the calculated position. ## Check the result The coordinate relationship should follow the chosen scale ratio within the portal search behaviour of the installed server. Test a second, more distant portal before accepting the correction. A short-distance test close to the origin can hide a large proportional error. Check both positive and negative coordinates near the trial portals. Rounding and portal search can make the final landing differ from a simple mental calculation. Keep the documented scaling ratio separate from the game’s later search for an existing valid destination portal. ## Recover or stop safely Restore the old scale if the trial disrupts established travel and retain the original frames. Recheck both directions after recovery. Do not delete destination chunks or move player bases to compensate for an unverified ratio; fix the world property and document the network policy first. ## Related guidance and maintainer reference For the broader setup, read [Link Nether and End worlds with Multiverse-NetherPortals](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/link-nether-and-end-worlds-with-multiverse-netherportals). Check the installed plugin version before applying syntax from the [official Multiverse-NetherPortals documentation](https://mvplugins.org/netherportals/fundamentals/basic-usage/). # Diagnose a Nether portal with no destination world A lit portal can fail when NetherPortals cannot resolve a managed destination. The plugin does not create the missing world just because a player enters the frame. Confirm the intended saved world exists before generating anything under a guessed name. ## Work through the change 1. Record the source world and portal type, then inspect the link listing. Check whether an explicit destination overrides the configured automatic naming convention. 2. List managed and loaded worlds through Multiverse-Core. Compare the destination’s exact name with the world data you expect, taking care not to confuse an alias with an internal name. 3. If the intended world exists, load or repair its managed reference through the documented workflow after a backup. If this is a new dimension, plan its creation separately with a distinct name and confirmed generator. 4. Test the route with a single expendable account, then verify its return link. Read the bounceback or no-destination message as diagnostic evidence instead of treating it as a reason to suppress all warnings. ## Check the result The portal should reach the intended existing dimension and its expected landmarks. An empty newly generated world is not a successful repair when players expected their saved Nether. Check both the managed name and the actual map contents before allowing traffic. List the destination world’s loaded state and environment before repairing a link. A plausible world name does not prove that the destination exists or is managed. Preserve its files and check startup errors if loading failed; do not create a replacement world over an unexplained folder. ## Recover or stop safely Restore the prior explicit link if the new target is wrong and keep access closed while locating the intended world. Preserve any existing dimension folder untouched. A backup and an explicit world inventory are safer recovery tools than repeatedly creating worlds until a portal responds. ## Related guidance and maintainer reference For the broader setup, read [Link Nether and End worlds with Multiverse-NetherPortals](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/link-nether-and-end-worlds-with-multiverse-netherportals). Check the installed plugin version before applying syntax from the [official Multiverse-NetherPortals documentation](https://mvplugins.org/netherportals/reference/faq/). # Disable Nether travel for one event world while keeping its saved dimension An event may need normal Nether travel closed for a limited period. Use a world-specific link policy and preserve the dimension data. Removing the saved Nether folder changes far more than whether players can enter it during the event. ## Work through the change 1. Record the event world’s current Nether arrow, reverse arrow and naming convention. Move test players to a safe lobby and keep an administrator recovery route available. 2. Read the installed NetherPortals documentation for disabling one portal type through a self-link. Apply the policy only to the named event world and retain the previous explicit target. 3. Try a normal lit Nether portal with an ordinary player account. Check the response and verify that End travel and an unrelated survival world still follow their existing rules. 4. Inspect menus and command-based warps that could still send players to the dimension. Decide whether those independent routes should remain available rather than assuming the portal policy closes every access path. ## Check the result The selected portal type should remain unavailable in the event world while other worlds and dimensions retain their intended routes. The dimension’s saved data should remain present and unchanged. Tell players whether a temporary denial is intentional so they do not rebuild frames to work around it. Check whether the event should block Nether travel only, End travel only or both. Each route needs its own observation. Keep the saved dimension available for later use and record the difference between disabling a route and removing a link that allows automatic discovery again. ## Recover or stop safely Restore the recorded explicit target or remove the self-link according to your intended automatic naming policy when reopening travel. Test a round trip before the event ends. Removing an explicit link may restore automatic travel, so verify the resulting arrow instead of assuming unlink means disabled. ## Related guidance and maintainer reference For the broader setup, read [Link Nether and End worlds with Multiverse-NetherPortals](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/link-nether-and-end-worlds-with-multiverse-netherportals). Check the installed plugin version before applying syntax from the [official Multiverse-NetherPortals documentation](https://mvplugins.org/netherportals/fundamentals/commands-usage/).