ProtocolLib

111 - Filtered option when sending packets is ignored

What step will reproduce the problem? Send a Packet51MapChunk to ProtocolLib using the:

ProtocolLibrary.getProtocolManager().sendServerPacket(player, packet, false);

method. The false is for filtered = false, meaning that it should not try to filter the packet. Only monitoring listeners should receive the packet.

What is the expected output? What do you see instead? I expect the packet not to end up at a non-monitoring listener, instead it does. This causes issues, since the packet was not meant to be handled (filtered).

What version of the product are you using? Latest is not an answer! Version 2.5.0 on CraftBukkit 1.6.2 R0.1

Do you have an error log of what happened? http://pastebin.com/Fnvm6B0S

If possible, please post a list of which additional plugins you're using, and their respective version number. NoLagg v1.90.1 #5, BKCommonLib v1.54 #234, Orebfuscator v1.9.6

Please provide any additional information below. This was working during the 1.5.2 builds, but stopped working during 1.6.2 builds. Fixing this in Nolagg or BKCommonLib is not possible at the moment, since I rely on ProtocolLib to deal with listener-ignored packets.

User When Change
aadnk Jul 26, 2013 at 02:04 UTC
aadnk Jul 26, 2013 at 02:02 UTC
bergerkiller Jul 25, 2013 at 23:02 UTC Changed description type from Plain Text to WikiCreole

Changed description:
- What step will reproduce the problem?
+ **What step will reproduce the problem?**
+ Send a Packet51MapChunk to ProtocolLib using the:
- Send a Packet51MapChunk to ProtocolLib using the ProtocolLibrary.getProtocolManager().sendServerPacket(player, packet, false) method.
- The false is for filtered = false, meaning that it should not try to filter the packet. Only monitoring listeners should receive the packet.
+ <<code java>>
+ ProtocolLibrary.getProtocolManager().sendServerPacket(player, packet, false);
+ <</code>>
+
+ method. The false is for filtered = false, meaning that it should not try to filter the packet. Only monitoring listeners should receive the packet.
+
- What is the expected output? What do you see instead?
+ **What is the expected output? What do you see instead?**
  I expect the packet not to end up at a non-monitoring listener, instead it does. This causes issues, since the packet was not meant to be handled (filtered).
- What version of the product are you using? Latest is not an answer!
+ **What version of the product are you using? Latest is not an answer!**
- Version 2.5.0
+ Version 2.5.0 on CraftBukkit 1.6.2 R0.1
- Do you have an error log of what happened?
+ **Do you have an error log of what happened?**
  http://pastebin.com/Fnvm6B0S
- If possible, please post a list of which additional plugins you're using, and their respective version number.
+ **If possible, please post a list of which additional plugins you're using, and their respective version number.**
- NoLagg, BKCommonLib, ProtocolLib
+ NoLagg v1.90.1 #5, BKCommonLib v1.54 #234, Orebfuscator v1.9.6
- Please provide any additional information below.
+ **Please provide any additional information below.**
  This was working during the 1.5.2 builds, but stopped working during 1.6.2 builds. Fixing this in Nolagg or BKCommonLib is not possible at the moment, since I rely on ProtocolLib to deal with listener-ignored packets.
bergerkiller Jul 25, 2013 at 22:59 UTC Create

You must login to post a comment. Don't have an account? Register to get one!

  • 3 comments
  • Avatar of aadnk aadnk Jul 26, 2013 at 12:52 UTC - 0 likes

    No problem. :)

    Keep in mind that this particular overload was added in 2.5.0, but it shouldn't be hard to fall back to the old method if the overload doesn't exist.

    Last edited Jul 26, 2013 by aadnk
  • Avatar of bergerkiller bergerkiller Jul 26, 2013 at 08:10 UTC - 0 likes

    All right, I'll temporarily use that other method in BKCommonLib then, should be fine. After some time I can always revert back (may the marker method end up missing)

    Thanks for looking into it :)

  • Avatar of aadnk aadnk Jul 26, 2013 at 02:02 UTC - 0 likes

    Oh, wow, this is embarrassing ...

    Looks like I forgot to pass on the "filtered" parameter when I added the NetworkMarker feature in 2.5.0. I've fixed this and it should be live on the latest developer build (2.5.1-SNAPSHOT).

    A possible workaround could be to use the overload sendServerPacket(Player, PacketContainer, NetworkMarker, boolean) in 2.5.0. Just pass NULL as the NetworkMarker.

    I'll just close the ticket as FIXED for know, but let me know if I missed something.

    Last edited Jul 26, 2013 by aadnk
  • 3 comments

Facts

Last updated
Jul 26, 2013
Reported
Jul 25, 2013
Status
Fixed - Developer made requested changes. QA should verify.
Type
Defect - A shortcoming, fault, or imperfection
Priority
Medium - Normal priority.
Votes
0

Reported by

Possible assignees