如何在Spigot/Bukkit插件中实现传送门定向到对应世界？

Alright, let's get that portal redirection sorted for your Spigot world management plugin rewrite. This is a common feature for world management tools, so here's a straightforward, tested approach to make it work exactly how you need.

1. Listen to the PlayerPortalEvent #

First, you'll need to hook into Spigot's PlayerPortalEvent—this fires whenever a player interacts with a Nether or End portal, giving you full control over where they're teleported.

Create a listener class like this:

import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.player.PlayerPortalEvent;
import org.bukkit.plugin.java.JavaPlugin;
import org.bukkit.Location;

public class PortalRedirector implements Listener {
    private final JavaPlugin plugin;

    public PortalRedirector(JavaPlugin plugin) {
        this.plugin = plugin;
        plugin.getServer().getPluginManager().registerEvents(this, plugin);
    }

2. Handle Nether Portal Redirection #

For your example where entering a Nether portal from plotworld sends players to plotworld_nether, we'll check the current world's name and map it to the corresponding Nether world. We'll also handle the reverse (returning from plotworld_nether to plotworld).

Add this event handler method inside the listener class:

@EventHandler
    public void onNetherPortalUse(PlayerPortalEvent event) {
        if (event.getPortalType() != PlayerPortalEvent.TeleportCause.NETHER_PORTAL) {
            return;
        }

        String currentWorld = event.getPlayer().getWorld().getName();
        String targetWorld;

        // Check if we're coming FROM a Nether world (returning to overworld)
        if (currentWorld.endsWith("_nether")) {
            targetWorld = currentWorld.substring(0, currentWorld.length() - 6);
        } 
        // Or going TO the Nether from an overworld
        else {
            targetWorld = currentWorld + "_nether";
        }

        // Only redirect if the target world exists
        if (plugin.getServer().getWorld(targetWorld) != null) {
            Location targetLoc = event.getTo().clone();
            targetLoc.setWorld(plugin.getServer().getWorld(targetWorld));
            event.setTo(targetLoc);
        }
    }

3. Handle End Portal Redirection #

Next, handle the End portal scenario: if a player is in myworld_the_end and uses the return portal, send them back to myworld. We'll also add support for sending players from myworld to myworld_the_end when they use an End portal.

Add this second event handler (separating keeps the code clean):

@EventHandler
    public void onEndPortalUse(PlayerPortalEvent event) {
        if (event.getPortalType() != PlayerPortalEvent.TeleportCause.END_PORTAL) {
            return;
        }

        String currentWorld = event.getPlayer().getWorld().getName();
        String targetWorld;

        // Return from End to overworld
        if (currentWorld.endsWith("_the_end")) {
            targetWorld = currentWorld.substring(0, currentWorld.length() - 8);
            // For return portals, send to the overworld's spawn (adjust if needed)
            if (plugin.getServer().getWorld(targetWorld) != null) {
                event.setTo(plugin.getServer().getWorld(targetWorld).getSpawnLocation());
            }
        } 
        // Go from overworld to End
        else {
            targetWorld = currentWorld + "_the_end";
            if (plugin.getServer().getWorld(targetWorld) != null) {
                Location targetLoc = event.getTo().clone();
                targetLoc.setWorld(plugin.getServer().getWorld(targetWorld));
                event.setTo(targetLoc);
            }
        }
    }
}

4. Register the Listener #

Don't forget to initialize the listener in your plugin's main class onEnable() method:

@Override
public void onEnable() {
    new PortalRedirector(this);
    // Rest of your plugin initialization code
}

• Pre-created Worlds: Make sure the target worlds (like plotworld_nether or myworld_the_end) exist before players use the portals—you can either create them manually or add logic to generate them in your plugin if needed.
• Configurable Mappings: For better flexibility, replace the hardcoded suffixes (_nether, _the_end) with a config file. Let users define custom world pairs (e.g., plotworld: custom_plot_nether) instead of relying on naming conventions.
• Coordinate Handling: The code above preserves the portal's relative coordinates, but you might want to adjust this for End returns (sending to spawn is standard, but you could keep relative positions if that fits your plugin's design).
• Error Handling: Add logging (using plugin.getLogger().info()) to track when a target world doesn't exist, so you can debug issues easily.

内容的提问来源于stack exchange，提问作者TheLukeGuy