-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chunks aren't appearing on the client #5
Comments
When I was creating my own proxy, I used this class to translate the chunk data https://gist.github.com/MrPowerGamerBR/e751de1a5cf17fa93212768e91648f64 However this is very old, probably from 0.14/0.15, but maybe it will be useful. What is the worst part is the "PEChunkRadiusUpdatePacket" (or it was another packet?), if you don't sent it, the client won't render the chunks for some reason. |
Can you tell me everything you know about getting the Minecraft PE client to render chunks? |
@robotman3000 if I knew why the chunks aren't rendered, I would already fixed it 😋 What you can do is creating a plugin for Nukkit to see what packets are sent/received by the client/server. Also, try sending a full stone chunk, then you can find out if it is the chunk translator issue, of if it is the client that doesn't want to render the chunk. Also, maybe they aren't sent because the client didn't receive any chunk data, so the client doesn't send any movement packets. |
I tried debugging the chunk packets and I didn't find anything useful... I removed every PC chunk translator packet and changed the initial air chunks to stone and sent the request chunk packet to the client... nothing, still air. Try figuring out how to send a full stone chunk before trying to figure out the PC chunk translator, because, if you figure out how to send successfully a stone chunk, then you know 100% that it is the translator that is wrong. |
@robotman3000 after looking a little bit here https://confluence.yawk.at/display/PEPROTOCOL/Login+sequence I found something wrong with DragonProxy The client first requests the chunk, then you send the chunk data and then you send the updated chunk packet. But in DragonProxy it is sending the chunk data, then the client requests the chunk and then you send the updated chunk packet. I don't know if the order matters, but hey, maybe that's the issue, right? |
This is the packet order in Nukkit https://gist.github.com/MrPowerGamerBR/aac5d16b62ffedd80f429bac2d10d752 So ignore what I said, the chunk request/chunk data/update packet order doesn't matter |
This is the packet order in Nukkit https://gist.github.com/MrPowerGamerBR/aac5d16b62ffedd80f429bac2d10d752 So ignore what I said, the chunk request/chunk data/update packet order doesn't matter And, if you need, here is a dump of a (working) FullChunkDataPacket in text format: https://gist.github.com/MrPowerGamerBR/b29670c92949a297b716e269d2b488b0 |
What you can do is send that FullChunkDataPacket dump for every chunk you send to the client. That way you can test the translator and packet order logic independent of the actual chunk translation. |
I have, actually made a plugin like you suggested already. Here is the source and plugin jar for you to use Packet Serialization is somewhat broken because some of the nukkit packets have circular references that mess up GSon |
I will try doing that later, shouldn't be too difficult to send the payload
array again.
Em 21 de jan de 2017 12:22 PM, "robotman3000" <notifications@github.com>
escreveu:
… What you can do is send that FullChunkDataPacket dump for every chunk you
send to the client. That way you can test the translator and packet order
logic independent of the actual chunk translation.
@NiclasOlofsson <https://github.com/NiclasOlofsson> might be able to help
us solve this problem.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJDnJ6NuMMz8SZ1mn33nDKfeg_oQZYE9ks5rUhSIgaJpZM4LnmzJ>
.
|
@robotman3000 here is my plugin, it doesn't have the StackOverflow issue due to circular references. https://gist.github.com/MrPowerGamerBR/0ed5b4f6b6d1dd0f04ba641934bbbf82 https://gist.github.com/MrPowerGamerBR/c3580d57f71ea50ce751224db7486cc7 |
Done more debugging and I still couldn't find the issue, I created a command to send the chunks when I want but still, nothing is rendered. |
I haven't checked your code. But I trust you understand that the chunk-format completely changed with 1.0. |
I had begun to understand that. @NiclasOlofsson Do you have good documentation on this new chunk-format? |
Also, will the client render the chunks once it receives them or are there other packets that have to be sent first? |
@robotman3000 if you are using the Nukkit classes, then I suppose that they are correct when you use toFastBinary, yeah, the translator is probably wrong, but the flat chunk method shouldn't be wrong. Well, if it is wrong, then Nukkit is also wrong, but Nukkit works, so... |
if it spawns, then it's usually just the chunks that are missing. |
So, that would mean that the problem is that the proxy isn't sending properly formatted chunks to the client. I am able to get the client to spawn, but it won't send movement packets and it won't render any chunks. I can get it to send packets when the clients inventory is opened, though. |
Actually, when I use toBinary (I think that's it) the client crashes. toFastBinary doesn't appear to have any effect |
@NiclasOlofsson this is what happens when you try to login DragonProxy sends a flat chunk with only air on login and then the PC server chunks after the player is logged in, the PC chunk translator is probably broken since 0.14, so I disabled it for testing, however the flat chunk with only air should work since it is from Nukkit, and Nukkit works in 1.0.0 |
@robotman3000 also, don't forget to change the world format in the flat chunk method, it should be Anvil, not MCRegion. (due to the 256 world height limit, MCRegion only supports up to 128) |
@robotman3000 To be honest, I don't even know if the toBinary/toFastBinary are even used in Nukkit when sending packets, after taking a quick look at the source code it seems that method is never used when sending chunk data. |
@robotman3000 yeah, toBinary/toFastBinary shouldn't be used at all, AFAIK they are used to save chunk data to disk, not to transform the data for packets. |
Well there's my problem. |
@robotman3000 here is how Nukkit does it magic for chunk data
|
Where was that? |
Strange, Nukkit uses that code to encode the chunks and it works (at least in the Anvil map format, not sure about LevelDB/MCRegion) Or probably that is old code that for some reason is still in Nukkit |
https://github.com/NiclasOlofsson/MiNET/blob/master/src/MiNET/MiNET/Worlds/ChunkColumn.cs#L307 and https://github.com/NiclasOlofsson/MiNET/blob/master/src/MiNET/MiNET/Worlds/Chunk.cs#L91 A "chunk column" is x number of chunks counting from bottom-up. Max 16 but can be less. |
Here is how Nukkit handles chunk data in MCRegion
I also don't know if it is right, but Nukkit uses that |
that's also wrong |
Then... how is Nukkit still working???? |
@robotman3000 I'm probably looking at the wrong place then... I even tried looking at the 1.0.0 branch (I think master is already on 1.0.0 but just to be sure) but the code is the same |
This one is "correct". At least from just looking at it. |
Regarding that wiki @robotman3000: It's still valid, but it's not the problem you have. |
So, @MrPowerGamerBR in UpstreamSession you can try changing to cn.nukkit.level.format.anvil.Chunk chunk = cn.nukkit.level.format.anvil.Chunk.getEmptyChunk(chunkX, chunkZ); in the getFlatChunk method and see if it works. |
@NiclasOlofsson when does that problem apply? |
It applies when you send chunks, and the last chunk is not air. You never see that in a regular world, because it keeps generate chunks .. but for a PVP server, loading a limited map, it always apply. You can recognize the problem easily since you can't see the blocks, but you can interact with them. The problem you are having is a problem we all had before sending proper chunks. It spawns without chunks. Earlier versions wouldn't even spawn, so that changed with 1.0. |
This doesn't work, will probably take a look later, anyway, thanks for helping @NiclasOlofsson 👍 (I would use MiNET if it worked on Linux, maybe someday when Mono implements crypto...) |
The problem is that I can't even figure out what the client even thinks about the packet, in Minecraft PC when you send a invalid packet it crashes and says in the crash log what was the issue, but in MCPE/MCW10 it seems it just throws away the packet like nothing never happened. |
Nukkit is just fine, so I'd stick to that if I wanted to do anything but Windows :-) The more servers, the merrier ! |
@NiclasOlofsson if Nukkit was still actively maintained... nowadays it only receives minimal bug fixes and protocol updates 😢. Even a lot of bugs that doesn't exist anymore in PocketMine-MP still exists in Nukkit |
Oh, i thought nukkit had payed developers. But maybe I'm mistaking that with some other server. |
Yes @NiclasOlofsson, thanks for your help 👍 . @MrPowerGamerBR I share your frustration with the lack of logging |
@NiclasOlofsson you are probably mistaking with Voxelwind, Voxelwind is sponsored by The Hive, however Voxelwind is on hold because the maintainer is busy with other projects. (And Voxelwind is nowhere near completion, the only thing you can do yet is join the server, place and break some blocks on a flat terrain, that's it.... but it has future) Nukkit is literally a PocketMine-MP port to Java |
Yeah, you are right. No project that doesn't get actively maintained at that stage has a "future". Not really. |
@NiclasOlofsson well, Tux (minecrafter) said why he has Voxelwind on hold (he got busy with real life + other Minecraft related project) so that's why it isn't actively maintained. So maybe I should change to "it had a future and maybe it has a future if it gets actively maintained again" |
Four hours later and I still couldn't figure out how to handle those chunks. Will keep trying... It doesn't help that you don't receive any feedback from MCPE, because only three things can happen when dealing with packets:
I'm trying to create my own minimal server to debug the issue, already got the client joined the server (really, it was easy), but of course I can't figure out those chunks. |
Perhaps we should enlist the help of one of the PocketMine-MP developers. |
@robotman3000 the problem is figuring out what fields are required for a chunk packet I think it is like that: Chunk X - VarInt If you send everything, it should work. Here is what I done (but didn't work)
The problem with MCPE development is the lack of a good, explained, protocol documentation, the PC version has a very extensive and good protocol documentation, the only similar thing that exists is yawk.at's MCPE documentation, but that's outdated since 0.15. |
6 days later and I still couldn't figure out how to send chunks I tried doing this
But nope, didn't work. |
Tried replaying the data sent by Nukkit when sending a chunk and... Also didn't work. |
Try replaying an exact packet stream from Nukkit and slowly remove packets, to see what is required to get chunks to appear |
@robotman3000 I will try doing that later. In theory, my code should work, but it doesn't.
But nope, NOTHING happens. |
No idea with this one. MiNet documentation suggests something to look into
The text was updated successfully, but these errors were encountered: