Most conventional way of iterating over a list

Discussion in 'Spigot Plugin Development' started by SKDown, Jul 17, 2017.

  1. Hello, a few months ago I decided to learn how to write plugins so I started developing a plugin. All of the features in the plugin are created for the sole purpose of teaching myself how to do essential things like serialization of data, json adaptation, manipulating game data, language systems etc.
    Here is a trailer for the plugin:

    Now I would like to make it open source so if somebody is trying to learn something basic could check it out which means that I should rewrite most of the classes as the code is a bit sloppy and not really conventional in some cases. So I will probably come again with more threads in the future. Here is the current problem I am facing:

    Currently, the plugin uses PlayerMove event to spawn particles, which I don't know if it is thread safe. Which of the next solutions in your opinion could give me the best ratio between performance and appearance?
    Creating a repeating task which iterates over the whole list with flying players and spawning a particle or
    creating a repeating task per player for spawning the particle? My thoughts are that in the first case if the list is longer players could experience missing particles because it takes longer to iterate over the whole list but the second solution will probably be an overkill to create a task for every player for just a simple spawning. Probably another way of doing this is creating a a new task for every 10 flying players so that everything is organized into small groups but this could lead to complicated dynamic data organization. What are your thoughts about it?
    #1 SKDown, Jul 17, 2017
    Last edited: Jul 17, 2017
  2. I just should keep it for the PlayerMoveEvent
  3. Nothing is thread-safe unless stated otherwise (I'm talking about Spigot (and Bukkit) plugins primarily) - most of the Spigot API is not thread safe.
    You can't spawn particles in async tasks.

    You CAN spawn particles asynchronously, read 2008Choco's post below.
    #3 Trigary, Jul 17, 2017
    Last edited: Jul 17, 2017
  4. For me personally I would probably go with a runnable that iterates through a string list and use Bukkit.getPlayer(). If you really care about performance that much see how many times PlayerMoveEvent is called per tick (make sure to check if their x,y and z values are not the same because this event even triggers when looking around) and that should give you an idea of how it may compare. For example which do you think is worse an event being called 100 times per 20 ticks, for every player, or a runnable that loops through every player 20 times per 20 ticks?
  5. Inkzzz

    Resource Staff

    Make a PlayerMoveBlockEvent and go from there.
  6. 2008Choco

    Resource Staff

    • Like Like x 1
  7. Using UUIDs is probably better.

    Right. I meant using the normal methods, I didn't think of using packets at all! Just for the record, you can also schedule sync tasks from inside an async task, but that is a pretty bad way compared to packets.
    • Agree Agree x 1
  8. 2008Choco

    Resource Staff

    No no, you can use the World#spawnParticle() and Player#spawnParticle() methods asynchronously. All it does is create a packet and send it.
    • Informative Informative x 1
  9. Ah, I see. I didn't know that. Is there a list of methods like that somewhere? (Sorry for the off-topic talk, SKDown)
  10. 2008Choco

    Resource Staff

    No, not really. You just kinda have to know what thread-safety is and be able to understand what is and is not thread-safe. You are correct, however, in saying that most of Bukkit's API is not thread safe.
  11. I am happy to see that you made a nice conversation based on my question. I will probably go with the PlayerMoveBlockEvent then as it is easier if the difference between a task and a simple event is minor from a performance standpoint.

Share This Page