Solved Check if player can build at certain location

Discussion in 'Spigot Plugin Development' started by Lockface77, May 28, 2020.

  1. Hello,

    I have an event in which when the player break a block with a certain tool, I do some cool stuff.

    But I wanna check if the user can build at the location of the broken block.

    In order to do that, I have set the priority of the event "BlockBreakEvent" to HIGHEST:

    Code (Java):
    @EventHandler(priority = EventPriority.HIGHEST)
        public void onBreakBlock(BlockBreakEvent event) {
        // Do my cool stuff
    So my event is fired at last and if it was canceled before, it mean that the player is not able to build here.

    My question is that is it a safe way of doing it?
    Will it work with plugins such as Factions or Worldguard?

    If not, is there any better way of achieving what I want to do instead of hooking in each zone safety plugin to check if the location is not safe by this plugin?
  2. Hey, I do not quite get what you mean. What do you want to check and what do you mean with "can built at the certain location"?
  3. Okay, I think I get it. With setting the priority you want to check whether the event was canceled by another plugin and based on that do your stuff, right?
  4. Yes thats my plan.
    • Friendly Friendly x 1
  5. You just have to check
    Code (Java):
    thats all!
    • Winner Winner x 1
  6. Ok, thank you,

    Then if I do priority highest and then check if it is cancelled it is enought to be sure that the player is not able to build at the location.

    Then the code:
    Code (Text):
    @EventHandler(priority = EventPriority.HIGHEST)
    public void onBreakBlock(BlockBreakEvent event) {
        if (event.isCancelled())
        // Do my cool stuff
    Should work
    • Friendly Friendly x 1
  7. That's right, in this way you are sure that the user cannot build in this location
    • Like Like x 1
  8. Thank you both for your answers :)
  9. Whoa whoa whoa whoa whoa, hold it right there!

    What if another plugin also modifies events at EventPriority.HIGHEST level? How can you guarantee that your plugin's event handler will be the very last one called? As a very close example, WorldGuard uses EventPriority.HIGH (and it ignores events that earlier handlers have cancelled):

    It would be easy for the developer to bump it up to HIGHEST, or for another plugin to operate at this priority level.

    I'm not aware of a better solution to this, but know that there are potential caveats.

    Also, I don't think that cancelled events generally get passed down to higher-priority listeners without the ignoreCancelled=true annotation parameters. So your best bet would be @EventHandler(priority=EventPriority.HIGHEST, ignoreCancelled = true)
  10. Exactly. Given no other plugin uses highest priority, yes. If this is the case, just modify the plugin, a JAR is like a ZIP file.
  11. Well most plugins should not do that when just preventing block breaking, although you can never be sure
    • Like Like x 1
  12. unless you are modifying the outcome of the event, you can even use EventPriority.MONITOR. Event Handlers with MONITOR priority run after all Event handlers with HIGHEST Priority. Event Handlers with MONITOR Priority should (as the name implies) only monitor the outcome of the event, but not actually modify it themselves.
    • Agree Agree x 3
    • Like Like x 1
  13. Woah nice, I did not know of that.
  14. Yes I have seen it but I was scared to do that x)
  15. I cancel the event too, will it work with monitor?

    What I do is a player have a certain tool, it instantly depop the item and give the item in player's inventory. without dropping.

    I do that for sugar cane so I set all sugar canes to air and give the amount set to air to the user.
  16. cancelling the event is modifying the outcome, so you should probably stick to Event priority HIGHEST.
    • Agree Agree x 1
  17. Will it work? Yes. But it's an off-label use, so it's possible that later implementations of the API might only fire off MONITOR priority events after the event has already completed, effectively nullifying any cancellation a MONITOR-level handler does. In fact, if I were writing the API, that's exactly how I would structure it, so as to enforce monitor-like behavior. Might go submit a PR for that right now...