Multiverse-Portals tasks

Task guides and troubleshooting for Multiverse-Portals. Check the installed release before changing configuration or data.

Allow one player role through a Multiverse portal without opening every portal

A portal access node can be narrower than world access or a teleport command. Use that distinction to give event participants one route while keeping staff portals private. Test the rule with an ordinary role and a separate denied account.

Work through the change

  1. Record the exact portal name and destination from portal information. Check whether portal access enforcement remains enabled and whether the destination world has its own access requirement.
  2. Find the documented multiverse.portal.access permission for that named portal. Grant the specific portal capability to a temporary test role without a wildcard or operator status.
  3. Walk through the portal as the role and as the denied account. Capture both results, then try a different restricted portal from the same source world.
  4. If arrival still fails, check destination-world access and safety separately. Keep the successful portal permission unchanged while tracing the next denial so one working layer remains clear.

Check the result

The selected role should use the approved portal and remain denied at the unrelated restricted portal. A successful teleport by an administrator is not the acceptance test. Check inherited groups and temporary permissions if the denied account unexpectedly passes.

Test direct portal use rather than a staff teleport command that skips the portal check. Keep the source world entry permissions and destination access in the notes. A visitor may pass one layer and still be correctly denied by another, so record the actual denial message.

Recover or stop safely

Remove the trial grant if it opens more access than intended and restore the earlier role policy. Leave access enforcement enabled while you investigate the exact permission. A temporary event route should not require publishing unrestricted staff teleport commands to all players.

For the broader setup, read Create a controlled Multiverse-Portal between worlds. Check the installed plugin version before applying syntax from the official Multiverse-Portals documentation.

Set a Multiverse portal landing position and facing without moving its frame

A portal’s destination can point to a world spawn, a second portal or exact coordinates. Choose a coordinate destination when visitors need to face a walkway rather than a wall. Keep the portal region unchanged while you test the landing details.

Work through the change

  1. Record the portal name, current destination and region bounds. Prepare a safe landing platform with enough headroom and mark which direction a visitor should face.
  2. Read the installed destination syntax, including its pitch and yaw fields. Use the documented exact-position or current-location destination rather than guessing the coordinate field order.
  3. Select the named source portal and change only its destination. Walk through as an ordinary visitor and record the arrival coordinates, facing and any safety adjustment.
  4. Repeat from the other side of the source frame and with a second visitor. Inspect whether another teleport plugin moves the player again after the portal action completes.

Check the result

Visitors should arrive on the platform and face the intended route without immediately entering another trigger. Check both the visible orientation and the world name. If the safety system adjusts an unsafe point, repair the landing area before attempting to disable the safety control.

Check the landing position with the destination chunks fully available. A safe-looking coordinate can still face a player into a wall or drop them off an edge during movement. Leave several blocks of clear standing space and repeat the arrival without staff flight enabled.

Recover or stop safely

Restore the recorded destination if the trial produces a loop or unsafe arrival. Keep a staff return route available during testing. Moving the physical frame is unnecessary when the destination alone needs correction, and can leave a hidden trigger at its old coordinates.

For the broader setup, read Create a controlled Multiverse-Portal between worlds. Check the installed plugin version before applying syntax from the official Multiverse-Portals documentation.

Stop an arrival loop between two Multiverse portals

A landing point inside an active return portal can send a player back at once. Portal safety and other teleport plugins can also move the arrival into a trigger. Separate the destination pad from both portal regions before changing global portal behaviour.

Work through the change

  1. Record both portal regions, their destinations and the direction of each link. Keep a staff teleport or console recovery route available for the test account.
  2. Prepare a landing point beyond the destination trigger with clear walking space. Check its world, height and facing using the documented destination format for your installed release.
  3. Change one source destination to the pad and walk through with an ordinary account. Wait without moving, then step toward the return portal to distinguish automatic loops from deliberate re-entry.
  4. Test the opposite route separately and inspect any spawn or last-location plugin that can override the pad. Keep each destination change recorded so you know which leg fixed the loop.

Check the result

The visitor should remain on the landing pad until choosing to enter the next portal. If a loop remains at a location outside both recorded regions, check for an overlapping hidden portal or another teleport action. Breaking frame blocks does not necessarily remove a configured portal region.

Distinguish immediate retriggering from a later scheduled teleport. Ask the tester to stand still on arrival, then walk out deliberately. Timestamped observations help identify whether the destination intersects a portal region or another plugin moves the player after the first transition.

Recover or stop safely

Restore the prior destination only after moving the test player to a safe world. If you need to close a route, use the portal’s documented access or configuration controls and notify participants. Avoid deleting both portal records before recording their bounds and links.

For the broader setup, read Create a controlled Multiverse-Portal between worlds. Check the installed plugin version before applying syntax from the official Multiverse-Portals documentation.

