Is the problem reproducible ? If yes, please describe how1. Use /season snow1. Stand at a location where snowfall is visible2. Let a plugin re-send a chunk using 'Packet51MapChunk'3. Notice that snowfall disappears
What's the problem ? What should be ?It should properly alter the map packet chunk biome data to replace it with a snowy biome, but this doesn't work. Unlike the packet 56 map chunk BULK which does work as expected.
What version of Seasons,Craftbukkit, (ProtocolLib) do you use ?Seasons: v2.0.1CraftBukkit: 1.4.7 R1.0ProtocolLib: v2.2.0
Do you have an error log ? If yes, please provide itNo errors.
Please provide the seasons config.It's the default config, left unchanged from startup.
Any more informations ?This issue has nothing to do with NoLagg or BKCommonLib - it is an issue in general.Code to reproduce this: http://pastebin.com/GwsJ1tME
ProtocolLib IS installed, and it is working fine. I have tested it using my own Packet listener, it listens for it correctly.
Let me stress: it DOES work using a new MapChunkBulk packet, it simply fails with the 51MapChunk packet. I suspect that it wasn't noticed that it was broken because all 51-chunks are replaced (in the server) with bulks, but plugins still use this 51 version to send updated chunk data.
Also note that because of this NoLagg chunks was failing, since it uses Packet51 to send chunks. (it can't line the bulks up). After changing the send line to send a bulk containing one chunk, it correctly showed snow instead of rain again.
Hint: check your packet listener where you prepare your chunk info from the packet51 - could be the int offset you used for biome/chunk mask is incorrect. Maybe you forgot that there are also variables declared in the Packet base class? (not sure if those are included in the fields ProtocolLib declares)
I'm not really getting what you're saying.
I'm handling both MapChunk and MapChunkBulk (that are packet 33 & 38)
But I don't know packet 51.
What is it ?
Here is the source code of my listener.
Any way to help ?
Thanks in advance,
MapChunk = Packet51MapChunk in net.minecraft.server
MapChunkBulk = Packet56MapChunkBulk in net.minecraft.server
Maybe the naming is different in ProtocolLib, because I'm not sure where you got the 33/38 from.
Check that this piece of code is really working as it should be. ProtocolLib should provide you with some way to construct a map chunk packet too, possible along the lines of newInstance(int id).
Easiest is to add CraftBukkit as dependency and send a Packet51 (MapChunk) this way, possibly in a separate plugin under a command.
The bulk conversion method (computeMapChunkBulk) is working just fine, same for the method IT calls at the end. It is mainly the MapChunk packet to Chunk Info method where something is broken. I suspect that you are reading the wrong fields for the data masks or the wrong boolean field, verify all of this yourself by printing what is read there.
Another thing I noticed is that you have: 'if (info.hasContinous)' in that last method. This makes me suspect that it is reading false instead of the standard true for the 'continuous' boolean. (which actually just sets whether biome data is sent, not sure what continuous means in this context)
33 and 38 is just the hex-representation of 51 and 56. :P
As for constructing packets, the recommended way is by calling ProtocolManager.createPacket(int).
I do no create packet.
Only modifying the sending of it.
But in fact, I did not understand what is not working ?
It's working well on my test server.
You may have an conflict with another plugin
It is working on your server because the server does not send Packet51 map chunks, it sends bulks. To test it, you have to MANUALLY send these packets. The only time when the server sends these chunk it sends them to update blocks, and in that case biome information is excluded.
You NEED another plugin to test it because the functionality is plugin defined. You need to test your Packet51mapchunk handler to see if it is really working. There is no possible way a plugin can fix your issue, because you are not handling the packet right.
You can mark it an issue for the plugin using the packets, but in the end you are the one handling the packet. No plugin can fix that issue, as i'ts not his issue.
The Packet51MapChunk packet does flow through the PacketListener of ProtocolLib (I have checked) so it definitely reaches your listener. The sender can not be to blame for that reason alone.
Ok thanks for explaining everything.
I'll try to look how I'm handling that packet
I really don't see where the issue is.
Here is the code I use to handle Packet 51 MapChunk.
I check the hasContinious and everything seems ok.
Sorry in advance if I'm blind or something like that :)
Thanks for helping.
To post a comment, please
or register a new account.