Link Nether and End worlds with Multiverse-NetherPortals

Multiverse-NetherPortals chooses which world a normal Nether or End portal leads to. It is different from a custom Multiverse-Portals gateway. Changing a link can redirect every portal of that type in the source world, so inspect the current route before changing it.

Inventory the worlds and current routes

Confirm that compatible Multiverse-Core and Multiverse-NetherPortals releases are installed. Record the actual identifiers of the overworld, Nether and End worlds, including any version-specific namespace format. The addon does not create a missing destination world merely because a player enters a portal.

Take a completed backup of every affected world and the Multiverse configuration before altering established travel. Keep a copy outside the server and note the existing links. See game backups and world creation and import.

Inspect automatic links first

Run /mvnp list as an authorised administrator. The output distinguishes explicit routes, automatic routes and disabled portal types. Copy the result into your maintenance notes before changing anything.

Default naming rules commonly pair a world with its Nether and End counterparts, but those rules are configurable. Check the plugin's current configuration and actual world list rather than renaming folders until a naming convention happens to match. Existing worlds may contain valuable builds, farms or player locations.

Set an explicit route when needed

1. Choose a source, portal type and destination. Confirm that the destination is loaded and that its environment and spawn area suit your plan.
2. Check the installed /mvnp help. Current documentation uses /mvnp link nether survival resource_nether for an example one-way Nether route.
3. Replace the example identifiers with your recorded values. Console commands omit the slash and should provide both source and destination explicitly.
4. Read the success or error response, then inspect /mvnp list again.
5. Create a reverse route only if the design requires it. The documented --bidirectional flag changes both directions and can replace existing routes on both sides; review both first.

Do not change all links just because one portal's exit is awkward. A world route and the physical portal-search result are different parts of the process.

Test coordinates and permissions

Use a quiet maintenance window and a non-operator test account. Enter from a safe source portal, record the arrival world and coordinates, then test the return journey. Check ordinary world-access permissions and claim protections at both ends.

Coordinate scaling affects where the destination portal is searched for or created. The usual Overworld-to-Nether relationship differs from a custom world pair. Inspect the worlds' scale properties before adjusting them; changing scale does not move existing terrain or portals into a new position.

If travel does nothing, confirm that a valid destination exists and review bounceback or disabled-route behaviour. If it goes to the wrong world, inspect explicit links before automatic naming. Avoid deleting portal blocks or dimensions during diagnosis.

Send support the route list, source/destination identifiers, portal type and test coordinates. Further reading: linking and scaling and command reference.

Looking for another plugin? Browse the Minecraft plugin guide directory.