Spigot GuardianBeamAPI 0.4

An easy solution for manipulating Guardian's beams in Spigot 1.8!

  1. MeRPG submitted a new resource:

    GuardianBeamAPI - An easy solution for manipulating Guardian's beams in Spigot 1.8!

    Read more about this resource...
     
  2. Things I noticed:

    1) You shouldn't compare World objects using Object#equals(Object). Honestly, you really shouldn't be storing World objects. If the World that is stored is unloaded and then reloaded, you'll have a ghost World object that no longer applies to the real one. Object#equals(Object) would fail here. It's like the Player object. Either do not store the World object and keep getting it from Locations, or update it as so. Or store its name as a String and call Server#getWorld(String). If you really don't care for the World object itself and just need it for other objects, I suppose the reference isn't of harm (slight memory leak, maybe? In the case the world was never loaded again), but you'd have to compare each World object's name.

    2) I do not think an ArrayList is the proper Object to store the viewers in this case. You may be better off using a HashSet.

    3) Package naming conventions are fully lowercase.

    4) The EID class. It's not really necessary. UUID#randomUUID() is more than suitable for the job. The chance of having duplicate UUIDs is basically impossible.

    5) A rather excessive use of the keyword "this". It is there to differentiate between objects with similar reference names. You're just using it because you can. Not that this is a problem, but rather a tiny (but still existant) improper coding convention.

    Also, your own Listener class may be needed for clean up (constant use of Player and World objects) and if a player logs out or something of the sort.

    Otherwise, oustanding plugin. Everything comes together smooth, clean, and efficient.

    /e Also, if you need help with getting a Maven repository, I could assist you in getting the API on Maven Central. It requires a little bit of time and know-how to use it though, with a lot more requirements to meet. If you have access to another repository, you're better off using that.
     
    • Like Like x 1
  3. Thanks for all the advice! Let's address these one by one:
    1) There is no problem with using world.equals. It would work just as well. However, I did not consider the possibility that the world might be reloaded by another plugin. I'll be changing this to use world UIDs in the next update.
    2) I do believe you are correct here. A set would provide superior performance.
    3) This is a bit of a nitpicky thing. I don't think I'll change it, as I made the B capital for readability, even though it isn't exactly convention.
    4) I guess I should add more documentation to the EID class. It is generating Entity Ids, not uuids or anything attempting to model it. For more information on how Entity Ids are generated in minecraft, decompile the server and look at the nms world class.
    5) I'm using it because I like to see where something is referencing. Placing a this. in front of fields makes it easy to see that the reference is to a class field and not to a local variable. I find it very useful in visualizing scope.

    Not sure I need a listener class. If the player logs out or changes worlds, that is checked on the next update for managed beams. The #isViewing method can help users of the API to recognize if something like that has happened, and they can then throw out the beam for garbage collection.

    About maven - I considered placing it in central, but I certainly wouldn't do that until I can call everything final. Maven Central isn't where WIP projects like this one should go because of the tedious process of getting an artifact in. I was thinking more along the lines of hitchhiking with some other Spigoteers repository.

    Thanks so much for all the feedback!
     
    • Like Like x 1
  4. Can you please update the api to 1.9?
     
  5. Sorry, it is taking longer than expected to update. As @dmulloy2 said when publishing ProtocolLib's 3.7.0 Beta, Data Watchers were changed and bloated. @dmulloy2 appears to plan to restore that backwards compatibility that will make updating GuardianBeamAPI much simpler. Unless he releases 3.7.0 recommending that developers move to a new (documented) system for using Data Watchers, I will make use of this backwards compatibility.
    If you are up to it, feel free to fork GuardianBeamAPI on GitHub and update it with 3.7.0-Beta. I'd happily merge it. A few pointers if you choose this: You can never under-use the wiki. Note that while the x, y, and z were integers in 1.8, they are now doubles.
    Sorry for any inconvenience this may cause. I just don't have the time to investigate the new Data Watchers in enough depth to do this now, as is. Still stuck in the lonely world of 1.7 for my job, so I really just haven't gotten the chance to tinker too much with 1.9.
     
  6. Okay, thanks for the answer. :)
     
  7. Developers should move to the new system of data watchers documented here: https://github.com/dmulloy2/Protoco...nix/protocol/wrappers/WrappedDataWatcher.java

    Not entirely sure why my javadocs aren't working, but GitHub should do for now.
     
  8. @MeRPG
    Code (Text):
    [21:21:00] [Server thread/ERROR]: #!#! Stack trace:
    [21:21:00] [Server thread/ERROR]: #!#! java.lang.IllegalArgumentException: You cannot register objects without the watcher object!
    [21:21:00] [Server thread/ERROR]: #!#!     at org.apache.commons.lang.Validate.isTrue(Validate.java:136)
    [21:21:00] [Server thread/ERROR]: #!#!     at com.comphenix.protocol.wrappers.WrappedDataWatcher.setObject(WrappedDataWatcher.java:362)
    [21:21:00] [Server thread/ERROR]: #!#!     at net.jaxonbrown.guardianBeam.protocol.PacketFactory.createPacketSquidSpawn(PacketFactory.java:47)
    [21:21:00] [Server thread/ERROR]: #!#!     at net.jaxonbrown.guardianBeam.beam.LocationTargetBeam.<init>(LocationTargetBeam.java:50)
    [21:21:00] [Server thread/ERROR]: #!#!     at net.jaxonbrown.guardianBeam.beam.Beam.<init>(Beam.java:78)
    [21:21:00] [Server thread/ERROR]: #!#!     at net.jaxonbrown.guardianBeam.beam.Beam.<init>(Beam.java:56)
    I might fork it later, but can you fix this?
     
  9. Yes, Yes. I assume this was running 1.9 or 1.10. I've yet to get the time to update it; if you do fork it though, feel free to put in a PR
     
  10. Hope 1.9 support comes soon
     
    • Agree Agree x 1
  11. I've not had time to do it. Might be able to do it in a month or so. In the mean time, feel free to submit a PR.
     
  12. Would like to pay to speed up the process...
    need the plugin
     
    • Agree Agree x 1
  13. Hmm. Sorry everyone, I don't have the time to update this right now. If someone else does update it, a pull request would be appreciated and if someone wants to maintain it into the future let me know.
     
  14. That's a real pity...
     
  15. Am I allowed to just take the code and slot it inside mine and compile it?
     
  16. Yup. It has a github and he says that someone can update it.
     
    #20 LimeGlass, May 29, 2017
    Last edited: Aug 20, 2018