Snow biome changing is failing for map chunks #84


  • Defect
  • Started
Open
Assigned to _ForgeUser7458855
  • _ForgeUser7105870 created this issue Mar 5, 2013

    Is the problem reproducible ? If yes, please describe how
    1. Use /season snow
    1. Stand at a location where snowfall is visible
    2. 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.1
    CraftBukkit: 1.4.7 R1.0
    ProtocolLib: v2.2.0

    Do you have an error log ? If yes, please provide it
    No 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.

  • _ForgeUser7105870 added the tags New Defect Mar 5, 2013
  • _ForgeUser7105870 edited description Mar 5, 2013
  • _ForgeUser7105870 posted a comment Mar 5, 2013

    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)


    Edited Mar 5, 2013
  • _ForgeUser7458855 posted a comment Mar 5, 2013

    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 ?

    http://pastiebin.com/51368d21eabfa

    Thanks in advance,

    Rominos2


    Edited Mar 5, 2013
  • _ForgeUser7105870 posted a comment Mar 5, 2013

    @rominos2: Go 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.

    http:www.hastebin.com/lixuketahu.avrasm

    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.


    Edited Mar 5, 2013
  • _ForgeUser7105870 posted a comment Mar 5, 2013

    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)

  • _ForgeUser1707009 posted a comment Mar 5, 2013

    @bergerkiller: Go

    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).

  • _ForgeUser7458855 posted a comment Mar 6, 2013

    @aadnk: Go

    I do no create packet.
    Only modifying the sending of it.

    @bergerkiller: Go

    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


    Edited Mar 6, 2013
  • _ForgeUser7458855 removed a tag New Mar 6, 2013
  • _ForgeUser7458855 added a tag Started Mar 6, 2013
  • _ForgeUser7105870 posted a comment Mar 6, 2013

    @rominos2: Go 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.

    1. The sending of Packet51 map chunks with biome information is not done by the server (anymore)
    2. The packet still supports it
    3. Plugins are still using this packet to send (updated) chunks to clients
    4. Your handler for this packet is broken in some way, resulting in no biome information being updated
    5. Server does not send the packet, so to reproduce it, you will have to send the packet yourself

    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.


    Edited Mar 6, 2013
  • _ForgeUser7458855 posted a comment Apr 3, 2013

    @bergerkiller: Go

    Ok thanks for explaining everything.

    I'll try to look how I'm handling that packet

  • _ForgeUser7458855 posted a comment Apr 9, 2013

    @bergerkiller: Go

    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 :)

    http://pastiebin.com/51641b881c37d

    Thanks for helping.


    Edited Apr 9, 2013

To post a comment, please login or register a new account.