[SPIGOT-1903] getTo() wrong location Created: 12/Mar/16  Updated: 23/Oct/16  Resolved: 23/Oct/16

Status: Resolved
Project: Spigot
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: meytro Assignee: Unassigned
Resolution: Fixed Votes: 23
Labels: 1.9, bug, entity

Issue Links:
is duplicated by SPIGOT-2733 Bug with WorldBorder Plugin Resolved
Plugin: WorldBorder


With the plugin "WorldBorder" and the 1.9 Spigot there is a bug that teleports players to the worldborder if they travel through a nether portal from the overworld.

The developer wrote that we should take the problem up to you, I'm sorry that I'm not able to tell you what the problem is exactly but thats the quote from the developer:

"_It's a bug in Spigot to do with the PlayerTeleportEvent not always reporting the correct getTo() location in relation to nether portal teleportation. Take it up with them.

Specifically, getTo() is returning the location coordinates they're coming from in the overworld rather than their destination location coordinates._"

Comment by Dave Goldsmith [ 12/Mar/16 ]

I think I'm having the same problem with WorldBorder and Spigot 1.9. I'm wondering if this is related to https://hub.spigotmc.org/jira/browse/SPIGOT-1807 and the PlayerTeleportEvent being called twice when going through a nether portal, with the getFrom() and getTo() locations being identical on the second call.

Comment by John Delsasi [ 13/Mar/16 ]

Hello, this is John Delsasi, avid minecrafter (lol) and server operator. This bug is really bamboozling me. My friends and I can't play!

Comment by Quinn N [ 13/Mar/16 ]

This is a pretty big issue, would like to see a fix soon

Comment by mibby mibster [ 17/Mar/16 ]

Can also confirm this issue. Pretty important, lots of players complaining about portals taking them past the border since it teleports them to the 1:1 coordinate location in the world before figuring out the compression for where they should actually be.

Comment by Josh Van Wingerden [ 19/Mar/16 ]

I am having the same issue, please fix soon!

Comment by The Dark Psycho [ 20/Mar/16 ]

I can confirm my server is also having this issue

Comment by Daniel Boston [ 22/Mar/16 ]

To all watchers and users of WorldBorder in 1.9, check my pull request here: https://github.com/Brettflan/WorldBorder/pull/60

Basically, the teleport event is totally fine. What is messing WorldBorder up is that the player object's world is altered first, then inventory and x,y,z location are altered after a short delay. This is messing with WorldBorder's standard checkPlayer timed routine as world and x,y,z location within the world are momentarily out of sync. Consistency is eventual, however; so my pull request simply "turns off" the standard check for a few ticks, to allow the player state to resynchronize. Not a final solution, but for now it will work.

The only issue here is the eventual consistency problem. World should never be updated in the player object independent of x,y,z location, yet, it is. Within the PlayerTeleportEvent, however, there is no inconsistency and in my testing it always reports the correct location until mangled by WorldBorder's checkPlayer update.

Comment by PseudoKnight [ 26/Mar/16 ]

A few of us did some testing and discovered a few things.

  • Can be reproduced if you teleport a player to another world when they step on a pressure plate.
  • At some point it thinks you are moving within the same world to the new xyz coordinates.
  • Sometimes "moved too quickly!" is triggered and the issue is corrected.
  • Sometimes "moved wrongly!" is triggered and causes potentially catastrophic results. (see below)
  • Symptom: teleporting to the wrong world at the right xyz coordinates (often resulting in death).
  • Symptom: one player was able to be in two worlds at once, creating this: https://www.youtube.com/watch?v=Rgau2J2hv7Q
Comment by Brett Flannigan [ 11/Apr/16 ]

@aikar has looked into it and submitted a pull request to CraftBukkit/Spigot to fix the root problem, so it should hopefully be fixed soon.

Comment by Brett Flannigan [ 13/Apr/16 ]

Since it's taking a while for Spigot to accept his pull request, anyone wanting the fix right now can get it by running Paper:

Comment by Dave Goldsmith [ 15/Apr/16 ]

Is there a process that someone uses to decide which bugs get fixed and which do not? It seems like some issues are addressed very quickly, while others are ignored. This bug report was made over a month ago, and there's even a submitted fix that appears to work (it's been incorporated into PaperSpigot, which seems to run very well), but no action has been taken. I don't normally say much on forums or in these bug reports, but this bug-fixing process (or lack thereof) does get frustrating. After all, isn't one of the goals here to make Spigot as bug-free as possible?

