Discussion: Oops, I broke your plugins!

Bump. I'm doing some stuff after teleporting, so this is important to me.

If I understand the question correectly then... Once the event has passed through all the plugins and continues to process the move event the teleport happens. However because each plugin has a say in .setTo() you could set the location then the plugin next in line could then change it... However that should be no different than 2 plugins teleporting within the event... only one will come out victorious.

https://github.com/Bukkit/CraftBukk...t/minecraft/server/NetServerHandler.java#L147

Hopefully that comment within the source as well as the source itself can better explain things, I tried to explain in the comment as to why we have to immediately teleport the player if a plugins changes the setTo() location.

Ouch. I want to do some stuff after teleporting (like changing vectors etc.), and it seems like It's impossible now

What was wrong with the old system?

Apologies I forgot to add....

The method used to teleport after the event is fired is -

PHP:

((CraftPlayer) this.player.getBukkitEntity()).teleport(event.getTo());

This method calls the Teleport event, so after the move event if a plugin has changed the setTo() a Teleport event will fire after it, this is to allow plugins to act upon the fact that a player may of changed world during a move event or simply moved 2000 blocks away and out of the border...

When a plugin teleported during the onPlayerMove event or changed the .setTo() to too far of a distance from their previous location... then Notchs speedhack check would trigger and the player would be kicked from the server.

Oh, so now i will have to split my code into two events?

I see that is the problem, but what was wrong with the old system where you manually teleported and activated setTo()?

No, if you triggered teleport event and then used .setTo(), nothing would go wrong.

Just out of curiosity... What are you trying to do with vectors straight after a teleport? What is the outcome you're after?

I simply set vectors (PortalStick plugin)

Do you mean yaw/pitch? Cause you can do that before you warp them.

I believe he wants to continue the players momentum when teleporting the player... so if he jumped into a hole with a portal in then his momentum would continue, and you do that via velocity.

@matejdro - All I can think would be to cancel the event and call the teleport/velocity change 1 tick later... This should be a cleaner method which would avoid the speed check and prevents you from having to listen to multiple events to achieve the same task.

Also a side note... teleporting the player and then calling .setTo() would still cause the player to be kicked. The speed check compares the location from the packet sent by the client compared to the player entities current position... So even if you teleport them before event.setTo() their entity location is updated but the location it's still comparing against is the one in the packet. (Anyways that's what's meant to happen and has happened during our extensive testing in trying to resolve the issue in a different matter... the event.setTo() change was the only logical choice for now.)

Yeah, i should wrote velocity instead of vector, sorry about that.

It sounds like interesting solution. But my point is that i should not be doing that. Why should i do workarounds for changes in API?

@EvilSeph what was wrong with the old system, where you manually teleported player and used .setTo()?

But i already manually teleported player, so that should not be an issue.

Since Notches speed check got implemented teleporting within the onPlayerMove event would almost certainly kick a player from the server... We needed an easy solution for this instead of requesting that every plugin utilizes the scheduler and did it one tick later.

I used this solution and did not have any problems.

@matejdro You have been told numerous times now why it was changed. Just because you do not notice the bug does not mean it does not exist, as a plugin dev I can say that this bug does exist, this change fixes it, and they aren't going to undo it.

By "initialize method" do you mean the onEnable method?

probably, because

Code:

JavaPlugin.
initialize(PluginLoader loader, Server server,PluginDescriptionFile description, File dataFolder, File file,ClassLoader classLoader)

is final.

It seems like this setTo() teleport won't change velocity. No problem for me then

Thanks for trying to explain it to me anyway.

Would you mind telling us what the option is, instead of just that there is one? I can't seem to find it mentioned in the Bukkit javadocs. Of course, I may just be blind.

Edit:
Ok, found the PluginLoadOrder enum... still haven't found where to put it...

My mistake, didn't realize "RTFS" was the standard way of finding out update details. That would explain why I couldn't find it in the javadocs though. Thanks for the answer!

Hey backing up to the PlayerMoveEvent and portals, the actual teleportation works fine, but I have an issue with failed teleporting. When a player enters one of my portals but the destination is not available, it fails and sends a message. Before this update, I prevented spamming the message by only checking when the player changed blocks:
if(!event.getTo().getBlock().equals(event.getFrom()))
This no longer works, and I do not know why, probably due to my lack of understanding of how events work.
I also tried
if(!event.getFrom().getBlock().equals(event.getPlayer().getLocation().getBlock()))
any help? I apologize for any aggravatingly simple solutions.

the legacy method player.teleportTo();
has been removed from craftbukkit in #1060