[Lib] PacketAPI - Next generation Packet Management [Questions]

Discussion in 'Resources' started by bigteddy98, Mar 26, 2014.

Thread Status:
Not open for further replies.
  1. Offline

    bigteddy98

    Thanks man :).

    EDIT:
    A little message for everyone, PacketAPI V1.1 has been approved and can be downloaded from the Bukkit Dev page.
     
  2. Offline

    CoderRyan

    can you do stuff like WrappedServerPing etc?
     
  3. Offline

    bigteddy98

    Packets which are send during or before the login, cannot be intercepted yet, I am working on it.

    I just finished the part which can intercept Ping packets, it will be possible to do this with at least version 1.2. (Hopefully approved this evening).

    -BigTeddy98, Sander.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 7, 2016
    ArthurMaker likes this.
  4. Offline

    CoderRyan

    So can i actually set the player count message to a msg? like what mcpvp does
     
  5. Offline

    bigteddy98

    You mean like a message when you hover over your mouse?
     
  6. Offline

    ccrama

    bigteddy98 Can your lib be used to spawn "fake" floating items, only displayed to one person at a time?

    Thanks,
    ccrama
     
  7. Offline

    bigteddy98

    Yes an item is an entity, you can send the entity spawn packet to only one of your players.
    I will try to find out how it exactly works,


    -BigTeddy98, Sander.
     
  8. Offline

    CoderRyan

    When you hover over the player count can you customize the msg like mcpvp?
     
  9. Offline

    bigteddy98

    Just a little update, I am currently working on wrappers for every packet, so you will never have to work with reflection yourself.
     
    glen3b, viper_monster and ArthurMaker like this.
  10. Offline

    xTrollxDudex

    I don't think you understand, you are doing lots of things wrong.

    First of all, you are using console logging to see results.
    Why that is wrong:
    Stream... You're not allowed to do IO before test, that messes lots of things up

    Second, you have made an unfair test.
    What you did:
    - Static allocation: simple, but less flexibility, reduced overhead of running compared to instance method createPacket
    - Object allocation: You're not allowed to have fields outside instantiated first
    - Method of sending: ProtocolLib throws Exception for send, causes overhead in exception handling

    Third, packet send implementations are different:
    ProtocolLib is designed concurrently
    ProtocolLib is also OOP designed, does not use static much, lots of interfaces and abstraction, nice API to work with without exposing internals (frankly, that makes it difficult to see what the code is doing, but whatever)

    Fourth, the entire benchmark is mostly incorrect:
    - "JVM warmup" is not what you think it is... Iterations of trials is not JVM warmup, and besides, you run your timings before and after ALL trials pass... Inconsistencies are made within a loop. You did not allow JVM warmup; it must be 10-20 iterations of control group or GC and/or operations to work the JVM. Running the program again does not count as JVM warmup.
    - I mentioned this - timings should be made WITHIN the loop. Again, there are inconsistencies, and you totally miss all of them
    - System env: this takes a while to execute, hopefully you didn't have any "noisy" apps running in background

    Last, but probably not ALL, JIT optimizations:
    I doubt anyone on this community would know anything about this, but JIT optimizations to fields or code could be made depending on the full code used. JVM also may optimize parts of the code, JVM implementation may optimize code...

    Lots of things...

    bigteddy98
    And I see the main reason PacketAPI is faster is the design. ProtocolLib supports concurrency, and uses OO design plus writes to the fields after creation.

    Aaaaaaaand you still forgot JVM warmup.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 7, 2016
    Garris0n and evilmidget38 like this.
  11. Offline

    bigteddy98

    everyone tells me java has to warm up but I can't "warm up" java if I don't know how to warm it up... :p

    Done, ProtocolLib code HERE, PacketAPI code HERE.

    Result:
    [​IMG]

    - BigTeddy98, Sander.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 7, 2016
  12. Offline

    bigteddy98

    Just to keep you up-to-date, PacketAPI V1.3 has been approved and can be downloaded from the BukkitDev. I am currently still making more and more wrappers to make it easier for you to work with.

    -BigTeddy98, Sander.
     
  13. Offline

    Cirno

    Add -XX:CompileThreshold=1 to the server startup; forces all classes to be compiled as soon as they're loaded. Also, it might help to somehow force load all the classes into memory.
     
    glen3b likes this.
  14. Offline

    bigteddy98

    Just made a 1.7.9 build. For now, it can be downloaded from the link below. I will remove this link as soon as this file has been approved on the BukkitDev.
     
  15. Offline

    viper_monster

    bigteddy98 you should make a Maven repo for this :)
     
  16. Offline

    BungeeTheCookie

    bigteddy98
    Is this compatible with ProtocolLib?
     
  17. Offline

    bigteddy98

    Sure!
     
  18. Offline

    BungeeTheCookie

    YER BOI
     
  19. Offline

    glen3b

    Is this library still maintained? I'd love to see more wrapper classes so I don't have to use ugly reflection when I'm using this in GBukkitCore. Beside from that, congrats on making a packet library, it is the second one I am supporting in GBukkitCore.
     
  20. Offline

    bigteddy98

    ofcourse I am still maintaining it. I recently started on some more wrappers and I will probably include some new ones in upcoming builds.

    BTW, you should change your code so you don't register a listener for both ProtocolLib and PacketAPI, it might conflict.
     
  21. Offline

    glen3b

    bigteddy98
    Why would someone have both installed? The whole point of my wrapper is to abstract specific packet libraries away from the user. Either way, I believe with Netty the listeners won't conflict, but Comphenix is better with Netty than I am. Plus, if both are installed, it wouldn't conflict in my listeners, but in the injectors of both plugins.

    By the way, I was only asking if you were still maintaining it because the last activity on the GitHub repository was 2 months ago.
     
  22. Offline

    Bammerbom

Thread Status:
Not open for further replies.

Share This Page