Have you guys considered making a Minecraft PE Proxy instead of a full server? That way, you could modify selected packets without having to know all of the Minecraft PE Protocol.
The whole point of this project was to create a standalone program that would run Minecraft PE servers like Vanilla servers do with Minecraft.
We have made some progress over the last few days though, one achievement being that receive timeouts now don't result in the server crashing, another is that the server can now read client username packets. Some other minor bugs were also fixed, but they are not as important.
Rollback Post to RevisionRollBack
Did you know I make music? Just click my logo to listen to my awesome Electronic beats!
Toxuin made the github version of the server, 500 ISE made the initial base for our version of the server, I worked on most of how the server operates, looks and works, Intyre does packet interpretations. You should thank everyone I mentioned who contributed greatly.
Of course. ik what intyre does. But yes I thank the whole modding team. Thanks jocopa. Any updates? Have you figured anything out? If you can pull this off you will save many of us from a melting idevice from staying in the game to run our servers
We recently took a break for awhile, but during the break I came up with place block packets. I am currently working on a way to save the placed blocks on a map without knowing the generation algorithm, so what I might do is make a placed.dat holding all placed blocks and send the data to the clients. Otherwise progress is still slow.
Rollback Post to RevisionRollBack
Did you know I make music? Just click my logo to listen to my awesome Electronic beats!
We recently took a break for awhile, but during the break I came up with place block packets. I am currently working on a way to save the placed blocks on a map without knowing the generation algorithm, so what I might do is make a placed.dat holding all placed blocks and send the data to the clients. Otherwise progress is still slow.
A new update, we are trying a new way to organize the server program to make it much more efficient. Before we used one class to store packets and another to 'read' them (it just looked at the ID, nothing else), now we are using a new class for each packet that reads and writes it. We also found the packet structures (what types of variables make it up) in the Android's minecraftpe.so.
There is one extreme setback, and that's how we'd get the server to be functional. If you don't already know, all Minecraft servers handle player movement, blocks, drowning, respawning, hearts, food, etc. The only thing the server doesn't handle is graphical and audio functions. This means in order to make a server we'd either have to program the client data for a server by hand or take the server files for working with servers from the Minecraft Vanilla or Bukkit server. In order to do that, we'd be breaking Mojang's terms of agreement in not to distribute their code. Anyway, we'll work out a solution.
Rollback Post to RevisionRollBack
Did you know I make music? Just click my logo to listen to my awesome Electronic beats!
This means in order to make a server we'd either have to program the client data for a server by hand or take the server files for working with servers from the Minecraft Vanilla or Bukkit server.
There are the SpoutEngine and Vanilla projects; they are implementing Minecraft and all the materials; might be worth a look. Their networking code, of course, would be incompatible, but the rest of the stuff - terrain gen, physics, etc - could be used. http://spout.org
There are the SpoutEngine and Vanilla projects; they are implementing Minecraft and all the materials; might be worth a look. Their networking code, of course, would be incompatible, but the rest of the stuff - terrain gen, physics, etc - could be used. http://spout.org
The terrain generation in MCPE is much different than Minecraft. Same method, different way. Since I don't know the exact algorithm and variables set, I'm just going to either let the user select custom maps and send seed data and modified column data or save all added/removed blocks to a file and send that data to the clients, thus I don't need to generate the chunks.dat.
As for the rest of the project, would I have rights to distribute that code without giving partial ownership (such as what I am allowed to do with their code) to the original writers of it? If not, I could just paraphrase the vanilla code into a completely different code but still do the same exact functions. That is technically legal in the software world.
Rollback Post to RevisionRollBack
Did you know I make music? Just click my logo to listen to my awesome Electronic beats!
As for the rest of the project, would I have rights to distribute that code without giving partial ownership (such as what I am allowed to do with their code) to the original writers of it? If not, I could just paraphrase the vanilla code into a completely different code but still do the same exact functions. That is technically legal in the software world.
They are using a custom SpoutDev license; I'm not actually sure; check with their team.
The terrain generation in MCPE is much different than Minecraft. Same method, different way. Since I don't know the exact algorithm and variables set, I'm just going to either let the user select custom maps and send seed data and modified column data or save all added/removed blocks to a file and send that data to the clients, thus I don't need to generate the chunks.dat.
Notch wrote on his blog that older gen algorithms used 2D Perlin noise for generation. The switch to caves happened by incorporating a 3D Perlin noise algorithm to sample the "density" of an area in 3D space. Any space below 0 is air while everything else is land. Then terrain elements are determined by custom code. http://notch.tumblr.com/post/3746989361/terrain-generation-part-1
Since guessing the exact algorithms isn't very conventional, the only solution is custom generation, send a fake seed to the client then send all the chunk data.
As for the rest of the project, would I have rights to distribute that code without giving partial ownership (such as what I am allowed to do with their code) to the original writers of it? If not, I could just paraphrase the vanilla code into a completely different code but still do the same exact functions. That is technically legal in the software world.
Spout is licensed under a dual license (ie, the SpoutDev license). You have all the rights under the LGPL, "but with a provision that files are released under the MIT license 180 days after they are published." Please see https://github.com/SpoutDev/Spout/blob/master/LICENSE.txt
With a server data base and a connected device would it be possible for the connected device to have, say something like a 'file' with its last coordinates or inventory or (probably not) skin? Thanks guys I really apreciate what your doing
Coordinates and inventory are easy to do with a server and we already have a method for that. Skins are handled by the client and not the server, so that wouldn't work. Basically we are going to save (playername).dat files for each player holding coordinates, inventory, health, air, fire, and at some point hunger and level.
Since guessing the exact algorithms isn't very conventional, the only solution is custom generation, send a fake seed to the client then send all the chunk data.
Since I don't need to have a copy of the chunks (only a file to store placed/removed blocks) the client will just handle seed generation. If the server properties is modified for a custom map, then the server will send chunk data individually instead of letting the client generate the chunks. I don't know exactly if that'd work since I haven't really gotten into investigating the "ChunkDataPacket" very much.
Their networking code, of course, would be incompatible, but the rest of the stuff - terrain gen, physics, etc - could be used.
The networking code is what Intyre and I are explicity looking at in the Vanilla server. Mostly trying to figure out the most "secure" and efficient way to run the server without killing peoples computers with unnecessary processes. We aren't copying everything part-by-part, but rather using it as a structure (how the server is setup, not the code) to build ours. The other stuff, such as terrain generation, physics and all that is handle by the client for the most part, with minor exceptions such as block gravity.
What we need mostly is how blocks function and how entities interact, since that is what the server mostly handles. I am a bit borderline on whether I should just code all the blocks and items myself, since they aren't primarily hard to do, but as for entities and such, that's another story (food, air, deaths, respawn, movement, attacks, etc).
In the Android version, use the quick filter to find "MinecraftPackets::createPacket(int)" which will tell you all the cases and "ID's" for data packets. Search for "RakNetInstance::runEvents(NetEventCallback *)" which will show you all the cases for the main instance.
If you find any packets in examining a server packet dump, packets that start with 84 will most likely be in the "MinecraftPackets::createPacket()" function. Search for a high number like in 9C(hex) and convert it to decimal (156), then find "jumptable ######## case 156" ignoring the # signs. Case 156 is a request chunk packet.
I've only just read through this topic and I'd be lying to say I understood any of the comments relating to packets, etc. Haha, so I wish you good luck even if it's only my benefit in the end. Thank you for your hardwork on enabling we "average users" to have access to that which we normally wouldn't. I really appreciate it!
The whole point of this project was to create a standalone program that would run Minecraft PE servers like Vanilla servers do with Minecraft.
We have made some progress over the last few days though, one achievement being that receive timeouts now don't result in the server crashing, another is that the server can now read client username packets. Some other minor bugs were also fixed, but they are not as important.
Of course. ik what intyre does. But yes I thank the whole modding team. Thanks jocopa. Any updates? Have you figured anything out? If you can pull this off you will save many of us from a melting idevice from staying in the game to run our servers
There is one extreme setback, and that's how we'd get the server to be functional. If you don't already know, all Minecraft servers handle player movement, blocks, drowning, respawning, hearts, food, etc. The only thing the server doesn't handle is graphical and audio functions. This means in order to make a server we'd either have to program the client data for a server by hand or take the server files for working with servers from the Minecraft Vanilla or Bukkit server. In order to do that, we'd be breaking Mojang's terms of agreement in not to distribute their code. Anyway, we'll work out a solution.
There are the SpoutEngine and Vanilla projects; they are implementing Minecraft and all the materials; might be worth a look. Their networking code, of course, would be incompatible, but the rest of the stuff - terrain gen, physics, etc - could be used.
http://spout.org
The terrain generation in MCPE is much different than Minecraft. Same method, different way. Since I don't know the exact algorithm and variables set, I'm just going to either let the user select custom maps and send seed data and modified column data or save all added/removed blocks to a file and send that data to the clients, thus I don't need to generate the chunks.dat.
As for the rest of the project, would I have rights to distribute that code without giving partial ownership (such as what I am allowed to do with their code) to the original writers of it? If not, I could just paraphrase the vanilla code into a completely different code but still do the same exact functions. That is technically legal in the software world.
They are using a custom SpoutDev license; I'm not actually sure; check with their team.
Notch wrote on his blog that older gen algorithms used 2D Perlin noise for generation. The switch to caves happened by incorporating a 3D Perlin noise algorithm to sample the "density" of an area in 3D space. Any space below 0 is air while everything else is land. Then terrain elements are determined by custom code. http://notch.tumblr.com/post/3746989361/terrain-generation-part-1
Since guessing the exact algorithms isn't very conventional, the only solution is custom generation, send a fake seed to the client then send all the chunk data.
Spout is licensed under a dual license (ie, the SpoutDev license). You have all the rights under the LGPL, "but with a provision that files are released under the MIT license 180 days after they are published." Please see https://github.com/SpoutDev/Spout/blob/master/LICENSE.txt
Coordinates and inventory are easy to do with a server and we already have a method for that. Skins are handled by the client and not the server, so that wouldn't work. Basically we are going to save (playername).dat files for each player holding coordinates, inventory, health, air, fire, and at some point hunger and level.
Since I don't need to have a copy of the chunks (only a file to store placed/removed blocks) the client will just handle seed generation. If the server properties is modified for a custom map, then the server will send chunk data individually instead of letting the client generate the chunks. I don't know exactly if that'd work since I haven't really gotten into investigating the "ChunkDataPacket" very much.
The networking code is what Intyre and I are explicity looking at in the Vanilla server. Mostly trying to figure out the most "secure" and efficient way to run the server without killing peoples computers with unnecessary processes. We aren't copying everything part-by-part, but rather using it as a structure (how the server is setup, not the code) to build ours. The other stuff, such as terrain generation, physics and all that is handle by the client for the most part, with minor exceptions such as block gravity.
What we need mostly is how blocks function and how entities interact, since that is what the server mostly handles. I am a bit borderline on whether I should just code all the blocks and items myself, since they aren't primarily hard to do, but as for entities and such, that's another story (food, air, deaths, respawn, movement, attacks, etc).
(Whispers "I'm not actually dead, I'm just in hiding and watching you all...)
In the Android version, use the quick filter to find "MinecraftPackets::createPacket(int)" which will tell you all the cases and "ID's" for data packets. Search for "RakNetInstance::runEvents(NetEventCallback *)" which will show you all the cases for the main instance.
If you find any packets in examining a server packet dump, packets that start with 84 will most likely be in the "MinecraftPackets::createPacket()" function. Search for a high number like in 9C(hex) and convert it to decimal (156), then find "jumptable ######## case 156" ignoring the # signs. Case 156 is a request chunk packet.
There is none. Intyre and I store it on a private repository on his site.