Comment by dididi [ 17/Apr/16 ]

@md_5 Please, check out pull request.

Comment by PseudoKnight [ 17/Apr/16 ]

I was able to reproduce the problem with end portals on Paper after this fix was added. (Paper 685) In my case it seems to be always be caused by teleports triggered during collisions.(end portal or physical interact event listener teleporting player) It says "moved wrongly" in console as always and the player is in the wrong location.

Comment by Brett Flannigan [ 17/Apr/16 ]

Interesting, the problem still exists in some circumstances even in Paper, then.

Since I don't think it was fully addressed here in this ticket, the actual problem at hand is the Player object's Location having the World updated but the coordinates stuck briefly (maybe a second or so, not sure exactly how long) to the coordinates in the old world, mismatching the World reference. This is all within the data provided by player.getLocation() immediately after the player has teleported between worlds.
Since WorldBorder (my plugin) checks player locations every 5 ticks by default to make sure they're not outside of the border for the world they're in, that mismatch of World and coordinates can trigger them being moved "back inside the border" from the incorrect coordinates.

The problem definitely does seem to be fixed in Paper 686 with Nether portals, anyway, so that's at least something. Previously with WorldBorder testing on Spigot, most trips through a Nether portal either way would trigger the bug. When I tested in Paper 686 I could no longer reproduce the bug after 25-30 trips back and forth through the same Nether portal I previously tested.
Obviously my testing did only include Nether portals, and not End portals or any other method of teleporting between worlds.

Comment by Dave Goldsmith [ 23/Apr/16 ]

I concur with the two previous comments that the problem is fixed in Paper for Nether portals, but still exists for End portals. With End portals, about half the time the teleportation goes just fine for me, but about half the time I get the "moved wrongly" warning and then end up in the wrong location which, in my case, means I fall out of the End world and die. Not fun. And, of course, the problem still exists in Spigot with both Nether portals and End portals.

Comment by SpacePuppeh [ 26/Apr/16 ]

I'm having this happen even after removing the plugin WorldBorder. I submitted something about this, and it was marked as a duplicate. Is this a second, separate problem from the WorldBorder one?

Comment by PseudoKnight [ 27/Apr/16 ]

WorldBorder is just one of many plugins that can be affected by this. The symptoms can be much worse depending on which plugins you use and how they're configured. As mentioned above, end portals are unreliable right now. In testing, it puts the player in the wrong location the majority of the time. This happens even on worlds without WorldBorder. I've had to write code to workaround this issue so that players don't get themselves killed most times they go through.

Comment by Matt Enloe [ 02/Sep/16 ]

This continues to be an issue for servers using multiple worlds, and can seriously affect player experiences.

Comment by Luisa [ 19/Oct/16 ]

Issue still happening for me. https://hub.spigotmc.org/jira/browse/SPIGOT-2733

Comment by Black Hole [ 19/Oct/16 ]

@Luisa How do you expect an issue to be fixed if you don't update to a version that includes the fix?

Comment by Luisa [ 20/Oct/16 ]

Last build (#55), 17 days ago. How am I suppose to update my builtools that has a fix from yesterday, if the last update was on the 2nd October?

Comment by Max Peters [ 20/Oct/16 ]

You have to update spigot, not BuildTools...
Do you know what BuildTools does?

Comment by Luisa [ 20/Oct/16 ]

"Run BuildTools:
Code (Bash):
java -jar BuildTools.jar
You're done! Check your folder for the server jars. Thanks for using CraftBukkit | Spigot."

Yes, I know how to read guides.

Comment by Max Peters [ 20/Oct/16 ]

BuildTools gets all the updates and builds you a new spigot.jar.
If the devs commit a fix you can find that in the changelog
When that happens, what you have to do is rerun BuildTools, so that it pulls that updated code and packs it into a new spigot.jar
Then you have to use that new jar to run your server.

When you Update BuildTools you only get a new Toolchain, not a new server jar.

Comment by Luisa [ 20/Oct/16 ]

Oh okay. Thank you for the explanation. Cheers!

Comment by md_5 [ 23/Oct/16 ]


Generated at Sat Jan 22 02:05:29 UTC 2022 using Jira 8.21.0#821000-sha1:de61880939b2921ff7847fe221d818d723678af0.