ProtocolSupport
PE Version?
Now we are on "next year" 😋
(ProtocolSupportPE was miles better than any PE server software)
Yes, but currently the main goal is to port ProtocolSupport to GlowStone, and then i can start thinking about implementing PE.
@Shevchik If there's demand for this i can work on it too. I'm sick of feature requests on my server for things that aren't in pocketmine :/
I also can help by... I don't know, saying "whoa you are awesome keep up the good work!"
(Okay, I can do more useful things than that)
Okay first we need someone familiar with PE itself, so we know how things work. Then we need someone with IDA knowledge because i don't have enough time to both decompile mcpe and code. And we need some testers too and maybe someone who knows how netty internals work to properly implement https://github.com/Shevchik/UdpServerSocketChannel
@Shevchik yeah, getting a MCPE protocol documentation is difficult because there isn't a good documentation like Minecraft PC. However I doubt you will need to decompile MCPE to know the protocol.
MiNET has a good auto generated protocol if you need https://github.com/NiclasOlofsson/MiNET/blob/master/src/MiNET/MiNET/Net/MCPE%20Protocol%20Documentation.md but alas, it is auto generated, so almost no explanation for anything.
For protocol you can also see how PocketMine-MP (or Nukkit or MiNET, better if using PocketMine-MP or MiNET as a "reference" because those are the better implementations of the MCPE network protocol) implements packets as a "documentation".
Before you get your hair pulled out because you can't figure out why the fuck the client doesn't login (I had this issue...), here is the packet order for the login process:
Player sends a LoginPacket (0x01) Server sends a PlayStatusPacket (0x02) with status 0 Server sends a StartGamePacket (0x0c) Server sends a PlayStatusPacket (0x02) with status 3
This a very very very basic handshake, but at least allows you to get the client to login (as in: the player is connected to a world and not stuck on the "Locating server..."/"Building terrain..." screen)
If you need help with the protocol, you can ask @NiclasOlofsson, he is the creator of MiNET and he is probably the person with most knowledge about packets, heck, probably more than Mojang itself!
Also, if "testers" is "someone who can't help with the project at all except for adding some packet translators and etc etc etc but can test with Minecraft Windows 10 Edition + Minecraft Pocket Edition", then count on me!
(Probably I will try donating again to ProtocolSupport (I donated once before in... I don't know? 2015/2016?) because damn Shevchik, you need to receive some awards due to the all work you already done with ProtocolSupport)
The problem is that most fields are still undocumented, or even worse they are actually wrong and it doesn't crash only by pure luck. Or worse due to mcpe inventory being retarded you never know how actually things work, see inventory open which actually pulls inventory info from real time of packet info, or chunk packet which actually expects all tiles nbt to be sent. Which means i still have to decompile mcpe.
@Shevchik There are very few fields that remain undocumented, and even fewer are wrong.
And what lacks in documentation is well made up by assistance by the dev community that deals with the protocols. It's not a big community (maybe 5-10 ppl), but a lot of collaboration going on. Some are good at IDA, some have clients, some just eat bytes for breakfast. But they all help.
But if you believe you need to disassemble MCPE to get the NBT out, yeah .. then maybe you shouldn't waste your time on doing PE.
The only real difficult thing about PE is dealing with encryption. Not because it is difficult to understand, but because it is difficult to get the proper tool-set to deal with it.
Is encryption really needed? To my knowledge it's only needed for players who are logged in with xbox live, and even xbox players can connect to servers without encryption enabled, a decent login plugin would suffice.
@DaMatrix when I was creating my MCPE server from scratch the client (nor my server) never sent any encryption request/response, I'm not using Xbox Live login so I don't know if it is the same thing if you are using Xbox Live.
But if you aren't using Xbox Live (or doesn't care if the client is using Xbox Live login) you can just not send the "ServerToClientHandshake" and never enable encryption, I think the client doesn't care about that.
For a minimal handshake only three packets are used: LoginPacket, PlayStatusPacket and StartGamePacket.
@DaMatrix No, encryption is not mandatory. And you can use XBL without encryption.
@DaMatrix just for science I enabled Xbox Live on MCPE just to see what was going to happen when connecting to my "made from scratch" server, and yep, the client doesn't care at all about encryption.
So don't send "ServerToClientHandshake" after the LoginPacket and then you don't need to care about encryption at all.
EDIT: @NiclasOlofsson replied first about encryption things, whoops.
Well, maybe something changed, i haven't looked at mcpe for a while. Is mcpe inventory still mostly clientside (so you have to guess what actually moved by searching items), or mojang finally fixed this?
@Shevchik they probably fixed that when they released Minecraft Windows 10 Edition. (Which has the Java PC GUI for inventory)
And moving items in a MCPE server while using MCW10 client works like what you would expect in PC Minecraft.
Em 22 de jan de 2017 12:44, "Shevchik" [email protected] escreveu:
Well, maybe something changed, i haven't looked at mcpe for a while. Is mcpe inventory still mostly clientside (so you have to guess what actually moved by searching items), or mojang finally fixed this?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ProtocolSupport/ProtocolSupport/issues/304#issuecomment-274334937, or mute the thread https://github.com/notifications/unsubscribe-auth/AJDnJ3TpF-IkXQ_QNIzT4TDlNxVT_rGJks5rU2sxgaJpZM4KsVxX .
Well, this makes things easier. I'm hoping that we finish glowstone support next week, and then i can start working on PE.
Also we need someone with deep knowledge of RakNet, because there are some issues in it which i don't know how to solve. For example:
- How to disconnect client with custom message when error happened during the initial connection request (Encapsulated layer should not be available yet).
- That happened long time ago, so maybe it is fixed, but there was a problems with ordering index which sometimes skipped ids. (So i had to order packets by seq index)
- What to do when indexes overflow?
- https://github.com/Nukkit/Nukkit/blob/master/src/main/java/cn/nukkit/Player.java#L1907
That's an encapsulated layer packet which is not available at RakNet handshake.
@DaMatrix I think Nukkit never kicks a player before processing the player's LoginPacket.
Well, @MarfGamer has his own RakNet version for Java (that he created to use in his own MCPE server software) and he still maintains it, so maybe he knows those questions.
@Shevchik this should be useful for you ;) https://github.com/sel-project/sel-utils ~ https://github.com/sel-project/sel-utils/blob/master/doc/pocket/100.md
(Or maybe not... anyway, maybe it will be useful for someone else)
Aside from the lack of comments, that format reminds me of wiki.vg's MCPC protocol documentation. looks very useful.
@DaMatrix for me the useful part is the "constants", a generated protocol already exists (MiNET auto generated documentation), but it doesn't includes the valid constants for that packet.
Example: The play status packet is ID 2 and has a unsigned int as a value, but what are the valid values for that unsigned int? MiNET's documentation only has a few comments about constants for some packets, but that documentation has for every packet (okay, I didn't see every packet, but it seems it has for all)
The repository also has auto generated Minecraft Pocket Edition packets in Java (and other languages): https://github.com/sel-project/sel-utils/tree/master/src/java/sul/protocol/pocket100/play
@DaMatrix another very useful thing in this documentation is the Metadata entity flags and MCPE attributes, I never seen something like that before in any other MCPE protocol documentation.
However I also found out that there are some packets missing from that documentation. (As far as I know: The send map item packet is missing and the batch packet is missing (the one used to send the map item data information and the... batch packet))
However, the Batch packet is auto generated but not documented: https://github.com/sel-project/sel-utils/blob/master/src/java/sul/protocol/pocket100/play/Batch.java
Just a small correction about something I said before:
To successfully connect a MCPE client to a server, you need to send the following packets: Player sends a LoginPacket (0x01) Server sends a PlayStatusPacket (0x02) with status 0 Server sends a ResourcePacksInfoPacket (0x07) Server sends a StartGamePacket (0x0c) Server sends a PlayStatusPacket (0x02) with status 3
Yes, the "ResourcePacksInfoPacket" is required, if not sent the client will never join the world.
@MrPowerGamerBR I know this thread is an old topic and that this probably has nothing to do with it, but could you DM me on Twitter? I followed you. I would love to have you on the BeetRoot-MP team as you seem to have important info about the protocol that I have been trying to get a hold of forever now and you seem that you would be a valuable addition to the team!
P.S. The message about the login sequence, thank you so much for posting that. I have spent weeks trying to get the client to join the world, without that I couldn't have get clients spawning (even if its just a void, haha)!
