+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Discussion (https://forum.cuberite.org/forum-5.html)
+--- Thread: Windows 10 Edition vs Cuberite (/thread-2075.html)
Windows 10 Edition vs Cuberite - JBar2000 - 07-29-2015
Hmmm. Will m$'s new C++ version of Minecraft cause any rumblings with Cuberite?
Probably not if the m$ version is only PE. You guys started something here by porting to C++.
RE: Windows 10 Edition vs Cuberite - DiamondToaster - 07-29-2015
It depends, the programming language of the server compared to the client is pretty unrelated, the trick is following the MCPE protocol. Cuberite would have to replicate this: http://wiki.vg/Pocket_Minecraft_Protocol in order for MCPE compatibility to work. According to this wiki, an entire new protocol class would have to be written and would need to handle interactions with "PC version" clients. It's a bit of an undertaking, but due to the modularity of Cuberite's protocol management in the past, it seems feasible. Way back when, Cuberite supported any Minecraft version from 1.2 to 1.7 at the same time.
RE: Windows 10 Edition vs Cuberite - NiLSPACE - 07-30-2015
Could we perhaps implement the protocol using a plugin? Is that even possible with the current API?
RE: Windows 10 Edition vs Cuberite - xoft - 07-30-2015
No, a plugin cannot supply a protocol, simply because it cannot create a new cClientHandle. Also the protocol parsing and serializing would most likely be way too slow. It'd be much easier and better to include the support into the main server.
RE: Windows 10 Edition vs Cuberite - NiLSPACE - 07-30-2015
I had controling everything, from creating it's own Player class to handling the protocol in mind, but if parsing the protocol would be too slow, that's out of the question.
RE: Windows 10 Edition vs Cuberite - DiamondToaster - 07-30-2015
Might as well create a new class for it. It would end up being less bloated and more manageable without extending the current API with stuff that it doesn't need.
RE: Windows 10 Edition vs Cuberite - xoft - 07-30-2015
no, no, no, bad idea.
RE: Windows 10 Edition vs Cuberite - worktycho - 07-30-2015
I personally don't see why a custom protocol requires the ability to create new cClientHandle objects. Can't you just create a new cProtocol descendent?
RE: Windows 10 Edition vs Cuberite - xoft - 07-30-2015
Oh, I was thinking along the lines that the plugin would handle all aspects of the protocol "manually" - if there is a "move 1 block" packet, then it would move the cPlayer by one block.
Implementing a cProtocol descendant in Lua would be easier, but still problematic due to plugin unloading; also the cProtocolRecognizer would need to be made aware of how to select this new protocol.