1.15.2 ProtocolLib: send packet after current handled packet

Discussion in 'Spigot Plugin Development' started by TeamBergerhealer, Feb 9, 2020.

  1. TeamBergerhealer

    Supporter

    So I ran into a fun bug today. I was listening for entity spawn packets to send a mount packet after the two required entities have spawned. I found out that if I send a packet to the player from inside the callback of a packet monitor ( ListenerPriority.MONITOR ), by pure chance either:
    • The packet is sent after the packet
    • The packet is sent before the packet
    Obviously sending a mount packet before the entities are both spawned doesn't work. By delaying the sending by one tick that bug was fixed. But I don't like scheduling a tick delay like that.

    Does ProtocolLib have an API to send the next packet AFTER the packet currently being handled inside a monitor?
     
  2. FrostedSnowman

    Resource Staff

    Are you sure it was only the MONITOR priority causing you this issue? The priority should only touch with the priority that packets are intercepted on different packet listeners.

    To answer your question, I don't believe you can.

    The entire listener system has similar logic to Bukkit's. The packet events are called right before the packet gets sent down the pipeline to the end user, not after the packets have already been sent--otherwise, modification & interception of packets would not be possible.

    You'll need to delay the mounting after a tick to ensure the spawn packets have already been sent.
     
  3. TeamBergerhealer

    Supporter

    I don't think the priority was much of the problem, more so that when you do a send packet while inside a handler, it executes the full sending loop of that packet inside the handler, and then sends the packet being handled. Im sure the same happens in a normal priority listener.

    I have found a middle ground of making use of the NMS NetworkManager PacketQueue to delay packets that way. I have no idea if it will be any faster than sending it the next tick, but for now this works fine. For not sending packets through listeners AND queuing them, I've decided to use a tick delay anyway.

    Another note: I suffered other strange bugs, such as some packets going missing resulting in partially setup entities or entities that are missing altogether. Clearly ProtocolLib does not like it when you do this, it may also be documented somewhere.

    I do keep this open in case somebody knows of an obscure ProtocolLib API to do this, as I'd much prefer that over my own hackjob for reliability reasons.
     
    #3 TeamBergerhealer, Feb 9, 2020
    Last edited: Feb 9, 2020