The method $playert->transfer(...) is closing the player after sending the TransferPacket.
In most of my attempts the Transfer did not work because the TransferPacket never reached my client (confirmed by Wireshark) and I have only been disconnected from the server.
After I removed the line $this->close("", $ev->getMessage(), false); it worked at all of my attempts (same when I'm using a plugin which sends the TransferPacket and is not closing the player).
Maybe this timing issue does not affect all servers, but I think in my case the client is disconnected to early.
And I also think the close() is not needed because the client will disconnect the server session when the TransferPacket has reached. The only downside is that the disconnect reason would then be "logged out due to client disconnect" and not "logged out due to transfer".
Because the built-in /transferserver command is also using this method it can be used for testing.
_Expected result_: Client is disconnected from the server and then automatically connected to the new server.
_Actual result_: Client is only disconnected.
PocketMine-MP 1.6.2dev 「Unleashed」 implementing API version 3.0.0-ALPHA5 for Minecraft: PE v1.0.5.0 beta (protocol version 105)
This literally always happened to me when I was sending TransferPacket and then using $player->close() or $player->kick().
And I also think the close() is not needed because the client will disconnect the server session when the TransferPacket has reached.
What about mods that ignore TransferPackets?
(what I was doing is send the TransferPacket, then schedule task to kick them 1 second later)
Oh mods - good point! And yes, a delayed task to kick the transfered player would probably help. I was hoping that a needed delay could be implemented into the server or that dktapps has another magical solution.
@SleepSpace9 @jojoe77777
PocketMine-MP is single threaded, code should run and synchronize one line at a time. This seems to be a timing issue with packets being sent... PocketMine's RakLib library has actually a ton of problems with packets, just last summer dktapps fixed a bug where client disconnect messages would not show up most of the time.
By scheduling the close function, that is just a hack not a solution. The whole RakLib library needs a re-write though that is not a priority right now and dktapps is very busy with re-writing network handling. This issue is actually abstractly related to #465, which is a critical issue.
@madecode15 That would be on the "rewrite-crap" branch of RakLib
Why do there need to be a close after the transfer ? The client sends back a disconnect packet after being transfered, no ?
@Guillaume351 read comments higher up before repeating the same questions.
As I recall, a similar issue occurred with regular disconnects not so long ago with RakNet disconnects reaching the client before the MCPE-layer DisconnectPacket, causing disconnect messages to not be shown.
@madecode15 it was @svilex , not me :P why do I get the credit for the weird bug fixes?
Could someone test the referenced commit? I cannot reproduce this issue on LAN.
Unable to reproduce on latest commit
Works for me 👍
Closing as Fixed, if the issue occurs again let me know.
Yes - unable to reproduce after latest commit! :tada:
Big thanks dktapps!
@dktapps you should read this post on the forum.
I stated that out after you added the close line, do you remember this? ;) @dktapps
Sometimes it works (I can confirm this, just did once), sometimes it doesn't. Please reproduce few times more with remote server, not the local one. Results may vary.


I get the issue with closing too, when the transfer packet doesnt come to the client. Happens when the server has a short lag/peak, or the client has a really bad ping. Though this happens with all packets.
Most helpful comment
Yes - unable to reproduce after latest commit! :tada:
Big thanks dktapps!