Portals spawning outside of worldborder (1.14.1)

[OEUG99]

I am currently using v1.9.0 and CraftBukkit version git-Spigot-03bd4b0-49e15b4 (MC: 1.14.1)

The issue occurs when you try to create a portal and go through it, what I believe is happening is the portal is outside of the worldborder, and as a result unable to create, and no portal is being created, so the player gets teleported to the world spawn with the message "you have reached the edge of this world" while also causing a huge lag spike on the server.

[Brettflan]

When a newly generated portal on the receiving end would be outside the border of the receiving world, the target location is attempted to be directed back inside the border.

[OEUG99]

When a newly generated portal on the receiving end would be outside the border of the receiving world, the target location is attempted to be directed back inside the border.

This isn't happening on my end, I believe it's because mojang recently changed portal mechanics, which loads chunks, even if the portal is inside the worldborder it has a tendency not to generate, or redirect and the player gets teleported to the world spawn.

[iperrealistico]

Same problem here! Even if i enable portal redirection! So many people is having the same problem

On Paper 94 and latest spigot version

[magmiy]

Same problem here...

[totemo]

I can see in the other bugs that I've referenced as possible duplicates (#137, #144, #140) that there is some argument over whose "fault" it is. For what it's worth, Spigot 1.14.4 build 2437 (and earlier) is firing some nonsensical teleport events even when WorldBorder is not loaded. So it's not WorldBorder's bug. I'll be raising it with the Spigot devs.

I have the following test code in a plugin:

    @EventHandler()
    public void onPlayerTeleport(PlayerTeleportEvent event) {
        plugin.getLogger().info("onPlayerTeleport(): " + event.getCause() +
                                " from " + formatBlockLoc(event.getFrom()) +
                                " to " + formatBlockLoc(event.getTo()));
    }

which produces the following logs when I go from the nether back to the overworld:

onPlayerPortal(): NETHER_PORTAL from (world_nether,296,68,321) to (world,2370,68,2568)
onPlayerTeleport(): NETHER_PORTAL from (world_nether,296,68,321) to (world,2370,68,2568)
onPlayerTeleport(): UNKNOWN from (world_nether,2370,68,2568) to (world_nether,2332,65,2466)
onPlayerTeleport(): UNKNOWN from (world,2332,65,2466) to (world,2332,65,2466)

• The PlayerPortalEvent logs exact nether side coordinates and the projected location of the corresponding portal in the overworld, computed by dividing X and Z by 8. There is no portal at those exact coordinates in the overworld.
• The first PlayerTeleportEvent (NETHER_PORTAL) simply echoes the coordinates used by the PlayerPortalEvent.
• The second PlayerTeleportEvent (UNKNOWN) is moving the player from the projected overworld coordinates to the actual coordinates of the portal in the overworld. However, the world is wrong - it is shown as the source world, world_nether, and that's a problem for us because our nether border (1500) is smaller than our overworld border (3500) and WorldBorder detects this event as an attempt to cross the border.
• The third PlayerTeleportEvent (UNKNOWN) is teleporting the player 0 blocks at the actual location of the portal in the overworld. This ensures that the player ends up in the destination world.

So clearly, there's a bug in Spigot whereby spurious teleport events are fired at plugins like WorldBorder.

It's not your fault, @Brettflan, but on the other hand it would be nice if WorldBorder added some defensive code to detect this sequence of events based on the preceding PlayerPortalEvent and the succeeding PlayerTeleportEvents with reason UNKNOWN.

For my paper trail:

• 59

• https://hub.spigotmc.org/jira/browse/SPIGOT-1903
• https://hub.spigotmc.org/jira/browse/SPIGOT-1906
• https://hub.spigotmc.org/jira/browse/SPIGOT-1807

Spigot bug raised: https://hub.spigotmc.org/jira/browse/SPIGOT-5252

[Brettflan]

It looks like they finally fixed it: https://hub.spigotmc.org/jira/browse/SPIGOT-5252

So it should hopefully be handled in the next Spigot release.