Find an invisible or overlapping Multiverse portal trigger

A configured portal can remain active without a visible frame. When a player teleports from an unexpected floor tile, inspect portal bounds and debug information before rebuilding the area. A second hidden trigger can overlap the decorative portal you already recognise.

Work through the change

  1. Record the exact world and coordinates where the teleport begins. List portals in that world and keep the player outside the suspected trigger during inspection.
  2. Use the documented portal information and debug controls for your installed release. Identify the portal selected at the test position without creating a new region over it.
  3. Compare the stored corners with the intended doorway. Walk a marked perimeter with an expendable account and record which blocks trigger the action, including upper and lower levels.
  4. Correct one portal’s region using the supported modify workflow if its bounds are wrong. Recheck any neighbouring portal rather than assuming the corrected region was the only trigger.

Check the result

The portal should activate only within its intended bounds after debug mode is turned off. Confirm that ordinary walking on the neighbouring path no longer teleports players. Debug mode itself can change whether teleporting occurs, so repeat the acceptance test in normal operation.

Portal regions can remain active when their decorative frame is removed. Record the coordinates of the trigger, not just a screenshot of the visible frame. Inspect vertically overlapping selections so an upstairs entrance does not accidentally include the corridor below it.

Recover or stop safely

Restore the earlier region bounds if the adjustment excludes a required part of the doorway. Keep the original portal record until its references are understood. Removing decorative blocks alone is not a reliable way to disable a hidden configured trigger.

For the broader setup, read Create a controlled Multiverse-Portal between worlds. Check the installed plugin version before applying syntax from the official Multiverse-Portals documentation.

Test a Multiverse portal fee without charging live players

A portal fee can fail because the route uses the wrong currency or because another world entry fee also applies. Trial the charge with a funded test account and a zero-balance account, then compare balances before opening the route to visitors.

Work through the change

  1. Record the portal’s price and currency plus any destination-world entry charge. Check the installed portal documentation and the actual economy provider rather than assuming every Vault integration behaves the same.
  2. Build an isolated test route or limit access to test accounts. Set a small documented fee, retaining the earlier values and avoiding changes to live player balances.
  3. Use the funded account once and record its before-and-after balance or item count. Try the unfunded account and confirm whether entry is denied without losing unrelated items.
  4. Repeat the return trip and any deliberate loop scenario. Check whether players can be charged twice by a portal fee and a separate world entry rule before enabling the production route.

Check the result

The allowed trip should deduct the intended amount once, while the unfunded trip should produce the documented denial. Confirm that failed or unsafe destinations do not create an unexpected debit. A successful teleport and a successful economy transaction need separate checks.

Keep the test balance and transaction record together, including the currency provider. A displayed portal price does not establish a successful charge, and a successful teleport does not establish that the debit happened exactly once. Repeat the denied-balance case with an expendable test account.

Recover or stop safely

Restore the original price and currency after an unsuccessful trial. Reconcile only the documented test transactions through the economy provider’s supported controls. Do not reset an economy database or refund every player to reverse a test that involved two controlled accounts.

For the broader setup, read Create a controlled Multiverse-Portal between worlds. Check the installed plugin version before applying syntax from the official Multiverse-Portals documentation.

Repair a Multiverse portal destination after a target world is renamed

A portal can retain a destination string that no longer matches the managed world name. An alias change and a real world rename are different events. Trace the stored target before creating replacement worlds or overwriting the original destination folder.

Work through the change

  1. Record the portal name and complete destination string. Compare the target with Multiverse’s current world list, including aliases and the names used by other portals.
  2. Confirm that the intended world data exists and is loaded under the expected identity. If the saved world is unavailable, stop and locate it rather than generating a new world with a similar name.
  3. Use the documented portal modification command to change the single stale reference. Preserve any coordinate or facing part of the destination only after verifying it belongs to the same map.
  4. Test the repaired route with an ordinary account and then test its return route. Inspect menus or other portals that refer to the same old world name without performing an unreviewed global text replacement.

Check the result

The route should reach the existing intended map with its builds intact. Check a landmark and the world identity, not just a successful teleport response. If the destination was another portal, repair that portal reference instead of changing the world portion of an unrelated exact-position string.

Check all references to the old internal world name before reopening the portal. An attractive display alias is insufficient if an action still names the former folder. Keep the old destination text in the change record so recovery restores the precise route rather than a guessed equivalent.

Recover or stop safely

Restore the previous destination string if the trial reaches the wrong area and keep the route closed to regular players. Recover any missing world reference through its saved configuration or backup. Reinstalling the server is not required to correct one stale portal target.

For the broader setup, read Create a controlled Multiverse-Portal between worlds. Check the installed plugin version before applying syntax from the official Multiverse-Portals documentation.